Subject: Re: [mobile-ip] Mobile Prefix Advertisements

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 25 Jun 2001 13:21:12 -0700

Hello again Ken,

> Section 4.5 New IPv6 ICMP Messages
> 
>    Should this section mention the new ICMP Mobile Prefix
>    Solicitation and ICMP Mobile Prefix Advertisement
>    messages?

Yes, definitely!  Done.  (Thanks, T.J.!)

> Section 5.8 ICMP Mobile Prefix Solicitation Message Format
> 
>    Will the Destination Option extension header with a
>    Home Address option normally be included? The exception
>    would be during mobile node initialization when the
>    mobile node does not have a home address yet.

Agreed.  I reckon this should just follow normal rules
for sending packets.  Does it need to be stated explicitly?

> 5.9 ICMP Mobile Prefix Advertisement Message Format
> 
>  > Destination Address
>  >     If a Mobile Prefix Solicitation was sent, the Source
>  >     Address field from that packet.
> 
>    If the Mobile Prefix Solicitation contained a home address
>    option, should the should this Destination Address be set
>    to the mobile node's home address?

Wouldn't the packet be sent with a routing header?  If so,
then this should follow normal rules for sending packets.

> 
>>     For unsolicited
>>     message, the mobile node's home address or care-of
>>     address may be used.
> 
>    I don't think the home agent should send an
>    unsolicited MPA message to the mobile node's
>    care-of address. Unsolicited messages should only
>    be sent when there is a valid home registration,
>    and in that case, sending to the home address seems
>    the best approach. Always doing so would probably
>    make it easier for the mobile node to associate
>    the advertisement with a particular home network.

Agreed.

> 
>    This message header should include a reserved
>    field to align the remaining prefix options on
>    a 64-bit boundary.

Here I am not so sure.  The Prefix Information option
doesn't start with a 64-bit field, and I didn't find
any specification that required an _option_ to be
aligned in a certain way -- only that the data fields
in the option should be aligned in a certain way.
I can see both sides of the argument, and the picture
at the beginning of section 4.6 of RFC 2461 doesn't
appear to mandate the restriction.

>> The Prefix Information option is defined in Section
>> 4.6.2 of [17]. The home agent MAY use the modified
>> option described in this draft to convey other home
>> agents' global addresses as well as their prefixes.
> 
>    Section 9.8.1 indicates the home agent clears
>    global address information of other routers when
>    building the aggregate prefix list. It also calls
>    this a SHOULD requirement. Therefore, I think this
>    statement should be changed to:
> 
>  + The Prefix Information Option is defined in
>  + Section 4.6.2 of [17] with modifications defined
>  +  6.2 of this specification. The home
>  + agent uses this option to send an aggregate
>  + list of home network prefixes as defined in
>  + Section 9.8.1."

Done.

>    It may be helpful to allow the Source Link Layer
>    Address option on the Mobile Prefix Advertisement
>    message. As section 10.20 points out, the home agent's
>    link layer address can be very handy to know before
>    returning home.
> 
>    I think you should also allow the Advertisement Interval
>    Option to support processing defined in Section 10.16.

Good ideas.  Done.

> 9.8.1. Building Aggregate List of Home Network Prefixes
> 
>  > A mobile node on a remote network SHOULD autoconfigure all of
>  > the global IP addresses, which it would autoconfigure if it were
>  > attached to its home network, that are served by home agents.
>                                  ==============================
>    What does this underlined phrase mean?

It means that the mobile node should only get home addresses
this way for networks that are served by home agents; I have
changed the wording to hopefully make that clearer.

> 
>  > To support this, the home agent monitors prefixes advertised on
>  > the home link by itself and other home agents, and passes the ...
>                            =====================
> 
>    Why limit this to prefixes from other home agents only? Why not
>    use prefixes from any router?

I don't think that was the intention.

> 
>> - Check Router Advertisements which contain an H bit (from other
>>   home agents) for valid prefixes that are not yet in the
>>   aggregate list, and if they are usable for autoconfiguration
>>   (A bit set, and prefix length less than 80 bits) add them and
>>   preserve the L flag  value. Clear the R flag and zero the
>>   interface-id portion of the
> 
>    Same question on home agent advertisement restriction. Why
>    not use prefixes from all routers on the home subnet?

What if those other prefixes don't have home agents

>    I noticed you added an interesting optimization of filtering
>    out any prefixes not used for autoconfiguration. This seems
>    like a reasonable thing to do. The mobile node ignores this
>    info when off link, and will rediscover all it needs soon
>    after moving home. Should this same filter be used to restrict
>    which prefixes from the home agent's AdvPrefixList are copied
>    to the aggregate list?
> 
>    I don't understand the test for "length less than 80 bits".
>    I assume that a node cannot autoconfigure to prefixes with
>    different lengths on the same link. The specific length
>    allowed is defined in the "IPv6 over foo" spec (where "foo"
>    is a link type like "ethernet"). Perhaps change this test
>    to "the prefix length is valid for address autoconfiguration
>    on the home subnet".

Done.

More soon.

Regards,
Charlie P.

---

From: "T.J. Kniveton" <[email-masked]>
Date: Mon, 25 Jun 2001 14:18:00 -0700

Thanks for the message Charlie. I agree with all your comments, and
would like to add the following:

> >    to the mobile node's home address?

This level of indirection is unnecessary, and will only work sometimes;
specifically, we can't rely on a home address option, and using the
option when it is there is OK, but not necessary. We don't need to
preserve a MN's Home Address in an advertisement -- the MN should be
ready to receive a MPA at the same address it sent the MPS from,
specifically the COA.

