Subject: RE: [netlmm] Which Addressing Model to Choose?

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 20 Jul 2006 10:46:29 -0700

Thanks for clarifications, James. In terms of the DAD collisions
with SEND, it seems that that would be covered under the SEND/CGA
references so it might be OK for us to just remain silent in the
MN-AR interface document.

Fred
[email-masked] 

-----Original Message-----
From: James Kempf [mailto:[email-masked]] 
Sent: Thursday, July 20, 2006 10:40 AM
To: Templin, Fred L; Julien Laganier
Cc: [email-masked]; Alexandru Petrescu
Subject: Re: [netlmm] Which Addressing Model to Choose?

Fred,

The MAG could assign link-locals in two ways: 1) RA that
advertises a /128 to the MN containing a link-local address,

jak>> This would require the mobile node to solicit the RA initially
with 
its IP address sent to undefined (i.e. ::). On a standard multicast
capable 
link, I think RFC 2461 says that the router replies to All_Nodes
multicast. 
I assume that the MN AR interface draft would need to specify that,
instead, 
the router unicasts the RA to the MN's link layer address, if the MAG is
to 
respond as a router. Otherwise, every node on the link would get the
/128.

jak>> As far as SEND is concerned, the RA would need to be signed by the

MAG. If the mobile node doesn't have the MAG's certificate, it would
need to 
do CPS/CPA, but, at that point, it still doesn't have a link local
address 
because it has not verified the /128. So I think it would simply have to

provisionally use the /128. The security considerations of this need 
thought. SEND does say that the certs provided in the CPAs are used 
provisionally without CRL checks until the host has a certified default 
router (because it won't get any traffic back from a CRL check before), 
perhaps this could be considered a similar case.

jak>> Finally, I'm not sure what happens when a host gets a /128. It's 
allowed by the formatting rules of RFC 2461 Prefix Option, but what do
real 
implementatoins do? Will the host take that as a hint that it should use
the 
/128 as its link local address? Or will it ignore the address?

or 2) DHCP request that assigns a link-local address. So, it
can certainly be done and it would allow DAD avoidance if it
were done.

jak>> Yes, DHCP will work.

About the SEND/CGA autoconfiguration currently in the spec,
I am wondering what can be done if the MN configures its own
CGA link-local address and DAD reports that it is a duplicate.
Can the MN configure a new CGA and try again, or must it
disable its interface and go dormant? (We should probably
say something about this in the spec.)

jak>> SEND allows three DAD clashes before the host assumes that it is
under 
attack and stops.

            jak 

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

---

From: Andy Huang <[email-masked]>
Date: Fri, 21 Jul 2006 11:22:58 +0800

hi, Fred:

I don't support MAG can assign LLA to MN through advertising /128 'prefix' 
in RA.
There are some reasons:
1. The LLA can be generated without the aid of the on-link router. It is an 
advantage.
2. As James pointed out, without the LLA, solicited RA must be a multicast 
RA and every on-link MN will receive the RA.
3. RFC2462 says that ' If the sum of the prefix length and interface 
identifier length does not equal 128 bits, the Prefix Information option 
MUST be ignored'. So unless MN's interface identifier length is 0, the 
Prefix Information option will be discard.

----- Original Message ----- 
From: "James Kempf" <[email-masked]>
To: "Templin, Fred L" <[email-masked]>; "Julien Laganier" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Friday, July 21, 2006 1:40 AM
Subject: Re: [netlmm] Which Addressing Model to Choose?

> jak>> This would require the mobile node to solicit the RA initially with 
> capable link, I think RFC 2461 says that the router replies to All_Nodes 
> multicast. I assume that the MN AR interface draft would need to specify 
> that, instead, the router unicasts the RA to the MN's link layer address, 
> if the MAG is to respond as a router. Otherwise, every node on the link 
> would get the /128.
>
> MAG. If the mobile node doesn't have the MAG's certificate, it would need 
> to do CPS/CPA, but, at that point, it still doesn't have a link local 
> address because it has not verified the /128. So I think it would simply 
> have to provisionally use the /128. The security considerations of this 
> need thought. SEND does say that the certs provided in the CPAs are used 
> real implementatoins do? Will the host take that as a hint that it should 
> use the /128 as its link local address? Or will it ignore the address?
>
> under attack and stops.

