Subject: draft-previdi-6man-segment-routing-header

From: Brian E Carpenter <[email-masked]>
Date: Sat, 15 Nov 2014 11:03:24 +1300

Hi,

1. I simply don't understand one aspect of this proposal. Whenever I have
looked for it in RFC 2640, I have failed to find anything that allows
extension headers to be inserted in packets en route. But this draft
seems to require an ingress router to insert a header and an egress
router to remove it. Is that even allowed? And are we sure it has no
unintended side effects?

2. There is no mention of MTU size or fragmentation. What happens if
the user packet plus the added header exceeds the network's MTU?

3. I think this model is completely orthogonal to the problem presented
by Behcet in draft-sarikaya-6man-sadr-overview.

     Brian
-- 
Regards
   Brian Carpenter
   http://orcid.org/0000-0001-7924-6182

---

From: Brian Haberman <[email-masked]>
Date: Fri, 14 Nov 2014 19:02:52 -0500

Hi Brian,

> router to remove it. Is that even allowed? And are we sure it has no

The insertion of information into a packet while in transit is an issue.
 Jinmei pointed this issue out many years ago, especially if a packet is
wrapped in any type of security mechanism.

> the user packet plus the added header exceeds the network's MTU?

*shrug*

> by Behcet in draft-sarikaya-6man-sadr-overview.

Definitely different problems.  These docs are unrelated.

Brian

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 14 Nov 2014 15:24:44 -1000

> router to remove it. Is that even allowed? And are we sure it has no

Doesn't work - breaks PMTUD (the origin receives a PTB which says MTU=X 
but sending packets of length X still fails due to the added headers). 
This should be in the "IP protocol FAQ" - I can't remember how many 
times Steve Deering had to correct this.

IPv6 extension headers can only be added together with an outer IPv6 
header. That ensure that any ICMP errors are sent to the encapsulators, 
that can regenerate a ICMP error which will have the correct MTU value 
for the original sender.

    Erik

---

From: Ole Troan <[email-masked]>
Date: Mon, 17 Nov 2014 13:14:33 -0800

Brian,

> router to remove it. Is that even allowed? And are we sure it has no

I'm not sure I got all the details of SR right.
isn't it essentially a SR domain in the middle? so that on SR domain entry encapsulation is added, and on SR domain exit it is decapsulated?
if it adds a new IPv6 header + SR, or injects SR in existing IPv6 packet, as long as it is restored on exit I guess it wouldn't matter. it would just be like a tunnel, wouldn't it?

> the user packet plus the added header exceeds the network's MTU?

if it looks like a tunnel then the SR domain entry point would send a PMTUD back, or one would have to ensure that the SR domain had a well managed MTU so that this doesn't happen.

> by Behcet in draft-sarikaya-6man-sadr-overview.

absolutely.

cheers,
Ole

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 18 Nov 2014 01:25:19 +0000

Before I file an erratum on RFC 2460, I’d like to get the working groups viewpoint on something. My guiding light here is the Robustness Principle, which (RFC 793 section 2.10) says

>   TCP implementations will follow a general principle of robustness:  be
>   conservative in what you do, be liberal in what you accept from
>   others.

I don’t find the text in RFC 791 or 2460; maybe IP is not required to be robust. However, I will argue that the following text from RFC 2460 section 4 fails to support the principle:

>   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, with an
>   ICMP Code value of 1 ("unrecognized Next Header type encountered")
>   and the ICMP Pointer field containing the offset of the unrecognized
>   value within the original packet.  The same action should be taken if
>   a node encounters a Next Header value of zero in any header other
>   than an IPv6 header.

The net effect is that, should one wish to deploy a new extension header, one cannot reliably use it until every host and router it will traverse has been updated, which is in effect “never”. The words “should discard the packet and” should, in my opinion, be removed, following the IPv4 model of ignoring an unknown option (RFC 1122 section 3.2.1.8, second paragraph). Send an ICMP if you like, but don’t prevent communication.

Note that this is not true of an option carried within an extension header. https://tools.ietf.org/html/rfc2460#section-4.2 gives the sender the option of declaring that an option may be skipped or must result in packet discard, and gives three cases for possible notification of the sender.

Can someone give me a good reason to NOT file that erratum?

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 18 Nov 2014 02:44:08 +0100

