Fred, My follow-up inlined below,
On Monday 06 November 2006 14:55, Templin, Fred L wrote: > Jari - see below for follow-up: > > Hi Fred, > > > >> 1. What are the issues wrt proxy/relay DAD that > >> would interfere with its adoption as a standard > >> mechanism? > > > > Almost anything can be made to work, but often > > the question is what works best or with least > > changes. In particular, we can make proxy DAD > > work, probably even with SEND. But I would > > still prefer an approach that does not require > > that. Also, if you need proxy DAD, does that > > mean that link local multicast does not work > > on the link as expected? > > The question is coming from the context of what to > do about two nodes connected to different links that > configure colliding addresses and then move onto the > same link at some later point in time. It seems that > a pre-service DAD procedure like proxy/relay DAD > would be preferrable to an in-service DAD, e.g., > (re)marking addresses as tentative and (re)running > DAD on link change. Especially since this the default DNA behavior is to not redo DAD when DNA concludes that the link did not change -- because in the NetLMM case the landmark prefix won't change even though the link indeed changed. Regarding the implications on link-local multicast, there's none since there's no change in the communication service model: Normal address resolution isn't impacted by proxy DAD, only NS and NA part of DAD would be proxied when a collision is detected by the NetLMM fabric, otherwise they won't. > [...] > > >> 3. Does the RFC1812 "subnet forwarding model" > >> still apply to IPv6, when there are no IPv6 > >> documents that reference RFC1812 normatively? > >> 4. What other non-obvious issues relating to > >> multilink subnets for shared links need to be > >> observed for NETLMM, Autoconf and other contexts? > > > > I am not sure I have an answer. But let me ask you > > a question about something which has been unclear > > to me during the NETLMM discussion. What is the > > real-world functionality that you would like to > > have? Media where this is needed? Employing just > > one prefix per a number of hosts? Special > > requirements on what the scope of link local > > multicast should be? > > Aside from the question of shared prefixes for the > moment, even in just the link-local case the concern > is for nodes that can move within a region between > shared media links on which there may be neighbors > other than just the provider's router. I think the concern apply even when links are point-to-point and the only neighbor to a MN is the provider's router. If a MN happens to move to a link where the router has a colliding link-local address, and the MN doesn't re-run DAD (as per default DNA behavior) then a collision will occur and won't be detected. That's orthogonal to the link type, be it point-to-point or shared, I think. > Proxy/relay-DAD is a pre-service DAD procedure for > ensuring that no two nodes in the region will > configure the same LL address prior to operation. > Another possible method which has been suggested by > James and others is to somehow enforce virtual > point-to-point links as overlays on the shared media > such that the (mobile) nodes would only ever see > their provider's router on the link and no other > neighbors. See my comment above. > Such an arrangement might not be appropriate for all > media types and/or deployments. > > > Also, my understanding of the NETLMM decision > > is that the working group wants to limit initial > > design to per-host prefix model, but that this > > could be extended in the future. > > Well, the relay/proxy-DAD is also about link-locals; > not just non-link-locals configured from a shared > prefix. So, this is somewhat independent from the > per-host prefix question. Agree. > > [...] Best, --julien _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
