Subject: [netlmm] draft-giaretta-netlmm-dt-protocoo: draft revision -02.c available

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 05 Oct 2006 00:28:45 +0200

Hi,

Today's batch of updates to the protocol draft is reflected in
intermediate version -02.c, and covers the items listed below.

Unless somebody points out text which urgently needs changing during
the next hour or so, this is the version I'll submit as -02 to the
secretariat later tonight.

Changes:

  * Tweaked the new security considerations with new text from Mohan.

 Applied changes based on Kent's review dated Sep. 27:
  * Added text to the third paragraph of Section 4 regarding the relationship
    between MN and MAGs.
  * Various fixes to Section 4.1 and 4.2.
  * Added description for some more error cases in Section 7.x, and added a
    new LMA error code, "Not Associated".

 Revisions based on interim WG meeting 26 Sep 2006:
  * Added changes supplied by Nishida-san to clarify Forwarding Update usage.
  * Added changes supplied by Nishida-san for other clarifications and
    corrections.
  * Added text to Section 4.1 to clarify the relationship (or lack of such!)
    between LMA and AAA infrastructure.
  * Added text on rate limitation of messages, Section 4.3.4. (Should this be
    a separate section?)
  * Added Section 4.4 on identity - locator split. Should this be sectin 4.1
    instead?
  * Added Section 7.2.9, about LMA garbage collection.
  * Added clarification of the nature of the MN ID to Section 4.
  * Added Section 4.5 about handling of link-local addresses.
  * Removed the appendix with earlier issues, from Montreal.

The following changes discussed at the interim meeting has *not* been
implemented in this revision:
  - Changing the name of the Location Registration message to 'Forwarding
    Update' to reflect the use of this to indicate forwarding state to the
    LMA also in cases when the MN has not moved. This would leave the
    'Location Deregistration' message with a very mis- aligned name. Needs
    revisiting.
  - Specify per-message which options may occur multiple times.
  - Text about the MAG being a router or a layer 3 bridge.
  - Text about handling of MLD states on handover.
  - How to handle 2461 nodes which doesn't use DNA.

The draft in various formats is available here, as are diffs:

  http://www1.tools.ietf.org/wg/netlmm/dt-draft/

Please check the diffs and review the changes.

Regards,

	Henrik

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

---

From: Julien Laganier <[email-masked]>
Date: Thu, 5 Oct 2006 10:15:07 +0200

Hi folks,

I quickly went through the diff of the new revision 
(-02) against the previous one (-01). I have the 
following comments (my previous comments on -01 still 
hold, I won't repeat them here.)

- In Section 4.5. Handling of Link-Local addresses, 
draft-giaretta-netlmm-dt-protocol-02 makes the 
following statement:

>    The link-local addresses are unique to each MN, or
>    expressed with different words, the link between
>    the MN and the MAG is effectively a point-to-point
>    link, with no other nodes than the MN and the MAG
>    on the link.

i.e. it is restricted to the case where the last hop 
link layer is point-to-point. To me this seems to 
contradict the NetLMM charter:

>   The protocol itself will be agnostic with respect
>   to the last hop link layer protocol between the
>   mobile node and the access router.

or I am missing something?

I also have a comment on one of the Link-Local handling 
scenario described in the draft:

>    b.  Link-local addresses may have MAG-wide scope;
>        i.e., all MNs attached to the same MAG will
>        have link-local reachability to each other. 
>        The consequence of this is that nodes may
>        discover they have link-local reachability at
>        one instant in time, but be deprived of it at
>        the next instant.  In other words, because of
>        node movements, nothing can really be assumed
>        about the reachability of other nodes through
>        link-local addresses from one moment to
>        another. 

IMHO it should be either replaced by the following 
(s/MAG/link/g):

   b.  Link-local addresses may have link-wide scope;    
       i.e., all MNs attached to the same link will
       have link-local reachability to each other.  The
       consequence of this is that nodes may discover
       they have link-local reachability at one instant
       in time, but be deprived of it at the next
       instant.  In other words, because of node
       movements, nothing can really be assumed about
       the reachability of other nodes through
       link-local addresses from one moment to another.

or alternatively, that could be added as a fourth 
scenario (d?)

- In Section 6.5. Prefix Allocation Option and Section 
6.6. Prefix Delegation Option,

There is two descriptions for a field which is not 
present in the Option figures. Are those left over 
from revision -01, or are the figures wrong?

>   Address Prefix
>      Variable.  The value indicates the prefix length
>      of the prefix or address allocated to the mobile
>      node.  If the prefix length is equal to the full
>      address length, the option describes an address 
>      allocation, otherwise it describes a prefix
>      allocation. 

>   Address Prefix
>      Variable.  The value indicates the prefix length
>      of the prefix delegated to the mobile node.

Best,

--julien

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 05 Oct 2006 14:10:08 +0200

Hi Julien,

Thanks for the comments!  More inline:

> or I am missing something?

I think the current text needs tweaking.  Or maybe we're
in big trouble here ,;-)  The point should not be to
require certain native behaviour of the last hop link
layer, but to require a certain handling of link-local
addresses for the MN to MAG connection, amounting to
a (possibly virtual) point-to-point link.

> or alternatively, that could be added as a fourth 

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.

>>      of the prefix delegated to the mobile node.

Leftover.  Should be removed.  Sorry, please disregard those.

Best,

	Henrik

---

From: Julien Laganier <[email-masked]>
Date: Thu, 5 Oct 2006 14:54:13 +0200

On Thursday 05 October 2006 14:10, you wrote:
> [...]

Hi Henrik, thanks for your answer. Please find a follow 
up below:

> > [...]
> > - In Section 4.5. Handling of Link-Local
> > addresses, draft-giaretta-netlmm-dt-protocol-02
> > makes the following statement:
> >
> >> The link-local addresses are unique to each
> >> MN, or expressed with different words, the link
> >> between the MN and the MAG is effectively a
> >> point-to-point link, with no other nodes than the
> >> MN and the MAG on the link.
> >
> > i.e. it is restricted to the case where the last
> > hop link layer is point-to-point. To me this seems
> > to contradict the NetLMM charter:
> >
> >> The protocol itself will be agnostic with
> >> respect to the last hop link layer protocol
> >> between the mobile node and the access router.
> >
> I think the current text needs tweaking.  Or maybe
> we're in big trouble here ,;-)  The point should not
> be to require certain native behaviour of the last
> hop link layer, but to require a certain handling of
> link-local addresses for the MN to MAG connection,
> amounting to a (possibly virtual) point-to-point
> link.

Ok, so in the following let's not assume any specific 
link layer on the last hop (and associated native 
behavior.)

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?

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.

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

> >>    b.  Link-local addresses may have MAG-wide
> >> scope; i.e., all MNs attached to the same MAG
> >> will have link-local reachability to each other.
> >> discover they have link-local reachability at one
> >> instant in time, but be deprived of it at the
> >> next instant.  In other words, because of node
> >    b.  Link-local addresses may have link-wide
> > scope; i.e., all MNs attached to the same link
> > will have link-local reachability to each other. 
> > The consequence of this is that nodes may discover
> > movements, nothing can really be assumed about the
> > reachability of other nodes through link-local
> > addresses from one moment to another.
> >
> 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.)

Best,

--julien

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 05 Oct 2006 15:57:43 +0200

> link layer on the last hop (and associated native 

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.

> unmodified host on any type of link layer?

You can't ;-)

> impossibility for a MN to discover other link-locals 

Agreed.

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

[...]
> forced upon us by the underlying link type (as I tried 

Right.  Maybe we need to consider this some more, but I
propose we let the current a/b/c text stand for now.

Regards,

	Henrik

---

From: Julien Laganier <[email-masked]>
Date: Thu, 5 Oct 2006 16:23:43 +0200

More below...

On Thursday 05 October 2006 15:57, Henrik Levkowetz 

[...]

> > 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.
>
> > possibly be implemented using VLANs but then we
> > start to assume a certain behavior from the link
> > layer.
> >
> 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

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

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 05 Oct 2006 16:38:19 +0200

Hi Julien,

On 2006-10-05 16:23 Julien Laganier said the following:
[...]
> while two MNs happens to sit on the same shared link. 

I agree with your discussion, but I'm not sure I weight
the benefits and drawbacks in the same way you do.  We
probably should have more people contribute at this
point :-)

> hop link layer indepedence.

Right.

Best,

	Henrik

---

From: "James Kempf" <[email-masked]>
Date: Thu, 5 Oct 2006 09:05:23 -0700

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

---

From: "Jun Lei" <[email-masked]>
Date: Thu, 5 Oct 2006 18:43:55 +0200

I've read through the doc and have some comments. Please let me
know if these are relevant.

1. It is mentioned that MAG/LMA failure can be recoganized by heartbeat
mechanism. I am just
wondering if the *cooperative mechanism* would be suitable for NETLMM,
where some selected MAGs/LMAs (e.g.,within the same subnet) work
cooperatively to detect the failures (by kind of cooperative neighboring
notification mechanisms etc).

2. Since NETLMM is a localized mobility management solution, it only
concerns on providing session continuity in a "limited" locality.
However, should we also consider the scenerio that "domain transition"?
For example, a MN moves from one EMD to another EMD. Is it possible to
still maintain such a session by kind of inter-domain NETLMM solution? Here,
I don't care what exactly how large is the NETLMM domain.

3. Regarding the "Handover performance", would it be possible to
integrate FMIPv6 into NETLMM in order to improve the efficiency?

Cheers,

Jun

----- Original Message ----- 
From: "James Kempf" <[email-masked]>
To: "Julien Laganier" <[email-masked]>; "Henrik Levkowetz" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, October 05, 2006 6:05 PM
Subject: Re: [netlmm] Comments on draft-giaretta-netlmm-dt-protocol-02

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

---

From: "Jun Lei" <[email-masked]>
Date: Thu, 5 Oct 2006 18:37:20 +0200

Dear all:

Cheers,

Jun

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 5 Oct 2006 10:42:24 -0700

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

Virtual p2p links over shared links, you mean? Is there a
way to do that w/o restricting a MN's mobility? 

Fred
[email-masked]

---

From: "James Kempf" <[email-masked]>
Date: Thu, 5 Oct 2006 11:36:59 -0700

Why do you think that would restrict mobility?

            jak

----- Original Message ----- 
From: "Templin, Fred L" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Julien Laganier" 
<[email-masked]>; "Henrik Levkowetz" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, October 05, 2006 10:42 AM
Subject: RE: [netlmm] Comments on draft-giaretta-netlmm-dt-protocol-02

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 5 Oct 2006 11:43:37 -0700

> Why do you think that would restrict mobility?

Maybe give some examples of the mobility scenarios you
have in mind for how a virtual p2p link configured over
a shared link is established/deprecated on behalf of a MN?

Fred

---

From: Julien Laganier <[email-masked]>
Date: Fri, 6 Oct 2006 11:09:09 +0200

Hi James,

On Thursday 05 October 2006 18:05, you wrote:
> Julien,
>
> The problem isn't intermediate reachability of link
> locals it is their uniqueness. 

Ok, I thought that was the primary issue at stake here.

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

Right (However there is knob allowing to force DAD even 
when the subnet prefix change, but I don't think we 
want to use that.)

> This effectively defines link local as subnet local.

I am not sure I'd interpret that as you, but anyway I 
agree with your first statement (DAD won't be 
re-executed)

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

Agreed.

So I'd like to discuss this link-local uniqueness 
requirement and the implications it has on support for 
specific link-layers (and the NetLMM protocol itself.)

1) The link is point-to-point: what is required is 
link-local uniqueness on the link, wherever the MN may 
move to. From the MN's point of view that means that 
the (only) other end of the link cannot collide. 

