Subject: Re: [mobile-ip] Mobile Prefix Advertisements (more comments)

From: Charlie Perkins <[email-masked]>
Date: Mon, 25 Jun 2001 20:08:13 -0700

"Powell, Ken" wrote:

> Hi T.J.,
>
> Vlad Yasevich, Brian Haley, Greg Colburn and I
> finished our discussion of your proposal. This is the
> remainder of our comments. Many comments also apply
> to draft-ietf-mobileip-ipv6-13 without your changes
> as well.
>
> Ken Powell
> Compaq Computer Corporation
>
> 5.8 Mobile Prefix Solicitation Message Format
>
>    My comments to section 9.8.2 below request that only the prefixes
>    that match a particular home registration be sent to the mobile
>    node in Mobile Prefix Advertisements. If the binding has a zero
>    prefix length, only the specific prefix for the mobile node's
>    home address would be sent. For a bindings with a non-zero prefix
>    length, all prefixes in the aggregate list would be sent.

I'm going to go out on a limb here, and suggest that the existing semantics
for the Prefix Length option need substantial change.  I might be missing
something, but having a nonzero prefix length seems to only have the effect
of requesting that the home agent should provide service for more home
addresses.  The addresses served by the home are determined by the
collection of on-link prefixes, not the actual value of the Prefix Length
field.  Thus, this purpose could be managed by a single bit.

That would allow us to use the Prefix Length field for something more
important -- namely to serve the same function as the proposed
"Mobile Router Prefix Length Sub-Option", which I wrote about
earlier and put into the existing intermediate (unfinished) draft which
I am trying to finish now.  Then we could get rid of that Sub-Option
and have a more natural specification.

>    This left a problem, what prefixes do we send in response to a
>    Router Solicitation? I think the home agent should use the
>    same prefix selection logic, but the mobile node needs a way to
>    override this behavior to support initialization. One option is
>    to add a flag to the Mobile Prefix Solicitation Message:
>
>  + Send All Prefixes flag
>  +
>  +   If clear, the home agent replies by sending only the prefixes
>  +   that match the mobile nodes home registration as defined in
>  +   section 9.8.2. If set, the home agent will send all prefixes
>  +   for the home network as defined in section 9.8.1. No prefixes
>  +   will be sent if this flag is clear and the mobile node does
>  +   not yet have a home registration.

So, in a way, I am supporting this suggestion.

> 9.8.2 Sending Changed Prefix Information to the Mobile Node
>
>    Due to the number of comments on this section, I'm including
>    the entire text with ">" marks, and slicing in the comments
>    where they apply.
>
>  > A home agent serving a mobile node will schedule the delivery
>  > of new prefix information to that mobile node when any of the
>  > following conditions occur:
>
>    Can the following list of MUST and MAY requirements be merged
>    into the algorithm for sending prefix information below?

Maybe -- especially if you think it will be clearer.  Would you be willing
to suggest some reorganized text?  However, one list says how to figure
out that the list needs to be sent, and the other list says how to figure
out when to send it.

>
>
>  > MUST:
>  > - The valid or preferred lifetime or the state of the flags
>  >   changes for the prefix of the mobile node's registered home
>  >   address changes
>  > - The mobile node requests the information with a Router
>  >   Solicitation (see section 10.16).
>  >
>  > MAY:
>  > - A new prefix is added to the aggregate list
>
>    Why is this a MAY instead of MUST? Is it to cover the case
>    where a home registration has a zero prefix length?

It's a MAY because it won't hurt the mobile node not to find out
this information.

>  > - The valid or preferred lifetime or the state of the flags
>  >   changes for a prefix which is not used in any binding cache
>  >   entry for this mobile node
>
>    I don't understand what your trying to do with this
>    last MAY requirement.

Maybe the mobile node didn't like one of the prefixes because
the lifetime was too short, and it changed to be long enough.
Really, though, it's almost the same as the previous bullet, thus
also a MAY.

>   It looks like its addressing a problem I've been wondering about.
>   A mobile node with  multiple home addresses could either
>
>     o establish a single binding with a non-zero prefix
>       length to cover all its home addresses, or
>
>     o establish multiple bindings each with a zero prefix
>       length to cover a single home address.
>
>    In the latter case, how does the home agent recognize
>    that a single node has multiple bindings? I believe the
>    home agent should avoid sending duplicate home prefix
>    advertisements to the mobile node.

