Subject: Re: US DoD and IPv6

From: [email-masked] (Noel Chiappa)
Date: Fri, 8 Oct 2010 09:36:41 -0400 (EDT)

> From: Keith Moore <[email-masked]>

    > What doesn't work well is to have everyone decide for himself how to
    > change the architecture.

The reason we have/had a free-for-all on the architectural front is that the
IETF's choice for architectural direction (15 years ago) was non-viable (i.e.
wrong); it wasn't economically feasible (in terms of providing economic
benefits to early adopters, or otherwise having an economically viable
deployment plan), and it didn't offer any interesting/desirable new
capabilities (which was a big factor in the former).

With an 'approved direction' that didn't work, having people go off in their
own directions instead was an inevitable corollary.

Which is why I am urging the IETF to be _realistic_ now, and accept the world
as it actually is, and set direction from here on out based on that, and not
on what we wish would happen. Which means, for instance, that any design for
architecural change (e.g. introducing separation of location and identity) is
going to be somewhat ugly, because we don't have a clean sheet of paper to
work with. It also means accepting that we have multiple naming domains at
the end-end level, and will for the forseeable future; and trying to work out
an architectual direction for coping with that ('get rid of it' doesn't
count). Etc, etc, etc.

	Noel

---

From: Steve Crocker <[email-masked]>
Date: Fri, 8 Oct 2010 09:47:20 -0400

Let me say this more strongly.  These two defects, "it wasn't economically feasible ... and it didn't offer any interesting/desirable new capabilities" were mild compared to an even bigger defect: There simply wasn't a technically feasible plan on the table for co-existence and intercommunication of IPv4 and IPv6 networks.

In addition to working our way through the IPv6 adoption and co-existence process, I think it would be useful to do a little soul-searching and ask ourselves if we're so smart, how come we couldn't design a next generation IP protocol and work out a technically viable adoption and co-existence strategy.  The "dual stack" approach implicitly assumed everyone would have both an IPv6 and an IPv4 address.  If everyone has both kinds of addresses, that implicitly asserts there's no visible shortage of IPv4 addresses, which is contrary to fundamental reason IPv6 is needed.  Further, although some scenarios suggest IPv4 usage will start to decline steeply once IPv6 transport, products and services are widely available, the safer bet is that IPv4 networks will persist for a fairly long time, say 20 to 50 years.

Steve

On Oct 8, 2010, at 9:36 AM, Noel Chiappa wrote:

> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Christian Huitema <[email-masked]>
Date: Fri, 8 Oct 2010 14:44:59 +0000

> any design for architecural change (e.g. introducing separation of location and identity) is going to be somewhat
> ugly, because we don't have a clean sheet of paper to work with.

Location independent identifiers can be introduced at the transport or application layer, without having to change the network infrastructure. There is nothing to prevent researchers or application developers to design a "transport" that sits on top of IPv4/IPv6, or even on top of UDP, and manage location independent identifiers. This is the classic "overlay" play, at the end of which IPv6/IPv4 addresses, or address+port pairs, are redefined as mere lcators.

Obviously, this only works for new applications, or new application releases. But if application developers really believe they will benefit from the split, they can do it.

-- Christian Huitema

---

From: John C Klensin <[email-masked]>
Date: Fri, 08 Oct 2010 10:49:53 -0400

--On Friday, October 08, 2010 09:47 -0400 Steve Crocker
<[email-masked]> wrote:

> Let me say this more strongly.  These two defects, "it wasn't
> economically feasible ... and it didn't offer any
> interesting/desirable new capabilities" were mild compared to
> an even bigger defect: There simply wasn't a technically
> feasible plan on the table for co-existence and
> intercommunication of IPv4 and IPv6 networks.
> 
> In addition to working our way through the IPv6 adoption and
> co-existence process, I think it would be useful to do a
> little soul-searching and ask ourselves if we're so smart, how
> come we couldn't design a next generation IP protocol and work
> out a technically viable adoption and co-existence strategy.
> The "dual stack" approach implicitly assumed everyone would
> have both an IPv6 and an IPv4 address.  If everyone has both
> kinds of addresses, that implicitly asserts there's no visible
> shortage of IPv4 addresses, which is contrary to fundamental
> reason IPv6 is needed.  Further, although some scenarios
> suggest IPv4 usage will start to decline steeply once IPv6
> transport, products and services are widely available, the
> safer bet is that IPv4 networks will persist for a fairly long
> time, say 20 to 50 years.

Steve,

While I agree with what you say (and most of what Noel says),
hindsight is pretty easy.   I even agree with your 20 to 50 year
estimate although an optimist might draw some comfort from how
quickly CLNP and CONP, TP0 and TP4 (and the rest of the OSI
machinery), Vines and Netware, etc., disappeared once the
network effects set in and the writing appeared on the wall.

However, certainly Noel's position was part of the discussion
15-odd years ago.   Certainly the positions that IPng must
either be strictly forward compatible or that it should
introduce enough new and valuable functionality to make people
want to incur the pain were part of the discussion.
Nonetheless, the IETF community selected what is now IPv6.  What
does this say about the IETF and how we make decisions?  Does
that need adjusting?

Finally, and perhaps more important right now, while it is easy
to observe that the 1995 (or 2000) predictions for IPv6
deployment rates have not come close to being satisfied and
recriminations based on hindsight may be satisfying in some
ways, the question is what to do going forward.   There are
communities out there who believe that we have managed to
"prove" that datagram networks, with packet-level routing, are a
failure at scale and that we should be going back to an
essentially connection-oriented design at the network level.
If they were to be right, then it may be that we are having
entirely the wrong discussion and maybe that we are on the wrong
road (sic) entirely.  If not, then there are other focused
discussions that would be helpful.  The latter discussions that
have almost started in this and related threads, but have (I
believe) gotten drowned out by the noise, personal accusations
about fault, and general finger-pointing.