1a) If that end is the MAG a mechanism is needed to 
avoid duplicates between the MN's link-local and all 
of the domain MAGs. This can be accomplished easily by 
having each MAG pick a link-local address for the 
pt-2-pt link after he's been made aware of the MN's 
link local. That can be accomplished by link-specific 
mechanisms, or by looking at the source address of the 
first IP packet sent by the MN when it attaches (NS 
part of DAD, or RS sent as part of DNA.)

1b) If that end is the LMA then the execution of DAD
at initial attachment would take care of that. (I also 
observe that for the last hop to be the LMA you'd need 
a L2 tunneling between MN and LMA as Mohamed discusses 
in his note)

2) The link is shared: what is required is link-local 
uniqueness on the link, wherever the MN may move to. 
From the MN's point of view that means that no 
collision should occurs with any MN/MAG attached to 
the same link, or a link it might attach to later on. 
That can be achieved by having MAG and LMA performing 
proxy DAD (and this is not a multilink subnet) to 
enforce link-local uniqueness across the domain.

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

I am wondering what those "many ways" could be, but 
anyway...

> In the NETLMM protocol draft, we don't have to

If that would be achievable with any link layer, I'd 
definitely agree that it doesn't need to be specified 
in the NetLMM protocol draft. But, as I just wrote I am 
wondering how that can be achieved on any link layer 
(Ethernet?)

Nevertheless, what I've been proposing (and describing 
in the beginning of this note) is to allow for any 
last hop link layer (not only point-to-point.) When 
the last hop link layer is shared that would require a 
specific support from the NetLMM protocol draft (proxy 
DAD by LMA and MAGs), and that would need to be 
specified in the NetLMM protocol draft IMHO.

> This approach was used in the 16ng draft on address
> configuration, for example. 

But you cannot compare the situation in 16ng and 
NetLMM: 16ng is targetting a single link layer (IEEE 
802.16.) And when the IPv6 CS is used the link layer 
indeed provides a point-to-point link from the MN 
point of view.

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

As I stated earlier I'd like the NetLMM protocol and 
interface to allow for any kind of last hop link-layer  
(and I felt there was some support for that). 

Because of the link-local uniqueness issue that we 
discussed here, that translates into having (when 
required, i.e. shared link are present in the domain) 
a proxy DAD functionality built-in the NetLMM protocol 
(and interface.) That functionality would not be 
needed when all links in the domain are pt-2-pt (e.g. 
cellular networks.)

Now I think I fully made my point (sorry for the long 
message), so I'll just wait for other opinions on the 
subject.

Best,

--julien

mCJskiGJBqZXbYHkCzWdoQO5SGOQewdTObvs88MKTlIjpMA2p4k6x7veC1b1BfkP2JDizeL2VWO9SYvTuekW7xj7iIWU9DyOnbfotM6rpCyPYQFZc9cU+SNfUWnSgWc8zbDmM5sTWgf6wReceived: by 10.48.202.19 with SMTP id z19mr5138990nff;
	Fri, 06 Oct 2006 02:21:00 -0700 (PDT)
From: Julien Laganier <[email-masked]>
To: "James Kempf" <[email-masked]>
Subject: Re: [netlmm] Comments on draft-giaretta-netlmm-dt-protocol-02
Date: Fri, 6 Oct 2006 11:09:09 +0200
Cc: [email-masked]

Hi James,

On Thursday 05 October 2006 18:05, you wrote:
> Julien,
>
> The problem isn't intermediate reachability of link
> locals it is their uniqueness. 

Ok, I thought that was the primary issue at stake here.

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

Right (However there is knob allowing to force DAD even 
when the subnet prefix change, but I don't think we 
want to use that.)

> This effectively defines link local as subnet local.

I am not sure I'd interpret that as you, but anyway I 
agree with your first statement (DAD won't be 
re-executed)

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

Agreed.

So I'd like to discuss this link-local uniqueness 
requirement and the implications it has on support for 
specific link-layers (and the NetLMM protocol itself.)

1) The link is point-to-point: what is required is 
link-local uniqueness on the link, wherever the MN may 
move to. From the MN's point of view that means that 
the (only) other end of the link cannot collide. 

1a) If that end is the MAG a mechanism is needed to 
avoid duplicates between the MN's link-local and all 
of the domain MAGs. This can be accomplished easily by 
having each MAG pick a link-local address for the 
pt-2-pt link after he's been made aware of the MN's 
link local. That can be accomplished by link-specific 
mechanisms, or by looking at the source address of the 
first IP packet sent by the MN when it attaches (NS 
part of DAD, or RS sent as part of DNA.)

1b) If that end is the LMA then the execution of DAD
at initial attachment would take care of that. (I also 
observe that for the last hop to be the LMA you'd need 
a L2 tunneling between MN and LMA as Mohamed discusses 
in his note)