I'm not totally understanding this.  It seems like a home agent
is going to have one primary care-of address for a mobile
node, and that is what binding the mobile node will effect.
I agree that the home agent shouldn't send duplicate MPAs
to the mobile node, insofar as it's possible to do so, but I didn't
get the connection with the previous bullets, sorry.

>    One way to fix this is to have the home agent to only
>    send prefix information that is applicable to a specific
>    binding. Is that what your additional requirement was
>    after? If so, I agree with the intent, but believe more
>    detail is needed. Perhaps a statement like the following
>    would help at the start of this section:
>
>  + A home agent normally sends only the prefixes that match
>  + a mobile node's home registration to the mobile node. A
>  + match exists if the home registration's home address
>  + contains a prefix or if the home registration's prefix
>  + length field is non-zero. Each home registration entry
>  + in the binding cache MUST be treated as if it were
>  + created for a separate mobile node.

I like the last sentence, but it belongs in the section on
"Home Agent Operation..  The first sentences are are
already implicit in the previous parts of the description
of the Prefix Lengths field (as it is currently, that is).

>  > The home agent uses the following algorithm to determine when to
>  > send prefix information to the mobile node.
>
>    There is a requirement at the end of section 9.8.3 to send all
>    prefixes periodically. I think that requirement should be folded
>    into this section to avoid confusion between the two sections.
>
>  + - Send a Home Agent Prefix Advertisement periodically to prevent
>  +   non-decrementing prefixes from expiring on the mobile node.
>  +   Calculate the interval between each successive transmission
>  +   independently as rand()*HomeRtrAdvInterval seconds;

I did put in a new bullet according to your suggestion, but I was not
so clear about randomizing the interval.  I see that it would be a good
idea to avoid having a lot of advertisements happening all at once,
but the nature of the Binding Update process seems to imply that
the transmissions will effectively be randomized anyway, and with
a longer period between periodic transmissions.

>  > - If a mobile node sends a solicitation, answer right away.
>
>    If the proposal for the Send All Prefixes flag is accepted,
>    the following text should be added here:
>
>  +   If the Send All Prefixes flag in the solicitation was set,
>  +   include all prefixes from the aggregate list in the advertisement.

But that would amount to saying the same thing in two different
places, unnecessarily, wouldn't it?

>  > - If a prefix changes state in a way that causes a mobile node's
>  >   address to go deprecated, send an advertisement right away.
>
>    I believe the algorithm for RAND_ADV_DELAY covers this situation.
>    It will cause an advertisement to be sent right away if a change
>    causes an address to go deprecated. Can we remove this special
>    case from here simplify the text?

I have done so at your suggestion.

>  > - For any existing prefix, if the mobile node's binding expires
>  >   before the advertised Preferred Lifetime, do not schedule the
>  >   advertisement.  The mobile node will get the revised information
>  >   in its next Binding Acknowledgement.
>
>   This is covered in the RAND_ADV_DELAY scheduling algorithm below.
>   Can we remove it from here to simplify the text?

O.K.

>  > - If a prefix is added, or if it changes in any way that does not
>  >                                                     =============
>  >   cause the mobile node's address to go deprecated, ensure that a
>  >   ================================================
>  >   transmission is scheduled at time RAND_ADV_DELAY in the future.
>
>    Same comment as before, do we need the special case text that is
>    underlined? Also, this probably should be qualified to be more
>    precise.

O.K.  I removed the text.

>  + - If a prefix in the aggregate list that matches the mobile node's
>  +   home registration is added or its information changes, ensure that
>  +   a transmission is scheduled at time RAND_ADV_DELAY in the future.

I basically merged this with the previous text.

>  > - If a prefix advertisement is scheduled, and a Binding Update
>  >   arrives, perform that advertisement and include the information
>  >   in a Router Advertisement that has the Binding Acknowledgement as
>  >        ====================
>  >   a Destination Option.  Remove the future scheduled advertisement.
>
>    Did you mean Mobile Prefix Advertisement here?
>
>    Is it really necessary to send the Binding Acknowledgement in the
>    same message as the Mobile Prefix Advertisement? I suspect this
>    will be awkward to implement given that Binding Acknowledgements are
>    probably handled in the kernel and Mobile Prefix Advertisements
>    in a daemon.

