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

From: "Powell, Ken" <[email-masked]>
Date: Mon, 21 May 2001 13:52:47 -0400

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.

   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.

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?

 > 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?

 > - 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. 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.

   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.

 > 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;

 > - 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.

 > - 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?

 > - 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?

 > - 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.

 + - 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.
 
 > - 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.

   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,
 +   cancel it.

   Should the following be added here for completeness?

 + - If a home registration expires, cancel any scheduled
 +   advertisements to the mobile node. 

 > 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.

 > 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.

 + 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.

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.

 > 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?

 > [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.

   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.

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?

 > 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.

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?

 > 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.

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.

---

From: "T.J. Kniveton" <[email-masked]>
Date: Thu, 24 May 2001 20:09:08 -0700

> to draft-ietf-mobileip-ipv6-13 without your changes

Thanks for your efforts! I will try and make some brief and immediate
comments, and please see my note at the end of the message as well.

>    Router Solicitation? I think the home agent should use the

Did you mean Mobile Prefix Solicitation here, or did you really mean
Router Solicitation?

>  +   not yet have a home registration.

When the mobile node is initializing, the home agent would not have a
home registration to refer to for prefix length. It seems to me that in
the case where the mobile node specifically requests prefixes, it is
probably best to give it all the prefixes on the home link served by
home agents. Can you elaborate on the benefits and functionality allowed
by a "Send All Prefixes flag," aside from some posssible reduction in
M.P.A. length?

>    where a home registration has a zero prefix length?

It is a may because I do not see it as essential for a mobile node,
which already has a home registration and presumably can use its
configured home address, to be able to configure additional home
addresses as the prefixes become available on the home network. It may
be possible to imagine a situation where the mobile node *would* want to
immediately use these addresses, but it doesn't seem important enough to
schedule a new M.P.A. just for this purpose.

>       length to cover a single home address.

Couldn't it establish multiple bindings, each with a non-zero prefix
length? That would be what I would expect to happen, since the key is
the home address, not the care-of address. That is to say, it would seem
valid to have multiple home addresses each registered (and prefix length
noted), pointing to the same care-of address.

>    advertisements to the mobile node.

Ah, I see what you're getting at. Well, I would first try to sort by the
care-of address; however, the mobile node could have a different care-of
address for each home address as well. In that case, it seems much
harder to tell when multiple bindings are the same machine. However, I
do not think that registering a zero prefix length would be the best
solution at this time.

>  + created for a separate mobile node.

I thought this was clear from the text - perhaps it is clearer in the
newer revision. Let's follow this up further.

>    into this section to avoid confusion between the two sections.

Yes, this has changed in the next version.

>    case from here simplify the text?

Good idea.
>  +   a transmission is scheduled at time RAND_ADV_DELAY in the future.

It's not clear to me how a prefix could be *added* that matches the
mobile node's home registration - wouldn't it have to be in the list for
the home registration to be accepted initially?

>    Did you mean Mobile Prefix Advertisement here?
Yes, there seems to be some intermixing of the terms, but I assure you
that I did a query-replace in draft 14 :)

>    probably handled in the kernel and Mobile Prefix Advertisements

I guess it depends on the implementation - it should be possible for the
kernel to grab the binding ack off the packet before it gets to user
space, no?

>  +   advertisements to the mobile node.

Good points.

>    complexity will be significant. We would prefer this to be an

I would tend to agree with you.
>    The spec should allow a mechanism to avoid this.

Yes, even with rewording this, there are conditions which could trigger
similar unwanted flooding. We need to think of ways to avoid this.

>  + to large numbers of mobile nodes.

Sounds like a good start.
>    Should it be removed here too?

I believe it was.

>  > Advertisement from the home agent. ...              ======

Yes, the security issues are probably the most unresolved, and I have
left room in draft 14 for a security association based on IPsec to
continue to exist, but I have many question marks on this issue.

>  >   Advertisement is .....                           ======

I believe the version of the document you are working with did not have
all the terminology fleshed out.

>    I noticed you didn't attempt to fix this part. How about:

Hmm, I was hoping you wouldn't notice ;)

>  + 10. Receive binding acknowledgement(s) then begin normal

This looks good. Thanks for all of your comments. Since there were some
more changes, which I alluded to, between the time I sent you the text
version you made comments on, and the updated (but not yet 14) draft
Charlie posted a link to yesterday, it might be best if we compare your
comments to that.

It would be ideal for us to just talk about this face to face, since
there are some difficult issues which are hard to fully discuss via
e-mail. I'd like to also point out (to everyone) that this section, or
at least as it relates to renumbering, and the changes I made to it are
still in what I would call a "research" stage; that is to say, there is
room for change before it will be mature and fully usable. So let's
continue to improve it and comments are still welcome even after draft
14 is submitted.

Thanks,

-- 
T.J. Kniveton
NOKIA Research