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

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

Hello Ken,

I've been delayed for quite a while in getting back to you on
this, but it was never forgotten.  I'm trying to catch up on the
way to finishing the new draft.

"Powell, Ken" wrote:

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

I think so.  I guess that means that the actual restriction is
the one placed on the advertisement.  Therefore, I guess you mean
to suggest that we can delete this field of the Binding Cache
entry.  I have done that, since I don't see any other reason
to keep it.  However, I'm open to further discussion!

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

O.K.  This sounds fine to me, but I expect that there may be
some networks where policy forbids the operation.  Anyway,
whether or not the operation works should be controlled by
whether the mobile node can create a security association,
and not by whether the protocol specification says which
addresses to use.

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

Done.  I agree with your analysis.

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

Done.  Thanks!

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

Done.  I replaced:
	"mobile node's home address as indicated in the Home Address option in"
by
	"Destination IP address of"

However, I only found one instance of the problem; your first example
was, I think, the text in the fourth rule.  Please let me know if somehow
I missed something.

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

I don't know about this.  It seems to me that the current wording
is correct.  I don't know about why a home agent would try to
protect addresses that it considers to be off-link.

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

I think the purpose is for the home agent to substitute its own
link-layer address for that of the mobile node.  And, it needs to
do this for the mobile node's link-local IPv6 address also.  Thus,
I wouldn't expect for the home agent to use its own link-local
address in that field.

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

Maybe I'm missing something, but I think the "on-link" criterion
is appropriate here 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.

Not really...?  Why can't the tunneled packets use the same rule
as in other cases.  In other words, the mobile node should use
a Home Address destination option here, but that would be implicit.
It would be a mistake for the Mobile IPv6 specification to go specify
the inclusion of the Home Address option for _every_ possible application
between endpoints.  Tunneling is not essentially different here, as far
as I can tell.

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

I don't think there is a problem here.  The tunnel should be set
up just like any tunnel would be set up.  The outer header should
have the natural IP addresses.  A home address destination option
would be used as normal.  The inner header should have the same
field values as if the mobile node were on its home network.

Policy determination for tunnel use is, I reckon, outside the scope
of the Mobile IPv6 specification.  Otherwise, we would have to do
it for every protocol, not just MLD.  That could be bad, and seems
like a major potential source for specification errors.

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

As of now, I don't believe this is the right technical direction;
I have left the current specification as is.

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

I have added the following:

   The home agent SHOULD periodically continue to retransmit an
   unsolicited Advertisement 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).  The home agent MUST wait PREFIX_ADV_TIMEOUT
   before the first retransmission, and double the retransmission wait
   time for every succeeding retransmission, up until a maximum of
   PREFIX_ADV_RETRIES attempts.  If the mobile node's bindings expire
   before the matching Binding Update has been received, then the home
   agent MUST NOT attempt any more retransmissions, even if not all
   PREFIX_ADV_RETRIES have been retransmitted.  After another Binding
   Update is received from the mobile node, and if the mobile node has
   not returned to the home network in the meantime, the home agent
   SHOULD begin the process again of transmitting the unsolicited
   Advertisement.

Thanks for the roadmap about what needed to be done.

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

Well, I hope we can keep the specification.  It's likely to work well
enough for Proposed Standard, and deployment and experience are clearly
needed.

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

I don't see anything wrong with this, but on the other hand I am
reluctant to put it into the revised protocol specification without
some additional working group discussion.

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

I guess you meant 3600 seconds.  So, I made that change.

Regards,
Charlie P.