Subject: 回复:Re: [netlmm] Which Addressing Model to Choose?

From: huangzhigang 50541 <[email-masked]>
Date: Sat, 15 Jul 2006 10:17:13 +0800

> > I think these two addressing models are two kinds of different 
> ways to 
> > realize the requirement defined in PS draft. Of course, prefix-
> per mobile 
> > node model has its own advantage, i.e. it can avoid a lot of 
> trouble such 
> > as DAD, DNA, proxy RA, default router selection and so on. In 
> fact, these
> 
> I don't think prefix per mobile node can avoid all of these. 
> Basically:
> 1) DAD: With the prefix per mobile node model, the MN does DAD but 
> there is 
> no possibility of ever having an address conflict, because the MN 
> is the 
> only one on the link. So there is no need to forward NAs between 
> links.

=>However, this simplify is at the cost of a waste of address resources.

> 2) DNA: If the link layer does not provide bidirectional 
> reachability 
> detection of the AR and movement detection, then these will have 
> to be done 
> at the IP layer. They must be done regardless of which model is 
> used. In 
> fact, DNA must be used on every L2 move (i.e. from one AP to 
> another) for 
> bidirectional reachability detection of the AR and subnet movement 
> detection 
> unless these are provided by the wireless link layer.

=> Yes, you are right, but DNA between LMA and MN or between AR and MN, it depends.

> 3) Proxy RA: Not sure what you meant here.

=> Here, I mean in MN-AR draft ARs will send RA on behalf of LMA, all prefix information and parameters are from LMA.

> 4) Default router selection: Again, unless the wireless link layer 
> supplies 
> this, it will need to be done at the IP layer, even with prefix 
> per mobile 
> node.
> 

=> It occurs to me that using LMA as default router, which caused a lot of discussion in the mail list. I am not sure how the prefix per mobile node model will be used in NetLMM domain, but perhaps it is possible to use LMA as default router.

> Prefix per mobile node doesn't get rid of having to do these 
> operations, it 
> just modifies the possible answers a MN can get to simplify the 
> protocol.

> > questions are resulted from current Netlmm architecture. To some 
> degree, I 
> > think current architecture is a kind of multilink subnets 
> architecture 
> > because the same questions exist in the multilink subnets. Link-
> scoped 
> > multicast and DAD have been brought up in 
> > [draft-thaler-intarea-multilink-subnet-issues-00.txt]. What's 
> more, I have 
> > the same worry as Vijay about whether the SeND and the DNA spec 
> will be 
> > widely implemented and used or not.
> >
> 
> Well, one could say the same of NETLMM at this point. :-) The 
> question 
> should be what is the right technical choice.
> 
> >
> >
> > However, if we can solve these problems perfectly we can insist 
> on our 
> > current choice. IMHO, we should not give up our efforts on the 
> way to 
> > success even if there are some potential problems in the current 
> solution. 
> > And if we mean to adopt prefix-per mobile node model perhaps 
> much more 
> > works have to be done. What's more, I could not see more 
> benefits from 
> > prefix-per mobile node model though it is recommended to 3GPP in 
> RFC3314.>
> 
> OK, sounds like you are in favor of continuing to develop 
> multilink subnets. 
> Perhaps you could give some thought to what benefits multiink 
> subnets would 
> have over the other two models, to justify the effort we will have 
> to make 
> to get it through the IESG.

=>I could not find the difference between multilink subnets and the shared link model in nature, perhaps you can tell me. :-) 
I don't support the prefix per mobile node model because I think its a waste of address resources. Though it is said in RFC3314 that 'IPv6 address space will not be exhausted if /64 prefixes are allocated to primary PDP contexts'.

>            jak

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

---

From: "Mohamed Khalil" <[email-masked]>
Date: Mon, 17 Jul 2006 09:46:06 -0500

=>I could not find the difference between multilink subnets and the
shared link model in nature, perhaps you can tell me. :-) 
I don't support the prefix per mobile node model because I think its a
waste of address resources. 

Address space is not an issue in IP6

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 17 Jul 2006 18:28:24 +0200

> Address space is not an issue in IP6

Well I think address waste is not good for anybody, be it v4 or v6.  We 
should not waste.

What's "prefix per mobile"?  Could two mobiles have their permanent 
addresses derived from the same prefix?

If one thinks that each MN in a netlmm domain has a different /64 prefix 
then waste is immediately visible.  The netlmm admin gets a /48 and thus 
left with 16bits to distribute to mobiles.  I.e. there could be only 
65535 distinct MNs.

Alex

---

From: "James Kempf" <[email-masked]>
Date: Mon, 17 Jul 2006 09:46:26 -0700

> => It occurs to me that using LMA as default router, which caused a lot of 
> discussion in the mail list. I am not sure how the prefix per mobile node 
> model will be used in NetLMM domain, but perhaps it is possible to use LMA 
> as default router.
>