On 2014-11-18 02:25, Fred Baker (fred) wrote:
[..]
> The net effect is that, should one wish to deploy a new extension
> header, one cannot reliably use it until every host and router it
> will traverse has been updated, which is in effect “never”.

Routers don't have to parse them.
Hosts likely do have to parse them.

The problem is that it is unknown how long that extension header is.
Hence one does not know how much to skip.

Unless there is a standard where the extension header always starts with
a length stored in 16bits or so, there is little one can do here.

If one has for instance:
IPv6 -> Unknown Header -> TCP

Nothing will be able to figure out what that "Unknown Header" is and
thus find TCP.

For a router this is fine as it does not have to care about TCP, but for
an endhost that wants to get to the TCP header it basically means that
without knowing what "Unknown Header" is it won't find it.

As some folks are doing experimentations with various things, I recently
added the list of headers that for instance sixxsd supports at:

https://www.sixxs.net/faq/sixxs/?faq=sixxsd

Note that for everything routed it does check the headers for the ones
it supports it. For when it terminates the IP though, eg:
IPv6 -> Unknown Header -> ICMPv6

would not work, it will just reject it.

Greets,
 Jeroen

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 17 Nov 2014 17:46:12 -0800

On 11/17/14 5:25 PM, Fred Baker (fred) wrote:
> I don’t find the text in RFC 791 or 2460; maybe IP is not required to 
> be robust. However, I will argue that the following text from RFC 2460 
> section 4 fails to support the principle:

Fred,

I haven't re-read RFC 2460 but I'm pretty sure that the preamble "is 
required to proceed" above is supposed to handle this.
A router is only "required to proceed" past the IPv6 header if
  - the packet is explicitly addressed to (one of) the router's IPv6 
address(es) (which was the case for routing headers)
  - the packet has a hop-by-hop options header

But a router must implement HBH.
And if the packet has a routing header then there is not need for the 
router to look at the header after the RH unless segments left = 0 
(i.e., the router is at the final destination of the RH path).

So if the world only has hosts and routers I think the text if fine.

But in a world with middle-boxes the text can be misinterpreted to also 
apply to those middleboxes. AFAIK that was not the intent.
Thus I think a clarification is in order.

Thanks,
    Erik

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

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 18 Nov 2014 02:24:34 +0000

On Nov 17, 2014, at 5:46 PM, Erik Nordmark <[email-masked]> wrote:

> I haven't re-read RFC 2460 but I'm pretty sure that the preamble "is required to proceed" above is supposed to handle this.
> - the packet is explicitly addressed to (one of) the router's IPv6 address(es) (which was the case for routing headers)
> And if the packet has a routing header then there is not need for the router to look at the header after the RH unless segments left = 0 (i.e., the router is at the final destination of the RH path).
> 

Well, I’m not so sure. I’d suggest you re-read https://tools.ietf.org/html/rfc2460#section-4

It doesn’t refer to a router or a host; it refers to a node. The context is not “going beyond the IPv6 header to TCP-or-whatever”. It is “I processed the base IPv6 header or some extension header, for whatever reason I need to go to the next extension header, and I don’t understand it.”

Extension headers invariable have as their first two bytes:

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Next Header  |  Hdr Ext Len  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

So there is no question of being able to step past the next header until it finds something it understands. It knows where the “next header” identifier and the header length are. The thing that raises the point, to me, is the Segment Routing Extension Header (which should perhaps be an option in the Routing Header, and about which there are several opinions). At this point, the ultimate recipient of a message with that extension has to be SRH-capable, or the penultimate hop has to remove the thing, because of this text. 

Now, everyone gets their own opinion of SRH, and personally I’m not sure I see why the considerations of RFC 5095 don’t apply. None-the-less, I’m wondering what happens when we do get a new extension header. I’m not sure it’s good. If we are trying to deploy a new extension header and it is presented to an unupdated system, we get a parameter problem, not a robust response.

> But in a world with middle-boxes the text can be misinterpreted to also apply to those middleboxes. AFAIK that was not the intent.

What clarification would you suggest? That the packet be dropped, or that the node that thinks it needs to continue on its way (perhaps a router addressed in the destination address looking to see if a Routing Header is present, for example, or a firewall that mistakenly thinks that combing through TCP headers makes sense) should attempt to skip the header?

