Fred,
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.
jak>> Well it does according to my reading of the enclosed text from RFC
4291. Perhaps we need someone else's opinion on this, since we clearly
disagree. Perhaps we should ask Bob Hinden, as he is the author of the
disputed text in RFC 4291?
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.
jak>> The current text is unacceptable to me, as insufficiently precise.
jak>> What are other people's opinions?
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.
jak>> What are your expectations about what advertising 'L=1' means for the
link?
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.
jak>> "Cannot avoid a multilink subnet"? Then why call it "Multilink Subnet
Avoidance"?'
jak
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]
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
