Hi Thomas,
On May 16, 2005, at 16:02, Thomas Narten wrote:
Hi Brian.
Wouldn't it make sense for this document to at least mention that there is a synchronization error in terminology used by IANA with respect to terminology used in this document?
Personally, I don't think so. The addressing architecture actually points at RFC 2375 which doesn't say anything about the allocation rules for IANA. RFC 3307 does put forth the rules. So, the cleanup needs to ensure that 3307 is the definitive reference for the registry. It seems to be an in-direct approach to say something about 3307 in the new addressing architecture.
As for the terminology, the text in the new addressing architecture is the correct text (in my view). The IANA pages will be updated to reflect that once it is published.
I'm still trying to convince myself that this is the case.
addr-arch has the T bit to distinguish between:
T = 0 indicates a permanently-assigned ("well-known")
multicast address, assigned by the Internet Assigned Number
Authority (IANA).
T = 1 indicates a non-permanently-assigned ("transient")
But, RFC 3307 (which has the IANA considerations for mcast addresses) doesn't use the latter terminology. It uses:
- The range 0x80000000 to 0xFFFFFFFF is reserved for use by dynamic multicast address allocation mechanisms, see Section 4.3.
I.e., "dynamic". This may be a minor point, but in looking through the various documents, this use of different terms didn't help me figure out what was going on...
As I mentioned, Bob will be updating the addressing arch to incorporate
text to clarify the R & P bits. We will ensure that the language is consistent.
With the use of "dynamic" or "transient" in the IANA section, the text from Section 4.3 in 3307 says:
Dynamic IPv6 multicast addresses can be allocated by an allocation server or by an end-host. Regardless of the allocation mechanism, all dynamically allocated IPv6 multicast addresses MUST have the T bit set to 1.
This was done to tie together the terminology from the IPv6 architecture with the multicast address allocation language in the MALLOC work. So, it really tries to manage two sets of definitions.
Which terminology is preferred? Is it the text in RFC 3307, or the text in addr-arch?
Depends on whether you want to talk IPv6 or MALLOC. :) Seriously, 3307 does suffer from the fact it straddles two worlds that defined separate terminology for the same behavior.
Additionally, the ad-hoc committee can do this without being dependent on the approval/publication of a document. We can point IANA to 3307 and say it is the guidelines for all multicast addresses and then work with them to ensure the webpages are correct.
I think this works as long as what we are asking IANA to do is consistent with the existing documents, as the ad-hoc shouldn't be filling in the gaps on its own. Or, if it needs to, then a document would presumably need to be produced and pushed through the system.
I hope we don't need another (separate) document.
As do I. My opinion is that we will need to spend some time explaining the existing docs rather than writing yet another one.
Also, one thing I notice (not sure how to fix or whether to fix) is that RFC 3307 talks about "group IDs", which seem to be 4-byte quantities (per 3307):
4.2 Permanent IPv6 Multicast Group Identifiers
Permanent group IDs allow for a global identifier of a particular
service (e.g. Network Time Protocol (NTP) being assigned the group ID
0x40404040). The use of permanent group IDs differs from permanent
multicast addresses in that a permanent group ID offers a global
identifier for a service being offered by numerous servers.
As an example, consider the NTP example group ID of 0x40404040. An
NTP client would be able to access multiple servers and multiple
scopes. That is, the NTP client will know that the group ID
0x40404040 identifies an NTP multicast stream regardless of the upper
96 bits of the multicast address.
Permanent group IDs are allocated on an Expert Review basis, in the
range 0x40000000 to 0x7FFFFFFF. These permanent group IDs are meant
to be used in IPv6 multicast addresses, defined in [UNIMCAST].
But, addr-arch talks about "group IDs" differently:
| 8 | 4 | 4 | 112 bits | +------ -+----+----+---------------------------------------------+ |11111111|flgs|scop| group ID | +--------+----+----+---------------------------------------------+
i.e., they are 112-bits long. And there is no mention of the RFC 3307-style Group IDs for which IANA has created a registry.
RFC 3306 explains this difference. So, the additional reference to 3306 for the P bit will help with this.
Regards, Brian
smime.p7s
Description: S/MIME cryptographic signature-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
