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

From: Fernando Gont <[email-masked]>
Date: Thu, 2 Feb 2017 06:14:46 -0300

Folks,

Some comments:

*  Section 4.8 ("Defining New Extension Headers and Options")

Specification of new EHs would bring problems. And, for instance,
recommending a specific format for new EHs does not really help.

A key problem with the Uniform Format for IPv6 Extension Headers
described in this section (originally specified in RFC6564) lies in that
both IPv6 Extension Headers and Transport Protocols share the same "Next
Header" registry/namespace.  Thus, given an "unknown Next Header value",
it is impossible to tell whether the aforementioned value refers to an
IPv6 Extension Header that employs the aforementioned uniform format, or
an "unknown" upper-layer protocol (e.g. an "unknown" transport
protocol).  That is, while this document (and RFC6564) specifies the
syntax for a Uniform Format for IPv6 Extension Headers, it does not
provide a mechanism for a node to identify whether the aforementioned
format is being employed in the first place.

The current impossibility to parse an IPv6 header chain that includes
unknown Next Header values results in concrete implications for the
extensibility of the IPv6 protocol, and the deployability of new
transport protocols.  Namely,

 o  New IPv6 extension headers cannot be incrementally deployed.

 o  New transport protocols cannot be incrementally deployed.

We've elaborated on this topic in draft-gont-6man-rfc6564bis. One
possible way to address this problem is simply to ban the specification
of new EHs. Another is to d something along the lines of
draft-gont-6man-rfc6564bis. However, the current text seems misleading
-- for instance as is, it doesn't buy much to have a "unified format"
for new EHs, since you don't really know how to parse that EH in the
first place.

* Section 3:

Regarding the "version" field, it might be useful to note that it should
be checked that, upon receipt of a packet, it is actually 6. It
shouldn't matter, but in practice, it might. Please see:
<http://blog.si6networks.com/2016/02/quiz-weird-ipv6-traffic-on-local-network.html>
for a real-world scenario.

* Security Considerations section

I think the security considerations section should be augmented.

For example, the Extension Headers have been known to be useful for the
evasion of security controls. While in theory this need not be the case,
in practice it is.

* Appendix B ("CHANGES SINCE RFC2460")

I think this section should summarize the changes since RFC2460 but
*not* on a "per I-D version basis". That is, "as is", it is hard to
figure out what has changed since RFC2460.

Thanks!

Best regards,
Fernando

On 02/01/2017 08:49 PM, The IESG wrote:
> 
> The IESG has received a request from the IPv6 Maintenance WG (6man) to
> consider the following document:
> - 'Internet Protocol, Version 6 (IPv6) Specification'
>   <draft-ietf-6man-rfc2460bis-08.txt> as Internet Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2017-03-01. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>    This document specifies version 6 of the Internet Protocol (IPv6).
>    It obsoletes RFC2460
> 
> 
> 
> 
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/ballot/
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 
> The document contains these normative downward references.
> See RFC 3967 for additional information: 
>     rfc4443: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification (Draft Standard - IETF stream)
>     rfc3168: The Addition of Explicit Congestion Notification (ECN) to IP (Proposed Standard - IETF stream)
> Note that some of these references may already be listed in the acceptable Downref Registry.
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

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

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 3 Feb 2017 13:26:49 +1300

Hi Fernando,

On 02/02/2017 22:14, Fernando Gont wrote:
...
> unknown Next Header values 

Wait... you're talking about parsing by intermediate systems. The destination
node either can understand the new Next Header or transport protocol,
or it can't. That's fine, and is the intended result.

> results in concrete implications for the

In both cases, add "in the presence of interfering middleboxes".

This is not new. For a document moving from PS to Standard, it is
not something we can change.

Note, I am all for coming back to this problem, after we have the
Internet Standard in place. Maybe we can fix it or maybe we can't,
but it's IMHO off topic here.

Regards
    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 3 Feb 2017 13:37:45 +1300

In Section 4 ("IPv6 Extension Headers") the draft says:

>    With one exception, extension headers are not processed by any node
>    along a packet's delivery path, until the packet reaches the node (or
>    each of the set of nodes, in the case of multicast) identified in the
>    Destination Address field of the IPv6 header.

(FYI, the exception is the hop-by-hop extension header.)

I do not dispute that this sentence reached WG consensus. However, I want
to ask if it has IETF consensus. In my opinion, this sentence should read

   With one exception, extension headers are not processed, inserted,
   deleted or modified by any node along a packet's delivery path, until
   the packet reaches the node (or each of the set of nodes, in the case
   of multicast) identified in the Destination Address field of the IPv6
   header.

I believe this was always the intended meaning of the word "processed"
from the earliest design phase of IPv6, but some people have read this
text as allowing insertion, deletion or modification of headers. IMHO
it needs to be clarified.

Regards
   Brian Carpenter

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 3 Feb 2017 01:44:54 +0000

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Brian E Carpenter
 
> it needs to be clarified.

I also prefer Brian's text. Just remembering that it took a long time to reach consensus. My impression was that some people preferred to retain the ambiguity. But not me, so I vote for Brian's clarified text. One extra comma, though: "... inserted, deleted, or modified ..."

Bert

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Fri, 3 Feb 2017 08:51:22 +0000

> On Feb 3, 2017, at 1:37 AM, Brian E Carpenter <[email-masked]> wrote:
> 

are we re-spinning the debate on a WG-agreed text ? 

s.

---

From: tom p. <[email-masked]>
Date: Fri, 3 Feb 2017 11:22:58 +0000

----- Original Message -----
From: "Stefano Previdi (sprevidi)" <[email-masked]>
Sent: Friday, February 03, 2017 8:51 AM

<tp>

Yes, and I am sure that that is exactly what is intended.

Some, many perhaps, may not like it but it is the consensus of the IETF
that is sought and that trumps anything that a WG may say or do.  Not
long ago, an I-D with good WG support, more so than this one, got thrown
out by the IETF Last Call and has sunk; the traces are there but it will
never make RFC.

I also expected the challenge, on another of this set, as to whether
IPv6 is ready for Standard status; the WG discussions, which I have
tracked, convince me that it is not.

Tom Petch

s.

---

From: [email-masked]
Date: Fri, 3 Feb 2017 19:22:16 +0100

> Yes, and I am sure that that is exactly what is intended.

Then let's encourage people outside of 6man, with other points of view, and other arguments to come forward.

A re-run of the discussions already had in 6man with the same arguments and the same participants doesn't seem useful.

For a brief (sic) overview take a look at 672 messages already on the topic:
https://mailarchive.ietf.org/arch/search/?q=header+insertion&f_list=ipv6

O.

---

From: 神明達哉 <[email-masked]>
Date: Fri, 3 Feb 2017 10:48:47 -0800

At Fri, 3 Feb 2017 13:37:45 +1300,

> it needs to be clarified.

I'd also like to see if it has IETF consensus.  I've never understood
why we can't correct text when it has been misunderstood and while
(almost?) everyone agrees it's really misunderstanding according to
the intent of the author of the text.
I stated it in a bit more detail at the time of WGLC:
https://www.ietf.org/mail-archive/web/ipv6/current/msg25489.html

Brian hinted that the wg probably just got stuck about this discussion
and realistically we can only discuss it in the IETF last call:
https://www.ietf.org/mail-archive/web/ipv6/current/msg25490.html

My understanding is that that's why we're now having this thread and I
fully support and appreciate it.  I guess this also answers the
question of whether we're re-spinning it here.  In fact, in my
understanding that's exactly the point of having both WG and IETF last
calls.

As for the actual text, I support the suggested text by Brian.  I
would probably propose something slightly different myself, but I'm
fine as long as the clarity issue is resolved/improved.

--
JINMEI, Tatuya

---

From: Fernando Gont <[email-masked]>
Date: Thu, 2 Feb 2017 22:38:58 -0300

> or it can't. That's fine, and is the intended result.

If it can, it already knows the syntax, so what's the point of a uniform
syntax? -- it could be anything, and wouldn't change anything.

> but it's IMHO off topic here.

Ok. Makes sense.

Cheers,

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 4 Feb 2017 08:34:58 +1300

> are we re-spinning the debate on a WG-agreed text ? 

Yes. That's what an IETF Last Call is about.

   Brian

---

From: Pete Resnick <[email-masked]>
Date: Fri, 3 Feb 2017 13:41:34 -0600

On 3 Feb 2017, at 12:22, [email-masked] wrote:

> Then let's encourage people outside of 6man, with other points of 
> view, and other arguments to come forward.
>
> A re-run of the discussions already had in 6man with the same 
> arguments and the same participants doesn't seem useful.
>

Might I, as a relatively disinterested observer of this discussion, 
humbly[1] suggest that pointing the IETF list to a 672-message thread is 
not a way to avoid re-running the discussion "with the same arguments 
and the same participants". It would be significantly more useful if 
you, as chair and the caller of the (apparently rough) consensus 
summarized the issue, explained what you took the objection to be, and 
told us what you saw as the replies to those objections that convinced 
you that WG had properly considered the issue and that there was (rough) 
WG consensus to go with the text you ended up with. Then folks who think 
you called it wrong can explain the essential point they think you 
missed when you made that call. Having the rest of us re-create your 
evaluation of the consensus by reading 672 messages is, at best, 
inefficient.

Cheers,

pr

[1] The non-humble version includes a reference to RFC 7282, sections 2 
and 3.

-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 3 Feb 2017 22:09:33 +0000

Hi Pete,

> On Feb 3, 2017, at 2:41 PM, Pete Resnick <[email-masked]> wrote:
> 
> On 3 Feb 2017, at 12:22, [email-masked] <mailto:[email-masked]> wrote:
> 
> https://mailarchive.ietf.org/arch/search/?q=header+insertion&f_list=ipv6 <https://mailarchive.ietf.org/arch/search/?q=header+insertion&f_list=ipv6>
> O.
> 
> Might I, as a relatively disinterested observer of this discussion, humbly[1] suggest that pointing the IETF list to a 672-message thread is not a way to avoid re-running the discussion "with the same arguments and the same participants". It would be significantly more useful if you, as chair and the caller of the (apparently rough) consensus summarized the issue, explained what you took the objection to be, and told us what you saw as the replies to those objections that convinced you that WG had properly considered the issue and that there was (rough) WG consensus to go with the text you ended up with. Then folks who think you called it wrong can explain the essential point they think you missed when you made that call. Having the rest of us re-create your evaluation of the consensus by reading 672 messages is, at best, inefficient.
> 
> 

Thanks for the suggestion. Ole will be working on summarizing the WG discussion. I also want to point out the IESG statement on IETF Last Calls at https://www.ietf.org/iesg/statement/last-call-guidance.html <https://www.ietf.org/iesg/statement/last-call-guidance.html> which states

"If substantive discussion of a technical comment is needed, it is often appropriate to move that discussion to the WG list, once the comment has been made on the IETF list. "