2) The link is shared: what is required is link-local 
uniqueness on the link, wherever the MN may move to. 
From the MN's point of view that means that no 
collision should occurs with any MN/MAG attached to 
the same link, or a link it might attach to later on. 
That can be achieved by having MAG and LMA performing 
proxy DAD (and this is not a multilink subnet) to 
enforce link-local uniqueness across the domain.

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

I am wondering what those "many ways" could be, but 
anyway...

> In the NETLMM protocol draft, we don't have to

If that would be achievable with any link layer, I'd 
definitely agree that it doesn't need to be specified 
in the NetLMM protocol draft. But, as I just wrote I am 
wondering how that can be achieved on any link layer 
(Ethernet?)

Nevertheless, what I've been proposing (and describing 
in the beginning of this note) is to allow for any 
last hop link layer (not only point-to-point.) When 
the last hop link layer is shared that would require a 
specific support from the NetLMM protocol draft (proxy 
DAD by LMA and MAGs), and that would need to be 
specified in the NetLMM protocol draft IMHO.

> This approach was used in the 16ng draft on address
> configuration, for example. 

But you cannot compare the situation in 16ng and 
NetLMM: 16ng is targetting a single link layer (IEEE 
802.16.) And when the IPv6 CS is used the link layer 
indeed provides a point-to-point link from the MN 
point of view.

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

As I stated earlier I'd like the NetLMM protocol and 
interface to allow for any kind of last hop link-layer  
(and I felt there was some support for that). 

Because of the link-local uniqueness issue that we 
discussed here, that translates into having (when 
required, i.e. shared link are present in the domain) 
a proxy DAD functionality built-in the NetLMM protocol 
(and interface.) That functionality would not be 
needed when all links in the domain are pt-2-pt (e.g. 
cellular networks.)

Now I think I fully made my point (sorry for the long 
message), so I'll just wait for other opinions on the 
subject.

Best,

--julien

---

From: "Mohamed Khalil" <[email-masked]>
Date: Fri, 6 Oct 2006 11:01:46 -0500

Hi Julien,

"If that end is the LMA then the execution of DAD
at initial attachment would take care of that. (I also 
observe that for the last hop to be the LMA you'd need 
a L2 tunneling between MN and LMA as Mohamed discusses 
in his note)"

Mohamed>> It is not necessary to have L2 tunneling all the way between
MN and LMA, what we can do is to have L2 tunnel between MN and MAG and
between MAG (e.g. BTS/RNC) and LMA we could use L3 tunneling. This is
similar to the L2 tunnel between MN and RNC and the L3 A11/A10 interface
between RNC and PDSN.

-----Original Message-----
From: Julien Laganier [mailto:[email-masked]] 
Sent: Friday, October 06, 2006 4:09 AM
To: James Kempf
Cc: [email-masked]
Subject: Re: [netlmm] Comments on draft-giaretta-netlmm-dt-protocol-02

Hi James,

Agreed.

> example.

Best,

--julien

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 6 Oct 2006 09:44:09 -0700

> enforce link-local uniqueness across the domain.

I think this is discussed in (RFC4389, Section 9).

Fred

---

From: "James Kempf" <[email-masked]>
Date: Fri, 6 Oct 2006 10:08:53 -0700

jak>> There was strong interest at the interim to accommodate nodes that 
don't have DNA. I think the knob is only for DNA nodes. Such an 
accommodation might not support optimization, if the node must wait for an 
unsolicited RA after handover, but it should at least not result in 
incorrect behavior.

jak>> What I mean by this is that the forwarding scope of a link local 
multicast address and therefore domain of uniqueness for link local 
addresses guaranteed by DAD is constrained to those nodes that have the same 
subnet prefix. Accurate forwarding cannot be achieved unless address 
uniqness is guaranteed on the last hop.

Agreed.

jak>>Another way is to have all the MAGs in the domain defend a set of link 
local addresses (which might be exactly one) that are used by all the MAGs. 
These addresses could be included in the router certs for the MAGs for 
example, so CGAs don't have to be used on the MAGs. There is a question 
about how the MAGs could be configured like this, perhaps using DHCP though 
DHCP is not typically used for link local address configuration, or perhaps 
by static configuration. The point is, there are ways around the problem.

jak>> Note that if the MAG is an IP level bridge, it is not IP addressable 
by the MN, since the LMA is the last hop router, so this problem doesn't 
exist. But there are other reasons why making the MAG a router might be 
desirable, and problems with making it a bridge.

jak>> Why would you need an L2 tunnel between the MN and LMA?

jak>> I think proxy DAD is not acceptable due to the fact that it is not 
secured. Secure proxy DAD has come up recently in the MIPv6 WG, nobody seems 
overly interested in working on it. There are also other issues with sending 
link local addresses for MNs around to different MAGs so they can proxy 
them. Right now, the addressing architecture is fairly clean, adding that 
would require more complexity.

jak>>  PPPoE, VLAN, I'm told there are others.

jak>> The point is, it's possible and we don't have to specify it because it 
is a Layer 2 configuration issue.

jak>> As above, regarding drawbacks of proxy DAD.

jak>> Right, I was just saying that this is an example of how it could be 
done. They have the same issue about how to ensure point to point semantics 
on an ASN that is running 802.3 on the wired segment.

jak>> OK. I'd be more inclined to be convinced if I felt there was some 
compelling service scenerio that required maintaining shared link semantics 
for link local addresses, and fewer potential problems.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Fri, 6 Oct 2006 10:16:50 -0700

It requires the ability to either transfer or re-establish a virtual p2p 
link when the mobile node moves to a new link. An example is how 3gpp2 
networks transfer the PPP link from a terminal to the PDSN when a terminal 
moves between PDSNs. Note that I am not saying that this is required for 
NETLMM, just that it is an existence proof. There are other possible Layer 2 
technologies that could be used to establish a virtual p2p link.

            jak