There is, of course, a security consideration. An interesting attack would be to use an unknown header option, or an incorrect length, to send the system that receives it into la-la-land. We already have that attack in the extensions and options we have.

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 18 Nov 2014 03:25:54 +0100

On 2014-11-18 02:46, Erik Nordmark wrote:
[..]
> Thus I think a clarification is in order.

I agree.

The problem is that when IPv6 was written down we did not have the
concept of "middleboxes" yet.

Hence, their behavior is completely unaccounted for as nobody considered
them back then.

The problem is also that middleboxes do not really speak IP in a way.
For instance they typically do not bother with ICMPv6 as well, why would
they...

I think the best thing would be an Informational draft:
 "Middlebox and IPv6: do's and dont's"

Could be quite short, as the people building those things don't really
care about what is defined anyway :(

Greets,
 Jeroen

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 18 Nov 2014 02:32:49 +0000

> From: ipv6 [mailto:[email-masked]] On Behalf Of Fred Baker (fred)
 
> Before I file an erratum on RFC 2460, I'd like to get the working groups
> viewpoint on something. My guiding light here is the Robustness Principle,
> which (RFC 793 section 2.10) says
> 

I'm with you that IP should also follow the robustness principle.

> I don't find the text in RFC 791 or 2460; maybe IP is not required to be
> robust. However, I will argue that the following text from RFC 2460 section 4
> fails to support the principle:
> 
> The net effect is that, should one wish to deploy a new extension header, one
> cannot reliably use it until every host and router it will traverse has been
> updated, which is in effect "never". The words "should discard the packet
> and" should, in my opinion, be removed, following the IPv4 model of ignoring
> an unknown option (RFC 1122 section 3.2.1.8, second paragraph). Send an ICMP
> if you like, but don't prevent communication.

Agreed. However two paragraphs before that one, still in Section 4, it says:

   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.

So, the end hosts would be the only ones to examine this new header, and potentially discard the packet. Is this not the way it should be?

> Can someone give me a good reason to NOT file that erratum?

Only that the issue does not apply to routers or any other intermediate node, before the IP DA is reached.

Bert

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 18 Nov 2014 02:42:13 +0000

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Jeroen Massar

> For instance they typically do not bother with ICMPv6 as well, why would

It looks to me like RFC 2460 itself followed the "robustness principle," by using the word "node" rather than "router," to cover any and all intermediate boxen, including ones that were still unknown at the time.

Bert

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 18 Nov 2014 04:05:38 +0100

On 2014-11-18 03:42, Manfredi, Albert E wrote:
>> -----Original Message----- From: ipv6
>> [mailto:[email-masked]] On Behalf Of Jeroen Massar
> 
>> The problem is also that middleboxes do not really speak IP in a
>> way. For instance they typically do not bother with ICMPv6 as well,
>> why would they...
> 
> It looks to me like RFC 2460 itself followed the "robustness
> principle," by using the word "node" rather than "router," to cover
> any and all intermediate boxen, including ones that were still
> unknown at the time.

Indeed and why typically the RFCs contain "Node Requirements".

The current "middle boxes", the Load Balancers that do ECMP based
forwarding, do not comply with the IPv6 Node Requirements (properly
handle ICMPv6) though.

And IMHO we do have to handle that properly as they will exist,
otherwise various content networks cannot scale up anymore.

Greets,
 Jeroen

---

From: Ole Troan <[email-masked]>
Date: Mon, 17 Nov 2014 19:45:42 -0800

Fred,

> Can someone give me a good reason to NOT file that erratum?

because there is no way an implementation can skip past an unknown header, unless we declared that every new IP protocol must have the same field layout in the preamble.
extension headers shares the name space with all other IP protocols.
http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml

cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Nov 2014 17:01:29 +1300

Fred,

On 18/11/2014 15:24, Fred Baker (fred) wrote:
>>> I don’t find the text in RFC 791 or 2460; maybe IP is not
>>> required to be robust. However, I will argue that the
>>> following text from RFC 2460 section 4 fails to support
>>> the principle:
>>>> 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,
>>>> with an ICMP Code value of 1 ("unrecognized Next Header
>>>> type encountered") and the ICMP Pointer field
>>>> containing the offset of the unrecognized value within
>>>> the original packet.  The same action should be taken
>>>> if a node encounters a Next Header value of zero in any
>>>> header other than an IPv6 header.
>>> The net effect is that, should one wish to deploy a new
>>> extension header, one cannot reliably use it until every
>>> host and router it will traverse has been updated, which
>>> is in effect “never”. The words “should discard the
>>> packet and” should, in my opinion, be removed, following
>>> the IPv4 model of ignoring an unknown option (RFC 1122
>>> section 3.2.1.8, second paragraph). Send an ICMP if you
>>> like, but don’t prevent communication.
>> Fred,
>> 
>> I haven't re-read RFC 2460 but I'm pretty sure that the
>> preamble "is required to proceed" above is supposed to
>> handle this. A router is only "required to proceed" past
>> the IPv6 header if - the packet is explicitly addressed to
>> (one of) the router's IPv6 address(es) (which was the case
>> for routing headers) - the packet has a hop-by-hop options
>> header
>> 
>> But a router must implement HBH. And if the packet has a
>> routing header then there is not need for the router to
>> look at the header after the RH unless segments left = 0
> Well, I’m not so sure. I’d suggest you re-read
> https://tools.ietf.org/html/rfc2460#section-4
> 
> It doesn’t refer to a router or a host; it refers to a node.

Well yes, but having spoken quite recently to Mr Deering about
this topic, it is quite clear that in his mind middleboxes of
any kind are evil and were assumed not to exist when IPv6 was
designed, and RFC 2460 makes that assumption throughout.

However, RFC 7045 explicitly discusses this topic and does
discuss the question of unknown headers. (We declared unknown
options out of scope.)

Among many other things, we say

"RFC 2460 requires destination hosts to discard packets
containing unrecognised extension headers.  However,
intermediate forwarding nodes SHOULD NOT do this, since that
might cause them to inadvertently discard traffic using a
recently standardised extension header not yet recognised by the
intermediate node.  The exceptions to this rule are discussed next."

So, I am not disagreeing with your point, just observing that it
is partially covered already by RFC 7045. And options are
discussed in draft-gont-6man-ipv6-opt-transmit.

I'm not sure this can be covered by an erratum, but please look
at 7045 and Fernando's draft anyway.

Regards

    Brian

> The context is not “going beyond the IPv6 header to
> TCP-or-whatever”. It is “I processed the base IPv6 header or
> some extension header, for whatever reason I need to go to
> the next extension header, and I don’t understand it.”
> 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |  Next Header  |  Hdr Ext
> Len  | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> So there is no question of being able to step past the next
> header until it finds something it understands. It knows
> where the “next header” identifier and the header length are.
> The thing that raises the point, to me, is the Segment
> Routing Extension Header (which should perhaps be an option
> in the Routing Header, and about which there are several
> opinions). At this point, the ultimate recipient of a message
> with that extension has to be SRH-capable, or the penultimate
> hop has to remove the thing, because of this text.
> 
> Now, everyone gets their own opinion of SRH, and personally
> I’m not sure I see why the considerations of RFC 5095 don’t
> apply. None-the-less, I’m wondering what happens when we do
> get a new extension header. I’m not sure it’s good. If we are
> trying to deploy a new extension header and it is presented
> to an unupdated system, we get a parameter problem, not a
> robust response.
> 
>> But in a world with middle-boxes the text can be
>> misinterpreted to also apply to those middleboxes. AFAIK
>> that was not the intent. Thus I think a clarification is in
>> order.
> 
> What clarification would you suggest? That the packet be
> dropped, or that the node that thinks it needs to continue on
> its way (perhaps a router addressed in the destination
> address looking to see if a Routing Header is present, for
> example, or a firewall that mistakenly thinks that combing
> through TCP headers makes sense) should attempt to skip the
> header?
> 
> There is, of course, a security consideration. An interesting
> attack would be to use an unknown header option, or an
> incorrect length, to send the system that receives it into
> la-la-land. We already have that attack in the extensions and
> options we have.
> 
>> Thanks, Erik
>> 
>>> Note that this is not true of an option carried within an
>>> extension header.
>>> https://tools.ietf.org/html/rfc2460#section-4.2 gives the
>>> sender the option of declaring that an option may be
>>> skipped or must result in packet discard, and gives three
>>> cases for possible notification of the sender.
>>> 
>>>  IETF IPv6 working group mailing list [email-masked] 
>>> Administrative Requests:
>>> https://www.ietf.org/mailman/listinfo/ipv6 
>>  IETF IPv6 working group mailing list [email-masked] 
>> Administrative Requests:
>> https://www.ietf.org/mailman/listinfo/ipv6 
> ------------------------------------------------------------------------
> 
> 
>  IETF IPv6 working group mailing list [email-masked] 
> Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Tue, 18 Nov 2014 13:09:09 +0000

> I'm not sure I got all the details of SR right.

I think you did ... ;-)

> isn't it essentially a SR domain in the middle?

yes.

> so that on SR domain entry encapsulation is added, and on SR domain exit it is decapsulated?

correct. You have two options here:

1. encapsulate the packet into an outer v6-header+srh
2. insert a new srh into the existing packet

in both cases:

. the packet delivered to the destination is the same as the one originated at the source
. you increase the size of the packet while transiting into a sr core.

 This is what we're doing for a few years now with GRE, MPLS, ... and any other encap.

Obviously, I'm not saying that the mtu problem doesn't exist, I'm just saying that in most practical cases, and due to core mtu sizes, it has not been reported as an issue by operators. At least, not reported as an issue preventing adoption and deployments.

> if it adds a new IPv6 header + SR, or injects SR in existing IPv6 packet, as long as it is restored on exit I guess it wouldn't matter. it would just be like a tunnel, wouldn't it?

yes.

> if it looks like a tunnel then the SR domain entry point would send a PMTUD back, or one would have to ensure that the SR domain had a well managed MTU so that this doesn't happen.

correct. 

s.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 18 Nov 2014 10:05:35 -0800

> Well, I’m not so sure. I’d suggest you re-read https://tools.ietf.org/html/rfc2460#section-4
That section says

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

Given that a router (or the typical middlebox for that matter) isn't 
identified in the DA field, they should not examine the extension headers.