I think the comment(s) under question fall(s) under that category. For this reason, I would like to loop the 6man WG mailing list into this discussion going forward.

Regards
Suresh

---

From: Pete Resnick <[email-masked]>
Date: Fri, 3 Feb 2017 17:07:56 -0600

On 3 Feb 2017, at 16:09, Suresh Krishnan wrote:

>> <https://mailarchive.ietf.org/arch/search/?q=header+insertion&f_list=ipv6>
>> O.
>>
>> humbly[1] suggest that pointing the IETF list to a 672-message thread 
>> is not a way to avoid re-running the discussion "with the same 
>> arguments and the same participants". It would be significantly more 
>> useful if you, as chair and the caller of the (apparently rough) 
>> consensus summarized the issue, explained what you took the objection 
>> to be, and told us what you saw as the replies to those objections 
>> that convinced you that WG had properly considered the issue and that 
>> there was (rough) WG consensus to go with the text you ended up with. 
>> Then folks who think you called it wrong can explain the essential 
>> point they think you missed when you made that call. Having the rest 
>> of us re-create your evaluation of the consensus by reading 672 
>> messages is, at best, inefficient.
>>
>>
>
> Thanks for the suggestion. Ole will be working on summarizing the WG 
> discussion.

Excellent. Thanks Ole.

> I also want to point out the IESG statement on IETF Last Calls at 
> https://www.ietf.org/iesg/statement/last-call-guidance.html 
> <https://www.ietf.org/iesg/statement/last-call-guidance.html> which 
> states
>
> "If substantive discussion of a technical comment is needed, it is 
> often appropriate to move that discussion to the WG list, once the 
> comment has been made on the IETF list. "
>
> I think the comment(s) under question fall(s) under that category. For 
> this reason, I would like to loop the 6man WG mailing list into this 
> discussion going forward.

If it's a *new* substantive technical comment, I absolutely agree, that 
should go back to the WG list. However, if this is an old topic that the 
WG has already come to a conclusion on, bringing it back to the list is 
not useful unless something has changed; that just becomes a "pile on" 
session. That's why I suggested Ole summarize the issue first, and that 
should be copied to the IETF list. That way we can see whether the issue 
is "The WG missed this important aspect of the issue" (which should go 
back to the WG to discuss once it's properly formulated) or "The chair 
misevaluated the consensus" (which should probably be handled by you and 
the chair). Either way, we agree that a protracted rehash of the topic 
on the IETF list is not the right choice.

pr

---

From: [email-masked]
Date: Sat, 4 Feb 2017 09:32:37 +0100

Thank you Pete! You are of course right.

Let me try to provide some background of the issue.

The contentious text is the following paragraph from 2460:

  With one exception, extension headers are not examined or processed
  by any node along a packet's delivery path, until the packet reaches
  the node (or each of the set of nodes, in the case of multicast)
  identified in the Destination Address field of the IPv6 header.

Essentially the question is:
- Does the IPv6 architecture permit insertion of extension headers and/or header options by a node along the packet's delivery path?

This question came up triggered by discussions around some recent proposals:
- draft-ietf-conex-destopt,
- RFC4782 (does header deletion)
- draft-ietf-6man-segment-routing-header
- draft-brockners-inband-oam-transport

The IP architecture (IPv4 and IPv6) supports _modifying_ IP options in flight, but it is unclear if it could permit changing the IP datagram's size.
Increasing a packets size in flight would break PMTUD (RFC1981), AH, and might results in other ICMP error messages being sent to an unsuspecting source.

There were three main positions argued in the working group.

1) Ban header insertion outright.
2) Describe the problems with header insertion.
3) No changes to RFC2460 text.

Permitting header insertion in the sense of specifying how header insertion could possibly work is of course outside the scope of advancing RFC2460.

The chairs tried various approaches to find a consensus without luck. The approach finally chosen was a poll between the three options. And the (rough) consensus was based on the data from the poll.

Excerpt from the shepherds writeup:

A working group last call for moving this and the other two documents to Internet Standard was started on 30 May 2016. Reviews were also requested. Issues found during the last call and reviews were entered into the 6MAN ticket system. These are now closed. The biggest issue raised was how to handle the issue of Extension Header insertion in this document. After many discussion on the mailing list and face to face meeting, there wasn’t a clear consensus. The chairs conducted an online survey that provided three choices: Ban header insertion, describe the problems with header insertion, or say nothing. The result of the survey was to describe the solution. The results and methodology used to evaluate the results can be seen at: https://mailarchive.ietf.org/arch/msg/ipv6/_gG2foiugk5B7w3TpnPvBbjHDzs This was discussed at the 6MAN session at IETF97 and on the mailing list after the meeting. The chairs believe there is a consensus to go forward with the text that is in draft-ietf-6man-rfc2460bis-08.

The summary given to the working group calling for the poll:
https://mailarchive.ietf.org/arch/msg/ipv6/AtY92TpJ3vvmiidzcPkJdXKZQIA/?qid=84de5e109c8f8f255d03c4c98ff3e50c

Best regards,
Ole, 6man co-chair

---

From: Fernando Gont <[email-masked]>
Date: Sat, 4 Feb 2017 06:04:46 -0300

On 02/04/2017 05:32 AM, [email-masked] wrote:
> Essentially the question is: - Does the IPv6 architecture permit
> insertion of extension headers and/or header options by a node along
> the packet's delivery path?
> 
> This question came up triggered by discussions around some recent
> proposals: - draft-ietf-conex-destopt, - RFC4782 (does header
> deletion) - draft-ietf-6man-segment-routing-header -
> draft-brockners-inband-oam-transport
> 
> The IP architecture (IPv4 and IPv6) supports _modifying_ IP options
> in flight, but it is unclear if it could permit changing the IP
> datagram's size. 

The only case that can be made for that is that the spec doesn't say
"insertion of EHs is forbidden" -- but then, if you were to have to
write a spec explicitly noting everything that is forbidden, you
wouldn't be able to achive that in your lifetime.

Everyone has agreed (including the authors of RFC2460) that EH insertion
has never been allowed.

> Increasing a packets size in flight would break
> PMTUD (RFC1981), AH, and might results in other ICMP error messages
> being sent to an unsuspecting source.
> 
> 1) Ban header insertion outright. 2) Describe the problems with
> header insertion. 3) No changes to RFC2460 text.
> 
> Permitting header insertion in the sense of specifying how header
> insertion could possibly work is of course outside the scope of
> advancing RFC2460.

Explicitly allowing EH insertion would most likely be out of scope, too:
It completely changes a very basic aspect of IPv6.

FWIW, I think that publishing a spec with what some have considered to
be ambiguous text (subsequently leading to 600+ messages on the very
group that specifies the protocol) would be a lousy job on our side.
Either explicitly ban extension header insertion, or explicitly allow it.

Whether EH insertion is allowed (or not) seems to me like a very basic
question that the protocol spec should be able to answer -- particularly
since we're moving it to Standard.

Given that the question has been "raised", it deserves an answer in the
spec. Otherwise, when asked "Are intermediate systems allowed to mangle
with IPv6 packets as they please?", I guess we'd have to answer "We
don't know... but neither did the group that wrote the spec".

Thanks,

---

From: tom p. <[email-masked]>
Date: Sat, 4 Feb 2017 12:48:15 +0000

I do not know how to make it happen but I would like to see considered
opinions on this rather important issue from those I see active on lists
such as tcpm, arch-d and intarea whom I do not see active on v6(ops).

Tom Petch

----- Original Message -----
From: <[email-masked]>
To: "Pete Resnick" <[email-masked]>
Cc: "tom p." <[email-masked]>; <[email-masked]>;
<[email-masked]>; "Stefano Previdi"
<[email-masked]>; <[email-masked]>
Sent: Saturday, February 04, 2017 8:32 AM
Subject: Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet
Protocol, Version 6 (IPv6) Specification) to Internet Standard

Essentially the question is:
- Does the IPv6 architecture permit insertion of extension headers
and/or header options by a node along the packet's delivery path?

proposals:

The IP architecture (IPv4 and IPv6) supports _modifying_ IP options in
flight, but it is unclear if it could permit changing the IP datagram's
size.
Increasing a packets size in flight would break PMTUD (RFC1981), AH, and
might results in other ICMP error messages being sent to an unsuspecting
source.

The chairs tried various approaches to find a consensus without luck.
The approach finally chosen was a poll between the three options. And
the (rough) consensus was based on the data from the poll.

A working group last call for moving this and the other two documents to
Internet Standard was started on 30 May 2016. Reviews were also
requested. Issues found during the last call and reviews were entered
into the 6MAN ticket system. These are now closed. The biggest issue
raised was how to handle the issue of Extension Header insertion in this
document. After many discussion on the mailing list and face to face
meeting, there wasn’t a clear consensus. The chairs conducted an online
survey that provided three choices: Ban header insertion, describe the
problems with header insertion, or say nothing. The result of the survey
was to describe the solution. The results and methodology used to
evaluate the results can be seen at:
https://mailarchive.ietf.org/arch/msg/ipv6/_gG2foiugk5B7w3TpnPvBbjHDzs
This was discussed at the 6MAN session at IETF97 and on the mailing list
after the meeting. The chairs believe there is a consensus to go forward
with the text that is in draft-ietf-6man-rfc2460bis-08.

The summary given to the working group calling for the poll:
https://mailarchive.ietf.org/arch/msg/ipv6/AtY92TpJ3vvmiidzcPkJdXKZQIA/?
qid=84de5e109c8f8f255d03c4c98ff3e50c

Best regards,
Ole, 6man co-chair

---

From: Enno Rey <[email-masked]>
Date: Sat, 4 Feb 2017 20:06:35 +0100

Hi,

On Sat, Feb 04, 2017 at 09:32:37AM +0100, Fernando Gont wrote:

> [...]

The first talk I gave about IPv6 was in 1999 (with an experimental IPv6 stack of Windows NT and being connected to the 6Bone). I don't remember much of it but I'm pretty sure I explained that the desire to restore the pre-middlebox, pre-NAT end-to-end character of the Internet was one of the main design drivers of IPv6 (hint: you may also look at the "Acknowledgments" section of RFC 2460).
Quite a few IPv6 books of the time (we still have them in the library, feel free to reach out for examples) explicitly mentioned end-to-end as a major property of IPv6 and many guys giving IPv6 talks & trainings since 15+ years now have it on their introductory slides. Furthermore several adjustments of the main IPv6 header (e.g. removing the checksum) and barring fragmentation performed by intermediate points clearly indicate the message: "in general we don't want devices to mangle with packets in transit".
So, from my personal perspective, it's painfully obvious that there was never any intent to allow the modification of IPv6 packets in transit (besides very specific exceptions which were clearly described), and this has been an undisputed principle of IPv6 for a long time.

