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

Arnaud Ebalard wrote:

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

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.


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.

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

Thanks for your support.

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

Reply via email to