Subject: [netlmm] Re: Why is PMIP a superior solution for NETLMM requireiments?

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 01 Nov 2006 15:34:23 +0100

Sri Gundavelli wrote:
> 
> 
> On Tue, 31 Oct 2006, Alexandru Petrescu wrote:
> 
>> Sri Gundavelli wrote:
>> 
>> Who tells AR the MN MAC address?  Neighbour Discovery - no.  Other 
>> l2 means? Which other?  Which l2.
>> 
> 
> Hi Alex,
> 
> The proxy mip signalling is triggered after the AR/PMA detect the 
> mobile on its link after the access authentication. It will certainly
>  know the MN's MAC address, as part of the access authentication 
> procedures

Access authentication - yes, that involves NAI and the MAC address.  So
it is necessary to have specified the use of a certain access control
protocol in order to have the RA targetted to a mobile.

But, if we know which access control protocol we use then we don't
necessarily need prefix-per-mobile, not even need to send RA.  The
address allocation happens as part of that access control.

> or when the mobile does a router solicitation.

That involves the use of link-layer triggers: send RS only when changing
attachment.  The link-layer triggers are very specific to a link.  There
is a need to stay independent of link type.

For some links that are pertinent to netlmm we don't even know how to
generate link-local addresses, so AR wouldn't know where to send RA.