So one may be tempted to ask: why do we have this discussion at all?
Well I think the answer is quite simple: as so often in life, it's about agendas and politics. Before I comment on this in a bit more detail, let me add two disclaimers:

Disclaimer (1): in the following rant on how certain things are happening at the IETF I can only speak for IPv6-related stuff. 
Disclaimer (2): addressing such a rant in direct to an IETF mailing list means I will tap on the feet of many people. Feel free to personally let me know your strong opinion or just ignore me/stare into another direction from now on when we meet. There's only a small chance this will happen at an IETF meeting anyway, for reasons laid out below. 

Let's look at how the actual discussion (and subsequent specification) work is done at the IETF, similar to other voluntary organizations: on mailing lists and in (f2f) meetings. As we all know, these meetings take place three times a year, each on a different continent (yes, I'm aware of remote participation, but let's be honest: at the end of the day how much impact on specification did this have this in past, in particular in heavily old boys' clubs dominated WGs like 6man?).

Further fact is: if you look at the lists of participants of the meetings, the vast majority of it is vendor personnel. This is not surprising when reflecting on the incentives different parties may have to send people to IETF meetings. How would, say, an enterprise person argue in front of her boss to attend the 51st (!) IETF meeting since the publication of RFC 2460 (especially considerung the ongoing [non-]state of deployment in large parts of that space. it's up to the reader to connect that state with the things I describe here...)?

But it's not like vendor people don't have to justify these nice trips to their bosses. Of course they have to. 
Here's two prevalent strategies:
- "we have that new feature. let's try to push it into an RFC, as this strengthens our market position (in general and for selling the specific thing)"
- "you know, there's this future thing called IPv6. I'm in one of the working groups where we come up with lots of creative ideas how to even make it better. my name is on one of the draft documents so I'll have to be there, at the next meeting (and we, as a vendor, demonstrated our contribution also)".

For quite some of the stakeholders (namely both the vendor in question and the respective participant[s]) these are not only legitimate but fully understandable. It's just: does this drive things in the right direction of the greater good & community? Me seems we have a classic tragedy of the commons here...

I'm in the very privileged position that my employer would (and did so several times in the past) actually pay for week-long trips to nice cities and expensive hotels (and release me from other tasks contributing to short-term productivity, let alone revenue) three times per year. Still I do know many people *very* unhappy with the current state of IPv6 specs - and scratching their heads in light of the present discussion - who are not.
We/you guys don't have to care about the esteem of IPv6 community (at least the part I myself can speak for) and you might even feel obliged to ignore it ("we know better what's good for them").
But we should at least be honest as for the obvious agenda quite some vendor guys are pushing as for EH insertion (I don't have to mention SR, do I?) and you Ole, as a 6man chair, have probably noticed that there's not much support for the idea from anybody outside Cisco space (yes, I'm aware of the poll. but I followed the mailing list discussions as well).

There you have it. I don't even think that this was anything new for most of you. Still at times it helps to name the obvious.
If any socio anthropologist wanted to find a textbook example for "how voluntary bodies claiming to be open for anyone get compromised over time by vested interests" the EH insertion thing would be one.

best

Enno

For the protocol: given the fundamental role of RFC 2460 I, too, think that an implementor must be able to get a clear answer to the question "is EH insertion allowed or not?" during its lecture, without going through 600+ e-mails in an archive (just to find out that "even the experts didn't agree on that, at the time"). So I support Fernando's request of 

-- 
Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Enno Rey

=======================================================
Blog: www.insinuator.net || Conference: www.troopers.de
Twitter: @Enno_Insinuator
=======================================================

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 5 Feb 2017 08:22:44 +1300

Hi Enno,

On 05/02/2017 08:06, Enno Rey wrote:
...
> Still I do know many people *very* unhappy with the current state of IPv6 specs...

Where do I find their analysis and proposed changes?

    Brian

---

From: Enno Rey <[email-masked]>
Date: Sat, 4 Feb 2017 20:33:59 +0100

Hi Brian,

> Where do I find their analysis and proposed changes?

the very fact that draft-ietf-v6ops-dhcpv6-slaac-problem created a 100+ messages thread over the last few weeks in v6ops might serve as an indication (and in that thread statements very similar to mine have been voiced, btw).
You might reject the following statement as similarly broad and unjust: many guys with a genuine interest in driving IPv6 (and being involved on a daily basis) have been repelled by what's happening in 6man and v6ops in the last yrs and have subsequently lost any interest in contributing. 
which creates the exact loop your question is directed to.

happy to discuss in more detail over a beer at RIPE74.

best

Enno

-- 
Enno Rey

---

From: John Leslie <[email-masked]>
Date: Sat, 4 Feb 2017 17:38:48 -0500

> such as tcpm, arch-d and intarea whom I do not see active on v6(ops).

   Disclaimer: I was quite inactive in IETF stuff until about ten years
ago. (How time flies when you're having fun!)

   When I resumed activity, it became obvious to me that IPv6 had quite
a number of flaws that some folks were trying to fix, unsuccesssfully.
It was even more obvious that IPv6 _couldn't_ see enough deployment
until it settled down. Thus, I joined the group encouraging settling
down.

   I have since realized that the flaws were more serious than I had
realized; and that _only_ exhaustion of IPv4 address space could incent
widespread deployment.

   IPv4 space _is_ exhausted; IPv6 deployment _is_ happening... But
we're seeing two Internets: one IPv4, and another IPv6.

   This, of course was always the most significant flaw: no smooth
transition path. I didn't know how to fix it then; and I still don't
know how today. But of course, a "fix" _is_ being deployed: and that
is middleboxes.

   Perhaps the most glaring disconnect today about IPv6 is the folks
who insist it will cure us of middleboxes. Alas! many of us are too
polite to laugh out loud.

   As to the header-insertion question: IMHO middleboxes will never
disappear (nor come under protocol control); and some of them _will_
insert headers. We _can_ certainly ignore this in our protocol design:
the middleboxes in question will be happy to return the favor.

   This is a perfectly legitimate way to proceed -- and it is certainly
better than trying to adapt IPv6 to every middlebox out there today.

   Is there a practical alternative?

   I like to imagine a WG studying what it is that each middlebox
accomplishes in the view of the folks deploying it; then come up with
a better way to do that through a standardized protocol. (Only then
can we discuss how to squeeze that into IPv6.)

   I've decided to act as if I don't have a horse in this race...

   (One particularly silly flaw is that we allow _most_ nodes to
have a hard limit of 1500 bytes per packet: requiring IPv6 nodes to
handle packets ten times that limit would help a lot!)

   Sorry I can't be more helpful!

--
John Leslie <[email-masked]>

---

From: Mark Smith <[email-masked]>
Date: Sun, 5 Feb 2017 13:06:40 +1100

On 5 February 2017 at 06:06, Enno Rey <[email-masked]> wrote:
> Well I think the answer is quite simple: as so often in life, it's about agendas and politics.

I think it is much simpler than that.

People have put quite a lot of work into EH insertion and they don't
want to throw it away. That is entirely understandable, however the
specification is clear.

"With one exception, extension headers are not examined or processed
   by any node along a packet's delivery path, until the packet reaches
   the node (or each of the set of nodes, in the case of multicast)
   identified in the Destination Address field of the IPv6 header."

"The exception referred to in the preceding paragraph is the Hop-by-
   Hop Options header, which carries information that must be examined
   and processed by every node along a packet's delivery path, including
   the source and destination nodes.  The Hop-by-Hop Options header,
   when present, must immediately follow the IPv6 header."

The only modifications of an IPv6 packet in flight allowed are:

- decrement the Hop Limit
- change the Traffic Class
- change the Flow Label if the value is zero
- Hop-by-Hop EH processing.

In none of these cases is new information added to the packet,
changing the size of the packet. In all of these the negative
consequences of a failed update are the packet gets dropped, gets
lower priority per-hop handling, or is delivered to the incorrect
destination. These types of failures do not conflict with any
semantics that other protocols rely on, specifically that the source
address identifies the originator of the entire structure and initial
contents of the packet, with the possible and permitted in-flight
changes in packet contents values being explicitly identified in
RFC2460 and published updates to it.

Claiming the spec is ambiguous is trying to create a loophole that
permits the violation of the specification. That is probably viewed as
having lower cost, if successful, than redoing the work to use
encapsulation to add information to packet while also preserving the
packet's original semantics.

I think claiming "not examined or processed by any node along a
packet's delivery path" is ambiguous is pretending to know less about
something than one really does.

Regards,
Mark.

---

From: Randy Bush <[email-masked]>
Date: Sun, 05 Feb 2017 14:04:33 +0900

> realized; and that _only_ exhaustion of IPv4 address space could incent

it will also take the destruction of nats, and that ain't gonna happen.

we shot ourselves in the foot and now we're left with shooting the
messengers.

randy

---

From: Sander Steffann <[email-masked]>
Date: Sun, 5 Feb 2017 10:42:49 +0100

Hi Enno,

>> Either explicitly ban extension header insertion, or explicitly allow it.

+1

Personally I think middleboxes should not insert or remove extensions headers. But whatever happens, it should be explicitly stated.

Cheers,
Sander

---

From: Greg Skinner <[email-masked]>
Date: Sun, 05 Feb 2017 17:59:58 -0800

> we shot ourselves in the foot and now we're left with shooting the

Tussle in Cyberspace: Defining Tomorrow’s Internet

https://groups.csail.mit.edu/ana/Publications/PubPDFs/Tussle%20in%20Cyberspace%20Defining%20Tomorrows%20Internet%202005's%20Internet.pdf

---

From: Joe Touch <[email-masked]>
Date: Tue, 7 Feb 2017 11:07:42 -0800

Hi, all,

Can anyone give those of us not tracking 672 messages a brief summary?

IMO, without diving into that thread deeply, I agree with the new

>    of multicast) identified in the Destination Address field of the IPv6
In fact, I'd go further to say that that non-HBH EHs should not even be
*viewed* or used as context by intermediate nodes.

And any limits on what can be done with HBH EHs should be stated
explicitly. I'd be glad if at least the EH lengths didn't change.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 7 Feb 2017 11:13:00 -0800

> handle packets ten times that limit would help a lot!)

Given we have no way to signal that an *endpoint* can do better, what's
the point?

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 7 Feb 2017 11:31:03 -0800

Hi, all,

I suppose I'm in the group below.

IMO:

    - the IPv6 base header and HBH EHs are the only ones that
intermediate nodes should even *look* at

    - everything else should be prohibited

    - there's little point in talking about middlebox behavior at all
until we have compliance verification in place

One other observation:

    - frag processing doesn't say what to do with an exact overlap that
isn't a exact duplicate (e.g., when the content differs). AFAICT, that
should be treated the same as an overlapping fragment - i.e., only
*exact* duplicates should be (optional, as already noted) silent
discards (but this does then create a potential DOS vector because of
the additional processing for dup frags - and that should be noted).

AFAICT, the only way a "middlebox" can legitimately get away doing more
than above is when it can claim it is doing so on behalf of an endpoint,
i.e., to claim that the endpoint services are distributed upstream. IMO,
that argument is OK for devices under the same control as the endpoint,
but not otherwise. However, that's all just a philosophical argument
without compliance verification anyway.

Joe

---

From: [email-masked]
Date: Tue, 7 Feb 2017 20:38:15 +0100

Joe,

> IMO, without diving into that thread deeply, I agree with the new proposed text below from Brian:

Posted to list on Satuday.
https://mailarchive.ietf.org/arch/msg/ietf/MJexpTisUTSN2XrkkYVVLPJrjFM/?qid=8e4597241d656835af9f01439581f375

> In fact, I'd go further to say that that non-HBH EHs should not even be *viewed* or used as context by intermediate nodes.
> 
> And any limits on what can be done with HBH EHs should be stated explicitly. I'd be glad if at least the EH lengths didn't change.

The original intent of the IPv6 design was certainly that. Routers should have no need to look beyond the first 40 byte header (with one exception) and everything else was end to end encrypted so there wouldn't be any purpose looking there anyway.

We might get into trouble with the implementation report.
If anyone knows of any implementation, software or hardware that is compliant with that, I'd certainly like to know. :-)

Best regards,
Ole

---

From: Joe Touch <[email-masked]>
Date: Tue, 7 Feb 2017 11:46:15 -0800

Thanks.

FWIW, AFAICT inserting headers on the fly also breaks PLPMTUD too
(though PLPMTUD will eventually recover).

Joe

---

From: Pete Resnick <[email-masked]>
Date: Tue, 7 Feb 2017 15:25:17 -0600

Ole,

After reading the replies, I wonder if you could amend your summary with 
one point in particular:

> 3) No changes to RFC2460 text.

What did you see as the objections to going with (1) (which I presume to 
be the equivalent of Brian's proposed text)? Why was it that people 
thought the protocol could not be clarified to say that? And was your 
assessment that those arguments were correct, or that they simply were 
not addressed by the WG? I've seen several people argue on this list 
that (1) was always the intent of the protocol, and that damage occurs 
if you don't follow that directive. I haven't seen anyone here argue 
otherwise. Could you summarize?

pr

---

From: Fernando Gont <[email-masked]>
Date: Tue, 7 Feb 2017 21:48:03 -0300

On 02/07/2017 06:25 PM, Pete Resnick wrote:
> On 4 Feb 2017, at 2:32, [email-masked]
> <mailto:[email-masked]> wrote:
> 
> thought the protocol could not be clarified to say that?

Because if we did, the loophole for people to violate the standard would
disappear (talk about Segment Routing).

Thanks,

---

From: [email-masked]
Date: Wed, 8 Feb 2017 14:51:52 +0100

Pete,

> After reading the replies, I wonder if you could amend your summary with one point in particular:
> 
> What did you see as the objections to going with (1) (which I presume to be the equivalent of Brian's proposed text)? Why was it that people thought the protocol could not be clarified to say that? And was your assessment that those arguments were correct, or that they simply were not addressed by the WG? I've seen several people argue on this list that (1) was always the intent of the protocol, and that damage occurs if you don't follow that directive. I haven't seen anyone here argue otherwise. Could you summarize?

I can try. It has been difficult to distill the essence out of all the mailing list discussions.
This is _my_ take of the discussion and arguments as I understood them. Please chime in with corrections.

The arguments of what would break are correct. The counter-arguments given would be that this is done within a controlled domain and the potential for damage could be controlled.

The discussion went something like (paraphrasing):

 - Inserting headers will break Path MTU discovery, AH and may result in unsuspecting hosts receiving ICMP error messages.
 - We will do this in a controlled domain only.
 - Even if you can guarantee it will not leak, it is not appropriate to specify that in the core IPv6 specification
 - We don't need that, we just need 2460 not to ban it. IPv6 is used in many networks not only the capital I Internet.

There was also quite a bit of discussion on the intent of the original authors. I don't know how much value it is correct to give that argument. "This is what I intended, but not what I wrote...". Given that this is in any case the output of the IETF and not two individual authors.

Objections:
a)  There are proposals wanting to insert headers:
   - draft-ietf-6man-segment-routing-header
   - draft-brockners-inband-oam-transport
   - Just now: draft-francois-dots-ipv6-signal-option-01

i) Out of scope: Argue the point of header insertion or alternatives in the context of those proposals, not in the context of the core IPv6 specification. Do not try to make a preemptive strike in the core specification.

ii) Use encapsulation alternative has problems. In e.g. inband-oam some meta-data is attached to a packet on ingress into a domain and removed at egress of the domain. The ingress doesn't necessarily know the egress, normal destination routing is supposed to happen. That is hard to achieve with a encapsulation solution.