How would you propose moving forward?

    john

---

From: Ole Jacobsen <[email-masked]>
Date: Fri, 8 Oct 2010 07:57:58 -0700 (PDT)

And our friends at the ITU are standing by ready to help us too :-)

Ole

Ole J. Jacobsen
Editor and Publisher,  The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972   Mobile: +1 415-370-4628
E-mail: [email-masked]  URL: http://www.cisco.com/ipj

---

From: Keith Moore <[email-masked]>
Date: Fri, 8 Oct 2010 12:10:56 -0400

> capabilities (which was a big factor in the former).

In hindsight, I suspect IETF could have made a better choice for IPv6.   Or even accepting the basic IPv6 approach that we ended up with, slight changes to some of the details might have made a big difference.  And it's worthwhile to try to learn lessons from that choice and the consequences.   However, I don't see how it's constructive to say that the choice was "wrong".   There is today an increasingly widespread realization that "the worldwide deployment of IPv6" is a better path forward than any of the likely alternatives.  That doesn't mean it's the best possible path forward, of course.  But as we're both painfully aware, having a better idea isn't sufficient.  A necessary condition for success is to get widespread buyin to the idea.  For better or worse, IPv6 is still the only semi-viable long-term strategy that has anything like widespread buyin.

> own directions instead was an inevitable corollary.

Except that neither middleboxes in general nor NATs in particular were a direct result of the decision to adopt IPv6.  NATs were not originally driven by a shortage of IPv4 addresses.  In the consumer market they were driven by what came to be a de facto standard of one IP address per customer, due partially to this assumption being widespread within IETF itself.  In the enterprise network space they were initially driven by a misguided notion that having private addresses would produce better network security.  In both cases the adoption of NATs was largely a consequence of IETF's failure to produce and adhere to a comprehensive plug-and-ping autoconfiguration architecture.  

The problem was that the 'approved direction' was wrong, it was that in many important spaces for both IPv4 and IPv6, there was no approved direction - only a hodgepodge of half-baked hacks that didn't fit together well.  

> on what we wish would happen.

Sigh.  Anytime someone makes an appeal to accept "reality" I wish a (small) brick would fall on his head.  That's exactly the same kind of argument that was made in the late 1990s within IESG as to why IETF could not do anything to make NATs predictable to applications.  

But for what it's worth, I do share your assumption that we don't have the luxury of working from a clean sheet design.  And I agree that at least in the near term it's going to be ugly.  But I think the goal should be to facilitate a transition to a world that's less ugly, or at least more functional.

Keith

---

From: Dave Cridland <[email-masked]>
Date: Fri, 08 Oct 2010 17:31:28 +0100

On Fri Oct  8 17:10:56 2010, Keith Moore wrote:
> Except that neither middleboxes in general nor NATs in particular  
> were a direct result of the decision to adopt IPv6.  NATs were not  
> originally driven by a shortage of IPv4 addresses.  In the consumer  
> market they were driven by what came to be a de facto standard of  
> one IP address per customer, due partially to this assumption being  
> widespread within IETF itself.  In the enterprise network space  
> they were initially driven by a misguided notion that having  
> private addresses would produce better network security.  In both  
> cases the adoption of NATs was largely a consequence of IETF's  
> failure to produce and adhere to a comprehensive plug-and-ping  
> autoconfiguration architecture.

Oh, I think there's rather more than that.

Initially, NATs came about because enthusiasts found that it was  
prohibitively expensive to get a routed block down a modem - the ISPs  
treated you like a business customer, and charged accordingly.  
There's nothing the IETF could, or even should, have done to avoid  
this, and FWIW, the ISPs got terribly upset with you for using NATs  
at the time, and given the very few implementations (Linux IP Masq,  
for instance), some were able to detect and filter.

As NATs moved from Linux IP Masq into the mainstream, though, ISPs  
simply took advantage of this - it meant that there was no  
configration distinction between a single user and a network - and  
that's a useful property. In hindsight, this would have been a good  
time for the IETF to step in and try to address the actual problem,  
but unfortunately consumer networking has never been a strong point  
of the IETF - I think largely because few of the stakeholders are  
average internet users for obvious reasons.

As NATs drifted into the enterprise, there was a security angle, but  
there was also a renumbering angle that still hasn't gone away. This  
is, in no small part, because the only way to refer to an arbitary  
network is via the addressing - actual hosts are largely dealt with  
by a combination of DHCP and DNS. (As a random thought, if there was  
a CIDR DNS RR, I wonder if this may help?) There is occasional  
rumblings within the IETF to address this, but given NATs have to  
some extent removed the bulk of the pain, I'm not sure there's  
sufficient motivation to solve all the issues.

So currently, a NAT provides:

- A degree of de-facto firewalling for everyone.
- An immunity to renumbering for enterprises.
- Fully automated network routing for ISPs.

If technologies could be introduced to tackle especially the last  
two, I think the advantages of NATs would vanish.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Keith Moore <[email-masked]>
Date: Fri, 8 Oct 2010 12:49:28 -0400

> Oh, I think there's rather more than that.

Of course there is, but I was trying to be brief.

> Initially, NATs came about because enthusiasts found that it was prohibitively expensive to get a routed block down a modem - the ISPs treated you like a business customer, and charged accordingly.

But part of that was because single-address-per-customer (or dialin session) was naturally a commodity service, while routing a block down a modem was something that required special-case handling at the ISP.   And I think it's fair to say that that was the assumption in IETF also.  I don't recall any efforts toward autoconfiguration of networks then, particularly not for those connected via point-to-point links.  It's hard to not blame the ISPs for wanting to charge differently for one-address dialin vs. other accounts that required more customization, setup, and support on their part.

