Subject: Re: Call for action vs. lost opportunity (Was: Re: Renumbering)

From: Ralph Droms <[email-masked]>
Date: Thu, 4 Oct 2007 04:52:29 -0400

Regarding transition:

On Sep 14, 2007, at Sep 14, 2007,3:43 PM, Dave Crocker wrote:
>
>
> Unless I've missed something rather basic, in the case of IPv6,  
> very little
> attention was paid to facilitating transition by maximizing  
> interoperability
> with the IPv4 installed base.
Dave, I have to agree with you in this regard.  We may have achieved  
neither
significant new capabilities because IPv6 ~= IPv6+more_bits, nor ease of
transition because transition wasn't thoroughly evaluated early on in
the design process...

- Ralph

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

---

From: Ralph Droms <[email-masked]>
Date: Thu, 4 Oct 2007 16:12:56 -0400

Typo: should read IPv6 ~= IPv4+more_bits...

- Ralph

On Oct 4, 2007, at Oct 4, 2007,4:52 AM, Ralph Droms wrote:

> Dave, I have to agree with you in this regard.  We may have  
> achieved neither

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 07 Oct 2007 09:14:40 +1300

On 2007-10-05 09:12, Ralph Droms wrote:
>>> Unless I've missed something rather basic, in the case of IPv6, very 
>>> little

Ralph, that last assertion simply isn't true. Migration/transition/
co-existence was on the radar screen right from the start. The dual
stack model was chosen explicitly to allow for co-existence, and in
particular so that dual stack servers can serve both IPv4 and IPv6
clients, and that is running code.

There's a fundamental difficulty in having IPvX-only clients working
with IPvY-only servers except via application-level relays. It isn't
a consequence of design details of v4 and v6. I'm sure we could
have done better, but this was very definitely thought about.

     Brian

_____________________________1.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IeG3N-0004Zl-9W
	for [email-masked]; Sat, 06 Oct 2007 16:15:13 -0400
Date: Sun, 07 Oct 2007 09:14:40 +1300
From: Brian E Carpenter <[email-masked]>
To: Ralph Droms <[email-masked]>
Cc: IETF-Discussion <[email-masked]>
Subject: Re: Call for action vs. lost opportunity (Was: Re: Renumbering)

On 2007-10-05 09:12, Ralph Droms wrote:
>>> Unless I've missed something rather basic, in the case of IPv6, very 
>>> little

Ralph, that last assertion simply isn't true. Migration/transition/
co-existence was on the radar screen right from the start. The dual
stack model was chosen explicitly to allow for co-existence, and in
particular so that dual stack servers can serve both IPv4 and IPv6
clients, and that is running code.

There's a fundamental difficulty in having IPvX-only clients working
with IPvY-only servers except via application-level relays. It isn't
a consequence of design details of v4 and v6. I'm sure we could
have done better, but this was very definitely thought about.

     Brian

__________________
Ietf mailing list
[email-masked]

---

From: Ralph Droms <[email-masked]>
Date: Tue, 9 Oct 2007 11:49:25 -0400

Brian - is it provable that no design for a follow-on to IPv4 would  
have provided that backward compatibility?  Or were there  
architectural and engineering decisions that chose other features  
over backward compatibility?

And, I guess I'll stop here as I'm rehashing a train that long ago  
left the station...

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Tue, 9 Oct 2007 11:43:56 -0400

Brian - OK, I agree that a wide range of tunneling/translation  
mechanisms have been considered; was the transition problem  
considered during the basic design?

In any event, in my opinion we don't have a fundamental level of  
backward compatibility that would solve the current deployment issues.

- Ralph

---

From: Tony Li <[email-masked]>
Date: Tue, 9 Oct 2007 09:43:21 -0700

On Oct 9, 2007, at 8:49 AM, Ralph Droms wrote:

> is it provable that no design for a follow-on to IPv4 would have  
> provided that backward compatibility?

Hi Ralph,

I don't know about 'provable', but there's a strong argument as to  
why that's challenging.

Any new design would have necessarily required more bits to address  
more end systems.  Making legacy systems interact with these  
additional addressing bits without some form of gateway, NAT or other  
translation would indeed be challenging.  You're literally trying to  
expand the size of the namespace that a legacy implementation will  
recognize.

> And, I guess I'll stop here as I'm rehashing a train that long ago  

While the train has left the station, it seems like it can still be  
modified while in motion.

Tony

---

From: David Conrad <[email-masked]>
Date: Tue, 9 Oct 2007 11:29:30 -0700

