[ih] Memories of Flag Day?

vinton cerf vgcerf at gmail.com
Fri Aug 11 05:17:21 PDT 2023


On Thu, Aug 10, 2023 at 12:16 PM 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.
>
users should not have to care or notice.

>
> 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
>



More information about the Internet-history mailing list