Subject: Re: [MOBILE-IP] How Mobile IPv6 should handle home ne tworkrenumbering

From: Roberts Philip-qa3445 <[email-masked]>
Date: Wed, 8 Nov 2000 11:26:07 -0600

I just want to emphasize one point in agreement with Charlie.  We need to
get this draft done.  It seems we're getting close.  Let's wrap it up.

Phil

> ----------
> From:         Charles E. Perkins
> Reply To:     Charles E. Perkins
> Sent:         Tuesday, November 7, 2000 1:33 AM
> To:   [email-masked]
> Subject:      Re: [MOBILE-IP] How Mobile IPv6 should handle home
> networkrenumbering
>
> Hello Mattias and Francis,
>
>
> Francis wrote in another thread:
>
> > The issue is what happens if the home link is renumbered when the MN is
> > stopped. In fact this depends on how the MN knows its home prefix(es):
> >  - very stupid implementations believe the MN is started at home then
> >    the home prefixes will be prefixes of the first attached link: no
> >    problem with renumbering.
> >  - stupid implementations use a static config in order to know home
> >    prefixes then if the config is too old the MN will not be able to
> >    find its home link (and a home agent).
> >  - someone suggested in the list to use a name which can be updated
> >    when the home prefix is renumbered (but not renamed :-). It is a
> >    fine idea out of the scope of the mobile IPv6 draft.
> > I think most implementations use the second way (static config)...
>
> One is left to wonder if there are any intelligent alternatives!
>
> I propose that the protocols and algorithms and procedures for getting
> an initial IPv6 home address allocated to a mobile node should all
> be declared out of scope, or otherwise we'll never get finished with
> the spec.
>
>
> >Mattias Pettersson wrote:
>
> > I've studied the thread above slightly and am a bit curious on
> > the effects of the new additions to the I-D below. It's still
> > the bootstrapping procedure which is of most interest; the
> > renumbering phase is a special case of the former. So: how does
> > the MN find it's home addresses and it's home agents?
>
> Likewise, I sincerely hope that these questions can be declared
> out of scope for the current draft.  On the other hand, I think it's
> a great discussion.
>
> > 1. The MN finds out its home prefix.
> > 2. MN performs DHAAD to find unicast address of an HA.
>
> That's a mighty big rabbit you just pulled out of that there hat ...
>
> > 3. MN sends RS to HA.
> > 4. HA sends RA with prefix list to MN.
> > 5. MN builds Home Addresses for all prefixes, by using address method
> > stated in prefix info.
> > 6. MN registers each Home Address.
> > 7. HA might help in address configuration (e.g. DAD)
> > 8. DNS should be updated, depending on address configuration method (it
> > should be done by the MN at this point, not earlier, IMO).
>
> What is the mobile node uses DHCP to update DNS?
>
> > Note that MN doesn't have a Home Address before step 5.
>
> Presumably, that would mean that the protocol you design would
> use a link-local address up until that point.
>
> > If home network renumbering occurs, while the MN is away from home, HA
> > normally takes care of informing the MN about new home prefixes. The MN
> > would run step 4-8 to synchronize with the renumbering.
>
> I'm not disagreeing with you, but my objective is to get the draft
> done, and making such dependencies for resynchronization purposes
> would be detrimental to that objective.
>
> > However, in the case when the MN is turned off for an extended period,
> > the MN won't be able to find it's HA again, and not even it's home
> prefix
> > to be able to run DHAAD. This is the same case as initial bootstrapping.
> > Step 1 has to be performed.
> >
> > As Francis said above, most implementations assume a manual
> > configuration of 1, i.e. the home prefix.  From there on you
> > can find out the home agents' anycast address and find a HA
> > to register with.  With Ken's contribution we now have a way
> > to find out all home addresses (BTW, what's been done in the
> > field of stateful autoconf of Home address and MIPv6?).
>
> I don't think a mobile node which is currently off-link can bootstrap
> from zero.  It has to at least have a security association with the
> home agent, and that has to depend on an IPv6 address, so you need to
> have an IPv6 address.  We can all try to design a better bootstrapping
> mechanism, which would clearly depend on finding new ways to identify
> a mobile node (other than using its home address).
>
> It took a year to standardize the Mobile IPv4 NAI extension, and there
> are still questions coming up on it.  My goal is to get a new Mobile IPv6
> Internet Draft done this week.  I hope we don't have to go down the
> path of specifying off-link bootstrapping from zero.
>
>
> > What we need at this stage is a new fall-back level, where the MN can
> > find it's home prefix independently of IP. So this is where AAA comes
> > in? MN would only need to know it's name (NAI?). Everything else can be
> > resolved from this.
>
> Agreed -- but next year, not this one.
>
>
> Regards,
> Charlie P.
>
>