Subject: Re: [mobile-ip] IPv6 advanced socket API extension for MIPv6

From: Erik Nordmark <[email-masked]>
Date: Mon, 10 Mar 2003 15:30:24 +0100 (CET)

If there already exists a common set of naming for the structures/fields/flags
that is used by multiple implementations it sure would make sense to
take that into account.
Do you know if multiple implementations have already chosen common names?

The proposed naming scheme in the draft is based on rfc2292bis as
I try to clarify below.

> I don't think you're following the precedence set in RFC 2292 for
> IPv6 extension headers, in that doc all structure names and elements
> start with "ip6".  I would change this to:

In rfc2292bis only the "IPv6 base" uses the "ip6_" prefix.
Other prefixes are "icmp6_" and "nd_".
Thus I think it makes sense to have a separate prefix for
the mobility header since it is as much (or little) separate from IPv6 as is
Neighbor Discovery.

> Embedding the common elements of the Mobility Header structure
> is also something that isn't done in 2292 either, I'd rather
> see this separated (this will also bring it inline with all the
> other implementations I've seen).  Flags should be broken out
> as well.

In rfc2292bis we have things like:
       struct nd_router_advert {      /* router advertisement */
         struct icmp6_hdr  nd_ra_hdr;
         uint32_t   nd_ra_reachable;   /* reachable time */
         uint32_t   nd_ra_retransmit;  /* retransmit timer */
           /* could be followed by options */
       };

> > 2.4  Routing Header Type 2
> [...]
> I don't think the address should be included in the struct,
> just a comment:
> 
> 	/* followed by one struct in6_addr */
> 
> This makes it extensible in the future to hold more addresses.

I think the mipv6 spec says that it MUST only contain one address.
Thus if there is something else defined in the future I think it would
need to be a different routing header type.

  Erik

---

From: Brian Haley <[email-masked]>
Date: Tue, 11 Mar 2003 11:49:32 -0500

> Do you know if multiple implementations have already chosen common names?

There are at least three implementations I know of that use similar
names, but none have used "mh_", they use "ip6m_".  I'm the only one
that's spoken up of course...

> the mobility header since it is as much (or little) separate from IPv6 as is

When Mobile IPv6 started it was a destination option, which is
probably why most have defined the structs in ip6.h and used a
"typical" IPv6 naming style.

>            /* could be followed by options */

I must have missed this, but I'm basing my opinion on the mobility
code I've seen.  I would be open to this embedded definition.

> need to be a different routing header type.

So the draft I cited:

http://www.nal.motlabs.com/nemo/drafts/draft-ng-nemo-access-router-option.txt

needs to be fixed?  I figured to conform to the base Mobile IPv6 draft
you MUST only have one address, but future drafts could revise that.
If that's not the case then we have to start policing other WGs that
might do such things.  Is there stronger verbage we can put in Mipv6
to prohibit such extensions?

-Brian

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 12 Mar 2003 21:13:36 +0100 (CET)

> "typical" IPv6 naming style.

Ah - makes me understand why.

> to prohibit such extensions?

It already says "MUST" doesn't it? and we don't have bold-face 40pt fonts 
we can use.

So defining a new type if somebody wants something which has different
semantics than type 0 (I haven't read the meat of the above draft to see
whether type 0 would work).

  Erik