Bernard,
thanks for a very thorough review.
[I didn't see this before the IESG raised a DISCUSS, it must be useful for the
authors / wg to see these reviews too?]
[...]
In the abstract, the draft correctly states that it is not mandatory that
the link layer destination of an IP multicast packet be a link layer
multicast address. However, the document does not state what the functional
requirement is, namely that the IP multicast packet be delivered to all
potential subscribers. In some situations (such as a point-to-point link),
this requirement can be met by sending the frame to a unicast destination
link-layer address. In other situations (such as a WLAN), to meet that
requirement it would be necessary to either send the frame to a multicast
link-layer destination address *or* to send the frame to multiple unicast
link-layer destination addresses.
we specifically didn't want to go into the use cases for this functionality.
e.g. one use case being N:1 VLANs (which are point to point upstream and
multi-access downstream), where one wants to send a different multicast message
to each user. everyone listens to the same multicast address (e.g. IPv6 all
routers), but the message sent to each is different, and that requires (in that
deployment) unicast L2 addresses. basically making the link appear like a point
to point link.
what the functional requirement is, depends. so I'd very much like to keep that
out of the document, which only purpose is to clarify that it is valid to map a
L3 IPv6 multicast address into a L2 unicast address.
The draft does not state the fundamental requirement, and is not
sufficiently precise about the circumstances in which a unicast link-layer
address can be used. For example, Section 3 states:
o An IPv6 sender node in some special cases and specifically when
the link-layer address of the target node is known, MAY choose to
transmit an IPv6 multicast message as a link-layer unicast message
to that node. In this case, the destination address in the IPv6
header will be a multicast group address, but the destination
address in the link-layer header will be an unicast address.
The problem is that the above paragraph does not adequately define the
meaning of the term "sender" or the special cases in which the MAY applies.
indeed. the same argument as above applies.
with regards to "sender", I've looked through a few multicast RFCs and none of
them define the term "sender". to me, although a non-native English speaker,
the term is not ambiguous. could you clarify what you mean?
Certainly if we are talking about a point-to-point link then a sender can
know that there is only one potential subscriber on the other end.
indeed. I would imagine many of the use cases are for such deployments, point
to point links, or where one try to make a multi-access link look like it is
point to point, where this mapping is done for link-local multicast packets.
e.g. ND RAs.
Also, if the sender is a device such as a switch or AP, then it will have
knowledge of the potential endpoints that are potential targets.
However, if the sender is a host, then the question is how a sender can know
the link-layer address of all the target nodes. Hosts don't normally keep
track of multicast subscriptions. In some situations, that may not even be
possible -- if we are talking about a multicast group that is not
link-scope, and the target node is known but is not on the link, the host
won't be able to obtain this knowledge and in any case, sending the frame to
the target's link layer address doesn't make sense, since it could result in
the frame not being delivered.
I haven't seen any use case where a host would use this. but, if there was one,
it would have to know the L2 address by some other means.
again, we do not want to go into details on how this could be used. just state
that the alternative mapping is valid.
So I think that the term "sender" needs to be defined and this paragraph
needs to be re-written to make it very clear when a unicast link-layer
address can be used by the sender, and in what circumstances this is not
safe.
this document is being referenced by BBF and also by some work in PMIP(?). in
any case I'd like those documents to have the restrictions.
on the other hand I see your point. we don't want 'random' multicast senders to
"optimize" and use this mapping.
the introduction states that this applies when there is _one_ receiver. if we
also added that restriction to the above paragraph, would that make it clearer?
o An IPv6 receiver node SHOULD NOT drop a received IPv6 multicast
message only for the one specific reason that the received IPv6
message has a multicast destination address in the IPv6 header
while the link-layer header has a unicast address. Such a
validity check comparing the address types in the IP header and
the link-layer header is considered a layer violation.
Given the fundamental point that is being made (that IP and link-layer
addressing are independent), I am not clear about the circumstances in
which it would be valid to drop an IPv6 multicast packet because of its
link-layer destination address. I would like to see this spelled out, so
that it is clear why this is a MUST NOT.
I can't think of one either. a SHOULD NOT is quite strong, but I would
certainly not disagree with changing that to a MUST NOT either.
cheers,
Ole
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf