Subject: Re: [MOBILE-IP] Placement for Binding Update and Home Address opt ions

From: "Powell, Ken" <[email-masked]>
Date: Thu, 9 Nov 2000 17:01:55 -0500

> Bottom line _proposal_:
>
> Mandatory placements:
>         - Home Address option between Routing and Fragment Headers
>         - Binding Update after ESP.
>
> Comments?

I did a quick comparison to RFC 2460 and the latest Advanced
IPv6 API spec. RFC 2460 recommends the header order listed
below:

   IPv6 header

   Hop-by-Hop Options

   Destination Options (AdvAPI: only if routing header exists)

   Routing
        <--- Charlie: destination option w/ home address here
   Fragment

   Authentication

   Encapsulating Security Payload

   Destination Options <--- Charlie: binding update here

   upper-layer

The advanced API spec currently only allows for 2 destination
option headers.

I was wondering why create another destination option header
for the home address option after the routing header instead
using the existing one before? On the other hand, I
don't know why RFC 2460 put the destination option header
before the routing header.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 9 Nov 2000 14:09:14 -0800

Hello Ken,

The reason why to have the Home Address destination
option after the Routing Header is because routers
are not supposed to look at the Home Address option.

The reason that some destination options should be
put before the Routing Header is because some routing
agents might need to look at an "Intermediate
Destination Option", and the routing header addresses
do end up being in the Destination Address field of
the IPv6 header.

I don't know how important it is for the destination
option to be tangible by way of the API, but there
certainly is an easy fix for that problem.  Most of
the direct processing of the Home Address option
requires kernel coding anyway, at least from my vantage
point.  Of course, everyone's kernel could be different,
and they usually are.

Regards,
Charlie P.

---

From: Francis Dupont <[email-masked]>
Date: Tue, 14 Nov 2000 14:44:33 +0100

In your previous mail you wrote:

=> the RFC 2460 has a clear problem with destination option headers.

      IPv6 header

      Hop-by-Hop Options

=> these destination options are for intermediate hops listed in
the routing header. No such destination option is defined today.

      Routing

      Authentication

=> insert possible IP compression header here.

=> this is the standard destination option placement but it doesn't
work for home address or tunnel encapsulation limit, only for others
which are binding update, acknowledgement and request.

      upper-layer

=> the advanded API is RFC 2460 compliant (:-).

   I was wondering why create another destination option header
   for the home address option after the routing header instead
   using the existing one before?

=> because the purpose is not the same.

   On the other hand, I

=> by mistake? Seriously the destination option stuff must be revisited
because it is too hairy (even two different kinds of options are too many).

Regards

[email-masked]