> It doesn’t refer to a router or a host; it refers to a node. The context is not “going beyond the IPv6 header to TCP-or-whatever”. It is “I processed the base IPv6 header or some extension header,…

The earlier text you quoted didn't say "for whatever reason" but instead 
said "a node is required to proceed to the next header" which IMHO ties 
back to the earlier text in section 4.

So while RFC 2460 is silent on middleboxes, it does describe how hosts 
and routers should work and I don't see any text which implies that a 
router should drop packets with unknown extension headers.

> What clarification would you suggest? That the packet be dropped, or that the node that thinks it needs to continue on its way (perhaps a router addressed in the destination address looking to see…
RFC 7045 seems to already clarify what I had in mind - that middleboxes 
such as firewalls should not automatically drop packets with extension 
headers but instead do this as part of an explicitly configured policy.

I don't know if there is something we can do to get the readers of RFC 
2460 also read RFC 7045.
> There is, of course, a security consideration. An interesting attack would be to use an unknown header option, or an incorrect length, to send the system that receives it into la-la-land. We alread…

And we had the same issue with IPv4 option length 20+ years ago.

Regards,
    Erik

---

From: James Woodyatt <[email-masked]>
Date: Tue, 18 Nov 2014 10:41:44 -0800

Before you file that erratum, have a look at RFC 6564, which is listed as
an update to RFC 2460.

On Mon, Nov 17, 2014 at 5:25 PM, Fred Baker (fred) <[email-masked]> wrote:

> Before I file an erratum on RFC 2460, I’d like to get the working groups
> I don’t find the text in RFC 791 or 2460; maybe IP is not required to be
> robust. However, I will argue that the following text from RFC 2460 section
> 4 fails to support the principle:
>
> The net effect is that, should one wish to deploy a new extension header,
> one cannot reliably use it until every host and router it will traverse has
> been updated, which is in effect “never”. The words “should discard the
> packet and” should, in my opinion, be removed, following the IPv4 model of
> ignoring an unknown option (RFC 1122 section 3.2.1.8, second paragraph).
> Send an ICMP if you like, but don’t prevent communication.
>
> Note that this is not true of an option carried within an extension
> header. https://tools.ietf.org/html/rfc2460#section-4.2 gives the sender
> the option of declaring that an option may be skipped or must result in
> packet discard, and gives three cases for possible notification of the
> sender.
>

-- 
james woodyatt <[email-masked]>
Nest Labs, Communications Engineering

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Nov 2014 08:40:16 +1300

> Before you file that erratum, have a look at RFC 6564, which is listed as

However, that doesn't really solve the problem, which is why RFC
7045 also updates 2460.

   Brian

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 18 Nov 2014 19:44:08 +0000

On Nov 18, 2014, at 10:41 AM, James Woodyatt <[email-masked]> wrote:

> Before you file that erratum, have a look at RFC 6564, which is listed as an update to RFC 2460.

What it says about skipping headers is:

7.  Security Considerations

   This document proposes a standard format for the IPv6 extension
   headers that minimizes breakage at intermediate nodes that inspect
   but do not understand the contents of these headers.  Intermediate
   nodes, such as firewalls, that skip over unknown headers might end up
   allowing the setup of a covert channel from the outside of the
   firewall to the inside using the data field(s) of the unknown
   extension headers.

---

From: James Woodyatt <[email-masked]>
Date: Tue, 18 Nov 2014 12:13:48 -0800

I'm not sure RFC 2460 is in error.

p1. Fred starts with the Segment Routing Header, which is not proposed to
be a new extension header, but rather a new subtype of the existing Routing
Header. We could have a similar conversation to this one about the
deployability of new RH types, but that's not what I think Fred is talking
about.

p2. Fred notes that IP is not robust, and I hope nobody is surprised to
discover it at this late date. The principle purpose of a firewall is to
allow the network to prevent destination hosts from being liberal in what
they receive. Does anyone think RFC 2460 is in error for failing to note
that the robustness principle doesn't apply to IPv6 because firewalls?

p3. One might note that TCP could be regarded as robust in general, but TCP
in the form of TCP/IP isn't robust, because IP (both 4 and 6) has firewalls
designed to thwart liberalism.  Is RFC 793 in error for failing to note
that?

On the specific question of whether routers must be updated to support a
new extension header, one imagines that the answer depends on whether the
new header is defined with behavior that requires routers to process it.
As RFC 6564 notes, there are some hurdles that must be jumped before such a
mechanism could be defined as a new extension header as opposed to a new
subtype of an existing extension header.

One practical consideration is that firewalls (not necessarily routers) are
almost certain to drop any packets with unknown extension headers, so it's
certainly the case that a new extension header isn't deployable without
updating all the firewalls to know about it.  That doesn't mean we can't
deploy new extension headers or that routers cannot skip them to get at the
transport header for whatever reason they may have for doing so.  It just
means that firewalls are generally incompatible with anything in the packet
they don't understand, new extension headers among them, and that's sorta
what they're good at being. So, where is there an error?

On Tue, Nov 18, 2014 at 11:40 AM, Brian E Carpenter <
[email-masked]> wrote:

> header,

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 18 Nov 2014 20:29:15 +0000

On Nov 18, 2014, at 12:13 PM, James Woodyatt <[email-masked]> wrote:
> p1. Fred starts with the Segment Routing Header, which is not proposed to be a new extension header, but rather a new subtype of the existing Routing Header. We could have a similar conversation to this one about the deployability of new RH types, but that's not what I think Fred is talking about.

You might want to look at that draft again. It is not proposing an option in the routing header, which it perhaps should; it is proposing, well, in its words:

   Segment Routing can be applied to the IPv6 data plane with the
   addition of a new type of Routing Extension Header.  This draft
   describes the Segment Routing Extension Header Type and how it is
   used by SR capable nodes.

https://tools.ietf.org/html/draft-previdi-6man-segment-routing-header
  "IPv6 Segment Routing Header (SRH)", Stefano Previdi, Clarence Filsfils,
  Brian Field, Ida Leung, 2014-11-12,

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Nov 2014 10:32:54 +1300

>   Brian Field, Ida Leung, 2014-11-12,

I think that's a drafting error, but it doesn't change the
argument much (and yes, we did discuss future routing header
types in RFC 7045, so either way the point is already covered
there).

   Brian

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 18 Nov 2014 21:54:25 +0000

On Nov 18, 2014, at 1:32 PM, Brian E Carpenter <[email-masked]> wrote:

> I think that's a drafting error, 

Again, go read the draft. If they didn’t intend it to be an extension header, they pretty thoroughly screwed the pooch.

https://tools.ietf.org/html/draft-previdi-6man-segment-routing-header-04#section-5.2

---

From: Ole Troan <[email-masked]>
Date: Tue, 18 Nov 2014 14:08:37 -0800

Fred,

> Again, go read the draft. If they didn’t intend it to be an extension header, they pretty thoroughly screwed the pooch.

I'm not quite sure what "screwing the pooch" means, but from a quick guess I'd probably best not knowing. ;-)

