On Tuesday, January 30, 2007 11:04:37 PM +0100 Christian Vogt
<chvogt(_at_)tm(_dot_)uka(_dot_)de> 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf