Subject: intermediate routers MUST NOT insert headers

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 22 Oct 2015 10:08:39 +0000

Hi:

The discussion was moving away from its title. I changed it.

1)      In case it is related, I see the words “recommended” lowercase in Bob’s suggestion. Would that one be understood as normative? I think not.
If not, I read the text like “IPv6 encapsulation is the current best practice”.

And if this a just recommendation, what is the alternate? Do we mean just an opening for future technology? Would we allow what Ralph calls subIP that transports IP but does not follow the IP rules?

2)      I agree with Mark’s suggestion that this has impacts in other places.

Another major impact is about fragmentation. Can an intermediate router fragment if it inserts the Frag header by adding in an IP in IP wrapper, to be reassembled by a router down the road?

I’ d think that this defeats the expectations in IPv6. OTOH, how is that different from a configured tunnel. Say I have a tunnel with a low MTU; being a tunnel endpoint, can the ingress router fragment for transmission along the tunnel?

If yes, what’s the difference between the two?

Cheers,

Pascal

From: ipv6 [mailto:[email-masked]] On Behalf Of Mark Smith
Sent: mercredi 21 octobre 2015 23:37
To: Bob Hinden <[email-masked]>
Cc: 6man WG <[email-masked]>; Ralph Droms <[email-masked]>
Subject: Re: RFC2119 Upper Case Syntax for rfc2460bis

Hi,

On 22 Oct 2015 6:25 am, "Bob Hinden" <[email-masked]<mailto:[email-masked]>> wrote:
>
> Brian,
>
> > On Oct 20, 2015, at 6:21 PM, Brian E Carpenter <[email-masked]<mailto:[email-masked]>> wrote:
> >
> >>>
> >>> Overall I think that moving to RFC2119 style has the potential to create problems where they don’t exist today.
> >>
> >> I agree with the points Bob makes and my input is that RFC 2119 style requirements language should not be edited into rfc2460bis.
> >
> > The real issue IMHO is that we must end up with unambiguous text. There are
> > certainly places in the text where there is ambiguity (my favourite is that
> > there is no statement that extension headers are never inserted by intermediate
> > nodes, although I'm dead certain that was the designers' intention). I don't
> > really care how the ambiguities are resolved - it certainly doesn't require upper
> > case to state that something must not happen - but we must resolve them.
> >
>
> I agree that we should add text that extension headers are never inserted by intermediate nodes.  I think I can say it was the designers intent and think it is a clarification.  I also don’t think there are any RFCs that call for the insertion of extension headers, so we wouldn’t be breaking any standards based interoperability.  How about something like this, following the figure showing extension header examples on page 7:
>
>    Extension headers must never be inserted by any node other than the source
>    of the packet.  If there is a requirement to add a header, IPv6 encapsulation is the
>    recommended approach.
>

Separate to that, it might be worth being both more general and more absolute regarding what the source address of the packet means. For example, something like the following text for the source address field description in section 3:

Source Address: 128-bit address of the originator of the packet, where originator means creator of the IPv6 header and its fields' initial values, all extension headers and their initial values, and the entire payload.

Regards,
Mark.

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

---

From: Bob Hinden <[email-masked]>
Date: Thu, 22 Oct 2015 12:42:54 -0700

Pascal,

inline

> On Oct 22, 2015, at 3:08 AM, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> Hi:
> 

I think you may be reading this out of context.  IP encapsulation is the recommended approach for any requirement to add headers to a packet anywhere except at the source.  A good example of this is RFC6554 "An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)"

> And if this a just recommendation, what is the alternate? Do we mean just an opening for future technology? Would weallow what Ralph calls subIP that transports IP but does not follow the IP rules?
> 
> Another major impact is about fragmentation. Can an intermediate router fragment if it inserts the Frag header by adding inan IP in IP wrapper, to be reassembled by a router down the road?

Yes, of course.  A router that is is tunneling can add a fragmentation or any other extension header to the tunneled packet it is sourcing.  The destination as indicated by the destination address in the outer header would reassemble.  These routers acting as the source and destination of the tunneled packets, that is, as hosts.  Note the definition of a router in RFC2460 (unchanged in rfc2460bis)

   router      - a node that forwards IPv6 packets not explicitly
                 addressed to itself.  [See Note below].

Routers that tunnel packets are acting as hosts.

This all explained in detail in RFC2473 "Generic Packet Tunneling in IPv6 Specification”.  Would it be helpful to add a reference to RFC2473 as part of the text about encapsulation?

> I’ d think that this defeats the expectations in IPv6. OTOH, how is that different from a configured tunnel. Say I have a tunnelwith a low MTU; being a tunnel endpoint, can the ingress router fragment for transmission along the tunnel?

See above.

I hope this answers your questions.

Thanks,
Bob

> On 22 Oct 2015 6:25 am, "Bob Hinden" <[email-masked]> wrote:
>> 
>> Brian,
>> 
>>> On Oct 20, 2015, at 6:21 PM, Brian E Carpenter <[email-masked]> wrote:
>>> 
>>>>> 
>> [email-masked]

---

From: Ralph Droms <[email-masked]>
Date: Thu, 22 Oct 2015 16:20:42 -0400

> On Oct 22, 2015, at 3:42 PM 10/22/15, Bob Hinden <[email-masked]> wrote:
> 
> Pascal,
> 
> inline
> 

