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

Mon Dec 30 20:46:58 UTC 2013

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.

  The problem is that the IETF basically failed to actually accept the only
  transition mechanism (network address translation) that could provide 
  meaningful backwards compatibility, 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.