Of course I might be wrong, so let me know if there is a better way to
support both of these cases.

> then this should follow normal rules for sending packets.

A mobile prefix solicitation will sometimes be sent from a mobile node
that is trying to construct a home address; thus, you can't rely on an
home address option.

> changed the wording to hopefully make that clearer.

Yes, that was bad wording. The old requirement was that the MN should be
able to autoconfigure all of the addresses it could on the home network.
I added *another* filter, that only the addresses that are served by a
HA (and thus, usable while away from home) should be required.

> I don't think that was the intention.

Actually it was my intention, so please correct me here because this is
important. In the general case, I do not see how a MN can use a prefix
being advertised on its home link, unless a home agent is willing to
"serve" that prefix by accepting registrations for addresses on the
prefix, and thus forwarding packets to the MN while it is roaming.

So, are you suggesting that a home agent would want to serve mobile
nodes that do not use a home address on a prefix that the HA is
advertising?

> What if those other prefixes don't have home agents

(see above question)

> >    which prefixes from the home agent's AdvPrefixList are copied

In a sense, that was what I was attempting to do above. I was thinking
that the more complexity that can be cut out of constructing, sending,
and receiving/processing the list, the better. But of course this is not
supposed to be at the expense of doing things the wrong way, so please
share your alternate thoughts about how to do it.

> >    to "the prefix length is valid for address autoconfiguration

Well yes, to be precise we could change the wording to say the prefix
has a length less than or equal to 128 minus the interface identifier
length for the media type in use, which is more or less equivalent to
your suggestion.  In other words, sounds good to me. :)
> Charlie P.

Thanks Charlie and Ken.

-- 
        T.J. Kniveton 
  Communications Systems Lab
     Nokia Research Center

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 25 Jun 2001 15:37:40 -0700

Hello T.J.,

> ready to receive a MPA at the same address it sent the MPS from,

I understand that it might not be necessary, and doesn't always
work, but the default address model means that the mobile node
should use its home address when it has one, and the home agent
should send packets to the home address when it needs to send
packets to the mobile node.  I guess the question is whether the
message _always_ invokes exceptional processing, or whether
the exceptional processing is only invoked for exceptional
conditions, like missing Home Address option.

> that is trying to construct a home address; thus, you can't rely on an

I think the same discussion applies here.

> nodes that do not use a home address on a prefix that the HA is

No, my wording was bad.  I was trying to say that the intention was
_not_ to use addresses from routers that are not home agents, but since
I was in a hurry I didn't put enough text around it to be clear.

Regards,
Charlie P.

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 25 Jun 2001 16:29:04 -0700

Hello Ken,

I'm back with more.

"Powell, Ken" wrote:

>  > ..... It may
>  > be possible to construct an aggregate list by combining information
>  > contained in the home agent's AdvPrefixList and its Home Agent List
>  > used for Dynamic Home Agent Address Discovery (section 10.7).
>
>    I don't think this will work. Only prefixes with the "R" bit
>    set are added to the home agent's list. There is no guarantee
>    that all prefixes with an "A" bit set will also have the "R" bit set.

The Home Agents List is formed from home agents that advertise
with the 'H' bit set.  The AdvPrefixList is preconfigured.  Should
there be additional restrictions on which home agent addresses can
be placed in the Home Agent list?  In particular, I don't see that
it is necessary for the home network to support "autonomous"
address autoconfiguration in order for a home agent on that
network to be listed in the Home Agents List.

So far, I don't see what change is needed to the specification
for this issue, but I will await further discussion.

> 9.8.2 Sending Changed Prefix Information to the Mobile Node
>
>    I have multiple concerns in this section. I wish we had
>    a proposal ready to fix these, but that's not so easy.
>
>    1)  There is a requirement at the end of section 9.8.3
>        to send all prefixes periodically. This is necessary
>        to avoid eventual expiration of prefixes that don't
>        change on the mobile node. Between this section, and
>        9.8.3, I'm confused about when all prefixes get sent
>        as opposed to just sending changes.
>
>    2) I don't fully understand what your trying to do with
>       the following MAY requirements:
>
>  > 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
>  > - 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 think this is O.K., as T.J. has noted in a much earlier message.

>
>
>       It looks like its addressing a problem I've been
>       wondering about. A mobile node with multiple home
>       addresses could either
>
>        - establish a single binding with a non-zero prefix
>          length to cover all its home addresses, or
>
>        - 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? The home agent
>       shouldn't send duplicate home prefix advertisements to
>       the mobile node.
>
>       One way to fix this for the home agent to only send
>       prefix information that is applicable to a specific
>       binding. If the prefix length of the binding is zero,
>       send information only for the home address's prefix.
>       If the prefix length is non-zero, send information for
>       all addresses in the aggregate list.

I'm not very clear on this, but I hope that in general that the
home agent can send as many addresses as possible at once.
Otherwise, there will get to be some weird timing dependencies
on sending Binding Updates, retransmissions, and asking for
more home agent addresses.

>    3) There may be a problem if the scheduling algorithm causes
>       the home agent to transmit a home prefix advertisement to
>       all mobile nodes at the same time. There probably should
>       be a requirement to avoid this. Perhaps the scheduling of
>       prefix advertisements should be done independently for each
>       home registration?

Yes, this was the intention.  However, it needs to be made
clearer in the specification so that the intention is more obvious.

Regards,
Charlie P.