Subject: [mobile-ip] Re: from Connectathon 2001

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 05 Sep 2001 13:20:21 -0700

Hello Alper,

Sorry these points didn't make it into revision ...-14, and thanks
to your reminder for inclusion into revision ...-15.

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

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

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

What if we mandate that the routing prefixes must also be considered?

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

Correct!

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

I assume that you meant in the case where the care-of address is
a prohibited destination.  Should we also exclude link-local
care-of addresses?

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

This is O.K. with me -- at least I don't see anything wrong with
it off the top of my head without re-reading all the relevant parts
of the specification.

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

I agree that this should be indicated in the draft.  Probably the right
place for it is within the Security Considerations section.

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

O.K.  Will do.

Regards,
Charlie P.

---

From: Alper Yegin <[email-masked]>
Date: Wed, 5 Sep 2001 14:59:14 -0700 (PDT)

Hi Charlie,

> What if we mandate that the routing prefixes must also be considered?

Yes, that should do.

> a prohibited destination. 

Yes.

> Should we also exclude link-local
> care-of addresses?
> 

I can't think of why a MN would use a link-local CoA, but I can't see a problem 
with this either. Unless somebody see a problem, I'd think link-local is fine.

> place for it is within the Security Considerations section.

Yes.

> > that for failed binding updates case).

Thanks Charlie!

alper