 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
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 invalidchecksum 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 ipv6 at ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------