the draft is a little unclear, but since it asks for a routing type 4, that matches the routing header registry, and it appears quite obvious that it is a new routing header type, rather than a brand new extension. so this would be protocol type 43, routing type 4.

https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xml

cheers,
Ole

---

From: James Woodyatt <[email-masked]>
Date: Tue, 18 Nov 2014 14:19:17 -0800

Fred, I looked at the draft again, and I'm not seeing what you mean. What
does "option in the routing header" mean to you? The draft proposes to
assign a new routing header type, not a new class of extension header.

On Tue, Nov 18, 2014 at 12:29 PM, Fred Baker (fred) <[email-masked]> wrote:

> > p1. Fred starts with the Segment Routing Header, which is not proposed
> to be a new extension header, but rather a new subtype of the existing
> Routing Header. We could have a similar conversation to this one about the
> You might want to look at that draft again. It is not proposing an option
> in the routing header, which it perhaps should; it is proposing, well, in
> its words:
>

---

From: Fernando Gont <[email-masked]>
Date: Sat, 22 Nov 2014 04:35:43 -1000

Hi, Fred,

On 11/17/2014 04:24 PM, Fred Baker (fred) wrote:
>> 
>> I haven't re-read RFC 2460 but I'm pretty sure that the preamble 
>> "is required to proceed" above is supposed to handle this. A
>> router is only "required to proceed" past the IPv6 header if -
>> the packet is explicitly addressed to (one of) the router's IPv6
>> address(es) (which was the case for routing headers) - the packet
>> has a hop-by-hop options header
>> 
>> But a router must implement HBH. And if the packet has a routing 
>> header then there is not need for the router to look at the
>> header after the RH unless segments left = 0 (i.e., the router is
>> at the final destination of the RH path).
>> 
> It doesn’t refer to a router or a host; it refers to a node. The 
> context is not “going beyond the IPv6 header to TCP-or-whatever”.
> It is “I processed the base IPv6 header or some extension header,
> for whatever reason I need to go to the next extension header, and
> I don’t understand it.”
> 
> |  Next Header  |  Hdr Ext Len
> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

