A Method for Generating Link-Scoped IPv6 Multicast Addresses
RFC 4489
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2017-05-16 |
09 | (System) | Changed document authors from "Park Jung-Soo" to "Park Jung-Soo, Myung-Ki Shin, Hyoung-Jun Kim" |
2015-10-14 |
09 | (System) | Notify list changed from bob.hinden@nokia.com, brian@innovationslab.net to (None) |
2012-08-22 |
09 | (System) | post-migration administrative database adjustment to the No Objection position for Bill Fenner |
2006-05-03 |
09 | Amy Vezza | State Changes to RFC Published from RFC Ed Queue by Amy Vezza |
2006-05-03 |
09 | Amy Vezza | [Note]: 'RFC 4489' added by Amy Vezza |
2006-04-28 |
09 | (System) | RFC published |
2005-08-19 |
09 | (System) | Removed from agenda for telechat - 2005-08-18 |
2005-08-08 |
09 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2005-08-04 |
09 | Amy Vezza | IESG state changed to Approved-announcement sent |
2005-08-04 |
09 | Amy Vezza | IESG has approved the document |
2005-08-04 |
09 | Amy Vezza | Closed "Approve" ballot |
2005-07-28 |
09 | Brian Carpenter | [Ballot Position Update] New position, No Objection, has been recorded for Brian Carpenter by Brian Carpenter |
2005-07-27 |
09 | Margaret Cullen | State Changes to Approved-announcement to be sent from IESG Evaluation by Margaret Wasserman |
2005-07-27 |
09 | Margaret Cullen | Placed on agenda for telechat - 2005-08-18 by Margaret Wasserman |
2005-07-27 |
09 | Margaret Cullen | State Changes to IESG Evaluation from Approved-announcement to be sent by Margaret Wasserman |
2005-07-27 |
09 | Margaret Cullen | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Margaret Wasserman |
2005-07-27 |
09 | Bill Fenner | [Ballot Position Update] Position for Bill Fenner has been changed to No Objection from Discuss by Bill Fenner |
2005-07-21 |
09 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2005-07-21 |
09 | (System) | New version available: draft-ietf-ipv6-link-scoped-mcast-09.txt |
2005-03-03 |
09 | Bill Fenner | [Ballot discuss] I'd like to see a change in title; as someone knowledable about IPv6 and multicast in general but not having seen this document, … [Ballot discuss] I'd like to see a change in title; as someone knowledable about IPv6 and multicast in general but not having seen this document, I thought from the title that it was about link scoped multicast - I would like to see the title be something like "A Method for Generating Link Scoped IPv6 Multicast Addresses", or "IID-based Link Scoped IPv6 Multicast Addresses". |
2005-03-03 |
09 | Amy Vezza | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza |
2005-03-03 |
09 | Amy Vezza | [Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin by Amy Vezza |
2005-03-03 |
09 | Amy Vezza | [Ballot Position Update] New position, No Objection, has been recorded for Sam Hartman by Amy Vezza |
2005-03-03 |
09 | Amy Vezza | [Ballot Position Update] New position, Discuss, has been recorded for Bill Fenner by Amy Vezza |
2005-03-03 |
09 | Thomas Narten | [Ballot comment] > Basically, it is preferred to use this method for the link-local > scope rather than unicast-prefix-based IPv6 multicast … [Ballot comment] > Basically, it is preferred to use this method for the link-local > scope rather than unicast-prefix-based IPv6 multicast addresses > [RFC 3306]. This document restricts the usage of defined fields > such as scop, plen and network prefix fields of [RFC 3306]. > Therefore, this document specifies encoded information for link- > local scope in multicast addresses. It would be good to add a sentence explaing _why_ this mechanism is preferred over the one in 3306. |
2005-03-03 |
09 | Thomas Narten | [Ballot discuss] does IID have to be an IEEE EUI-64 identifier? The document is unclear. I assume it does not need to be, but it … [Ballot discuss] does IID have to be an IEEE EUI-64 identifier? The document is unclear. I assume it does not need to be, but it says: > The IID field (replacing the 64-bit prefix field from [RFC 3306]) > is used to distinguish each node from others. This value is > obtained from the IEEE EUI-64 based interface identifier of the > link-local unicast IPv6 address. Given the use of this method for IEEE EUI-64 is a very specific thing and is not an IID. |
2005-03-03 |
09 | Thomas Narten | [Ballot Position Update] New position, Discuss, has been recorded for Thomas Narten by Thomas Narten |
2005-03-03 |
09 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by Jon Peterson |
2005-03-03 |
09 | Harald Alvestrand | [Ballot comment] Reviewed by Mark Allman, Gen-ART His review: This one is ready to go. No issues. |
2005-03-03 |
09 | Harald Alvestrand | [Ballot Position Update] New position, No Objection, has been recorded for Harald Alvestrand by Harald Alvestrand |
2005-03-03 |
09 | David Kessens | [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens |
2005-03-02 |
09 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Undefined by Russ Housley |
2005-03-02 |
09 | Russ Housley | [Ballot comment] The header needs to indicate that this document updates RFC 3306. |
2005-03-02 |
09 | Russ Housley | [Ballot Position Update] New position, Undefined, has been recorded for Russ Housley by Russ Housley |
2005-02-28 |
09 | Scott Hollenbeck | [Ballot Position Update] New position, No Objection, has been recorded for Scott Hollenbeck by Scott Hollenbeck |
2005-02-26 |
09 | Margaret Cullen | [Ballot Position Update] New position, Yes, has been recorded for Margaret Wasserman |
2005-02-26 |
09 | Margaret Cullen | Ballot has been issued by Margaret Wasserman |
2005-02-26 |
09 | Margaret Cullen | Created "Approve" ballot |
2005-02-26 |
09 | Margaret Cullen | Note field has been cleared by Margaret Wasserman |
2005-02-22 |
09 | Margaret Cullen | State Changes to IESG Evaluation from Waiting for Writeup::Revised ID Needed by Margaret Wasserman |
2005-02-22 |
09 | Margaret Cullen | Placed on agenda for telechat - 2005-03-03 by Margaret Wasserman |
2004-12-09 |
09 | Margaret Cullen | State Changes to Waiting for Writeup::Revised ID Needed from Waiting for Writeup::External Party by Margaret Wasserman |
2004-12-07 |
08 | (System) | New version available: draft-ietf-ipv6-link-scoped-mcast-08.txt |
2004-12-05 |
09 | Margaret Cullen | Follow-up message sent to Pekka: Date: Sun, 5 Dec 2004 10:35:25 -0500 To: Pekka Savola <pekkas@netcore.fi>, iesg@ietf.org From: Margaret Wasserman <margaret@thingmagic.com> X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: ipv6@ietf.org … Follow-up message sent to Pekka: Date: Sun, 5 Dec 2004 10:35:25 -0500 To: Pekka Savola <pekkas@netcore.fi>, iesg@ietf.org From: Margaret Wasserman <margaret@thingmagic.com> X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: ipv6@ietf.org Subject: Re: Last Call: 'Link Scoped IPv6 Multicast Addresses' to Proposed Standard X-BeenThere: ipv6@ietf.org List-Id: "IP Version 6 Working Group (ipv6)" <ipv6.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe> List-Post: <mailto:ipv6@ietf.org> List-Help: <mailto:ipv6-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe> Sender: ipv6-bounces@ietf.org X-Spam: [F=0.0004985666; B=0.500(0); HS=0.500(-26400); S=0.010; MH=0.830(2004120501); R=0.010(s301/n44012)] Hi Pekka, There is a new version of this document available at: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-link-scoped-mcast-07.txt Could you check if it addresses your substantial concerns? Margaret At 12:15 AM +0200 11/13/04, Pekka Savola wrote: >On Sat, 30 Oct 2004, The IESG wrote: >> 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 >> iesg@ietf.org or ietf@ietf.org 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 ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- |
2004-12-05 |
09 | Margaret Cullen | State Changes to Waiting for Writeup::External Party from Waiting for Writeup::AD Followup by Margaret Wasserman |
2004-12-05 |
09 | Margaret Cullen | [Note]: 'Sent follow-up message to Pekka to see if the latest version addresses his concerns.' added by Margaret Wasserman |
2004-12-02 |
09 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2004-12-02 |
07 | (System) | New version available: draft-ietf-ipv6-link-scoped-mcast-07.txt |
2004-11-22 |
09 | Margaret Cullen | State Changes to Waiting for Writeup::Revised ID Needed from Waiting for Writeup by Margaret Wasserman |
2004-11-22 |
09 | Margaret Cullen | [Note]: 'Waiting for update to address LC issues from Pekka Savola.' added by Margaret Wasserman |
2004-11-22 |
09 | Margaret Cullen | IETF LC Comments: From: Pekka Savola <pekkas@netcore.fi> To: iesg@ietf.org Cc: ipv6@ietf.org Subject: Re: Last Call: 'Link Scoped IPv6 Multicast Addresses' to Proposed Standard On Sat, … IETF LC Comments: From: Pekka Savola <pekkas@netcore.fi> To: iesg@ietf.org Cc: ipv6@ietf.org Subject: Re: Last Call: 'Link Scoped IPv6 Multicast Addresses' to Proposed Standard On Sat, 30 Oct 2004, The IESG wrote: > The IESG has received a request from the IP Version 6 Working Group WG to > consider the following document: > ...snip... > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org 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". |
2004-11-17 |
09 | Michelle Cotton | IANA Last Call Comments: We understand there to be NO IANA Actions for this document. |
2004-11-13 |
09 | (System) | State has been changed to Waiting for Writeup from In Last Call by system |
2004-10-30 |
09 | Amy Vezza | Last call sent |
2004-10-30 |
09 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2004-10-28 |
09 | Margaret Cullen | Last Call was requested by Margaret Wasserman |
2004-10-28 |
09 | Margaret Cullen | State Changes to Last Call Requested from AD Evaluation::AD Followup by Margaret Wasserman |
2004-10-28 |
09 | (System) | Ballot writeup text was added |
2004-10-28 |
09 | (System) | Last call text was added |
2004-10-28 |
09 | (System) | Ballot approval text was added |
2004-10-15 |
09 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2004-10-15 |
06 | (System) | New version available: draft-ietf-ipv6-link-scoped-mcast-06.txt |
2004-10-03 |
09 | Margaret Cullen | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Margaret Wasserman |
2004-10-03 |
09 | Margaret Cullen | I have completed my review of draft-ietf-ipv6-link-scoped-mcast-05.txt, and I have several comments on this draft. As some of these comments are substantive, I would like … I have completed my review of draft-ietf-ipv6-link-scoped-mcast-05.txt, and I have several comments on this draft. As some of these comments are substantive, I would like the draft to be updated to address these concerns before I send it to IETF Last Call. Let me start with a couple of general comments: (1) There are several places in this document where it says that these link-scoped multicast addresses will be assigned "at the same time" as link-local addresses are auto-configured. I don't see any reason for this restriction, and I believe that these addresses could safely be configured at any time after DAD is completed. (2) The document says: 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]. This makes sense to me, but I think it misses the point... Since these addresses are created from the unique IID, their useful lifetime is linked to the period during which the IID is known to be unique. Right? So, the document needs to discuss what happens to these addresses if there is a later IID conflict, due to a new node joining the network that uses the same IID. I also have some specific comments on the text (marked with '>>'): Abstract This document specifies an extension to the multicast addressing architecture of the IPv6 protocol. The extension allows for the use of interface-IDs to allocate multicast addresses. When a link- >> I would refer to Interface Idenfitiers (IIDs) the first time and later use the IID acronym for consistency with other IPv6 documents. Consequently, this technique MUST be used for link scoped multicast >> MUST only be used for link scoped multicast? (s/MUST/MUST only) ?? addresses. If you want to use multicast addresses greater than link-local scope, you need other methods such as [RFC 3306]. That is, flgs, scop, and LSM fields are used to identify whether an address is a multicast address as specified in this document and to be processed any further. >> What type of further processing is done on these addresses? I wouldn't think that, after they are generated, these addresses would be handled any differently than other link scoped multicast addresses... Interface ID field is used to distinguish each node from others. And this value is obtained from the IEEE EUI-64 based interface identifier of the link-local unicast IPv6 address. Given the use of this method for link-local scope, the interface ID embedded in the multicast address SHOULD come from the interface ID of the link-local unicast address on the interface after DAD has completed. That is, the creation of the multicast address MUST occur after DAD has completed as part of the auto-config process. >> This paragraph conflicts with itself. It is not clear whether the link scoped address SHOULD only be configured after DAD has completed or MUST only be configured after DAD has completed. I think you mean MUST... 6. Security Considerations [RFC 3041] describes the privacy extension to IPv6 stateless address autoconfiguration for an interface ID. The interface ID, generated by [RFC 3041], is also used in this method since the uniqueness is verified by DAD procedure as part of the secure auto- config process. >> You should probably indicate whether link scoped multicast addresses can be configured using IIDs generated for privacy addresses or not. Informative [RFC 2461] T. Narten, E. Nordmark and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)," RFC 2461, December 1998. >> I think that you need a normative reference to this and to IPv6 Auto Configuration. |
2004-09-24 |
09 | Margaret Cullen | State Changes to AD Evaluation from Publication Requested by Margaret Wasserman |
2004-09-24 |
09 | Margaret Cullen | 1) Have the chairs personally reviewed this version of the ID and do they believe this ID is sufficiently baked to forward to the … 1) Have the chairs personally reviewed this version of the ID and do they believe this ID is sufficiently baked to forward to the IESG for publication? Yes 2) Has the document had adequate review from both key WG members and key non-WG members? Do you have any concerns about the depth or breadth of the reviews that have been performed? The document has been reviewed by several members of the IPv6 WG. Additionally, several multicast experts have reviewed the proposal. The chairs have no concerns about the reviews. 3) Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)? No. 4) Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or whether there really is a need for it, etc., but at the same time these issues have been discussed in the WG and the WG has indicated it wishes to advance the document anyway. No concerns. 5) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? This document has strong concurrence within a small set of the WG. 6) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize what are they upset about. No. 7) Have the chairs verified that the document adheres to _all_ of the ID nits? Yes - Technical Summary This document specifies an extension to the multicast addressing architecture of the IPv6 protocol. The extension allows for the use of interface-IDs to allocate multicast addresses. When a link- local unicast address is configured at each interface of a node, an interface ID is uniquely determined. By delegating multicast addresses at the same time as the interface ID, each node can generate their unique multicast addresses automatically without conflicts. Basically, it is preferred to use this method for the link-local scope rather than unicast-prefix-based IPv6 multicast addresses [RFC 3306]. - Working Group Summary The IPv6 working group has done reviews of this document and this document reflects the consensus of the group. - Protocol Quality This document has been reviewed by members of the ipv6@ietf.org mailing list and by the working group chairs. Regards, Brian & Bob IPv6 WG co-chairs |
2004-09-22 |
09 | Dinara Suleymanova | Draft Added by Dinara Suleymanova in state Publication Requested |
2004-08-18 |
05 | (System) | New version available: draft-ietf-ipv6-link-scoped-mcast-05.txt |
2004-07-15 |
04 | (System) | New version available: draft-ietf-ipv6-link-scoped-mcast-04.txt |
2003-07-02 |
03 | (System) | New version available: draft-ietf-ipv6-link-scoped-mcast-03.txt |
2002-11-07 |
02 | (System) | New version available: draft-ietf-ipv6-link-scoped-mcast-02.txt |
2002-07-05 |
01 | (System) | New version available: draft-ietf-ipv6-link-scoped-mcast-01.txt |
2002-04-22 |
00 | (System) | New version available: draft-ietf-ipv6-link-scoped-mcast-00.txt |