On Oct 9, 2007, at 9:43 AM, Tony Li wrote:
> additional addressing bits without some form of gateway, NAT or  
> other translation would indeed be challenging.  You're literally  
> trying to expand the size of the namespace that a legacy  
> implementation will recognize.

32 bit AS numbers.

Regards,
-drc

---

From: Tony Li <[email-masked]>
Date: Tue, 9 Oct 2007 12:21:28 -0700

On Oct 9, 2007, at 11:29 AM, David Conrad wrote:

>> Any new design would have necessarily required more bits to  
>> address more end systems.  Making legacy systems interact with  
>> these additional addressing bits without some form of gateway, NAT  
>> or other translation would indeed be challenging.  You're  
>> literally trying to expand the size of the namespace that a legacy  

Fortunately, the legacy BGP implementations don't need to recognize  
the new part of the namespace.  They only see the legacy space,  
including AS_TRANS.  The new namespace is translated (with major  
amounts of information loss) into the old namespace for their  
benefit.  This still doesn't provide a mechanism for legacy systems  
to interact directly with new systems.  For example, you can't have a  
legacy system directly peer with a system using a 32 bit AS number.   
Instead, it has to be remapped to AS_TRANS.

So, it's just NAT for BGP.  ;-)

Tony

---

From: Dave Crocker <[email-masked]>
Date: Tue, 09 Oct 2007 16:16:15 -0400

Ralph Droms wrote:
> Brian - is it provable that no design for a follow-on to IPv4 would have 
> provided that backward compatibility?  Or were there architectural and 
> engineering decisions that chose other features over backward 
> compatibility?

    1.  Take the original, simple Deering specification.

    2.  Declare the initial IPv6 address space as being the current IPv4 
address space, with all upper bits zero.

    3.  The requirement for connecting a v6 stack to a v4 stack is a very 
simple IP header-mapping translation, with no loss of information at the IP 
level.

    4.  The v6 stack would need to have a v4 mode, for use by v4 applications 
-- applications that use v4 addresses.

You are now done with an initial v6 deployment.

Note the absence of dual stack in any single host, the minimal incompatibility 
between the two versions of IP, and so on.

A continuing series of incremental changes would permit incremental benefit of 
the larger address space in IP, routing, applications, etc.

Has the added 15 years brought more functionality than this approach would 
have permitted? Is deployment easier?

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "Stephen Sprunk" <[email-masked]>
Date: Tue, 9 Oct 2007 16:05:38 -0500

Thus spake "Tony Li" <[email-masked]>
>>> more end systems.  Making legacy systems interact
>>> with these additional addressing bits without some form of
>>> gateway, NAT or other translation would indeed be challenging.
>>> You're literally trying to expand the size of the namespace that
>>> a legacy implementation will recognize.
>>
>> 32 bit AS numbers.
>
> Fortunately, the legacy BGP implementations don't need to
> recognize the new part of the namespace.  They only see the
> legacy space, including AS_TRANS.  The new namespace is
> translated (with major amounts of information loss) into the old
> namespace for their benefit.  This still doesn't provide a
> mechanism for legacy systems to interact directly with new
> systems.  For example, you can't have a legacy system directly
> peer with a system using a 32 bit AS number.   Instead, it has
> to be remapped to AS_TRANS.
>

Does that mean the IETF is going to deprecate 32-bit ASNs like was done to 
NAT-PT?  ;-)

Perhaps, if the folks hadn't been so dogmatically against NAT at the time, 
the v4-to-v6 transition model would have worked similarly and we'd be done 
with it by now...

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: Keith Moore <[email-masked]>
Date: Tue, 09 Oct 2007 19:44:05 -0400

>    2.  Declare the initial IPv6 address space as being the current
> IPv4 address space, with all upper bits zero.
>
>    3.  The requirement for connecting a v6 stack to a v4 stack is a
> very simple IP header-mapping translation, with no loss of information
> at the IP level.
>
>    4.  The v6 stack would need to have a v4 mode, for use by v4
> applications -- applications that use v4 addresses.
Close.  But that still wouldn't have let hosts with extended addresses
(nonzero upper bits) converse with hosts that only had v4 capability,
even assuming that "very simple IP header mapping translation" in the
signal path.  The upgraded hosts could have sent packets to the v4-only
hosts but not vice versa.

Of course, if we could have all agreed on an approach like that 15 years
ago, and convinced stack vendors to add the stack extensions long before
they were needed,  AND somehow manage to get those extensions well
tested, AND updated all of the APIs and applications to be able to use
extended addresses, not to mention DNS, then we might have made our
transition a lot easier.  That's a big IF though.  My experience is that
seldom-used extensions don't tend to work very well. 