---

From: "Mohamed Khalil" <[email-masked]>
Date: Fri, 21 Jul 2006 09:59:05 -0500

Hi James,

-
or 2) DHCP request that assigns a link-local address. So, it can
certainly be done and it would allow DAD avoidance if it were done.

MK>> I wounder how DHCP will be used to allocate a local IP address
while the messages needs an local IP address. Here is the information I
got from 3315.

  The client  MUST use a link-local address assigned to the interface
for which it
   is requesting configuration information as the source address in the
   header of the IP datagram.

MK>> If the client have a local IP address why he should allocate an IP
address thorugh DHCP?? missing something??

About the SEND/CGA autoconfiguration currently in the spec,
I am wondering what can be done if the MN configures its own CGA
link-local address and DAD reports that it is a duplicate. Can the MN
configure a new CGA and try again, or must it disable its interface and
go dormant? (We should probably say something about this in the spec.)

jak>> under
attack and stops.

            jak

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 21 Jul 2006 08:23:16 -0700

Andy,

Thanks, and this is basically the same as James pointed out.
About  LLA being self-generated by the MN, that is fine but
then the LLA needs to be tested for uniqueness in the NETLMM
domain, i.e., using proxy-DAD. In part, this discussion has
been exploring whether proxy-DAD could be avoided and it is
beginning to look like the answer is "no".

Fred

-----Original Message-----
From: Andy Huang [mailto:[email-masked]] 
Sent: Thursday, July 20, 2006 8:23 PM
To: James Kempf; Templin, Fred L; Julien Laganier
Cc: [email-masked]
Subject: Re: [netlmm] Which Addressing Model to Choose?

hi, Fred:

I don't support MAG can assign LLA to MN through advertising /128
'prefix' 
in RA.
There are some reasons:
1. The LLA can be generated without the aid of the on-link router. It is
an 
advantage.
2. As James pointed out, without the LLA, solicited RA must be a
multicast 
RA and every on-link MN will receive the RA.
3. RFC2462 says that ' If the sum of the prefix length and interface 
identifier length does not equal 128 bits, the Prefix Information option

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

with 
> MAG. If the mobile node doesn't have the MAG's certificate, it would
need

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 21 Jul 2006 09:11:40 -0700

Mohamed,

I'll speak because I may have been the one who put forth the

>    header of the IP datagram.

Right; thanks for pointing that out.

> address thorugh DHCP?? missing something??

The idea is that, if a MN has a probably-unique link-local address
(e.g., one derived from an interface hardware address, one derived
from CGA/SEND, etc.) it could skip DAD and try to "register" the
link-local address with the DHCP server by sending a DHCP_SOLICIT
(using 4-message exchange) that includes the proposed link-local
address in an IA Address option associated with an IA_NA option.
Then, the DHCP server would respond with a DHCP_OFFER that contains
a status code indicating whether the MN's proposed link-local
address is acceptable.

If the MN's proposed (un-DADed) link-local was in fact a duplicate,
the DHCP_OFFER would be harmlessly directed to the true owner of
the link-local address which would discard it due to unrecognized
DUID and/or Transaction ID, and the MN would assume duplicate
after a timeout period.

Fred

---

From: Julien Laganier <[email-masked]>
Date: Mon, 24 Jul 2006 09:19:46 +0200

> beginning to look like the answer is "no".

It now seems to me that it's not possible to avoid proxy DAD. An 
offline discussion with Kent brought to me an additional issue that 
would require proxy DAD. The issue deals with how to avoid collision 
of link-local addresses of MN with MAGs.

RFC2462 DAD would avoid the MN to collide with its MAG when it first 
attaches to the domain. But when the MN handover to a different 
MAG, we do have a problem because there is the possibility that a 
collision happens between the link-local addresses of the MN and the 
new MAG. RFC2462 DAD would not help with this because as per the 
current DNA specification the MN would not redo DAD.

