[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (IPng 5744) Re: [Karen Seo: Thomas Narten -- clarification, etc.]
Ted,
>
> If this is the case, this simplifies things significantly. This way, if
> there is an unknown extension header before the AH header, the IPSEC
> host (or security gateway) will have already rejected the packet and
> have sent an ICMP packet back at the sender. So we don't need to have
> any words about handling unknown extension headers; they will just be
> rejected. Can someone in the IPNG working group confirm my reading of
> IPV6 spec?
>
Your reading is correct. The UNH Interoperability Lab folks have had tests
for this case for quite some time.
> I'm curious --- was it ever the case that the extension header
> processing worked the way I described them in the first paragraph? The
> IPV6 expert whom I talked to was pretty definitive that this was the way
> things worked; I was pretty surprised, since I thought it was incredibly
> ugly and unclean, but I wasn't the IPv6 expert.
>
Given that the ESP header itself does not conform to this rule regarding
extension header structure I don't see how one could require that every
other extension header obey this rule.
I don't recall it ever being stated or implied that there was a required
structure that extension headers had to follow other than they had to have
a next header field somewhere and they needed to be a multiple of eight bytes
in length to preserve alignment.
tim