I made it a SHOULD.

>    The 3rd rule in this list says "do not schedule the advertisement"
>    if a binding update is expected before the prefix becomes
>    deprecated. The 5th rule says to send an advertisement if "a
>    prefix advertisement is scheduled". Any change that satisfies
>    3rd rule will never be sent. Perhaps this last rule should say:
>
>  + - If there are any unacknowledged changes to prefix information
>  +   when a Binding Update arrives for the home registration, send
>  +   a Mobile Prefix Advertisement to the mobile node
> immediately.                                          +   If an
> advertisement was previously scheduled for the changes,

Done.

>    Should the following be added here for completeness?
>
>  + - If a home registration expires, cancel any scheduled
>  +   advertisements to the mobile node.

Done.

>  > The home agent uses the following algorithm to compute
>  > RAND_ADV_DELAY, the offset from the current time for the
>  > scheduled transmission.
>  >
>  > If there is a transmission already scheduled, then
>  >
>  >    if the current RAND_ADV_DELAY would cause another
>  >    transmission BEFORE the Preferred Lifetime of the
>  >    mobile node's home address derived from the prefix whose
>  >    advertisement information has changed, then
>  >
>  >       add the new information to be transmitted to the
>  >       existing scheduled transmission -- return.
>  >
>  >    otherwise,
>  >
>  >       continue with the following computation, and add the
>  >       data from the existing scheduled transmission to the
>  >       newly scheduled transmission, deleting the previously
>  >       scheduled transmission event.
>
>    I understood that the reason for sending only the changed prefix
>    information instead of all prefix information is to reduce the
>    connection costs for the mobile nodes on expensive wireless
>    networks. We don't believe the cost savings for this extra
>    complexity will be significant. We would prefer this to be an
>    optional feature.

You suggest that the home agent should be allowed to send more
than the minimum amount of information.  This is O.K., except that
I didn't find a good place to insert the necessary text.  If you can
suggest some text, I'll put it in.  However, the important thing is that
the Mobile Node _MUST_ be able to correctly interpret a partial
list to contain only _changed_ information.  A mobile node should
not assume that missing advertisements mean that the prefix has
been deleted.  The latter operation has to be done by other means.

>
>  > If the mobile node's binding expires after the Preferred Lifetime,
>  > then compute
>
>    The indentation following this text could be interpreted to mean
>    we still need to compute RAND_ADV_DELAY even when the IF condition
>    here is false. As an alternative, perhaps a rewording of this IF
>    clause combined with text from above would be helpful.
>
>  + If the mobile node's binding expires before the Preferred Lifetime,
>  + then return. The mobile node will get the revised information
>  + with its next Binding Acknowledgement. Otherwise, continue with the
>  + following computation:
>
>  >    MAX_SCHEDULE_DELAY ==
>  >    min (MAX_PFX_ADV_DELAY, Preferred Lifetime)
>  >
>  > for the newly advertised Preferred Lifetime.
>  > Then compute RAND_ADV_DELAY =
>  > MinRtrAdvInt + rand()*(MAX_SCHEDULE_DELAY - MinRtrAdvInt)
>
>    There may be a problem overwhelming system or network resources
>    if the scheduling algorithm causes the home agent to transmit a
>    home prefix advertisement to all mobile nodes at the same time.
>    The spec should allow a mechanism to avoid this.

This was supposed to be part of the point of the RAND_ADV_ DELAY.

>  + A home agent SHOULD perform scheduling of advertisements
>  + described in this section independently for each home
>  + registration in the binding cache to avoid a burst of
>  + advertisements being sent to all mobile nodes at the same time.
>  + In addition, a home agent MAY throttle transmission of
>  + advertisements to prevent overwhelming local resources when
>  + the rules above require immediate transmission of advertisements
>  + to large numbers of mobile nodes.

I used most of your words here.

> Section 9.8.3 Sending Mobile Prefix Advertisements to the Mobile Node
>
> > - When the advertisement was triggered by network renumbering, the
> >   advertisement MUST include a Binding Request destination option.
>
>    I agree with your intent of not requesting ACKs for
>    every advertisement, but I don't think the term "triggered
>    by network renumbering" catches all the important situations.
>    How does the following sound?
>
>  + The advertisement MUST include a Binding Request destination
>  + option if this is the first advertisement sent for a home
>  + registration or if there was a change in prefix information
>  + since the last acknowledged advertisement was sent to the
>  + mobile node for the home registration.

