Subject: Re: [MOBILE-IP] MIPv6 node location detection

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Mon, 16 Oct 2000 15:00:48 +1100

> > > Another way of looking at it is that the "new"
> > > Ruter advertisement should inform hosts that
> > > this subnet is "being renumbered".  I think
> > > this is a clean option. I don't think this
> > > should be a MIP issue. MIPv6 solves the problem
> > > when the MN is away from home, which is when
> > > MIPv6 is espected to solve it. I would suggest
> > > that this is a ND-MIP interaction issue.
>
> I don't think this is a general enough solution.  In the common case, an
> administrator would renumber by adding the new prefix and marking the old
> prefix to time-out.  A mobile node that returns home during the time-out
> delta could probably surmise that a renumbering was going on without
> needing
> an extra bit in the router advertisement.  Yes, the extra bit could serve
> to
> aid those mobile nodes that don't come home until after the old prefix has
> expired, but how long does the router continue to advertise the "being
> renumbered" bit?
>
        => You can do it for the same duration that you advertise dual
        prefixes for or more. There are no hard rules for how long that
should be
        and I think that's a good thing.
        I would argue that having a flag is better than simply just
advertising two
        prefixes at the same time. If you have a flag then at least you're
        encouraging the MN's (or just any IPv6 node) to use the new
        prefix in establishing its new connection. On the other hand,
        advertising two prefixes may not necessarily mean that you
        are renumbering. Even if one of them has a shorter lifetime.

> At some point the administrator has to claim that the
> "being renumbered" state has finished, confusing any mobile nodes that
> don't
> return home until after that.  And if some administrators never get around
> to turning the bit off, you'll have some networks in a state of perpetual
> renumberment.
>
        => Well, the way of turning the flag off can be automated and
        set when you  turn it on. I think that would depend on the
implementation.
        As to the confusion if the MN returns after the flag is turned off,
I think
        the confusion already exists, that's why we're having this
discussion.
        Adding the flag will make it possible to reduce the confusion by
        keeping it on for a bit longer. When I mentioned a "being
renumbered"
        flag I didn't mean that it MUST mean that. You could think of
        a flag that says "new prefix" and be included in the new prefix
option.
        It certainly should be interpreted in a way that doesn't confuse
hosts
        and make them think they're in a transient state.
        I'm not saying this is the best way, but it is certainly a stright
forward
        solution that seems quite simple.

> I think there's a better solution.  Have mobile nodes attempt to treat
> every
> home agent they encounter as their home agent.  A mobile node should only
> be
> able to successfully do so if the home agent actually is its home agent.
>
        => I'm not quite sure if I understand this correctly. The MN will
        have a fixed home address with a certain prefix. If it asumes
        that it has a new Home address every time it hears an RA with
        the H flag set (for HA), that's ok but that doesn't solve the
mobility
        problem for other Home addresses. It still needs to update
        the original "home" HA. The HA is only updated when the MN
        is in foreign subnet. What you're saing (if I understood it
correctly)
        means the MN will have a new Home Address every time
        it moves to a new subnet. Again that's fine but it doesn't help
        the fixed home address and all the connections using it.

> Note that there has to be some sort of security authorization between the
> mobile node and the home agent or bad people visiting your link could
> steal
> one of your addresses (such authorization is required for the mobile node
> to
> securely update the home agent as to what its care-of-address is, so the
> authorization capability must exist).  In other words, if you pass
> security,
> you're at home (or one of your homes, at any rate).
>
        => That authorisation only happens when you're in a foreign subnet.

> Now the MIPv6 draft is
> a little weak regarding how this authorization should be done, but I think
> that's a problem for the mobile ip working group.
>
        => I disagree here. MIPv6 BUs are secured using AH and that's
mandatory.
         How a security asociation is established is not a MIP problem. It
        can be manually configured or dynamically using IKE.

        Hesham

---

From: Linfeng Yang <[email-masked]>
Date: Mon, 16 Oct 2000 18:01:03 +0300

When I read Section 12 RENUMBERING CONSIDERATION of RFC 2461 "Neighbor
Discovery for IPv6", I got a feeling, renumbering should not happen in a
sudden. A best practice would be: before new prefix being advertised, the
old one will be advertised with progress shorter Lifetime time and with
progress shorter interval. At the point old prefix being advertised with 0
Lifetime, new prefix will be advertised, after that point, old prefix will
continue be advertised with a Lifetime of 0 for some period of time.

So the MN should be well prepared for renumbering, and thus distinguish
renumbering with movement detection.

In any case MN should avoid unplugged for a period of time longer than its
HA expiration time as the same section of RFC suggested.

Linfeng

---

From: Fred Baker <[email-masked]>
Date: Tue, 17 Oct 2000 05:26:57 -0700

The issues are a lot greater than that. If you want to read my initial
thoughts on a procedure (which are by no means done; this was put up for
review by the IPv6 Directorate ad will eventually be published as an ID)
you can glance at
ftp://ftpeng.cisco.com/fred/iesg/draft-baker-ipng-renumbering-00.html