draft-ietf-mboned-embeddedrp-01.txt   draft-ietf-mboned-embeddedrp-02.txt 
mboned Working Group P. Savola mboned Working Group P. Savola
Internet Draft CSC/FUNET Internet Draft CSC/FUNET
Expiration Date: August 2004 Expiration Date: September 2004
B. Haberman B. Haberman
Caspian Networks Caspian Networks
February 2004 March 2004
Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address
draft-ietf-mboned-embeddedrp-01.txt draft-ietf-mboned-embeddedrp-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026. of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
To view the list Internet-Draft Shadow Directories, see To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
A very difficult deployment problem with global, interdomain IPv6 This memo defines an address allocation policy in which the address
multicast using Protocol Independent Multicast - Sparse Mode (PIM-SM) of the Rendezvous Point (RP) is encoded in an IPv6 multicast group
has been identified. This memo defines an address allocation policy address. For Protocol Independent Multicast - Sparse Mode (PIM-SM),
in which the address of the Rendezvous Point (RP) is encoded in the this can be seen as a specification of a group-to-RP mapping
IPv6 multicast group address. For PIM-SM, this can be seen as a mechanism. This allows an easy deployment of scalable inter-domain
specification of a group-to-RP mapping mechanism. This allows an multicast, and simplifies the intra-domain multicast configuration as
easy deployment of scalable inter-domain multicast, and simplifies well. This memo updates the addressing format presented in RFC 3306.
the intra-domain multicast configuration as well. This memo updates
the addressing format presented in RFC 3306.
Table of Contents Table of Contents
1. Introduction ............................................... 2 1. Introduction ............................................... 3
1.1. Background ............................................. 3
1.2. Solution ............................................... 3
1.3. Assumptions and Scope .................................. 4
1.4. Keywords ............................................... 4
2. Unicast-Prefix-based Address Format ........................ 4 2. Unicast-Prefix-based Address Format ........................ 4
3. Modified Unicast-Prefix-based Address Format ............... 4 3. Modified Unicast-Prefix-based Address Format ............... 5
4. Embedding the Address of the RP in the Multicast Address ... 5 4. Embedding the Address of the RP in the Multicast Address ... 5
5. Examples ................................................... 6 5. Examples ................................................... 7
5.1. Example 1 .............................................. 6 5.1. Example 1 .............................................. 7
5.2. Example 2 .............................................. 7 5.2. Example 2 .............................................. 7
5.3. Example 3 .............................................. 7 5.3. Example 3 .............................................. 8
5.4. Example 4 .............................................. 7 5.4. Example 4 .............................................. 8
6. Operational Considerations ................................. 7 6. Operational Considerations ................................. 8
6.1. RP Redundancy .......................................... 7 6.1. RP Redundancy .......................................... 8
6.2. RP Deployment .......................................... 8 6.2. RP Deployment .......................................... 8
6.3. Guidelines for Assigning IPv6 Addresses to RPs ......... 8 6.3. Guidelines for Assigning IPv6 Addresses to RPs ......... 9
7. PIM-SM Protocol Modifications .............................. 8 6.4. Use as a Substitute for BSR ............................ 9
7. The Embedded-RP Group-to-RP Mapping Mechanism .............. 9
7.1. PIM-SM Group-to-RP Mapping ............................. 9 7.1. PIM-SM Group-to-RP Mapping ............................. 9
7.2. Overview of the Model .................................. 9 7.2. Overview of the Model .................................. 10
8. Scalability/Usability Analysis ............................. 10 8. Scalability Analysis ....................................... 11
9. Acknowledgements ........................................... 11 9. Acknowledgements ........................................... 12
10. Security Considerations ................................... 11 10. Security Considerations ................................... 12
11. References ................................................ 13 11. References ................................................ 13
11.1. Normative References .................................. 13 11.1. Normative References .................................. 13
11.2. Informative References ................................ 13 11.2. Informative References ................................ 13
Authors' Addresses ............................................. 14 Authors' Addresses ............................................. 14
A. Discussion about Design Tradeoffs .......................... 14 A. Discussion about Design Tradeoffs .......................... 14
B. Changes since -00 .......................................... 15 B. Changes .................................................... 15
Intellectual Property Statement ................................ 15 B.1 Changes since -01 ....................................... 15
B.2 Changes since -00 ....................................... 15
Intellectual Property Statement ................................ 16
Full Copyright Statement ....................................... 16 Full Copyright Statement ....................................... 16
1. Introduction 1. Introduction
1.1. Background
As has been noticed [V6MISSUES], there exists a deployment problem As has been noticed [V6MISSUES], there exists a deployment problem
with global, interdomain IPv6 multicast: PIM-SM [PIM-SM] RPs have no with global, interdomain IPv6 multicast: PIM-SM [PIM-SM] RPs have no
way of communicating the information about multicast sources to other way of communicating the information about (active) multicast sources
multicast domains, as there is no Multicast Source Discovery Protocol to other multicast domains, as Multicast Source Discovery Protocol
(MSDP) [MSDP] (at least yet). Therefore the whole interdomain Any (MSDP) [MSDP] has not been, on purpose, specified for IPv6.
Source Multicast model is rendered unusable; Source-Specific Therefore the whole interdomain Any Source Multicast model is
Multicast (SSM) [SSM] avoids these problems but is not a complete rendered unusable; Source-Specific Multicast (SSM) [SSM] avoids these
solution for several reasons. problems but is not a complete solution for several reasons.
Further, it has been noted that there are some problems with the Further, it has been noted that there are some problems with the
support and deployment of mechanisms SSM would require: it seems support and deployment of mechanisms SSM would require [V6MISSUES]:
unlikely that SSM could be usable as the only interdomain multicast it seems unlikely that SSM could be usable as the only interdomain
routing mechanism in the short term. multicast routing mechanism in the short term.
1.2. Solution
This memo describes a multicast address allocation policy in which This memo describes a multicast address allocation policy in which
the address of the RP is encoded in the IPv6 multicast group address, the address of the RP is encoded in the IPv6 multicast group address,
and specifies a PIM-SM group-to-RP mapping to use the encoding, and specifies a PIM-SM group-to-RP mapping to use the encoding,
leveraging and extending the unicast-prefix -based addressing leveraging and extending unicast-prefix -based addressing [RFC3306].
[RFC3306].
This mechanism not only provides a simple solution for IPv6 This mechanism not only provides a simple solution for IPv6
interdomain Any Source Multicast (ASM) but can be used as a simple interdomain Any Source Multicast (ASM) but can be used as a simple
solution for IPv6 intradomain ASM on scoped addresses as well. It solution for IPv6 intradomain ASM with scoped multicast addresses as
can also be used in those deployment scenarios which would have well. It can also be used as an automatic RP discovery mechanism in
previously used the Bootstrap Router protocol (BSR) [BSR]. those deployment scenarios which would have previously used the
Bootstrap Router protocol (BSR) [BSR].
The solution consists of three elements: The solution consists of three elements:
o A specification of a subrange of [RFC3306] IPv6 multicast group o A specification of a subrange of [RFC3306] IPv6 multicast group
addresses defined by setting one previously unused bit of the addresses defined by setting one previously unused bit of the
Flags field to "1", Flags field to "1",
o A specification of the mapping by which such a group address o A specification of the mapping by which such a group address
encodes the RP address that is to be used with this group, and encodes the RP address that is to be used with this group, and
o A specification of optional and mandatory procedures to operate o A description of operational procedures to operate ASM with PIM-
ASM with PIM-SM on these IPv6 multicast groups. SM on these IPv6 multicast groups.
Addresses in the subrange will be called embedded RP addresses. This Addresses in the subrange will be called embedded-RP addresses.
scheme obviates the need for inter-domain MSDP, and the routers are
not required to include any multicast configuration, except when they This scheme obviates the need for MSDP, and the routers are not
act as an RP. required to include any multicast configuration, except when they act
as an RP.
This memo updates the addressing format presented in RFC 3306.
1.3. Assumptions and Scope
In general, a 128-bit RP address can't be embedded into a 128-bit In general, a 128-bit RP address can't be embedded into a 128-bit
group address with space left to carry the group identity itself. An group address with space left to carry the group identity itself. An
appropriate form of encoding is thus defined, and it is assumed that appropriate form of encoding is thus defined by requiring that the
the Interface-ID of RPs in the embedded RP range can be assigned to Interface-IDs of RPs in the embedded-RP range can be assigned to be a
be a specific value. specific value.
If these assumptions can't be followed, either operational procedures If these assumptions can't be followed, either operational procedures
and configuration must be slightly changed or this mechanism can not and configuration must be slightly changed or this mechanism can not
be used. be used.
The assignment of multicast addresses is outside the scope of this The assignment of multicast addresses is outside the scope of this
document; it is up to the RP and applications to ensure that group document; it is up to the RP and applications to ensure that group
addresses are unique using some unspecified method. However, the addresses are unique using some unspecified method. However, the
mechanisms are very probably similar to ones used with [RFC3306]. mechanisms are very probably similar to ones used with [RFC3306].
Similarly, RP failure management methods, such as Anycast-RP, are out Similarly, RP failure management methods, such as Anycast-RP, are out
of scope for this document. These do not work without additional of scope for this document. These do not work without additional
specification or deployment. This is covered briefly in Section 6.1. specification or deployment. This is covered briefly in Section 6.1.
This memo updates the addressing format presented in RFC 3306. 1.4. Keywords
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Unicast-Prefix-based Address Format 2. Unicast-Prefix-based Address Format
As described in [RFC3306], the multicast address format is as As described in [RFC3306], the multicast address format is as
follows: follows:
| 8 | 4 | 4 | 8 | 8 | 64 | 32 | | 8 | 4 | 4 | 8 | 8 | 64 | 32 |
+--------+----+----+--------+--------+----------------+----------+ +--------+----+----+--------+--------+----------------+----------+
|11111111|flgs|scop|reserved| plen | network prefix | group ID | |11111111|flgs|scop|reserved| plen | network prefix | group ID |
+--------+----+----+--------+--------+----------------+----------+ +--------+----+----+--------+--------+----------------+----------+
Where flgs are "0011". (The first two bits are yet undefined, sent Where flgs are "0011". (The first two bits have been yet undefined,
as zero and ignored on receipt.) sent as zero and ignored on receipt.)
3. Modified Unicast-Prefix-based Address Format 3. Modified Unicast-Prefix-based Address Format
This memo specifies a modification to the unicast-prefix-based This memo specifies a modification to the unicast-prefix-based
address format: address format:
1. If the second high-order bit in "flgs" is set to 1, the address 1. If the second high-order bit in "flgs" is set to 1, the address
of the RP is embedded in the multicast address, as described in of the RP is embedded in the multicast address, as described in
this memo. this memo.
2. If the second high-order bit in "flgs" is set to 1, interpret 2. If the second high-order bit in "flgs" is set to 1, interpret
the last low-order 4 bits of "reserved" field as signifying the the last low-order 4 bits of "reserved" field as signifying the
RP interface ID, as described in this memo. RP interface ID ("RIID"), as described in this memo.
In consequence, the address format becomes: In consequence, the address format becomes:
| 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 | | 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 |
+--------+----+----+----+----+--------+----------------+----------+ +--------+----+----+----+----+--------+----------------+----------+
|11111111|flgs|scop|rsvd|RIID| plen | network prefix | group ID | |11111111|flgs|scop|rsvd|RIID| plen | network prefix | group ID |
+--------+----+----+----+----+--------+----------------+----------+ +--------+----+----+----+----+--------+----------------+----------+
+-+-+-+-+ +-+-+-+-+
flgs is a set of 4 flags: |0|R|P|T| flgs is a set of 4 flags: |0|R|P|T|
+-+-+-+-+ +-+-+-+-+
R = 1 indicates a multicast address that embeds the address on the 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 RP. Then P MUST be set to 1, and consequently T MUST be set to 1, as
specified in [RFC3306]. specified in [RFC3306].
In the case that R = 1, the last 4 bits of the previously reserved In the case that R = 1, the last 4 bits of the previously reserved
field are interpreted as embedding the RP interface ID ("RIID"), as field are interpreted as embedding the RP interface ID, as specified
specified in this memo. in this memo.
R = 0 indicates a multicast address that does not embed the address R = 0 indicates a multicast address that does not embed the address
of the RP and follows the semantics defined in [ADDRARCH] and of the RP and follows the semantics defined in [ADDRARCH] and
[RFC3306]. In this context, the value of "RIID" MUST be as zero and [RFC3306]. In this context, the value of "RIID" MUST be sent as zero
MUST be ignored on receipt. and MUST be ignored on receipt.
4. Embedding the Address of the RP in the Multicast Address 4. Embedding the Address of the RP in the Multicast Address
The address of the RP can only be embedded in unicast-prefix -based The address of the RP can only be embedded in unicast-prefix -based
ASM addresses. ASM addresses.
To identify whether an address is a multicast address as specified in That is, to identify whether an address is a multicast address as
this memo and to be processed any further, it must satisfy all of the specified in this memo and to be processed any further, it must
below: satisfy all of the below:
o it MUST be a multicast address and have R, P, and T flag bits set o it MUST be a multicast address and have R, P, and T flag bits set
to 1 (that is, be part of the prefixes FF70::/12 or FFF0::/12), to 1 (that is, be part of the prefixes FF70::/12 or FFF0::/12),
o "plen" MUST NOT be 0 (ie. not SSM), and o "plen" MUST NOT be 0 (ie. not SSM), and
o "plen" MUST NOT be greater than 64. o "plen" MUST NOT be greater than 64.
The address of the RP can be obtained from a multicast address The address of the RP can be obtained from a multicast address
satisfying the above criteria by taking the two steps: satisfying the above criteria by taking the two steps:
skipping to change at page 6, line 4 skipping to change at page 6, line 35
|| \\ vvvvvvvvvvv || \\ vvvvvvvvvvv
|| ``====> copy plen bits of "network prefix" || ``====> copy plen bits of "network prefix"
|| +------------+------------------------+ || +------------+------------------------+
|| | network pre| 0000000000000000000000 | || | network pre| 0000000000000000000000 |
|| +------------+------------------------+ || +------------+------------------------+
\\ \\
``=================> copy RIID to the last 4 bits ``=================> copy RIID to the last 4 bits
+------------+---------------------+--+ +------------+---------------------+--+
| network pre| 0000000000000000000 |ID| | network pre| 0000000000000000000 |ID|
+------------+---------------------+--+ +------------+---------------------+--+
One should note that there are several operational scenarios (see One should note that there are several operational scenarios (see
Example 2 below) when [RFC3306] statement "all non-significant bits Example 2 below) when [RFC3306] statement "all non-significant bits
of the network prefix field SHOULD be zero" is ignored. This is to of the network prefix field SHOULD be zero" is ignored. This is to
allow multicast address assignments to third parties which still use allow multicast group address allocations to be consistent with
the RP associated with the network prefix. unicast prefixes, while the multicast addresses would still use the
RP associated with the network prefix.
"plen" higher than 64 MUST NOT be used as that would overlap with the "plen" higher than 64 MUST NOT be used as that would overlap with the
upper bits of multicast group-id. high-order bits of multicast group-id.
When processing an encoding to get the RP address, the multicast When processing an encoding to get the RP address, the multicast
routers MUST perform at least the same address validity checks to the routers MUST perform at least the same address validity checks to the
calculated RP address as to one received via other means (like BSR calculated RP address as to one received via other means (like BSR
[BSR] or MSDP for IPv4), to avoid e.g., the address being "::", [BSR] or MSDP for IPv4). At least fe80::/10, ::/16, and ff00::/8
"::1", or a link-local address. MUST be excluded. This is particularly important as the information
is obtained from an untrusted source, i.e., any Internet user's
input.
One should note that the 4 bits reserved for "RIID" set the upper One should note that the 4 bits reserved for "RIID" set the upper
bound for RPs for the combination of scope, network prefix, and group bound for RPs for the combination of scope, network prefix, and group
ID -- without varying any of these, you can have 4 bits worth of ID -- without varying any of these, you can have 4 bits worth of
different RPs. However, each of these is an IPv6 group address of different RPs. However, each of these is an IPv6 group address of
its own (i.e., there can be only one RP per multicast address). its own (i.e., there can be only one RP per multicast address).
5. Examples 5. Examples
Four examples of multicast address allocation and resulting group-to- Four examples of multicast address allocation and resulting group-to-
RP mappings are described here, to better illustrate the RP mappings are described here, to better illustrate the
possibilities provided by the encoding. possibilities provided by the encoding.
5.1. Example 1 5.1. Example 1
The network administrator of 2001:DB8::/32 wants to set up an RP for The network administrator of 2001:DB8::/32 wants to set up an RP for
the network and all of his customers. (S)he chooses network the network and all the customers. (S)he chooses network
prefix=2001:DB8 and plen=32, and wants to use this addressing prefix=2001:DB8 and plen=32, and wants to use this addressing
mechanism. The multicast addresses (s)he will be able to use are of mechanism. The multicast addresses (s)he will be able to use are of
the form: the form:
FF7x:y20:2001:DB8:zzzz:zzzz:<group-id> FF7x:y20:2001:DB8:zzzz:zzzz:<group-id>
Where "x" is the multicast scope, "y" the interface ID of the RP Where "x" is the multicast scope, "y" the interface ID of the RP
address, and "zzzz:zzzz" will be freely assignable within the PIM-SM address, and "zzzz:zzzz" will be freely assignable to anyone. In this
domain. In this case, the address of the PIM-SM RP would be: case, the address of the RP would be:
2001:DB8::y 2001:DB8::y
(and "y" could be anything from 0 to F); the address 2001:DB8::y/128 (and "y" could be anything from 1 to F, as 0 must not be used); the
is added as a Loopback address and injected to the routing system. address 2001:DB8::y/128 is added on a router as a loopback address
and injected to the routing system.
5.2. Example 2 5.2. Example 2
As in Example 1, the network administrator can also allocate As in Example 1, the network administrator can also allocate
multicast addresses like "FF7x:y20:2001:DB8:DEAD::/80" to some of his multicast addresses like "FF7x:y20:2001:DB8:DEAD::/80" to some of
customers within the PIM-SM domain. In this case the RP address customers. In this case the RP address would still be "2001:DB8::y".
would still be "2001:DB8::y".
Note the second rule of deriving the RP address: the "plen" field in Note the second rule of deriving the RP address: the "plen" field in
the multicast address, 0x20 = 32, refers to the length of "network the multicast address, 0x20 = 32, refers to the length of "network
prefix" field considered when obtaining the RP address. In this prefix" field considered when obtaining the RP address. In this
case, only the first 32 bits of the network prefix field, "2001:DB8" case, only the first 32 bits of the network prefix field, "2001:DB8"
are preserved: the value of "plen" takes no stance on actual are preserved: the value of "plen" takes no stance on actual
unicast/multicast prefix lengths allocated or used in the networks, unicast/multicast prefix lengths allocated or used in the networks,
here from 2001:DB8:DEAD::/48. here from 2001:DB8:DEAD::/48.
In short, this distinction allows more flexible RP address
configuration in the scenarios where it is desirable to have the
group addresses to be consistent with the unicast prefix allocations.
5.3. Example 3 5.3. Example 3
In the network of Examples 1 and 2, the network admin sets up In the network of Examples 1 and 2, the network admin sets up
addresses for use by their customers, but an organization wants to addresses for use by their customers, but an organization wants to
have their own PIM-SM domain; that's reasonable. The organization have their own PIM-SM domain. The organization can pick multicast
can pick multicast addresses like "FF7x:y30:2001:DB8:BEEF::/80", and addresses like "FF7x:y30:2001:DB8:BEEF::/80", and then their RP
then their RP address would be "2001:DB8:BEEF::y". address would be "2001:DB8:BEEF::y".
5.4. Example 4 5.4. Example 4
In the above networks, if the admin wants to specify the RP to be in In the above networks, if the administrator wants to specify the RP
a non-zero /64 subnet, (s)he could always use something like to be in a non-zero /64 subnet, (s)he could always use something like
"FF7x:y40:2001:DB8:BEEF:FEED::/96", and then their RP address would "FF7x:y40:2001:DB8:BEEF:FEED::/96", and then their RP address would
be "2001:DB8:BEEF:FEED::y". There are still 32 bits of multicast be "2001:DB8:BEEF:FEED::y". There are still 32 bits of multicast
group-id's to assign to customers and self. group-id's to assign to customers and self.
6. Operational Considerations 6. Operational Considerations
This desction describes the major operational considerations for This desction describes the major operational considerations for
those deploying this mechanism. those deploying this mechanism.
6.1. RP Redundancy 6.1. RP Redundancy
A technique called "Anycast RP" is used within a PIM-SM domain to A technique called "Anycast RP" is used within a PIM-SM domain to
share an address and multicast state information between a set of share an address and multicast state information between a set of
RP's mainly for redundancy purposes. Typically, MSDP has been used RP's mainly for redundancy purposes. Typically, MSDP has been used
for that as well [ANYCASTRP]. There are also other approaches, like for that as well [ANYCASTRP]. There are also other approaches, like
using PIM for sharing this information [ANYPIMRP]. using PIM for sharing this information [ANYPIMRP].
RP failover cannot be used with this specification without additional RP failover cannot be used with this specification without additional
mechanisms or techniques such as MSDP, PIM-SM extensions, or mechanisms or techniques such as MSDP, PIM-SM extensions, or
anycasting the RP address in the IGP without state sharing (depending "anycasting" (i.e., the shared-unicast model [ANYCAST]) the RP
on the redundancy requirements, this may or may not be enough, address in the IGP without state sharing (depending on the redundancy
though). However, the redundancy mechanisms are outside of the scope requirements, this may or may not be enough, though). However, the
of this memo. redundancy mechanisms are outside of the scope of this memo.
6.2. RP Deployment 6.2. RP Deployment
As there is no need to share inter-domain state with MSDP, each DR As there is no need to share inter-domain state with MSDP, each DR
connecting multicast sources could act as an RP without scalability connecting multicast sources could act as an RP without scalability
concerns about MSDP sessions. concerns about setting up and maintaining MSDP sessions.
This might be particularly attractive when concerned about RP This might be particularly attractive when concerned about RP
redundancy. In the case where the DR close to a major source for a redundancy. In the case where the DR close to a major source for a
group acts as the RP, a certain amount of fate-sharing properties can group acts as the RP, a certain amount of fate-sharing properties can
be obtained without using any RP failover mechanisms: if the DR goes be obtained without using any RP failover mechanisms: if the DR goes
down, the multicast transmission may not be all that interesting down, the multicast transmission may not work anymore in any case.
anymore in any case.
Along the same lines, it's may also be desirable to distribute the RP Along the same lines, it's may also be desirable to distribute the RP
responsibilities to multiple RPs. As long as different RPs serve responsibilities to multiple RPs. As long as different RPs serve
different groups, this is is trivial: each group should map to a different groups, this is is trivial: each group could map to a
different RP (or enough many different RPs that the load on one RP is different RP (or sufficiently many different RPs that the load on one
not a problem). However, load sharing one group faces the similar RP is not a problem). However, load sharing one group faces the
challenges as Anycast-RP. similar challenges as Anycast-RP.
6.3. Guidelines for Assigning IPv6 Addresses to RPs 6.3. Guidelines for Assigning IPv6 Addresses to RPs
With this mechanism, the RP can be given basically any network prefix With this mechanism, the RP can be given basically any network prefix
up to /64. The interface identifier will have to be manually up to /64. The interface identifier will have to be manually
configured to match "RIID". configured to match "RIID".
RIID = 0 SHOULD NOT be used as using it would cause ambiguity with RIID = 0 must not be used as using it would cause ambiguity with the
the Subnet-Router Anycast Address [ADDRARCH]. Subnet-Router Anycast Address [ADDRARCH].
If an administrator wishes to use an RP address that does not conform If an administrator wishes to use an RP address that does not conform
to the addressing topology but is still from the network provider's to the addressing topology but is still from the network provider's
prefix (e.g., an additional loopback address assigned on a router), prefix (e.g., an additional loopback address assigned on a router, as
that address can be injected into the routing system via a host described in example 1 in Section 5.1), that address can be injected
route. into the routing system via a host route.
7. PIM-SM Protocol Modifications 6.4. Use as a Substitute for BSR
This section describes how PIM-SM is modified, i.e., how the group- With embedded-RP, use of BSR or other RP configuration mechanisms
to-RP mapping mechanism works for Embedded RP. throughout the PIM domain is not necessary, as each group address
specifies the RP to be used.
7. The Embedded-RP Group-to-RP Mapping Mechanism
This section specifies the group-to-RP mapping mechanism works for
Embedded RP.
7.1. PIM-SM Group-to-RP Mapping 7.1. PIM-SM Group-to-RP Mapping
The only PIM-SM modification required is implementing this mechanism The only PIM-SM modification required is implementing this mechanism
as one group-to-RP mapping method. as one group-to-RP mapping method.
The implementation will have to recognize the address format and The implementation will have to recognize the address format and
derive and use the RP address using the rules in Section 4. This derive and use the RP address using the rules in Section 4. This
information is used at least when performing RPF lookups and when information is used at least when performing Reverse Path Forwarding
processing Join/Prune messages, or performing Register-encapsulation. (RPF) lookups, when processing Join/Prune messages, or performing
Register-encapsulation.
To avoid loops and inconsistancies, the group-to-RP mapping specified To avoid loops and inconsistancies, the group-to-RP mapping specified
in this memo MUST be used for all embedded RP groups (i.e., with in this memo MUST be used for all embedded-RP groups (i.e., addresses
prefix FF70::/12 or FFF0::/12). with prefix FF70::/12 or FFF0::/12).
It is worth noting that compared to the other group-to-RP mappings, It is worth noting that compared to the other group-to-RP mapping
which can be precomputed, the embedded RP mapping must be redone for mechanisms, which can be precomputed, the embedded-RP mapping must be
every new IPv6 group address which would map to a different RP. For redone for every new IPv6 group address which would map to a
efficiency, the results may be cached in an implementation-specific different RP. For efficiency, the results may be cached in an
manner. implementation-specific manner, to avoid computation for every
embedded-RP packet.
This group-to-RP mapping mechanism must be supported by the DR This group-to-RP mapping mechanism must be supported by the DR
adjacent to senders and any router on the path from any receiver to adjacent to the senders and any router on the path from any receiver
the RP. It also must be supported by any router on the path from any to the RP. Further, as the switch-over to Shortest Path Tree (SPT)
sender to the RP -- in case the RP issues a Register-Stop and Joins is also possible, it must be supported on the path between the
the sources. receivers and the senders as well. It also must be supported by any
router on the path from any sender to the RP -- in case the RP issues
It should be noted that this approach removes the need to run inter- a Register-Stop and Joins the sources. So, in practice, the
domain MSDP. Multicast distribution trees in foreign networks can be mechanism must be supported by all routers on any path between the
joined by issuing a PIM-SM Join/Prune/Register to the RP address RP, receivers, and senders.
encoded in the multicast address.
Also, the addressing model described here could be used to replace or
augment the intra-domain Bootstrap Router mechanism (BSR), as the RP-
mappings can be derived from the application of multicast address
assignmen policies.
7.2. Overview of the Model 7.2. Overview of the Model
This section gives a high level, non-normative overview of how This section gives a high-level, non-normative overview of how
Embedded RP operates, as specified in the previous section. Embedded RP operates, as specified in the previous section.
The steps when a receiver wishes to join a group are: The steps when a receiver wishes to join a group are:
1. A receiver finds out a group address from some means (e.g., SDR 1. A receiver finds out a group address from some means (e.g., SDR
or a web page). or a web page).
2. The receiver issues an MLD Report, joining the group. 2. The receiver issues an MLD Report, joining the group.
3. The receiver's DR will initiate the PIM-SM Join process towards 3. The receiver's DR will initiate the PIM-SM Join process towards
the RP embedded in the multicast address. the RP encoded in the multicast address, irrespective of
whether it is in the "local" or "remote" PIM domain.
The steps when a sender wishes to send to a group are: The steps when a sender wishes to send to a group are:
1. A sender finds out a group address from some means, whether in 1. A sender finds out a group address using an unspecified method
an existing group (e.g., SDR, web page) or in a new group (e.g, by contacting the administrator for group assignment or
(e.g., a call to the administrator for group assignment, use of using a multicast address assignment protocol).
a multicast address assignment protocol).
2. The sender sends to the group. 2. The sender sends to the group.
3. The sender's DR will send the packets unicast-encapsulated in 3. The sender's DR will send the packets unicast-encapsulated in
PIM-SM Register-messages to the RP address encoded in the PIM-SM Register-messages to the RP address encoded in the
multicast address (in the special case that DR is the RP, such multicast address (in the special case that DR is the RP, such
sending is only conceptual). sending is only conceptual).
In fact, all the messages go as specified in [PIM-SM] -- embedded RP In fact, all the messages go as specified in [PIM-SM] -- embedded-RP
just acts as a group-to-RP mapping mechanism; instead of obtaining just acts as a group-to-RP mapping mechanism; instead of obtaining
the address of the RP from local configuration or configuration the address of the RP from local configuration or configuration
protocols (e.g., BSR), it is derived transparently from the encoded protocols (e.g., BSR), it is derived transparently from the encoded
multicast address. multicast address.
8. Scalability/Usability Analysis 8. Scalability Analysis
Interdomain MSDP model for connecting PIM-SM domains is mostly Interdomain MSDP model for connecting PIM-SM domains is mostly
hierarchical in configuration and deployment, but flat with regard to hierarchical in configuration and deployment, but flat with regard to
information distribution. The embedded RP inter-domain model behaves information distribution. The embedded-RP inter-domain model behaves
as if all of the Internet was a single PIM domain, with just one RP as if all of the Internet was a single PIM domain, with just one RP
per group. So, the inter-domain multicast becomes a flat, RP- per group. So, the inter-domain multicast becomes a flat, RP-
centered topology. The scaling issues are be described below. centered topology. The scaling issues are described below.
Previously foreign sources sent the unicast-encapsulated data to Previously foreign sources sent the unicast-encapsulated data to
their local RP, now they do so to the foreign RP responsible for the their local RP, now they do so to the foreign RP "responsible" for
specific group. This is especially important with large multicast the specific group (i.e., the prefix where the group address was
derived from). This is especially important with large multicast
groups where there are a lot of heavy senders -- particularly if groups where there are a lot of heavy senders -- particularly if
implementations do not handle unicast-decapsulation well. implementations do not handle unicast-decapsulation well.
This model increases the amount of Internet-wide multicast state This model increases the amount of Internet-wide multicast state
slightly: the backbone routers might end up with (*, G) and (S, G, slightly: the backbone routers might end up with (*, G) and (S, G,
rpt) state between receivers (and past receivers, for PIM Prunes) and rpt) state between receivers (and past receivers, for PIM Prunes) and
the RP, in addition to (S, G) states between the receivers and the RP, in addition to (S, G) states between the receivers and
senders. Certainly, the amount of inter-domain multicast traffic senders, if SPT is used. However, the traditional ASM model also
between sources and the embedded RP will increase compared to the ASM requires MSDP state to propagate everywhere in inter-domain, so the
model with MSDP. total amount of state is smaller.
The embedded RP model is practically identical in both inter-domain The embedded-RP model is practically identical in both inter-domain
and intra-domain cases to the traditional PIM-SM in intra-domain. On and intra-domain cases to the traditional PIM-SM in intra-domain. On
the other hand, PIM-SM has been deployed (in IPv4) in inter-domain the other hand, PIM-SM has been deployed (in IPv4) in inter-domain
using MSDP; compared to that inter-domain model, this specification using MSDP; compared to that inter-domain model, this specification
simplifies the multicast routing by removing the RP for senders and simplifies the multicast routing by removing the RP for senders and
receivers in foreign domains. receivers in foreign domains, and eliminating the MSDP information
distribution.
As the address of the RP is tied to the multicast address, the RP As the address of the RP is tied to the multicast address, the RP
failure management becomes more difficult, as failover or redundancy failure management becomes more difficult, as failover or redundancy
mechanisms (e.g., BSR, Anycast-RP with MSDP) cannot be used as-is. mechanisms (e.g., BSR, Anycast-RP with MSDP) cannot be used as-is.
This described briefly in Section 6.1. On the other hand, Anycast-RP using PIM could be used. This
described briefly in Section 6.1.
The PIM-SM specification states, "Any RP address configured or The PIM-SM specification states, "Any RP address configured or
learned MUST be a domain-wide reachable address". What "reachable" learned MUST be a domain-wide reachable address". What "reachable"
precisely means is not clear, even without embedded RP. This precisely means is not clear, even without embedded-RP. This
statement cannot be proven especially with the foreign RPs (one can statement cannot be proven especially with the foreign RPs as one can
not even guarantee that the RP exists!). Instead of configuring RPs not even guarantee that the RP exists. Instead of configuring RPs
and DRs with a manual process (configuring a non-existent RP was and DRs with a manual process (configuring a non-existent RP was
possible though rare), with this specification the hosts and users possible though rare), with this specification the hosts and users
using multicast indirectly specify the RP themselves, lowering the using multicast indirectly specify the RP themselves, lowering the
expectancy of the RP reachability. expectancy of the RP reachability. This is a relatively significant
problem but not much different from the current multicast deployment:
e.g., MLDv2 (S,G) joins, whether ASM or SSM, yield the same result
[PIMSEC].
Being able to join/send to remote RPs raises security concerns that Being able to join/send to remote RPs raises security concerns that
are considered separately, but it has an advantage too: every group are considered separately, but it has an advantage too: every group
has a "home RP" which is able to control (to some extent) who are has a "responsible RP" which is able to control (to some extent) who
able to send to the group. are able to send to the group.
A more extensive description and comparison of the inter-domain A more extensive description and comparison of the inter-domain
multicast routing models (traditional ASM with MSDP, embedded RP, multicast routing models (traditional ASM with MSDP, embedded-RP,
SSM) and their security properties has been described in [PIMSEC]. SSM) and their security properties has been described in [PIMSEC].
9. Acknowledgements 9. Acknowledgements
Jerome Durand commented on an early draft of this memo. Marshall Jerome Durand commented on an early draft of this memo. Marshall
Eubanks noted an issue regarding short plen values. Tom Pusateri Eubanks noted an issue regarding short plen values. Tom Pusateri
noted problems with earlier SPT-join approach. Rami Lehtonen pointed noted problems with an earlier SPT-join approach. Rami Lehtonen
out issues with the scope of SA-state and provided extensive pointed out issues with the scope of SA-state and provided extensive
commentary. Nidhi Bhaskar gave the draft a thorough review. commentary. Nidhi Bhaskar gave the draft a thorough review.
Toerless Eckert, Hugh Holbrook, and Dave Meyer provided very Toerless Eckert, Hugh Holbrook, and Dave Meyer provided very
extensive feedback. The whole MboneD working group is also extensive feedback. The whole MboneD working group is also
acknowledged for the continued support and comments. acknowledged for the continued support and comments.
10. Security Considerations 10. Security Considerations
The address of the RP is encoded in the multicast address. RPs may The address of the RP is encoded in the multicast address -- and thus
be a good target for Denial of Service attacks -- as they are a become more visible as single points of failure. Even though this
single point of failure (excluding failover techniques) for a group. does not significantly affect the multicast routing security, it may
In this way, the target would be clearly visible. However, it could expose the RP to other kinds of attacks. The operators are
be argued that if interdomain multicast was to be made to work e.g., encouraged to pay special attention to securing these routers. See
with MSDP, the address would have to be visible anyway (through via Section 6.1 on considerations regarding failover and Section 6.2 on
other channels). placement of RPs leading to a degree of fate-sharing properties.
As any RP will have to accept PIM-SM Join/Prune/Register messages As any RP will have to accept PIM-SM Join/Prune/Register messages
from any DR, this might cause a potential DoS attack scenario. from any DR, this might cause a potential DoS attack scenario.
However, this can be mitigated by the fact that the RP can discard However, this can be mitigated by the fact that the RP can discard
all such messages for all multicast addresses that do not encode the all such messages for all multicast addresses that do not encode the
address of the RP, and if deemed important, the implementation could address of the RP. The implementation MAY also allow manual
also allow manual configuration of which multicast addresses or configuration of which multicast addresses or prefixes embedding the
prefixes embedding the RP could be used, so that only the pre-agreed RP could be used.
sources could use the RP.
In a similar fashion, when a receiver joins to an RP, the DRs must In a similar fashion, when a receiver joins to an RP, the DRs must
accept similar PIM-SM messages back from RPs. accept similar PIM-SM messages back from RPs. However, this is not a
considerable threat.
One consequence of the embedded RP usage model is that it allows
Internet-wide multicast state creation (from receiver(s) in another
domain to the RP in another domain) compared to the domain wide state
creation in the traditional ASM model. However, the traditional ASM
model also requires MSDP state to propagate everywhere in inter-
domain, so the total amount of state is smaller.
One should observe that the embedded RP threat model is actually
pretty similar to SSM; both mechanisms significantly reduce the
threats at the sender side, but have new ones in the receiver side,
as any receiver can try to join any non-existent group or channel,
and the local DR or RP cannot readily reject (e.g., based on MSDP
information) such joins.
RPs become single points of failure as anycast-RP mechanism is not One should observe that the embedded-RP threat model is actually
(at least immediately) available. However, some other forms of rather similar to SSM; both mechanisms significantly reduce the
failover are still possible (see Section 6.1) and one can obtain some threats at the sender side. On the receiver side, the threats are
forms of fate-sharing properties with a proper placement of RPs (see somewhat comparable, as an attacker could do an MLDv2 (S,G) join
Section 6.2). towards a non-existent source, which the local RP could not block
based on the MSDP information.
The implementation MUST perform at least the same address validity The implementation MUST perform at least the same address validity
checks to the embedded RP address as to one received via other means checks to the embedded-RP address as to one received via other means;
(like BSR or MSDP), to avoid the address being e.g., "::", "::1", or at least fe80::/10, ::/16, and ff00::/8 should be excluded. This is
a link-local address. particularly important as the information is derived from the
untrusted source (i.e., any user in the Internet), not from the local
configuration.
A more extensive description and comparison of the inter-domain A more extensive description and comparison of the inter-domain
multicast routing models (traditional ASM with MSDP, embedded RP, multicast routing models (traditional ASM with MSDP, embedded-RP,
SSM) and their security properties has been described in [PIMSEC]. SSM) and their security properties has been done separately in
[PIMSEC].
11. References 11. References
11.1. Normative References 11.1. Normative References
[ADDRARCH] Hinden, R., Deering, S., "IP Version 6 Addressing [ADDRARCH] Hinden, R., Deering, S., "IP Version 6 Addressing
Architecture", RFC3513, April 2003. Architecture", RFC3513, April 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3306] Haberman, B., Thaler, D., "Unicast-Prefix-based IPv6 [RFC3306] Haberman, B., Thaler, D., "Unicast-Prefix-based IPv6
Multicast Addresses", RFC3306, August 2002. Multicast Addresses", RFC3306, August 2002.
11.2. Informative References 11.2. Informative References
[ANYCAST] Hagino, J., Ettikan, K., "An analysis of IPv6
anycast", work-in-progress,
draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt, June 2003.
[ANYCASTRP] Kim, D. et al, "Anycast RP mechanism using PIM and [ANYCASTRP] Kim, D. et al, "Anycast RP mechanism using PIM and
MSDP", RFC 3446, January 2003. MSDP", RFC 3446, January 2003.
[ANYPIMRP] Farinacci, D., Cai, Y., "Anycast-RP using PIM", [ANYPIMRP] Farinacci, D., Cai, Y., "Anycast-RP using PIM",
work-in-progress, draft-ietf-pim-anycast-rp-00.txt, work-in-progress, draft-ietf-pim-anycast-rp-00.txt,
November 2003. November 2003.
[BSR] Fenner, B., et al., "Bootstrap Router (BSR) Mechanism for [BSR] Fenner, B., et al., "Bootstrap Router (BSR) Mechanism for
PIM Sparse Mode", work-in-progress, draft-ietf-pim-sm- PIM Sparse Mode", work-in-progress, draft-ietf-pim-sm-
bsr-03.txt, February 2003. bsr-03.txt, February 2003.
skipping to change at page 13, line 41 skipping to change at page 14, line 15
[MSDP] Meyer, D., Fenner, B, (Eds.), "Multicast Source [MSDP] Meyer, D., Fenner, B, (Eds.), "Multicast Source
Discovery Protocol (MSDP)", RFC 3618, October 2003. Discovery Protocol (MSDP)", RFC 3618, October 2003.
[PIMSEC] Savola, P., Lehtonen, R., Meyer, D., "PIM-SM Multicast [PIMSEC] Savola, P., Lehtonen, R., Meyer, D., "PIM-SM Multicast
Routing Security Issues and Enhancements", Routing Security Issues and Enhancements",
work-in-progress, draft-savola-mboned-mroutesec-00.txt, work-in-progress, draft-savola-mboned-mroutesec-00.txt,
January 2004. January 2004.
[PIM-SM] Fenner, B. et al, "Protocol Independent Multicast - [PIM-SM] Fenner, B. et al, "Protocol Independent Multicast -
Sparse Mode (PIM-SM): Protocol Specification (Revised), Sparse Mode (PIM-SM): Protocol Specification (Revised),
work-in-progress, draft-ietf-pim-sm-v2-new-08.txt, work-in-progress, draft-ietf-pim-sm-v2-new-09.txt,
October 2003. February 2004.
[SSM] Holbrook, H. et al, "Source-Specific Multicast for IP", [SSM] Holbrook, H. et al, "Source-Specific Multicast for IP",
work-in-progress, draft-ietf-ssm-arch-04.txt, work-in-progress, draft-ietf-ssm-arch-04.txt,
October 2003. October 2003.
[V6MISSUES] Savola, P., "IPv6 Multicast Deployment Issues", [V6MISSUES] Savola, P., "IPv6 Multicast Deployment Issues",
work-in-progress, draft-savola-v6ops-multicast- work-in-progress, draft-savola-v6ops-multicast-
issues-02.txt, October 2003. issues-03.txt, February 2004.
Authors' Addresses Authors' Addresses
Pekka Savola Pekka Savola
CSC/FUNET CSC/FUNET
Espoo, Finland Espoo, Finland
EMail: psavola@funet.fi EMail: psavola@funet.fi
Brian Haberman Brian Haberman
Caspian Networks Caspian Networks
One Park Drive, Suite 300 One Park Drive, Suite 300
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
EMail: brian@innovationslab.net EMail: brian@innovationslab.net
Phone: +1-919-949-4828 Phone: +1-919-949-4828
A. Discussion about Design Tradeoffs A. Discussion about Design Tradeoffs
One could argue that there should be more RPs than the 4-bit "RIID" It has been argued that instead of allowing the operator to specify
allows for, especially if anycast-RP cannot be used. In that light, RIID, the value could be pre-determined (e.g., "1"). However, this
extending "RIID" to take full advantage of whole 8 bits would seem has not been adopted, as this eliminates address assignment
reasonable. However, this would use up all of the reserved bits, and flexibility from the operator.
leave no room for future flexibility. In case of large number of
RPs, an operational workaround could be to split the PIM domain: for
example, using two /33's instead of one /32 would gain another 16 (or
15, if zero is not used) RP addresses. Note that the limit of 4 bits
worth of RPs just depends on the prefix the RP address is derived
from; one can use multiple prefixes in a domain, and the limit of 16
(or 15) RPs should never really be a problem.
Values 64 < "plen" < 96 would overlap with upper bits of the Values 64 < "plen" < 96 would overlap with upper bits of the
multicast group-id; due to this restriction, "plen" must not exceed multicast group-id; due to this restriction, "plen" must not exceed
64 bits. This is in line with RFC 3306. 64 bits. This is in line with RFC 3306.
The embedded RP addressing could be used to convey other information The embedded-RP addressing could be used to convey other information
(other than RP address) as well, for example, what should be the RPT (other than RP address) as well, for example, what should be the RPT
threshold for PIM-SM. These could be encoded in the RP address threshold for PIM-SM. These could be, whether feasible or not,
somehow, or in the multicast group address. Whether this is a good encoded in the RP address somehow, or in the multicast group address.
idea is another thing. In any case, such modifications are beyond In any case, such modifications are beyond the scope of this memo.
the scope of this memo.
For the cases where the RPs do not exist or are unreachable, or too For the cases where the RPs do not exist or are unreachable, or too
much state is being generated to reach in a resource exhaustion DoS much state is being generated to reach in a resource exhaustion DoS
attack, some forms of rate-limiting or other mechanisms could be attack, some forms of rate-limiting or other mechanisms could be
deployed to mitigate the threats while trying not to disturb the deployed to mitigate the threats while trying not to disturb the
legitimate usage. This has been described at more length in legitimate usage. However, as the threats are generic, they are
[PIMSEC]. considered out of scope and discussed separately in [PIMSEC].
The mechanism is not usable with Bidirectional PIM without protocol The mechanism is not usable with Bidirectional PIM without protocol
extensions, as pre-computing the Designated Forwarder is not extensions, as pre-computing the Designated Forwarder is not
possible. possible.
B. Changes since -00 B. Changes
[[ RFC-Editor: please remove before publication ]] [[ RFC-Editor: please remove before publication ]]
B.1 Changes since -01
o Lots of editorial cleanups and some reorganization, without
technical changes.
o Remove the specification that RIID=0 SHOULD NOT be accepted, but
state that they "must not" be used (implementation vs.
operational wording).
o Specify that the RP address MUST NOT be of prefixes fe80::/10,
::/16, or ff00::/8.
B.2 Changes since -00
o Lots of editorial cleanups, or cleanups without techinical o Lots of editorial cleanups, or cleanups without techinical
changes. changes.
o Reinforce the notion of Embedded RP just being a group-to-RP o Reinforce the notion of Embedded RP just being a group-to-RP
mapping mechanism (causing substantive rewriting in section 7); mapping mechanism (causing substantive rewriting in section 7);
highlight the fact that precomputing the group-to-RP mapping is highlight the fact that precomputing the group-to-RP mapping is
not possible. not possible.
o Add (a bit) more text on RP redundancy and deployment tradeoffs o Add (a bit) more text on RP redundancy and deployment tradeoffs
wrt. RPs becoming SPoF. wrt. RPs becoming SPoF.
o Clarify the usability/scalability issues in section 8. o Clarify the usability/scalability issues in section 8.
o Clarify the security issues in Sections 8, Security o Clarify the security issues in Sections 8, Security
Considerations and Appendix A, mainly by referring to a separate Considerations and Appendix A, mainly by referring to a separate
document. document.
o Add a MUST that embedded RP mappings must be honored by o Add a MUST that embedded-RP mappings must be honored by
implementations. implementations.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/