> As NATs drifted into the enterprise, there was a security angle, but there was also a renumbering angle that still hasn't gone away. This is, in no small part, because the only way to refer to an arbitary network is via the addressing - actual hosts are largely dealt with by a combination of DHCP and DNS. (As a random thought, if there was a CIDR DNS RR, I wonder if this may help?)

Not sure what you mean by a CIDR DNS RR, but I hope it's nothing like A6 / DPTR was.

> There is occasional rumblings within the IETF to address this, but given NATs have to some extent removed the bulk of the pain, I'm not sure there's sufficient motivation to solve all the issues.

And there's always considerable pressure on and within IETF to "just embrace NAT" for this.

> If technologies could be introduced to tackle especially the last two, I think the advantages of NATs would vanish.

But the "NATs are good" mentality would still be widespread.    Old timers hate to learn how to use new tools, even if the old tools are crap. 

Keith

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 09 Oct 2010 02:51:23 +0900

> on what we wish would happen.

The only realistic approach is to accept IPv4 at least for next
10 or 20 years, which is possible with port restricted IP while
keeping the end to end transparency.

> Which means, for instance, that any design for
> work with.

ID locator separation is not essential. All we need is an architecture
to handle multiple addresses (which may be raw addresses or an ID and
multiple locators).

> It also means accepting that we have multiple naming domains at
> the end-end level,

It means to handle multiple IP addresses.

> and will for the forseeable future;

It means to handle multiple IPv4 addresses.

> and trying to work out

The basic architectural problem so many people want to ignore
is that IP is connectionless, which means there is no time out
at the IP layer to know some address is not working.

As a result, there are a lot of wrong proposals seen in multi6
WG, which declare TCP connections are dead merely because
no traffic is observed for a while, which is no different from
poor legacy NAT violating the end to end principle.

Interestingly enough, IPv6 failed partly because its neighbor
discovery has introduced a lot of time out at the IP layer,
which is architecturally wrong (in this case, timing depends
on link layers). Requirements on RtrAdvInterval was finally
loosened in RFC3775 (MIPv6) but rest remains.

Once it is recognized that the problem of multiple addresses can
be solve only at (in case of TCP) or above (in case of UDP) the
transport layer, the solution is easy and straight forward.

Details are documented in draft-ohta-e2e-multihoming-00.txt
in Apr. 2000.

Though my experimental implementation is in IPv6 with ID/locator
separation, same is doable with (port restricted) IPv4.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 09 Oct 2010 03:02:43 +0900

Dave Cridland wrote:

> If technologies could be introduced to tackle especially the last two, I 
> think the advantages of NATs would vanish.

It is not necessary to make NAT vanish.

Let people satisfied with legacy NAT keep using it.

The point is to keep offering the end to end transparency of IPv4
Internet to people who want it even if IPv4 address is mostly
consumed.

						Masataka Ohta

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 8 Oct 2010 15:31:46 -0400

> essentially connection-oriented design at the network level.

I think that many, perhaps most, of the people who believe that would believe it regardless of the
facts on the ground.

Regards
Marshall

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 8 Oct 2010 11:14:02 -0400

[Replying to John, Steve, others]

This might sound like a completely off the wall suggestion. But is it
possible that we could use an IPv4 extension header to carry the internal
address of a NAT-ed host in some way and thus preserve end-to-end
addressability?

Assume for the sake of argument that we have a secure DNS deployed and that
this scheme makes it efficient to publish policy records for protocols. [I
have a detailed justification for why this is possible]. Such that when a
client attempts to connect to the http protocol for www.example.com it is
going to receive back a DNS record chain from its resolver that includes:

www.example.com
                     A            18.1.1.1
                     AA          18.1.1.1.10.1.0.0
_http._tcp    ESRV    "IP=a+aa+aaaa"

If the application is going to use the AA record it has to have an IPv4.1
stack. This causes it to emit IPv4 packets where the first four bytes are
sent in the IPv4 header and the remaining four bytes are sent as a header
option.

The NAT box at 18.1.1.1 now has all the information it requires to allow
complete transparency in either direction.

Clients can connect to a server behind a NAT box provided only that they
have a current IP stack.

I can even provide a pretty good solution to Brian's mobility/referral
problem. Say that there are 256 points of presence, each of which has a
distinct IPv4 address. All we need to do is to tell the mobile device when
to change its Internet point of presence address. The target need not know
that the gateway has been changed.

Of course one objection that would be made against this is likely to be that
it solves the problem a bit too well and eliminates the need for IPv6
entirely. The other objection is going to be that we are now so far into the
deployment of IPv6 that 'it is too late to change'.

---

From: Dave Cridland <[email-masked]>
Date: Fri, 08 Oct 2010 23:49:08 +0100

On Fri Oct  8 17:49:28 2010, Keith Moore wrote:
> >> Except that neither middleboxes in general nor NATs in  
> particular were a direct result of the decision to adopt IPv6.   
> NATs were not originally driven by a shortage of IPv4 addresses.   
> In the consumer market they were driven by what came to be a de  
> facto standard of one IP address per customer, due partially to  
> this assumption being widespread within IETF itself.  In the  
> enterprise network space they were initially driven by a misguided  
> notion that having private addresses would produce better network  
> security.  In both cases the adoption of NATs was largely a  
> consequence of IETF's failure to produce and adhere to a  
> comprehensive plug-and-ping autoconfiguration architecture.
> >
Oh, sure, but I think the points you glossed over in that effort were  
more significant that the points you retained.

> prohibitively expensive to get a routed block down a modem - the  
> ISPs treated you like a business customer, and charged accordingly.
> 
> But part of that was because single-address-per-customer (or dialin  
> session) was naturally a commodity service, while routing a block  
> down a modem was something that required special-case handling at  
> the ISP.   And I think it's fair to say that that was the  
> assumption in IETF also.  I don't recall any efforts toward  
> autoconfiguration of networks then, particularly not for those  
> connected via point-to-point links.  It's hard to not blame the  
> ISPs for wanting to charge differently for one-address dialin vs.  
> other accounts that required more customization, setup, and support  
> on their part.
> 
> 
Absolutely, and I basically stated that later - that's why the ISPs  
changed from actively trying to supress such usage into actively  
supporting it, because it meant that network setups became, from  
their viewpoints, "free".