And, by rfc 2461 one can't send an RA to a particular MAC address (in
the ll header) but unknown dst IP address - the dst IP address must be
either the one from RS, or multicast all-nodes (we don't want).

With DHCPv6 the things are a little bit different, by my comprehension,
in that there are not such restrictions.  A Relay can send a Relay-Reply
to mobile (specifying its MAC address) and without specifying an IP address.

Alex

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 1 Nov 2006 08:59:16 -0800

> either the one from RS, or multicast all-nodes (we don't want).

As I have been saying for some time, why not just send RAs
with IP_dst=all-nodes-multicast and L2_dst=MN's MAC address?

Fred
[email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 01 Nov 2006 18:06:12 +0100

> with IP_dst=all-nodes-multicast and L2_dst=MN's MAC address?

I think it's because when one wants prefix-per-mobile model one doesn't 
want RA multicasted to all MNs.  Or so?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 01 Nov 2006 18:13:15 +0100

Sri Gundavelli wrote:
> 
> 
> On Wed, 1 Nov 2006, Alexandru Petrescu wrote:
> 
>> Templin, Fred L wrote:
>>>> And, by rfc 2461 one can't send an RA to a particular MAC
>>>> address (in the ll header) but unknown dst IP address - the dst
>>>> IP address
>>> must be
>>> As I have been saying for some time, why not just send RAs with
>>> IP_dst=all-nodes-multicast and L2_dst=MN's MAC address?
>> 
>> I think it's because when one wants prefix-per-mobile model one 
>> doesn't want RA multicasted to all MNs.  Or so?
>> 
> 
> Its a L3 multicast, but a L2 unicast. So, no other MN see's this RA.

An L3 all-nodes-on-link message that gets sent to only one node on that
link?  Now that is an architectural issue :-)

Alex

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 1 Nov 2006 09:27:27 -0800

> An L3 all-nodes-on-link message that gets sent to only
> one node on that link?  Now that is an architectural issue :-)

It is theoretically possible that a link-scoped multicast
could be sent on a shared links with lots of nodes attached
and only one of them would actually receive it. The protocol
is equipped to deal with such possibilities, so I don't see
an architectural issue?

Fred

PS We looked at Linux kernel and it looks like it would
   accept such a multicast/unicast packet...

---

From: "James Kempf" <[email-masked]>
Date: Wed, 1 Nov 2006 12:42:17 -0800

Alex,

How much of this discussion is specific to PMIP and how much could also be 
used for NETLMM?

            jak

----- Original Message ----- 
From: "Alexandru Petrescu" <[email-masked]>
To: "Sri Gundavelli" <[email-masked]>
Cc: "Templin, Fred L" <[email-masked]>; <[email-masked]>; 
"Soliman, Hesham" <[email-masked]>; "Basavaraj Patil" 
<[email-masked]>
Sent: Wednesday, November 01, 2006 6:34 AM
Subject: [netlmm] Re: Why is PMIP a superior solution for 
NETLMMrequireiments?

>>> Who tells AR the MN MAC address?  Neighbour Discovery - no.  Other l2 
>>> means? Which other?  Which l2.
>>>
>>
>> Hi Alex,
>>
>> The proxy mip signalling is triggered after the AR/PMA detect the mobile 
>> on its link after the access authentication. It will certainly

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 1 Nov 2006 09:08:03 -0800 (PST)

On Wed, 1 Nov 2006, Alexandru Petrescu wrote:

> I think it's because when one wants prefix-per-mobile model one doesn't want 
> RA multicasted to all MNs.  Or so?
>

Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 1 Nov 2006 14:33:21 -0800 (PST)

Hi James,

Sorry. This thread should have been in the MIP6 mailing list.
Did not realize that.

Sri

On Wed, 1 Nov 2006, James Kempf wrote:

> ----- Original Message ----- From: "Alexandru Petrescu" 
> <[email-masked]>

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 1 Nov 2006 22:19:37 -0800 (PST)

Hi Alex,

On Wed, 1 Nov 2006, Alexandru Petrescu wrote:

>>  know the MN's MAC address, as part of the access authentication procedures
>

Sure. But it might be better if we decouple the access authentication
mechanism from the protocol. We can certainly enable address configuration
as part of the access auth protocol, but it is important we preserve the
home link behaviour on the access link from the mobile's point of view.

> is a need to stay independent of link type.

That is the assumed IPv6 host behaviour. I'd expect
the host to send RS, any time, it detects a link change.
I dont see any protocol coupling with the link-type.

> either the one from RS, or multicast all-nodes (we don't want).

Ok.

> to mobile (specifying its MAC address) and without specifying an IP address.

Ok.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 02 Nov 2006 16:19:20 +0100

James Kempf wrote:
> Alex,
> 
> How much of this discussion is specific to PMIP and how much could also 
> be used for NETLMM?

NETLMM MN-AR interface seems to be open to DHCP address allocation, 
while PMIP seems to prefer stateless autoconf.

Alex

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 2 Nov 2006 10:33:59 -0800

Alex,

> NETLMM MN-AR interface seems to be open to DHCP
> address allocation, while PMIP seems to prefer
> stateless autoconf.

Does that mean that PMIP would not support prefix
delegation too?

Fred

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 2 Nov 2006 10:52:38 -0800 (PST)

> Does that mean that PMIP would not support prefix

Couple of points:

1. PMIP does support DHCP based address configuration
in addition to stateless auto configuration. However, I
did point out the provisioning complexity when using
per-mn-address model. There should be a way for the
operator to ensure the configured home address in the
policy store (AAA) is the same that the mobile gets
when using DHCP. Configuring MAC-IP is a not a good
idea, as the node size could be high.

2. Secondly, when using per-mn-prefix model, stateless
auto config just elimates the need for DHCP. Every
mobile has it own prefix and the address configuration
becomes simple. Even if the operator like to use DHCP,
there is no provisioning complexity at the DHCP. Every
MN get an address from its own pool and the AR acting
as a DHCP relay would set the link-addr option. The
idea of hosting the prefix on the AR link, just simplifies
lot of things and it does eliminate the need for
proxy DAD or relay DAD.

3. W.r.t prefix delegation, its a configuration policy
at the home agent. Certainly, it can come from the
MN's profile at the policy store or the home agent
obtaining the prefix dynamically from a DHCP server or
from some other backend address store.

Sri

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 2 Nov 2006 11:18:18 -0800

> Configuring MAC-IP is a not a good

How is it any different for per-mn-prefix? You still
need to store MAC-prefix.

> just simplifies lot of things

You keep saying "simplifies lot of things" and still
the only thing I know about is proxy/relay-DAD for
non-link-locals not needed. If that is the only thing,
then please stop saying "lot of things"; otherwise,
please enumerate what the other things are.

Thanks - Fred

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 02 Nov 2006 20:42:14 +0100

Sri Gundavelli wrote:
>>> NETLMM MN-AR interface seems to be open to DHCP address
>>> allocation, while PMIP seems to prefer stateless autoconf.
>> 
>> Does that mean that PMIP would not support prefix delegation too?
>> 
> 
> Couple of points:
> 
> 1. PMIP does support DHCP based address configuration in addition to
> stateless auto configuration.

Sri, would you agree that for PMIP to work with DHCP it would need a
proxy-DHCP client on the AR?

Alex

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 2 Nov 2006 12:00:15 -0800 (PST)

Hi Alex,

> proxy-DHCP client on the AR?

No. AR (with the proxy mobile agent function) can just be a DHCP relay 
agent.

Mobile can do the DHCP and I dont see the need for that function to be
delegated to AR.

Thanks
Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 2 Nov 2006 12:06:23 -0800 (PST)

> need to store MAC-prefix.

You just configure the pools on the DHCP (p1, p2, p3 ... pn)
AR functioning as a DHCP relay would set the link-addr
option to the mobile's home prefix. DHCP would allocate an
address from that prefix. No other relay agent would set the
link-addr to some other mobile's prefix. The prefix is hosted
at the access link, its a normal link and a normal DHCP
relay on that link.

> please enumerate what the other things are.

Ok. Consider that as verbosity. To me proxy/relay DAD
is not a trivial function. Its quite a bit of work
to implement that. The home agent code will bloat
significantly to get that in place. IMHO.

Regards
Sri

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 2 Nov 2006 13:21:48 -0800

> option to the mobile's home prefix.

DHCP relay doesn't have to set link-address if it
doesn't have anything useful to put there. As long
as the DHCP client includes a Client ID the relay can
just write peer-address and include an Interface-ID
to identify the link on which the client is attached.

This thread has become overly-long, and I'm going to
have to stop responding now.

Fred

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 02 Nov 2006 23:46:21 +0100

Sri Gundavelli wrote:
>>> 1. PMIP does support DHCP based address configuration in addition
>>>  to stateless auto configuration.
>> 
>> Sri, would you agree that for PMIP to work with DHCP it would need
>>  a proxy-DHCP client on the AR?
>> 
> 
> No. AR (with the proxy mobile agent function) can just be a DHCP 
> relay agent.
> 
> Mobile can do the DHCP

Not sure the security context of that is clear - MN acquires the address
but AR does BU on its behalf.

Not sure PMIP clears the implications of using SeND.

You'll say PMIP can work with SeND too, I'm fine :-)

Alex

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 2 Nov 2006 15:14:02 -0800 (PST)

Hi Alex,

> but AR does BU on its behalf.

Proxy model requires one authorized entity to request the
setup of a routing context on behalf of some other entity.
That is the nature of the solution. That's the required
trust model for this solution to work. Mobile is a host
and it does exactly what it would do on its home link
including address obtaining. The AR would emulate the
home link, ensures, the mobile believes its at home and
so it sends the BU. The AR is doing a service.

> You'll say PMIP can work with SeND too, I'm fine :-)