iii) Use encapsulation alternative has problems 2. A packet with extension headers would be processed normally by an unmodified end host,
while an encapsulated packet would not.

b) RFC2460 is already clear and no clarification is needed. No interoperability issue has been shown caused by this perceived ambiguity.

Objections:
a) The list of problems with header insertion can never be complete. It might be misconstrued as the only set of problems required to be solved to allow header insertion.

b) Speculating about something we don't know how to do (header insertion) is not appropriate when bringing the specification to internet standard.

c) Leaves the ambiguity in place.

Objections:
a) Leaves the ambiguity in place.

There was hard to find consensus on either of the alternatives. As the poll shows there was a clear preference (if people couldn't get their first choice) to describe the problem, over banning it, or over saying nothing.

Best regards,
Ole

---

From: [email-masked]
Date: Wed, 8 Feb 2017 14:55:30 +0100

Fernando,

> disappear (talk about Segment Routing).

There is nothing stopping a future IETF from publishing a document specifying header insertion, even if 2460bis where to ban it.

Best regards,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Wed, 8 Feb 2017 11:10:01 -0300

On 02/08/2017 10:55 AM, [email-masked] wrote:
> Fernando,
> 
>> Because if we did, the loophole for people to violate the standard
>> would disappear (talk about Segment Routing).
> 
> There is nothing stopping a future IETF from publishing a document
> specifying header insertion, even if 2460bis where to ban it.

There's a "small" difference: If the standard clearly states that header
insertion is forbidden, then, a proposal to insert EHs would need to
update the corresponding standard.

Since RFC2460 is being moved to (full) Standard, that would not be minor.

I guess we all know what, and why we even got to rather ridiculous
arguments of the form "we can do EH insertion because RFC2460 does not
prohibit it"   (well, yes, :-)  RFC2460 does not prohibit that upon
receipt of an IPv6 packet, a router drops the IPv6 packet, and forwards
a TCP packet instead... )

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 8 Feb 2017 11:25:25 -0300

On 02/08/2017 10:51 AM, [email-masked] wrote:
>> What did you see as the objections to going with (1) (which I
>> presume to be the equivalent of Brian's proposed text)? Why was it
>> that people thought the protocol could not be clarified to say
>> that? And was your assessment that those arguments were correct, or
>> that they simply were not addressed by the WG? I've seen several
>> people argue on this list that (1) was always the intent of the
>> protocol, and that damage occurs if you don't follow that
>> directive. I haven't seen anyone here argue otherwise. Could you
>> summarize?
> 
> I can try. It has been difficult to distill the essence out of all
> the mailing list discussions. This is _my_ take of the discussion and
> arguments as I understood them. Please chime in with corrections.
> 
> The arguments of what would break are correct. The counter-arguments
> given would be that this is done within a controlled domain and the
> potential for damage could be controlled.

There need not be "counter arguments". It was clear to everyone that
IPv6 never allowed EH insertion. If you want to change that, you have to
update RFC2460 (and if you do it before rfc2460bis is published, good
luck with moving it to Standard).

OTOH, if the argument is that you want to break a protocol in your own
environment, in which you can "control the damage"... why do you need an
RFC for that? why should we rubberstamp it?

> - Inserting headers will break Path MTU discovery, AH and may result

You miss the most important point: EH insertion was never allowed in
IPv6.  Quite a lot of us find the argument that "we're doing EH
insertion because RFC2460 doesn't explicitly prohibit *insertion*" quite
funny.

I'm not against EH-insertion per se. I'm against what looks like a
procedural hack.

If people want EH insertion, fine: write a proposal that updates
RFC2460, and let's have the discussion. But please do not pretend that
RFC2460 allows EH insertion.

> in unsuspecting hosts receiving ICMP error messages. - We will do
> this in a controlled domain only. - Even if you can guarantee it will
> not leak, it is not appropriate to specify that in the core IPv6
> specification - We don't need that, we just need 2460 not to ban it.
> IPv6 is used in many networks not only the capital I Internet.
> 
> There was also quite a bit of discussion on the intent of the
> original authors. I don't know how much value it is correct to give
> that argument. "This is what I intended, but not what I wrote...".
> Given that this is in any case the output of the IETF and not two
> individual authors.
> 
[...]
> 
> b) RFC2460 is already clear and no clarification is needed. No
> interoperability issue has been shown caused by this perceived
> ambiguity.

RFC2460 already bans EH insertion. Only when SR wa published people
started to argue otherwise.

Given that for some guys there was room for EH insertion, we clearly
need to make the point clear.

> There was hard to find consensus on either of the alternatives. As
> the poll shows there was a clear preference (if people couldn't get
> their first choice) to describe the problem, over banning it, or over
> saying nothing.

Based on the mailing-list discussion, it was quite clear that most of
the folks arguing in favor of "ambiguity" were from the same company
pushing a proposal with EH insertion. That's not a minor datapoint.

Besides, moving a document to Standard with "ambiguity" on an item that
led to 600+ messages discussion at the same group that specifies the
protocol would be really bad.

We're moving RFC2460 to standard. I think it should be able to answer
the very basic question "Is it possible to insert EHs in the middle of
the network?"  -- or, framed in a different way: "is IPv6 and end-to-end
protocol?"

Thanks,

---

From: [email-masked]
Date: Thu, 9 Feb 2017 11:36:50 +0100

Fernando,

Pete asked me to summarize the objections to option 1 - banning header insertion explicitly.
I responded with the set of objections I've heard for all options, as I couldn't see a straightforward way of only summarising for option 1.

I don't understand your message.
Do you disagree with the summary itself? Are there arguments missing?
Or is your grief that the I have distilled the arguments wrongly or put them in a bad light?

Or are you just rehashing your position on the issue?

cheers,
Ole

> On 8 Feb 2017, at 15:25, Fernando Gont <[email-masked]> wrote:
>

---

From: Fernando Gont <[email-masked]>
Date: Thu, 9 Feb 2017 18:30:11 -0300

> Or are you just rehashing your position on the issue?

I think that some points are not as clear as they should be:

1) The current state of affairs with respect to IPv6 EH insertion is
that insertion is forbidden. It has always been clear to everyone.