To me this seems like one more requirement to do proxy DAD in the 
NetLMM domain (to insure that none of the MN has a link-local address 
colliding with any MN or MAG in the whole domain.)

--julien

> 3. RFC2462 says that ' If the sum of the prefix length and
> interface identifier length does not equal 128 bits, the Prefix
> Information option
>
> MUST be ignored'. So unless MN's interface identifier length is 0,
> the Prefix Information option will be discard.
>
>
> To: "Templin, Fred L" <[email-masked]>; "Julien
> Laganier" <[email-masked]>
> Cc: <[email-masked]>
> > its IP address sent to undefined (i.e. ::). On a standard
> > multicast capable link, I think RFC 2461 says that the router
> > replies to
>
> All_Nodes
>
> > multicast. I assume that the MN AR interface draft would need to
>
> specify
>
> > that, instead, the router unicasts the RA to the MN's link layer
>
> address,
>
> > if the MAG is to respond as a router. Otherwise, every node on
> > the
>
> link
>
> > would get the /128.
> >
> > jak>> As far as SEND is concerned, the RA would need to be signed
> > by
>
> the
>
> > to do CPS/CPA, but, at that point, it still doesn't have a link
> > local address because it has not verified the /128. So I think it
> > would
>
> simply
>
> > have to provisionally use the /128. The security considerations
> > of
>
> this
>
> > need thought. SEND does say that the certs provided in the CPAs
> > are
>
> used
>
> > provisionally without CRL checks until the host has a certified
>
> default
>
> > router (because it won't get any traffic back from a CRL check
>
> before),
>
> > real implementatoins do? Will the host take that as a hint that
> > it
>
> should
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 24 Jul 2006 11:30:10 +0200

Julien Laganier wrote:
>> Thanks, and this is basically the same as James pointed out. About
>>  LLA being self-generated by the MN, that is fine but then the LLA
>>  needs to be tested for uniqueness in the NETLMM domain, i.e.,
>> using proxy-DAD. In part, this discussion has been exploring
>> whether proxy-DAD could be avoided and it is beginning to look like
>> the answer is "no".
> 
>  attaches to the domain. But when the MN handover to a different MAG,
>  we do have a problem because there is the possibility that a 

Not sure what DNA spec you consider?  draft-ietf-dna-protocol-01.txt?
In this draft there is a flag saying whether MN re-does or not DAD upon
link change.

>  colliding with any MN or MAG in the whole domain.)

I've tried to keep up understanding the discussion as it unfolded.  I
may have missed something though.

It is not clear to me why _proxy_ DAD is needed.  I understand that DAD
is needed for link-local addresses, but why _proxy_, and why in the
_entire_ netlmm domain?

And why emphasizing the collision risk with MAG?  The risk concerns
all nodes on the link, presumably other mobiles, no?

When the MN attaches to a different link it would do DAD on that link
for its link-local address, and only if it needs to use that link-local
address.  The link-local address is presumably used prior to acquiring a
global address, or for other neighbouring communications.

BTW, if MN uses DHCPv6 to aquire a global address, spec says that it 
SHOULD do DAD on it too.

BTW, FMIPv6 has a means to proxy the DAD prior to attach to nAR (MAG role).

Thanks, and sorry if I missed something.

Alex

---

From: Julien Laganier <[email-masked]>
Date: Mon, 24 Jul 2006 13:01:37 +0200

Hi Alex,

Thanks for your message. More thoughts inlined below...

On Monday 24 July 2006 11:30, Alexandru Petrescu wrote:
> > offline discussion with Kent brought to me an additional issue
> > that would require proxy DAD. The issue deals with how to avoid
> > collision of link-local addresses of MN with MAGs.
> >
> > RFC2462 DAD would avoid the MN to collide with its MAG when it
> > first attaches to the domain. But when the MN handover to a
> > different MAG, we do have a problem because there is the
> > possibility that a collision happens between the link-local
> > addresses of the MN and the new MAG. RFC2462 DAD would not help
> > with this because as per the current DNA specification the MN
> > would not redo DAD.
>
> Not sure what DNA spec you consider? 
> draft-ietf-dna-protocol-01.txt? In this draft there is a flag
> saying whether MN re-does or not DAD upon link change.

