Subject: Re: rfc2460bis question

From: Fernando Gont <[email-masked]>
Date: Mon, 4 Apr 2016 10:20:37 -0300

On 03/28/2016 09:30 PM, Brian E Carpenter wrote:
> Hi,
> 
> rfc2460bis doesn't fix an ambiguity in interpretation of RFC 2460 that
> seems to come up repeatedly.
> 
> Are intermediate systems allowed to insert, change or delete Extension Headers,
> apart from specified cases (routing headers, and HbH options that may change
> en route)? And in the cases where changes are allowed, are intermediate systems
> allowed to change the *length* of headers or option data?
> 
> For option data, the answer is clear but slightly hidden: since the Option Data
> but *not* the Opt Data Len may be omitted from IPSec AUTH, Opt Data Len is
> clearly not allowed to change and therefore options cannot be inserted or
> deleted either (which breaks RFC 4782). But it isn't stated anywhere that
> I can see that intermeiate systems must not insert, change or delete EHs,
> although they are all supposed to be e2e except for HbH options.
> 
> Maybe that needs to be an erratum on 2460?

+1

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

---

From: Bob Hinden <[email-masked]>
Date: Mon, 4 Apr 2016 16:46:09 -0300

Brian,

> On Mar 28, 2016, at 9:30 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> Hi,
> 

Some relevant words from rfc2460bis Section 4. "IPv6 Extension Header":

   Extension headers must never be inserted by any node other than the
   source of the packet.  IP Encapsulation must be used to meet any
   requirement for inserting headers, for example, as defined in
   [RFC2473].

I think covers the inserting issue.

I don’t see any text that prohibits changing or deleting Extension Headers.  I think it was the intent to not delete or change the length of Extension Headers, so we could add that as a clarification.  Changing the content is more complex, as you note, we do allow changing the content of some extension headers.  I think that needs to be part of the definition of each extension header.

We could add text cover deleting and changing the length.

> although they are all supposed to be e2e except for HbH options.

I think that confirms the intent.  I could work on some text for rfc2460bis.

Bob

> Regards
>   Brian
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 5 Apr 2016 08:05:38 +1200

Thanks Bob, that all works for me.

RFC 4782 seems to be problematic.

    Brian

---

From: Bob Hinden <[email-masked]>
Date: Mon, 4 Apr 2016 23:32:34 -0300

Here is my proposed text:

   Extension headers must never be deleted or changed in size by any
   node on the path the packet takes.

   The contents of an Extension header or Option in an Extension header
   may be modified if this is permitted by the definition of the
   Extension header or option.

The first paragraph is unchanged.  I will probably combine all of this into one paragraph, but kept separate for now for easier review.

Comments?

Thanks,
Bob

> On Apr 4, 2016, at 5:05 PM, Brian E Carpenter <[email-masked]> wrote:
>

---

From: Mark Smith <[email-masked]>
Date: Tue, 5 Apr 2016 12:48:47 +1000

On 5 Apr 2016 12:32 PM, "Bob Hinden" <[email-masked]> wrote:
> The first paragraph is unchanged.  I will probably combine all of this
into one paragraph, but kept separate for now for easier review.
> Comments?

I like it.

Regards,
Mark.

> >> I don’t see any text that prohibits changing or deleting Extension
Headers.  I think it was the intent to not delete or change the length of
Extension Headers, so we could add that as a clarification.  Changing the
content is more complex, as you note, we do allow changing the content of
some extension headers.  I think that needs to be part of the definition of
each extension header.

---

From: 神明達哉 <[email-masked]>
Date: Tue, 5 Apr 2016 09:56:42 -0700

At Mon, 4 Apr 2016 23:32:34 -0300,

> The first paragraph is unchanged.  I will probably combine all of this into one paragraph, but kept separate for now for easier review.

