Re: Revision of draft-gont-6man-ipv6-universal-extension-header

["C. M. Heard" <[e-mail]>]

Greetings Fernando,

My thanks to you and your co-authors for continuing with this 
initiative.  In response to your request for feedback, I would like 
first to discuss a quasi-editorial issues, and then provide my view 
of the preferred solution.

In Section 4, Implications, you state:

   Since there is no way for a node to process IPv6 extension 
   headers that employ unknown next header values, an IPv6 host that 
   receives a packet that employs a new IPv6 extension header will 
   not be able to parse the IPv6 header chain past that unknown 
   extension header, and hence it will drop the aforementioned 
   packet.

It seems to me that this is not really a problem, since RFC 2460 
Section 4 already mandates that a host discard packets with 
extension headers that it does not recognize:

   If, as a result of processing a header, a node is required to 
   proceed to the next header but the Next Header value in the 
   current header is unrecognized by the node, it should discard the 
   packet and send an ICMP Parameter Problem message to the source 
   of the packet, with an ICMP Code value of 1 ("unrecognized Next 
   Header type encountered") and the ICMP Pointer field containing 
   the offset of the unrecognized value within the original packet.  
   The same action should be taken if a node encounters a Next 
   Header value of zero in any header other than an IPv6 header.

The paragraph above does use the word "node" rather than "host" but 
in the context of RFC 2460 it does refer specifically to an end 
system ("the node [...] identified in the Destination Address field 
of the IPv6 header").

As far as I am aware, there have been no updates to the IPv6 
specifications requiring or even suggesting that end systems should 
ever try to skip over extension headers that they do not recognize.  
The problem exists only for middleboxes that examine and act on 
extension headers, so I recommend that this draft drop all 
discussion of end systems.

Furthermore, I don't see how the extension header problem discussed 
in this draft impedes deployment of transport protocols.  To be 
sure, here are problems with middleboxes filtering out transport 
protocols that they don't know, but that is an issue even without 
extension headers.

I therefore suggest the following replacement for Section 4 of your 
draft:

   The current impossibility to parse an IPv6 header chain that 
   includes unknown Next Header values results in concrete 
   implications for the extensibility of the IPv6 protocol, and the 
   deployability of IPv6 extension headers.  Specifically, a 
   middlebox that needs to process the transport-protocol header 
   will be faced with the dilemma of what to do with packets that 
   employ unknown Next Header values.  Since it will not be able to 
   parse the IPv6 header chain past the unknown Next Header, it is 
   very likely that it will drop such packets.

   We believe that the current situation has implications that are
   generally overlooked, and that, whatever the outcome, it should be
   the result of an explicit decision by our community, rather than
   simply "omission".

BTW, I strongly agree with that last paragraph (which I did not 
change).

Now to solution space.  A couple of months ago, in this message

http://www.ietf.org/mail-archive/web/ipv6/current/msg20215.html

I acted on Brian Carpenter's suggestion to examine whether any of 
the existing extension headers could not have been equally well 
implemented by one of the following:

- hop-by-hop option
- destination option
- upper-layer header

My conclusion -- subject to provisos that the Destination Options 
header be allowed to appear more than twice and that constraints be 
allowed regarding the order in which destination options could 
appear -- was that the only extension headers that had really good 
reasons for being extension headers rather than one of the above 
were the Fragment Header and the Authentication Header, and AH was 
so classified only because it is shared with IPv4, which has no 
analog to the Destination Options header.  Based on that, I would be 
perfectly comfortable with the solution proposed in Section 5.3, 
i.e., prohibiting new extension headers.  That would largely(*) 
obsolete RFC 6564.

As for the other alternatives, I can't see any technical reason why 
the Destination Options header (subject to the provisos stated 
above) could not be used under any circumstance when the UEH 
(Section 5.1) would be wanted.  And given the previous history

  "Yes we wanted to do this as well, but the WG didn't want to waste 
   a protocol number for something that may never be used"

when RFC 6564 was being developed (see Suresh Krishnan's message 
http://www.ietf.org/mail-archive/web/ipv6/current/msg20168.html), it 
would require a remarkable turnaround to get consensus for the range 
of values alternative (Section 5.2).

That being said, I can live with any of the alternatives suggested 
in the draft.

If we are unable to come to consensus on any of those alternatives 
(which IMHO would be an unfortunate outcome), I think we should at 
least publish advice to implementors of middleboxes that any 
unrecognized Next Header value SHOULD be treated as if it indicates 
the presence of an unknown upper-layer header, and that they MUST 
have a configuration option to pass packets containing such values 
(as specified in RFC 7045).  Accompanying that should be an 
admonition to protocol designers to plan for such behavior.

See also Brian Carpenter's message

http://www.ietf.org/mail-archive/web/ipv6/current/msg20285.html

for more discussion of this issue.

Thanks and regards,

Mike Heard

(*) As far as I can tell, the one part of RFC 6564 that would not be 
obsoleted by such a move is this:

   New options for the existing Hop-by-Hop Header SHOULD NOT be 
   created or specified unless no alternative solution is feasible. 
   Any proposal to create a new option for the existing Hop-by-Hop 
   Header MUST include a detailed explanation of why the hop-by-hop 
   behavior is absolutely essential in the document proposing the 
   new option with hop-by-hop behavior.

On Tue, 8 Apr 2014, Fernando Gont wrote:
> Folks,
> 
> We have published a revision of the aforementioned I-D. It is available
> at:
> <http://www.ietf.org/internet-drafts/draft-gont-6man-ipv6-universal-extension-header-01.txt>
> 
> This version hopefully does a better job about describing the problem,
> and also, rather than focusing on a single solution, it describes three
> possible alternative solutions, with pros and cons.
> 
> We'd like to receive feedback on this document, including feedback on
> which of the possible solutions is deemed as the most appropriate.
> 
> Thanks so much!
> Fernando et al
> 
> 
> 
> 
> -------- Original Message --------
> Subject: New Version Notification for
> draft-gont-6man-ipv6-universal-extension-header-01.txt
> Date: Tue, 08 Apr 2014 03:39:07 -0700
> From: [e-mail]
> To: Fernando Gont <[e-mail]>, "Shucheng LIU (Will)"
> <[e-mail]>, "Suresh Krishnan"
> <[e-mail]>, Hagen Paul Pfeifer
> <[e-mail]>, Will (Shucheng) Liu
> <[e-mail]>, "Hagen Paul Pfeifer"
> <[e-mail]>, Suresh Krishnan
> <[e-mail]>, "Fernando Gont" <[e-mail]>
> 
> 
> A new version of I-D, draft-gont-6man-ipv6-universal-extension-header-01.txt
> has been successfully submitted by Fernando Gont and posted to the
> IETF repository.
> 
> Name:		draft-gont-6man-ipv6-universal-extension-header
> Revision:	01
> Title:		IPv6 Universal Extension Header
> Document date:	2014-04-08
> Group:		Individual Submission
> Pages:		10
> URL:
> http://www.ietf.org/internet-drafts/draft-gont-6man-ipv6-universal-extension-header-01.txt
> Status:
> https://datatracker.ietf.org/doc/draft-gont-6man-ipv6-universal-extension-header/
> Htmlized:
> http://tools.ietf.org/html/draft-gont-6man-ipv6-universal-extension-header-01
> Diff:
> http://www.ietf.org/rfcdiff?url2=draft-gont-6man-ipv6-universal-extension-header-01
> 
> Abstract:
>    This document analyzes a problem in the Uniform Format for IPv6
>    Extension Headers specified in RFC 6564, which results in nodes not
>    being able to process an IPv6 Header Chain if it contains an
>    unrecognized IPv6 Extension Header that follows the aforementioned
>    Uniform Format.  It analyzes the implications of the aforementioned
>    problem, and discusses a number of possible solutions, including the
>    specification of a new IPv6 Extension Header - the Universal
>    Extension Header - that overcomes the aforementioned issues.
> 
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> 
> 
> 
>