Subject: Re: Backwards compatibility myth [Re: Last Call: <draft-weil-shared-transition-space-request-14.txt>]

From: [email-masked] (Noel Chiappa)
Date: Mon, 13 Feb 2012 22:53:17 -0500 (EST)

> From: Brian E Carpenter <[email-masked]>

    > The design error was made in the late 1970s, when Louis Pouzin's advice
    > that catenet addresses should be variable length, with a format prefix,
    > was not taken during the design of IPv4.

Ironically, TCP/IP had variable length addresses put in _twice_, and they were
removed both times! (You can't make this stuff up! :-)

- TCPv1 (no separate TCP and IP at that point) had variable lenth addresses
	of up to 15 4-bit nibbles

- TCP/IPv3 had variable lenth addresses of up to 15 8-bit bytes (but the
	'network number' part was supposed to be only the first byte, exactly
	like IPv4 in its early days)

This latter change happened shortly before I joined the project, otherwise no
doubt I would have strenously objected! :-)

	Noel

---

From: Bob Braden <[email-masked]>
Date: Tue, 14 Feb 2012 09:31:01 -0800

On 2/13/2012 7:53 PM, Noel Chiappa wrote:
>      >  From: Brian E Carpenter<[email-masked]>
>
Noel,

You probably remember this, but...

Within the ARPA-funded Internet research program that designed IP and 
TCP, Jon Postel and
Danny Cohen argued strenuously for variable length addresses. (This must 
have been
around 1979. I cannot name most of the other 10 people in the room, but 
I have
a clear mental picture of Jon, in the back of the room, fuming over this 
issue. Jon believed
intensely in protocol extensibility.)

However, Vint Cerf, the ARPA program manager, rules against variable 
length addresses and
decreed the fixed length 32 bit word-aligned addresses of RFC 791. His 
argument was that
TCP/IP had to be simple to implement if it were to succeed (and survive 
the juggernaut
of the ISO OSI protocol suite).

  System programmers of that day were familiar with word-aligned data
structures with fixed offsets, and variable length addresses seemed to 
be (and in fact
would be) harder to program and would make packet dumps harder to interpret.

It was a political as much as a technical judgment, and Vint may have 
been right ... we
can never know. We do know that IP eventually succeeded and OSI failed, 
but it
was a near thing for awhile. Of course, there were other factors in the 
success
of IP, such as Berkeley Unix.

It is to be noted that when it came time to define IPv6 some 20 years 
later, the IETF
stuck with fixed length internet addresses.

Bob Braden

---

From: Steve Crocker <[email-masked]>
Date: Tue, 14 Feb 2012 19:34:53 +0100

The word alignment issue was very strong and the router people had considerably more influence than the host folks.  I tried to propose variable length addressing using four bit nibbles in August 1974 and I got no traction at all.

Steve

Sent from my iPhone

On Feb 14, 2012, at 6:31 PM, Bob Braden <[email-masked]> wrote:

