> -----Original Message----- > From: marcelo bagnulo braun [mailto:[EMAIL PROTECTED] > > > El 08/08/2006, a las 9:51, Narayanan, Vidya escribió: > > > > > 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). > > > > so, the router will not send unsolicited RADV but will only > answer to router solicitations is that it? >
There will have to be no multicast RAs. Some networks detect the mobile at L2 and send a unicast RA when the link local address is available (via L2 means). In others, yes, there will be no unsolicited RAs. > wouldn't this pose some problems with movement detection for > instance? > i mean there will no periodic RADV to detect the we are on a > different link... but i guess you are assuming some for > netlmm... but this is off topic for the int ml i guess > Yes - due to this restriction, all nodes attaching to links within the NETLMM domain will have to follow NETLMM defined behavior - I don't see how there can be a mix of nodes on the network, some that obtain NETLMM services and some that don't. Those are actually the reasons applicability of this model to all sorts of environments becomes weird. It fits the cellular world, where the attached hosts are all paid subscribers that may uniformly get NETLMM services. In the enterprise world, where true shared prefixes are used, for instance, one may want to provide NETLMM services just to the enterprise hosts and not for guest devices or such. This model will not really allow for such mixed deployments. Regards, Vidya > regards, marcelo > > > > >>> 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
