Subject: RFC2460bis and draft-previdi-6man-segment-routing-header-08

From: Brian E Carpenter <[email-masked]>
Date: Sat, 3 Oct 2015 08:28:54 +1300

Hi,

I'm glad to see this statement in draft-previdi-6man-segment-routing-header-08:

>    While the source routing model defined in [RFC2460] doesn't mandate
>    which node is allowed to insert (or modify) the SRH, it is assumed in
>    this document that the SRH is inserted in the packet by its source.

Now my reading of RFC 2460 has always been that extension headers are
only created by the source node, but I do agree that the present text is
not explicit on that point.

I would like this to be clarified one way or the other in RFC 2460bis.

   Brian

---

From: Bob Hinden <[email-masked]>
Date: Fri, 2 Oct 2015 14:49:35 -0700

Brian,

> On Oct 2, 2015, at 12:28 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> Hi,
> 

The current relevant text from Section 4. is:

   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.

Where the exception is the hop by hop header (described in the next paragraph).

I also have trouble reading that as allowing any node other than the source node to add them to a packet.

> I would like this to be clarified one way or the other in RFC 2460bis.

How about something like this:

    Extension headers are only allowed to be added to packets at
    the source node.

I think that was always the intent and this would be a clarification to the specification.

Bob

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

---

From: joel jaeggli <[email-masked]>
Date: Fri, 2 Oct 2015 15:27:05 -0700

> I think that was always the intent and this would be a clarification to the specification.

it's very hard to conceive of disallowing on-wire fragmentation without
precluding the addition of headers on intermediate hops.

encapsulation however has no such problem and conveniently tells the
network where the wrapper should be sent to be processed.

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 2 Oct 2015 16:30:54 -0700

> I think that was always the intent and this would be a clarification to the specification.
Bob,
"source node" might not be sufficiently specific in the case of 
tunneling, and "added" can be read as their insertion is somehow 
independent and we want it to be coupled with the insertion of an IPv6 
header.

I think what we want to say is that extension headers can only be placed 
in packets by the same node that is placing the base IPv6 header in the 
packet. Hence they can not be added unless a preceeding IPv6 header is 
also added.

Regards,
    Erik

---

From: Bob Hinden <[email-masked]>
Date: Fri, 2 Oct 2015 16:38:11 -0700

Erik,

> On Oct 2, 2015, at 4:30 PM, Erik Nordmark <[email-masked]> wrote:
> 
> "source node" might not be sufficiently specific in the case of tunneling, and "added" can be read as their insertion is somehow independent and we want it to be coupled with the insertion of an IPv6 header.
> 
> I think what we want to say is that extension headers can only be placed in packets by the same node that is placing the base IPv6 header in the packet. Hence they can not be added unless a preceeding IPv6 header is also added.

Good suggestion.

Thanks,
Bob

---

From: [email-masked]
Date: Mon, 5 Oct 2015 12:06:47 +0200

>> I think what we want to say is that extension headers can only be placed in packets by the same node that is placing the base IPv6 header in the packet. Hence they can not be added unless a precee…

what about:

   1.  If the SRH specifies the complete path from source to
        destination, the router places the SRH directly in the datagram
        itself.

   2.  If the SRH only specifies a subset of the path from source to
       destination, the router uses IPv6-in-IPv6 tunneling [RFC2473] and
       places the SRH in the outer IPv6 header.  Use of tunneling
       ensures that the datagram is delivered unmodified and that ICMP
       errors return to the source of the SRH rather than the source of
       the original datagram.

which is verbatim from RFC6554.

cheers,
Ole

---

From: [email-masked]
Date: Mon, 5 Oct 2015 20:14:32 +0200

> which is verbatim from RFC6554.

sorry, I misread this and made this suggestions for draft-previdi-6man-segment-routing-header. I don't propose the above text for 2460bis.

Best regards,
Ole