----- Original Message ----- 
From: "Templin, Fred L" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Julien Laganier" 
<[email-masked]>; "Henrik Levkowetz" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, October 05, 2006 11:43 AM
Subject: RE: [netlmm] Comments on draft-giaretta-netlmm-dt-protocol-02

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 6 Oct 2006 10:23:12 -0700

Thanks for citing the examples in this message and your
previous James, but I am concerned about handover latencies.
Taking VLAN over Ethernet as an example, can you provide
references/data that show evidence of voice-quality
handover capability?

Fred

-----Original Message-----
From: James Kempf [mailto:[email-masked]] 
Sent: Friday, October 06, 2006 10:17 AM
To: Templin, Fred L; Julien Laganier; Henrik Levkowetz
Cc: [email-masked]
Subject: Re: [netlmm] Comments on draft-giaretta-netlmm-dt-protocol-02

link when the mobile node moves to a new link. An example is how 3gpp2 
networks transfer the PPP link from a terminal to the PDSN when a
terminal 
moves between PDSNs. Note that I am not saying that this is required for

NETLMM, just that it is an existence proof. There are other possible
Layer 2 
technologies that could be used to establish a virtual p2p link.

            jak

----- Original Message ----- 
From: "Templin, Fred L" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Julien Laganier" 

Fred

---

From: "James Kempf" <[email-masked]>
Date: Fri, 6 Oct 2006 10:39:52 -0700

I'll see if I can find some information on this.

            jak

----- Original Message ----- 
From: "Templin, Fred L" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Julien Laganier" 
<[email-masked]>; "Henrik Levkowetz" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, October 06, 2006 10:23 AM
Subject: RE: [netlmm] Comments on draft-giaretta-netlmm-dt-protocol-02

Fred

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Friday, October 06, 2006 10:17 AM
To: Templin, Fred L; Julien Laganier; Henrik Levkowetz
Cc: [email-masked]
Subject: Re: [netlmm] Comments on draft-giaretta-netlmm-dt-protocol-02

            jak

----- Original Message ----- 
From: "Templin, Fred L" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Julien Laganier"

Fred

---

From: Julien Laganier <[email-masked]>
Date: Sat, 7 Oct 2006 16:22:54 +0200

On Friday 06 October 2006 18:44, Templin, Fred L wrote:
> > That can be achieved by having MAG and LMA
> > performing proxy DAD (and this is not a multilink
> > subnet) to enforce link-local uniqueness across
> > the domain.
>

I think it is important to note the (subtle?) 
difference between proxy ND and proxy DAD. 

As you note, and as is described in RFC4389, it is true 
that proxy ND is incompatible with SEND: that would 
require rewriting of the signed TSLLAO, and hence 
extensions of SEND would be needed.

However, the situation is different with DAD. There's 
no need for proper address resolution in DAD, just 
defend an IPv6 address so that a colliding address 
isn't configured. TSLLAO does not need rewrite for a 
DAD defend to succeed. Thus proxy DAD is compatible 
with *current* SEND, no extension are needed neither 
to SEND nor to DAD.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Sat, 7 Oct 2006 16:33:04 +0200

Hi James,

Cutting most of your message -- I agree with many point 
you made, and my message wasn't intended to discuss 
specific ways of implementing NetLMM on pt-2-pt link 
(I know that can be done without big issues), rather 
to show that it is possible to realize NetLMM on 
shared links.

Realizing that would require secure proxy DAD, and the 
rest of that note tries to show that it is possible...

On Friday 06 October 2006 19:08, James Kempf wrote:
> I am not sure I'd interpret that as you, but anyway
> I agree with your first statement (DAD won't be
> re-executed)
>
> jak>> What I mean by this is that the forwarding
> scope of a link local multicast address and
> therefore domain of uniqueness for link local
> addresses guaranteed by DAD is constrained to those
> nodes that have the same subnet prefix. 

I agree if you do DAD as per RFC2461. However if you do 
secure proxy DAD then you can guarantee address 
uniqueness across the domain.

[...]

> 2) The link is shared: what is required is
> link-local uniqueness on the link, wherever the MN
> may move to. From the MN's point of view that means
> that no collision should occurs with any MN/MAG
> attached to the same link, or a link it might attach
> to later on. That can be achieved by having MAG and
> LMA performing proxy DAD (and this is not a
> multilink subnet) to enforce link-local uniqueness
> across the domain.
>
> jak>> I think proxy DAD is not acceptable due to the
> fact that it is not secured. Secure proxy DAD has
> come up recently in the MIPv6 WG, nobody seems
> overly interested in working on it. There are also
> other issues with sending link local addresses for
> MNs around to different MAGs so they can proxy them.
> Right now, the addressing architecture is fairly
> clean, adding that would require more complexity.

As I noted in my note to Fred:

[...]

[...]

> Nevertheless, what I've been proposing (and
> describing in the beginning of this note) is to
> allow for any last hop link layer (not only
> point-to-point.) When the last hop link layer is
> shared that would require a specific support from
> the NetLMM protocol draft (proxy DAD by LMA and
> MAGs), and that would need to be specified in the
> NetLMM protocol draft IMHO.
>

As above in my note to Fred.

[...]

> jak>> OK. I'd be more inclined to be convinced if I
> felt there was some compelling service scenerio that
> required maintaining shared link semantics for link
> local addresses, and fewer potential problems.

I don't think it's about maintaining shared links 
semantics or service model. It's about being able to 
run NetLMM with existing hardware that provide only a 
shared link service model (an old hub?)