2) However, some folks came up with proposals to insert EH, on the basis
that "RFC2460 does not explicitly ban EH insertion". If there's people
arguing that, we clearly need to make this clear in the spec.

3) There was a consensus call, yes. When the call was made on the
mailing-list, the vast majority of supporters of "let's keep the
ambiguity" were folks from the same company as "2)". I have no idea if
this changes (or not) "consensus"... but this is clearly an important
datapoint.

4) Given "1)" and "2)" above, it should be evident that the spec needs
to be crystal-clear on this topic.

5) Arguing in favor of keeping ambiguity in a spec that has generated
600+ messages in the very group that standardizes the protocol pretty
much reads like "Let's publish a lousy spec!". And I think that would be
very bad. We're talking about something that is at the core of the
protocol, essentially "Is IPv6 an end-to-end protocol?". I would expect
rfc2460bis to answer such a very basic question, and I'm curious how we
could move a spec to (full) Standard without answering such a basic
question.

There's no grief at all. If anything, just a concern that some of these
items might not be clear enough, and, in particular that without the
datapoint in "3)", folks might get a misleading interpretation of the
discussions that happened in th wg. "3" could be read pretty much like
"all folks from the same company that has a proposal to insert EHs what
insertion of EHs to be allowed".

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Feb 2017 11:55:26 +1300

Hi Fernando,

First let me say that I though Ole's summary was fair. One comment below:

> that insertion is forbidden. It has always been clear to everyone.

I don't think it has. In fact, that's the whole point: some people
have *not* deduced that rule from the RFC2460/RFC1883 wording.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Thu, 9 Feb 2017 20:17:05 -0300

> have *not* deduced that rule from the RFC2460/RFC1883 wording.

"It has always been clear.... till these proposals on EH insertion arised".

Since some people didn't "deduce" it from the current text, that's a
clear indication that a clarification is warranted.

Thanks,

---

From: [email-masked]
Date: Fri, 10 Feb 2017 00:36:54 +0100

Fernando,

> clear indication that a clarification is warranted.

You can now optimize this discussion without having to bother the whole IETF list. Just look up the counter arguments in the previously posted summary.

E.g. the response to your argument in this email:
1.a.i) Out of scope: Argue the point of header insertion or alternatives in the context of those proposals, not in the context of the core IPv6 specification. Do not try to make a preemptive strike in the core specification.

Only partly tongue in cheek.
O.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 9 Feb 2017 21:29:25 -0300

On 02/09/2017 08:36 PM, [email-masked] wrote:
>>> I don't think it has. In fact, that's the whole point: some
>>> people have *not* deduced that rule from the RFC2460/RFC1883
>>> wording.
>> 
>> Since some people didn't "deduce" it from the current text, that's
>> a clear indication that a clarification is warranted.
> 
> You can now optimize this discussion without having to bother the
> whole IETF list. Just look up the counter arguments in the previously
> posted summary.

We're moving RFC2460 to full Standard. You have to make arguments to
*change* the spec, not to clarify what's already in there -- for
instance, ne would expect that part of the benefit of the process is to
clarify the spec where necessary.

If you can make enough of a case to enable EH insertion, then propose
that as what it actually is: a *modification* to the spec.

If we move RFC2460 to full Std without even being able to tell people
whether this is an end-to-end protocol or not, I think that would be a
*very* bad outcome.

Me, I'm done with this discussion. A number of us (Enno Rey, Mark Smith,
and others) have commented on our view on the topic (for IETF folks that
didn't participate in the 6man discussions).

Cheers,

---

From: Philip Homburg <[email-masked]>
Date: Fri, 10 Feb 2017 12:29:00 +0100

>1.a.i) Out of scope: Argue the point of header insertion or alternatives 
>in the context of those proposals, not in the context of the core IPv6 
>specification. Do not try to make a preemptive strike in the core 
>specification.

Quoting from this draft (Section 4):
"With one exception, extension headers are not processed by any node
"along a packet's delivery path

"Hop Options header

I guess somebody has to come up with a creative interpretation of this 
text that allows segment routing headers to be removed along the way.

---

From: 神明達哉 <[email-masked]>
Date: Fri, 10 Feb 2017 10:22:52 -0800

At Thu, 9 Feb 2017 18:30:11 -0300,
Fernando Gont <[email-masked]> wrote:

While I largely agree with Fernando on everything he said, I have to
admit most of the points are just repeated from the 6man discussion,
and won't get us anywhere new by discussing these again at this point.

> this changes (or not) "consensus"... but this is clearly an important

Although I don't want to point a finger at particular people or
organizations without an evidence, I guess not a small number of 6man
participants (not only those who explicitly spoke up here) suspected
that the decision process was biased with the influence of a large and
powerful organization and the process and resulting "consensus" was
not really a fair one.  And I'm not an exception to it - in fact, it
was so unbelievable to me that we can't clarify an ambiguity even when
we were also open for future extensions, that I couldn't think of
other reasons than a company agenda.

Of course, it's quite possible that it was just a coincidence that
many people with the same organization genuinely thought we should
leave it ambiguous while many others strongly thought we should
clarify it but few (if not no) people from that organization supported
the clarification.  But I don't think we can prove it either way.

But as Fernando said, I believe this point (and that several, and
arguably more, participants suspected it) should be included in making
the decision at the IESG and at the IETF last call.  And, whatever the
decision, it would be more productive to move on after that and use
our time for some other things.

I'll shut up here on this so I won't be a cause of another 600+ email
thread.

--
JINMEI, Tatuya

---

From: Randy Bush <[email-masked]>
Date: Sat, 11 Feb 2017 10:02:30 +0900

> and won't get us anywhere new by discussing these again at this point.

excuse?  this is why we have ietf last call.

randy

---

From: Ted Lemon <[email-masked]>
Date: Fri, 10 Feb 2017 20:12:28 -0500

> excuse?  this is why we have ietf last call.

No, we do not have IETF last call so that people who participated in the working group discussion can re-litigate the points they lost on in the working group discussion.

---

From: Randy Bush <[email-masked]>
Date: Sat, 11 Feb 2017 10:17:49 +0900

> No, we do not have IETF last call so that people who participated in
> the working group discussion can re-litigate the points they lost on
> in the working group discussion.

cite?

and those of us who gave up on 6stonewall years ago appreciate a more
open discussion on the ietf list, tyvm.

randy

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 Feb 2017 14:32:41 +1300

> No, we do not have IETF last call so that people who participated in the working group discussion can re-litigate the points they lost on in the working group discussion.

I was fairly specific when I raised the issue at
https://mailarchive.ietf.org/arch/msg/ietf/myyPO9b4dYfYeGQrdPjTNzIHArY

>> to ask if it has IETF consensus.

If people who were not involved in the 6man debate have opinions, it would
be useful to hear from them. I agree that there is no point in the same
people repeating the same arguments.

     Brian

---

From: Scott Bradner <[email-masked]>
Date: Fri, 10 Feb 2017 21:02:56 -0500

kinda a cynical view

Scott

> On Feb 10, 2017, at 8:12 PM, Ted Lemon <[email-masked]> wrote:
>

---

From: Randy Bush <[email-masked]>
Date: Sat, 11 Feb 2017 11:23:31 +0900

> If people who were not involved in the 6man debate have opinions, it
> would be useful to hear from them. I agree that there is no point in
> the same people repeating the same arguments.

in the absence of a (somewhat unbiased) summary of the critical
issues(s), what do you suggest?

randy

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 Feb 2017 16:10:49 +1300

> issues(s), what do you suggest?

I was going to say this off list, but what the heck?

To be honest I'm trying to stay quiet. I think I've made my opinion
plain, and although I am of course the only human being alive who doesn't
suffer from confirmation bias, I'd *really* like to hear what people
think whose opinion I haven't already heard 20 times.

I try not to be a purist. If the right answer is to allow packet
modifications that break PMTUD and IPsec/AH, let's do it, but let's
also say we're doing it. (I happen to think it's the wrong answer,
but that's my problem.) Leaving the text open to interpretation
would make a mockery of promoting it to Standard.

Regards
   Brian

---

From: Randy Bush <[email-masked]>
Date: Sat, 11 Feb 2017 12:23:10 +0900

just to get down a level from meta-

> If the right answer is to allow packet modifications that break PMTUD
> and IPsec/AH, let's do it, but let's also say we're doing it.

obvious imiho

> I happen to think it's the wrong answer, but that's my problem.

i share it, but this is at the border of my expertise.  i have this
fantasy of pmtu actually working before i retire.  i realize it is
unrealistic.

> Leaving the text open to interpretation would make a mockery of
> promoting it to Standard.

agree.  but v6 specs seem to like wussing out and leaving the
opportunity to do wrong things.  i'll bet you a reuben at the corned
beef factory in chicago that the next try at the addressing architecture
still does not *unambiguously* state cidr except for slaac.

randy

---

From: Suresh Krishnan <[email-masked]>
Date: Sat, 11 Feb 2017 01:11:07 -0500

Hi Jinmei,

On Feb 10, 2017 1:23 PM, "神明達哉" <[email-masked]> wrote:

I am guessing that the people who spoke up during the WG process to not put
in an outright prohibition would make their case along with their arguments
here as well. We are only a week into a four week long last call.

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Sat, 11 Feb 2017 01:15:29 -0500

Hi Brian,

On Feb 10, 2017 8:32 PM, "Brian E Carpenter" <[email-masked]>
wrote:

On 11/02/2017 14:12, Ted Lemon wrote:
> No, we do not have IETF last call so that people who participated in the
working group discussion can re-litigate the points they lost on in the
working group discussion.

Thanks for putting it so succinctly. Getting the input from the broader
community will be extremely helpful.

Regards
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Sat, 11 Feb 2017 01:26:49 -0500

Hi Randy,

On Feb 10, 2017 10:23 PM, "Randy Bush" <[email-masked]> wrote:

obvious imiho

Do you mean the affinity for a 64 bit IID for addresses? If so, this has
been widely explored and documented in RFC7421. I agree with you that this
is hard to get out of given the state of implementations. I am not sure how
this draft (rfc2460bis) is related to that though.

Thanks
Suresh

---

From: [email-masked]
Date: Sat, 11 Feb 2017 13:36:51 +0100

Brian,

> would make a mockery of promoting it to Standard.

This is really not the discussion we ought to be having.
"Allowing" or in any way specifying how header insertion could possibly be made to work is far outside of the scope of advancing 2460 to Internet standard.

Best regards,
Ole

---

From: [email-masked]
Date: Sat, 11 Feb 2017 13:48:40 +0100

> still does not *unambiguously* state cidr except for slaac.

we're striving to write specifications that ensure interoperability.

is rewriting addresses permitted by the IPv6 architecture?
the intent of the authors were certainly clear, but we still have IPv6 NAT and NPT66.

does 2460 permit 5-tuple based ECMP? clearly not, but we also have to accept reality sometimes.