You are prompting me to say that :) .. so I say, I dont see
any special requirements for supporting secure ND on the
access link, atleast when using per-mn-prefix addressing
scheme. Its just an another link with the MN's home prefix.
But, I need to understand that.

Regards
Sri

---

From: Julien Laganier <[email-masked]>
Date: Sat, 4 Nov 2006 17:05:54 +0000

On Thursday 02 November 2006 20:06, Sri Gundavelli 
wrote:
> > You keep saying "simplifies lot of things" and
> > still the only thing I know about is
> > proxy/relay-DAD for non-link-locals not needed. If
> > that is the only thing, then please stop saying
> > "lot of things"; otherwise, please enumerate what
> > the other things are.
>
> Ok. Consider that as verbosity. To me proxy/relay
> DAD is not a trivial function. Its quite a bit of
> work to implement that. The home agent code will
> bloat significantly to get that in place. IMHO.

From my experience proxy/relay DAD is trivial to 
implement.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Sat, 4 Nov 2006 17:05:54 +0000

--julien

---

From: Sri Gundavelli <[email-masked]>
Date: Sat, 4 Nov 2006 10:15:22 -0800 (PST)

On Sat, 4 Nov 2006, Julien Laganier wrote:

>> To me proxy/relay

Hi Julien,

Trivial or complex, my word against your word.
The point is that pmip does not need this function,
in the per-mn-prefix mode of operation. Simplifies
the implementation to certain extent. I was comparing
the implementation complexity between the two addressing
modes. This meets the pmip design goals of leveraging
the MIPv6 infrastructure, signalling and with "minimal"
changes to the Home Agent. I relate this mode to the
NEMO's MNP allocation in the explicit mode, to show
minimal HA's involvment in cases where a prefix follows
the mobile.

