Hi Suresh, > Your understanding above is correct, but your conclusion does not > follow. The problem is that a new extension header may decide to have > the Header length at another location than the second byte or > not have > one at all. The goal of the GIEH is to force all new > extension headers > to have the Header length at a KNOWN location in order to > skip over them
I had posted a draft yesterday and is temporarily available here (should get announced in a day or two): http://www.ietf.org/staging/draft-bhatia-6man-update-ipv6-ext-hdr-00.txt This proposes a standard format for all IPv6 extension headers so that there is no such ambiguity. Also, I don't think it's a good idea to let new extensions define the Header length in some arbitrary location as it would become really messy for the HW to parse such packets. > > > > > 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. > > Yes. This (discard+ICMP) would be the expected behavior. I do > not think > that extension headers should require any other behavior (please see > below). I see incremental deployment as requiring two consenting > end-points talking over an unaware network. Not all the time. You can look http://tools.ietf.org/id/draft-bhatia-karp-non-ipsec-ospfv3-auth-00.txt for an example of why this may not necessarily be true. Also, I think we should have a generalized solution that works for all the cases. Cheers, Manav > > 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. > > As specified in RFC2460, if this kind of behavior is > required, I think > it is better to use Destination Options rather than an > extension header. > Quoting straight from there. > > " o If the desired action is for the destination node to discard > the packet and, only if the packet's Destination > Address is not > a multicast address, send an ICMP Unrecognized Type > message to > the packet's Source Address, then the information may be > encoded either as a separate header or as an option in the > Destination Options header whose Option Type has > the value 11 > in its highest-order two bits. The choice may > depend on such > factors as which takes fewer octets, or which yields better > alignment or more efficient parsing. > > o If any other action is desired, the information > must be encoded > as an option in the Destination Options header whose ..." > > Thanks > Suresh > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