Ok, I wasn't up-to-date with DNA.

So probably we should just specify how to set the DNA configuration 
parameter affecting DAD usage after *no link change detected* (as per 
DNA terminology. That is, the DNASameLinkDADFlag conceptual flag 
SHOULD be set to True on NetLMM MN.

> > NetLMM domain (to insure that none of the MN has a link-local
> > address colliding with any MN or MAG in the whole domain.)
>
> I've tried to keep up understanding the discussion as it unfolded. 
> I may have missed something though.
>
> It is not clear to me why _proxy_ DAD is needed.  I understand that
> DAD is needed for link-local addresses, but why _proxy_, and why in
> the _entire_ netlmm domain?

If you do not proxy DAD it is possible that two nodes configures the 
same link-local addresses while attached to different links (DAD 
works only on a given links.) If later on they move to the *same* 
link, and does not redo DAD then there's a collision of link-locals 
in the same link. 

Note that I didn't say that the DAD NS has to be propagated to the 
entire domain. Rather, I said that the DAD NS has to be propagated 
where the duplicate address occurs (the LMA knows where.)

However, now that you pointed out the existence of the 
DNASameLinkDADFlag, it seems that proxy DAD would not be required; 
more below.

> all nodes on the link, presumably other mobiles, no?

Yes the risk is not specific to collision with MAGs. This message only 
was considering the issue of MN and MAG addresses collision.

> When the MN attaches to a different link it would do DAD on that
> link for its link-local address, and only if it needs to use that
> link-local address.  The link-local address is presumably used
> prior to acquiring a global address, or for other neighbouring
> communications.

Yes, as you are pointing out it seems that we should be covered 
against link-local collision if the DNASameLinkDADFlag is set to 
True. 

> BTW, if MN uses DHCPv6 to aquire a global address, spec says that
> it SHOULD do DAD on it too.
>

Well it seems that in that case, I was the one who missed something :) 
Thanks for advertizing the DNASameLinkDADFlag, this is certainly an 
important factor w.r.t. the matter we've been discussing here.

--julien

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 24 Jul 2006 10:42:21 -0700

Alex and Julien,

Just for further clarification on what has been said here,
it might help to couch things in terms of the actual text
from ('draft-ietf-dna-protocol-01', Section 5.2.6.2):

   "When the host receives unicast or multicast RAs from the router, if
   the host determines from the received RAs that it has moved to a new
   link, the host MUST immediately move all unicast global addresses to
   the "Deprecated" state and configure new addresses using the subnet
   prefixes obtained from the RA.  For all unicast link local addresses,
   the host MUST initiate NS signaling for optimistic Duplicate Address
   Detection to confirm the uniqueness of the unicast link local
   addresses on the new link."

>From this, I am wondering if there might be a slight disparity
between DNA and NETLMM in terms of how "link" is defined. In
terms of DNA, it seems that "new link" means "different prefixes
advertised in RAs", and that case is already well covered by
('draft-ietf-netlmm-mn-ar-if-01', Section 2.2). But, in NETLMM,
it seems that we have been considering "new link" to be a new
network point of attachment from which RAs are heard from a
different AR (MAG) *whether or not the RAs advertise different
prefixes*. Please correct me if I'm wrong.    

   "If the host determines from the received RAs that it has not moved
to
   a new link (i.e. the link has not changed) and the previous state of
   an address was "Optimistic", then the host MUST send an NS to confirm
   that the address is unique on the link.  This is required because
   optimistic Duplicate Address Detection may not have completed on the
   previous point of attachment, so the host may not have confirmed
   address uniqueness.  If the previous state of an address was
   "Preferred", whether or not the host initiates optimistic Duplicate
   Address Detection depends on the configurable DNASameLinkDADFlag
   flag.  A host MUST forgo sending an NS to confirm uniqueness if the
   value of the DNASameLinkDAD flag is False.  If, however, the
   DNASameLinkDAD flag is True, the host MUST perform optimistic
   duplicate address detection on its unicast link local and unicast
   global addresses to determine address uniqueness."