The text looks good to me, but should we also do something explicitly
for cases like RFC4782 (or any other existing spec that would violate
this clarification)?  For example, should we explicitly refer to such
RFC(s) and explain, e.g., those spec exist due to less clear wording
of RFC2460 but should have been considered invalid all the time?
Should we add "Update RFC4782" tag to rfc2460bis?

--
JINMEI, Tatuya

---

From: Bob Hinden <[email-masked]>
Date: Tue, 5 Apr 2016 14:23:04 -0300

Jinmei,

> On Apr 5, 2016, at 1:56 PM, 神明達哉 <[email-masked]> wrote:
> 
...
> Should we add "Update RFC4782" tag to rfc2460bis?

I am not sure it's appropriate to include updating text in rfc2460bis since RFC4782 is experimental, how about if we submit an errata on RFC4782 when rfc2460bis is published describing the issue.

Bob

---

From: 神明達哉 <[email-masked]>
Date: Tue, 5 Apr 2016 10:45:31 -0700

At Tue, 5 Apr 2016 14:23:04 -0300,
Bob Hinden <[email-masked]> wrote:

> I am not sure it's appropriate to include updating text in
> rfc2460bis since RFC4782 is experimental, how about if we submit an
> errata on RFC4782 when rfc2460bis is published describing the issue.

I don't necessarily think it's inappropriate (unlike a case where an
experimental updates a standards track), but I'm fine with the errata
approach, too.  I just thought we should take some explicit action to
resolve this seeming conflict.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 6 Apr 2016 08:32:55 +1200

> resolve this seeming conflict.

I think that a patch to RFC4782, suggested by Fred, to overwrite the
option with a PAD, would be a valid erratum, and would actually have
been a better fix when the document was approved than the changes
made after Last Call.

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Tue, 05 Apr 2016 18:52:06 -0400

> Comments?

I'd rather you left them as seperate sections, and I wouldn't mind if they
were easily referred to, as it would make it easier to explain if I could say
rfc2460bis#section4_1_1 or something like that.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Bob Hinden <[email-masked]>
Date: Tue, 5 Apr 2016 21:27:28 -0300

Michael,

> On Apr 5, 2016, at 7:52 PM, Michael Richardson <[email-masked]> wrote:
> 
> 

I am OK keeping it as separate paragraphs, but making each (the last two are only one sentence) a separate section, would be be sort of odd.  You could refer to them as, for example, the third paragraph of Section 4.

Bob

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Wed, 6 Apr 2016 10:46:40 +0000

> On Apr 4, 2016, at 9:46 PM, Bob Hinden <[email-masked]> wrote:
> 
> Brian,
> 

in a controlled environment where boundaries are clearly identified and with the appropriate security mechanisms, I don’t see why an extension header can’t be inserted, as long as whatever you insert is removed when existing the controlled domain.

As a matter of fact, it does happen already thanks to multiple interoperable implementations (segment routing header, RH4) and I know networks where this is being deployed. 

Again, this is a controlled environment.

Stating that "Extension headers must never be inserted by any node…” looks a bit extreme to me and I’d prefer to “recommend” not to insert rather than just ignoring what happens in real networks and for real use cases.

Thanks.
s.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 6 Apr 2016 10:59:19 +0000

>-----Original Message-----
>From: ipv6 [mailto:[email-masked]] On Behalf Of Stefano Previdi (sprevidi)
>Sent: Wednesday, April 06, 2016 6:47 AM
>To: Bob Hinden
>Cc: IPv6 List
>Subject: Re: rfc2460bis question

>in a controlled environment where boundaries are clearly identified and with the appropriate security mechanisms, I don’t see why an extension header can’t be inserted, as long as whatever you insert is removed >when existing the controlled domain.

+1

Thanks,

Hemant

---

From: Michael Richardson <[email-masked]>
Date: Wed, 06 Apr 2016 08:14:02 -0400

> I am OK keeping it as separate paragraphs, but making each (the last
    > two are only one sentence) a separate section, would be be sort of odd.
    > You could refer to them as, for example, the third paragraph of Section
    > 4.

