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 > -----Original Message----- > From: Christian Vogt [mailto:[EMAIL PROTECTED] > Sent: Monday, August 07, 2006 11:01 AM > To: Christian Vogt > Cc: INT Area; Dave Thaler; NetLMM WG > Subject: Follow-up: Re: [netlmm] IPv6 addressing model, > per-MN subnet prefix, and broadcast domain > > To clarify the point I want to make: > > - Certainly, there is currently no mechanism that allows you > to limit a node on a broadcast link to a subset of all > on-link prefixes (even though loss of RAs may temporarily > prevent the node from seeing all on-link prefixes). > > - The prefix-per-MN approach would be the first mechanism > that guarantees to permanently limit a node on a broadcast > link to a subset of all on-link prefixes. From this > perspective, the prefix-per-MN approach does make a difference. > > - But my point is that things won't break if you use the > prefix-per-MN approach on a broadcast link, because the > IPv4/IPv6 architecture does AFAICT not require nodes to be > aware of all on-link prefixes. > Neighboring nodes will simply not be able to communicate > directly on the link layer because they don't consider each > other "on link". This is what we'd like to have in NETLMM anyway. > > - 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) > > > Christian Vogt wrote: > > Hi Julien, > > > > I don't think there is a problem. > > > > If you use the prefix-per-MN case on a broadcast link, what > you get is > > a link comprising multiple subnets. RFC 3513 explicitly > allows links > > with multiple prefixes: > > > > Currently IPv6 continues the IPv4 model that a subnet prefix is > > associated with one link. Multiple subnet prefixes may > be assigned > > to the same link. > > > > (This is, BTW, the passage that Dave Thaler cites in > > [draft-thaler-intarea-multilink-subnet-issues].) > > > > In the scenario you describe (the one including MNs A, B, > and C), you > > simply have a link with 3 prefixes. The unusual, but still > legitimate > > circumstance in this scenario is that the MNs do not see their > > neighbors' prefixes. > > > > Note that a situation where hosts on the same link see different > > prefixes may also arise when the link has multiple routers, each > > router advertises a different set of prefixes, and no two hosts > > receive RAs from the same router due to packet loss. The > hosts will > > then not be aware of their neighbors' prefixes. Certainly, this is > > unlikely to happen, but it may happen. > > > > Let me know if I have missed something. > > > > - Christian > > > > > _______________________________________________ > netlmm mailing list > [EMAIL PROTECTED] > https://www1.ietf.org/mailman/listinfo/netlmm > _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