> > As NATs drifted into the enterprise, there was a security angle,  
> but there was also a renumbering angle that still hasn't gone away.  
> This is, in no small part, because the only way to refer to an  
> arbitary network is via the addressing - actual hosts are largely  
> dealt with by a combination of DHCP and DNS. (As a random thought,  
> if there was a CIDR DNS RR, I wonder if this may help?)
> 
In IPv4 terms a DNS RR that meant I could lookup what  
dave.cridland.net's network was, and get back 217.155.137.156/29, and  
therefore use the network name instead of the IP addresses in  
configuration, such as firewalling rules, DHCP server config, etc.

I vaguely recall the A6/DPTR combination as being rather more  
ambitious than that, but really, a search/replace on a zonefile  
during a renumber is pretty easy. It's the hunting down the network  
references in router configs and firewall rules that's the pain.

> > There is occasional rumblings within the IETF to address this,  
> but given NATs have to some extent removed the bulk of the pain,  
> I'm not sure there's sufficient motivation to solve all the issues.
> 
Right - it's a vicious circle, too, because we must embrace NAT  
because no other solution exists, but there's no point developing a  
better solution because NAT exists. Unfortunately, renumbering still  
happens even when you're using 10/8, so NAT doesn't answer all the  
cases.

> But the "NATs are good" mentality would still be widespread.    Old  
> timers hate to learn how to use new tools, even if the old tools  
> are crap.

Right, and we need to work around that damage with stuff like BEHAVE,  
and careful application design.

Still, to my mind, I have the feeling that end-to-end addressing  
could actually be a security and reliability benefit to many  
peer-to-peer applications (VOIP and IM file transfer being just two  
that spring to mind), so there could be interest in getting there  
from here.

Moreover, if we tackle the renumbering and automated routing case  
(and I think the latter is largely done - not my area though) then  
we've provided the tools for home and enterprise alike to ween  
themselves off NAT quite effectively.

Dave.

---

From: Dave Cridland <[email-masked]>
Date: Fri, 08 Oct 2010 23:51:54 +0100

> sent in the IPv4 header and the remaining four bytes are sent as a  

Can't one then use a DNS lookup which tells it a tunnel endpoint for  
an IPv6-in-IPv4 tunnel, and provide transparent IPv6 at both ends?  
This could be implemented entirely at the network edge, eliminating  
the need for special stacks at the endpoints.

Dave.

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Sun, 10 Oct 2010 13:51:53 +0100

On 8 Oct 2010, at 23:51, Dave Cridland wrote:
> Can't one then use a DNS lookup which tells it a tunnel endpoint for an IPv6-in-IPv4 tunnel, and provide transparent IPv6 at both ends? This could be implemented entirely at the network edge, eliminating the need for special stacks at the endpoints.

I think this should be possible, today, with 6to4 and NAT64/46 in combination without any changes for the IPv4 host at all.  6to4 has the nice property that it is instantly compatible with every other 6to4 user, without any kind intermediate choke points (assuming that the non-tunneled IPv4 Internet remains reasonably flat and NAT-free, of course).  Sooner or later you're going to need IPv6 on the wire, though, because your IPv4-only hosts aren't capable of encoding more bits into their packets than they know how (address and port).  Besides that, quite a few apps do not fair well with NAT64, but I suppose if we're dead-set on keeping it alive, then we had better get to work fixing those.  Should work for any DNS-addressible resource running over straight TCP/UDP without any payload modifications.  We just need some spare addresses to implement our NAT state table, no DNSSec and minimal caching, and a strong stomach.

Just FTR, I'm not advocating this direction.  I really think we're worrying about the wrong problem - it isn't really the end nodes where the IPv6 is lacking, it's the blasted middleboxes.  Having said that, I just got an Epson Photo Stylus PX710W which is IPv4 only, unfortunately.

Cheers,
Sabahattin

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 10 Oct 2010 22:42:31 +0900

Sabahattin Gucukoglu wrote:

>>> If the application is going to use the AA record it has to have
>>> an IPv4.1 stack. This causes it to emit IPv4 packets where the
>>> first four bytes are sent in the IPv4 header and the remaining
>>> four bytes are sent as a header option.

> I think this should be possible, today, with 6to4 and NAT64/46 in
> combination without any changes for the IPv4 host at all.

That's overkill.

Port restricted IP with the current TCP and UDP already achieved
"remaining *TWO* bytes are sent as a *PAYLOAD*".

Moreover, URLs can specify port numbers, which is why new DNS
records are not necessary.

> 6to4 has
> the nice property that it is instantly compatible with every other
> 6to4 user, without any kind intermediate choke points

There is no room for 6.

> (assuming that
> the non-tunneled IPv4 Internet remains reasonably flat and NAT-free,
> of course).

which means you *MUST* deploy port restricted IPv4, which means
there is no room for 6.

> Sooner or later you're going to need IPv6 on the wire, though,
> because your IPv4-only hosts aren't capable of encoding more bits
> into their packets than they know how (address and port).

Sooner, port restricted IP with 2B port gives a lot more than enough
application address space.

Later, as a natural extension, we will use IPv4 with more than 2B
for port (I call it TUPLE (TCP and UDP with Port Length Enhancement)),
which means there is no room for 6.

> Besides
> that, quite a few apps do not fair well with NAT64,

That's partly why there is no room for 6.

							Masataka Ohta

---

From: Steve Crocker <[email-masked]>
Date: Sun, 10 Oct 2010 17:51:15 -0400

John,

See below for an attempt at a more nuanced position.

Steve

> network effects set in and the writing appeared on the wall.

Predicting timing is the very hardest part of introduction of new technology.  Sometimes it goes fast; sometimes not.  I'd be surprised if IPv4 disappears in substantially less than 20 years.  50 years does seem kind of long, but I think that's the right horizon to consider.  If it disappears more quickly, that's fine.

To put a slight bit more structure on this, I think there are five epochs:

1. Pure IPv4

2. IPv4 is dominant; IPv6 is showing up in pockets

3. Strong operation of both IPv4 and IPv6

4. IPv6 is dominant but IPv4 is still heavily used

5. IPv6 dominates and IPv4 has essentially disappeared.  (More or less symmetric with pure IPv4, but there's likely to be some isolated pockets or enclaves.)

We're in the early stages of the second epoch, in my view.

> want to incur the pain were part of the discussion.

I don't think these are the only two choices, though I agree that either of these would have been more attractive than the position we're in.

In lieu of compatibility, we needed a viable co-existence and transition plan.  I don't think the dual stack approach was ever viable, no matter how optimistic one might have been about the adoption of IPv6.  As I understand it, the idea behind dual stack is that all new end systems, all wide area and enterprise networks, and all services would become IPv6 capable, and all new systems would operate smoothly in both IPv6 and IPv4 mode.  Then, when it was evident that everyone who had an IPv4 address also has an IPv6 address, new systems could appear that were IPv6 only.  And all of this would happen before IPv4 addresses ran out.

I think it would have been -- and still is -- sensible to dissect the picture in terms of the different types of players -- end users, enterprise operators, ISPs, content providers and perhaps others.  Further, imagine that each type of players have a mixture of early, medium and late adopters.  Or, perhaps more usefully stated, at any given point in time, some are IPv4-only, some are IPv6-only and some are operating in both IPv6 and IPv4 mode.  Is there a sequence of transitions that allows each type of player to move through its own transitions and still interoperate with everyone else?

Without going into extensive discussion of the details, it seems to me inescapable that we would need application level gateways, and that there will be some breakage because some of the protocols have IP addresses embedded as data.

The good news, from my point of view, is that the requisite steps are now being taken to design and build the components that will permit IPv4 and IPv6 systems to co-exist and interoperate.

> does this say about the IETF and how we make decisions?  Does

A compatible solution would have been better, but I don't think IPv4 -- and its predecessors! -- were designed in a way that permitted a compatible extension.  I think we missed the boat in not designing the transition and co-existence scenarios, and I think that ought to cause us to examine our internal standards for knowing when we have a viable design.

Cheers,

Steve

---

From: Steve Crocker <[email-masked]>
Date: Sun, 10 Oct 2010 18:44:49 -0400

Mebbe.  I confess I didn't study the details of the competing proposals at the time because I was confident the people who were heavily involved surely had things under control.

Steve

On Oct 10, 2010, at 6:41 PM, Dave CROCKER wrote:

> 
> 
> On 10/10/2010 2:51 PM, Steve Crocker wrote:
>> A compatible solution would have been better, but I don't think IPv4... --
>> were designed in a way that permitted a compatible extension.
> 
> 
> Oh?
> 
> Perhaps:
> 
>   1.  Adopt an IPv6 as Steve Deering originally designed it[1]:  A basic upgrade to the IPv4 header, with more address bits, an extensibility mechanisms for adding fields later, and removal of some bits that weren't needed.
> 
>   2.  Define the IPv6 address space as the IPv4 address space, with all zeroes for the higher bits.  (In other words, defer more interesting schemes until later.)
> 
>   3.  Design header translation devices to map between the two formats.
> 
>   4.  Start fielding these implementations.  (That could have started by 1994 or so.)
> 
> The "gateways" between v4 and v6 would initially be notably for having almost no work to do and of not losing any information.  In particular, barely qualifies as a "dual" stack.
> 
> With this approach, "incompatibility" between v4 and v6 would only occur when additional addresses, beyond v4's limitations, start to be assigned.
> 
> We must deal with the current reality and make it work, but historical considerations need to factor in the ambitions that dominated during the many years of design.
> 
> The community got ambitious in a fashion that smacked of the overreaching that is often called second system syndrome (although counting the Arpanet, this was really a third system...)
> 
> d/
> 
> [1]  http://tools.ietf.org/html/draft-deering-sip-00
> -- 
> 
>  Dave Crocker
>  Brandenburg InternetWorking
>  bbiw.net

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 10 Oct 2010 16:02:10 -0700

Oh?

Perhaps:

    1.  Adopt an IPv6 as Steve Deering originally designed it[1]:  A basic 
upgrade to the IPv4 header, with more address bits, an extensibility mechanisms 
for adding fields later, and removal of some bits that weren't needed.

    2.  Define the IPv6 address space as the IPv4 address space, with all zeroes 
for the higher bits.  (In other words, defer more interesting schemes until later.)

    4.  Start fielding these implementations.  (That could have started by 1994 
or so.)

The "gateways" between v4 and v6 would initially be notably for having almost no 
work to do and of not losing any information.  In particular, barely qualifies 
as a "dual" stack.

With this approach, "incompatibility" between v4 and v6 would only occur when 
additional addresses, beyond v4's limitations, start to be assigned.

We must deal with the current reality and make it work, but historical 
considerations need to factor in the ambitions that dominated during the many 
years of design.

The community got ambitious in a fashion that smacked of the overreaching that 
is often called second system syndrome (although counting the Arpanet, this was 
really a third system...)

d/

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 10 Oct 2010 16:02:31 -0700

On 10/10/2010 3:44 PM, Steve Crocker wrote:
> Mebbe.  I confess I didn't study the details of the competing proposals at
> the time because I was confident the people who were heavily involved surely
> had things under control.

Alas...

Along with the imposition of ASN.1's complexities as the MIB format, for 
"compatibility" between the competing network management protocols (SNMP and 
CMOT), IPv6 was an early demonstration of the problems that accrue from treating 
technical design as a political process, trying to accommodate too many factions.

Such accommodations seem to rarely provide the long-term benefit that is 
intended, but instead consistently add complexity and limitations.

Politicized technical processes rarely allow good folk to adequately "have 
things in control".  (I'm sure that your experiences on the ICANN Board and its 
SSAC have not disclosed this unexpected fact of life to you yet, so I thought it 
worth pointing out.)