--julien

---

From: "James Kempf" <[email-masked]>
Date: Mon, 9 Oct 2006 09:25:08 -0700

Julien,

The signaling used during DAD is the same as for address resolution. In 
order to ensure secure address resolution, SEND requires that the mobile 
node generate a CGA and sign the NA with an RSA signature. If an unsigned NA 
is received and accepted, it could be a spoof attempt. So I don't see any 
difference between proxy DAD and proxy ND.

            jak

---

From: Julien Laganier <[email-masked]>
Date: Thu, 12 Oct 2006 10:25:08 +0200

James,

On Monday 09 October 2006 18:25, James Kempf wrote:
> Julien,
>
> The signaling used during DAD is the same as for
> address resolution. In order to ensure secure
> address resolution, SEND requires that the mobile
> node generate a CGA and sign the NA with an RSA
> signature. If an unsigned NA is received and
> accepted, it could be a spoof attempt. So I don't
> see any difference between proxy DAD and proxy ND.

Probably I wasn't clear enough. 

I didn't want to say the signalling is different, 
rather that because there are two goals, requirement 
for secure proxying are different:

If one would need to proxy ND for address resolution, 
it would be required to rewrite link-layer addresses 
at the proxies. 

When one need to proxy ND for duplicate address 
detection, it is not required to rewrite anything in 
the *signed* NS and NA -- address resolution isn't 
needed, just detect and signal the collision. 

Therefore *signed* NS and NA can be relayed as they are 
to detect duplicates.

Now citing myself and adding a bit more:

> > However, the situation is different with DAD.
> > There's no need for proper address resolution in
> > DAD, just defend an IPv6 address so that a
> > colliding address isn't configured. TSLLAO does
> > not need rewrite for a DAD defend to succeed. Thus
> > proxy DAD is compatible with *current* SEND, no
> > extension are needed neither to SEND nor to DAD.

As I wrote above, because the TSLLAO does not need to 
be rewritten in case of collision while doing DAD (the 
goal isn't to perform address resolution, but to 
detect and signal the collision) both the NS and the 
NA part of DAD can be signed by their sender as per 
SEND. Then the MAGs and LMA would proxy them "as they 
are". That's what currently is in Section 2.5.1. of 
the MN-AR interface draft (MN using SLAAC configuring 
colliding CGA):

MN1       AR1                 MAP        AR2       MN2
|         |                   |           |         |
| NS(DAD) |UPDATE(MNID,CGA,NS)|           |         |
|-------->|------------------>|colli(MNID)|         |
|         |                   |           |         |
|         |                   | QUERY(NS) | NS(DAD) |
|         |                   |---------->|-------->|
|         |                   | REPLY(NA) |  NA     |
|         |                   |<----------|<--------|
|   NA    |  REPLY[COLLI](NA) |           |         |
|<--------|<------------------|           |         |
|         |                   |           |         |

Hope I was clearer that time; IMHO the above would just 
work with SEND as it is specified. That would be 
different of course if we wanted to implement complete 
proxying of ND (as discussed in RFC4389.)

--julien

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 12 Oct 2006 08:10:28 -0700

I think this is an interesting idea that Julien has put
forward, but I have a question for James - why do you
claim that "the signaling used during DAD is the same
as for address resolution"? As far as I can tell, an
NS used for DAD can be distingushed by the unspecified
source address and no SLLAO, and any resulting NA would
not update any neighbor caches.

This seems different than the signaling during address
resolution; am I missing something?

Fred

-----Original Message-----
From: Julien Laganier [mailto:[email-masked]] 
Sent: Thursday, October 12, 2006 1:25 AM
To: James Kempf
Cc: [email-masked]
Subject: Re: [netlmm] Comments on draft-giaretta-netlmm-dt-protocol-02

James,

MN1       AR1                 MAP        AR2       MN2
|         |                   |           |         |

--julien

---

From: "James Kempf" <[email-masked]>
Date: Thu, 12 Oct 2006 10:20:33 -0700

> it would be required to rewrite link-layer addresses

It is possible to do ND proxying securely without rewriting link layer 
addresses. How you do it depends on how much trust you want to grant the 
router, or whether you would rather not have to grant trust and instead use 
cryptographic verification. But these require changes in RFC 3971.

> Therefore *signed* NS and NA can be relayed as they are

Yes, but this requires forwarding the signed NS and NA around the localized 
mobility management domain. Result: TTL gets decremented and the NS and NA 
are rejected. Unless they are somehow special cased, which is part of the 
multlink subnet problem.

> |         |                   | QUERY(NS) | NS(DAD) |

I don't understand how you could generate a CGA and sign the NA without 
having the public key. The MN owning the CGA has the public key, not AR1 
(BTW, MAP is now deprecated).

            jak

            jak

---

From: "James Kempf" <[email-masked]>
Date: Thu, 12 Oct 2006 10:25:39 -0700

Fred,

You're right. My point was that the basic protocol is the same, and, in 
particular, the protocol for security (which are what are causing the 
problems) is the same. A node that doesn't have the SEND key for a CGA can't 
proxy an NA. So, if we are to maintain security on the ND signaling, either 
we need some way to securely proxy or we need to ship the NA generated by 
the node the holds the CGA key around the localized mobility domain without 
TTL decrement.

            jak

----- Original Message ----- 
From: "Templin, Fred L" <[email-masked]>
To: "Julien Laganier" <[email-masked]>; "James Kempf" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, October 12, 2006 8:10 AM
Subject: RE: [netlmm] Comments on draft-giaretta-netlmm-dt-protocol-02

Fred

