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

[Adiel Akplogan]

On 2013-12-31, at 01:05 AM, Avri Doria <avri at acm.org> wrote:
> 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.

Agree Avri, and this is the kind of reasoning that we, from the technical community, must be open enough to agree to explore …. We should not bash out  perceived (or even sometime very real) problems just because no one want to work on new technical challenge that addressing the issue may pose. Indeed that is a pattern of a voluntary work: the result is solely driven by voluntary and good will (self responsibility) of the engaged people. This has a good and bad side which we may need to assess and acknowledge it limitation and see how that can be improved.

> 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.

partly because we too naively believe that everyone has the necessary knowledge, background and interest to apply good technical judgement in their choices.

- a.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 313 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://1net-mail.1net.org/pipermail/discuss/attachments/20140102/430eba03/signature.asc>