Subject: Re: comments on ipngwg-rfc2292bis-01

From: Tim Hartrick <[email-masked]>
Date: Wed, 5 Jan 2000 12:45:12 -0800 (PST)

Jinmei,

> 
> 2.1.2.  IPv6 Extension Headers
> 
> I think it would be useful to define a generic structure to specify
> IPv6 extension headers, since we sometimes encounter a situation where
> we can't detect the type of an extension header but should deal with
> the header. As an example, here is the KAME's structure for this
> purpose:
> 
> struct	ip6_ext {
> 	u_char	ip6e_nxt;
> 	u_char	ip6e_len;
> };
> 
>

I am not sure how useful this really is given the fact that there is no
requirement that all extension headers be structured in this way.  It is
fine for hop-by-hop options, destination options and routing headers but
it is not generally useful.
 
> 
> 6.  Packet Information
> 
>    An
>    application can clear any sticky IPV6_PKTINFO option by either doing
>    a setsockopt for option with optlen being zero, or by doing a
>    "regular" setsockopt with ipi6_addr being in6addr_any and
>    ipi6_ifindex being zero.
> 
> Is the latter way necessary? This prohibits implementation from
> specifing the unspecified address as source address. (I'm not sure if
> it should be allowed, but it might be useful for some purposes.)
>

Indeed.  If someone wants to implement DAD in user space then they need
to be able to specify IN6ADDR_ANY as the source.  One could always use
ancillary data for that purpose and avoid sticky options I suppose, but it
would be best I think, if we didn't have corner cases that behaved differently
between ancillary data and sticky options.

tim
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 07 Jan 2000 00:50:50 +0900

>>>>> On Wed, 5 Jan 2000 12:45:12 -0800 (PST), 
>>>>> Tim Hartrick <[email-masked]> said:

> it is not generally useful.

That's right, but (currently) the only exception is the fragment
header and I think if we defined a new (variable length) extension
header it would probably be formatted as above.

Anyway, we are using the structure in chasing a header chain like
this:

		while (len < off) {
			ip6e = (struct ip6_ext *)(packetbuf + len);

			switch(nxt) {
			case IPPROTO_FRAGMENT:
				len += sizeof(struct ip6_frag);
				break;
			case IPPROTO_AH:
				len += (ip6e->ip6e_len + 2) << 2;
				break;
			default:
				len += (ip6e->ip6e_len + 1) << 3;
				break;
			}
			nxt = ip6e->ip6e_nxt;
		}

Despite the exception, I still believe the generic structure is useful
in such a situation. But I don't strongly argue that it should be
incorporated to the draft. I'd like to follow the authors' decision.

> between ancillary data and sticky options.

As I said in the previous mail, I'm now about to change my mind on
this point. In6addr_any in the ipi6_addr field has already another
semantics, i.e. the user doesn't want to specify the address. So we
may not be able to specify the unspecified address as source using
IN6_PKTINFO option/ancillary data...

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 07 Jan 2000 00:50:50 +0900

while (len < off) {

			switch(nxt) {
			case IPPROTO_FRAGMENT:

					JINMEI, Tatuya

---

From: Robert Elz <[email-masked]>
Date: Sat, 08 Jan 2000 20:23:03 +1100

Date:        Fri, 07 Jan 2000 00:50:50 +0900
    From:        JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
		 <[email-masked]>
    Message-ID:  <[email-masked]>

  | > I am not sure how useful this really is given the fact that there is no
  | > requirement that all extension headers be structured in this way.  It is
  | > fine for hop-by-hop options, destination options and routing headers but
  | > it is not generally useful.
  | 
  | That's right, but (currently) the only exception is the fragment
  | header and I think if we defined a new (variable length) extension
  | header it would probably be formatted as above.

Only if the length fits in a byte, which is by no means certain.

  | Anyway, we are using the structure in chasing a header chain like
  | this:

As I recall, the intent was always very explicitly, that as soon as an
unknown header is detected, packet parsing must cease.   You are explicitly
not supposed to be able to step over an unknown header.

kre

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 27 Jan 2000 11:38:51 +0900

Sorry, I missed your reply.

>>>>> On Sat, 08 Jan 2000 20:23:03 +1100, 
>>>>> Robert Elz <[email-masked]> said:

> Only if the length fits in a byte, which is by no means certain.

Of course yes in theory, but I'd think that an IPv6 extension header
rarely needs a length field in more than one byte.

> not supposed to be able to step over an unknown header.

Sorry, the sample code was too simple. In our actual code we of course
reject an unknown header.

					JINMEI, Tatuya

---

From: Robert Elz <[email-masked]>
Date: Thu, 27 Jan 2000 20:31:37 +1100

Date:        Thu, 27 Jan 2000 11:38:51 +0900
    From:        JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
		 <[email-masked]>
    Message-ID:  <[email-masked]>

  | Of course yes in theory, but I'd think that an IPv6 extension header
  | rarely needs a length field in more than one byte.

That depends what they end up being used for - I wouldn't like to define
something now which would constrain choices in the future.   The (not
accepted but for this purpose that doesn't matter) payload header intended
to allow a UCP or TCP (or anything else) packet to appear in its data
field - clearly a one byte length would never have worked.

  | Sorry, the sample code was too simple. In our actual code we of course
  | reject an unknown header.

That's good.   Then, when you stop parsing the packet when you reach the
unknown header, there's no need to know its length - because there's no
need to skip over it (or do anthing else at all to it).  Packet processing
simply stops (and an ICMPv6 can be returned - that also doesn't need to be
able to parse the insides of the unknown header, or anything beyond it).

kre