And if we had (at least initially) embedded IPng addresses inside IPv4
packets, by any of various means (IPAE had one approach, 6to4 another,
and embedding the extended bits in an IPv4 option a third) and assumed
that we would start out routing IPng packets over the IPv4 Internet, we
could have avoided coupling (at least) several difficult problems: (a)
upgrading the network to use larger addresses, (b) renumbering the
network to improve routing scalability, (c) simplifying the packet format.

(but it's at least conceivable that if IPng had been designed as an
extension to IPv4, to be carried at least initially over IPv4 networks,
then NATs would have evolved in such a way as to facilitate use of
extended addresses between participating pairs of hosts.  not that this
would have been obvious circa 1992.  ).

As it turned out, the approach chosen coupled those three problems with
at least two other problems: the one of having to upgrade apps, stacks,
and DNS; and the problem of forcing apps to choose between multiple
source and destination addresses.

And finally there's the problem of marketing/mindshare - trying to get
people to understand and accept the subtle differences between IPv4 and
IPv6 instead of selling them an enhanced version of IPv4.  By
comparison, the notion of "extended addressing" was already familiar
from the PC world.   It might have been much easier to sell IPv4 with
extended addresses than to sell the "new" IPv6.

This is, I believe, a classic case of second-system effect.  Trying to
solve several problems at once significantly raises the difficulty of
solving any of them, particularly when adoption of the solution requires
parties with vastly different interests (like carrier ISPs, enterprise
networks, OS developers, and application developers) to all buy into the
solution within a narrow timeframe.  By contrast, decoupling the
solutions might have allowed a more incremental adoption of all of the
ideas, or most of them.   (renumbering for routing scalability might
still have been a hard sell)

Of course, the devil is in the details.

And the delay in adopting IPv6 further compounded the difficulties,
because networks have changed a lot since 15 years ago.  NATs,
firewalls, intrusion detection, interception proxies, were much rarer in
the early 1990s.  All of these are affected by IPv6, and all of these
impose further barriers to adoption of IPv6.

But there's no point in kicking ourselves about this now.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 10 Oct 2007 13:55:48 +1300

> hosts but not vice versa.

Indeed. And that was the problem with my own proposal (aeiou)
which was in some ways even simpler - it preserved the existing
32 bit address space and added a 32 bit address extension to be
used within sites. Exactly the same issue as Keith points out
applied, except that it was the nonzero _lower_ extension bits
that would prevent 2-way communication with legacy hosts.

Around about IETF 25 through 29, this class of ideas was thoroughly
discussed.

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 10 Oct 2007 14:12:56 +1300

Stephen,
> 
> Perhaps, if the folks hadn't been so dogmatically against NAT at the 
> time, the v4-to-v6 transition model would have worked similarly and we'd 
> be done with it by now...

I doubt it. The underlying problem with NAT doesn't go away whatever you
do. IMHO, there probably isn't any true solution that doesn't involve
a mechanism for distributing address-to-address mappings in some shape
or form, so that all parties have the same view of whatever address
mapping applies to a given e2e traffic flow. (It doesn't matter for
this argument whether you're using the address mapping to perform NAT,
encapsulation, or SHIM6 type address-swapping.)

If you try to design a better NAT-PT, I'm pretty sure it will involve
signalling back to the IPv6 side that "your correspondent believes
that your address is ::FFFF:192.0.2.3", or some such.

    Brian

---

From: Thomas Narten <[email-masked]>
Date: Wed, 10 Oct 2007 09:31:04 -0400

> applications -- applications that use v4 addresses.

Um, sounds an awful lot like dual-stack to me. Hosts (that understand
IPv6) also must be able to originate and receive either IPv4 packets
or the bigger IPv6 ones. Sure, the details may be somewhat different,
but fundamentally, we have dual stack, with IPv6 nodes needing to
support IPv4 for backwards compatability.

And in the network, routers have to understand both the original IPv4
format, plus the new IPv6 format.

If there was a magic "trivial" transition/upgrade strategy, we would
have done it years ago.

Really.

Thomas

---

From: Dave Crocker <[email-masked]>
Date: Wed, 10 Oct 2007 10:17:24 -0400

