Subject: [mobile-ip] draft-ietf-mobileip-ipv6-13 comments

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

Hi Dave, Charlie,

I reviewed draft-ietf-mobileip-ipv6-13 while checking
T.J.'s proposal, and discussed my concerns with Vlad
Yasevich, Brian Haley, and Greg Colburn here at Compaq.
The following items apply specifically to draft 13.
I'll send comments on T.J.'s proposal separately.  

Ken

Section 4.6 Conceptual Data Structures

   I don't understand why the following Binding Cache field exists:

 > - The time at which a Binding Request was last sent for this
 >   entry, as needed to implement the rate limiting restriction
 >   for sending Binding Requests.

   I could find two reasons to send a Binding Request:

    o When a binding cache entry is about to time-out (see Section
      8.6). There is no suggestion that the correspondent node
      should retransmit the binding request if the mobile node
      does not respond.

    o When sending a Router Advertisement (see Section 9.8.3). In
      this case, the Router Advertisement with Binding Request does
      get retransmitted and rate-limiting applies.

    Was this Binding Cache field intended to support the rate
    limiting restriction on the router advertisements?

Section 5.6 ICMP Home Agent Address Discovery Request Message

   What does the mobile node specify in the home address field
   if it doesn't have a home address, like upon initialization?
   Should it use the unspecified address in this case?

Section 6.2 Modified Prefix Information Option Format

 > In a solicited Router Advertisement, a router MUST include at least
 > one Prefix Information option with the Router Address (R) bit set.
 > Neighbor Discovery specifies that, if including all options in a
 > Router Advertisement causes the size of the Advertisement to exceed
 > the link MTU, multiple Advertisements can be sent, each containing
 > a subset of the options [17].  In this case, at least one of these
 > multiple Advertisements being sent instead of a single larger
 > solicited Advertisement, MUST include a Prefix Information option
 > with the Router Address (R) bit set.

   Why are these MUST requirements applied to all routers instead
   of just home agents? There is nothing in Neighbor Discovery or
   this spec that relies on this information from IPv6 routers that
   are not home agents. We can see how such information could support
   applications outside the scope of ND and Mobility, but this doesn't
   warrant an unconditional mandate. We would prefer to see something
   like:

 + In a solicited Router Advertisement, a home agent MUST and all
 + other routers SHOULD include at least one Prefix Information
 + option with the Router Address (R) bit set....

Section 7.2 Requirements for All IPv6 Routers

   Should this section list the new requirements from
   section 6.2?

 + - all routers SHOULD include at least one prefix with the R bit
 +   set and with it's full IP address in its router advertisements.

Section 9.2 Dynamic Home Agent Address Discovery

 > - For each entry in this home agents ...
 >                 ... The selected global IP address for each home
 >   agent to include in forming the Home Agent Addresses field in the
 >   Reply message MUST be the global IP address of the respective
 >   home agent sharing a prefix with the mobile node's home address
 >   as indicated in the Home Address option in the Request message;

   During initialization, the mobile node may not have a home
   address when it performs home agent address discovery. Assuming
   the mobile node sent the unspecified address instead, what global
   IP addresses does the home agent select? Perhaps it could
   select IP addresses that share a prefix with the destination
   address from the Home Agent Address Discovery Request packet's
   IPv6 header instead.

   Same problem in the fourth rule for constructing the Home Agent
   Addresses Field:

 >                 ... The selected global IP address for each home
 >   agent to include in forming the Home Agent Addresses field in the
 >   Reply message MUST be the global IP address of the respective
 >   home agent sharing a prefix with the mobile node's home address
 >   as indicated in the Home Address option in the Request message;

Section 9.5 Intercepting Packets for a Mobile Node

 > - The home agent examines the value of the Prefix Length field
 >   in the new "home registration" Binding Cache entry.  If this
 >   value is zero, the following step is carried out only for the
 >   individual home address specified for this binding.  If, instead,
 >   this field is nonzero, then the following step is carried out
 >   for each address for the mobile node formed from the interface
 >   identifier in the mobile node's home address in this binding
 >   (the remaining low-order bits in the address after the indicated
 >   subnet prefix), together with each one of the subnet prefixes
 >   currently considered by the home agent to be on-link ...
                             ==============
   The home agent should forward messages considered by other
   routers on the home network to be on-link as well. In other
   words, we think the home agent should use the aggregate list
   of home network prefixes for this.

 > - For each specific IP address for the mobile node determined
 >   in the first step above, the home agent multicasts onto the
 >   home link (to the all-nodes multicast address) a Neighbor
 >   Advertisement message [17] on behalf of the mobile node, to
 >   advertise the home agent's own link-layer address for this IP
 >   address.
 >
 >   All fields in each such Neighbor Advertisement message SHOULD be
 >   set in the same way they would be set by the mobile node itself
 >   if sending this Neighbor Advertisement while at home [17], with
 >   the following exceptions:
 >
 >    *  The Target Address in the Neighbor Advertisement message MUST
 >       be set to the specific IP address for the mobile node.

   Does the home agent set the Neighbor Advertisement source IP
   address to its own link-local address as opposed to the
   mobile node's link-local address?

 > While a node is serving as a home agent for some mobile node (it
 > still has a "home registration" entry for this mobile node in its
 > Binding Cache), the home agent uses IPv6 Neighbor Discovery [17]
 > to intercept unicast packets on the home link addressed the mobile
 > node's home address.  In order to intercept packets in this way,
 > the home agent MUST act as a proxy for this mobile node to reply to
 > any received Neighbor Solicitation messages for it.  When a home
 > agent receives a Neighbor Solicitation message, it MUST check if the
 > Target Address specified in the message matches the home address
 > of any mobile node for which it has a Binding Cache entry marked
 > as a "home registration".  This check MUST include all possible
 > home addresses for the mobile node, based on the subnet prefixes
 > currently considered to be on-link by the home agent ...
                                      =================

   The home agent probably should use the aggregate list of prefixes
   for this as well?

