The IESG has received a request from the IP Version 6 Working Group WG to consider the following document:
- 'Link Scoped IPv6 Multicast Addresses ' <draft-ietf-ipv6-link-scoped-mcast-06.txt> as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2004-11-13.
The document is in an awful shape. It clearly hasn't seen sufficient review. I think thew applicability is very questionable as well, but it seems some think this is sufficiently useful...
semi-substantial ----------------
==> this doc should probably say "This memo updates RFC 3306." at the end, because you're modifying the format specified there (an old MUST no longer applies).
flgs MUST be "0011". (The first two bits have been yet undefined,
sent as zero and ignored on receipt) flgs MUST use the same flag
defined in section 4 of [RFC 3306].==> the sentence no longer holds true, due to embedded-RP. I'd suggest just
removing the sentence, because it doesn't seeem to be relevant to the main thrust of the document.
scop MUST be <= 2. It is preferred to use this method for the
link-local scope rather than unicast-prefix-based IPv6 multicast
addresses [RFC 3306].
==> The sentence here is redundant. The users can use whichever they wish and deem appropriate.
LSM (Link Scoped Multicast) field MUST be "1111 1111" which maps to
the plen field in [RFC 3306], whereas the plen field in [RFC 3306]
MUST NOT be greater than 64.
That is, flgs, scop, and LSM fields are used to identify whether an address is a multicast address as specified in this document.
==> this seems an inappropriately complex and confusing way to specify this,
renaming plen field to "LSM" and giving it static value of 255. Just
specify that plen = 255, you don't even have to have the extra diagram and you're done!
The lifetime of link scoped multicast addresses has no dependency
on the Valid Lifetime field in the Prefix Information option,
corresponding to the unicast address being used, contained in the
Router Advertisement message [RFC 2461].==> does this need to be said? This is rather obvious. If you want to say something, I'd rather say that there is no lifetime because link-local addresses have no lifetime!
5. Considerations
Since multicast addresses are created from the unique IID, their useful lifetime is linked to the period during which the IID is known to be unique. Thus, it is possible to conflict between IIDs, due to a new node joining the network that uses the same IID. The document does not consider this case at this phase. It is another challenging issue and out of scope of this document.
==> this is a bit inaccurate, "due to a new node joining the network that uses the same IID" -- this node would fail DAD and be unable to use the link-local address to generate the link-scoped address! On the other hand, the cases where DAD fails, this also fails -- like the node with same MAC address as with someone on the link powered on and only after that plugged on the link.
The link scoped multicast address format supports source-specific
multicast addresses by the same method, as defined by [RFC 3306].==> this is tehnically conflicting with the spec because plen is 255, and not 0 as required by SSM. Just remove this.
==> The title should be renamed in any case to something better than "Considerations".
6. Security Considerations
[RFC 3041] describes the privacy extension to IPv6 stateless address autoconfiguration for an IID. The secure IID, generated by [RFC 3041], can be used for consisting of a link scoped multicast address since the uniqueness is verified by the DAD procedure as part of the secure auto-configuration process.
==> Here Be Dragons! This is technically wrong: RFC3041 addresses are generated based on the received prefix information options, so there will never be link-local scope RFC3041 addresses to generate the multicast addresses from -- and even if there were, you'd have to consider their lifetime here.
==> Now that this bogus text is removed, Security Considerations section is empty. I guess something needs to be written there. I guess you could say that the uniqueness of the multicast addresses is guaranteed by the DAD process.
editorial ---------
of a node, an IID is uniquely determined. After then, each node
==> "After then" should be replaced with something like "After that" or just simply "Then". Fix in multiple places.
conflicts. Basically, it is preferred to use this method for the
link-local scope rather than unicast-prefix-based IPv6 multicast
addresses [RFC 3306].==> no references in the abstract, just remove '[RFC 3306]'.
Also, nodes which are
supplied multicast services, easily consist of multicast addresses
of multicast servers using NDP (address resolution) and well-known
group IDs.==> "supplied" -> "supplying" ? Further, I'm having trouble understanding what this sentence tries to mean..
Group ID is generated to indicate multicast application and is used
to guarantee its uniqueness only in the host. It may also be set
on the basis of the guidelines outlined in [RFC 3307].==> remove "also".
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