OK. I don't see much advantage to having the MAGs advertise on behalf of the 
LMA if the MAGs are not routers (i.e. if they are bridges). On the other 
hand, if the MAGs are routers and the prefix per mobile node model is in 
use, then the MAGs will advertise as routers. But perhaps I'm missing 
something.

> =>I could not find the difference between multilink subnets and the shared 
> link model in nature, perhaps you can tell me. :-)
> waste of address resources. Though it is said in RFC3314 that 'IPv6 
> address space will not be exhausted if /64 prefixes are allocated to 
> primary PDP contexts'.
>

I'm interested in hearing WG discussion on the different models, and I'd 
really like to see all the issues surfaced and considered. But I don't think 
address space wastage is really an issue in IPv6. That opinion was reflected 
in RFC 3314. People tend to think this way as a holdover from IPv4, where it 
is an issue.

I think there is an issue regarding making all the links look like a shared 
link, involving link local multicast. All link local multicast traffic would 
have to be forwarded between the links if the addressing model is shared 
link. While this could be done, the problem from a cellular standpoint is 
that many of the nodes on the links will be in dormant mode, this is typical 
in cellular links and is one reason why cell phones get far better power 
efficiency than laptops with 802.11 (there are others). These nodes will 
have to wake up and reactive their IP stack just to process link local 
multicast. This provides an opening for much inefficiency in power 
management at best, and a DoS attack vector at worst. There are possible 
solutions, the MAG could have a timer that set a filter for the mobile node 
if traffic wasn't seen over a certain period, to filter out all link local 
multicast but ND. There could be a message from the mobile node to set a 
filter in place, but that would require some modification on the mobile 
node. These measures make the protocol more complex, and one must question 
what purpose link local multicast serves in these kinds of links.

The only other use of link local multicast that I am aware of other than ND 
is Apple's Bonjouir protocol. Bonjouir is used for service discovery, in 
small office and enterprise networks. Neither of these are expected to be 
the kinds of links where NETLMM will be deployed. Is there some other use of 
link local multicast that I am missing? Other than that,in NETLMM networks, 
I don't see much use for link local multicast except for ND, but if we 
support the shared link model, all link local multicast will need to be 
forwarded, so that the addressing model is architecturally consistant.

            jak

---

From: "Roberts Phil-APR042" <[email-masked]>
Date: Mon, 17 Jul 2006 12:57:42 -0400

Not to single out Alex here, but folks, before going down the path of
discussing wastefulness in allocation, please read RFC 3314,
particularly section 2.3.1.

> -----Original Message-----
> From: Petrescu Alexandru-AAP021
> Sent: Monday, July 17, 2006 11:28 AM
> To: Mohamed Khalil
> Cc: Templin, Fred L; [email-masked]
> Subject: Re: [netlmm] Which Addressing Model to Choose?
> 
> Mohamed Khalil wrote:
> >
> >

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 18 Jul 2006 10:18:37 +0200

> particularly section 2.3.1.

Yes, that section makes the case that there are enough /64 prefixes to
accomodate 490 trillion mobiles ("pdp contexts"), when the only reserved
bits are the first 001. I.e. 61 bits for representing mobiles.

However, that section also has a last paragraph referring to APNIC, ARIN
and RIPE for address allocation policy.  It would surprise me that a
netlmm deployer is not subject to these policies, and decide to use
001::/3 prefixes for themselves, as some use today non-routable class A
10.0.0.0.

I wonder how many bits for subnet id would a netlmm deployer plan, if
using prefix-per-mobile (prefix-per-pdp-context).  What prefix would
netlmm request from APNIC/ARIN/RIPE?  A /3?  A /32?  A /48?

If a netlmm deployer wishes to avoid requesting a prefix, then it is
limited to use of 6to4, which is hard limited to /48.

Alex

> 
> 
> 
>> -----Original Message----- From: Petrescu Alexandru-AAP021 Sent: 
>> Monday, July 17, 2006 11:28 AM To: Mohamed Khalil Cc: Templin, Fred
>>  L; [email-masked] Subject: Re: [netlmm] Which Addressing Model to
>>  Choose?
>> 
>> Mohamed Khalil wrote:
>>> 
>>> =>I could not find the difference between multilink subnets and 
>>> the shared link model in nature, perhaps you can tell me. :-) I 
>>> don't support the prefix per mobile node model because I think 
>>> its
> a
>> Well I think address waste is not good for anybody, be it v4 or v6.
>> 
>> 
>> 
> We
>> should not waste.
>> 
>> then waste is immediately visible.  The netlmm admin gets a /48 and
>> 
>> 
>> 
> thus
>> left with 16bits to distribute to mobiles.  I.e. there could be 
>> only 65535 distinct MNs.
>> 
>> Alex
>> 
>> 
>> _______________________________________________ netlmm mailing list
>>  [email-masked] https://www1.ietf.org/mailman/listinfo/netlmm
>