Section 9.6 Tunneling Intercepted Packets to a Mobile Node

 > Tunneling of multicast packets to a mobile node follows similar
 > limitations to those defined above for unicast packets addressed to
 > the mobile node's link-local and site-local addresses.  Multicast
 > packets addressed to a multicast address with link-local scope [9],
 > to which the mobile node is subscribed, MUST NOT be tunneled
 > to the mobile node; such packets SHOULD be silently discarded
 > (after delivering to other local multicast recipients).  Multicast
 > packets addressed to a multicast address with scope larger
 > than link-local but smaller than global (e.g., site-local and
 > organization-local) [9], to which the mobile node is subscribed,
 > SHOULD be tunneled to the mobile node by default, but this behavior
 > MUST be configurable to disable it; this default behavior might
 > change at some point in the future as the definition of these
 > scopes become better defined in IPv6.

   This spec does not explain how a home agent determines what
   multicast addresses to forward to a mobile node. Host systems
   normally send Multicast Listener Discovery (MLD) messages to
   attached routers to join/leave multicast groups. The rules
   for doing this between mobile node and home agent are undefined.

   The text above and in section 10.19 indicates a bi-directional
   tunnel could be used to support this. There is no clear definition
   of how to set up such a tunnel. What addresses are used for
   tunnel source and destination? Would the tunnel have its own
   link local and global interface addresses? Will it carry MLD
   traffic specifically for the mobile node? What other traffic
   should such a tunnel between a mobile node and the home agent
   carry?

   IMHO we should not try to solve the multicast tunneling
   issues now. Instead, descriptions of tunneling multicast
   traffic should be removed from the spec and left for future
   work. Perhaps the spec could say something like:

 + It may be possible to tunnel multicast traffic between
 + a mobile node and it's home agent to extend the range of
 + a multicast zone. The rules for setting up such tunnels and
 + for identifying which traffic to forward is beyond the scope
 + of this spec.

Section 9.8.2 Sending Changed Prefix Information to the Mobile Node

   T.J. Kniveton proposed numerous changes to this section.
   I couldn't split my comments between the two versions easily.
   Our comments on T.J.'s work will cover items that apply to
   this version as well.

9.8.3. Sending Mobile Prefix Advertisements to the Mobile Node

 > The home agent SHOULD periodically continue to retransmit this
 > tunneled packet to the mobile node, until it is acknowledged by
 > the receipt from the mobile node of a Binding Update matching
 > the Binding Request in the packet (i.e., with matching Sequence
 > Number).  A Binding Update matches a Binding Request if it specifies
 > a binding for the mobile node to which the Binding Request was sent
 > and contains a Unique Identifier Sub-Option matching the unique
 > identifier sent in the Unique Identifier Sub-Option in the Binding
 > Request.

   At what rate should this retransmission occur? Once per
   INITIAL_BINDACK timeout?

   How many router advertisements should the home agent send
   before it gives up?

   Should retransmissions stop if the mobile node's binding is
   deleted?

Section 10.16 Sending Tunneled Router Solicitations

   T.J. Kniveton proposed numerous changes to this section.
   I couldn't split my comments between the two versions easily.
   Our comments on T.J.'s work will cover items that apply to
   this version as well.

Section 10.19 Routing Multicast Packets

 > Alternatively, a mobile node MAY join multicast groups via a
 > bi-directional tunnel to its home agent.  The mobile node tunnels its
 > multicast group membership control packets to its home agent, and the
 > home agent forwards multicast packets down the tunnel to the mobile
 > node.
 >
 > A mobile node that wishes to send packets to a multicast group
 > also has two options:  (1) send directly on the foreign link being
 > visited; or (2) send via a tunnel to its home agent.  Because
 > multicast routing in general depends upon the Source Address used in
 > the IPv6 header of the multicast packet, a mobile node that tunnels a
 > multicast packet to its home agent MUST use its home address as the
 > IPv6 Source Address of the inner multicast packet.

   Same concern with multicast messages as for section 9.6. We think
   this spec should describe option (1) and leave option (2) as beyond
   scope for now.

Section 10.20 Returning Home

 > .....
 > In addition, when returning home prior to the expiration of a current
 > binding for its home address, and configuring its home address on its
 > network interface on its home link, the mobile node MUST NOT perform
 > Duplicate Address Detection on its own home address, in order to
 > avoid confusion or conflict with its home agent's use of the same
 > address.  .....

   Could a mobile node perform DAD if it had knowledge of the home
   agent's link layer address? It could work as follows:

     1) the mobile node runs DAD when it moves to any new
        physical link;
     2) if this happens on the home link, the home agent will
        respond with a neighbor advertisement defending the mobile
        node's address;
     3) the mobile node recognizes the home agent's link
        layer address in the neighbor solicit and thus
        determines it moved home;
     4) the mobile node immediately sends a binding update
        to the home agent to delete the binding (no neighbor
        solicit needed);
     5) the home agent responds with a binding ack to
        signal that the binding is deleted and the home
        agent is no longer defending the mobile node's
        home address;
     6) The mobile node runs DAD again;
     7) Communication proceeds as normal.

11. Protocol Constants

 >   HomeRtrAdvInterval        1,000 seconds

   This is the maximum interval between periodic router
   advertisements from the home agent to the mobile node.
   Given that advertisements are acknowledged and the
   periodic advertisements are primarily a fail-safe
   feature, would it be reasonable to increase this to
   something like 36000 seconds (1 hour) to further
   overhead?