Re: secdir review of draft-ietf-hip-mm-04.txt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Tuesday, January 30, 2007 11:04:37 PM +0100 Christian Vogt <chvogt@xxxxxxxxx> wrote:

Given that the protocol right now only allows type-1 locators, do you
think that the handling of different locator types could be left to
those protocol extensions that specify them?

I think you need to specify what happens if you see a type you don't understand, so that when you do specify a new locator type, existing implementations will have a behavior you can depend on. Otherwise, you're painting yourself into a corner with respect to protocol updates.


 After all, a mobile node
using a locator of a type other than 1 would not comply to the current
protocol specification, and hence it would be legitimate for the peer to
drop the mobile node's UPDATEs.

Sure, but the question is whether you _want_ that to be legitimate behavior. If you allow this, then hosts using a new locator type will be unable to probe to discover whether other hosts also support that type, because a negative response is indistinguishable from a dropped packet. I had trouble last week designing a negotiation mechanism for another (non-IETF) protocol with exactly this problem. I recommend against it, but I won't push.


On the other hand, the draft could certainly state in section 5.3
(Handling Received Locators) that "A host MUST drop any received UPDATE
packets that include a locator with a Locator Type other than 1."

I think even that is preferable to leaving the behavior unspecified.


Section 5.2: Sending LOCATORs

 The announcement of link-local addresses is a policy decision; such
 addresses used as Preferred locators will create reachability
 problems when the host moves to another link.

In fact, even a host which is not mobile should be careful to avoid
advertising link-local addresses to peers not on the same link.

Yes, that's true.  We could extend the above sentence to the following:

    Link-local addresses MAY be announced to peers that are known to be
    neighbors on the same link, for example, when the IP destination
    address of a peer is link-local, too.  The announcement of
    link-local addresses in this case is a policy decision; link-local
    addresses  used
    as Preferred locators will create reachability problems when the
    host moves to another link.  In any case, link-local addresses MUST
    NOT be announced to a peer unless that peer is known to be on the
    same link.

I think that would be a good change.  But maybe there are people reading
this thread with more layer-3 expertise than I who can comment...

A mobile node could inspect its IPv6 Neighbor Cache to find whether a
particular peer is on-link, even if that peer is known by a global IP
address.  The mobile node would de-register the link-local address with
the peer when movement detection indicates that the mobile node has
moved to a different link.  The mobile node could further rely on
Neighbor Unreachability Detection to find out when that neighbor has
moved away.

Yes, those all sound reasonable to me.  But I am not an IPv6 expert.

-- Jeff

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]