-----Original Message-----
From: Julien Laganier [mailto:[email-masked]]
Sent: Thursday, October 12, 2006 1:25 AM
To: James Kempf
Cc: [email-masked]
Subject: Re: [netlmm] Comments on draft-giaretta-netlmm-dt-protocol-02

James,

MN1       AR1                 MAP        AR2       MN2
|         |                   |           |         |

--julien

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 12 Oct 2006 10:34:08 -0700

> or we need to ship the NA generated by the node the
> holds the CGA key around the localized mobility domain
> without TTL decrement.

If I understand correctly, I believe that is what
Julien is proposing.

Fred

---

From: "James Kempf" <[email-masked]>
Date: Thu, 12 Oct 2006 10:38:32 -0700

I thought he was proposing that the AR signal the LMA and that the LMA 
indicate whether there is a collison or not, but that the AR generate the NA 
responding to the DAD NS itself. I didn't see any sign of the LMA forwarding 
the NS around the LMD.

            jak

----- Original Message ----- 
From: "Templin, Fred L" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Julien Laganier" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, October 12, 2006 10:34 AM
Subject: RE: [netlmm] Comments on draft-giaretta-netlmm-dt-protocol-02

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 12 Oct 2006 10:43:26 -0700

> I didn't see any sign of the LMA forwarding 
> the NS around the LMD.

Maybe take another look at his text and diagram
(because it seems clear enough to me) and/or wait
to hear what Julien has to say about it.

Fred

---

From: "James Kempf" <[email-masked]>
Date: Thu, 12 Oct 2006 10:52:17 -0700

OK.

I agree that if the LMA forwards the NS around the LMD, and if a node 
replies, the MAG forwards the SEND-secured NA through the LMA, then it could 
be done without decrementing TTL and with SEND.

It would require a change in the NETLMM protocol specifically to support 
shared link networks, which is something that we've been trying to avoid 
(putting something into the NETLMM protocol to support specific types of 
link layers). Also, I am not sure if that would be acceptable to the IESG 
and IAB. I think it would be advisable to discuss it with Dave Thaler first.

            jak

----- Original Message ----- 
From: "Templin, Fred L" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Julien Laganier" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, October 12, 2006 10:43 AM
Subject: RE: [netlmm] Comments on draft-giaretta-netlmm-dt-protocol-02

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 12 Oct 2006 11:04:44 -0700

> Also, I am not sure if that would be acceptable to the IESG 
> and IAB.

Seems like it would be best to have something like this
standardized, but is standardization really necessary
given that it has already been documented here (and
probably elsewhere)? And, would any interest groups be
disenfranchised were it not standardized?

Fred

---

From: Julien Laganier <[email-masked]>
Date: Fri, 13 Oct 2006 10:01:55 +0200

On Thursday 12 October 2006 19:34, Templin, Fred L 
wrote:
> > or we need to ship the NA generated by the node
> > the holds the CGA key around the localized
> > mobility domain without TTL decrement.
>

Yes this is what I've been proposing.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Fri, 13 Oct 2006 10:01:16 +0200

On Thursday 12 October 2006 19:20, James Kempf wrote:
> > rather that because there are two goals,
> > requirement for secure proxying are different:
> >
> > If one would need to proxy ND for address
> > resolution, it would be required to rewrite
> > link-layer addresses at the proxies.
>
> It is possible to do ND proxying securely without
> rewriting link layer addresses. How you do it
> depends on how much trust you want to grant the
> router, or whether you would rather not have to
> grant trust and instead use cryptographic
> verification. But these require changes in RFC 3971.

Yes, no argument here.

> > detection, it is not required to rewrite anything
> > in the *signed* NS and NA -- address resolution
> > isn't needed, just detect and signal the
> > collision.
> >
> > Therefore *signed* NS and NA can be relayed as
> > they are to detect duplicates.
>
> Yes, but this requires forwarding the signed NS and
> NA around the localized mobility management domain.
> Result: TTL gets decremented and the NS and NA are
> rejected. Unless they are somehow special cased,
> which is part of the multlink subnet problem.

Yes they would be special cased: NSs and NAs part of 
DAD for a link-local address would be relayed by the 
NetLMM protocol without TTL decrement, not just 
forwarded.

IMO this has nothing to do with the multilink subnet 
problem:

	- we're discussing relaying NSs and NAs part of DAD
          for link-local addresses (and they have no
          subnet!)
	- we're not discussing forwarding across different 
          links any IP packets with source and 
          destination within the same subnet.

> >> > There's no need for proper address resolution
> >> > in DAD, just defend an IPv6 address so that a
> >> > not need rewrite for a DAD defend to succeed.
> >> > Thus proxy DAD is compatible with *current*
> >> > SEND, no extension are needed neither to SEND
> >> > nor to DAD.
> >
> > As I wrote above, because the TSLLAO does not need
> > to be rewritten in case of collision while doing
> > DAD (the goal isn't to perform address resolution,
> > but to detect and signal the collision) both the
> > NS and the NA part of DAD can be signed by their
> > sender as per SEND. Then the MAGs and LMA would
> > proxy them "as they are". That's what currently is
> > in Section 2.5.1. of the MN-AR interface draft (MN
> > using SLAAC configuring colliding CGA):

MN1       AR1                 LMA        AR2       MN2
|         |                   |           |         |

> > Hope I was clearer that time; IMHO the above would
> > just work with SEND as it is specified. That would
> > be different of course if we wanted to implement
> > complete proxying of ND (as discussed in RFC4389.)
>
> I don't understand how you could generate a CGA and
> sign the NA without having the public key. The MN
> owning the CGA has the public key, not AR1 (BTW, MAP
> is now deprecated).

