Subject: Review of draft-krishnan-ipv6-exthdr-08

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Sat, 25 Sep 2010 17:18:41 +0530

Hi,

I was reading draft-krishnan-ipv6-exthdr-08 and I think it does an incomplete job of fixing IPv6's extension header treatment.

The only thing this draft addresses is the issue of an intermediary that wants to deep inspect the packet. The solution presented is that newer implementations should use the Generic IPv6 Extension Header (GIEH) which would internally carry the new extension header value. Devices that don't understand this new extension header value (one that's inside the GIEH) can look at the GIEH header and skip as many bytes as given in the Hdr Ext Len and continue with parsing the remaining packet. 

If the above understanding is correct, then we really don't need GIEH! Why cant the devices that want to parse the packet and which don't understand a given extension header look at the Header length (specified in the extension header) and skip those many bytes and get on to the remaining packet - how is GIEH improving things?

The reason I said this solution is incomplete is because it still doesn't solve the problem of an end node receiving an IPv6 packet with some extension header that it does not understand. What should it do with the packet? Discard it and send an ICMP error back to the original source? If so, then how do you incrementally deploy new extension headers in a network.

IMO, a complete solution is to standardize the new IPv6 extension headers that are allocated in the future to the following 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  | Hdr Options   |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
   |                                                               |
   .                                                               .
   .                  Header Specific Data                         .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

We have added a 1 byte field called Hdr Options which should contain information about how this extension header must be treated in case the processing node does not recognize the extension header. Note that the processing node can be either a device that's deep inspecting the packets (firewall) or an end-node.

We can define the first two bits as follows:

00 - Skip and continue processing (used for incremental deployments)
01 - Silently discard the packet (could again be used for incremental deployments)
10 - Discard the packet and send ICMP parameter problem message to the source
11 - Discard the packet and send an ICMP error back to the source only if the destination is NOT a multicast address

This solution fixes the problem that GIEH is solving and additionally helps in incrementally introducing new extension headers in the network. 

Cheers, Manav

--
Manav Bhatia,
IP Division, Alcatel-Lucent,
Bangalore - India

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 27 Sep 2010 11:53:15 -0400

Hi Manav,
   Thanks for the comments. Please find responses inline.
> If the above understanding is correct, then we really don't need GIEH! Why cant the devices that want to parse the packet and which don't understand a given extension header look at the Header leng…

Your understanding above is correct, but your conclusion does not 
follow. The problem is that a new extension header may decide to have 
the Header length at another location than the second byte or not have 
one at all. The goal of the GIEH is to force all new extension headers 
to have the Header length at a KNOWN location in order to skip over them

> The reason I said this solution is incomplete is because it still doesn't solve the problem of an end node receiving an IPv6 packet with some extension header that it does not understand. What shou…

Yes. This (discard+ICMP) would be the expected behavior. I do not think 
that extension headers should require any other behavior (please see 
below). I see incremental deployment as requiring two consenting 
end-points talking over an unaware network.

> IMO, a complete solution is to standardize the new IPv6 extension headers that are allocated in the future to the following format:

As specified in RFC2460, if this kind of behavior is required, I think 
it is better to use Destination Options rather than an extension header. 
Quoting straight from there.

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

Thanks
Suresh

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Mon, 27 Sep 2010 21:49:54 +0530

Hi Suresh,

> to have the Header length at a KNOWN location in order to 

I had posted a draft yesterday and is temporarily available here (should get announced in a day or two):

http://www.ietf.org/staging/draft-bhatia-6man-update-ipv6-ext-hdr-00.txt

This proposes a standard format for all IPv6 extension headers so that there is no such ambiguity.

Also, I don't think it's a good idea to let new extensions define the Header length in some arbitrary location as it would become really messy for the HW to parse such packets.

> 
> > 
> > The reason I said this solution is incomplete is because it 
> still doesn't solve the problem of an end node receiving an 
> IPv6 packet with some extension header that it does not 
> understand. What should it do with the packet? Discard it and 
> send an ICMP error back to the original source? If so, then 
> how do you incrementally deploy new extension headers in a network.
> 

Not all the time.

You can look http://tools.ietf.org/id/draft-bhatia-karp-non-ipsec-ospfv3-auth-00.txt for an example of why this may not necessarily be true. 

Also, I think we should have a generalized solution that works for all the cases.

Cheers, Manav

> > IMO, a complete solution is to standardize the new IPv6 
> extension headers that are allocated in the future to the 
> following format:
> > 
> > 0                   1                   2                   3
> > We have added a 1 byte field called Hdr Options which 
> should contain information about how this extension header 
> must be treated in case the processing node does not 
> recognize the extension header. Note that the processing node 
> can be either a device that's deep inspecting the packets 
> (firewall) or an end-node.
> > 
> > 11 - Discard the packet and send an ICMP error back to the 
> source only if the destination is NOT a multicast address
> > 
> > This solution fixes the problem that GIEH is solving and 
> additionally helps in incrementally introducing new extension 
> headers in the network. 
>

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 27 Sep 2010 13:26:27 -0400