Regards
Sri

PS: Moving the thread to the MIP6 ML.

---

From: Julien Laganier <[email-masked]>
Date: Sat, 4 Nov 2006 10:22:25 -0800

Hi Sri,

On Saturday 04 November 2006 10:15, Sri Gundavelli 
> Trivial or complex, my word against your word.

Fair enough.

> in the per-mn-prefix mode of operation. 

The function isn't required to avoid duplicates of 
global addresses (since each MN has a different prefix 
for its global addresses.)

But what about avoidance of link-locals addresses 
duplicates (e.g. with the AR, or with another MN when 
shared links are used.) ? How do you do that if you do 
not relay/proxy DAD across the domain when a collision 
occurs?

> Simplifies the implementation to certain extent. I
> was comparing the implementation complexity between
> the two addressing modes. 

I'd agree about the simplification if the function 
wasn't required, but I think it is (see above)

Best,

--julien

---

From: Sri Gundavelli <[email-masked]>
Date: Sat, 4 Nov 2006 10:48:18 -0800 (PST)

Hi Julien,

Hi Julien,

Even for the link-local address duplicate detection,
in the given shared link scenario, the resolution
happens on that access link and all the visiting
nodes on that link can do the resolution with out
the need for the messages to go beyond the link.
Lets assume host "A" and "B" are using the same
LLA: FE80::2AA:FF:FE22:2222 and both will register
for the corresponding solicited-node multicast
address FF02::1:FF22:2222. The link is not a split
link and LLA uniqueness have to be to contained to
that link. Why do I need across domain resolution
or DAD or Relay-DAD ? The link/prefix is following
the mobile.

Regards
Sri

---

From: Julien Laganier <[email-masked]>
Date: Sat, 4 Nov 2006 16:21:59 -0800

On Saturday 04 November 2006 10:48, Sri Gundavelli 
wrote:
> >>>> DAD is not a trivial function. Its quite a bit
> >>>> of work to implement that. The home agent code
> >>>> will bloat significantly to get that in place.
> >>>> IMHO.
> >>>
> >> The point is that pmip does not need this
> >> function, in the per-mn-prefix mode of operation.
> >
> > global addresses (since each MN has a different
> > prefix for its global addresses.)
>
> Hi Julien,
>

Just to make sure: I did not say that address 
resolution should occur across links, only that DAD 
traffic should be relayed across link *when* a 
collision occurs.

> or DAD or Relay-DAD ?

[again I am not saying that we should have domain-wide 
address resolution] 

Let's take the following example: one host H and two 
access routers AR1 and AR2 on two different links 
(link1 and link2). H is attached to AR1. 

Suppose that H and AR2 happens to configure the same 
link-local address. H will do DAD on link1 and won't 
detect a collision, AR2 will do DAD on link2 and won't 
detect a collision.

Now what happens if H moves to link2: there's a 
collision of link local addresses of H and AR2.

That can be avoided by relaying/proxying DAD messages 
*when* a collision occurs (the anchor point knows 
when.) 

--julien

---

From: Julien Laganier <[email-masked]>
Date: Sat, 4 Nov 2006 16:21:59 -0800

--julien

---

From: Sri Gundavelli <[email-masked]>
Date: Sat, 4 Nov 2006 16:47:09 -0800 (PST)

Hi Julien,

Please see inline ..

> collision of link local addresses of H and AR2.

When H moves to link2, it will do a DAD on that
link and detect the collision. The collision is
very much on that link and will be detected right
after the host H moves to that link and starts
the address configuration.

The collision is on the link, why do these messages
need to go out of the link ? Why do we need Proxy 
or Relay DAD ? Why is this scenario any special ? This
is a normal IPv6 DAD scenario and ND will very much
take care of that. Again, this is not a split link,
we are not bridging traffic between links in this
case.

Regards
Sri

---

From: Julien Laganier <[email-masked]>
Date: Sat, 4 Nov 2006 17:14:17 -0800

Hi Sri,

Please find my answer inlined below:

On Saturday 04 November 2006 16:47, Sri Gundavelli 
wrote:
> >> Even for the link-local address duplicate
> >> detection, in the given shared link scenario, the
> >> resolution happens on that access link and all
> >> the visiting nodes on that link can do the
> >> resolution with out the need for the messages to
> >> go beyond the link.
> >
> > resolution should occur across links, only that
> > DAD traffic should be relayed across link *when* a
> > collision occurs.
> >
> >> LLA: FE80::2AA:FF:FE22:2222 and both will
> >> register for the corresponding solicited-node
> >> multicast address FF02::1:FF22:2222. The link is
> >> not a split link and LLA uniqueness have to be to
> >> contained to that link. Why do I need across
> >> domain resolution or DAD or Relay-DAD ?
> >
> > [again I am not saying that we should have
> > domain-wide address resolution]
> >
> > Let's take the following example: one host H and
> > two access routers AR1 and AR2 on two different
> > links (link1 and link2). H is attached to AR1.
> >
> > Suppose that H and AR2 happens to configure the
> > same link-local address. H will do DAD on link1
> > and won't detect a collision, AR2 will do DAD on
> > link2 and won't detect a collision.
> >
> link and detect the collision. 

I was assuming that the host implements DNAv6. Under 
that scenario, when the host get a Link_up indication, 
it will sollicit a router by sending an RS, and 
receive from the new router a RA with the same prefix, 
thus making it believe that it did not change link (I 
am intentionally omitting the subtleties of DNA link 
change determination, e.g. the use of a landmark 
prefix)

The default behavior for a host would then to not redo 
DAD, and hence not detect the collision. (The host 
might however be forced to redo DAD even though DNA 
determined that the link did not changed if 
DNASameLinkDADFlag is set to True)

> The collision is 

See above -- It won't be detected by a DNA node with 
default configuration.

> or Relay DAD ? Why is this scenario any special ?

This scenario is special because you are hiding the 
change of network prefix from one AR to another, thus 
hiding the link change to DNA, which in effect disable 
DAD upon link change in the same domain.

> This is a normal IPv6 DAD scenario and ND will very
> much take care of that. 

See above.

> Again, this is not a split link, we are not bridging
> traffic between links in this case.

Again, and just to be sure, I never talked about split 
link or IP-layer bridging across different links.

Best,

--julien

---

From: Sri Gundavelli <[email-masked]>
Date: Sat, 4 Nov 2006 17:48:26 -0800 (PST)

Hi Julien,

> DNASameLinkDADFlag is set to True)

PMIP did not make any assumption with respect to the
node's capability of DNAv6, DNAv6 is still a draft.
A native IPv6 host will certainly do a DAD after
detecting a link flap and there is no question of
DAD not getting triggered there. Now, with the new
DNAv6 draft(s), assuming they get standardised and
get into the IPv6 host stack, its a config option
as you have pointed out, that will force the host
to do DAD after link flap and still detecting the
same-link with out having a need for pre-establishing
LLA uniqueness across the domain.

Thanks for the discussion.

Regards
Sri

Ok.

---

From: "James Kempf" <[email-masked]>
Date: Sat, 4 Nov 2006 20:10:48 -0800

Guys,

