Hi Erik, "Erik Kline" <[EMAIL PROTECTED]> writes:
> [snip] > >> 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? > > One of the issues is the "cross-pollution" of IPv6 header number space > 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+ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