Hi Manav,

> This proposes a standard format for all IPv6 extension headers so that there is no such ambiguity.

This is nothing new. That is what draft-ietf-6man-exthdr has also been 
proposing. The original draft draft-krishnan-ipv6-exthdr has been around 
for more than 4 years.

The very first revision published in July 2006 proposed a standard 
format for IPv6 extension headers.

http://tools.ietf.org/html/draft-krishnan-ipv6-exthdr-00

It has evolved into the current version because the WG felt that we 
needed to conserve IP protocol number space and to differentiate between 
new transport protocols and new IPv6 extension headers.

> Also, I don't think it's a good idea to let new extensions define the Header length in some arbitrary location as it would become really messy for the HW to parse such packets.

Right. That is the reason we proposed the GIEH.

> Also, I think we should have a generalized solution that works for all the cases.

It is not clear to me what the problem is. Please state the problem you 
are trying to solve and why draft-ietf-6man-exthdr does not meet the 
purpose. We can then work together to get the issue(s) fixed. The draft 
is in its current state because it solves the following problems

*) Need for a standardized format for new extension headers (for 
efficient parsing and for middlebox skipping)
*) Need to conserve protocol number space (1 allocation for all new 
extension headers vs. 1 allocation per new extension header)
*) Need to differentiate new extension headers from new transport 
protocols (non-GIEH next header value==>New transport protocol)

Thanks
Suresh

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 28 Sep 2010 05:04:46 +0530

Hi Suresh,

> protocols (non-GIEH next header value==>New transport protocol)

Ok, so this clears one doubt that I had which was that we would use GIEH for all new allocations (even new transport protocols). Patently, this is not the case and it will only be used for new v6 extension headers. This sounds good!

My concern with the current format is that it does not help in incrementally introducing new v6 extension headers. I would like to add the following to the list of problems that GIEH currently solves:

*) Some Hdr Options that indicates what a processing node MUST do when it does not recognize the extension header its trying to process (drop/pass/etc). We cannot necessarily assume that it will always be the end node that's trying to process an extension header. You could also have some intermediate node processing extension headers and what if it does not understand them? It (or the end node) could either ignore this (indicated in the Hdr Option) or it could raise hell and drop the packet (again indicated in the Hdr Options).

Thanks, Manav

---

From: "Hing-Kam (Kam) Lam" <[email-masked]>
Date: Tue, 28 Sep 2010 20:22:09 +0530

I think the argument sounds reasonable given that the intent of
draft-ietf-6man-exthdr is to standardize the IPv6 extension headers that
might get proposed in the future.

Kam

On Tue, Sep 28, 2010 at 5:04 AM, Bhatia, Manav (Manav) <
[email-masked]> wrote:

> Ok, so this clears one doubt that I had which was that we would use GIEH
> for all new allocations (even new transport protocols). Patently, this is
> not the case and it will only be used for new v6 extension headers. This
> sounds good!
>
> My concern with the current format is that it does not help in
> incrementally introducing new v6 extension headers. I would like to add the
> following to the list of problems that GIEH currently solves:
>
> *) Some Hdr Options that indicates what a processing node MUST do when it
> does not recognize the extension header its trying to process
> (drop/pass/etc). We cannot necessarily assume that it will always be the end
> node that's trying to process an extension header. You could also have some
> intermediate node processing extension headers and what if it does not
> understand them? It (or the end node) could either ignore this (indicated in
> the Hdr Option) or it could raise hell and drop the packet (again indicated
> in the Hdr Options).
>
> Thanks, Manav
>
> >
> > Thanks
> > Suresh
> >
> >
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 28 Sep 2010 17:56:09 -0400

Hi Manav,

> *) Some Hdr Options that indicates what a processing node MUST do when it does not recognize the extension header its trying to process (drop/pass/etc). We cannot necessarily assume that it will al…

Great. I will open up an issue for this and cover it when I present to 
the WG at the next IETF meeting.

Cheers
Suresh

---

From: Rémi Després <[email-masked]>
Date: Wed, 29 Sep 2010 15:06:37 +0200

Hi,

Le 28 sept. 2010 à 16:52, Hing-Kam (Kam) Lam a écrit :

> ...
> *) Some Hdr Options that indicates what a processing node MUST do when it does not recognize the extension header its trying to process (drop/pass/etc). We cannot necessarily assume that it will always be the end node that's trying to process an extension header. You could also have some intermediate node processing extension headers

> and what if it does not understand them?

As usual, ignoring is in my understanding sufficient.

> It (or the end node) could either ignore this (indicated in the Hdr Option)

(not necessary to indicate it in an option)

> or it could raise hell and drop the packet (again indicated in the Hdr Options).

Practical examples showing that would be important to drop the packet rather than ignoring it would, IMHO, be necessary before considering to delay approval of the current draft.

Regards,
RD