d/
-- 

   Dave Crocker

---

From: Joel Jaeggli <[email-masked]>
Date: Sun, 10 Oct 2010 16:21:02 -0700

On 10/10/10 4:02 PM, Dave CROCKER wrote:
> "compatibility" between the competing network management protocols (SNMP
> and CMOT), IPv6 was an early demonstration of the problems that accrue
> from treating technical design as a political process, trying to
> accommodate too many factions.
> 
> Politicized technical processes rarely allow good folk to adequately
> "have things in control".  

The difference with ipv4 address length being mainly that at the end of
the day the darpa program manager could say, "stop your bickering we're
doing it this way."

I'm reminded of Churchill,  "Democracy is the worst form of government,
except for all those other forms that have been tried from time to
time." while that's not our process, I think it's a bit presumptuous to
suppose that some other organizational construct might produce a
different, and presumed better result.

By the time this thread is done perhaps the axes will have been ground
down to nubs.

> (I'm sure that your experiences on the ICANN
> Board and its SSAC have not disclosed this unexpected fact of life to
> you yet, so I thought it worth pointing out.)
> 
> d/

---

From: Marshall Eubanks <[email-masked]>
Date: Sun, 10 Oct 2010 19:45:51 -0400

> The community got ambitious in a fashion that smacked of the overreaching that is often called second system syndrome (although counting the Arpanet, this was really a third system...)

Dear Dave;

Not being directly involved at the time, I have always wondered this :

Was it second system syndrome, or was a slowness to realize that the time to drastically change the system increased from 
months to (effective) infinity somewhere between 1988 and 1994 ?

Regards
Marshall

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 10 Oct 2010 16:50:39 -0700

> months to (effective) infinity somewhere between 1988 and 1994 ?

In fact, it was /too much/ realization of likely deployment time.

That is, there was an ingrained belief that this one be the last time that 
things "under the hood" would get to be revised for many years.  Hence the 
belief that it was important to stuff in as many changes as possible...

d/
-- 

   Dave Crocker

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 11 Oct 2010 19:29:19 +0900

Dave CROCKER wrote:

> upgrade to the IPv4 header, with more address bits, an extensibility 
> mechanisms for adding fields later, and removal of some bits that 
> weren't needed.

That is an option because, with port restricted IP, we have enough
time for the transition.

That is, there is no reason to insist on deploying IPv6 with 16B
addresses when SIP with 8B address will do.

However, original SIP is unnecessarily combined with Steve's
other proposals and is still too complex.

For example, considering that his favorite PMTUD does not really
work elegantly to detect increase of PMTU, minimum MTU should be
increased without PMTUD or reserved header field should be used
to record the current PMTU to be modified at each hop.

His favorite multicast should be purely optional because broadcast
is a lot simpler.

Flow ID for his favorite RSVP is unnecessary, because QoS capable
L2s have its own label.

There may be other simplifications possible.

						Masataka Ohta

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 10 Oct 2010 15:41:44 -0700

Oh?

Perhaps:

d/

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 10 Oct 2010 15:53:56 -0700

Alas...

d/
-- 

   Dave Crocker

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 11 Oct 2010 11:25:23 -0400

Without getting into the question of whether your suggestion would have 
helped anything in terms of transition and interoperability,  it shares 
one major flaw with the path we did adopt.