They don't. Please check
<http://tools.ietf.org/id/draft-gont-6man-ipv6-universal-extension-header-01.txt>

> Now, everyone gets their own opinion of SRH, and personally I’m
> not sure I see why the considerations of RFC 5095 don’t apply. 
> None-the-less, I’m wondering what happens when we do get a new 
> extension header. I’m not sure it’s good. If we are trying to
> deploy a new extension header and it is presented to an unupdated
> system, we get a parameter problem, not a robust response.

This is also discussed in the aforementioned I-D.

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

---

From: Fernando Gont <[email-masked]>
Date: Sat, 22 Nov 2014 04:38:16 -1000

Hi, Ole,

On 11/17/2014 05:45 PM, Ole Troan wrote:
[....]
> 
> because there is no way an implementation can skip past an unknown
> header, unless we declared that every new IP protocol must have the
> same field layout in the preamble.

Or that we do this:

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 23 Nov 2014 07:58:10 +1300

> <http://tools.ietf.org/id/draft-gont-6man-ipv6-universal-extension-header-01.txt>

In any case it's IMHO a lot more complicated than an erratum in 2460
can possibly fix; we already have two RFCs that update 2460 in this
area (6564, 7045) and three normative drafts (draft-gont-opsec-ipv6-eh-filtering,
draft-gont-6man-ipv6-opt-transmit, draft-gont-6man-ipv6-universal-extension-header).
Plus approved and proposed updates to the routing header.

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Sat, 22 Nov 2014 04:59:07 -1000

> a length stored in 16bits or so, there is little one can do here.

We tried to address this in:
<http://tools.ietf.org/id/draft-gont-6man-ipv6-universal-extension-header-01.txt>

> https://www.sixxs.net/faq/sixxs/?faq=sixxsd

Thanks! ;-)

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Sun, 23 Nov 2014 04:46:03 -1000

> Plus approved and proposed updates to the routing header.

Fully agree.

Thanks,