if you aren't happy with my biases please provide your own.

Best regards,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 12 Feb 2017 08:24:16 +1300

> "Allowing" or in any way specifying how header insertion could possibly be made to work is far outside of the scope of advancing 2460 to Internet standard.

If so, how can it be OK to leave the text ambiguous?

    Brian

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Sun, 12 Feb 2017 20:56:40 +0000

Suresh, Jinmei and Fernando,

I fully agree with you Suresh, the goal of an IETF last call is to get NEW discussion and to re-do the lengthy discussions we had on 6MAN WG.

-éric

From: ipv6 <[email-masked]> on behalf of Suresh Krishnan <[email-masked]>
Date: Saturday 11 February 2017 at 07:11
To: 神明達哉 <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, IETF Discussion list <[email-masked]>, Pete Resnick <[email-masked]>, Fernando Gont <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard

Hi Jinmei,

On Feb 10, 2017 1:23 PM, "神明達哉" <[email-masked]<mailto:[email-masked]>> wrote:
At Thu, 9 Feb 2017 18:30:11 -0300,
Fernando Gont <[email-masked]<mailto:[email-masked]>> wrote:

I am guessing that the people who spoke up during the WG process to not put in an outright prohibition would make their case along with their arguments here as well. We are only a week into a four week long last call.

Thanks
Suresh

---

From: "Leddy, John" <[email-masked]>
Date: Sun, 12 Feb 2017 23:05:49 +0000

I’m trying to understand how a ban of this functionality would work.  Is it targeted at vendor products, precluding them from implementing the functionality?

If there is a technical problem that can be solved by using EH insertion within a domain where there are no harmful side effects, it should be able to be used.
In a software networking world where functionality is being deployed that is not from traditional network vendors; solutions that solve problems efficiently will get deployed.

John Leddy

From: ietf <[email-masked]> on behalf of "Eric Vyncke (evyncke)" <[email-masked]>
Date: Sunday, February 12, 2017 at 3:56 PM
To: Suresh Krishnan <[email-masked]>, 神明達哉 <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, IETF Discussion list <[email-masked]>, Pete Resnick <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard

-éric

Hi Jinmei,

Thanks
Suresh

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 13 Feb 2017 13:40:04 +1300

John,

> I’m trying to understand how a ban of this functionality would work.  Is it targeted at vendor products, precluding them from implementing the functionality?

It's targetted at interoperability across the Internet. We can never stop
people doing whatever they please inside a private domain, obviously.
As always, there are no protocol police.

> In a software networking world where functionality is being deployed that is not from traditional network vendors; solutions that solve problems efficiently will get deployed.

We had a lot of this conversation in a slightly different form prior to
RFC 6437. It proved impossible to specify "local domain" rules that could
reach consensus. I think we'd have the same problem trying to write rules
for header insertion/deletion within a domain. But in any case, that isn't
the target for RFC2460bis: the target is the Internet.

    Brian

---

From: Mark Smith <[email-masked]>
Date: Mon, 13 Feb 2017 12:51:33 +1100

On 13 Feb. 2017 11:40 am, "Brian E Carpenter" <[email-masked]>
wrote:

John,

On 13/02/2017 12:05, Leddy, John wrote:
> I’m trying to understand how a ban of this functionality would work.  Is
it targeted at vendor products, precluding them from implementing the
functionality?

> If there is a technical problem that can be solved by using EH insertion
within a domain where there are no harmful side effects, it should be able
to be used.
> In a software networking world where functionality is being deployed that
is not from traditional network vendors; solutions that solve problems
efficiently will get deployed.

We also know that this statement from RFC1918 hasn't been 100% effective:

   Because private addresses have no global meaning, routing information
   about private networks shall not be propagated on inter-enterprise
   links, and packets with private source or destination addresses
   should not be forwarded across such links.

and we still don't have enough deployment of BCP38 which would also help
enforce that.

If it is possible to plug a device into the Internet I think it is better
to assume somebody probably will (and you won't be there to stop them) and
design to that assumption.

(All the recent "IoT" botnets and corresponding attacks are a result of
assuming those devices will only be connected to Private Internets, and
therefore they don't have to be individually "Internet proof" (conceptually
similar to a "water proof" watch).)

Regards,
Mark.

    Brian

> Cc: "[email-masked]" <[email-masked]>, IETF Discussion list <[email-masked]>,
Pete Resnick <[email-masked]>, "draft-ietf-6man-rfc2460bis@
tools.ietf.org" <[email-masked]>, "
[email-masked]" <[email-masked]>
> I fully agree with you Suresh, the goal of an IETF last call is to get
NEW discussion and to re-do the lengthy discussions we had on 6MAN WG.
> Cc: "[email-masked]" <[email-masked]>, IETF Discussion list <[email-masked]>,
Pete Resnick <[email-masked]>, Fernando Gont <
[email-masked]>, "[email-masked]" <
[email-masked]>, "[email-masked]" <
[email-masked]>
> I am guessing that the people who spoke up during the WG process to not
put in an outright prohibition would make their case along with their
arguments here as well. We are only a week into a four week long last call.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 14 Feb 2017 11:24:15 -0500

I want to reinforce this.

There are two separate but related issues here.  One is what behavior we 
want to require.  The other is whether we make the document clear.

I think choosing to leave a document going to Internet Standard 
ambiguous is a serious mistake, bordering on failure.  We know that the 
choice of permitting insertion of extension headers has interoperability 
implications.  There are weveral ways we can clarify the text.
o We could say "MUST NOT" be added.  Preferably with explaantion of the 
problems being avoided.
o We could say "MUST NOT unless some other standards track RFC says it 
is okay" which is technically correct but confusing.
o We can say "SHOULD NOT unless ..." as long as we can write a clear 
description of the conditions under which it is safe.
o We can say "AMY< but note that doing so has the following risks" if 
that is the IETF rough consensus.

But leaving it ambiguous ought to be a non-starter.

Personally, I would go with "MUST NOT", as I think that is the robust 
and interoperable answer.  But that is MUCH less important to me than 
our being unambiguous.

Yours,
Joel

---

From: Fernando Gont <[email-masked]>
Date: Tue, 14 Feb 2017 14:10:32 -0300

[...]
> and interoperable answer.  But that is MUCH less important to me than

Agreed with the quoted part above.

Now regarding the possible options, may I ask: How could we possibly
allow EH insertion in this document, and still move rfc2460 to full
standard?

Allowing EH insertion in rfc2460bis would essentially preclude us from
moving it to full standard.

OTOH, as you correctly note, "I think choosing to leave a document going
to Internet Standard ambiguous is a serious mistake, bordering on failure".

Thanks,

---

From: [email-masked]
Date: Tue, 14 Feb 2017 19:59:48 +0100

Joel,

> There are two separate but related issues here.  One is what behavior we want to require.  The other is whether we make the document clear.
> 
> I think choosing to leave a document going to Internet Standard ambiguous is a serious mistake, bordering on failure.  We know that the choice of permitting insertion of extension headers has interoperability implications.  There are weveral ways we can clarify the text.
> o We could say "MUST NOT" be added.  Preferably with explaantion of the problems being avoided.

Yes.

> o We could say "MUST NOT unless some other standards track RFC says it is okay" which is technically correct but confusing.

That's redundant. A new standards RFC can always be written that will override this.

> o We can say "SHOULD NOT unless ..." as long as we can write a clear description of the conditions under which it is safe.

As the 6man chair we declared that as out of scope in the context of advancing 2460 to Internet standard.

> o We can say "AMY< but note that doing so has the following risks" if that is the IETF rough consensus.

Middleboxes live in unregulated territory, there was no support (or even suggestion) in the working group for explicitly permitting header insertion.

> But leaving it ambiguous ought to be a non-starter.

Why?
Leaving it as it was, including describing what we would imagine it would break was the preferred solution in the working group.
Note that both IPv4 and IPv6 has this so-called ambiguity, that has caused no known interoperability issues and has existed for decades.

This is perceived as an ambiguity only because we as a community have accepted layer violations for so long.
This can be exemplified by discussions on maximum extension header length in IPv6. The only reason that discussion happens is because middleboxes require access to the transport header and beyond. In a purist 2460 view a router doing 5-tuple ECMP is not compliant with the specification. Clarifying that ambiguity would probably not make the operational community proud of us.

The only purpose an outright ban would achieve, would be a pre-emptive strike against potential future standardisation.

So when you think long enough about it, which choice you pick will unlikely have much consequence either way. It has no effect on implementations, it is not testable. In the context of 2460 this isn't a debate with many technical points.

Which is why the working group could not reach a consensus, and we ended up decided it with a poll. Do you prefer your bike shed red, yellow or green. You have added a couple of more colours.

> Personally, I would go with "MUST NOT", as I think that is the robust and interoperable answer.  But that is MUCH less important to me than our being unambiguous.

There is an infinite set of creative (ab)uses of 2460 that hasn't been banned. I would claim it would be impossible to write a document which would MUST NOT every potential abuse.

Best regards,
Ole

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 14 Feb 2017 14:05:11 -0500

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.

Yours,
Joel

PS: The ability to do ECMP is why I helped with and supported the effort 
to get the flow label use for ECMP entropy documented.  That would 
ameliorate a number of problems.  I do not expect this revision of 2460 
to fix that, particularly since there seems to be little adoption.  I 
try not to get distracted looking for perfection.

On 2/14/17 1:59 PM, [email-masked] wrote:
> Joel,
>
>> There are two separate but related issues here.  One is what
>> behavior we want to require.  The other is whether we make the
>> document clear.
>>
>> ambiguous is a serious mistake, bordering on failure.  We know that
>> the choice of permitting insertion of extension headers has
>> interoperability implications.  There are weveral ways we can
>> clarify the text. o We could say "MUST NOT" be added.  Preferably
>> with explaantion of the problems being avoided.
>
> Yes.
>
>> o We could say "MUST NOT unless some other standards track RFC says
>> it is okay" which is technically correct but confusing.
>
>> o We can say "SHOULD NOT unless ..." as long as we can write a
>> clear description of the conditions under which it is safe.
>
> Middleboxes live in unregulated territory, there was no support (or
> even suggestion) in the working group for explicitly permitting
> header insertion.
>
> Why? Leaving it as it was, including describing what we would imagine
> it would break was the preferred solution in the working group. Note
> that both IPv4 and IPv6 has this so-called ambiguity, that has caused
> no known interoperability issues and has existed for decades.
>
> This is perceived as an ambiguity only because we as a community have
> accepted layer violations for so long. This can be exemplified by
> discussions on maximum extension header length in IPv6. The only
> reason that discussion happens is because middleboxes require access
> to the transport header and beyond. In a purist 2460 view a router
> doing 5-tuple ECMP is not compliant with the specification.
> Clarifying that ambiguity would probably not make the operational
> community proud of us.
>
> The only purpose an outright ban would achieve, would be a
> pre-emptive strike against potential future standardisation.
>
> So when you think long enough about it, which choice you pick will
> unlikely have much consequence either way. It has no effect on
> implementations, it is not testable. In the context of 2460 this
> isn't a debate with many technical points.
>
> Which is why the working group could not reach a consensus, and we
> ended up decided it with a poll. Do you prefer your bike shed red,
> yellow or green. You have added a couple of more colours.
>
>> Personally, I would go with "MUST NOT", as I think that is the
>> robust and interoperable answer.  But that is MUCH less important
>> to me than our being unambiguous.
>
> There is an infinite set of creative (ab)uses of 2460 that hasn't
> been banned. I would claim it would be impossible to write a document
> which would MUST NOT every potential abuse.
>
> Best regards, Ole
>

