Re: I-D Action: draft-gont-6man-ipv6-universal-extension-header-01.txt

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

On Wed, 7 May 2014, Fernando Gont wrote:
> On 05/01/2014 10:57 PM, Brian E Carpenter wrote:
> > I've finally understood what's been bothering me about this draft.
> > Actually, two things:
> > 
> > 1. If a node (regardless of whether it's the destination host,
> > or an intermediate node such as a firewall) has a policy
> > of discarding packets with an unknown extension header
> > or an unknown transport protocol, it *doesn't matter* that
> > it can't distinguish them. The packet is discarded anyway.
> > 
> > Comment on that: In either case, this discard by a host is
> > consistent with RFC2460 (even as updated by RFC7045). 
> 
> While I agree that it is consistent with RFC2460, that also implicitly
> means that new EHs are not incrementally deployable. Not only because of
> firewalls, but also because of the hosts themselves. (i.e., if I send
> you my packets with my [shiny] new EH then, if you don't understand it,
> you'd drop the packet).

I don't agree with that at all.  If intermediate systems were 
transparent to EHs, as envisioned by RC 2460, then it would be 
possible for consenting hosts to use them without updates to the 
intervening network.  That counts as incremental deployment to me.

> (another way to see it would be to assume that the reason for which
> RFC2460 says so is because it didn't define a uniform format for EHs in
> the first place?)

I'd be inclined to say RFC 2460 did not bother to define a uniform 
format for EHs because it there was no need: the Destination Options 
header already provided a way to provide optional information that a 
host could skip over (i.e., ignore).  Here is what it said:

   Note that there are two possible ways to encode optional destination
   information in an IPv6 packet: either as an option in the Destination
   Options header, or as a separate extension header.  The Fragment
   header and the Authentication header are examples of the latter
   approach.  Which approach can be used depends on what action is
   desired of a destination node that does not understand the optional
   information:

      o  If the desired action is for the destination node to discard
         the packet and, only if the packet's Destination Address is not
         a multicast address, send an ICMP Unrecognized Type message to
         the packet's Source Address, then the information may be
         encoded either as a separate header or as an option in the
         Destination Options header whose Option Type has the value 11
         in its highest-order two bits.  The choice may depend on such
         factors as which takes fewer octets, or which yields better
         alignment or more efficient parsing.

      o  If any other action is desired, the information must be encoded
         as an option in the Destination Options header whose Option
         Type has the value 00, 01, or 10 in its highest-order two bits,
         specifying the desired action (see section 4.2).

To me, it is obvious that anything UEH can do, a destination option 
can also do, provided that a destination option header is allowed to 
appear as many times as needed.  To see this, consider the proposed 
UEH format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Next Header  |  Hdr Ext Len  |    Subtype    |               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
    |                                                               |
    .                                                               .
    .                   Subtype Specific Data                       .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


If this were encoded as a destination option, it would look like this:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Next Header  |  Hdr Ext Len  |    Subtype    | SubtypDataLen |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                                                               .
    .                   Subtype Specific Data                       .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

True, the subtype would need to have the two upper bits encoded to 
signal to the destination what to do if it does not understand the 
subtype.  But that is a feature, not a bug.  It also requires one 
extra byte for a possibly redundant subtype/option data length.  
One could imagine circumstances in which this would expand the 
header by up to eight bytes.  There is a possible cost in 
efficiency, but not in functionality.

> > In either case, it's what we would expect a firewall to do if it 
> > has the usual sort of paranoid policy, and that again is 
> > consistent with RFC7045.
> 
> I'm not sure I'd agree. in v4, some firewalls do not just filter packets
> for the options they contain, but they do filter based on the {src ip,
> dst ip, protocol, src port, dst port}

If firewalls treat IPv6 destination options as the do IPv4 options, 
then the desired effect is achieved by using the destination options 
header instead of the proposed UEH.

//cmh