> Within the ARPA-funded Internet research program that designed IP and TCP, Jon Postel and
> Danny Cohen argued strenuously for variable length addresses. (This must have been
> around 1979. I cannot name most of the other 10 people in the room, but I have
> a clear mental picture of Jon, in the back of the room, fuming over this issue. Jon believed
> However, Vint Cerf, the ARPA program manager, rules against variable length addresses and
> decreed the fixed length 32 bit word-aligned addresses of RFC 791. His argument was that
> TCP/IP had to be simple to implement if it were to succeed (and survive the juggernaut
> structures with fixed offsets, and variable length addresses seemed to be (and in fact
> It was a political as much as a technical judgment, and Vint may have been right ... we
> can never know. We do know that IP eventually succeeded and OSI failed, but it
> was a near thing for awhile. Of course, there were other factors in the success
> It is to be noted that when it came time to define IPv6 some 20 years later, the IETF
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: "Bradner, Scott" <[email-masked]>
Date: Tue, 14 Feb 2012 18:37:39 +0000

in the case of IPng, the router people wanted variable length but the host people (or at least some of them) did not

Scott

Scott O Bradner

Senior Technology Consultant

Harvard University Information Technology

Innovation & Architecture

(P) +1 (617) 495 3864

29 Oxford St. Rm 407

Cambridge, MA 02138

On Feb 14, 2012, at 1:34 PM, Steve Crocker wrote:

Steve

Sent from my iPhone

Noel,

Bob Braden

Ietf mailing list

[email-masked]

Ietf mailing list

[email-masked]

---

From: Martin Rex <[email-masked]>
Date: Tue, 14 Feb 2012 22:40:34 +0100 (MET)

Bob Braden wrote:
> TCP, Jon Postel and Danny Cohen argued strenuously for variable length
> addresses. (This must have been around 1979. I cannot name most of the
> other 10 people in the room, but I have a clear mental picture of Jon,
> in the back of the room, fuming over this issue. Jon believed
> length addresses and decreed the fixed length 32 bit word-aligned
> addresses of RFC 791. His argument was that TCP/IP had to be simple
> to implement if it were to succeed (and survive the juggernaut

I'm quite OK with both, IPv4 fixed-length 32-bit addresses and
IPv6 fixed-length 128-bit addresses, and consider fixed-length
addresses reasonable.

What I really don't like is that IPv6 was not made to be transparently
backwards compatible (on the IPv4 address range), but instead a completely
different protocol that requires non-trivial translation IPv4<->IPv6.

One the one hand, the IETF was frowning upon NATs when they were
developed outside of the IETF.  But if you look at the IETFs
(lack of) migration plan, the translation that you need in order
to make old-IPv4 interoperate with new-IPv6, is actually worse than
an IPv4 NAT.

-Martin

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Feb 2012 11:34:07 +1300

Martin,

> to make old-IPv4 interoperate with new-IPv6, is actually worse than

I'm sorry, but *any* coexistence between RFC791-IPv4-only hosts and
hosts that are numbered out of an address space greater than 32 bits
requires some form of address sharing, address mapping, and translation.
It doesn't matter what choice we made back in 1994. Once you get to the
point where you've run out of 32 bit addresses and not every node can
support >32 bit addresses, you have the problem.

   Brian

---

From: Martin Rex <[email-masked]>
Date: Tue, 14 Feb 2012 23:45:10 +0100 (MET)

> support >32 bit addresses, you have the problem.

But what is your point?

With a fully backwards compatible transparent addressing scheme,
a much larger fraction of the nodes would have switched to actively
use IPv6 many years ago.

You would not have two distinct routing tables for two independent
Internets, but a single routing table for a single Internet.

And the first network interfaces that would be using >32-bit
IP-addresses exclusively would have been networking equipment of
ISPs that does not need to be IPv4-addressable by everyone and his dog
anyway (that is not so much different from the /10 shared address space
that CGNs will be using).

The necessary changes to applications would be minimal,
the "happy eyeballs" contortion completely unnecessary
and the security assessment for an IPv6 enabled network
*MUCH* simpler.

-Martin

---

From: Mark Andrews <[email-masked]>
Date: Wed, 15 Feb 2012 10:26:41 +1100

In message <[email-masked]>, Martin Rex writes
> and the security assessment for an IPv6 enabled network

Happy eyeballs just points out problems with multi-homing in general.
IPv4 has the *same* problem and sites spend 1000's of dollars working
around the issue which could have been addressed with a couple of
extra lines of code on the client side in most cases.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Bob Hinden <[email-masked]>
Date: Tue, 14 Feb 2012 15:56:16 -0800

Martin,

> a much larger fraction of the nodes would have switched to actively

Right, just like they could have deployed dual stack many years ago too.

The deployment problem was not due to technical issues, it was because the Internet changed to only deploy new technology that generated revenue in the short term.  After a lot of thought, I have come to the conclusion that it wouldn't have mattered what the IETF did, we would still be facing the same problems.  It wouldn't be seriously deployed until IPv4 address ran out.

These "if we had only done foo" discussions all miss the biggest deployment factor.

Bob

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 15 Feb 2012 09:06:57 +0900

Brian E Carpenter wrote:

> requires some form of address sharing,

Sure.

> address mapping, and translation.

Not at all.

Realm Specific IP [RFC3102] is such an example without any
mapping nor translations. Abstract of the RFC states:

   This document examines the general framework of Realm Specific IP
   (RSIP).  RSIP is intended as a alternative to NAT in which the end-
   to-end integrity of packets is maintained.  We focus on
   implementation issues, deployment scenarios, and interaction with
   other layer-three protocols.

> support>32 bit addresses, you have the problem.

The only problem is that some people misinterpret it that
we had needed IPv6.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 15 Feb 2012 09:10:47 +0900

> extra lines of code on the client side in most cases.

It's Brian Carpenter who refused to discuss such issues in
MULTI6 WG.

						Masataka Ohta

---

From: Randy Bush <[email-masked]>
Date: Tue, 14 Feb 2012 17:09:50 -0800

> The deployment problem was not due to technical issues, it was because
> the Internet changed to only deploy new technology that generated
> revenue in the short term.  After a lot of thought, I have come to the
> conclusion that it wouldn't have mattered what the IETF did, we would
> still be facing the same problems.  It wouldn't be seriously deployed
> until IPv4 address ran out.

perhaps 'engineering' includes thinking about the costs of deployment.
perhaps backward compatibility would have reduced the costs.

randy, whose $dayjob did deploy very early

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Feb 2012 16:04:36 +1300

> a much larger fraction of the nodes would have switched to actively

Why? They would have needed updated stacks. The routers would
have need updated stacks. The servers would have needed updated
stacks. The firewalls would have needed updated stacks. The load
balancers would have needed updated stacks. Many MIBs would have
needed to be updated. DHCP servers would have needed to be updated.
ARP would have needed to be updated, and every routing protocol.

Why would the economic incentives have been significantly different?

> Internets, but a single routing table for a single Internet.

True, but why is this a particular advantage? It wouldn't have
affected the need for an update to BGP4, for example.

> that CGNs will be using).

Neither is it so much different from dual stack routing, which has been
working for, what, 15 years now? I don't see the comparison with CGN
though, which is a carefully engineered single bottleneck of failure,
in contrast to dynamic routing.

> the "happy eyeballs" contortion completely unnecessary

As someone else said, this is to do with multihoming
and multi-interfacing; the fact that there are two address
lengths is a side-issue. We would still have needed to update
the socket interface to deal with >32 bit addresses, and ditto
the DNS.

> and the security assessment for an IPv6 enabled network

I agree that the fact that IPv6 has a different feature list
from IPv4 has provided entertainment for security analysts.

I will shut up on this topic and get back to IPv6 deployment.

    Brian

---

From: Randy Bush <[email-masked]>
Date: Tue, 14 Feb 2012 19:40:08 -0800

> ARP would have needed to be updated, and every routing protocol.

<rant>

the routers had v6 code in the mid to late '90s.  servers had the kame
stack before then.  etc etc etc.  except for dhcp, of course, as the v6
religious zealots did not want to allow dhcp, it would make enterprise
conversion too easy.

what we did not have was a way to deploy around the fracking
incompatibility.  it was not until 2001 or so that we could even run
useful dual stack, so we early deployers had two parallel networks for
some years.

religion has always been more important to the ietf than deployment.
look at dhcpv6, the zealots are still stonewalling router discovery.
look at the deprecation of nat-pt, now nat64/dns64.  it is as if the
ipv6 high priesthood did everything in their power to make ipv6
undeployable without very high cost.  and they have succeeded admirably.

so today, since the costs of ipv6 incompatibility and lack of feature
parity are still high, for some folk it is easier to deploy nat44444.
what a win for the internet.  congratulations.

randy

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 14 Feb 2012 20:16:45 -0800

> what a win for the internet.  congratulations.

</rant>

But, this pig too shall fly

Cb

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 15 Feb 2012 13:46:51 +0900

> ARP would have needed to be updated, and every routing protocol.

With Realm Specific IP [RFC3102]:

what is necessary are minor modification on IPv4/transport stack
of new (but not existing) hosts and minor extension of DHCP.

						Masataka Ohta

---

From: Yoav Nir <[email-masked]>
Date: Wed, 15 Feb 2012 09:50:56 +0200

> These "if we had only done foo" discussions all miss the biggest deployment factor.

I disagree with that. With things that take considerable effort to develop and deploy, any sane business or agency would do a cost/benefit analysis, and not deploy unless they can see how it pays off. 

Smaller projects sometimes go under the radar. Maybe the cost-benefit analysis says it's not worth doing a cost-benefit analysis. When investment is low, people do things even without assurances that those would in fact be needed. I'll leave example from our employer out of this thread.

If adding support for the next IP version in products was easy (say, 1-2 man-years for an OS, and 1-2 man months for an application), then Windows XP, Mac OS 10.1 and whatever Linux was running at the time and Solaris 2.9 would have had the support, and applications would follow quickly, long before IPv4 addresses became scarce.

Yoav

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 15 Feb 2012 06:42:44 -0800

G'day.

Always fun to watch an exchange among entrenched perspectives...

On 2/14/2012 9:31 AM, Bob Braden wrote:
> However, Vint Cerf, the ARPA program manager, rules against variable length
> addresses and decreed the fixed length 32 bit word-aligned addresses of RFC
> 791. His argument was that TCP/IP had to be simple to implement if it were to
> succeed (and survive the juggernaut of the ISO OSI protocol suite).

Experience with development, deployment and operations using a core construct is 
not irrelevant when trying to upgrade an infrastructure function.

As I recall, there was essentially no experience with variable length addresses 
-- and certainly no production experience -- then or even by the early 90s, when 
essentially the same decision was made and for essentially the same reason.[1]

It's not that variable length addressing is a bad idea; it's that it didn't get 
the research work and specification detail it needed, for introduction into what 
had become critical infrastructure.  What I recall during the IPng discussions 
of the early 90s was promotion of the /concept/ of variable length addressing 
but without the experiential base to provide assurance we knew how it would operate.

Clearly the motivation for variable-length addresses is a Good Thing, since 
having it work properly would save needing to do an infrastructure change to 
quadruple the address space every 2-3 decades.  (With 128-bit addressing, 
perhaps it will be longer; with the rapid expansion of the Internet, perhaps it 
will be sooner.)

But really I'll suggest that fixed-vs-variable addressing is essentially 
irrelevant to the question of transition ease and backward compatibility.  What 
mostly affects that is effort.  Development, deployment and operations effort. 
For an established infrastructure, the more a change is different from what 
already is used, the more effort it takes to introduce the new thing.  (Versions 
of this point have been made on this thread repeatedly by other folk, and mostly 
everyone is ignoring the premise. I'll add that for folk who have noted the 
potential significance of my occasional consonance with the views of John 
Klensin, please be aware that its occurrence with Randy Bush is considerably 
more rare...)

Among the arguments being used to miss the point are:

>
> On 2/14/2012 2:34 PM, Brian E Carpenter wrote:
>> I'm sorry, but*any*  coexistence between RFC791-IPv4-only hosts and

This notes an objective reality about a limit, while entirely missing the 
potential benefit available until reaching it.  In this case, that was a 15-20 
year window.

If the design goal had been restricted to the original "increase the address 
space bits", without encumbering it with additional architecture and functional 
changes, and had been based on re-use of the existing IPv4 scheme, the initial 
upgrade could have:

    a) been with a module tacked on to existing IPv4 implementations and 
installed as a relatively minor software upgrade (albeit with some additional 
API hooks) to most implementations, rather than the traumatic installation of an 
entirely new stack

    b) used trivial format-mapping translators rather than having to deal with 
the software and operational complexities of gateways that have to reconcile 
independent address spaces and other functionality

    c) had essentially no incremental deployment or operations costs

This would have gotten the core of the larger address space mechanism deployed 
and operational long before it was needed, and the focus after that would have 
been restricted to /using/ the additional bits, rather than trying to solve a 
variety of additional problems.

Moving from re-using IPv4 addressing to expansion into new IPv6 bits for 
addressing could have then been a separate, incremental step.  An important one, 
certainly.  A step with its own challenges, sure.  But incremental and narrow.

The classic project management point for major change is to minimize critical 
dependencies.  Instead, the IPv6 increased them.

> On 2/14/2012 3:56 PM, Bob Hinden wrote:
>> The deployment problem was not due to technical issues, it was because the Internet changed to only deploy new technology that generated revenue in the short term.

The Arpanet did not convert to production use of TCP/IP until it was forced to 
by a central authority in 1983.  Long before 'revenue' was an issue.

Absent coercion like this, organizations do not incur the considerable cost of 
infrastructure change in the absence of a strongly-perceived need that will have 
reasonably immediate and significant benefit.  This is one of the very basic 
reasons that any change targeting longer-term benefit and with little-to-no 
short-term benefit needs to be made as painless as possible.  In this case, 
painless would have meant being as compatible as possible, with small increments 
of change.

That is, I claim that absent well-funded research efforts and/or the leverage of 
a central authority, the history of the Net has /always/ been to focus on 
immediate need, not long-term benefit.  (This includes the original motivations 
for inventing packet-switching. Lofty long-term visions notwithstanding, it was 
overcoming expensive [and fragile] long-haul telecom costs and 
hostile-environment outages that motivated the work. )

 > affected the need for an update to BGP4, for example.

With the sort of highly-constrained upgrade I've described above, no immediate 
change to BGP would have been required.  That could have been deferred to a 
follow-on effort.  The same applies to DHCP re-use.

> On 2/14/2012 3:26 PM, Mark Andrews wrote:

Multi-homing is a problem above the IP layer, not at it.  As classically noted, 
the problem starts with using addresses as identifiers.

d/

[1] Unless I've misread, my brother and Scott have exactly opposite memories of 
which constituencies ere lobbying for and against variable-length addressing.

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Stephen Sprunk <[email-masked]>
Date: Wed, 15 Feb 2012 15:10:09 -0600

On 15-Feb-12 08:42, Dave CROCKER wrote:
> As I recall, there was essentially no experience with variable length
> addresses -- and certainly no production experience -- then or even by
> the early 90s, when essentially the same decision was made and for
> essentially the same reason.[1]
>
> It's not that variable length addressing is a bad idea; it's that it
> didn't get the research work and specification detail it needed, for
> introduction into what had become critical infrastructure.  What I
> recall during the IPng discussions of the early 90s was promotion of
> the /concept/ of variable length addressing but without the
> experiential base to provide assurance we knew how it would operate.

The problem with variable-length addressing that, in practice, one needs
to specify a maximum length.  The result, therefore, is that you don't
have variable-length addresses at all but rather fixed-length addresses
with a shorthand encoding for unused bits.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 15 Feb 2012 13:35:56 -0800

On 2/15/2012 1:10 PM, Stephen Sprunk wrote:
> to specify a maximum length.

In some practical terms, perhaps, but there are extensibility schemes that allow 
the payload (addressing bits, in this case, to go on forever, in theoretical terms.

 > The result, therefore, is that you don't

For most variable-length schemes, yes, but not all.

d/

-- 

   Dave Crocker

---

From: Steve Crocker <[email-masked]>
Date: Wed, 15 Feb 2012 16:39:20 -0500

This is essentially correct.  The apparent conceptual difference is that a variable length address looks more like source routing.  The end system owns only a small part of the total address; the rest is the network portion, fashioned to seem like a source route.  Depending on how the address is interpreted, the division of the network portion into routing steps will be specified in advance or will be interpreted at each step.  The latter alllows gradual evolution of the network by consolidating small switches into larger ones.

The transition to CIDR within IPv4 accomplished pretty much the same thing and had the same benefits.  Nonetheless, 32 bits just isn't enough.  The only way variable length address would have provided a smooth transition is if there had been room to increase the length of the address after some years of use.  Well, if we had left room in the address field for more than 32 bits, we'd have had the same advantage.  But we didn't.

Steve

---

From: Richard Barnes <[email-masked]>
Date: Wed, 15 Feb 2012 16:39:26 -0500

> In some practical terms, perhaps, but there are extensibility schemes that allow the payload (addressing bits, in this case, to go on forever, in theoretical terms.

I look forward to your design for a forwarding plane based on streaming addresses :)

Does anyone really think that we'll need more than 128 bits?

--Richard

---

From: Wes Beebee <[email-masked]>
Date: Wed, 15 Feb 2012 16:41:52 -0500

> the payload (addressing bits, in this case, to go on forever, in theoretical

One example would be a linked-list of strides...

- Wes

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 15 Feb 2012 13:46:46 -0800

> Does anyone really think that we'll need more than 128 bits?

You might have missed my opening qualification by refererring to practical terms 
as an actual limit?

I was responding to a comment about design limitations; I wasn't recommending 
infinite-length addressing.

I wasn't being as theoretical as one might assume.  Although I had no direct 
hands-on, some of the folks on this list did:

<http://en.wikipedia.org/wiki/Word_%28computer_architecture%29#Variable_word_architectures

d/

-- 

   Dave Crocker

---

From: Steven Bellovin <[email-masked]>
Date: Wed, 15 Feb 2012 17:29:55 -0500

Scott, if memory serves you and I wanted the high-order 2 bits of the IPng
address to select between 64, 128, 192, and 256-bit addresses -- and when
we couldn't get that we got folks to agree on 128-bit addresses instead of
64-bit, which is what had been on the table.

>>> stuck with fixed length internet addresses.

		--Steve Bellovin, https://www.cs.columbia.edu/~smb

---

From: Ross Callon <[email-masked]>
Date: Wed, 15 Feb 2012 17:44:53 -0500

But the maximum for implementation is not necessarily the maximum for the packet format. 

Thus one could have started with a variable length address format, but said "For the immediate future we will always pick a length of 32 bits". Then at some point we could have said "in 5 years we are going to start assigning 64 bit addresses, you MUST update your implementations to support this as well -- same packet format and everything else stays the same". 

We would have needed to be very careful to ensure that the packet formats allowing variable lengths applied to all protocols that carry or use IP addresses (such as DNS records, ...). Such architectural care is not easy to enforce. 

Whether everyone actually would have updated their implementations is another issue -- but at least in theory it *might* have been simpler than upgrading to a new version of IP. 

Of course, since we don't have time machines, it is too late to change our past (and we will note that other types of networks have run out of addresses / digits / area codes  also). 

Ross

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Sprunk
Sent: Wednesday, February 15, 2012 4:10 PM
To: [email-masked]
Subject: Re: Variable length internet addresses in TCP/IP: history

S

---

From: Steven Bellovin <[email-masked]>
Date: Wed, 15 Feb 2012 18:40:43 -0500

> Whether everyone actually would have updated their implementations is another issue -- but at least in theory it *might* have been simpler than upgrading to a new version of IP. 

One argument against the 64/128/192/256 proposal was that untested code paths would be buggy.  Very true -- which is why we should have done things like use 192-bit addresses for loopback, 256 for multicast, 128 for root servers, etc.
> Of course, since we don't have time machines, it is too late to change our past (and we will note that other types of networks have run out of addresses / digits / area codes  also). 

Fred Brooks has noted (in the context of computer address spaces) that every successful architecture has eventually run out of bits.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 16 Feb 2012 09:40:30 +0900

Steve Crocker wrote:

> The only way variable length address would have provided a
> smooth transition is if there had been room to increase the
> length of the address after some years of use.

Bottom up approach to extend address length toward port numbers,
thus, worked, is working and will keep working with or without
NAT.

If necessary, we can have new TCP, UDP and other transport
protocols with 32 or 48 bit long port numbers without changing
core routers, though it requires minor modifications to transport
and application code.

Anyway the current 48 bit space of IPv4 addresses and 16 bit port
numbers will be suffice for a decade or two.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 16 Feb 2012 09:43:30 +0900

> 64-bit, which is what had been on the table.

Thus, IPv6 was mortally wounded from the beginning.

					Masataka Ohta

---

From: Steven Bellovin <[email-masked]>
Date: Wed, 15 Feb 2012 22:58:11 -0500

> Thus, IPv6 was mortally wounded from the beginning.

The history is vastly more complex than that.  However, this particular decision
was just about the last one the IPng directorate made before reporting back to
the IETF -- virtually everything else in the basic IPv6 design had already
been agreed-to.  It was a long, painful effort, with a lot of debate over very
many of the points that have been discussed over and over again.  I don't think
this was "the" wrong decision.

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 17 Feb 2012 10:30:39 +0900

Steven Bellovin wrote:

> been agreed-to.

I understand that, unlike 64 bit, 128 bit enables MAC based
SLAAC with full of states, which is as fatal as addresses
with 32 hexadecimal characters.

> I don't think this was "the" wrong decision.

Isn't it obvious that, with a lot more than 1% penetration of the
Internet to the world today, we don't need address length much more
than 32 bits?

						Masataka Ohta

---

From: Steven Bellovin <[email-masked]>
Date: Thu, 16 Feb 2012 21:46:48 -0500

> with 32 hexadecimal characters.

That decision came later.  In fact, the deficiencies of relying on MACs were
discussed quite frequently in the directorate.
> Internet to the world today, we don't need address length much more

No.  I did and I do think that 64 bits was inadequate.

Why?  Apart from the fact that if this transition is painful, the next
one will be well-nigh impossible, having more bits lets us find creative
ways to use the address space.  Stateless autoconfig is one example,
though I realize it's controversial.  ID/locator split, which I've been
a proponent of for very many years, works a lot better with more bits,
because it allows topological addressing both within and outside an
organization.

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 17 Feb 2012 05:41:26 -0800

On 2/16/2012 6:46 PM, Steven Bellovin wrote:
> ways to use the address space.

Not to single out Steve, but my recollection is that that view was at the core 
of much of the thinking about v6, certainly in the early-/mid-90s.  "We only get 
this one (last) opportunity to make changes, so we'd better add everything we 
think we'll (ever) need."

The view is wrong.

Changing an established infrastructure is of course (a lot) more difficult and 
expensive than creating a new one, but infrastructures can and do get changed.

There is a difference between saying "we need to make all of the changes that we 
know we need now, versus saying we need to anticipate all of the changes we are 
going to need to make."

Steve's phrasing points to the latter and that winds up as a fantasy exercise 
which adds complexity and delay.  It also tends to add the wrong things in the 
wrong way.

d/

-- 

   Dave Crocker

---

From: Bob Hinden <[email-masked]>
Date: Fri, 17 Feb 2012 10:10:39 -0800

Steve,

> discussed quite frequently in the directorate.

And that's why the standard allows for other types of identifiers to be used to create Interface Identifiers.

> because it allows topological addressing both within and outside an

To confirm what your are saying about an ID/locator split in IPv6, that the other reason why we went with 128-bit address with a 64/64 split as the common case and defining IIDs that indicate if they have global uniqueness.  This creates a framework that an ID/locator split could be implemented.  

Opinions vary if ID/locator split is useful, but we have a framework that would allow it without having to roll out another version of IP.  A win IMHO.

Bob

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 20 Feb 2012 18:14:13 +0900

Bob Hinden wrote:

>> ID/locator split, which I've been

> To confirm what your are saying about an ID/locator split in
> IPv6, that the other reason why we went with 128-bit address
> with a 64/64 split as the common case and defining IIDs
> that indicate if they have global uniqueness.  This creates
> a framework that an ID/locator split could be implemented.

I actually implemented such a system about 10 years ago
and it worked fine.

It was an experiment for hosts to use multiple IPv4 and IPv6
addresses, some of which may have ID/loc separation. DNS
was used for ID->loc mapping. Mobility was also supported
with multiple home locators and multiple foreign locators.

We did something related to end to end multihoming and
happy eyeball.

ID locator separation was good, because it requires about
half amount of space to store multiple addresses sharing
an ID.

Moreover, rewriting destination locators enables elegant
forwarding from home agents to mobile nodes without
tunneling (and associated MTU tax), if transport check
sums do not involve locators.

But, that's all. It was not very interesting that I
abandoned further work on it after government funding
period expired.

> Opinions vary if ID/locator split is useful, but we have a
> framework that would allow it without having to roll
> out another version of IP.  A win IMHO.

Assuming address must be 16B long, it may be good to
have ID/loc separation.

However, if we have choice, having 8B long addresses
is much better, because it is more compact than 16B
address with ID/loc separation.

Even with 8B addresses, we can rewrite destination addresses,
if there is a destination header option (or a mandatory field)
"original destination address" to be used to confirm transport
identity and checksum.

So, along with the failure with a lot of confusion to have
SLAAC, we can conclude that IPv6 addresses should have been
8B long.

Maybe, even with the current IPv6 packet format, routers
can look only at first 8B of addresses and ignore the
latter 8B (used as "original source/destination address"
for source/destination address rewriting).

						Masataka Ohta

---

From: Martin Rex <[email-masked]>
Date: Thu, 23 Feb 2012 17:51:59 +0100 (MET)

Bob Hinden wrote:
> Martin Rex wrote:

Just two days ago I had an extremeley disappointing experience with IPv6.
Windows XP 64-bit (aka Win2003sp2) on a local network with a private
DNS universe, IPv4 only network, Windows IPv6 protocol stack installed
but IPv6 active only on the two virtual network interfaces of VMware.

Somehow the DNS servers configured in the network settings had performed
only a partial zone reload and were replying only to some queries,
failing some DNS queries with server failure or timeout,
and one DNS zone had become completely invisible.

I noticed the problem suddenly during work because every new connection
took ~16 seconds delay to complete.  Wondering what was wrong, I started
wireshark.

I saw Windows2003 send out 23 DNS lookups for AAAA records for the
requested hostname over the course of 16 seconds (some of which returned
server failure, some of which failed with no such name),
until Windows 2003 finally decided to also try a DNS A query--which got
immediately successfully answered and the connection was established.
The delay affected each and every connection attempt, even when contacting
the same host repeatedly (although there is a DNScache service running...).

Disabling IPv6 on all network adapters did not stop this Windows AAAA frenzy,
I had to actually uninstall the IPv6 protocol stack (an action which
immediately kills *ALL* network connectivity of the machine and requires
a reboot to recover...) for this AAAA nonsense to end.

During the past few years I had two similar encounters with sudden severe
connectivity problems on a Windows XP and a Linux installation, and
both times, the problem disappeared when I disabled IPv6.

It is also significantly easier to configure the firewall for IPv4-only...

-Martin

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 24 Feb 2012 10:32:27 +1300

Martin,

Yes, the issues with an unconditional "prefer IPv6" approach
have been noted, and operating systems of the vintages you
mention certainly deserved criticism. In fact this has been a
major focus of IPv6 operational discussions, and lies behind
things like the DNS whitelisting method, the happy-eyeballs
work, and my own RFC 6343.

Old news; unfortunately it means you need new o/s versions.
Disabling 6to4 and Teredo unless they are known to be working
well is a good start, however.

Regards
   Brian Carpenter

---

From: [email-masked]
Date: Thu, 23 Feb 2012 13:51:50 -0800 (PST)

> well is a good start, however.

Old news perhaps, but an unavoidable consequence of this is that the
oft-repeated assertions that various systems have been "IPv6 ready for over 10
years" don't involve a useful definition of the term "ready".

				Ned

---

From: Doug Barton <[email-masked]>
Date: Thu, 23 Feb 2012 14:31:59 -0800

> years" don't involve a useful definition of the term "ready".

The OP specified "IPv4 only network." I suspect that if he had IPv6
connectivity his experience would have been quite different. I happily
use Windows XP on a dual-stack network, for example.

Doug (well, maybe "happily" is too strong a word, but you get the idea)

-- 

	It's always a long day; 86400 doesn't fit into a short.

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: [email-masked]
Date: Thu, 23 Feb 2012 14:48:33 -0800 (PST)

> use Windows XP on a dual-stack network, for example.

And systems running these old OS versions never under any circumstances move
from one network to another where connectivity conditions change. Riiight.

				Ned

---

From: Doug Barton <[email-masked]>
Date: Thu, 23 Feb 2012 14:55:37 -0800

> from one network to another where connectivity conditions change. Riiight.

Brian already covered "unconditional prefer-IPv6 was a painful lesson
learned," and I'm not saying that those older systems did it right. What
I am saying is that for most values of "IPv6 Ready" which included
putting the system on an actual IPv6 network, they worked as advertised.

Doug

--

---

From: [email-masked]
Date: Thu, 23 Feb 2012 14:57:23 -0800 (PST)

> putting the system on an actual IPv6 network, they worked as advertised.

Which brings us right back to my original point: This definition of "ready" is
operationally meaningless in many cases.

				Ned

---

From: Mark Andrews <[email-masked]>
Date: Fri, 24 Feb 2012 10:24:48 +1100

In message <[email-masked]>, [email-masked] w
> operationally meaningless in many cases.
 
I contend that OS are IPv6 ready to exactly the same extent as they
are IPv4 ready.  This isn't a IPv6 readiness issue.  It is a
*application* multi-homing readiness issue.  The applications do
not handle unreachable addresses, irrespective of their type, well.
The address selection rules just made this blinding obvious when
you are on a badly configured network.

No one expect a disconnected IPv4 network to work well when the
applications are getting unreachable addresses.  Why do they expect
a IPv6 network to work well under those conditions?

---

From: [email-masked]
Date: Thu, 23 Feb 2012 15:32:25 -0800 (PST)

> you are on a badly configured network.

That's because the choice has recently been made that the place to deal with
this problem is in applications themselves. I happen to think this is an
exceptionally poor choice - the right way to do it is to provide a proper
network API that hides network selection details, rather than demanding every
application out there solve the problem separately.

And yes, I'm familiar with the line of reasoning that says applications are too
varied in their needs, or their internal environments conflict with the
necessary use of threads, or whatever. I don't buy any of it. Yes, such
applications exist, but like most things there's a sweet spot that solves a
significant fraction of the problem.

> a IPv6 network to work well under those conditions?

First, you're comparing apples and oranges. Losing all network connectivity is
very different thing from losing partial network connectivity. Nobody expects
an applications that's totally dependent on the network to work without
connectivity. That's just silly.

But with other sorts of applications, I *do* have that expectation. I often
work from places without any network connectivity using applications that
employ networking as part of their function but also do non-networked stuff,
and pretty much without exception they handle the transition fine, and have
done so for years.

Then again, I use a Mac. I have no idea what the state of play of Windows or
Linux apps is in this regard.

				Ned

---

From: Martin Rex <[email-masked]>
Date: Fri, 24 Feb 2012 00:52:23 +0100 (MET)

Mark Andrews wrote:
> 
> [email-masked] writes:
> > 
> > Which brings us right back to my original point: This definition of 
> > "ready" is operationally meaningless in many cases.

Correct.

> you are on a badly configured network.

There was *NO* multihoming involved at all.

The OS of my primary workmachine has in IPv6 protocol stack with
an extremely bogus design that pretty much precludes any kind
of migration and testing.  It delays sending DNS A lookups (in favour
to AAAA lookups) for whooping 16 seconds to DNS servers for which
only an IPv4 address is known over an interface that is IPv4-only
with a default route over that very same IPv4-only interface.
And even disabling IPv6 on the two virtual network interfaces
did not stop that non-sensical behaviour.

It just doesn't make sense to send out less DNS A lookups than
DNS AAAA lookup, and even less to delay DNS A queries for 16 seconds.

The only solution was to rip IPv6 out of the OS entirely.  Luckily
I had access to the console of the machine, because when requesting
uninstall of that (inactive) IPv6 protocol stack, the machine
immediately dropped *ALL* networking on all interfaces,
ipconfig /all gives an empty list, as if remote administration
of servers was a concept completely unknown to the OS vendor.

If there is desire for widespread adoption of some new protocol
or feature, than it is a very very very very bad idea to create
such an extremely misbehaved implementation.  And it's not like
"this is brand new and we didn't have time yet to fix this bug".

-Martin

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 24 Feb 2012 09:36:37 +0900

Mark Andrews wrote:

>>> learned," and I'm not saying that those older systems did it right.

You learned a wrong lesson, then.

The essential problem is that there is half hearted support
for handling multiple addresses.

It is not an operational problem but a fundamental defects
of protocols.

> not handle unreachable addresses, irrespective of their type, well.

In part, it is an application problem. However, it is also an
IP layer problem.

> you are on a badly configured network.

The half hearted address selection rules will keep causing
this kind of problems, until IPv6 specification is
fundamentally fixed.

> a IPv6 network to work well under those conditions?

With proper IP layer support, which is lacking, which means
IPv6 specification is not ready to handle multiple addresses,
which means hosts are not IPv6 ready to handle multiple
addresses, we can expect applications work well if one of
an address among many works and rest of the addresses are
unreachable.

						Masataka Ohta

PS

IPv4, of course, is not ready to handle multiple addresses
properly, which causes some problems for multihomed hosts.

But it is not a serious problem because IPv4 hosts do not
have to have IPv6 addresses.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 24 Feb 2012 13:41:53 +1300

>> In message <[email-masked]>, [email-masked] w

...
> application out there solve the problem separately.

I wish, I *really* wish, that it worked. Making it work, by one technique
or another, is not a new topic, even when only IPv4 connectivity
was at issue. Those things are often called 'connection managers'
and are largely based on trial and error or reachability probes.

Then there are efforts like SCTP and MPTCP to solve it in the transport
layer, and shim6 to solve it in the network layer (for IPv6 only, but the
issue is the same). These solutions are also essentially based on
trial and error, and need to be supported by both hosts.

> significant fraction of the problem.

That's been part of Java for some years (since 1.5 iirc). But it
*doesn't* solve precisely the problem that Martin was describing,
where a stack falsely believes that it has IPv6 connectivity but
in fact it doesn't. In that sort of situation, short of manual
intervention, something like happy-eyeballs seems to be needed in
order for the application to fix things up when the network layer
is confused.

And no, I'm not happy with this, but it seems to be reality.

   Brian

---

From: Mark Andrews <[email-masked]>
Date: Fri, 24 Feb 2012 11:50:54 +1100

In message <[email-masked]>, Martin Rex writes
> There was *NO* multihoming involved at all.

What addresses were there on the loopback interface?  If there were
IPv4 and IPv6 addresses then it was dual stack multi-homed machine.
Applications need to work over the loopback interface as much as
they need to work over a external interface.  Having a IPv4 address
on the loopback interface is NOT a given.  A application MUST work
over the loopback interface when it does not have a IPv4 address.

I've yet to work on a machine that was not multi-homed to some
extent.  All of the machines I've worked on in the last 25 years
have had multiple interfaces.

> did not stop that non-sensical behaviour.

If there is a 16 second delay you can blame the authoritative server
adminstrators for either installing a non RFC compliant nameserver
or misconfiguring a delegation which is detectable by looking at
the negative response.  The returned records are inconsistent with
the delegation.  DNSSEC however will help fix this as broken
delegation like this don't work for positive signed answers either
with a general purpose nameserver whereas that can be overlooked
with simple testing in a non DNSSEC environment.

A RFC 1035 compliant nameserver is quite capable of answering "I
have no type 28 records at this name" or this name doesn't exist
to a type 28 query.

A RFC 1035 recursive server should also handle the lookup and return
of type 28 records as opaque blobs of data.  This is why compression
pointers are only supported on "well known types" in RFC 1035 so
it could handle records that it doesn't know the internal structure
of.

The only thing a RFC 1035 server can't do is serve AAAA records.
Serving AAAA records requires a newer server.

Secondly there is no evidence that asking for AAAA records is due to
a OS problem or a application problem.  Without reading the source
code there is no way to know.

> DNS AAAA lookup, and even less to delay DNS A queries for 16 seconds.

Actually it can make sense to make AAAA queries. Knowing whether
there are AAAA addresses or not can change how you behave when you
can't reach the machine over IPv4 assuming there are A records.

> "this is brand new and we didn't have time yet to fix this bug".

Making a AAAA should add 1 round trip lookup,  in most cases that's
much less than 200ms to the startup of a application assuming no
caching.  If there is caching or overlapping queries the additional
time can drop to nano seconds.

Mark

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 24 Feb 2012 10:05:07 +0900

[email-masked] wrote:

> This definition of "ready" is operationally meaningless in many cases.

The meaningful question is whether we have to modify code or not.

If we have to, a host is not ready. And, if it is not an
implementation problem, protocols must be fixed.

If we don't have to, it's an operational issue.

						Masataka Ohta

---

From: Mark Andrews <[email-masked]>
Date: Fri, 24 Feb 2012 12:43:04 +1100

In message <[email-masked]>, Martin Rex writes
> It is also significantly easier to configure the firewall for IPv4-only...

We (ISC) learned a long time ago (last century) that partial DNS
service for a zone is worse than total failure for a zone.  By
totally failing a zone on error it gets fixed instead of trying to
limp by on partial service.

I also suspect the search algorithm is not stopping on NOERROR
NODATA or SERVFAIL.  Searches really should stop on both those
conditions.  By stopping I mean not going onto the next element
in the search list without getting a NXDOMAIN response.  You
can ask multiple servers on SERVFAIL.

I've been arguing this for around 10+ years.

Mark