The PMIP proposal in draft-sgundave-mipv6-proxymipv6-00 gets around the link 
local uniqueness problem by turning off DAD and using DHCP address 
allocation exclusively. The link between the mobile node and the MIPv6 FA 
(aka proxy mobile node) is a virtual point to point link. See Section 7.3. I 
don't know how this problem is handled in the PMIP proposal in 
draft-chowdhury-netmip6-01.txt, I assume by the use of the unique identifier 
assigned by the network using IPCP, whether or not PPP is used, but the 
draft says nothing about whether DAD is used (it won't be if PPP is). I 
don't think these approaches are unique to PMIP, however.

            jak

----- Original Message ----- 
From: "Sri Gundavelli" <[email-masked]>
To: "Julien Laganier" <[email-masked]>
Cc: <[email-masked]>; "Templin, Fred L" <[email-masked]>; 
<[email-masked]>
Sent: Saturday, November 04, 2006 4:47 PM
Subject: Re: [netlmm] Re: Why is PMIP a superior solution 
forNETLMMrequireiments?

> need to go out of the link ? Why do we need Proxy or Relay DAD ? Why is 
> this scenario any special ? This

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 6 Nov 2006 14:33:09 -0800

I'm coming into this late, but I'm not sure about having the
MN re-DAD its link-locals every time its link flaps when the
link flaps could be happening constantly (e.g., when a MN is
on the cusp btw the coverage regions of multiple access
points). Wouldn't that be a concern in terms of stability,
e.g., if the MN is constantly marking its LL's as tentative
and rerunning DAD?

Fred

-----Original Message-----
From: Sri Gundavelli [mailto:[email-masked]] 
Sent: Saturday, November 04, 2006 5:48 PM
To: Julien Laganier
Cc: [email-masked]; [email-masked]; Templin, Fred L
Subject: Re: [netlmm] Re: Why is PMIP a superior solution for
NETLMMrequireiments?

Hi Julien,

Regards
Sri

Ok.

---

From: Julien Laganier <[email-masked]>
Date: Mon, 6 Nov 2006 16:24:28 -0800

Hi Sri,

On Monday 06 November 2006 14:59, Sri Gundavelli wrote:
> Hi Fred,
>
> The point is the default IPv6 host behaviour is
> assumed for PMIP to work. With respect to the host
> having the DNAv6 support, we need to see how that
> impacts the DAD. Also, the point to note is the
> current assumption of PMIP is a p2p MN-AR link and
> the whole issue about LLA uniqueness on the access
> link is when shared link is assumed.

I don't thing the LLA uniqueness issue is limited to 
the shared link case. I think the concern apply even 
when links are point-to-point and the only neighbor to 
a MN is the provider's router.

If a MN happens to move to a link where the router has 
a colliding link-local address, and the MN doesn't 
re-run DAD (as per default DNA behavior) then a 
collision will occur and won't be detected.

That's orthogonal to the link type, be it 
point-to-point or shared, I think.

Best,

--julien

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 6 Nov 2006 14:59:39 -0800 (PST)

Hi Fred,

The point is the default IPv6 host behaviour is assumed
for PMIP to work. With respect to the host having the
DNAv6 support, we need to see how that impacts the DAD.
Also, the point to note is the current assumption of PMIP
is a p2p MN-AR link and the whole issue about LLA
uniqueness on the access link is when shared link is
assumed. In any case, ensuring domain-wide uniqueness
for a LLA comes at it own cost and we want to avoid that.

Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 6 Nov 2006 17:04:07 -0800 (PST)

Hi Julien,

> collision will occur and won't be detected.

When the mobile moves to a new link, the home detection
logic happens after it reseives an RA from the access
router. The RA will be sent using the LLA and if there
is a collision, the mobile will detect it right there
and triggers a DAD procedure.

Regards
Sri

---

From: Julien Laganier <[email-masked]>
Date: Mon, 6 Nov 2006 18:14:15 -0800

Hi Sri,

On Monday 06 November 2006 17:04, Sri Gundavelli wrote:
> > I don't thing the LLA uniqueness issue is limited
> > to the shared link case. I think the concern apply
> > even when links are point-to-point and the only
> > neighbor to a MN is the provider's router.
> >
> > If a MN happens to move to a link where the router
> > has a colliding link-local address, and the MN
> > doesn't re-run DAD (as per default DNA behavior)
> > then a collision will occur and won't be detected.
>
> When the mobile moves to a new link, the home
> detection logic happens after it reseives an RA from
> the access router. The RA will be sent using the LLA
> and if there is a collision, the mobile will detect
> it right there and triggers a DAD procedure.

I haven't seen this behavior (trigger DAD after 
observing a duplicate) specified in RFC 2461, 2462 or 
their revision (bis.)

Best,

--julien

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 7 Nov 2006 11:57:07 -0800 (PST)

Hi Julien,

> observing a duplicate) specified in RFC 2461, 2462 or

If the node will not do the DAD after detecting a RA with
its own LLA, you think it will create a new neighbor cache
entry or the default-router entry with its own LLA ? The
whole expensive DAD procedure is for detecting duplicate,
I'd expect the IPv6 protocol host stack to check the address
before it adds it to its data structures. I will check our
implementation. To me, this appears to be too implicit to
even be mentioned in 2461 or the bis.

Regards
Sri