> Um, sounds an awful lot like dual-stack to me. Hosts (that understand

It's not.

No more than having your TCP use selective acks constitutes a 'dual stack', 
relative to having TCP not use selective acks.  While what I suggested isn't 
that "minor" an enhancement to the stack, neither does it constitute an 
entirely separate stack.

To repeat:  Dual stack is entirely separate.

That's the approach that was chosen.  IPv6 is an incompatible protocol module, 
compared with IPv4.  Independent addressing.  Independent interfacing. 
Independent management.

What I described was a compatible upgrade.  Very different beast.

Yes, it is not perfectly compatible.  The only way to achieve that is to have 
purely syntactic differences.

Oh.  Wait a minute.  hat I described -- as a first step for adoption -- would 
have been a purely syntactic difference, albeit one that set the basis for 
fixing the only problem that IPv6 was originally asked to solve:  bigger 
address space.

Exploiting that basis would have been moved to a strictly administrative step. 
  Prior to exploiting it, interoperability between IPv4 and IPv6 could have 
been perfect and easy.

But it would have had the feature of being adopted as no more than a software 
upgrade (and availability of syntax-translating routers.)

> support IPv4 for backwards compatability.

And what I described was an approach that would have permitted a "pure" IPv6 
host, where interaction with an IPv4 host required a syntax-translating relay 
of some sort.

This approach does not prohibit having a host implement both formats, but what 
is fundamental is that it does not require it.  This is in marked contrast 
with what we have now, needing a much hairier different translating relay, 
independent address administration and, really, independent operations and 
management.  V6 is an independent network from V4.

> format, plus the new IPv6 format.

Yes, anything looking at a format must understand it.  If IPv4 traffic is 
mixed with IPv6 traffic, then yes the routers need to understand both.

The difference in what I described is that networks that do only one of the 
formats would nonetheless be part of a unified global service.  What we 
instead have is that we have two separate services.  Separate addressing, 
separate management.  Very much larger barrier to adoption.

(For reference, I am being so painfully redundant in making my points, here, 
because it seems to be necessary.)

> If there was a magic "trivial" transition/upgrade strategy, we would

You must have been participating in different discussions than I was.  If one 
looks at the style of discussion now, what we see is an effort to dismiss 
criticisms and alternatives, rather than counter them seriously.  This is what 
took place back then, too.  Timely deadlines were dismissed.  Simplicity was 
dismissed. Integration was dismissed.

The ones that I was around suffered from a classic second-system syndrome of 
a) lack of pressure to delivery a timely solution, b) feature creep, c) lack 
of concern for interoperability.

Brian's reference to a history that discussed this, and other, alternatives 
entirely ignores the differences between "discussing" and "taking seriously". 
  That is, what he does not do is explain why a simpler approach was rejected.

One would think that a 15-year project that was pursued to solve a fundamental 
Internet limitation but has achieved such poor adoption and use would motivate 
some worrying about having made some poor decisions.  A quick response that 
says "we talked about that" but says no more seems a little bit facile.

d/
-- 

   Dave Crocker

---

From: Keith Moore <[email-masked]>
Date: Wed, 10 Oct 2007 11:30:08 -0400

