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

[Fernando Gont <[e-mail]>]

Hi, Mike,

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


On 04/19/2014 01:51 PM, C. M. Heard wrote:
> 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.

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.


> 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").

Not really. It could be a router, if the packet used a Routing 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.

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.


> 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.

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.



> 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).

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


> 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.

Point taken.



> 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.

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
> 
>   "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).

Me, I fully agree.



> 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.

Agreed.


> (*) 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.

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: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1