ietf
[Top] [All Lists]

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

2017-02-17 12:16:46


El 17/2/17 a las 2:14 p.m., Scott O. Bradner escribió:
On Feb 17, 2017, at 9:12 AM, otroan(_at_)employees(_dot_)org 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???
…

I was about to ask the same question

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 <fgont(_at_)si6networks(_dot_)com> 
wrote:

On 02/15/2017 07:18 AM, otroan(_at_)employees(_dot_)org 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: fgont(_at_)si6networks(_dot_)com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

<Prev in Thread] Current Thread [Next in Thread>