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

[Avri Doria]

Hi,

Indeed several addressing formats were discussed for v6 encapsulation of 
v4 addresses. Even though v6 was limited by its not being a variable 
length address, solutions were possible, but were decided against 
because they had a few more technical challenges than anyone at the time 
wanted to deal with.  But had there been discussion of policy areas that 
might have tipped the long term balance point in this engineering 
tussle, who knows what solutions might have been worked through to 
implementation.

And I remember long discussion about whether NAT as good or evil, which 
seems somewhat silly at this point, given that it was pragmatically the 
solution.

avri


On 30-Dec-13 15: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.
>
>    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.
>
>
>
>
>
>
> _______________________________________________
> discuss mailing list
> discuss at 1net.org
> http://1net.org/mailman/listinfo/discuss
>
>