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

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 21 Sep 2001 13:53:12 -0700

Hello Alper,

Alper Yegin wrote:
> 
> I assume the "Connectathon 2001 feedback on the Mobile IPv6 draft" will
> also be incorporated into this upcoming version. Right? I attached the
> original e-mail that details the issues which were both presented at IETF
> 50 and sent on the mailing list before. 

Thanks, Alper.  As noted, I am finally trying to catch up on this...

>From your earlier note (slightly reformatted to fit my screen better):

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

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

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.

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

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

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

Regards,
Charlie P.

---

From: Francis Dupont <[email-masked]>
Date: Tue, 25 Sep 2001 10:59:17 +0200

=> argh! Link-local addresses are legal in some cases, what is
forbidden is zone mismatch and/or ambiguity (i.e. the source, the
current destination and the next destination must be in the same zone,
in case of link-local in the same link).

   
=> same remark but I agree a link-local address must be prohibited
(i.e. the argument is wrong in its form but right in deep).
   
Regards

[email-masked]

PS: I believe that Itojun would like to add IPv4 mapped addresses
in the list of forbidden address kinds.