[ih] Memories of Flag Day?

[Brian E Carpenter]

Jack,

Three comments.

1. For many people, the whole business of governments formally requiring
a switch to IPv6 is too reminiscent of GOSIP and its abject failure for
comfort. You'll find a lot of cynicism in the netops community about this.

2. As you say:

> ... those documents don't say anything about any IT hardware or 
> software that is not government-owned.  There's a *lot* more of that on 
> the 'net now than there was in 1983.  I don't see anything in the plans 
> describing how all of those users' IT will be upgraded to only use IPV6.


Despite various government mandates around the world over many years,
industry is never going to migrate to IPv6 just because somebody tells
them to. We're now at between 30% and 50% IPv6 support (according to
whose statistics you prefer) because operators have decided that's
beneficial to them. (Many vendors and open-source implementers are
well ahead of operators, but it's deployment that counts.)

> But it looks like at some point fairly soon (few years), if you want to
> use any US government services, you'll have to use IPV6 to do it.

I don't think so. All the evidence is that operators of public-facing
services will retain IPv4 support indefinitely, alongside IPv6. On the
other hand, *contractors* for government departments might find IPv6
support to be mandatory.

Regards
    Brian Carpenter

On 17-Aug-23 04:19, Jack Haverty via Internet-history wrote:
> Thanks Greg -- very interesting documents.   I'm not "in the loop" these
> days, but it looks like a US-government-wide edict to complete the
> migration of all "public-facing" services first to include IPV6, and
> then transition to IPV6 only, removing IPV4.   NIST is producing new
> testing mechanisms too.
> 
> Sounds very similar to the NCT->TCP "Flag Day" in 1983 that successfully
> decommissioned NCP.   But of course the US government is a much smaller
> player in today's Internet.
> 
> However, those documents don't say anything about any IT hardware or
> software that is not government-owned.  There's a *lot* more of that on
> the 'net now than there was in 1983.  I don't see anything in the plans
> describing how all of those users' IT will be upgraded to only use IPV6.
> 
> But it looks like at some point fairly soon (few years), if you want to
> use any US government services, you'll have to use IPV6 to do it.  It
> will be interesting to see if that carrot/stick is now enough to get
> IPV4 replaced.   I wonder when they're going to tell the public.
> 
> The schedule is interesting.  That document is dated November 2020. By
> now there should be plans for the implementation of IPV6 "native"
> operation (i.e., IPV4 no longer used at all) - see item 4 below. Anyone
> find these online?   Or similar plans from other governments or ISPs etc.?
> 
> Jack
> 
> "To keep pace with and leverage this evolution in networking technology,
> agencies shall:
> 1. Designate an agency-wide IPv6 integrated project team (including
> acquisition, policy,
> and technical members), or other governance structure, within 45 days of
> issuance of this
> policy to effectively govern and enforce IPv6 efforts;
> 2. Issue and make available on the agency's publicly accessible website,
> an agency-wide
> IPv6 policy, within 180 days of issuance of this memorandum. The
> agency-wide IPv6
> policy must require that, no later than Fiscal Year (FY) 2023, all new
> networked Federal
> information systems are IPv6-enabled 7 at the time of deployment, and
> state the agency's
> strategic intent to phase out the use of IPv4 for all systems;
> 3. Identify opportunities for IPv6 pilots and complete at least one
> pilot of an IPv6-only
> operational system by the end of FY 2021 and report the results of the
> pilot to 0MB upon
> request;
> 4. Develop an IPv6 implementation plan 9 by the end of FY 2021, and
> update the
> Information Resources Management (IRM) Strategic Plan 10 as appropriate,
> to update all
> networked Federal information systems (and the IP-enabled assets
> associated with these
> systems) to fully enable native IPv6 11 operation. The plan shall
> describe the agency
> transition process and include the following milestones and actions: 12
>    a. At least 20% of IP-enabled assets on Federal networks are operating
> in IPv6-only
> environments by the end of FY 2023; 13
>    b. At least 50% of IP-enabled assets on Federal networks are operating
> in IPv6-only
> environments by the end of FY 2024;
>    c. At least 80% ofIP-enabled assets on Federal networks are operating
> in IPv6-only
> environments by the end of FY 2025; and
>    d. Identify and justify Federal information systems that cannot be
> converted to use
> IPv6 and provide a schedule for replacing or retiring these systems;
> 5. Work with external partners to identify systems that interface with
> networked Federal
> information systems and develop plans to migrate all such network
> interfaces to the use
> ofIPv6;and
> 6. Complete the upgrade of public/external facing servers and services (
> e.g., web, email,
> DNS, and ISP services) and internal client applications that communicate
> with public
> Internet services and supporting enterprise networks to operationally
> use native 1Pv6.
> "
> 
> 
> On 8/13/23 00:14, Greg Skinner wrote:
>> Jack,
>>
>> The following two links may speak to some of the concerns you have
>> raised.  The first [1] discusses the completion of an IPv6 transition
>> plan for (US) Federal information systems and services. The second [2]
>> is a NIST publication.
>>
>> Additional material may be found by following links from the
>> DuckDuckGo query results at
>> https://duckduckgo.com/?va=a&t=hn&q=us+government+ipv6+mandate&ia=web
>> <https://duckduckgo.com/?va=a&t=hn&q=us+government+ipv6+mandate&ia=web>.
>>
>> [1] https://www.whitehouse.gov/wp-content/uploads/2020/11/M-21-07.pdf
>>
>> [2]
>> https://www.nist.gov/news-events/news/2020/12/nist-updates-usgv6-program-support-new-federal-ipv6-initiatives
>>
>> —gregbo
>>
>>> On Aug 10, 2023, at 9:16 AM, Jack Haverty via Internet-history
>>> <internet-history at elists.isoc.org> wrote:
>>>
>>> I've been wondering if the IETF is still effective today.   It's been
>>> trying for decades to cajole the Internet into adopting IPV6.
>>>
>>> Instead we now live with a multi-protocol Internet, and the
>>> complexity and problems that come with it.  In the 90s, the world
>>> embraced TCP and got rid of all the other protocols.   As I
>>> understand it, the IETF now "puts new technology on the shelf, where
>>> anyone is free to pick it up and use it" - quite different from the
>>> management process that orchestrated "Flag Day" and managed the
>>> evolution of the Internet technology in the field. Some people have
>>> "picked up" IPV6, but many have not. I can't tell if I have. I also
>>> have no idea how I would do it.   Or why I should.
>>>
>>> Perhaps someone can fill in the history of how the Internet got from
>>> then to now?  I sent an email on this topic a week or so ago, but it
>>> seems to have never come out of the elists.isoc.org system.   FYI,
>>> here it is, in case you didn't get it:
>>>
>>> --------------------
>>>
>>> IIRC, the "Flag Day" was one piece of a larger plan.
>>>
>>> I don't recall the timing of the pieces - it was 40+- years ago. But
>>> there was also a bureaucratic action in that same era to declare TCP
>>> a "DoD Standard", and require its presence in DoD procurements - any
>>> computer system in a DoD purchase using networking had to have TCP.
>>> Also, there was a program created by NIST (or was it still NBS then?)
>>> to provide a test suite for conformance to the TCP standard.   So any
>>> contractor who wanted to sell something to DoD had to have TCP, and
>>> by going through the NIST test suite they could get a certificate
>>> proving that they had TCP implemented properly. I don't remember
>>> which of these happened in what order or how it related to Flag Day
>>> (1/1/1983). But it all seems to me to be part of some larger plan to
>>> migrate the admittedly small existing network to a new standard.
>>>
>>> At BBN, we went through the NIST process to become a certified
>>> testing lab, so we could run the tests for anyone who needed it and
>>> issue conformance certificates.  I'm not sure how many other such
>>> labs there were.  We also provided consulting services to help people
>>> understand TCP and figure out why their software didn't pass the
>>> tests.   This was never seen as any kind of "money maker", but seemed
>>> important to do it, since we had access to IMPs and such which made
>>> it easy to set up a small test lab.
>>>
>>> I never saw "the plan", but it struck me that there was a lot going
>>> on behind the scenes to make things like this happen, outside of the
>>> research or Arpanet community or technology per se, in order to
>>> facilitate the introduction of TCP to DoD.  Maybe someone else knows
>>> more about who was involved in all that activity.   Somebody made
>>> those things happen...
>>>
>>> In retrospect, it seems to me that such "soft technology"
>>> (conformance certification etc.) was complementary to the technical
>>> work documented in the stream of RFCs, and was important to making
>>> TCP "real", and establishing a bit of regulation around its use "in
>>> the field" with mechanisms such as "Flag Day" to enforce a migration
>>> from old to new.
>>>
>>> The Internet is now arguably world class "infrastructure".   But,
>>> IMHO, it still lacks a lot of the mechanisms that surround other,
>>> older, infrastructures that move things from point A to point B -
>>> e.g., highways, electrical service, railroads, airplanes, etc.   The
>>> early work on things like Flag Day, TCP Conformance Tests, DoD
>>> Standardization, and such were the beginning of adding a management
>>> structure around the Internet technology.
>>>
>>> As near as I can tell, no such effort continues today. It may have
>>> faded away back in the 1980s, before TCP became the dominant
>>> technology.   Perhaps the Internet is just too new for such machinery
>>> to be created?
>>>
>>> Other infrastructures have gone through stages as rules, regulations,
>>> and practices congeal.  In the early days of electricity it was
>>> common for accidents to occur, causing fires, deaths, or other
>>> disasters.  Electrical Codes, safety mechanisms, licensing, rules and
>>> practices have made using electricity much less dangerous.  The same
>>> is true of highways, railroads, etc.
>>>
>>> I've always wondered what happened to that "management framework"
>>> that started in the 1980s around the Internet infrastructure, and why
>>> it hasn't resulted in mechanisms today to make the Internet
>>> "safer".   I suspect all infrastructures need things like electrical
>>> codes, UL testing, development of fuses, circuit breakers, GFIs,
>>> etc., that are used in the electrical infrastructure. But nobody
>>> seems to be doing that for the Internet?
>>>
>>> There's lots of such mechanisms I know about in the US to manage
>>> infrastructures.  My car occasionally gets a government-mandated
>>> recall.  Airplanes get grounded by FAA.  Train crashes are
>>> investigated by the Department of Transportation.   Other governments
>>> have similar mechanisms to manage infrastructure.
>>>
>>> Has any Internet component, hardware or software, ever been
>>> recalled...?   "Flag Day" was the last enforcement action I can remember.
>>>
>>> Jack Haverty
>>>
>>>
>>> --------------------
>>>
>>> On 8/9/23 18:50, John Gilmore via Internet-history wrote:
>>>> I had a "tourist" account at the MIT-AI system running ITS, back in the
>>>> NCP days.  I used to log in to it over a TIP that had RS232 cables
>>>> quietly connecting it to a Telenet node.  I'd dial in to a local Telenet
>>>> access point, connect to the cross-connect's node and port, and be
>>>> talking to a TIP, where I'd "@o 134" to get to MIT-AI.
>>>>
>>>> When NCP was turned off on the Flag Day, that stopped working.  At MIT,
>>>> as I understand it, they decided not to implement TCP/IP for ITS.  The
>>>> workaround for tourists like me was to borrow someone's account at
>>>> MIT-OZ, which had TCP support and could also talk to ITS (over
>>>> Chaosnet?).  So I'd connect from the TIP using TCP to MIT-OZ, and then
>>>> connect to MIT-AI.  It worked OK, though I had to remember when (and how
>>>> many times) to double the escape characters.  My access was via a dialup
>>>> modem, which was probably the slowest part of the whole system.
>>>>
>>>> Moving to the present day...
>>>>
>>>> I continue to see Internet old-timers who long nostalgicly for somebody,
>>>> somewhere, to force a "flag day" to shut down IPv4.  The IETF has
>>>> unfortunately been captured by these folks, who object to making even
>>>> tiny improvements to IPv4 protocols on the grounds that "we shouldn't
>>>> make it easier to use IPv4 because that would reduce the urgency of
>>>> switching to IPv6".  It is taken for granted in much of IETF that "IPv4
>>>> is dead, or it should be" even though it carries far more global daily
>>>> traffic, to a far broader range of locations, than IPv6 does.  There was
>>>> even a move to "declare IPv4 Historic" which would officially recommend
>>>> that nobody use it any more.  That draft RFC was approved in 2017 by the
>>>> Sunset4 working group on a vote of three zealots, but it got killed once
>>>> saner heads looked at the implications.  For a discussion of that
>>>> history, and pointers to the source materials, see section 4 of:
>>>>
>>>> https://www.ietf.org/archive/id/draft-schoen-intarea-ietf-maintaining-ipv4-01.txt
>>>>
>>>> (The IETF, predictably, declined to support the publication of an RFC
>>>> describing this history or succinctly stating that IETF would continue
>>>> maintaining IPv4.)
>>>>
>>>> John
>>>>
>>>
>>> -- 
>>> Internet-history mailing list
>>> Internet-history at elists.isoc.org
>>> https://elists.isoc.org/mailman/listinfo/internet-history
>>