Subject: Requesting adoption of draft-krishnan-ipv6-exthdr-06.txt as wg item

From: Suresh Krishnan <[email-masked]>
Date: Tue, 14 Oct 2008 18:14:36 -0400

Hi Folks,
   We have resolved all the issues raised during the last IETF meeting 
in the latest version of this draft. We would like the people who had 
issues with the earlier versions of this draft to check if they are OK 
with the changes. The latest version of the draft is available at

http://www.ietf.org/internet-drafts/draft-krishnan-ipv6-exthdr-06.txt

We request the wg and the chairs to consider adopting this draft as a wg 
item.

Thanks
Suresh
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: [email-masked] (Arnaud Ebalard)
Date: Thu, 16 Oct 2008 10:12:53 +0200

Hi,

First, a typo:

> 4.  Exceptions
> 
>    The the Generic IPv6 extension header is generic enough that it is

     ^^^^^^^ 

Then, a comment:

This is version 6 of the draft but I only found a single comment in the
mailing list archive so my question below may already have been done
during a meeting or privately.

Instead of creating a new specific header type and a specific registry
for new allocations, I wonder if it would not be easier (for everyone,
AFAICT) to just consider:

- *currently* existing headers : implementations will have to cope with
  those ones.
- future header: force those to be in the common TLV format (1-byte NH,
  1-byte Length, Data)

In the end, instead of defining "An uniform format for IPv6 extensions
headers" using a new specific type, wouldn't it be easier to just force
future definitions of extension headers to follow the common layout
proposed below. What were the arguments raised privately or during
meetings not to follow that path?

Cheers,

a+

---

From: "Erik Kline" <[email-masked]>
Date: Thu, 16 Oct 2008 02:13:31 -0700

> meetings not to follow that path?

One of the issues is the "cross-pollution" of IPv6 header number space
and IP protocol number space.  IPv6 headers are indistinguishable from
higher layer protocols.  I'm thinking of a new end-node header that a
firewall might block for lack of recognition when in fact the higher
layer protocol might be recognizable (TCP, UDP, ...).  With the
introduction of a separation between the two more policy choices
become possible.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: [email-masked] (Arnaud Ebalard)
Date: Thu, 16 Oct 2008 15:09:38 +0200

Hi Erik,

"Erik Kline" <[email-masked]> writes:

> [snip]
> and IP protocol number space.

yes.

> IPv6 headers are indistinguishable from higher layer protocols.

In the network, they are. But at the end of the path, the destination
will make the distinction.

> I'm thinking of a new end-node header that a firewall might block for
> lack of recognition when in fact the higher layer protocol might be
> recognizable (TCP, UDP, ...).

I see your point, but ... if it is not able to parse an unknown
extension header before the upper layer, then, trying to interpret this
upper layer based on its *local and partial understanding of the
context* looks like a bad idea to me. Just consider the case of a
RH2-carried or HAO in DestOpt-carried TCP packet which has an invalid
checksum during transport. 

L4 is an E2E matter. Deep inspection in the network, like NAT, are
*usually* just bad ideas that kill E2E (IMHO).

I understand the logic for having a common header format for IPv6
extension headers (parsing, code reuse, easier dissection when
debugging) and a different number space, but I just don't buy the FW
argument.

> With the introduction of a separation between the two more policy
> choices become possible.

yes.

Just to clarify my position, I think the draft is a good idea. It would
have been better to have that format for extensions defined that way
from the beginning in IPv6 specification ;-)

Cheers,

a+

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 17 Oct 2008 14:17:25 -0400

Hi Arnaud,
   Thanks for your comments. Please see responses inline.

> *usually* just bad ideas that kill E2E (IMHO).

We agree with you, but the point is that extension headers are an L3 
matter. If we cannot distinguish between unknown extension headers (L3 
matter) from unknown transport protocols (L4 matter), we will end up 
jeopardizing future transport protocols. This also allows for security 
policy to differentiate between unknown extension headers and unknown 
transport protocols. If the extension header transforms the packet in 
some way, I agree with you that it does not make sense to proceed any 
further up the stack to analyze a packet.

> from the beginning in IPv6 specification ;-)

Thanks for your support.

Cheers
Suresh

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 21 Oct 2008 09:38:14 +0200

Hello,

> http://www.ietf.org/internet-drafts/draft-krishnan-ipv6-exthdr-06.txt

Some comments:

* If I understand correctly, this now proposes to merge all future new IPv6
options into a single header type. Is it implicitly assumed that hop-by-hop
options will be deprecated completely? If not, won't this adversely affect
routers that will have to parse all GIEH packets on the slow path? If yes,
should this not mention it or refer to any appropriate hop-by-hop
deprecation document?

* I realize this is Work In Progress, but option formatting guidelines (as
RFC2460 has) would probably make sense.

* I am suspicious about "blaming" the Fragment Header in the document. As
far as I know, the fragment header cannot be extended (and it cannot be
deprecated/replaced either), so it should be a non-issue in this context. 

* Routing Header seems to be in a similar situation. If I understand the
"problem", only Dst header and HbH header are "broken", no?

Regards,

-- 
Rémi Denis-Courmont