Yes, I'll be doing that :-)
(hoping our revised rfc-format will let us turn that into a URL.)

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 6 Apr 2016 10:13:00 -0300

> As a matter of fact, it does happen already thanks to multiple interoperable implementations (segment routing header, RH4) and I know networks where this is being deployed.
Stefano,
In addition to having a strict boundary around the controlled 
environment to prevent the IPv6 base header to leak with this extension, 
you also need to ensure that it doesn't leak inside an ICMP error.
Do the current implementations ensure that?

I assume one would also need to mandate that there are no tunnels that 
can cause the packets to leak out with the added extension header. Do 
you have a mechanism to ensure that?

> Stating that "Extension headers must never be inserted by any node…” looks a bit extreme to me and I’d prefer to “recommend” not to insert rather than just ignoring what happens in real networks an…

Similar arguments has been made many times in the IETF  for protocols 
with an intended deployment in a controlled environment. (I recall the 
ones about not needing security for some protocol because of the 
intended deployment.) The experience has been that that successful 
protocol get deployed outside of their initially intended environment or 
constraints.

In the case of segment routing it wouldn't be unreasonable to assume 
that in the future there could be some gradual deployments into 
controlled environments resulting in some routers doing segment routing 
(hence adding/removing the extension header) while other routers at the 
boundary of the environment remain unmodified.
In such a case you do not have a strict boundary to prevent the leakage 
inside ICMP errors, and perhaps not even in the IPV6 base header 
depending on how routing is done.

Regards,
    Erik

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 7 Apr 2016 08:15:40 +1200

> Stating that "Extension headers must never be inserted by any node…” looks a bit extreme to me and I’d prefer to “recommend” not to insert rather than just ignoring what happens in real networks an…

I disagree. We're fixing some poor writing in 2460, which failed to state what
seemed obvious at the time. Of course, there are no protocol police and people
can do what they want in a closed domain, but if we relax the "must not" we have
done nothing to fix the poor writing; we've actually made it worse.

I completely agree with Erik that there's a real probability of leakage, which
is another reason for the "must not" approach.

Regards
   Brian

---

From: 神明達哉 <[email-masked]>
Date: Wed, 6 Apr 2016 13:19:58 -0700

At Thu, 7 Apr 2016 08:15:40 +1200,
Brian E Carpenter <[email-masked]> wrote:

> > Stating that "Extension headers must never be inserted by any
> > node…” looks a bit extreme to me and I’d prefer to “recommend” not
> > to insert rather than just ignoring what happens in real networks
> > and for real use cases.
>

+1 (to Brian and Erik).

--
JINMEI, Tatuya

---

From: Mark Smith <[email-masked]>
Date: Thu, 7 Apr 2016 06:58:04 +1000

> is another reason for the "must not" approach.

And here is an example of how hard troubleshooting silent modification
in the network can be:

"How both TCP and Ethernet checksums fail"
http://www.evanjones.ca/tcp-and-ethernet-checksums-fail.html

The statement

"The answer is that the Ethernet CRC is recalculated by switches. If
the switch corrupts the packet and it has the same TCP checksum, the
hardware blindly recalculates a new, valid Ethernet CRC when it goes
out."

Isn't quite right. Switches only recalculate the checksum when they
modify the packet, by adding or removing e.g., an 802.1q shim.
Occurrence may be rare, but it is hard and time costly to
troubleshoot.

