First off, a prefix advertised in an RA is not assigned to an end
node, it
is assigned to a link. A prefix can only rightly be considered to be
assigned to a node when it is delegated via DHCP, this allows the node
to
then assign the prefix to links downstream, or delegate further if the
prefix isn't a /64.
The text does not say anywhere "assigned to (sic) an end node";
it says "associated with (sic) an end node/nodes", and prefixes
are associated with a link per (RFC4291, Section 2.1).
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:
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.
Secondly, exactly what is meant by 'L=0' is underspecified by RFC
2461. I
think everyone agrees with 'L=1' means, that the prefix is only being
advertised to nodes that are on this physical link. Any effort to
tighten up
the definitoin of 'L=0' is going to need wider discussion with the
ipv6 WG
and possibly might impact RFC2461bis. This draft is currently in AD
Evauation:Revised Draft Needed.
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?
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.
jak
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
