[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: (IPng 5744) Re: [Karen Seo: Thomas Narten -- clarification, etc.]

   Date: Fri, 01 May 1998 07:46:34 +1000
   From: Robert Elz <kre@munnari.OZ.AU>

     | Let me back up a little and clarify the point that caught my
     | attention. draft-ietf-ipsec-auth-header-05.txt says:
     | 
     | >>>    If the IPsec implementation encounters an
     | >>>    extension header that it does not recognize, it MUST zero the whole
     | >>>    header except for the Next Header and Hdr Ext Len fields.

   To me, that reads like nonsense.  If the implementation doesn't
   recognise the header, what would be the basis upon which it would
   locate the Next Header or Hdr Ext len fields?  Is there some
   (incorrect) implicit assumption here that all headers for all time
   will have such fields, and that they'll always be in the same place?

I had the exact same reaction, and when I rasied the question, someone
who is much more versed in the ways IPv6 told me this was really how
extension headers were supposed to work --- and in fact that IPv6
implementations were supposed to ("SHOULD") assume that the Next Header
field was in a fixed location, and skip the unknown extension header.
Given that extension headers are defined by new IP protocol numbers,
this seemed rather (OK, *very*) unclean to me.  (Presumably if we were
to define a new IP protocol number that wasn't an extension header, the
IPV6 protocol would try to process it as an extension header and get a
parse error... eventually.)

Fortunately, I hadn't eaten recently when this was explained to me, or I
probably would have lost my lunch.  However, I just checked
draft-ietf-ipngwg-ipv6-spec-v2-01.txt, and this doesn't appear to be the
case.  The IPV6 specification now appears to say that if there is an
unknown next-header field, an ICMP code 1 is supposed to be returned.
(See the second full paragraph on page 6 of ipv6-spec-v2-01.)

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?

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.

							- Ted