Subject: Re: [mobile-ip] Re: Connectathon input for Mobile IPv6 draft revision

From: Alper Yegin <[email-masked]>
Date: Fri, 21 Sep 2001 15:32:04 -0700 (PDT)

Hi Charlie,

> > [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.
> 
> Here, the important thing seems to be that the mobile node is
> still reachable from the router.  Other problems would presumably

Actually it is not reachable. MN is just attached to another link on the AR. The 
packets coming from the AR can have the same MAC address (a legal choice and a 
feature on some platforms) and the same source IP address (link local address 
derived from the same MAC address). But MN is not "reachable", because it's 
using a prefix from another link, not the current link.

> be resolved by way of Neighbor Discovery (not Mobile IPv6), and
> so should not be specified again within Mobile IPv6.  Here is the
> current relevant text:
> 
>     Instead, when a mobile node receives any IPv6 packets from its
>     current default router at all, irrespective of the source IPv6
>     address, it SHOULD use that as an indication that 
>     it is still reachable from the router.

That doesn't work, as I explained above. Only if the same prefix is advertised 
on this link, then MN can conclude it's reachable.

So, I suggest we remove the text in the draft that suggests checking source IP 
address and MAC address is sufficient.

> 
> Is this O.K.?
> 
> 
> > [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?)
> 
> This requires further revision to the last text I sent out about
> deregistering care-of addresses:
> 
>     -  Otherwise, if the Source IP Address of the packet containing
>        the Binding Update, is legal for inclusion in a Routing Header,
>        the routing header will be constructed using that IP address.
>        Note that multicast addresses, link-local addresses, and the
>        unspecified address, MUST NOT be used within a Routing Header for
>        the Binding Acknowledgement.
> 
>     -  Otherwise, if the Binding Update has a zero lifetime but the
>        Source IP address is not allowable for use within the Routing
>        Header, the Binding Acknowledgment MUST be sent to the mobile
>        node's home address
> 
> I also inserted the following prohibition within section 5.1:
> 
>     In any case, the care-of address MUST NOT be any IPv6 address
>     which is prohibited for use within a Routing Header; thus
>     multicast addresses, the unspecified address, loop-back address,
>     and link-local addresses are excluded.  Binding Updates indicating
>     any such excluded care-of address MUST be silently discarded.
> 

Looks good to me.

> 
> 
> > [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. 
> 
> I didn't see any discussion about this.  And, as best I can tell,
> you are correct in your assertion, because a home agent couldn't
> respond to the "Mobile IPv6 Home-Agents" anycast address without
> knowing the routing prefix for that anycast address.  So, I've
> deleted that field.  This also removes the need to say anything
> about what happens if the mobile node doesn't have a home address.
> 
> Once the Home Address field is gone, the alignment requirement
> for ICMPv6 messages is is (I think) different, so I reduced the
> Reserved field to only 16 bits.
> 
> Furthermore, I don't see any reason to restrict the inclusion
> of a Home Address option.  Such a thing might be handy if, in
> the future, we can devise a security association with an anycast
> group.  Besides that, it might be the case that home agent
> discovery is initiated when the mobile node has a perfectly
> valid care-of address for one of its other home addresses,
> so some of the other wording in the relevant section has been
> changed.
> 
> Lastly, if it is decided that this ICMPv6 message can also be
> used by the mobile node to request a home address, that can
> be done by using a bit from the Reserved field, but I reckon
> that is something we can defer for a long time.
> 

Sounds good.

> 
> > [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.
> 
> O.K.  I have borrowed your wording as part of a statement to this effect
> in the Security Considerations:
> 
>     The only way binding cache entries can be deleted is through Binding  
>     Updates and persistent ICMP unreachables messages.  The former are
>     required to be authenticated, but not the latter.  Therefore,
>     unauthenticated ICMP messages can unfortunately be used 
>     for DoS attacks.   However, the security exposure is limited,
>     since the effect would be only to cause packets for the mobile
>     node to be sent by way of the mobile node's home network.
> 

Looks good.

> 
> > [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).
> 
> According to recent discussion, I hope this problem has been fixed.
> 

Yes, except the care-of address vs. source address issue I pointed out.

> Regards,
> Charlie P.

Thanks Charlie.

alper

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 21 Sep 2001 16:53:17 -0700

Hello again Alper,

> using a prefix from another link, not the current link.

Maybe it would be enough to say that the mobile node should use the
lack of continued advertisement of a particular prefix as evidence that
it is no longer connected to the interface which had advertised that
prefix.

> address and MAC address is sufficient.

Can you be more specific about which text you would like to see removed?

Regards,
Charlie P.