Subject: [mobile-ip] Mobile IPv6 spec issues from Connectathon 2001

From: Alper Yegin <[email-masked]>
Date: Fri, 6 Apr 2001 18:12:30 -0700 (PDT)

This message didn't show up on the mailing list. Resending...

------------- Begin Forwarded Message -------------

For the second year Connectathon covered testing both Mobile IPv4 and Mobile 
IPv6 protocols. During the event, Mobile IP participants got together to discuss 
specification related issues. We came up with a number of them, which was 
outlined in the Connectathon presentation given by Carl Williams and myself at 
IETF 50.

Here's a recapture of Mobile IPv6 spec issues, for those who weren't at the IETF 
meeting (in case they have comments), and for the Mobile IPv6 draft authors to 
incorporate these into the next revision of the draft.

Cheers,

Alper Yegin

[1] Movement detection (section 10.4)

   ... Instead,
   a mobile node SHOULD consider receipt of any IPv6 packets from its
   current default router as an indication that it is still reachable
   from the router.  Both packets from the router's IP address and
   (IPv6) packets from its link-layer address (e.g., those forwarded but
   not originated by the router) SHOULD be considered.

Draft suggests that receiving packets from a node with same link-layer address 
and IP address as current default router means that mobile node is still 
attached to the same link.

BUT, different interfaces of the same router can have the same MAC address, 
therefore same link-local address but advertise different prefixes. In this 
case, mobile node would fail to detect movement if it only looks at the source 
MAC and IP address of packets.

Therefore draft should not suggest a match on source MAC address and IP address 
is sufficient.

[2] Sending binding acknowledgement for failed binding updates (section 5.2)

   Rather, the care-of address used by this node in
   sending the packet containing the Binding Acknowledgement MUST be
   copied from the care-of address received in the rejected Binding
   Update; ...

Draft says receiving node MUST send a binding acknowledgement for failed binding 
updates. It also says the care-of address MUST be copied from the failed binding 
update. 

BUT in the case care-of address is an invalid address such as multicast or 
unspecified address, such an address should not be used as the care-of address 
in binding acknowledgement.

Draft can be updated to say:
- If we have received this binding update as a home agent, we MUST not send a 
binding acknowledgement
- If we have received this binding update as a correspondent node, we MUST send 
the binding acknowledgement to home address (or not send at all?)

[3] Home agent address discovery request message (section 5.6)

Home Agent Address Discovery Request Message includes the Home Address field. 
This information is used by the receiving home agent to return the list of home 
agents matching the prefix of the mobile node.

This request packet is sent to "Mobile IPv6 Home-Agents" anycast address for its 
own home subnet prefix.

The receiving home agent can figure out the prefix of the mobile node just by 
looking at the destination address of the request packet. Therefore Home Address 
field in the request message is not needed in the draft.

[4] ICMPs can delete binding cache (section 8.8)

   If the correspondent node
   receives persistent ICMP Destination Unreachable messages after
   sending packets to a mobile node based on an entry in its Binding
   Cache, the correspondent node SHOULD delete this Binding Cache
   entry. 

The only way binding cache entries can be deleted is through binding updates and 
persistent ICMP unreachables. The former is required to be authenticated, but 
not the latter. The draft should have a proper warning about this, as 
unauthenticated ICMP messages can be used for DoS attacks.

[5] Deregistering a care-of address (section 8.5)

The draft says that binding acknowledgement MUST be sent using a routing header 
in the same way as any other packet sent to a mobile node using a care-of 
address.

BUT, what should be the care-of address used in the case this was a 
deregistration? Draft should specify that it MUST be the care-of address used in 
the triggering binding update. (similarly, draft already specifies that for 
failed binding updates case).

------------- End Forwarded Message -------------