Re: Which use cases are using direct EH insertion?

[Tim Chown <[e-mail]>]

Hi Mark,

> On 26 Jul 2016, at 15:28, Mark Smith <[e-mail]> wrote:
> 
> On 26 July 2016 at 23:17,  <[e-mail]> wrote:
>> Tim,
>> 
>>> I’m still not clear as to where in any current IETF RFC/I-D there is text stating that a new EH should be inserted into an existing packet traversing a path, rather than encapsulated.
>>> 
>>> For the Type 4 RH used for Segment Routing, in draft-ietf-6man-segment-routing-header-01 it says in Section 2:
>>> 
>>> " 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.
>>>  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.”
>>> 
>>> and then in Section 2.2.1:
>>> 
>>> "The outer header with the SRH is no different from any other
>>>  tunneling encapsulation mechanism and allows a network operator to
>>>  implement traffic engineering mechanisms so to efficiently steer
>>>  traffic across his infrastructure."
>>> 
>>> So that implies encapsulation.
>>> 
>>> For the Type 3 RH used in RPL, in RFC6554 it says in Section 2:
>>> 
>>> “There are two cases that determine how to include an SRH when a RPL
>>>  router requires the use of an SRH to deliver a datagram to its
>>>  destination.
>>> 
>>>  1.  If the SRH specifies the complete path from source to
>>>      destination, the router places the SRH directly in the datagram
>>>      itself.
>>> 
> 
> This one sounds to me like it is saying routers insert the SRH into an
> existing packet, as routers don't originate packets, hosts do (or the
> host component of a router i.e., the control plane.).

I think this is the point that Michael was reviewing in draft-richardson-roll-useofrplinfo-2460bis-01, looking at a variety of flow scenarios, on the assumption it’s all encap with no direct insertion, i.e. his draft says "This document assumes the rule that a Header cannot be inserted or removed on the fly inside an IPv6 packet that is being routed.”  
 
>>>  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 also implies encapsulation.
>>> 
>>> So who is actually doing direct EH insertion into packets today? Am I misinterpreting the above documents, or are there use cases that are not being standardised in IETF documents?
>> 
>> Indeed, which is leaves me unconvinced that any changes are needed with regards to the perceived ambiguity.
>> Any proposal of header injection would have to stand on its own feet.
>> 
>> Cheers,
>> Ole

Best wishes,
Tim

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