There is no incentive to spend resources to get there.
No matter how elegant it is technically, without a benefit for 
deployment there is no way to get past very small scale deployment 
(some folks will deploy anything to see if it has value, but most won't.)
That is one of the main stumbling blocks that Noel reported publicly for 
getting Nimrod off the ground separately from the IPv6 effort.  The 
operators who had to deploy it did not gain anything.

As long as our path is one of minimal change, we were inherently locked 
in to a behavioral set that matched Ipv4.  that is what SIP proposed. 
That is what IPv6 gave us.

For any proposal to work, there has to be a benefit to folks to use it. 
  Even before it is ubiquitous.  As far as I can tell, we ignored that 
question during the 1993-1999 period when we should have been working on it.

We also get ourselves into a mind set of "we need an answer now.  There 
is no time to do technically hard work."  That was a bad call.  5 extra 
years spend=t serously working on what the needs were, what the 
deployments could be, and what the technology could look like, might 
have given us a better path.  (No, there is no guarantee.  We could have 
blown it anyway.)

Yours,
Joel M. Halpern

On 10/10/2010 6:41 PM, Dave CROCKER wrote:
> 2. Define the IPv6 address space as the IPv4 address space, with all
> zeroes for the higher bits. (In other words, defer more interesting
> schemes until later.)
>
> The "gateways" between v4 and v6 would initially be notably for having
> almost no work to do and of not losing any information. In particular,
> barely qualifies as a "dual" stack.
>
> With this approach, "incompatibility" between v4 and v6 would only occur
> when additional addresses, beyond v4's limitations, start to be assigned.
>
> considerations need to factor in the ambitions that dominated during the
> many years of design.
>
> The community got ambitious in a fashion that smacked of the
> overreaching that is often called second system syndrome (although
> counting the Arpanet, this was really a third system...)
>
> d/
>

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 11 Oct 2010 09:35:20 -0700

On 10/11/2010 8:25 AM, Joel M. Halpern wrote:
> Without getting into the question of whether your suggestion would have helped
> anything in terms of transition and interoperability, it shares one major flaw
> with the path we did adopt.
>

Indeed, it has been remarkable how poor the sales pitch has been to 
resource-poor operations that are expected to adopt this, even after all this time.

The only counter I will make -- and it is not an attempt to contradict your 
point -- is that the adoption barrier for the scheme I described is minuscule, 
when compared with the full, incompatible, dual-stack scheme that we've pursued.

Most of the software could be shared between v4 and the simplified v6 I 
described, and initially most of the operations procedures could be shared.  And 
router products could have been enhanced to include the translation pretty easily.

Again, none of this contradicts the lack of an attractive value proposition for 
adopters.  But it could have made incremental adoption much cheaper and simpler 
and could have started it much sooner.

> As long as our path is one of minimal change, we were inherently locked in to a
> behavioral set that matched Ipv4. that is what SIP proposed. That is what IPv6
> gave us.

The current IPv6 is not minimal change.  It is an entirely incompatible dual 
stack model.  That really is fundamentally different from what I described, 
which was actually a clean upgrade to the existing system and would have 
remained entirely compatible with it, semantically, when initially deployed.

> For any proposal to work, there has to be a benefit to folks to use it. Even
> before it is ubiquitous. As far as I can tell, we ignored that question during
> the 1993-1999 period when we should have been working on it.

Yup.  The motivating requirement was address space, but address space is not 
functional enhancement, in terms of marketing to adopters.  Fixing address 
space, for most folk, would have been an overhead expense.

> We also get ourselves into a mind set of "we need an answer now. There is no
> time to do technically hard work." That was a bad call. 5 extra years spend=t
> serously working on what the needs were, what the deployments could be, and what
> the technology could look like, might have given us a better path. (No, there is
> no guarantee. We could have blown it anyway.)

Probably not.  If we were going to be blown away, there turned out to be plenty 
of time for that to have developed.

One could argue that those likely to pursue that path of innovation were 
discouraged from it, but I think it more likely that the spiffy, mind-blowing 
enhancement is still eluding folk.  So we are left with the ideal alternative of 
an unrealized, unspecified, superior choice, versus the concrete, flawed path we 
went down.  The former always looks better, since it is not constrained by the 
real world.

FWIW, when work seriously began, in the early/mid 90s, we were already turning 
down legitimate requests, such as from the electricity folks (EPRI).  Instead we 
chose to focus on global exhaustion rather than individual denial.

That was the real mistake.  There really was urgency back then and we convinced 
ourselves there wasn't.

d/
-- 

   Dave Crocker

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 11 Oct 2010 15:09:06 -0400

On Mon, Oct 11, 2010 at 12:35 PM, Dave CROCKER <[email-masked]> wrote:

>> helped

[other good stuff I mostly agree with deleted]

The problem is not merely marketing in the sense of messaging. The problem
with each one of the stalled IETF infrastructure upgrades is deployment
deadlock.

Specifically there is a cycle of ungranted requests. Alice has no incentive
to upgrade her infrastructure because she cannot use any new feature until
Bob upgrades. Meanwhile Bob has no incentive to upgrade ahead of Alice.

Mere exhortations from the great and the good have very limited effect.

Specifically, with the IPv6 upgrade we need to catalog each of the
stakeholders that have to upgrade their gear and work out a unilateral
deployment incentive for each one in turn.

Whenever I try to propose this sort of thing to conferences the referees
always kick the papers back saying that it is 'obvious'. Well if it is so
damn obvious, how come we don't seem to be able to manage to do it?

I think it is a fairly obvious consequence of a rational choice model.
Assume that each actor is not going to budge unless there is a short term
benefit to themselves for changing behavior. Now I agree that there are
major differences between the way the world really works and the axioms of
rat choice modeling. But they certainly work as models in cases where there
is a strong positive feedback loop (network effect).

What I want as a consumer is a box that enables me to do things like peer to
peer video chat efficiently and without all my traffic going in and out of
some peer to peer network whose real function is no more than NAT bypass.

Trying to tie functionality to the flavor of network I am on is a losing
proposition for me. I only have one broadband provider in my area at the
moment and they know it.

-- 
Website: http://hallambaker.com/

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 12 Oct 2010 12:13:54 -0700

Perhaps beating a horse that has long left the gate, since I'm responding to a
note earlier than the one I already responded to...  But this issue really needs
to be settled carefully, IMO, and the modern renditions about this period of 
time are typically off the mark:

On 10/8/2010 6:47 AM, Steve Crocker wrote:
> There simply wasn't a technically feasible plan on the table for co-existence
> and intercommunication of IPv4 and IPv6 networks.
>
> In addition to working our way through the IPv6 adoption and co-existence
> process, I think it would be useful to do a little soul-searching and ask
> ourselves if we're so smart, how come we couldn't design a next generation IP
> protocol and work out a technically viable adoption and co-existence
> strategy.

Bob Hinden and I chaired a working group that was answering your question BEFORE
IPv6 was adopted and while there were a number of very different proposals.

The community chose to drop the work and ignore the issue for 10 or 15 years. 
It happens that Deering's proposal came out of participation in our working 
group, muttering something like "all this transition stuff is fine, but when 
it's done, what we'll be left with will be ugly."  So he designed his elegant IP 
enhancement.

One bit of work that came out of the group was IPAE.  More generally, it's
interesting to review documents of the competing proposals and note quite a few
references to transition:

    <http://www.sobco.com/ipng/internet-drafts/index.html>

My point, here, is that the failures here were ones of goals, priorities and
management, not technology.  Quite simply, we did not pay attention to larger
issues such as market incentives and adoption barriers.

d/
-- 

   Dave Crocker

---

From: Keith Moore <[email-masked]>
Date: Tue, 12 Oct 2010 17:22:45 -0400

On Oct 12, 2010, at 3:13 PM, Dave CROCKER wrote:
> The community chose to drop the work and ignore the issue for 10 or 15 years. It happens that Deering's proposal came out of participation in our working group, muttering something like "all this transition stuff is fine, but when it's done, what we'll be left with will be ugly."  So he designed his elegant IP enhancement.
> 

Or people cared more about making the end result "right" (for some meaning of "right") than about how to get there.  (which is pretty close to the definition of second system effect.)

There are a lot of things I didn't/don't like about HTTP, but I had to admit that early versions (especially 0.9 and 1.0) were optimized for deployability.  Say what you will about its quality, efficiency, robustness, etc., but it's certainly been successful from an evolutionary perspective.  HTTP 1.1 tried to fix a lot of the omissions in 1.0, and was partially successful, but it would never have succeeded as an initial version.

I also remember that the current Internet email system evolved from a hodgepodge of dissimilar systems, first by most of those systems adopting (more-or-less) a common message format (at least for external traffic), then by MX records providing a way to tie all of those dissimilar systems into a common addressing framework, then (finally) by widespread adoption of IP and SMTP.   At each step there were incentives to local adoption.  RFC 822 headers gave systems a more flexible way to represent message metadata (especially with things like Reply-To), MX records solved the problem of how to route traffic between the Internet and mail domains not connected via IP, and moving to SMTP provided faster and more-reliable service.

I've often wondered whether we could have used something like IPAE as a stepping-stone to something like SIPP (which evolved into IPv6).  Especially since, in hindsight, it turned out to be much easier to get the host support for IPv6, and even support for IPv6 in major applications, than to get the networks upgraded.   

Keith

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 13 Oct 2010 06:33:34 +0900

> Mere exhortations from the great and the good have very limited effect.

It's interesting to note that, with monopoly by telco, deployment
of ITU standards was almost automatic.

However, on the Internet with full competitive backbone and the end
to end principle, upgrading has been occurring from the end.

For example, ftp servers and clients are upgraded to web servers
and clients at the ends without any changes to the backbone.

Subnetting was an issue within end sites.

NAT is another example.

> some peer to peer network whose real function is no more than NAT bypass.

Upgrading NAT boxes in consumer houses and edge ISPs by end to end
NAT gives you the environment you want.

						Masataka Ohta

---

From: "Fleischman, Eric" <[email-masked]>
Date: Tue, 12 Oct 2010 08:24:55 -0700

> On Mon, Oct 11, 2010 at 12:35 PM, Dave CROCKER <[email-masked]<mailto:[email-masked]>> wrote:

 > Indeed, it has been remarkable how poor the sales pitch has been to resource-poor operations that are expected to adopt this, even after all this time.

<snip>
 > Specifically there is a cycle of ungranted requests. Alice has no incentive to upgrade her infrastructure because she cannot use any new feature until Bob upgrades.  Meanwhile Bob has no incentive to upgrade ahead of Alice.

 > Mere exhortations from the great and the good have very limited effect.

The "elephant in the room" which this discussion hasn't considered is "Why would a widget maker want to spend money, thereby reducing their bottom line, to upgrade their network to IPv6? Applying traditional business risk/reward analysis, is there even one real *business advantage* to justify such an expense? If there isn't any, then IPv6 would only rationally be deployed by such an end user if it were both transparent and free.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 12 Oct 2010 13:52:45 -0400

I would hope that a practical benefit of IPv6 would be improved performance
as a result of support for large packets.

That said, I expect to be disappointed.

I had really hoped that IEEE would have made support for jumbo frames an
absolute requirement for all gigabit ethernet. But nooooo, its an option so
we missed out on that opportunity.

On Tue, Oct 12, 2010 at 11:24 AM, Fleischman, Eric <
[email-masked]> wrote:

>  > On Mon, Oct 11, 2010 at 12:35 PM, Dave CROCKER <[email-masked]>wrote:
>
>>
>  > Specifically there is a cycle of ungranted requests. Alice has no
> incentive to upgrade her infrastructure because she cannot use any new
> feature until Bob upgrades.  Meanwhile Bob has no incentive to upgrade
> ahead of Alice.
>
>  The "elephant in the room" which this discussion hasn't considered
> is "Why would a widget maker want to spend money, thereby reducing their
> bottom line, to upgrade their network to IPv6? Applying traditional
> business risk/reward analysis, is there even one real *business advantage*
> to justify such an expense? If there isn't any, then IPv6 would only
> rationally be deployed by such an end user if it were both transparent
> and free.
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 12 Oct 2010 19:00:27 -0400

When the big dig was going on in Boston, an entire interchange had to be
constructed was used for some years and then torn down again. The cost of
the interchange was in the high tens of millions of dollars.

On Tue, Oct 12, 2010 at 3:13 PM, Dave CROCKER <[email-masked]> wrote:

> to be settled carefully, IMO, and the modern renditions about this period
> of time are typically off the mark:
>
>
> The community chose to drop the work and ignore the issue for 10 or 15
> years. It happens that Deering's proposal came out of participation in our
> working group, muttering something like "all this transition stuff is fine,
> but when it's done, what we'll be left with will be ugly."  So he designed
> his elegant IP enhancement.
>

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 14 Oct 2010 09:23:09 +0900

> as a result of support for large packets.

That is, like almost all the other ambitiously extended
functionality of IPv6, an illusion.

> absolute requirement for all gigabit ethernet. But nooooo, its an option so

I'm not sure what is "an option", as maxUntaggedFrameSize of
Ethernet is 1518B without any option, though larger frames are
not actively prohibited.

I'm not sure what "jumbo frames" mean, as 9KB frames which is
available also to IPv4.

But, if you are talking about jumbograms, which is larger than
64KB, which is IPv6 specific, they are useless.

While some computers (vector super computers, especially) are
slow to react on interrupts and context switching to receive
packets, which was the motivation to introduce jumbograms,
such computers have I/O subsystem, which can take care of TCP
without bothering main CPUs.

						Masataka Ohta