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

From: "Powell, Ken" <[email-masked]>
Date: Mon, 7 May 2001 16:42:00 -0400

Hi T.J.,

I reviewed your proposed changes to draft-ietf-mobileip-ipv6-13
(the version with new ICMP msg types), and discussed some of my
concerns with Vlad Yasevich, Brian Haley, and Greg Colburn here
at Compaq. We are still working through Section 9.8.2. I thought
it worth sending the comments up to that point for now. We'll
send more along later as we work our way through them.

I changed some line-breaks in pasted text for readability. I
understand my mail system tends to chop lines longer than 72
characters.

Ken

Section 4.5 New IPv6 ICMP Messages

   Should this section mention the new ICMP Mobile Prefix
   Solicitation and ICMP Mobile Prefix Advertisement
   messages?

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.

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?

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

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

 > 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
 + in Section 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."

   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.

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?

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

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

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

 > ..... 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. In addition, this does not account for prefixes
   advertised by routers not acting as home agents.

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

      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.

   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?