Done!

>
>
>  > The home agent SHOULD periodically continue to retransmit this
>  > tunneled packet to the mobile node, until it is acknowledged by
>    ========
>
>    The term "tunneled" was removed elsewhere in section 9.8.
>    Should it be removed here too?

Done.

>  > [Delete this paragraph? This is also too much.]
>  > Whenever a mobile node has a valid binding on a network other
>  > than its home network, the home agent MUST send a Mobile Prefix
>  > Advertisement with all prefixes in the aggregate list to the
>  > mobile node at least once per HomeRtrAdvInterval seconds, and
>  > upon receipt of a valid Router Solicitation from the mobile
>  > node.

O.K.  I reckon it's already been covered earlier.

>    I have no idea what "a network other than its home network"
>    means, but I think a requirement to periodically transmit
>    all prefixes is needed because home addresses on mobile nodes
>    still have a finite lifetime that will expire unless
>    periodically updated. As I stated above, I think this requirement
>   fits better in section 9.8.2.

It's there now.

> Section 10.16 Sending Mobile Prefix Solicitations
>
>  > The mobile node SHOULD send a Solicitation to the home agent
>  > when its home address will become invalid within MaxRtrAdvInterval
>  > seconds, where this value is acquired in a previous Router
>  > Advertisement from the home agent. ...              ======
>    =============
>
>    Should this be Mobile Prefix Advertisement?

Done.

>  > If the mobile node does not have a valid home address available for
>  > use as the IP source address, it MAY use its care-of address, [but
>  > there will not be a security association between the Home Agent and
>  > the care-of address for the corresponding Advertisement to be
>  > authenticated.]
>
>    We think some kind of security association will be needed here.

I don't know how to specify that, and the home agent can limit this.

> Section 10.17 Receiving Mobile Prefix Advertisements
>
>  > - The Source Address of the IP packet carrying the Router
>  >   Advertisement is .....                           ======
>      =============
>
>    Should this be Mobile Prefix Advertisement?

Fixed.

>  > Since the advertisement contains a Binding Request option, the mobile
>  > node SHOULD return a Binding Update, which will be viewed by the home
>  > agent as an acknowledgement of the corresponding Mobile Prefix
>  > Advertisement, which it can cease retransmitting.
>
>    Should this paragraph start with "If the advertisement contains..."?
>    The Binding Request option does not always need to be included with
>    a Mobile Prefix Advertisement.

Fixed.

> Appendix A:  Remote Home Address Configuration
>
>    I noticed you didn't attempt to fix this part. How about:
>
>    Delete:
>
>  > A mobile node MAY generate a temporary home address using the
>  > following information:
>  >
>  > - the subnet prefix from the home network's mobile agent anycast
>  >    address, and
>  >
>  > - the globally unique interface identifier that would have been
>  >   used to generate the link local address if the mobile node were
>  >   attached directly to the home network.
>  >
>  > Such a temporary address could be used to establish a binding with
>  > a home agent in the absence of any other known home addresses.  It
>  > could be created with short valid lifetime and a preferred lifetime
>  > of zero to ensure a quick transition to other addresses generated
>  > when stateless or stateful (DHCPv6) address autoconfiguration runs.
>
>    Your new Mobile Prefix Solicit/Advertisement exchange capability
>    between the mobile node's care-of address and home agent makes this
>    hack unnecessary.
>
>    Change steps 5 through 9 to:
>
>  + 5. Select the most preferred home agent and establish a security
>  +    association between the mobile node's current care-of address
>  +    and the home agent for temporary use during initialization only.
>  +
>  + 6. Send a Home Prefix Solicitation message with the Request All
>  +    Prefixes flag set to the home agent from the mobile node's
>  +    care-of address.
>  +
>  + 7. Receive a Home Prefix Advertisement message from the home agent,
>  +    follow stateless address autoconfiguration rules to configure
>  +    home addresses for prefixes received.
>  +
>  + 8. Create a security association between the mobile node's home
>  +    address and the home agent.
>  +
>  + 9. Send a binding update(s) to the home agent to register the
>  +    mobile node's home addresses.
>  +
>  + 10. Receive binding acknowledgement(s) then begin normal
>  +    communications.

