> -----Original Message----- > From: marcelo bagnulo braun [mailto:[EMAIL PROTECTED] > Sent: Monday, August 07, 2006 11:08 PM > To: Narayanan, Vidya > Cc: Alexandru Petrescu; INT Area; James Kempf > Subject: Re: [Int-area] IPv6 addressing model, per-MN subnet > prefix,and broadcast domain > > > El 08/08/2006, a las 0:34, Narayanan, Vidya escribió: > > > > >> -----Original Message----- > >> From: Alexandru Petrescu [mailto:[EMAIL PROTECTED] > >> > >> marcelo bagnulo braun wrote: > >> [snip picture and text] > >>> How do the nodes configure their global addresses? I mean > are they > >>> using stateless autconf? > >> > >> Not sure about what's becoming mandatory and what not. > >> There's a draft on MN-AR interface talking about _both_ > stateless and > >> stateful, haven't checked recently though. > >> > >>> If they do, how do you prevent the nodes from configuring > >> one address > >>> per prefix the get in the RADV? > >> > >> By putting M bit to 1 in RA thus instructing MN not to derive an > >> address from the prefix in RA ('M' stands for managed, > instructing to > >> use DHCP instead). > >> > >>> wouldn't some of the nodes end up with multiple addresses from > >>> different prefixes? > >> > >> Yes, provided stateless autoconf is used. > > > > > > No. The goal here is strangely different, actually. The > goal is not to > > advertise all the prefixes in all the RAs - the RA itself will be > > tailored per mobile - so, each mobile will only see the > prefix that is > > being "assigned" to it. > > > > but how do you achieve that? isn't all a single broadcast > link (with multiple subnets? if this is the case all the > nodes see all the RADV, hence all the nodes configure > addresses from all prefixes, right? >
I believe those will be unicast RAs sent to the link local address - there will be a huge mess without that, as you observe (I believe there is a mess in the addressing model even with that, but it will be worse with broadcast RAs). > > The other strange thing here is that the mobile may not > know that it > > is being "assigned" anything - so, it may continue to use stateless > > autoconfig, assuming it is a shared prefix. > > i am lost now.... are you using something different than > stateless autocnf and than dhcp? a new address conf protocol > for specific for netlmm? > I'm waiting to see some proposed text myself to see how this whole thing is going to work on shared media :) Based on the emails I've seen, I think the proposal is the following (people who are actually proposing this may correct anything I say incorrectly here): When a mobile shows up, the AR obtains a prefix for the mobile from the LMA using the NETLMM protocol. That prefix is sent in a unicast RA to the mobile by the AR. The MN doesn't really know it is a unique prefix - it performs SLAAC and comes up with an address and performs DAD. At the moment, I'm very skeptical about slapping a point-to-point model on shared media - I'll wait for some text to see if I can convince myself :) Regards, Vidya > regards, marcelo > > > > > > The other point here that may be considered weird is that > although the > > prefix is being "assigned" so to say, there is no lifetime for it > > (unlike DHCP-PD, for e.g.) - so, I'm not sure if these prefixes are > > pretty much permanently assigned or if, based on the NETLMM > location > > registration information, these are somehow removed. > > > > Vidya > > > > > >> > >>> breaking the goal of having one node per prefix? > >> > >> Not sure about the goal of having one node per prefix, where is it > >> from? > >> I know about a netlmm goal needing MN not to change its address > >> (maybe called CoA, not sure), not sure whether this is in the reqs > >> draft either. > >> > >> Alex > >> > >> > >> _______________________________________________ > >> Int-area mailing list > >> [email protected] > >> https://www1.ietf.org/mailman/listinfo/int-area > >> > > > > _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