> That's the approach that was chosen.  IPv6 is an incompatible protocol
> module, compared with IPv4.  Independent addressing.  Independent
> interfacing. Independent management.
>
> Yes, it is not perfectly compatible.  The only way to achieve that is
> to have purely syntactic differences.
>
> Oh.  Wait a minute.  hat I described -- as a first step for adoption
> -- would have been a purely syntactic difference, albeit one that set
> the basis for fixing the only problem that IPv6 was originally asked
> to solve:  bigger address space.
>
> Exploiting that basis would have been moved to a strictly
> administrative step.  Prior to exploiting it, interoperability between
> IPv4 and IPv6 could have been perfect and easy.
>
> But it would have had the feature of being adopted as no more than a
> software upgrade (and availability of syntax-translating routers.)
You make it sound like a trivial step, but it's not.  That "no more than
a software upgrade" is fairly equivalent to the effort required to
upgrade IPv4 software to IPv6 today (different APIs, different DNS
records, updated apps, and difficulties for p2p apps) and I'll note that
after 15 years that effort is still not complete (especially for
software that isn't bundled with operating systems).  And "the
availability of syntax-translating routers" can't necessarily be assumed
either, particularly not if there would have been a need to draw firm
borders between legacy IPv4 and enhanced IPv4 enclaves. (though perhaps
NATs would have evolved in that direction).
> And what I described was an approach that would have permitted a
> "pure" IPv6 host, where interaction with an IPv4 host required a
> syntax-translating relay of some sort.
As you probably remember, the "syntax-translating relay" approach at the
boundary of different mail enclaves (ASCII-only vs. 8-bit transparent,
ASCII headers vs. UTF-8 headers) has been discussed several times and
generally rejected in favor of per-message negotiation, mostly because
of that difficulty of drawing a clean boundary between enclaves (and
also the difficulty of having flag days during which an entire enclave
upgrades).  Offhand I'm not sure why IP networks would find this kind of
operation any easier.
> This approach does not prohibit having a host implement both formats,
> but what is fundamental is that it does not require it.  This is in
> marked contrast with what we have now, needing a much hairier
> different translating relay, independent address administration and,
> really, independent operations and management.  V6 is an independent
> network from V4.
Independent address administration, and treating v6 as a separate
network from v4, do impose a barrier to adoption.  I understand why IPv6
didn't go this way.  But I also wonder if the costs of having IPv6 be
completely separate were as well-understood as the advantages.

I think too many people assumed that everyone would independently adopt
IPv6 in the absence of any immediate advantage to doing so, and also
that the barriers to "adopting IPv6" looked far simpler in the mid-1990s
than they are today.
> Yes, anything looking at a format must understand it.  If IPv4 traffic
> is mixed with IPv6 traffic, then yes the routers need to understand both.
>
> The difference in what I described is that networks that do only one
> of the formats would nonetheless be part of a unified global service. 
not clear.   for instance, would enhanced IPv4 hosts universally be able
to reach one another?  or would the absence of translating relays in
some cases make their connectivity spotty?
> (For reference, I am being so painfully redundant in making my points,
> here, because it seems to be necessary.)
The problem might not be that people don't understand what you are
saying, but that people don't so readily accept that the alternative
would have been as simple and easy as you seem to think.

> You must have been participating in different discussions than I was. 
> If one looks at the style of discussion now, what we see is an effort
> to dismiss criticisms and alternatives, rather than counter them
> seriously.  
People may differ on what constitutes a dismissal versus a serious
counterargument.
> This is what took place back then, too.  Timely deadlines were
> dismissed.  Simplicity was dismissed. Integration was dismissed.
That's a bit of an over-simplification.  Simplicity was highly valued -
that's why the IPv6 packet format ended up being simpler than IPv4, and
part of why the idea of incorporating IPv4 address space into IPv6 was
rejected.  Integration wasn't dismissed out-of-hand; instead, a number
of proposals were considered at length.  Sure the effort ran long, but
so does everything else that IETF does.   It was obvious that IPng was
going to require changes to host stacks, apps, DNS, and routers no
matter which proposal was chosen.  The dual-stack alternative looked
attractive because it carried with it the notion that someday the IPv4
stack could be dropped.  (People don't like the idea of old cruft
hanging around forever.  The most frequent complaint I hear about RFC
2047 is not that it works poorly or that the things leak but that it's
ugly and it's hard to get rid of.)

I think that in hindsight there was too much emphasis on producing a
desirable end-state and too little emphasis on producing an attractive
transition path. 

And I think the transition model that most people assumed was, well,
naive.  But in the early 1990s, before Windows even had an IP stack,
when the net was much smaller and had a higher clue density, when the
web was just a small-scale experiment that didn't even have the IMG tag
yet (and therefore much less glitz potential), it was possible to
imagine that the small, generally clueful net would see the necessity of
moving to IPv6 and do it fairly quickly.  By the late 1990s when IPv6
was thought to be finished, the net was too big to make that kind of
transition in a short time.
> The ones that I was around suffered from a classic second-system
> syndrome of a) lack of pressure to delivery a timely solution, b)
> feature creep, c) lack of concern for interoperability.
We certainly agree that IPv6 suffered from second-system effect.
> One would think that a 15-year project that was pursued to solve a
> fundamental Internet limitation but has achieved such poor adoption
> and use would motivate some worrying about having made some poor
> decisions.  A quick response that says "we talked about that" but says
> no more seems a little bit facile.
Looking back to try to abstract lessons seems worthwhile, though it
makes no more sense to dismiss the choices that were made as obviously
wrong than to dismiss the alternatives you are suggesting as obviously
wrong.  To the extent IPv6 could have been different in such a way as to
make it more successful, the differences are subtle and the effects even
moreso.  As for worrying, I see little value in that now.   And as for
quick responses, that's the nature of anything discussed on the IETF
list, or pretty much any mailing list that I've seen.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Oct 2007 09:45:25 +1300

On 2007-10-11 03:17, Dave Crocker wrote:
> No more than having your TCP use selective acks constitutes a 'dual 
> stack', relative to having TCP not use selective acks.  While what I 
> suggested isn't that "minor" an enhancement to the stack, neither does 
> it constitute an entirely separate stack.
> 