As with the above comment, it seems that in the way we have been
considering NETLMM up to now we would rewrite this first sentence
as: "If the host determines from the received RAs that it has not
moved to a new *NETLMM domain* (i.e. the *NETLMM domain* has not
changed) and the previous state of an address was "Optimistic",
then the host MUST send an NS to confirm that the address is unique
on the *NETLMM domain*.". Again, please correct me if I'm wrong.

Depending on how we define "link", if we were to omit proxy-DAD
and do DAD every time a MN changes its AR (MAG) point of attachment
within a NETLMM domain, I see the following points to consider:

  1) it could amount to alot of (potentially unnecessary) NS(DAD)
     messaging.
  2) if proxy-DAD were omitted, it doesn't address the case of
     a duplicate link-local address occuring within the NETLMM
     domain when the MN first powers up and/or enters the domain,
     i.e., according to ('draft-ietf-netlmm-mn-ar-if-01',
     Sections 2.1, 2.2 and 2.5.1).
  3) it puts the burden on the *moving* MN to discard its
     addresses and redo DAD whether/not the moving MN was the
     first to configure the addresses within the NETLMM domain,
     i.e., it would allow a latecomer to "steal" addresses from
     the rightful owner (where "rightful" is based on FCFS).

So, if we consider "link" to be a MN's affiliation with an
AR (MAG) within the NETLMM domain (i.e., the way it seems we
have been considering it up to now) then proxy-DAD would still
be useful to minimize NS(DAD) messaging and to assure fairness
for FCFS delegation of addresses. If instead we consider "link"
to be a MN's NETLMM domain point of attachment, then we have
a point of inconsistency because this would imply that packets
destined to a link-local address should be bridged across the
entire NETLMM domain and as we have discussed in the past we
really don't want that due to factors such as scalability, etc.

Fred

-----Original Message-----
From: Julien Laganier [mailto:[email-masked]] 
Sent: Monday, July 24, 2006 4:02 AM
To: Alexandru Petrescu
Cc: Templin, Fred L; [email-masked]
Subject: Re: [netlmm] Need for proxy DAD [Was: Which Addressing Model to
Choose?]

Hi Alex,

--julien

---

From: "James Kempf" <[email-masked]>
Date: Mon, 24 Jul 2006 11:02:11 -0700

Julien,
 
There is no need for full proxy DAD if the MAG is a bridge (i.e. routes the same prefixes on the wireless and wired side) and the LMA is the last hop router. The MN's multicast NS for the DAD gets forwarded by the MAG to the LMA, the LMA checks whether there is a conflict, and sends the NS to the link where the conflict occurs. The MN on that link replies to the MAG which forwards the NA back to the MN. The MAG isn't acting as a full proxy, just enough to determine if there is a conflict.
 
But this makes it look like there are other nodes on the link, rather than the single node per link model. So I think if we want to go for that model, we need to figure out some way that the MN never gets a NA in response to DAD, as with IPCPv6 in PPP.

            jak

________________________________

From: Julien Laganier [mailto:[email-masked]]
Sent: Mon 7/24/2006 12:19 AM
To: Templin, Fred L
Cc: Andy Huang; James Kempf; [email-masked]
Subject: Need for proxy DAD [Was: Which Addressing Model to Choose?]

--julien

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 24 Jul 2006 11:13:47 -0700

Jmaes,

> There is no need for full proxy DAD if the MAG is a bridge (i.e.
> routes the same prefixes on the wireless and wired side) and the
> LMA is the last hop router. The MN's multicast NS for the DAD gets
> forwarded by the MAG to the LMA, the LMA checks whether there is a
> conflict, and sends the NS to the link where the conflict occurs.
> The MN on that link replies to the MAG which forwards the NA back
> to the MN. The MAG isn't acting as a full proxy, just enough to
> determine if there is a conflict.

I think this is exactly what we've been talking about when we
say "proxy DAD", and it is also exactly what currently occurs
in ('draft-ietf-netlmm-mn-ar-if-01', Section 2.5.1).
 
> But this makes it look like there are other nodes on the link,
> rather than the single node per link model. So I think if we want
> to go for that model, we need to figure out some way that the MN
> never gets a NA in response to DAD, as with IPCPv6 in PPP.