---

From: [email-masked]
Date: Tue, 14 Feb 2017 20:12:57 +0100

Joel,

> difference, we have an obligation to address it.

This particular issue has caused no interoperability issue, and only a single question to the working group 20 years ago.
The current debate has been caused by a set of new proposals, independently of 2460, where the authors have in a creative reading of the current text figured out that they can shoe-horn header insertion in without actually violating the specification. Now, if clarifying the text was done, then I presume these proposals would just adapt to update 2460bis instead. The real battle would in any case have to be over those documents, not this one.

Now for the snarkiness; an issue that has created real problems is both IETF specifications (although experimental) and implementations of address rewriting by intermediate boxes. And there isn't a explicit ban on address rewriting in 2460. Should we add that? Would it help?

> PS: The ability to do ECMP is why I helped with and supported the effort to get the flow label use for ECMP entropy documented.  That would ameliorate a number of problems.  I do not expect this revision of 2460 to fix that, particularly since there seems to be little adoption.  I try not to get distracted looking for perfection.

Yes, and that's greatly appreciated!

Best regards,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Tue, 14 Feb 2017 17:00:56 -0300

On 02/14/2017 04:12 PM, [email-masked] wrote:
> This particular issue has caused no interoperability issue,

May I ask what's the data that support this statement?

You certainly have no way of knowing this, or whether interoperability
issues may arise in the future.

Thanks,

---

From: [email-masked]
Date: Wed, 15 Feb 2017 11:18:50 +0100

> 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

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

What you are talking about is something else. You are talking about the hypothetical "What if someone standardised something new in the future?"

Ole

---

From: Fernando Gont <[email-masked]>
Date: Fri, 17 Feb 2017 09:40:19 -0300

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

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

---

From: [email-masked]
Date: Fri, 17 Feb 2017 15:12:54 +0100

Fernando,

It is a simple logical consequence.

Middleboxes do not exist in the IPv6 architecture.
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 <[email-masked]> wrote:
>

---

From: Fernando Gont <[email-masked]>
Date: Fri, 17 Feb 2017 11:28:12 -0300

> Therefore, there is no interoperability issue in RFC2460 nor any ambiguity that needs to be resolved in RFC2460.

lAt the Last 6man meeting there was a bunch of people arguing that
inserting EHs was "ok" because "it was not explicitly banned" -- the
"interpretation" :-) at the time being that "'processed' doesn't mean
'inserted'"

I asked you whether EH insertion was allowed, and you didn't answer the
question, even after asking multiple times (it should be in the audio
recordings).

Now you say the above. When did you change your mind?

Simple:

1) It was clear to everyone that EH insertion wasn't allowed.

2) Some folks came with a funny interpretation, such that EHs could be
inserted.

3) Lots of supporters of EH-insertion (mostly from the same company)
argued that "it wasn't forbidden". And this wasted lots of people's time.

So a clarification is warranted. That's it.

P.S.: And then folks wonder why people "give up"??

Me, I'm not wasting more time on this. It should be pretty clear to the
IESG what's going on here.

Thanks,

---

From: [email-masked]
Date: Fri, 17 Feb 2017 15:40:16 +0100

Fernando,

> Now you say the above. When did you change your mind?

Huh?
I'm not saying anything about header insertion outside the context of 2460 being allowed or not.
I'm saying that in the context of implementing 2460 header insertion cannot come up.

> IESG what's going on here.

Sorry, you lost me.

Ole

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 17 Feb 2017 11:22:28 -0500

Given that different people have interpreted 2460 as permitting or 
prohibiting the addition of Extension Headers by intermediate devices, 
there clearly is an ambiguity.

That is the point that concerns me.

Yours,
Joel

---

From: "Scott O. Bradner" <[email-masked]>
Date: Fri, 17 Feb 2017 12:14:51 -0500

> On Feb 17, 2017, at 9:12 AM, [email-masked] wrote:
> 
> Fernando,
> 

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

Scott

---

From: [email-masked]
Date: Fri, 17 Feb 2017 18:15:25 +0100

Joel,

> Given that different people have interpreted 2460 as permitting or prohibiting the addition of Extension Headers by intermediate devices, there clearly is an ambiguity.

I'm a little uncertain if I'm unclear or if you simply didn't read my message. :-)

Do we agree that you can see this at two different angles?

1) Are there any interoperability issue or ambiguity in the protocol specification of 2460 and how implementors of 2460 have interpreted that?

2) Is 2460 "future-ambiguous", i.e it is unclear if 2460 permits a future extension? Like ECMP, Header insertion NAT...

The answer to 1 is no. And no-one has claimed otherwise in these discussions.

For 2, that would be in the area of stating the law for what future extensions of IPv6 can or cannot do.
If we want to go there 2460, yes there are ambiguities. It's hard to predict what the IETF can possible invent in the future and if that should be permitted or not. And of course what effect that would have on future documents regardless.

Clear?

Best regards,
Ole

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 17 Feb 2017 12:26:52 -0500

I am not sure what youa re asking with either of your quesitons.

With regard to question 1, you seem to be asking whether we have seen 
folks adding EHs, and whether it has been observed to cause 
difficulties.  We have seen folks trying to standardize exactly such 
additions.  So I presume they have already implemented them.  And we 
have seen folks explaining a range of cases where it causes problems.

With regard to 2, you seem to be you seem to be constructing a very odd 
reading of an RFC.  Some people have clearly said that they read the 
existing RFC as permitting additions of EHs.  That is not a matter of 
future RFCs, but of current readers.  Other people have said that they 
read the text as clearly prohibiting such behavior.  Which would at a 
minimum mean that any IETF effort to change it would be required to 
explain why it was acceptable and interoperable to change the rules.

Given that the existing wording has been interpreted in different ways 
by different people, and that there is good reason to beileve that the 
differing interpretations will (if they have not already) cause 
interoperability issues, it seems to me incumbent on the WG to be clear 
about what it means.

The usual approach to this is to use RFC 2119 terminology and careful 
wording.

Yours,
Joel

---

From: [email-masked]
Date: Fri, 17 Feb 2017 18:31:48 +0100

Scott,

> content redirectors do not exist in IPv6???

In the world view of RFC2460, the world consists of hosts and routers connected with links.
That's largely the IETF specification perspective too...
We don't write our protocols to accommodate middleboxes on the path.

Cheers,
Ole

---

From: [email-masked]
Date: Fri, 17 Feb 2017 18:39:42 +0100

Joel,

> With regard to question 1, you seem to be asking whether we have seen folks adding EHs, and whether it has been observed to cause difficulties.  We have seen folks trying to standardize exactly such additions.  So I presume they have already implemented them.  And we have seen folks explaining a range of cases where it causes problems.

No, that's not what I'm asking.
I'm asking if an implementor of the 2460 specification has interpreted the text as ambiguous and if that has led to interoperability issues.
The answer to that is no.

Do you see my point here? That this point is important for advancing RFC2460. There is no shown ambiguity that has had any consequence for 2460 implementors.

Header insertion just doesn't exist in the context of implementing 2460.

> With regard to 2, you seem to be you seem to be constructing a very odd reading of an RFC.  Some people have clearly said that they read the existing RFC as permitting additions of EHs.  That is not a matter of future RFCs, but of current readers.  Other people have said that they read the text as clearly prohibiting such behavior.  Which would at a minimum mean that any IETF effort to change it would be required to explain why it was acceptable and interoperable to change the rules.
> 
> Given that the existing wording has been interpreted in different ways by different people, and that there is good reason to beileve that the differing interpretations will (if they have not already) cause interoperability issues, it seems to me incumbent on the WG to be clear about what it means.

Can you please explain how that can create interoperability issues? An implementation of 2460 does not do header insertion.
You must be talking about some future specification (there are drafts) that specify header insertion.
_Those_ specifications will create interoperability problems. I think we should not standardise those.

Sure you could ban NAT's, ECMP and header insertion, and whatever else you can imagine in 2460, but how exactly is that going to prohibit anyone from writing the above set of specs? We're not writing law, we're writing interoperable protocols.

Cheers,
Ole

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 17 Feb 2017 12:44:45 -0500

I disagree with your interpretation of the bar the document must meet.
I believe I have clearly stated my concern.
I will leave that judgment to the relevant ADs and IESG when they review 
the last call results.

Yours,
Joel

---

From: "Scott O. Bradner" <[email-masked]>
Date: Fri, 17 Feb 2017 12:58:33 -0500

> On Feb 17, 2017, at 12:31 PM, [email-masked] wrote:
> 
> Scott,
> 

parellel universe

Scott

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 17 Feb 2017 18:00:51 +0000

Ole

Are you saying:

A correct implementation of RFC2460 MUST NOT insert an EH at any point 
along the path other than at the packet source.

Or

A correct implementation of RFC2460 MAY insert an EH at any point along 
the path.

Either way, why not add that line to the text to remove any possible 
ambiguity in interpretation?

- Stewart

---

From: [email-masked]
Date: Fri, 17 Feb 2017 19:13:20 +0100

Stewart,

> Are you saying:
> 
> A correct implementation of RFC2460 MUST NOT insert an EH at any point along the path other than at the packet source.
> 
> Or
> 
> A correct implementation of RFC2460 MAY insert an EH at any point along the path.

No, I'm saying that for a correct implementation of RFC2460 the issue doesn't ever arise.

> Either way, why not add that line to the text to remove any possible ambiguity in interpretation?

Yes, we could. We couldn't find consensus for that in the working group though.
I'm trying out the argument of declaring the whole question of ambiguity out of scope. To see if there is better consensus for that.

Best regards,
Ole

---

From: Alejandro Acosta <[email-masked]>
Date: Fri, 17 Feb 2017 15:16:26 -0300

> content redirectors do not exist in IPv6???

I was about to ask the same question

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 17 Feb 2017 18:37:51 +0000

> No, I'm saying that for a correct implementation of RFC2460 the issue doesn't ever arise.

That seems somewhat like Schroedinger's cat.

Given that RFC2460 defines EHs only one of those statements can be true 
for any EH type.