Not viewed from the socket programmer's point of view.
Look at how an AF_INET6 socket behaves when given
an address like ::FFFF:192.0.2.3
afaik the behavior is then exactly what you describe.
Whether the stacks are independent code modules or
alternate paths through the same code is irrelevant
to the externally observed behavior.

     Brian

> Yes, it is not perfectly compatible.  The only way to achieve that is to 
> have purely syntactic differences.
> 
> Oh.  Wait a minute.  hat I described -- as a first step for adoption -- 
> would have been a purely syntactic difference, albeit one that set the 
> basis for fixing the only problem that IPv6 was originally asked to 
> solve:  bigger address space.
> 
> Exploiting that basis would have been moved to a strictly administrative 
> step.  Prior to exploiting it, interoperability between IPv4 and IPv6 
> could have been perfect and easy.
> 
> And what I described was an approach that would have permitted a "pure" 
> IPv6 host, where interaction with an IPv4 host required a 
> marked contrast with what we have now, needing a much hairier different 
> translating relay, independent address administration and, really, 
> independent operations and management.  V6 is an independent network 
> from V4.
> 
> 
> The difference in what I described is that networks that do only one of 
> the formats would nonetheless be part of a unified global service.  What 
> we instead have is that we have two separate services.  Separate 
> addressing, separate management.  Very much larger barrier to adoption.
> 
> If one looks at the style of discussion now, what we see is an effort to 
> dismiss criticisms and alternatives, rather than counter them 
> seriously.  This is what took place back then, too.  Timely deadlines 
> were dismissed.  Simplicity was dismissed. Integration was dismissed.
> 
> Brian's reference to a history that discussed this, and other, 
> alternatives entirely ignores the differences between "discussing" and 
> "taking seriously".  That is, what he does not do is explain why a 
> simpler approach was rejected.
> 
> fundamental Internet limitation but has achieved such poor adoption and 
> use would motivate some worrying about having made some poor decisions.  
> A quick response that says "we talked about that" but says no more seems 
> a little bit facile.
> 
> d/

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Thu, 11 Oct 2007 19:46:53 +0900 (JST)

> to the externally observed behavior.

	see draft-ietf-v6ops-security-overview-06.txt section 2.2.

itojun

---

From: Markku Savela <[email-masked]>
Date: Thu, 11 Oct 2007 15:20:48 +0300

> From: [email-masked] (Jun-ichiro itojun Hagino)
> Cc: [email-masked]
> 

My view is that "::FFFF:192.0.0.2" totally identical with "192.0.0.2"
(internally inside the host stack implementation).  There will be no
functional difference anywhere in API, whichever form is used.

I realize, that the above is not easy to achieve using the legacy
POSIX socket API, which has has different sized address structures for
IPv4 and IPv6.

