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. >> 2. What harmful on-link assumptions could there be for >> IPv6 Prefix Information Options that advertise a >> shared prefix with 'L=0'? > > None that I know of. OK. If a node receives a PIO with 'L=0' and then configures a /128 on an interface, could applications get confused and assume that all destinations covered by the /64 that also covers the /128 are on-link? Is this something that should be added to an "on-link assumption considered harmful" document? (The latest version of the 'multilink-subnet' draft also says something about this.) >> 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. 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. 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. > As for AUTOCONF, there are no decisions yet, > but my main requirement for them has been > that they must define their architecture, including > addressing and how links are seen from IP. And > avoid issues from Dave's draft if possible. The > architecture needs to be concrete enough so > that we can determine what protocol work is > needed for, e.g., prefix allocation, prefix/address > uniqueness checking, and gateway selection. Thanks for this and for the other perspectives, Fred [EMAIL PROTECTED] --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
