[mobile-ip] Re: New idea for Router Sol/Adv and Mobility - NO new types

[root <tj@Kniveton.com>]

Francis Dupont wrote:

>  In your previous mail you wrote:
>
> => this thread was completely messed by the mobile-ip mailing list bug:
> I believe a summary is needed in order to understand ideas and
> their chain.

You might be able to find the thread on the IPng group since I crossposted 
there.
My message which describes the problem is "New idea for Router Sol/Adv and
Mobility," which should fill you in.

If you can't find that, let me know and I will forward some of the messages to
you.

>    On one hand I agree with Erik that new types are better than overloading 
>the
>    semantics unnecessarily. The basic problem I am having with this thread 
>is
>    understanding the problem it is trying to solve.
>
> => look at my intro (:-).
>
>    Since the HA is required to be in all possible routing paths to my
>    home subnet (else some parts of the world will never contact the node
>    when it is mobile), it has to be a function of the last hop router.
>
> => not exactly. The Home Agent (HA) must be attached to the home link.
> If the home link doesn't physically exist then (and only then) your
> statement applies.
>
>    The premise of this proposal was that the MN would need to ask the
>    HA for a prefix so it could configure its home address.

Although you might be able to configure *an* home address using the router's
prefix, you are supposed to be able to configure *all* home addresses while 
away
from home. The value of this flexibility is debatable, but it certainly seems 
like
a good thing to be able to configure at least more than one address.

>
>
> => the issue is home link renumbering, in particular when the Mobile
> Node (MN) is down for a very long period. This is a real problem
> but there are far more important problems, for instance the abyssal
> performance of secure mobile IPv6 when a MN is booted in visit
> (of course having to learn the HA address and the home address will
> not improve this).

There is a couple of issues. The home link being renumbered while the MN is 
off,
is a subject that I have filed into "for future study" under the rubrick 
"Mobile
Node Bootstrap Problem." However, this thread addresses a more specific 
problem,
which is that Tunneled Router Advertisements, as currently defined in the 
draft,
a. Will *not *work when a MN does not yet have its Home Address
b. Add an IPv6-in-IPv6 encapsulation header which is unnecessary

There may be more reasons, but these two, especially (a), are probably 
sufficient
to merit solving this problem now (IMHO).

>
>  This thread assumes that:
>   - the home link is often renumbered
>   - DNS is not available in the visit network (if it is available
>     then you need only to configure a name as proposed by Compaq folks)
>   - home AAA is not available (if it is available then HA and home address
>     allocation may/should be done by AAA)
>   - statefull autoconfig will never be available!

Sorry, I may have mixed the discussion of these two issues -- mobile bootstrap
(for which you did a good job of describing the assumptions), and fleshing 
out the
Tunneled Router Adv/Sol as my original message in this thread describes. It is
also noteworthy that the latter does not solve the former, though they are
connected; future work is necessary to come up with a general, palatable 
solution
to bootstrapping.

>
>    Since it knows (presumably via configuration) the address of the
>    HA, (and given the HA has to be in the routing path) it already has a
>    useable prefix. I have always assumed that the MN is configured with its
>    home prefix, then it would use the all-routers anycast address to find 
>the
>    HA. In this case the proposed messages are unnecessary. Clearly I need a
>    picture to understand why the MN would know its HA, but not its home 
>prefix.
>
> => there is a dedicated anycast address for HAs (because if HAs are routers,
> not all routers are HAs).
>  I agree this topic is a secondary one and we should throw it into the
> for further studies stuff. Of course, I'll strongly object if this is
> slowing down the mobile IPv6 draft (BTW, is there an I-D 14?).

>
> Thanks
>
> Francis.Dupont@enst-bretagne.fr