In Symbian OS, there is no such problem. The generic address structure
allocation (TInetAddr) can hold both IPv4 and IPv6 address. Thus, the
there is only one IP stack, which just happens to do IPv4, when
address is IPv4 (either 192.0.0.2 or ::FFFF:192.0.0.2"). Real IPv6
addresses trigger IPv6 processing. Logically stack implements *one*
"INET family" (PF_INET) with two possible address families "AF_INET"
and "AF_INET6".

Applications can be written totally agnostic on whether connection is
over IPv4 or IPv6. All sockets are just opened as AF_INET, and the
addresses used determine whether IPv4 or IPv6 gets used. On listening
"undefined address family" can be used to accept both IPv4 and IPv6
for the same socket (TCP or UDP).

Receiving "::FFFF:127.0.0.1" from network is not going to work as an
attack, because of "strong model", and 127.0.0.1 is not configured for
the real interface (=> destination 127.0.0.1 does not match configured
address and gets dropped).

---

From: Dave Crocker <[email-masked]>
Date: Thu, 11 Oct 2007 11:07:21 -0400

Brian E Carpenter wrote:
>> suggested isn't that "minor" an enhancement to the stack, neither does it
>> constitute an entirely separate stack.
>> 
> Not viewed from the socket programmer's point of view. Look at how an
> AF_INET6 socket behaves when given an address like ::FFFF:192.0.2.3 afaik
> the behavior is then exactly what you describe.

The underlying point of my note was:

> fundamental Internet limitation but has achieved such poor adoption and use
> would motivate some worrying about having made some poor decisions.  A
> quick response that says "we talked about that" but says no more seems a
> little bit facile.

Yet your response continues down the path of "What was decided was fine. So 
let's dismiss expressions of concerns about it by citing a previous decision, 
as if that choice was inevitable." In particular, my point was that a 
v6-specific API was not immediately required.

The approach to IPv6 could have been vastly more incremental, so as to make 
its adoption vastly less disruptive.  But you have to start by considering the 
benefits of such an approach.

Brian, the approach to IPv6 ignored protecting the installed base and ignored 
finding a way to have the lowest possible barriers to adoption.  As 15 years 
of non-adoption has demonstrated, the value proposition for adopters also was 
not compelling.

To repeat:  At some point, it would help to take history as being instructive, 
rather than to dismiss attempts at considering alternatives.

This might not change the situation with IPv6, but it could have an effect on 
other, future work.

d/
-- 

   Dave Crocker

---

From: Keith Moore <[email-masked]>
Date: Thu, 11 Oct 2007 11:15:54 -0400

>> and use
> Yet your response continues down the path of "What was decided was
> fine. So let's dismiss expressions of concerns about it by citing a
> previous decision, as if that choice was inevitable." In particular,
> my point was that a v6-specific API was not immediately required.
perhaps not.  but without such an API, software would not have been able
to migrate.  so at the point when people started to actually want to use
the extended addresses, the software would not have been there.
> To repeat:  At some point, it would help to take history as being
> instructive, rather than to dismiss attempts at considering alternatives.
yes.  but it's not instructive to pick apart the solution that was
chosen and claim that some other solution would have produced a better
result, without applying similar analysis to the alternative.

Keith

---

From: John C Klensin <[email-masked]>
Date: Thu, 11 Oct 2007 12:09:58 -0400

Dave,

Reordering your comments slightly.,..

--On Thursday, 11 October, 2007 11:07 -0400 Dave Crocker
<[email-masked]> wrote:

> To repeat:  At some point, it would help to take history as
> being instructive, rather than to dismiss attempts at
> considering alternatives.
> 
> This might not change the situation with IPv6, but it could
> have an effect on other, future work.

It is hard to predict the future.  It is almost equally hard to
draw firm conclusions from the fairly recent past, especially
when drawing those conclusions requires understanding the
counterfactual implications of various choices.   I agree that
history is instructive and should not be ignored, but think we
should hesitate to jump to conclusions about what it tells us.

> The approach to IPv6 could have been vastly more incremental,
> so as to make its adoption vastly less disruptive.  But you
> have to start by considering the benefits of such an approach.
> 
> Brian, the approach to IPv6 ignored protecting the installed
> base and ignored finding a way to have the lowest possible
> barriers to adoption.  As 15 years of non-adoption has
> demonstrated, the value proposition for adopters also was not
> compelling.

Examining a value proposition requires asking both the question
"how hard, expensive, or risky is it for me to do this?" and
"how do I benefit if I do?".  Larger benefits justify larger
investments; a perception of few benefits may not justify even a
small investment. From that perspective, even small changes to
something that is perceived as working satisfactorily involve
risks of bugs and disruption.  There is no way to make a change
zero-cost and zero-risk.

Certainly it is reasonable to hypothesize, as you are doing,
that decisions about transition and compatibilities with IPv6
created a bad value proposition by making transition too
complicated and costly.  But it is equally reasonable to
hypothesize that the error lay in our failure to address enough
other issues -- to solve enough other problems -- to create real
"pull" for making changes, no matter how cheap those changes
appeared to be.  

Would IPv6 have been more successful had the solution addressed
fundamental routing issues more directly?   If it somehow made
small-site multihoming more straightforward and plausible?  If
it incorporated a solution to the semantic and management issues
implied by RFC 3514?  If it solved some other real or imagined
problem with IP?   If we had simultaneously overhauled TCP to
support more connection-agile or address-insensitive use of
applications?

As things have turned out, we've pretty much ended up with "IPv4
with more bits".  Selling that one to the community is hard
except on the basis of either an anti-NAT campaign or one based
on the imminent falling of the sky.  The former is made more
difficult by the observation that most user organizations do not
perceive that they are suffering real harm from NATs (whether
that perception is correct or incorrect is irrelevant) and more
difficult yet by concerns that IPv6 will not eliminate some of
the factors that cause NATs.  The latter is made more difficult
by too many prior predictions, some unrealistic over-marketing,
and an inability to see the sky moving downward and accurately
and convincingly anticipate the dire effects of its coming down.
Can one demonstrate that, given those factors, an easier
transition process would have made a significant difference?
Possibly it would have, but I don't think there is any way to be
convinced.

On the other hand, had IPv6 offered more than what the market
seems to see as a mostly-theoretical improvement (elimination of
NATs) and avoidance of a future address space catastrophe) --
some obvious advantages to those who who already have deployed
IPv4 installations and the address space needed to support
them-- would we have seen wider adoption?  Again, there is no
way to know for sure but, if the answer is "yes", then it is
hard to guess how much difference a slightly easier transition
would have made.

