Re: [netlmm] Comments on draft-giaretta-netlmm-dt-protocol-02

["James Kempf" <[e-mail]>]

Julien,

The problem isn't intermediate reachability of link locals it is their 
uniqueness. There is no requirement in either 2462 or DNA that link local 
address uniqueness be reconfirmed if the default router changes unless the 
subnet prefix also changes. This effectively defines link local as subnet 
local. Using SEND would provide statistical uniqueness but that effectively 
makes DAD useless and won't guarantee lack of clashes. I'm not going to 
argue about the statistical probability of address clashes, we've been 
through that argument numerous times in the IPv6 and MIPv6 WGs and the 
answer always comes down to how we can reduce DAD overhead without removing 
DAD entirely. I think one could apply the same arguments here (and I expect 
we will get these arguments from the IESG if we attempt to argue statistical 
uniquess, and thereby effectively remove DAD, as the answer to this 
problem).

With regard to restricting the link type, there are many ways that links can 
be configured as virtual point to point links without restricting the actual 
layer 2 protocol. In the NETLMM protocol draft, we don't have to specify how 
its done, just what the properties we are looking for are. This approach was 
used in the 16ng draft on address configuration, for example. We might 
consider specifying a default way in the MN-AR interface draft, but I don't 
think it is really necessary there either, unless people really want it.

            jak

----- Original Message ----- 
From: "Julien Laganier" <[e-mail]>
To: "Henrik Levkowetz" <[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, October 05, 2006 7:23 AM
Subject: Re: [netlmm] Comments on draft-giaretta-netlmm-dt-protocol-02


> More below...
>
> On Thursday 05 October 2006 15:57, Henrik Levkowetz
> wrote:
>>
>> On 2006-10-05 14:54 Julien Laganier said the
>> following:
>
> [...]
>
>> > Ok, so in the following let's not assume any
>> > specific link layer on the last hop (and
>> > associated native behavior.)
>>
>> Right.  But I think we need to keep in mind that we
>> could end up requiring some particular link layer
>> behaviour for the current spec, and possibly take on
>> the problem of link- layers that don't perform in
>> this way as a new work item.
>
> Yes that might be one way. My preference would however
> be that any link layer is allowed from day 1, and IMHO
> it is possible (see below.)
>
>> > How can it be possible to require the such
>> > handling of link-locals ("Link-local addresses
>> > have MN-scope only", "the MN will never discover
>> > link-local addresses belonging to other MNs")
>> > addresses from an unmodified host on any type of
>> > link layer?
>>
>> You can't ;-)
>>
>> > For example let's assume Ethernet as a link layer,
>> > and two IPv6 hosts (A and B) attached to it. How
>> > would you prevent host A to reach B using a
>> > link-local multicast ICMP echo request sent to
>> > ff02::1, and receive a unicast ICMP reply sourced
>> > from B's link-local address and sent to A's
>> > link-local address (after B performed address
>> > resolution for A's link local using ND.) ?
>> >
>> > In the above scenario clearly the a link-local
>> > address isn't confined to the MN only, neither
>> > there's an impossibility for a MN to discover
>> > other link-locals on the link.
>>
>> Agreed.
>>
>> > The virtual point-to-point link you evocated could
>> > possibly be implemented using VLANs but then we
>> > start to assume a certain behavior from the link
>> > layer.
>> >
>> > Or I still miss the point...
>>
>> No, you've got the point all right, I guess it's
>> just a matter of deciding which problems we want to
>> be stuck with - having the base spec be applicable
>> and a clean solution for a limited set of link
>> layers, with the remaining link- layers a matter for
>> further development, or having it be applicable to
>> all link layers, but have problems with the random
>> changes in existence and reachability of nodes
>> through link-local addresses...
>
> Agree that it might be sensible to focus on a subset of
> link layers if we're stuck.
>
> However, the problem of the intermittent reachability
> of link-locals isn't IMHO a showstopper.
>
> It's always been a limitation of link-locals that their
> reachability is confined to one link, and that one
> can't assume to maintain long-term communications
> using those.
>
> For example if you consider the situation of two MIPv6
> nodes attached to the same link but originating from
> different home links, then they'll be able to
> communicate with link-locals, but as soon as one move
> elsewhere they won't be able anymore, and have to rely
> on globals to communicate. This is IMHO a very similar
> situation in which we observe intermitent reachability
> of link-locals.
>
> Hence this intermitent reachability doesn't seem to be
> a fundamental issue of NetLMM but rather a generic
> limitation of link-local addresses.
>
> Further, I've seen the point made that link-locals are
> not for applications, but for infrastructure support
> (e.g. DCHP bootstrapping with DHCP, SLAAC and address
> resolution with ND.) Such infrastructure tasks would
> AFAICS not be disturbed by this intermittent
> reachability as long as the infrastructure nodes
> (router and DHCP relay/server) stays reachable.
>
> Finally, if you compare the situation in the proposed
> 'virtual point-to-point link' scenario vs.
> 'intermittent reachability', then the latter isn't
> that bad compared to the former: in the former case
> you have no link-local reachability at all, while in
> the latter at least you get intermittent reachability
> while two MNs happens to sit on the same shared link.
>
>> [...]
>>
>> >> The problem I see with your proposed change is
>> >> that it defines link-local in terms of link
>> >> scope, so in this sense is correct for both the
>> >> current b. and c. without providing a clear
>> >> distinction between them. I explicitly used 'MAG'
>> >> rather than 'link' to remove any assumption about
>> >> the nature of the native MAG - MN link behaviour.
>> >
>> > Ok I now see your point. I proposed this text
>> > because I assumed we cannot force any handling of
>> > link-locals onto an unmodified host: I think the
>> > handling is forced upon us by the underlying link
>> > type (as I tried to sketch above.)
>>
>> Right.  Maybe we need to consider this some more,
>> but I propose we let the current a/b/c text stand
>> for now.
>
> Agreed: Let's first decide on the way to go w.r.t. last
> hop link layer indepedence.
>
> Best,
>
> --julien
>
> _______________________________________________
> netlmm mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/netlmm 


_______________________________________________
netlmm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/netlmm