James, > jak>> The last paragraph of Section 2.1 in 4291 says: > > Currently, IPv6 continues the IPv4 model in that a subnet prefix is > associated with one link. Multiple subnet prefixes may be assigned > to the same link. > > jak>> So whether the term "associated" or "assigned" is used is not > particularly relevant. Both are used to mean that the link is what, in a > sense, "owns' the prefix, not the node. > > jak>> Inferring from the previous text in that section, the discussion makes > clear that prefixes are assigned to interfaces, not nodes. In fact, the > first sentence in the section says that: > > IPv6 addresses of all types are assigned to interfaces, not nodes. > > jak>> I interpret the text in the paragraph you sent to mean that the node > "owns" the prefix. I would suggest modifying the text as follows:
"Associated" does not mean "owned" by any sense of the definition for "associated" I was able to find in www.m-w.com. > An individual prefix is an IP prefix assigned to an interface on a specific > MN on a single link and is not shared by any other node on the link with > the exception of the last hop router, and a shared prefix is an IP prefix that > may be assigned to interfaces on multiple MNs on a single link. That is unnecessarily restrictive, as I believe you know. > As long as a MN does not assign a prefix with 'L=0' to an interface, > then the RFC2461 interpretation of 'L=0' is irrelevant in terms of > the text I offered and RFC2461 is certainly specified well enough > such that implementations would not assign a prefix with 'L=0' to > an interface. > > jak>> I'm not sure I understand. Perhaps you can provide some background on > what exactly you are intending to convey with this text? I don't know how to address a question like this without more detail, since my statement above and the offered text read clearly to me. > Thirdly, this doesn't discuss at all link forwarding considerations, > particularly with regard to link local multicast (i.e. forwarding of traffic > to link local multicast addresses). As we've discussed offlist, exactly how > link local multicast forwarding works for NETLMM is an open question at this > point. I started another thread on that for comment. So far, the thread > hasn't been very active. > Again, this is irrelevant wrt to the text I offered, and subject > for a separate thread of discussion. Such discussion should take > place on a wider distribution such as the INT area and IPv6 lists > since it is germane to the IPv6 addressing architecture and not > particular to NETLMM. > > jak>> I think it is relevant to multilink subnets. Suppose a NETLMM domain > is a multilink subnet. Then the question of what happens with link local > multicast is important. Does it get forwarded between physical links or not? > This determines whether the NETLMM domain looks like a single virtual > physical link or not. An application that uses link local multicast might > work differently if link local multicast is forward or not, as we have > discussed. The point of the offered text is that by following the guidelines a NETLMM domain cannot be a multilink subnet. I can call it something like "Multilink Subnet Avoidance" if you'd like. Here is the offered text again: "5. Multilink Subnet Considerations An individual prefix is an IP prefix associated with a specific MN, and a shared prefix is an IP prefix that may be associated with multiple MNs. ARs must not include an individual prefix in RAs that may be received by a MN other than the one associated with the prefix. ARs must not send RAs that include a shared prefix in a Prefix Information Option with 'A'=1 unless there is operational assurance of duplicate address detection/avoidance across the NETLMM domain. ARs must not send RAs that include an individual or shared prefix in a Prefix Information Option with 'L'=1 unless all RAs that include the prefix and all MNs that receive them are associated with a single link." Fred [EMAIL PROTECTED] -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
