Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08

Stefano,

Your case below falls under the "acting on behalf of the endpoint"
approach, IMO.

I'm comfortable with the current proposed resolution, which IMO allows
for enterprises to "create" the IP header in whatever distributed system
they want.

The only rule is simple: that enterprise must act like a host in total,
i.e., it must follow node requirements.

If you do that, then nobody will care how you implement header creation.

Joe


On 3/15/2017 8:55 AM, Stefano Previdi (sprevidi) wrote:
> Suresh,
>
> I appreciate your effort and I’m obviously interested into finding a way out 
> from this issue.
>
> To my view, due to the work that has been initiated in 
> drat-ietf-6man-segment-routing-header and recently in 
> draft-filsfils-srv6-network-programming, the current text of RFC2460 (i.e., 
> not the “bis” version) is good enough.
>
> RFC2460 section 4 states:
>
>    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.
>
> Now, RFC2460 has been written almost 20 years ago and since then, both 
> technology and network operators requirements have evolved.
>
> We do have today use cases where not only the source of a packet should be 
> allowed to insert a header but also the source “domain” of a packet. I’ll try 
> to explain.
>
> In a domain controlled by a single organization (typically the set of ASs 
> under control of the same operator) a packet enters at the edge where the 
> ingress node applies a policy resulted into an additional outer ipv6 header 
> that may or may not contain an extension header. Bottom line, the outer 
> header means that now, it is a NEW packet, originated by the ingress node, 
> with SA/DA representing the nodes that are inside the operator domain. 
> Therefore, we can say that this new packet (formed by an outer header and 
> encapsulated original packet) is now owned by the operator and whatever the 
> operator does with this packet:
>
> . The packet MUST leave the operator network in the exact same shape/format 
> as it entered (i.e.: outer encapsulation removed).
> . The outer header MAY change while in transit in the operator’s domain. 
> Moreover, a header MAY be inserted while inside the operator’s domain 
> (knowing that outer header and any other inserted header would be removed at 
> egress). This means that an SRH MAY be inserted at the same time the outer 
> header is added but it can also be that the ingress adds the outer header and 
> some other node inserts an SRH (e.g.: fast reroute within operator’s 
> infrastructure).
> . While in transit, the operator network must handle aspects like MTU 
> properly, taking into account the increased size of the packet.
>
> So, this use case enlarge the rule for header insertion.
>
> Originally RFC2460 stated that only the source of the packet is entitled to 
> add an EH. Now we’re going to propose that the source “domain” of the packet 
> is allowed to insert EHs. The source domain being the set of nodes (including 
> the ingress node adding the outer header) under common administration. This 
> also implies that when the packet leaves the domain, it must recover its 
> original format/shape.
>
> In order to have a more productive discussion, we are writing a draft on 
> header insertion that will be submitted as soon as the windows re-open 
> (during ietf week).
>
> In the mean time, I think it is way too premature to come to conclusion on 
> what text should be used for RFC2460bis and I recommend that the current text 
> is left unchanged until we figured out what to do with EH insertion.
>
> Thanks.
> s.
>
>
> > On Mar 15, 2017, at 3:47 AM, Suresh Krishnan 
> > <suresh(_dot_)krishnan(_at_)ericsson(_dot_)com> wrote:
> >
> > Thanks to everyone who commented during the IETF Last Call of 
> > draft-ietf-6man-rfc2460bis-08. The IETF last call discussion for this draft 
> > was mainly focused around the text in Section 4 that discusses the handling 
> > of extension headers. The biggest concern raised was that the current text 
> > is ambiguous on whether header insertion is allowed on intermediate nodes or 
> > not. There were some people arguing that an explicit prohibition is not 
> > necessary as the text is already clear, while others believed that 
> > explicitly listing the prohibitions will minimize any misunderstandings in 
> > the future. There was also a small number of people who wanted to explicitly 
> > allow header insertion and describe how to do it, but this was clearly out 
> > of scope for this draft (but may be in scope for future work in 6man). 
> > Overall, no one argued against the fact that the intent of the text in 
> > RFC2460 was to forbid insertion of extension headers on any other node but 
> > the source of the packet.  The only a!
 rgument made against adding clarifying text was that the text was already 
clear. Given this, I believe there is consensus to add explicit text about 
header insertion into the draft before it progresses further. I have discussed 
this with the editor and the document shepherd and would like to propose the 
following text change.
> > OLD (from -08):
> >
> > The insertion of Extension Headers by any node other than the source
> > of the packet causes serious problems.  Two examples include breaking
> > the integrity checks provided by the Authentication Header Integrity
> > [RFC4302], and breaking Path MTU Discovery which can result in ICMP
> > error messages being sent to the source of the packet that did not
> > insert the header, rather than the node that inserted the header.
> >
> > One approach to avoid these problems is to encapsulate the packet
> > using another IPv6 header and including the additional extension
> > header after the first IPv6 header, for example, as defined in
> > [RFC2473]
> >
> > With one exception, extension headers are not 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...
> >
> > NEW:
> >
> > With one exception, extension headers are not examined, processed,
> > inserted, or deleted 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...
> >
> > Please feel free to comment either privately or on list if you have any 
> > concerns with this resolution going forward.
> >
> > Regards
> > Suresh
> >
> > P.S.: There were also other editorial issues that were raised during last 
> > call and they should be addressed in the next version of the 
> > draft--------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6(_at_)ietf(_dot_)org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------