I understand the 802.1q people did it because they didn't think widely
available ethernet hardware could handle fully encapsulating the
packet in another - as Cisco did with their proprietary alterantive
(whose name doesn't spring to mind right now). Thinking about the
above risk was what made me realise that tunnelling is a far better
method of adding information or other semantics via indirect methods
to a packet than "shimming", because it always left the original
packet alone.

Regards,
Mark.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 6 Apr 2016 18:17:21 -0300

On 04/06/2016 05:15 PM, Brian E Carpenter wrote:
>> 
>> 
>> in a controlled environment where boundaries are clearly identified
>> and with the appropriate security mechanisms, I don’t see why an
>> extension header can’t be inserted, as long as whatever you insert
>> is removed when existing the controlled domain.
>> 
>> As a matter of fact, it does happen already thanks to multiple
>> interoperable implementations (segment routing header, RH4) and I
>> know networks where this is being deployed.
>> 
> I disagree. We're fixing some poor writing in 2460, which failed to
> state what seemed obvious at the time. Of course, there are no
> protocol police and people can do what they want in a closed domain,
> but if we relax the "must not" we have done nothing to fix the poor
> writing; we've actually made it worse.
> 
> I completely agree with Erik that there's a real probability of
> leakage, which is another reason for the "must not" approach.

I concur with Brian and Erik here.

Thanks,

---

From: [email-masked]
Date: Wed, 6 Apr 2016 18:57:33 -0300

Let me add on to the comments that I made during the meeting today:

There is a high bar to introduce changes to RFC2460. Changes are limited to those described in RFC6410 in addition to "Updated by" documents.

The proposed change presented today is: (note that is updated from what is in the draft)

   "Extension headers must never be deleted or changed in size by any node on the path the packet takes.
    The contents of an Extension header or Option in an Extension header may be modified if this is permitted
    by the definition of the Extension header or option."

There is no errata or updated-by document concerning this issue.
It is not an unused feature, since the proposal is to add new text to RFC2460.

As far as I am aware, there is no interoperability issue caused by the current RFC2460 text.
And as far as I can tell the proposed addition is unlikely to create interoperability issues either.

There is RFC4782, that allows for deletion of extension headers. That is an experimental RFC, and I'm unaware of what the conclusion from the experiment is. RFC791 allows the introduction of options in certain cases.

Resolving how header insertion or deletion of extension headers / option is done  is outside the scope of the changes we can make to 2460. Those considerations should be done in the protocol specification for those proposed extension headers / options.

My current view on this, is that it would appear that like to have this additional text, not to fix an existing problem, but to fend off what should be allowed in new protocol specifications.

As I said at the microphone, my position as chair is that by _default_, the text in RFC2460 is left unchanged.

Ole

> On 06 Apr 2016, at 17:15, Brian E Carpenter <[email-masked]> wrote:
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 7 Apr 2016 13:35:10 +1200

Hi Ole,

> There is no errata or updated-by document concerning this issue.

Correct. But I was extremely surprised the first time I saw a proposal to
insert headers en route, since I had *always* read RFC2460 (and RFC1883)
to imply that headers are only created by the source node. So I maintain
that it is a drafting ambiguity (in RFC1883, actually) and therefore fair game
for clarification during the revisions allowed by RFC6410.

If you really want to see it as an erratum, that would only take a few
minutes.

> As far as I am aware, there is no interoperability issue caused by the current RFC2460 text.

Yes there is, because it does not forbid insertion of an extension header by a third
party, whereas the interoperability model for extension headers is that both the
source and the destination need to understand the extension header (a "consenting
adults" model). An unknown inserted header will cause a lost packet:

"  If, as a result of processing a header, a node is required to proceed
   to the next header but the Next Header value in the current header is
   unrecognized by the node, it should discard the packet and send an
   ICMP Parameter Problem message to the source of the packet..."

It might also cause PMTUD anomalies, too.

> Resolving how header insertion or deletion of extension headers / option is done  is outside the scope of the changes we can make to 2460. 

Obviously, I disagree.

> Those considerations should be done in the protocol specification for those proposed extension headers / options.
> 

Agreed, but when that text is actually interpreted differently by different people,
which is clearly the case here, we are IMHO obliged to clarify it.

   Brian

---

From: [email-masked]
Date: Thu, 7 Apr 2016 11:01:56 -0300

Dear Brian,

Thank you for your comments.

> If you really want to see it as an erratum, that would only take a few

I don't think you were alone about being surprised by those proposals.
It is an ambiguity that we have lived with in the Internet since RFC791 though.

>   ICMP Parameter Problem message to the source of the packet..."

What I meant was that there is no currently known interoperability problem with existing implementation or existing protocol specifications.
I agree with you that there are many issues if a future specification would require to do header injection. We could deal with those issues if or when those proposals where made.

> It might also cause PMTUD anomalies, too.

Indeed, as far I can see it wouldn't only create anomalies but it would break it.

>> Resolving how header insertion or deletion of extension headers / option is done  is outside the scope of the changes we can make to 2460.

I do understand your concern. We can argue if that concern should be tackled while taking 2460 to IS, or if it should be tackled whenever a proposal to do it comes up.

> which is clearly the case here, we are IMHO obliged to clarify it.

I'm not sure that is true. Some level of ambiguity in specifications is good. Ambiguity equals freedom and room for innovation.

In any case, if there was clear a consensus about what to say, this would be simpler. If there isn't, then saying nothing is the safer option, rather than saying the wrong thing.

Best regards,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Thu, 7 Apr 2016 13:37:17 -0300

Ole,

On 04/07/2016 11:01 AM, [email-masked] wrote:
>> Correct. But I was extremely surprised the first time I saw a
>> proposal to insert headers en route, since I had *always* read
>> RFC2460 (and RFC1883) to imply that headers are only created by the
>> source node. So I maintain that it is a drafting ambiguity (in
>> RFC1883, actually) and therefore fair game for clarification during
>> the revisions allowed by RFC6410.
>> 
>> If you really want to see it as an erratum, that would only take a
>> few minutes.
> 
> I don't think you were alone about being surprised by those
> proposals. It is an ambiguity that we have lived with in the Internet
> since RFC791 though.

And we have lived without IPv6 as Internet Standard for 30 years... so?

>> "  If, as a result of processing a header, a node is required to
>> proceed to the next header but the Next Header value in the current
>> header is unrecognized by the node, it should discard the packet
>> and send an ICMP Parameter Problem message to the source of the
>> packet..."
> 
> What I meant was that there is no currently known interoperability
> problem with existing implementation or existing protocol
> specifications. I agree with you that there are many issues if a
> future specification would require to do header injection. We could
> deal with those issues if or when those proposals where made.

Working on revised protocol spec an intentionally keeping a well-noted
ambiguity is a bad idea, and would be a poor job on our side.

Thanks,

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Fri, 8 Apr 2016 04:21:13 +0000

> On Apr 7, 2016, at 6:37 PM, Fernando Gont <[email-masked]> wrote:
> 
> Ole,
> 

it’s not "keeping an ambiguity” just for fun.

It’s waiting to have the correct analysis prior to decide which behavior to mandate. We can’t really ignore what the industry is working at, can we ?

Thanks.
s.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Fri, 8 Apr 2016 04:22:57 +0000

Ole,

I agree with your point and the point Mark (Townsley) made during the meeting.

I think we need to evaluate better the use cases and current technology development that operators are undergoing before taking drastic architectural and protocol specification decisions.

I’m not saying that everything it’s perfect as it is now. I’m saying that we may have to dig more before jumping into conclusions.

Thanks.
s.

> On Apr 7, 2016, at 4:01 PM, [email-masked] wrote:
> 
> Dear Brian,
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 8 Apr 2016 17:31:05 +1200

> I’m not saying that everything it’s perfect as it is now. I’m saying that we may have to dig more before jumping into conclusions.

"Extension headers must never be deleted or changed in size by any node on the path the packet takes."

There's no jumping to conclusions. We know that this breaks IPsec/AH and PMTUD.
It's explicit in 2460 that in the case of options, only the "Option Data" may change,
not the "Option Type" or "Opt Data Len", because of AH. But the same statement is not
made about other extension headers. As far as I'm concerned that's a clear error of omission
in 2460.

Of course inserting an extension header also breaks AH and PMTUD.

"The contents of an Extension header or Option in an Extension header may be modified if this is permitted by the definition of
the Extension header or option."

That actually should be s/may/may only/ to change anything. It's more debatable
because it doesn't damage PMTUD. But since AH is not immunised against changes
to extension headers in the same way that it's immunised against changes in
"Option Data", I think this is also a clear omission.

The fact that AH is no longer loved by the security community is a separate issue.
If the security community was ready to make AH Historic, that would change the
discussion.

Regards
  Brian

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Fri, 8 Apr 2016 05:47:56 +0000

> On Apr 8, 2016, at 7:31 AM, Brian E Carpenter <[email-masked]> wrote:
> 

in a core where header is inserted and where the mtu is over 8K I don’t see how pmtud may be broken. Also, whatever you do to the packet, if you deliver it in the same shape you received it, there’s nothing wring. At least from an operational perspective it’s happening daily.

Thanks.
s.

---

From: Mark Smith <[email-masked]>
Date: Fri, 8 Apr 2016 18:38:13 +1000

On 8 Apr 2016 3:48 PM, "Stefano Previdi (sprevidi)" <[email-masked]>
wrote:
> >> I think we need to evaluate better the use cases and current
technology development that operators are undergoing before taking drastic
architectural and protocol specification decisions.
> >>
> >> I’m not saying that everything it’s perfect as it is now. I’m saying
that we may have to dig more before jumping into conclusions.
> in a core where header is inserted and where the mtu is over 8K I don’t
see how pmtud may be broken. Also, whatever you do to the packet, if you
deliver it in the same shape you received it, there’s nothing wring. At
least from an operational perspective it’s happening daily.

Has anybody troubleshooted broken devices yet?

What is the objection to tunneling?

Regards,
Mark.

> > "The contents of an Extension header or Option in an Extension header
may be modified if this is permitted by the definition of
> >>>>> There is a high bar to introduce changes to RFC2460. Changes are
limited to those described in RFC6410 in addition to "Updated by" documents.
> >>>>>  The contents of an Extension header or Option in an Extension
header may be modified if this is permitted
> >>>> Correct. But I was extremely surprised the first time I saw a
proposal to
> >>>> If you really want to see it as an erratum, that would only take a
few
> >>>> "  If, as a result of processing a header, a node is required to
proceed
> >>> What I meant was that there is no currently known interoperability
problem with existing implementation or existing protocol specifications.
> >>> I agree with you that there are many issues if a future specification
would require to do header injection. We could deal with those issues if or
when those proposals where made.
> >>>>> There is RFC4782, that allows for deletion of extension headers.
That is an experimental RFC, and I'm unaware of what the conclusion from
the experiment is. RFC791 allows the introduction of options in certain
cases.
> >>>>>
> >>>>> Resolving how header insertion or deletion of extension headers /
option is done  is outside the scope of the changes we can make to 2460.
> >>>>
> >>>> Obviously, I disagree.
> >>>
> >>> I do understand your concern. We can argue if that concern should be
tackled while taking 2460 to IS, or if it should be tackled whenever a
proposal to do it comes up.
> >>>
> >>>>> Those considerations should be done in the protocol specification
for those proposed extension headers / options.
> >>>>>
> >>>>> My current view on this, is that it would appear that like to have
this additional text, not to fix an existing problem, but to fend off what
should be allowed in new protocol specifications.
> >>>>>
> >>>>> As I said at the microphone, my position as chair is that by
_default_, the text in RFC2460 is left unchanged.
> >>> I'm not sure that is true. Some level of ambiguity in specifications
is good. Ambiguity equals freedom and room for innovation.
> >>>
> >>> In any case, if there was clear a consensus about what to say, this
would be simpler. If there isn't, then saying nothing is the safer option,
rather than saying the wrong thing.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 8 Apr 2016 10:35:08 +0000

I like what Ole proposed.  Before the drastic text, use a "By default,", so that other behaviors are possible.  

Hemant

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Stefano Previdi (sprevidi)
Sent: Friday, April 08, 2016 12:23 AM
To: [email-masked]
Cc: Bob Hinden; 6man WG
Subject: Re: rfc2460bis question

Ole,

Thanks.
s.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 8 Apr 2016 15:27:24 -0300

On 04/08/2016 01:22 AM, Stefano Previdi (sprevidi) wrote:
> technology development that operators are undergoing before taking
> drastic architectural and protocol specification decisions.

There are no drastic decision. It's a clarification about a part of the
spec that, while evident to the authors and other folks, was not spelled
out clearly, and should be.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 8 Apr 2016 15:51:02 -0300

> it’s not "keeping an ambiguity” just for fun.

Ambiguity in a protocol specification is a bad thing. If you want to
change RFC2460 to allow for the insertion of EHs, that's fair enough:
write an I-D. THer might be valid reasons for that.

But inserting EHs is not part of RFC2460. So rfc2460bis should clarify
this. And if we want that to change, there's a process for that.

> It’s waiting to have the correct analysis prior to decide which behavior to mandate. 

It's the other way around: that behavior is already mandated. Just not
clearly stated in the specs. -- that's why rfc2460bis should include a
clarification.

> We can’t really ignore what the industry is working at, can we ?

We're not ignoring anything. For instance, segment routing is a work
item of this wg. And the decision of this wg was to employ encapsualtion
(rather than header insertion, which would violate RFC2460).

Thanks,

---

From: [email-masked]
Date: Fri, 8 Apr 2016 18:23:47 -0300

Let me clarify what my position is, since there are some nuances here.

While a discussion on header insertion may be necessary, it is not in context for taking RFC2460 to IS. If a proposal is made, then the working group should discuss that in the context of that proposal.

The RFC2460 text has not caused interoperability issues. Which is why I'm not convinced this change was required.

The default action, unless we can come to a different agreement, is to leave the RFC2460 text unchanged in RFC2460bis.

Please do not view that as if I am condoning header insertion. That would have to be future work. RFC2460 is clear that routers should not look further into packets than the base IPv6 header.

Best regards,
Ole

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 8 Apr 2016 21:34:41 +0000

Ole,

Sounds reasonable to me - thanks.

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, April 08, 2016 5:24 PM
To: 6man WG
Cc: Stefano Previdi (sprevidi); Bob Hinden; Hemant Singh (shemant)
Subject: Re: rfc2460bis question

Best regards,
Ole

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Mon, 11 Apr 2016 14:15:02 +0000

Ole,

I agree with your proposal.

s.

> On Apr 8, 2016, at 11:23 PM, [email-masked] wrote:
>

---

From: Fernando Gont <[email-masked]>
Date: Mon, 11 Apr 2016 12:19:49 -0300

On 04/08/2016 06:23 PM, [email-masked] wrote:
> While a discussion on header insertion may be necessary, it is not in
> context for taking RFC2460 to IS. If a proposal is made, then the
> working group should discuss that in the context of that proposal.

Since header insertion is certainly not part of RFC2460, rfc2460bhis
should include a clarification that header insertion is not allowed.

It would be a shame that we're working on a bis document and we fail to
clarify a question that has been raised for RFC2460.

> The RFC2460 text has not caused interoperability issues. Which is why
> I'm not convinced this change was required.

Not has RFC2460 not being IS.... so?

> The default action, unless we can come to a different agreement, is
> to leave the RFC2460 text unchanged in RFC2460bis.

I disagree. Particularly when I've filled an errata about it. The WG has
to accept or reject, I'd think.

Thanks,

---

From: 神明達哉 <[email-masked]>
Date: Mon, 11 Apr 2016 10:44:19 -0700

At Fri, 8 Apr 2016 18:23:47 -0300,
[email-masked] wrote:

> While a discussion on header insertion may be necessary, it is not
> in context for taking RFC2460 to IS. If a proposal is made, then the

I'm not sure what this "proposal" means...is it the proposed text for
rfc2460bis from Bob like this one?
https://mailarchive.ietf.org/arch/msg/ipv6/MTOkrjcscodS0C5FLmZm_LJapGY

I thought it was a clarification of the original intent of the RFC2460
authors (and the understanding of most of then and now wg members),
rather than some new proposal.  And since it's apparent that the
wording in RFC2460 wasn't really as clear as we originally as we
actually saw the "misinterpretation" in RFC4782, I thought it made
very sense to clarify that in rfc2460bis (to advance it to IS).

> The RFC2460 text has not caused interoperability issues. Which is
> why I'm not convinced this change was required.

This logic doesn't make sense to me.  The fact that we had RFC4782
suggests it's quite possible that we have other standard publications
in future that misunterprets the original intent and really cause
interoperability issues.  I don't know if the violation of RFC2460 by
RFC4782 is currently implemented and actually causes an
interoperability issue, but even if not, I don't see any reason for
not making the clarification because of that.

Now, if someone who has a conflict of interest between the original
RFC2460 intent and some particular new protocol wants to challenge
the original intent, we might be open to consider it, depending
on its technical details.  But I'd say "the working group should
discuss that in the context of that proposal" outside of whether to
make a helpful clarification in rfc2460bis.  If and when we agree on
making such a change, we'll publish a new standard document that
updates RFC2460(bis).

> to leave the RFC2460 text unchanged in RFC2460bis.

So, for one, I disagree with this and I suggest we should come to a
"different agreement" (= making this clarification in rfc2460bis).

--
JINMEI, Tatuya

---

From: Fernando Gont <[email-masked]>
Date: Mon, 11 Apr 2016 15:06:19 -0300

+1

(couldn't write it down better than this)

---

From: Tim Chown <[email-masked]>
Date: Wed, 13 Apr 2016 10:09:15 +0000

Hi,

> On 11 Apr 2016, at 19:06, Fernando Gont <[email-masked]> wrote:
> 

I agree.

But I would also add that whether we add the text or not, the (lack of) maturity in Extension Header experience means we should not advance 2460-bis to IS yet. That point was also made at the mic by someone in last week’s meeting.

Tim

---

From: 神明達哉 <[email-masked]>
Date: Wed, 13 Apr 2016 08:38:46 -0700

At Wed, 13 Apr 2016 11:08:07 +0100,
Tim Chown <[email-masked]> wrote:

> But I would also add that whether we add the text or not, the (lack
> of) maturity in Extension Header experience means we should not
> advance 2460-bis to IS yet. That point was also made at the mic by
> someone in last week’s meeting.

I didn't attend the meeting locally or remotely, but if our latest
agreement is that issues regarding EHs (including whether an
intermediate node can insert/remove them) are so substantial that we
should cancel the idea of advancing the spec to IS, I'm actually fine
with that.  I'm not yet convinced that we should allow intermediate
nodes to do that, but I'm okay with holding off and discussing the
matter.

What I mainly disagreed with is to pretend that there is no issue at
all (because "the RFC2460 text has not caused interoperability
issues") and advance the doc with being silent about it.

--
JINMEI, Tatuya

---

From: Tim Chown <[email-masked]>
Date: Wed, 13 Apr 2016 16:07:58 +0000

> On 13 Apr 2016, at 16:38, 神明達哉 <[email-masked]> wrote:
> 

Well, that was by no means agreed, but a number of people hold that view.
That view might be independent of views on the addition (or not) of EH handling text.

Tim

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Apr 2016 08:35:32 +1200

> But I would also add that whether we add the text or not, the (lack of) maturity in Extension Header experience means we should not advance 2460-bis to IS yet. That point was also made at the mic b…

I could argue that in this case the IESG should rescind the Internet Standard
status of RFC791, because we have plenty of running code experience that
new IPv4 Options cannot be deployed, so there is a distinct lack of maturity
in IPv4 Option experience.

However, the first step is perhaps to await the analysis of the two recent errata
reported on RFC 2460.

    Brian