MN1's and MN2's CGAs are generated by MN1 and MN2, 
respectively. In case of collision, AR1, AR2 and LMA 
just relay (without TTL decrement) the NS signed by 
MN1 and the NA signed by MN2.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Fri, 13 Oct 2006 10:28:01 +0200

On Thursday 12 October 2006 19:52, James Kempf wrote:
> OK.
>
> I agree that if the LMA forwards the NS around the
> LMD, and if a node replies, the MAG forwards the
> SEND-secured NA through the LMA, then it could be
> done without decrementing TTL and with SEND.
>
> It would require a change in the NETLMM protocol
> specifically to support shared link networks, which
> is something that we've been trying to avoid
> (putting something into the NETLMM protocol to
> support specific types of link layers).

I have some sympathy with the goal of avoiding to put 
something into the NetLMM protocol to support specific 
types of link layers. 

However, I'd like to make the following observations 
w.r.t. to the relay DAD for link-locals functionality 
in NetLMM:

First, the need isn't entirely specific to shared 
links. Let's consider the situation where the link is 
point-to-point and the MAG acts as the next-hop router 
for the MN: we need to avoid link-local address 
collisions between any MN and any MAG to which the MN 
might attach later on (not only the one to which it 
attaches when it first configures the link-local and 
perform DAD.) This avoidance can be realized in two 
ways:

1) all MAGs are configured with a single link-local 
addresses (which would require, when SEND is used, to 
share the same public key across all MAGs -- that 
wouldn't be a good thing IMO), and 

2) we do secure relay DAD for link-local addresses to 
avoid MN to configure the same link-local that any of 
the MAGs in the domain.
		
Second, while building in the protocol support for 
specific link layer types can be seen as a limiting 
factor for its link layer "agnosticism", not 
supporting relay DAD would presumably making it 
difficult to run it on shared links, which are 
arguably a huge proportion of deployed access 
networks. IMO that would indeed limit NetLMM 
applicability to the Internet at large.

Finally, I'd observe that this relay DAD procedure is 
pretty scalable, it doesn't require flooding the 
domain with DAD packets, but only relay them to the 
MAG where the collision occurs (if it occurs!)

> Also, I am not sure if that would be acceptable to
> the IESG and IAB. I think it would be advisable to
> discuss it with Dave Thaler first.

If you are concerned by multilink subnet issues, as 
I've been arguing in some of my other notes, I don't 
think relay DAD for link-local addresses is related to 
multilink subnet issues.

I am however open to consult Dave Thaler again if the 
WG is concerned about relay DAD for link-local 
addresses introducing multi-link subnet issues.

--julien

> To: "James Kempf" <[email-masked]>;
> "Julien Laganier" <[email-masked]>
> Cc: <[email-masked]>

---

From: "James Kempf" <[email-masked]>
Date: Fri, 13 Oct 2006 08:40:29 -0700

Julien,

I don't think not using relay DAD would limit deployment on shared links. 
There are ways to get an effective link layer point to point connection with 
them. But if you can convince Dave and Jari that relay DAD is OK, then I am 
fine with having it in the draft.

Regarding configuring MAGs with a shared link local address, that could be 
done or there could be a collection that all defend. CGAs needn't be used, 
the addresses could be contained in the router certificate. The RFC 3971 
allows certified addresses, it just does not say anything about how they are 
used. That would, of course, limit security on existing nodes.

            jak

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 13 Oct 2006 08:52:19 -0700

> I don't think not using relay DAD would limit deployment
> on shared links. There are ways to get an effective link
> layer point to point connection with them.

You said you would try to locate some information for
us on performance aspects for dynamically configuring
these kinds of (virtual) p2p links:

http://www1.ietf.org/mail-archive/web/netlmm/current/msg00803.html

were you able to find anything? 

Fred

---

From: "James Kempf" <[email-masked]>
Date: Fri, 13 Oct 2006 10:19:26 -0700

Not yet.

            jak

----- Original Message ----- 
From: "Templin, Fred L" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Julien Laganier" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Friday, October 13, 2006 8:52 AM
Subject: RE: [netlmm] Comments on draft-giaretta-netlmm-dt-protocol-02

Fred

---

From: "James Kempf" <[email-masked]>
Date: Sun, 15 Oct 2006 15:45:14 -0700

I got some information on VLAN establishment performance. Establishing a new 
VLAN is less than 3 msec. The number comes from a well known vendor's home 
agent product, which also does a VLAN per mobile node.

Hope that helps.

            jak

----- Original Message ----- 
From: "Templin, Fred L" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Julien Laganier" 

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 16 Oct 2006 08:29:41 -0700

James,

Thanks, but I would need to see some more details, e.g.,
on what type of media are you talking about? And, is a
similar VLAN capability available across a wide range of
shared media types? Also, how is the VLAN signaling done?
(In particular, does the MN need to get involved with the
VLAN signaling?) If possible, please cite some references.

Fred

-----Original Message-----
From: James Kempf [mailto:[email-masked]] 
Sent: Sunday, October 15, 2006 3:45 PM
To: Templin, Fred L; Julien Laganier
Cc: [email-masked]
Subject: Performance of VLAN establishment (was: Re: [netlmm] Comments
on draft-giaretta-netlmm-dt-protocol-02)

I got some information on VLAN establishment performance. Establishing a
new 
VLAN is less than 3 msec. The number comes from a well known vendor's
home 
agent product, which also does a VLAN per mobile node.

Hope that helps.

            jak

----- Original Message ----- 
From: "Templin, Fred L" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Julien Laganier" 

Fred