Hi Vidya, right, the term "virtual point-to-point link" describes very well what a broadcast link becomes as soon as one deploys the prefix-per-MN model.
(Although neighboring MNs can still circumvent the "pseudo-point-to-point" property by communicating via link-local IP addresses...) - Christian -- Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH) www.tm.uka.de/~chvogt/pubkey/ "Everything should be made as simple as possible, but not simpler." (Albert Einstein) Narayanan, Vidya wrote: > While it is true that IPv6 allows multiple subnets per link and has no > requirement about all nodes being aware of all prefixes, it is intended > for routers on a link supporting multiple prefixes. So, the number of > prefixes that you would actually see on a link in practice would be much > more limited than the number of prefixes you are likely to have with the > prefix-per-MN case. > > This does work fine for point-to-point links such as cellular links, but > for the general broadcast media, it is rather strange. It seems to me > that taking broadcast/multicast capability away from a medium that > natively supports the functionality is placing a serious limitation on > such links. I don't know if it specifically breaks something w.r.t IPv6, > but it definitely takes away some powerful functionality. > > Also, if, keeping inline with the charter goals, we still maintain that > the MN does not require any changes, this means that an MN, on WLAN or > ethernet or such media, will assume it is on a shared link and attempt > to do DAD - it will always succeed, but it is just a waste of resources > and time in such a prefix-per-MN model. Also, if stateful address > configuration is used, this means that the MN must do DHCP-PD, which it > normally may not do - so, that will be a change that NETLMM imposes on > an MN. > > If we are going with the prefix-per-MN model, perhaps a good thing to do > will be to scope NETLMM to virtual point-to-point links, since that is > what a broadcast link will be reduced to, in this case. > > Vidya _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
