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
>
> [EMAIL PROTECTED]
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