This goes to whether the link-local address is intended as a
unique identifier for the MN. If it is, then there is a problem
for two MNs affiliated with the same AR (MAG) to have the same
link-local address even if the two nodes are not considered to
be on the same link wrt each other. If the link-local address
is *not* intended to be a unique identifier for the MN, then
it is really just a string of bits to stuff inside src, dst
addresses that really have no significance anyway and there
is no need for DAD of link-locals at all.

Fred

            jak

--julien

---

From: "James Kempf" <[email-masked]>
Date: Mon, 24 Jul 2006 11:37:33 -0700

Fred,

DNA defines a new link when a prefix is seen that was not seen before. So, 
yes, there is a difference. They use the term "IP link" for this purpose 
(which is what I originally proposed we use too).

            jak

----- Original Message ----- 
From: "Templin, Fred L" <[email-masked]>
To: "Julien Laganier" <[email-masked]>; "Alexandru Petrescu" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Monday, July 24, 2006 10:42 AM
Subject: RE: [netlmm] Need for proxy DAD [Was: Which Addressing Model 
toChoose?]

Alex and Julien,

Fred

-----Original Message-----
From: Julien Laganier [mailto:[email-masked]]
Sent: Monday, July 24, 2006 4:02 AM
To: Alexandru Petrescu
Cc: Templin, Fred L; [email-masked]
Subject: Re: [netlmm] Need for proxy DAD [Was: Which Addressing Model to
Choose?]

Hi Alex,

--julien

---

From: "James Kempf" <[email-masked]>
Date: Mon, 24 Jul 2006 11:41:23 -0700

jak>> I think link locals are exactly that in P-P links. If there is only 
one node on the link, there is no need for an end node identifier, because 
any traffic going onto the link only goes to that node.

            jak

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 24 Jul 2006 14:20:02 -0700

Hi James,

I'll lay off on the other stuff for now to give folks in
different timezones a chance to respond. About "IP link":

> They use the term "IP link" for this purpose 

I was only able to find two uses of the term "IP link" in the
DNA docs - both were in ('draft-ietf-dna-protocol-01', Section
5.2.5.2), and neither instance gave a definition for the term.
Did I miss something?

If not, it makes me wonder whether we should suggest the DNA
people to either define the term or drop it; my opinion (see
earlier discussion) is that it should be dropped, but that
is just my 2cents.

Fred

---

From: "James Kempf" <[email-masked]>
Date: Mon, 24 Jul 2006 14:28:47 -0700

jak>> The term was used extensively during the DT discussions on DNA. I am 
suprised that it was not formally defined. The DT wanted to distinguish 
between the idea of a subnet and a link as a broadcast domain on which 
multiple subnets were defined (a multisubnet link). A subnet and a link are 
the same in IPv4, because each link can have only a single subnet on it but 
not in IPv6.

jak>> For NETLMM, we really don't need the term and we could easily drop it.

jak>> Yes. DNA has a big job ahead of it consolidating its documents. This 
is an issue that also needs attention.

---

From: Julien Laganier <[email-masked]>
Date: Tue, 25 Jul 2006 11:27:38 +0200

Hi Fred,

On Monday 24 July 2006 19:42, Templin, Fred L wrote:

[...]

>   1) it could amount to alot of (potentially unnecessary) NS(DAD)

Agree.

>      Sections 2.1, 2.2 and 2.5.1).

Agree. But we'd also agreed earlier that domain-wide link-local 
uniqueness has no value (unless the link-local is used as a MN 
identifier, which it isn't.)
 
>      the rightful owner (where "rightful" is based on FCFS).

Agree. However you are considering "rightful" based on FCFS on a 
domain-wide basis. 

If you limit the FCFS principle of link-local addresses to the link 
scope (which is think makes sense), then rightful means that the 
first owner of a link-local *on a given link* is the rightful owner 
of it.

In other words, imagine two MNs A and B configuring colliding 
link-locals, where A attaches to the NetLMM domain before B, and both 
being on different links. Then later on A and B attaches to a same 
link at time t_A and T_B, respectively, with t_A > t_B. Then I would 
say that the "right owner" of the colliding link-local address *on 
that link* is B cuz it attached to the link before (one could say 
that the link-local belongs to the link.)

> really don't want that due to factors such as scalability, etc.

As I said above I am not sure about the strength of the fairness point 
above. I however do agree that the desire to limit "useless" DAD 
signalling is valid (especially since NetLMM has claimed to limit 
on-the-air signalling.)

But at the end we'll have to use a prefix model (with or without relay 
DAD) that is acceptable to the IETF community. For that matter I 
think the 16ng DT working on addressing model will provide us with 
good guidance on the right technical solution (Notably, Dave Thaler 
is part of it.) 