- Stewart

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 18 Feb 2017 08:34:32 +1300

> A correct implementation of RFC2460 MAY insert an EH at any point along 

Ole doesn't, apparently, want to say either of those things.

I want to say the first *as part of the promotion to Internet Standard*
because it was the clear and documented intent of the authors and WG
of RFC 1883, which became RFC 2460. (Documented in the ancient email I dug
out a while back.) And it has been assumed by subsequent work such
as PMTUD and IPsec/AH.

If we want to *change* it, that's a separate discussion from promoting
the current standard. We can do it afterwards.

(And in answer to some other comments, I'll note that RFC 791 does not
forbid NAT, but I bet the authors would have done so if they'd thought
of it. When did forbidding something in an RFC ever prevent people from
implementing it in a limited domain?)

    Brian

---

From: james woodyatt <[email-masked]>
Date: Fri, 17 Feb 2017 12:24:43 -0800

> Middleboxes do not exist in the IPv6 architecture.

I wish I had known that when I was writing RFC 6092.

--james woodyatt <[email-masked] <mailto:[email-masked]>>

---

From: [email-masked]
Date: Fri, 17 Feb 2017 21:48:50 +0100

> I wish I had known that when I was writing RFC 6092.

Indeed what a shame. Well if you encounter any of them, please let me know and I'll send you instructions for how to get them repurposed into routers with the IETF approved 40 byte header inspection limiter installed. I've just added an IETF hackathon proposal to improve the IETF approved router reference software to insert a small header in each packet it forwards: "This packet is certified to be IETF compliant.".

Oh Fridays...

Best regards,
Ole

---

From: Philip Homburg <[email-masked]>
Date: Sat, 18 Feb 2017 13:59:35 +0100

>implementing it in a limited domain?)

I agree.

Personally, I wish we could allow routers to insert fragmentation headers.
There is some crazy interaction between DNS and fragmentation that doesn't
happen in IPv4.

But in any case, a stronger text doesn't have much impact on parties outside
the IETF. If, as a random example, I came to the conclusion that I can
reduce PMTU problems by having one of my routers fragment IPv6 packets, then
that may violate the spec, but it is possible that the gains are worth it.

So the only purpose of a stronger text against inserting extension headers
would be to prevent IETF working groups from publishing RFCs that use
that technique. 

Then the question becomes, why would we need to pre-emptively constrain
ourselves? 

If we expect that there is some real world use case where insering
extension headers along the way brings a lot of benefit, then it is much
better to prepare for that situation then writing text to disallow it.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 20 Feb 2017 09:36:27 +1100

> There is some crazy interaction between DNS and fragmentation that doesn't

With IPv4 DF is 0 unless you are running a out of RFC compliance
stack (Yes I'm talking about Linux) so fragmentation is done when
required. Add to that very few paths that actually require PMTUD
even with DF=1 you don't see issues.  As IPv4 as a service becomes
more common you will start to see more issues.

For IPv6 you have to play games with DNS.  We tried just fragmenting
at 1280 but the idiots with firewalls that drop all fragments made
that not viable.  At the moment named is forcing fragmentation at
1280 on DNS/UDP message sizes > 1432 (IPv6 in IPv4 + UDP header).
This removes most of the PMTUD issues without getting DNS/UDP
messages between 1252 and 1432 bytes dropped just because they were
fragmented.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Fernando Gont <[email-masked]>
Date: Wed, 22 Feb 2017 22:48:43 -0300

Folks,

One thing that is missing in this document is a reality-check of the use
of Extension Headers in the public Internet.

No matter whether one likes it or not, published studies regarding the
drop rate of IPv6 packets with extension headers should signal an alarm
in at least the operational world.

RFC7872 ("Observations on the Dropping of Packets with IPv6 Extension
Headers in the Real World") might be of use here.

Thanks,
Fernando

---

From: Fernando Gont <[email-masked]>
Date: Sun, 26 Feb 2017 03:42:08 -0300

Folks,

Page 15 of the document says:

    For every packet that is to be fragmented, the source node generates
    an Identification value.  The Identification must be different than
    that of any other fragmented packet sent recently* with the same
    Source Address and Destination Address.  If a Routing header is
    present, the Destination Address of concern is that of the final
    destination.

      *  "recently" means within the maximum likely lifetime of a
          packet, including transit time from source to destination and
          time spent awaiting reassembly with other fragments of the same
          packet.  However, it is not required that a source node know
          the maximum packet lifetime.  Rather, it is assumed that the
          requirement can be met by implementing an algorithm that
          results in a low identification reuse frequency.  Examples of
          algorithms that can meet this requirement are described in
          [RFC7739].

This is certainly an improvement over RFC2460, which suggested the use
of a simple counter to achieve this requirement. While the algorithms in
RFC7739 are meant to result in non-predictable (by off-path attackers)
Identification values, I believe that this spec should clarify that
Identification values should not be predictable by off-path attackers.

The survey in Appendix B of RFC7739
(<https://tools.ietf.org/html/rfc7739#appendix-B>) shows some sample
popular implementations that, unfortunately, still employ predictable
Identification values.

Given too-frequent pattern of protocol implementations employing
improper numeric-identifier generators (see
<https://tools.ietf.org/html/draft-gont-predictable-numeric-ids>) and
<https://tools.ietf.org/html/draft-gont-numeric-ids-history>), I think
an explicit requirement is warranted.

Thanks,
Fernando

---

From: Fernando Gont <[email-masked]>
Date: Sun, 26 Feb 2017 04:30:02 -0300

Folks,

Page 9 of the document says:

2.3.  Address Type Identification

   The type of an IPv6 address is identified by the high-order bits of
   the address, as follows:

      Address type         Binary prefix        IPv6 notation   Section
      ------------         -------------        -------------   -------
      Unspecified          00...0  (128 bits)   ::/128          2.4.2
      Loopback             00...1  (128 bits)   ::1/128         2.4.3
      Multicast            11111111             ff00::/8        2.6
      Link-Local unicast   1111111010           fe80::/10       2.4.6
      Global Unicast       (everything else)

I wonder if this table should explicitly call out ULAs, and provide a
reference to the corresponding section.

(Question came up while looking at a slide I use in an IPv6 course I
teach, in which I use a modified version of this table, which calls out
ULAs).

Thanks,
Fernando

---

From: Sander Steffann <[email-masked]>
Date: Sun, 26 Feb 2017 13:55:59 +0100

Hi,

>      Address type         Binary prefix        IPv6 notation   Section

ULAs are not an address type, they are Global Unicast. Adding them here might confuse people. And if we include ULAs then there is lots more that we should include as well. So while I understand your question, I think it would be better not to.

Cheers,
Sander

---

From: Fernando Gont <[email-masked]>
Date: Sun, 26 Feb 2017 10:05:59 -0300

> ULAs are not an address type, they are Global Unicast. Adding them here might confuse people. And if we include ULAs then there is lots more that we should include as well. So while I understand yo…

The "confusing" part is that, while globally unique, their scope is not
really global -- i.e., they are not meant to be globally routable.

Wasn't there at some point an I-D aiming to clarify what "global" meant?
-- IIRC, authored by Brian et al.

Cheers,

---

From: Sander Steffann <[email-masked]>
Date: Sun, 26 Feb 2017 14:24:35 +0100

> Op 26 feb. 2017, om 14:05 heeft Fernando Gont <[email-masked]> het volgende geschreven:
> 

Indeed, globally unique vs globally routable. But if you go into this then it's more complicated than it seems. Whether something is routable and where are an operational choice. Companies choosing to interconnect might route each other's ULA space, while some of my RIPE NCC allocated space is not routed anywhere public. It's difficult to give a fixed definition that doesn't take operational stuff into account.

Of course the intention of how to use ULA should be mentioned somewhere, but probably not in this table.

> -- IIRC, authored by Brian et al.

Sorry, I don't remember.

Cheers,
Sander

---

From: Fernando Gont <[email-masked]>
Date: Sun, 26 Feb 2017 11:03:54 -0300

On 02/26/2017 10:24 AM, Sander Steffann wrote:
>>>> The type of an IPv6 address is identified by the high-order
>>>> bits of the address, as follows:
>>>> 
>>>> Address type         Binary prefix        IPv6 notation
>>>> Section ------------         -------------        -------------
>>>> ------- Unspecified          00...0  (128 bits)   ::/128
>>>> 2.4.2 Loopback             00...1  (128 bits)   ::1/128
>>>> 2.4.3 Multicast            11111111             ff00::/8
>>>> 2.6 Link-Local unicast   1111111010           fe80::/10
>>>> 2.4.6 Global Unicast       (everything else)
>>>> 
>>>> 
>>>> I wonder if this table should explicitly call out ULAs, and
>>>> provide a reference to the corresponding section.
>>> 
>>> ULAs are not an address type, they are Global Unicast. Adding
>>> them here might confuse people. And if we include ULAs then there
>>> is lots more that we should include as well. So while I
>>> understand your question, I think it would be better not to.
>> 
>> The "confusing" part is that, while globally unique, their scope is
>> not really global -- i.e., they are not meant to be globally
>> routable.
> 
> Indeed, globally unique vs globally routable. But if you go into this
> then it's more complicated than it seems. Whether something is
> routable and where are an operational choice. Companies choosing to
> interconnect might route each other's ULA space, while some of my
> RIPE NCC allocated space is not routed anywhere public. It's
> difficult to give a fixed definition that doesn't take operational
> stuff into account.

According to the definition of global scope in RFC4291, ULAs are not
really global. If they were, an ULA address should be able to uniquely
identify an interface in the whole (global) network. If anything, this
only happens "statistically".

In practice, sine 2001:db8::/16 is not routable, if your teaching a
course you'll probably use ULAs for a virtual lab. And since you copy
the same VMs to all attendees, they all end up using the same ULA
addresses. Hence their scope (within which an interface is uniquely
identified) will certainly not be global (multiple different interfaces
employ the same address at the same timeframe). :-)

Cheers,

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 27 Feb 2017 08:15:47 +1300

Hi Fernando,
> -- IIRC, authored by Brian et al.

Not me, but you are thinking of draft-bchv-rfc6890bis

However I think this is totally out of scope for 2460bis, where the above summary
is necessary & sufficient. It's covered in 4291bis (section 2.4.7).

    Brian

---

From: Erik Kline <[email-masked]>
Date: Mon, 27 Feb 2017 12:47:16 +0900

On 26 February 2017 at 22:05, Fernando Gont <[email-masked]> wrote:

> > ULAs are not an address type, they are Global Unicast. Adding them here
> might confuse people. And if we include ULAs then there is lots more that
> we should include as well. So while I understand your question, I think it
> would be better not to.
>

https://tools.ietf.org/html/draft-carpenter-6man-whats-global

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 27 Feb 2017 11:00:33 +0100

>> -- IIRC, authored by Brian et al.

It was something to correct at IANA about this 'global'.

Alex