Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard

["Scott O. Bradner" <[e-mail]>]

> On Feb 17, 2017, at 9:12 AM, [e-mail] wrote:
> 
> Fernando,
> 
> It is a simple logical consequence.
> 
> Middleboxes do not exist in the IPv6 architecture.

firewalls do not exist in IPv6????
load balancers do not exist in IPv6???
content redirectors do not exist in IPv6???
…

Scott

> There is no interpretation of 2460 that can lead to an implementor inserting headers other places than at the source.
> Therefore, there is no interoperability issue in RFC2460 nor any ambiguity that needs to be resolved in RFC2460.
> 
> We're not writing law, we're writing interoperable protocol.
> 
> Ole
> 
> 
>> On 17 Feb 2017, at 13:40, Fernando Gont <[e-mail]> wrote:
>> 
>> On 02/15/2017 07:18 AM, [e-mail] wrote:
>>> 
>>>>>> Ole, it is true that we write in English, and there is always room for
>>>>>> "interpretation", sometimes reasoanble room, sometimes not.
>>>>>> 
>>>>>> But in this case we have a demonstrated difference in how people
>>>>>> understand the existing text.  When we have such a demonstrated
>>>>>> difference, we have an obligation to address it.
>>>>> 
>>>>> This particular issue has caused no interoperability issue,
>>>> 
>>>> May I ask what's the data that support this statement?
>>> 
>>> From the shepherd's writeup:
>>>  IPv6 is implemented on most platforms (hosts, routers, servers, etc.),
>>>  including proprietary and open source.  A list of products that have
>>>  received the IPV6 Ready logo can be found at:
>>> 
>>>  https://www.ipv6ready.org/db/index.php/public/?o=4
>> 
>> This has nothing to do wth the interoperability problems that may be
>> caused by a middlebox that inserts EHs.
>> 
>> 
>> 
>>>> You certainly have no way of knowing this, or whether interoperability
>>>> issues may arise in the future.
>>> 
>>> Yes, we do know if our protocols have interoperability issues.
>>> Have you implemented RFC2460? I have. So have many others on this list.
>>> In the context of implementing 2460 there just is no ambiguity and this issue will never arise.
>> 
>> Huh?  Yes, if you connect two IPv6 devices, without a middle-box
>> inserting EHs in the middle, you will not experience the associated
>> possible problems. What's the news here?
>> 
>> 
>> 
>>> What you are talking about is something else. You are talking about the hypothetical "What if someone standardised something new in the future?"
>> 
>> :-)
>> 
>> C'mon, Ole. Take a look at the initial versions of the SR I-D -- and, EH
>> insertion has reportedly been deployed as a result of the implementation
>> of such initial versions of the I-D.
>> 
>> 
>> You can clarify that EH insertion is banned, and move rfc2460bis to full
>> stanard (since that's what's supposed to be mature)
>> 
>> You can delay rfc2460->std, and work to update rfc2460.
>> 
>> Now, moving rfc2460 to full std knowingly leaving a hole there such that
>> after rfc2460 is std you completely change the architecture (e2e vs
>> !e2e) with EH insertion doesn't seem a serious thing to do, IMO.
>> 
>> Thanks,
>> --
>> Fernando Gont
>> SI6 Networks
>> e-mail: [e-mail]
>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>