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

From: Fernando Gont <[email-masked]>
Date: Tue, 08 Apr 2014 08:07:23 -0300

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: [email-masked]
To: Fernando Gont <[email-masked]>, "Shucheng LIU (Will)"
<[email-masked]>, "Suresh Krishnan"
<[email-masked]>, Hagen Paul Pfeifer
<[email-masked]>, Will (Shucheng) Liu
<[email-masked]>, "Hagen Paul Pfeifer"
<[email-masked]>, Suresh Krishnan
<[email-masked]>, "Fernando Gont" <[email-masked]>

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

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 19 Apr 2014 09:51:10 -0700 (PDT)

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.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 21 Apr 2014 21:19:27 -0300

Hi, Mike,

Thanks so much for your feedback! Please find my comments in-line....

>    Header value of zero in any header other than an IPv6 header.

Good grief. I guess one would just conclude that "it is impossible to
incrementally deploy new EHs".

That said, there's a different assumption that is very widespread in
that one can parse an IPv6 header chain even it it contains new EHs. At
the very least, it would seem that this should be clarified.

> system ("the node [...] identified in the Destination Address field 

Not really. It could be a router, if the packet used a Routing Header.

> discussion of end systems.

I understand your point. Me, I think it would be worthwhile to note that
you cannot really "incrementally deploy" new EHs... at least without an
Universal Extension Header.

> protocols that they don't know, but that is an issue even without 

Right now, there's the misleading assumption (confusion?) that you *can*
parse past unknown EHs. I wouldn't be surprised if a middlebox that
receives a packet with a new transport protocol assumes that the
corresponding header is really an EH, and tries to parse it according to
RFC6564, and hence discard th packet.

> BTW, I strongly agree with that last paragraph (which I did not 

Ok. I'll wait for your response to my comments above -- but will keep
this text in mind for incorporation.

> i.e., prohibiting new extension headers.  That would largely(*) 

Point taken.

> (Section 5.1) would be wanted.

I guess the argument in favor of UEH would be "to leave the door open
for future uses that might need a new EH, but that we cannot think of
today".

>  And given the previous history
> 

Me, I fully agree.

> admonition to protocol designers to plan for such behavior.

Agreed.

>    new option with hop-by-hop behavior.

Agreed. Although some folks have argued that, in such case, we better
incorporate that para into oour document, and obsolete RFC6564.

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 21 Apr 2014 22:51:35 -0700 (PDT)

> Not really. It could be a router, if the packet used a Routing Header.

True, but that does not change my main point: end systems are 
required by 2460 to discard any extension header they don't 
understand, so a UEH does not help them work better.  The problem it 
solves is that of middleboxes being unable to find the upper-layer 
header.

> Universal Extension Header.

Yes, that's true, since the barrier to incremental deployment is 
that middleboxes can't presently parse past them.

Point taken.

//cmh

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 Apr 2014 08:33:16 +1200

On 22/04/2014 17:51, C. M. Heard wrote:
...
>> RFC6564, and hence discard th packet.

But operationally, it doesn't matter. The destination doesn't receive
the packet, and whether the middlebox discarded it because it thought
it was a suspicious extension header or a suspicious transport payload
is of no importance. I would expect firewalls to have a whitelist
of extension headers and a whitelist of transport protocols, and
an unknown extension header or an unknown transport protocol will
be in neither list, so will be discarded.

Please don't forget that RFC 7045 "updates RFC 2460 to clarify how
intermediate nodes should deal with such extension headers and with
any that are defined in the future." A universal extension header
format makes RFC 7045 easier to implement, but doesn't change the
principle. I don't believe any other changes to RFC 2460 are needed
in this area.

   Brian