[ih] Memories of Flag Day?

[Jack Haverty]

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
>