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

From: "Powell, Ken" <[email-masked]>
Date: Fri, 25 May 2001 13:39:46 -0400

Hi T.J.,

> -----Original Message-----
> From: T.J. Kniveton [mailto:[email-masked]]
> Sent: Thursday, May 24, 2001 11:09 PM
> To: Powell, Ken
> Cc: [email-masked]'; [email-masked]';
> [email-masked]'
> Subject: Re: [mobile-ip] Mobile Prefix Advertisements (more comments)
> 
> 
> "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.
> 
> 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.

OK

> 
> > 
> > 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
> 
> Did you mean Mobile Prefix Solicitation here, or did you really mean
> Router Solicitation?

Oops, I meant Mobile Prefix Solicitation.

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

I was thinking of a case where the mobile node detects that a home
address is about to expire. It may be useful to send a Home Prefix
Solicitation to get the current lifetime for that address.

I agree that we don't need this flag. An alternative would be to
send all prefixes in the aggregate list upon receipt of a home
prefix solicitation, regardless of how (or if) the home
registration was set up. This means that the mobile node might
get some unnecessary junk at times, but it probably wouldn't
be much.

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

I disagree. I believe that when the home agent accepts a home
registration with a non-zero prefix length, it must provide all
prefix changes from the home network to the mobile node. Some
mobile nodes may rely on this information and the home agent
cannot predict which ones. For example, another node may get
the mobile node's new address relatively quickly, perhaps
through an A6 record in DNS, and try to initiate a connection
to the mobile node. I agree that the timing for sending some
changes can be delayed, but I don't think that it should be
dependent on the prefix being used for the registered home
address.

That said, I think it would be reasonable for support of non-zero
prefix lengths to be optional on home agents that are targeted
at specific environments. For example, a home agent that only
supports a mechanism for forwarding from a previous care-of
address as described in section 10.9 wouldn't need to pass any
other prefix information on to the mobile node. Any home agent
that supports a mobile node's permanent home address on networks
configured with stateless address autoconfiguration probably
MUST support the non-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.
> 
> 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.

Good point, but establishing multiple bindings should be the
exception rather than the common case to reduce overhead. The
mobile node should select one address to be its registered home
address. During renumbering events and possibly other occasions,
a mobile node may need to change the address it uses for a home
registration. It makes sense to allow both the old and the new
home registration to exist at the same time to support a smooth
transition. I assume the home agent may forward any message
addressed to any of the mobile node's home addresses to
either care-of address in this situation?

> 
> > 
> >    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.
> 
> Ah, I see what you're getting at. Well, I would first try to 
> sort by the
> care-of address;

I think we should leave the door open for multiple nodes to share
the same care-of address. Such a capability may prove handy for
some future requirement. Therefore, I think it would be a mistake
to assume two bindings with the same care-of address apply to the
same node.

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

I agree for the mobile node's permanent home network. However, section
10.9 "Establishing Forwarding from a Previous Care-of Address" describes
a situation where the mobile node sets up its old care-of address
as a temporary home address. I see no reason to use a non-zero prefix
length with the temporary home addresses.

> 
> > 
> >    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 thought this was clear from the text - perhaps it is clearer in the
> newer revision. Let's follow this up further.

OK

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

I defined "match" as "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."

Therefore, this particular case would happen when there is a
non-zero prefix length on the home registration and some router
advertises a new prefix on the home network.

> 
> > 
> >  > - 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?
> Yes, there seems to be some intermixing of the terms, but I assure you
> that I did a query-replace in draft 14 :)
> 
> > 
> >    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 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?

I was more concerned about the send side on the home agent. I
envision implementing binding option processing in the kernel and
home prefix message handling in a daemon. When the binding update
arrives on the home agent, it is processed in the kernel. The
kernel could easily send a binding ack immediately and signal
the daemon that an update arrived. The daemon then performs its
mobile prefix processing and sends the mobile prefix
advertisement independently if needed. The part that gets awkward
is the requirement for the kernel to synchronize sending the
ack with the daemon's home prefix advertisement. I see no
reason to send the ack on the advertisement other than to
reduce message overhead. The ack could be piggybacked on any
message sent to the mobile node.

> > 
> >  > 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.
> 
> Yes, even with rewording this, there are conditions which 
> could trigger
> similar unwanted flooding. We need to think of ways 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.
> 
> Sounds like a good start.

We intentionally left the mechanisms vague. We figured the
requirements will probably be driven more by the capabilities
of each implementation and their intended environments than
by anything else.

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

Same 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?
> 
> I believe the version of the document you are working with 
> did not have
> all the terminology fleshed out.

Ya, I'm not surprised that you cleaned up a few things since
I grabbed your changes. It's been quite a while.

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

Did you post the changes at the same location as before?

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