Re: Next steps on advancing core IPv6 specifications to full Internet standard

[Tim Chown <[e-mail]>]

Hi,

On 22 Nov 2016, at 03:22, Hemant Singh <[e-mail]<mailto:[e-mail]>> wrote:

<snip>

<hs> Inband OAM in an EH.  If encapsulation is used each node in the path of the packet adds a new IPv6 header followed by a Hop-by-Hop (HBH) EH.  The EH includes OAM data.  Now if encapsulation is not used, each node adds a its own EH - at least this is how the FD.io<http://FD.io> Inband was described to me.  Thus all nodes have to be instructed how to add the OAM data using out-of-band mechanisms such as DHCPv6.

The thing is, and I raised it in 6man in Seoul, insertion is not described in the SR architecture or the IPv6 Data Plane drafts.

In draft-ietf-spring-segment-routing-10, the specifics of how the SRH is added are not discussed.

Indeed, that draft says the SRH is “installed” in 8.2: "In the general case, an SR IPv6 router accepts and install segments identifiers (in the form of IPv6 addresses)”.  “Install" is pretty vague.

In draft-ietf-6man-segment-routing-header-02 there is no mention of insertion. In 2.2 it says:

" While the source routing model defined in [RFC2460<https://tools.ietf.org/html/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.
   For example:

   o  At the node originating the packet (host, server).

   o  At the ingress node of an SR domain where the ingress node
      receives an IPv6 packet and encapsulates it into an outer IPv6
      header followed by a Segment Routing header.”


The “For example” of course allows wiggle room, and this text also seems to imply that the authors believe RFC2460 allows insertion on path.   Further, Hemant’s comment says that at least one implementation of IPv6 SR does insertion on path, without it being explicitly defined in a WG draft, yet alone an RFC.


Also, Section 5 (Security Considerations) of draft-ietf-6man-segment-routing-header-02 doesn’t discuss the downsides of header insertion that have been documented in 2460-bis.


So there’s a lot of vagueness about the whole SRH “insertion” issue, partly in the spring WG, partly in 6man, and implementation(s) doing things that are not (as yet, or perhaps never will be?) documented in the IETF.


Tim