Best,

--julien

---

From: Julien Laganier <[email-masked]>
Date: Tue, 25 Jul 2006 13:03:24 +0200

James,

What's described in the mn-ar-if-01 I-D is actually quite similar to 
the setup you described in your message:

On one hand the MAG and LMA acts as regular routers that decrement 
TTL/Hop Count while forwarding packets *but* they forward signed DAD 
NS's and NA's without TTL/Hop Count decrement. 

One could therefore says that both MAG and LMA "bridge" NS's and NA's 
for DAD. In the mn-ar-if case it would however be a bit misleading to 
say that the "MAG is a bridge" since the LMA "is a bridge" too, 
albeit selective (limited to DAD.) 

I also think that my use of the "proxy" qualifier for DAD was even 
more confusing. A more appropriate term would be "relay DAD" as 
employed within the 16ng WG.

Now I shall ask you if you think that we're talking about the same 
"relay DAD" ?

--julien

On Monday 24 July 2006 20:02, James Kempf wrote:
> would require proxy DAD. The issue deals with how to avoid
> with this because as per the current DNA specification the MN would
> not redo DAD.
>

---

From: "James Kempf" <[email-masked]>
Date: Tue, 25 Jul 2006 09:48:03 -0700

As I mentioned in the original email on this thread, the MAG must be either 
a router or a bridge for the prefixes that are routed on the wireless link. 
It can't be a router for one type of traffic and a bridge for others.

            jak

----- Original Message ----- 
From: "Julien Laganier" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Templin, Fred L" <[email-masked]>; "Andy Huang" 
<[email-masked]>; <[email-masked]>
Sent: Tuesday, July 25, 2006 4:03 AM
Subject: Re: Need for proxy DAD [Was: Which Addressing Model to Choose?]

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 25 Jul 2006 11:47:54 -0700

Hi Julien,

I guess its time to start processing the daily dose of NETLMM

> identifier, which it isn't.)

I didn't realize we had reached any agreement, but this gets
to the main point I've been trying to examine. If indeed the
link-local address is *not* to be used as a MN identifier
beyond the scope of the local link, then there would really
be no need for any NETLMM domain-wide DAD of link-locals,
and also no need to register link-locals with the LMA.
But, there would still need to be a NETLMM domain-wide
DAD capability for the non-link-locals. 

> that the link-local belongs to the link.)

I can buy this and I think it applies equally well to pt-2-pt and
shared links. But, I believe it only applies to link-locals. This
would tell me that link-locals should only be DAD tested within
the scope of the local link and not registered with the LMA at
all in either the pt-2-pt or shared link case.

Non-link-locals on the other hand would have to be registered
with the LMA and the FCFS for those should apply on a NETLMM
domain-wide scope. Then, DAD for non-link-locals would still
need to be performed on a NETLMM domain-wide basis.

(cut)

> signalling is valid (especially since NetLMM has claimed to limit 

I'll agree with you that fairness for link-locals is on a FCFS-
per-link basis if you'll agree with me that fairness for non-
link-local is on a FCFS-per-NETLMM-domain basis.

> good guidance on the right technical solution (Notably, Dave Thaler 

I agree with prefix-per-MN if that is the question. I think
the prefix could be fined-grained (e.g., /64) or coarse-grained
(e.g., /48), but I think it could also be fully-qualified
(i.e., /128) as long as the NETLMM domain is not represented
as a multilink subnet.

Thanks - Fred

Best,

--julien