Subject: Re: <draft-ietf-6man-rfc2460bis-09.txt>

From: Brian E Carpenter <[email-masked]>
Date: Sat, 8 Apr 2017 07:20:49 +1200

As a reminder, I suggested this change precisely to avoid the issue raised
by Alvaro Retana:

On 31/03/2017 03:13, Brian E Carpenter wrote:
> Proposed text change near the end of the Introduction:
> 
> OLD:
>    This document specifies the basic IPv6 header and the initially-
>    defined IPv6 extension headers and options.
> 
> NEW:
>    This document specifies the basic IPv6 header and the initially-
>    defined IPv6 extension headers and options required for interoperable
>    communication between any two nodes on the Internet.
> 
> Regards
>    Brian
> 
> On 31/03/2017 02:35, Bob Hinden wrote:
>> Hi,
>>
>> I published the -09 version of 6man working group draft of rfc2460bis.  Links below.
>>
>> The changes in this draft are:
>>
>>       Based on results of IETF last call, changed text in Section 4
>>       to add clarification that extension headers are not examined,
>>       processed, inserted, or deleted by any node along a packet's
>>       delivery path.
>>
>>       Changed reference from draft-ietf-6man-rfc4291bis to RFC4291
>>       because the bis draft won't be advanced as the same time.
>>
>>       Revised "Changes since RFC2460" Section to have a summary of
>>       changes since RFC2460 and a separate subsection with a change
>>       history of each Internet Draft.  This subsection will be
>>       removed when the RFC is published.
>>
>>       Editorial changes.
>>
>> A diff from the -08 version can be found at:
>>
>>    https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc2460bis-09
>>
>> Please review the changes.
>>
>> This is part of the project to move the core IPv6 specifications to Internet Standard.
>>
>> Thanks,
>> Bob
>>
>>> A new version of I-D, draft-ietf-6man-rfc2460bis-09.txt
>>> has been successfully submitted by Robert M. Hinden and posted to the
>>> IETF repository.
>>>
>>> Name:		draft-ietf-6man-rfc2460bis
>>> Revision:	09
>>> Title:		Internet Protocol, Version 6 (IPv6) Specification
>>> Document date:	2017-03-30
>>> Group:		6man
>>> Pages:		41
>>> URL:            https://www.ietf.org/internet-drafts/draft-ietf-6man-rfc2460bis-09.txt
>>> Status:         https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/
>>> Htmlized:       https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-09
>>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc2460bis-09
>>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc2460bis-09
>>>
>>> Abstract:
>>>   This document specifies version 6 of the Internet Protocol (IPv6).
>>>   It obsoletes RFC2460
>>>
>>
>>
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [email-masked]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>

---

From: Fernando Gont <[email-masked]>
Date: Fri, 7 Apr 2017 23:37:56 +0100

Brian,

FWIW, I'm against the proposed "clarification". I don't think we want
"IPv6 for the Internet", "IPv6 for...", "IPv6 for..". If we move in that
direction, it's not hard to envision this kind of conversation:

A: I have finally deployed IPv6
B: Which variant?

IPv6 is IPv6. And it is an end-to-end protocol. Inserting EHs is quite
the opposite to e2e, and in a very radical way.

It's kind of unfortunate that, after the sequence of events we have had
for this I-D, folks seem to find yet another loophole to accommodate the
future plans of a single vendor.

Thus, I don't think the current version of the I-D requires any changes.
Actually quite the opposite: such modification would be incorrect.

Thanks!

Cheers,
Fernando

-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 9 Apr 2017 01:21:23 +1200

> the opposite to e2e, and in a very radical way.

IPv4 is IPv4. And it is an end-to-end protocol. Inserting NATs is quite
the opposite to e2e, and in a very radical way.

Yet we had zero success in preventing NATs.

> future plans of a single vendor.

I don't think this creates a loophole at all. The loophole is already
there: there are no protocol police. I think we need a clear applicability
statement: the IPv6 standard is for Internet-wide interoperability. If
you don't follow this standard, you won't achieve interoperability. 
 
> Actually quite the opposite: such modification would be incorrect.

We want exactly the same final result...

Regards
     Brian

---

From: Fernando Gont <[email-masked]>
Date: Sun, 9 Apr 2017 14:21:53 +0100

> Yet we had zero success in preventing NATs.

But nobody argued that NATs were compliant with the IP model, which is
what's going on here.

As noted in my previous email, if there's a clear need for something,
and it's also clear that the only/best possible way to do that is to
insert EHs, fine. But pretending that there are loopholes in RFC2460
that allow for EH insertion, or meaning to block this document from
going to IS because it just make it crystal clear what has always been
the case, is not.

That is, let's call a lemon like that: "lemon".

> you don't follow this standard, you won't achieve interoperability. 

It's not just Internet-wide. If you mean to operate, say, in multiple
domains (without that including "the Internet"), and packets leak from
one domain to another, you still fail to interoperate.

I think there's no need for rfc2460bis to have an applicability
statement. Actually it's the other way arund: if the wg eventually
agrees to do EH, then such document should have a big boilerplate that
says "look, we're breaking the e2e model, and the IPv6 operation
context, and these are the implications, and possible problems that may
arise. You're supposed to use this only in a blahblah domain. If you're
packets leak out of that domain, you're probably busted"

> We want exactly the same final result...

Agreed.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492