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

From: The IESG <[email-masked]>
Date: Wed, 01 Feb 2017 15:49:25 -0800

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.

---

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:
> --------------------------------------------------------------------
> 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: 神明達哉 <[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: 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:
> 
> <tp>
> 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 <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:

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

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

---

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:
> 
> On 4 Feb 2017, at 2:32, [email-masked] wrote:
> 
> 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.
> 
> 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.

1) Ban header insertion outright.

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.

2) Describe the problems with header insertion.

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.

3) No changes to RFC2460 text.

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: Fernando Gont <[email-masked]>
Date: Wed, 8 Feb 2017 11:25:25 -0300

On 02/08/2017 10:51 AM, [email-masked] wrote:
>> 1) Ban header insertion outright. 2) Describe the problems with
>> header insertion. 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?
> 
> 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

"The exception referred to in the preceding paragraph is the Hop-by-
"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: 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: 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: "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]>
> Subject: Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet
Protocol, Version 6 (IPv6) Specification) to Internet Standard
> 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]>
> Subject: Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet
Protocol, Version 6 (IPv6) Specification) to Internet Standard
> 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: 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