Skip to main content

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