Bob - "recommended" leaves some room for other ways to add headers.  Are there others?  If not, would it be clearer to write "IP encapsulation used to meet any requirement [...]"?

- Ralph

---

From: Mark Smith <[email-masked]>
Date: Fri, 23 Oct 2015 10:05:42 +1100

On 22 Oct 2015 21:09, "Pascal Thubert (pthubert)" <[email-masked]>
wrote:
> 1)      In case it is related, I see the words “recommended” lowercase in
Bob’s suggestion. Would that one be understood as normative? I think not.
> And if this a just recommendation, what is the alternate? Do we mean just
an opening for future technology? Would we allow what Ralph calls subIP
that transports IP but does not follow the IP rules?
> Another major impact is about fragmentation. Can an intermediate router
fragment if it inserts the Frag header by adding in an IP in IP wrapper, to
be reassembled by a router down the road?

So I think in this case, the router is actually acting as a host (end),
because the source address of the outer IP packet is owned by the
encapsulating router. So it is originating/creating the IP packet, any
extension headers and the entire payload, which happens in this case to be
a copy of another IP packet that it has been given by a higher layer
application.

The other "router" that decapsulates the inner IP packet is also a
host/end, because it owns the destination address of the outer IP packet,
and hands the inner IP packet up to an application, which most likely will
forward it further, but could also drop it or do something else with it,
depending on the upper layer application.

>
> I’ d think that this defeats the expectations in IPv6. OTOH, how is that
different from a configured tunnel. Say I have a tunnel with a low MTU;
being a tunnel endpoint, can the ingress router fragment for transmission
along the tunnel?
> > >>> Overall I think that moving to RFC2119 style has the potential to
create problems where they don’t exist today.
> > >>
> > >> I agree with the points Bob makes and my input is that RFC 2119
style requirements language should not be edited into rfc2460bis.
> > I agree that we should add text that extension headers are never
inserted by intermediate nodes.  I think I can say it was the designers
intent and think it is a clarification.  I also don’t think there are any
RFCs that call for the insertion of extension headers, so we wouldn’t be
breaking any standards based interoperability.  How about something like
this, following the figure showing extension header examples on page 7:
> Separate to that, it might be worth being both more general and more
absolute regarding what the source address of the packet means. For
example, something like the following text for the source address field
description in section 3:
>
> Source Address: 128-bit address of the originator of the packet, where
originator means creator of the IPv6 header and its fields' initial values,
all extension headers and their initial values, and the entire payload.

---

From: Bob Hinden <[email-masked]>
Date: Fri, 23 Oct 2015 08:12:37 -0700

Ralph,

> On Oct 22, 2015, at 1:20 PM, Ralph Droms <[email-masked]> wrote:
> 
> 
> Bob - "recommended" leaves some room for other ways to add headers.  Are there others?  If not, would it be clearer to write "IP encapsulation used to meet any requirement [...]”?

How about something like this:

  Extension headers must never be inserted by any node other than the source
  of the packet.  IP Encapsulation must be used to meet any requirement for
  inserting headers, for example, as defined in RFC2473.

Bob

---

From: Ralph Droms <[email-masked]>
Date: Fri, 23 Oct 2015 11:53:21 -0400

> On Oct 23, 2015, at 11:12 AM 10/23/15, Bob Hinden <[email-masked]> wrote:
> 
> Ralph,
> 

That text is unambiguous and looks fine to me.

- Ralph

---

From: "Liushucheng (Will)" <[email-masked]>
Date: Tue, 27 Oct 2015 12:10:21 +0000

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Bob Hinden
> Sent: Friday, October 23, 2015 3:43 AM
> To: Pascal Thubert (pthubert)
> Cc: IPv6 List; Bob Hinden; Ralph Droms
> Subject: Re: intermediate routers MUST NOT insert headers
> 
> Pascal,
> 
> inline
> 
> I think you may be reading this out of context.  IP encapsulation is the
> recommended approach for any requirement to add headers to a packet
> anywhere except at the source.  A good example of this is RFC6554 "An IPv6
> Routing Header for Source Routes with the Routing Protocol for Low-Power and
> Lossy Networks (RPL)"
> 
> > And if this a just recommendation, what is the alternate? Do we mean just an
> opening for future technology? Would weallow what Ralph calls subIP that
> transports IP but does not follow the IP rules?
> >
> fragment if it inserts the Frag header by adding inan IP in IP wrapper, to be
> reassembled by a router down the road?
> 
> Yes, of course.  A router that is is tunneling can add a fragmentation or any
> other extension header to the tunneled packet it is sourcing.  The destination
> as indicated by the destination address in the outer header would reassemble.
> These routers acting as the source and destination of the tunneled packets, that
> is, as hosts.  Note the definition of a router in RFC2460 (unchanged in
> rfc2460bis)
> 
> This all explained in detail in RFC2473 "Generic Packet Tunneling in IPv6
> Specification”.  Would it be helpful to add a reference to RFC2473 as part of
> the text about encapsulation?

+1. 
I also believe this would be a sensible thing to do.

Regards,
Will (Shucheng LIU)

---

From: Bob Hinden <[email-masked]>
Date: Tue, 27 Oct 2015 10:56:57 -0700

Will,

> On Oct 27, 2015, at 5:10 AM, Liushucheng (Will) <[email-masked]> wrote:
> 

I plan to include that in the -01 version of the draft.

Thanks,
Bob