[discuss] Report from the BR meeting local organizing group - Dec 2013

Mon Dec 30 22:17:49 UTC 2013

On 31/12/2013 09:46, John Curran wrote:
> On Dec 30, 2013, at 2:49 PM, Brian E Carpenter <brian.e.carpenter at gmail.com> wrote:
> 
>> On 31/12/2013 04:00, Roland Perry wrote:
>> ...
>>> If IPv6 had been devised as backwards compatible, then my problems (and
>>> those of millions of other business users) would be much less. 
>> This meme needs to die. IPv4 is the problem - since it contains no
>> provision for variable length addresses, there is mathematically no
>> such thing as a backwards-compatible design for extended addresses.
>> We didn't invent the dual stack mechanism because we liked it, but
>> because (regardless of all design details of IPv6) there was mathematically
>> no alternative.
> 
> Brian - 
> 
>   IPv4 was part of the problem; however, that doesn't mean that transparent
>   backward compatibility couldn't have been developed, only that it was to 
>   be on the IPv6 end.  The goal, as I recall, was that an IPv4 packet should
>   be able to find its way from any IPv4 host to any other IPv4 or IPv6 host, 
>   or vice versa, through a mixture of IPv4 and IPv6 routers, without any 
>   modifications to the IPv4 hosts.  
>   
>   This required developing a clear statement of the mandatory and optional 
>   mechanisms that vendors should implement in hosts, routers, and other 
>   components of the Internet in order for the transition to be carried out. 
>   Dual-stack, encapsulation and header translation mechanisms were to be 
>   defined, with the resulting specification to be used by people who were
>   implementing these IPv6 systems to achieve a straight-forward transition
>   plan to/from those IPv4-only.

Sure.

>   The problem is that the IETF basically failed to actually accept the only
>   transition mechanism (network address translation) that could provide 
>   meaningful backwards compatibility, 

We don't disagree technically. What went wrong was that the IETF assumed that
implementors and operators would move much faster on deployment, so that
the legacy problem that calls for v4/v6 translation would be minor. That
didn't happen and the IETF recognized it far too late.

>   thus leaving the world just with 
>   tunnels and dual-stack, i.e. no interoperability at all. After the IETF
>   said everything was fine, the operators began experimenting with IPv6
>   and realized that they'd have to pick up the ball and resume the work
>   in order to get what they actually needed - thus began the decade of 
>   NAT specifications and experimentation, and we're finally getting to 
>   some useful results that are seeing solid deployment (e.g. 464XLAT -
>   https://sites.google.com/site/tmoipv6/464xlat)
> 
>   I agree that changing existing IPv4 hosts would have been out-of-scope 
>   for IPng, but that did not rule having a straight-forward transition 
>   plan with some backwards compatibility via header translation - it only 
>   meant that such had to be deployed on the IPv6-side.  If that had been 
>   done, as was agreed at the time of the IPng recommendation, Roland's 
>   problems (and everyone else's) would now be much less.
> 
> FYI,
> /John
> 
> Disclaimers: My views alone (although the goal in first paragraph above is from 
>              Brian's RFC 1671, and the second nearly verbatim from RFC 1752, 
>              i.e. "The Recommendation for the IP Next Generation Protocol")
>              I (along with Brian) was a member of the IETF's IPng Directorate 
>              which made the IPv6 protocol recommendation.

Indeed. It wasn't that we (including thou and I) didn't think about
these issues, but our crystal balls were faulty because we failed
to allow for the massive growth that started when the Web was
released.

   Brian