[pim] draft-ietf-pim-rfc1112bis-07 early Iotdir review

Document: draft-ietf-pim-rfc1112bis
Title: Host Extensions for IP Multicasting and "Any Source Multicasting" (ASM)
IP service Reviewer: Erik Nordmark Review result: Ready with Issues

I have a question around Level 2L, which is new to me. In the past there has
been an assumption that layer 2 devices (bridges, L2 switches) can perform
IGMP/MLD snooping to determine what to filter based on Ethernet multicast
addresses. Back in the day this possible except that the all-hosts (IPv4) and
all-nodes (IPv6) would always need to be forwarded at L2. Has the industry
moved away from IGMP/MLD snooping? And is the draft trying to say that an
implementation is free to implement support for IGMP/MLD snooping but it is not
part of the standard? (The intent of the different sections are not quite clear
to me on this topic.)

Security considerations: have there been any discussion about the fact that
applications should not assume that traffic sent to a link-local multicast
address was sent by a host on the attached link? (various tunneling approaches
can be used to have a router potentially send such a packet on a link.) Is this
worth noting?

Terminology nit:
For better or worse, the IPv6 RFCs do not use the term "IPv6 host group", yet
in this document that term appears three times. Some of those are odd - "IPv6
host group address" should be replaced by "IPv6 multicast address". The one in
section 4 might make sense to keep (but reword) to make the connection with the
IPv4 terminology. Thus I'd suggest changing "IPv6 Host groups are identified by
IPv6 addresses" to "In IPv6 the concept of host groups are identified by IPv6
multicast addresses" or something along those lines.

Section 9.2:
I'm having a hard time parsing this sentence "do or may include backward
compatibility with IGMPv1" since it isn't clear what "do or may" means when
referring to existing specifications. Is this intended to refer to
implementations?

Section 10.8 typo: "MLS" should be "MLD".

Section 12.2 says "keep an IP multicast address secret"
That can easily be read as "secure" when "obscure" would be a better name for
it. This is an observation about the pssibility to have randomly generated IPv6
multicast addresses, and if such are used, it is hard (but not impossible) to
find them by trial and error. But many IPv6 protocols use well-defined fixed
multicast addresses.



_______________________________________________
pim mailing list -- [email protected]
To unsubscribe send an email to [email protected]