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 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------