Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address
RFC 3956
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22 |
07 | (System) | post-migration administrative database adjustment to the No Objection position for Thomas Narten |
2012-08-22 |
07 | (System) | post-migration administrative database adjustment to the No Objection position for Bill Fenner |
2012-08-22 |
07 | (System) | post-migration administrative database adjustment to the No Objection position for Ted Hardie |
2012-08-22 |
07 | (System) | post-migration administrative database adjustment to the No Objection position for Alex Zinin |
2004-11-23 |
07 | Amy Vezza | State Changes to RFC Published from RFC Ed Queue by Amy Vezza |
2004-11-23 |
07 | Amy Vezza | [Note]: 'RFC 3956' added by Amy Vezza |
2004-11-08 |
07 | (System) | RFC published |
2004-08-17 |
07 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2004-08-16 |
07 | Amy Vezza | IESG state changed to Approved-announcement sent |
2004-08-16 |
07 | Amy Vezza | IESG has approved the document |
2004-08-16 |
07 | Amy Vezza | Closed "Approve" ballot |
2004-08-13 |
07 | David Kessens | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by David Kessens |
2004-07-19 |
07 | Bill Fenner | [Ballot Position Update] Position for Bill Fenner has been changed to No Objection from Discuss by Bill Fenner |
2004-07-19 |
07 | Thomas Narten | [Ballot Position Update] Position for Thomas Narten has been changed to No Objection from Discuss by Thomas Narten |
2004-07-13 |
07 | Alex Zinin | [Ballot Position Update] Position for Alex Zinin has been changed to No Objection from Discuss by Alex Zinin |
2004-07-02 |
07 | Ted Hardie | [Ballot Position Update] Position for Ted Hardie has been changed to No Objection from Discuss by Ted Hardie |
2004-07-02 |
07 | (System) | New version available: draft-ietf-mboned-embeddedrp-07.txt |
2004-06-30 |
07 | Thomas Narten | [Ballot discuss] > R = 1 indicates a multicast address that embeds the address on the > RP. Then P MUST be set … [Ballot discuss] > R = 1 indicates a multicast address that embeds the address on the > RP. Then P MUST be set to 1, and consequently T MUST be set to 1, as > specified in [RFC3306]. If R = 1, but P is set to 0, the packet MUST > be discarded. The behaviour if T is set to 0 when P is set to 1 is > derived from [RFC3306] and is unspecified in this memo. "MUST be discarded" seems like a bad thing to specify. Are we really saying there are illegal addresses that one is not allowed to use? (In the unicast space, we have tried very hard not to have any addresses that are "reserved" in the sense that implementations check for them and don't process them.) Better to leave unspecified, and have hosts treat them as if they were normal multicast addresses (i.e, with no special semantics) > RIID = 0 must not be used as using it would cause ambiguity with the > Subnet-Router Anycast Address [ADDRARCH]. Are there other conflicts? Actually, a whole range of anycast addresses has been reserved. See RFC 2526. So, the addresses in this document potentially conflict with other ones. Need clarification on what the right thing to do is. |
2004-06-30 |
07 | Thomas Narten | [Ballot discuss] > R = 1 indicates a multicast address that embeds the address on the > RP. Then P MUST be set … [Ballot discuss] > R = 1 indicates a multicast address that embeds the address on the > RP. Then P MUST be set to 1, and consequently T MUST be set to 1, as > specified in [RFC3306]. If R = 1, but P is set to 0, the packet MUST > be discarded. The behaviour if T is set to 0 when P is set to 1 is > derived from [RFC3306] and is unspecified in this memo. MUST be discarded seems like a bad thing to specify. Are we really saying there are illegal addresses that one is not allowed to use? Better to leave unspecified, and have hosts treat them as if they were normal multicast addresses (i.e, with no special semantics) > RIID = 0 must not be used as using it would cause ambiguity with the > Subnet-Router Anycast Address [ADDRARCH]. Are there other conflicts? Actually, a whole range of anycast addresses has been reserved. So, the addresses in this document potentially conflict with other ones. Need clarification on what the right thing to do is. |
2004-06-30 |
07 | Thomas Narten | [Ballot Position Update] New position, Discuss, has been recorded for Thomas Narten by Thomas Narten |
2004-06-28 |
07 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2004-06-28 |
06 | (System) | New version available: draft-ietf-mboned-embeddedrp-06.txt |
2004-06-25 |
07 | David Kessens | [Ballot comment] Comments received from gen-art (by Mark Allman <mallman@icir.org>): I'd say this draft is not quite ready. A few points .... … [Ballot comment] Comments received from gen-art (by Mark Allman <mallman@icir.org>): I'd say this draft is not quite ready. A few points .... * I'd **really** like to see an introduction that says what problem is being solved in very high-level terms. By the end of the document I sort of have an understanding, but I was immediately lost because the document seems to assume context that just isn't there for some of us. I understand that this is really only going to be used by folks implementing, but still --- I don't think it too much to ask to craft a statement on the problem the document solves that everyone else can understand. * Please define all acronymns. There are plenty of cases when an acronymn is just used without being defined or even spelled out. Please check them all. (A concrete example is the use of "DR" starting in section 6.) * Likewise, this (S,G) notation is weird to an outsider. A word or two about it's meaning would be useful (not an entire tutorial -- I understand the document is not for "outsiders", but a little help would be appreciated). * The text does not refer to appendix A, but should. * Section 3: The first half of the section seems un-needed to me (before the diagram). This text says things like if the flags are set to "01". But, that is not really what is meant. Rather, the document is keying on the second bit being one. At the moment, the first bit is unassigned and should be zero. But, the document even notes that this may change in the future. So, why does the document specify the first bit when it doesn't need to? Also, what happens when R=1 and either P or T (or both) are not 1? It seems that the failure cases should be considered more. * In the diagram on page 6, I assume "ID" is really "RIID"? I'd suggest changing the diagram for consistency. |
2004-06-25 |
07 | (System) | Removed from agenda for telechat - 2004-06-24 |
2004-06-24 |
07 | Amy Vezza | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza |
2004-06-24 |
07 | Amy Vezza | [Ballot Position Update] New position, No Objection, has been recorded for Harald Alvestrand by Amy Vezza |
2004-06-24 |
07 | Allison Mankin | [Ballot Position Update] New position, No Objection, has been recorded for Allison Mankin by Allison Mankin |
2004-06-24 |
07 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by Jon Peterson |
2004-06-24 |
07 | Alex Zinin | [Ballot discuss] > R = 1 indicates a multicast address that embeds the address on the > RP. Then P MUST be set … [Ballot discuss] > R = 1 indicates a multicast address that embeds the address on the > RP. Then P MUST be set to 1, and consequently T MUST be set to 1, as > specified in [RFC3306]. The spec needs to say what to do if R==1 && P==0 && T==0 |
2004-06-24 |
07 | Alex Zinin | [Ballot Position Update] New position, Discuss, has been recorded for Alex Zinin by Alex Zinin |
2004-06-24 |
07 | Margaret Cullen | [Ballot Position Update] New position, No Objection, has been recorded for Margaret Wasserman by Margaret Wasserman |
2004-06-23 |
07 | Bill Fenner | [Ballot discuss] I don't get why Example 2 seperates "zzzz:zzzz" and [group ID]. You're really moving the boundary between group ID and prefix, right, so … [Ballot discuss] I don't get why Example 2 seperates "zzzz:zzzz" and [group ID]. You're really moving the boundary between group ID and prefix, right, so it's more like FF7x:y20:2001:DB8:[group ID], and the group ID is 64 bits in this case. An alternate way of saying this is that using the 20 plen results in being able to assign addresses out of FF7x:y20:2001:DB8/64. I think the confusing part is 'and "zzzz:zzzz" will be assignable to anyone'. If you don't want to switch notations, please reword this part. I don't see the difference between example 2 and example 3, other than that example 3 has a more concrete address (replaces zzzz:zzzz with DEAD::). -- In the section on Group-to-RP Mapping, I think it would be useful to completely specify in the terms of the PIM algorithm - for example - For addresses in the range FF70::/12, the Embedded-RP mapping is considered to be the longest possible match and higher priority than any other mechanism - this uses the terms of the PIM spec to say the group-to-RP mapping specified in this memo MUST be used for all embedded-RP groups (i.e., addresses with prefix FF70::/12). so is more likely to be easily implementable. |
2004-06-23 |
07 | Bill Fenner | [Ballot Position Update] New position, Discuss, has been recorded for Bill Fenner by Bill Fenner |
2004-06-23 |
07 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Undefined by Russ Housley |
2004-06-23 |
07 | Russ Housley | [Ballot comment] Please delete Appendix B before publication as an RFC. |
2004-06-23 |
07 | Russ Housley | [Ballot Position Update] New position, Undefined, has been recorded for Russ Housley by Russ Housley |
2004-06-21 |
07 | Steven Bellovin | [Ballot Position Update] New position, No Objection, has been recorded for Steve Bellovin by Steve Bellovin |
2004-06-18 |
07 | Ted Hardie | [Ballot discuss] Perhaps I'm misreading this, but: 6.3. Guidelines for Assigning IPv6 Addresses to RPs With this mechanism, the RP can be given basically … [Ballot discuss] Perhaps I'm misreading this, but: 6.3. Guidelines for Assigning IPv6 Addresses to RPs With this mechanism, the RP can be given basically any network prefix up to /64. The interface identifier will have to be manually configured to match "RIID". seems to limit this mechanism to entities which control a specific prefix length. That limit, though, does not appear to be present in Example 1, and the discussion in the "design trade-offs" section on this point (and the related text in 3306) does not clarify it enough. It seems to the non-expert review that it would be better to start off with something like "Within the prefix FF70::/12 ...." and go on from there. But some clarification would be appreciated. |
2004-06-18 |
07 | Ted Hardie | [Ballot Position Update] New position, Discuss, has been recorded for Ted Hardie by Ted Hardie |
2004-06-18 |
07 | Scott Hollenbeck | [Ballot Position Update] Position for Scott Hollenbeck has been changed to No Objection from Undefined by Scott Hollenbeck |
2004-06-18 |
07 | Scott Hollenbeck | [Ballot comment] Missing IANA Considerations (I-D checklist), though I assume it's not there because there aren't any. |
2004-06-18 |
07 | Scott Hollenbeck | [Ballot Position Update] New position, Undefined, has been recorded for Scott Hollenbeck by Scott Hollenbeck |
2004-06-17 |
07 | David Kessens | Placed on agenda for telechat - 2004-06-24 by David Kessens |
2004-06-17 |
07 | David Kessens | State Changes to IESG Evaluation from Waiting for Writeup by David Kessens |
2004-06-17 |
07 | David Kessens | [Ballot Position Update] New position, Yes, has been recorded for David Kessens |
2004-06-17 |
07 | David Kessens | Ballot has been issued by David Kessens |
2004-06-17 |
07 | David Kessens | Created "Approve" ballot |
2004-06-07 |
05 | (System) | New version available: draft-ietf-mboned-embeddedrp-05.txt |
2004-06-03 |
07 | (System) | State has been changed to Waiting for Writeup from In Last Call by system |
2004-06-03 |
07 | Michelle Cotton | Follow-up IANA Comments: It has been confirmed that there are no IANA actions. |
2004-05-21 |
07 | Michelle Cotton | IANA Last Call Comments: There is not mention of IANA. Does this affect the following registries in any way? <http://www.iana.org/assignments/ipv6-multicast-addresses> <http://www.iana.org/assignments/perm-mcast-groupids> … IANA Last Call Comments: There is not mention of IANA. Does this affect the following registries in any way? <http://www.iana.org/assignments/ipv6-multicast-addresses> <http://www.iana.org/assignments/perm-mcast-groupids> We would just like this to be confirmed. |
2004-05-20 |
07 | Amy Vezza | Last call sent |
2004-05-20 |
07 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2004-05-20 |
07 | David Kessens | Last Call was requested by David Kessens |
2004-05-20 |
07 | David Kessens | State Changes to Last Call Requested from Publication Requested by David Kessens |
2004-05-20 |
07 | (System) | Ballot writeup text was added |
2004-05-20 |
07 | (System) | Last call text was added |
2004-05-20 |
07 | (System) | Ballot approval text was added |
2004-05-13 |
07 | Dinara Suleymanova | Draft Added by Dinara Suleymanova |
2004-04-29 |
04 | (System) | New version available: draft-ietf-mboned-embeddedrp-04.txt |
2004-04-21 |
03 | (System) | New version available: draft-ietf-mboned-embeddedrp-03.txt |
2004-03-09 |
02 | (System) | New version available: draft-ietf-mboned-embeddedrp-02.txt |
2004-02-10 |
01 | (System) | New version available: draft-ietf-mboned-embeddedrp-01.txt |
2003-10-09 |
00 | (System) | New version available: draft-ietf-mboned-embeddedrp-00.txt |