So, let us by all means look at history and try to learn its
lessons.  But let us also be sure we know what those lessons
actually are, rather than using the historical argument to
justify a position that may not be supported by the evidence.

best,
     john

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 12 Oct 2007 08:43:17 +1300

> 	see draft-ietf-v6ops-security-overview-06.txt section 2.2.

Sure. I absolutely don't like to see ::FFFF/96 on the wire.

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 12 Oct 2007 08:46:31 +1300

Dave,

On 2007-10-12 04:07, Dave Crocker wrote:

...
> Yet your response continues down the path of "What was decided was fine. 

No, I'm on the path of trying to be precise and accurate about
what was decided. Since it's engineering, it isn't perfect.

> So let's dismiss expressions of concerns about it by citing a previous 
> decision, as if that choice was inevitable." In particular, my point was 
> that a v6-specific API was not immediately required.
> 
> The approach to IPv6 could have been vastly more incremental, so as to 
> make its adoption vastly less disruptive.  But you have to start by 
> considering the benefits of such an approach.
> 
> Brian, the approach to IPv6 ignored protecting the installed base and 
> ignored finding a way to have the lowest possible barriers to adoption.  
> As 15 years of non-adoption has demonstrated, the value proposition for 
> adopters also was not compelling.
> 
> This might not change the situation with IPv6, but it could have an 
> effect on other, future work.

I can't possibly disagree with that, but my interest is in getting
the implemented code deployed before the IPv4 clock winds down.

     Brian

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Fri, 12 Oct 2007 12:27:58 +0900 (JST)

> Sure. I absolutely don't like to see ::FFFF/96 on the wire.

	then we'd have to deprecate SIIT at least.  still, you cannot be sure
	that ::ffff:0:0/96 are not on the wire.

itojun

---

From: Tony Li <[email-masked]>
Date: Thu, 11 Oct 2007 22:58:35 -0700

> the implemented code deployed before the IPv4 clock winds down.

The IPv4 clock will wind down right after the last FORTRAN compiler is
decomissioned.  Wouldn't it make more sense to put the effort into  
morphing
v6 into something that *IS* attractive?

Tony

---

From: Keith Moore <[email-masked]>
Date: Fri, 12 Oct 2007 02:13:58 -0400

> decomissioned.
actually it looks like FORTRAN is going to outlast IPv4 by several years.
> Wouldn't it make more sense to put the effort into morphing v6 into
> something that *IS* attractive?
perhaps, though there's precious little time left to do that, and still
a lot of denial to overcome.

Keith

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 11 Oct 2007 19:43:30 +0200

> If there was a magic "trivial" transition/upgrade strategy, we would

How about this: we magically go back 10 years in time and define  
"IPv4.6" which is the first 32 bits of the IPv6 address in the IPv4  
address fields and the other 96 bits in a new header that sits  
between the IPv4 header and the upper layer protocol (TCP/UDP/etc).  
IPv4 stacks are updated to copy back the extra header with the lower  
96 bits whenever sending packets in reponse to ones with those 96  
bits in them.

I'm pretty sure we'd still have issues with unupgraded TCP stacks and  
firewalls, but just implementing the simple copyback mechanism and  
adjusting firewalls accordingly would be a much simpler way for  
existing IPv4 users to be able to talk to IPv6 users than adding IPv6  
to their networks. Applications on the IPv4 host that are unaware of  
the fact that they're talking to an IPv6 host would still have NAT  
issues, but it would also be possible to run applications that know  
about the IPv6 address of the correspondent so the communication  
would be end-to-end clean.

(Ok there would have to be some extra bit shuffling to avoid using up  
the IPv6 address space as fast as the IPv4 space but that's just  
details. Maybe copy bits 4 - 31 and set bits 0 - 3 to 1111 in the  
IPv4 address if they are 0010 in the IPv6 address.)

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Fri, 12 Oct 2007 20:06:39 +0900 (JST)

> morphing v6 into something that *IS* attractive?

	hope you can do that in time... (i mean, not just for the States
	but for the entire planet)

	for me, IPv6 itself is attractive enough (that's why i'm putting so
	much time on it).  if it can lose some of the extra meat which makes
	it a little bit more complex than it should be, it would be super.

itojun

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 15 Oct 2007 09:39:51 +1300

> 	that ::ffff:0:0/96 are not on the wire.

I agree, it just isn't obvious that such packets will be delivered...

    Brian