Done, to a close approximation.

Regards,
Charlie P.

---

From: Mattias Pettersson <[email-masked]>
Date: Tue, 26 Jun 2001 21:11:48 +0200

Hi Charlie,

Charlie Perkins wrote:

> field.  Thus, this purpose could be managed by a single bit.

Yes, get rid of the Prefix Length option. Sounds good.

I really would like to hear people's opinion on if we should keep the
possibility of registering all possible home addresses with one single
BU using a non-zero prefix length. Especially mixing non-zero and zero
prefix lengths seems like a mess.

Either, we need a very strict specification on how to use the two
formats, or we'd get rid of the case "prefix length != 0". I know it is
there to save bandwidth on a scare-bandwidth wireless link MN is
attached to and to minimize messaging, but the complexity on HA and MN
side due to this increases. Still, we can't use non-zero prefix length
towards the CN. I also see cases where the MN and HA have different
opinions on what home addresses are registered due to MPA/MPS/BU/BA
messaging mismatch. This thread has already explained difficulties on
this.

> and have a more natural specification.

Is this draft the Mobile IPv6 draft or another one? Does this have
anything to do with the mobile networks draft by INRIA and Motorola?

Is the idea to send one BU for the registration of the MR itself (prefix
length 128) and a second BU for the registration of the network behind
the MR (prefix length e.g. 64)?

I brought up the issues with this earlier. Do we have a solution for
running some kind of routing protocols between the MR and the home
subnet, in order to update routers and HAs on the home subnet of the
existance of the mobile network behind the MR? In all cases I know of
the routing protocols use link-local addresses in messaging. Link-local
addresses are not handled by Mobile IPv6 and are not tunnelled between
HA and MN.

/Mattias

---

From: Thierry Ernst <[email-masked]>
Date: Wed, 27 Jun 2001 15:36:33 +0200

> anything to do with the mobile networks draft by INRIA and Motorola?

Probably not because I've never had comments from Charlie concerning my
draft and I do not know what Charlie is speaking about ... :-)   I'm
impatient to read the new draft.   Should I assume that Charlie is in
favor of bringing the "Mobile Network support item" up to the WG charter
?

> existance of the mobile network behind the MR? 

I have never heard anything such like this and I think this has nothing
to do with Mobile IPv6.   There is a couple of interesting issues
here.   If we do run a routing protocol between the MR and the home
network, then the MR wouldn't need to perfom Mobile IPv6 anymore.

> In all cases I know of

Thierry.

--
* mailto:[email-masked]  Tel +33 (0) 4 76 61 52 69 
* INRIA Rhone-Alpes Projet PLANETE       (fax 52 52) 
* and MOTOROLA Labs Paris
* http://www.inrialpes.fr/planete/

---

From: Mattias Pettersson <[email-masked]>
Date: Thu, 28 Jun 2001 08:58:31 +0200

Thierry Ernst wrote:

> network, then the MR wouldn't need to perfom Mobile IPv6 anymore.

If the MR runs routing protocols at home, then it should continue to do
so when it is not at home, shouldn't it?

I didn't intend to run routing protocols propagating MR's mobile prefix
over the Internet, but rather in a bi-directional tunnel between the HA
and MN.

/Mattias

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 28 Jun 2001 17:07:00 +0200

> so when it is not at home, shouldn't it?

I guess it should, but doesn't it raises a number of issues ?   I can
think of a larger cost for the path for instance.  Increasing delays may
cause routing table partition and that sort of things.   What about a
multi-homed mobile network ?  Etc ...

> over the Internet, but rather in a bi-directional tunnel between the HA

Of course not, I can not see how one could propagate a MR's mobile
prefix over the Internet, we would end up in breaking aggregation.  No
one would ever think about it ...  Having a bi-directional tunnel and
keep running the routing protocol over the tunnel is the easiest thing
to do, but may be not the best.  All is depending of what kind of mobile
network is behind the MR.   I am going to write a draft to try to
explain the issues.

Thierry.

--
* mailto:[email-masked]  Tel +33 (0) 4 76 61 52 69 
* INRIA Rhone-Alpes Projet PLANETE       (fax 52 52) 
* and MOTOROLA Labs Paris
* http://www.inrialpes.fr/planete/people/ernst/Welcome.html