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]
--------------------------------------------------------------------

--------------------------------------------------------------------
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: Tim Hartrick <[email-masked]>
Date: Thu, 6 Jan 2000 09:38:09 -0800 (PST)

Erik,

> 
> > So I'll add ND_OPT_PI_FLAG_ROUTER.
> > Is there something else missing from the mobile IPv6 specification?
> 
> Sorry, I'm not an expert in mobile ip6...maybe some other people can
> answer this.
>

I don't have the spec in front of me but I believe that mobile IPv6 has
added some options, some of which MUST be supported by implementations.  I
think it would be a good idea to add those option code points to the
list of well known option code points.

tim