< draft-savola-mboned-mcast-rpaddr-00.txt   draft-savola-mboned-mcast-rpaddr-01.txt >
Internet Engineering Task Force P. Savola Internet Engineering Task Force P. Savola
Internet Draft CSC/FUNET Internet Draft CSC/FUNET
Expiration Date: April 2003 Expiration Date: August 2003
B. Haberman B. Haberman
Caspian Networks Caspian Networks
October 2002 February 2003
Embedding the Address of RP in IPv6 Multicast Address Embedding the Address of RP in IPv6 Multicast Address
draft-savola-mboned-mcast-rpaddr-00.txt draft-savola-mboned-mcast-rpaddr-01.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 46 skipping to change at page 1, line 46
Abstract Abstract
As has been noticed, there is exists a huge deployment problem with As has been noticed, there is exists a huge deployment problem with
global, interdomain IPv6 multicast: PIM RPs have no way of global, interdomain IPv6 multicast: PIM RPs have no way of
communicating the information about multicast sources to other communicating the information about multicast sources to other
multicast domains, as there is no MSDP, and the whole interdomain Any multicast domains, as there is no MSDP, and the whole interdomain Any
Source Multicast model is rendered unusable; SSM avoids these Source Multicast model is rendered unusable; SSM avoids these
problems. This memo outlines a way to embed the address of the RP in problems. This memo outlines a way to embed the address of the RP in
the multicast address, solving the interdomain multicast problem. The the multicast address, solving the interdomain multicast problem. The
problem is three-fold: specify an address format, adjust the problem is three-fold: specify an address format, adjust the
operational procedures and configuration if necessary, and modify operational procedures and configuration if necessary, and modify PIM
receiver-side PIM implementations. In consequence, there would be no implementations of those who want to join a group (DR's) or create
need for interdomain MSDP. one (RP's). In consequence, there would be no need for interdomain
MSDP.
Table of Contents Table of Contents
1. Introduction ............................................... 2 1. Introduction ............................................... 2
2. Unicast-Prefix-based Address Format ........................ 3 2. Unicast-Prefix-based Address Format ........................ 3
3. Modified Unicast-Prefix-based Address Format ............... 3 3. Modified Unicast-Prefix-based Address Format ............... 3
4. Embedding the Address of the RP in the Multicast Address ... 4 4. Embedding the Address of the RP in the Multicast Address ... 4
5. Examples ................................................... 5 5. Examples ................................................... 5
5.1. Example 1 .............................................. 5 5.1. Example 1 .............................................. 5
5.2. Example 2 .............................................. 5 5.2. Example 2 .............................................. 5
5.3. Example 3 .............................................. 5 5.3. Example 3 .............................................. 6
5.4. Example 4 .............................................. 6 5.4. Example 4 .............................................. 6
6. Operational Requirements ................................... 6 6. Operational Requirements ................................... 6
6.1. Anycast-RP ............................................. 6 6.1. Anycast-RP ............................................. 6
6.2. Guidelines for Assigning IPv6 Addresses to RPs ......... 6 6.2. Guidelines for Assigning IPv6 Addresses to RPs ......... 6
7. Required PIM Modifications ................................. 6 7. Required PIM Modifications ................................. 7
8. Scalability/Usability Analysis ............................. 7 7.1. Overview of the Model .................................. 8
9. Acknowledgements ........................................... 8 8. Scalability/Usability Analysis ............................. 8
10. Security Considerations ................................... 8 9. Acknowledgements ........................................... 9
11. References ................................................ 8 10. Security Considerations ................................... 9
11.1. Normative References .................................. 8 11. References ................................................ 10
11.2. Informative References ................................ 9 11.1. Normative References .................................. 10
Authors' Addresses ............................................. 9 11.2. Informative References ................................ 10
A. Open Issues/Discussion ..................................... 9 Authors' Addresses ............................................. 11
A. Open Issues/Discussion ..................................... 11
1. Introduction 1. Introduction
As has been noticed [V6MISSUES], there is exists a huge deployment As has been noticed [V6MISSUES], there is exists a huge deployment
problem with global, interdomain IPv6 multicast: PIM [PIM] RPs have problem with global, interdomain IPv6 multicast: PIM [PIM] RPs have
no way of communicating the information about multicast sources to no way of communicating the information about multicast sources to
other multicast domains, as there is no MSDP [MSDP], and the whole other multicast domains, as there is no MSDP [MSDP], and the whole
interdomain Any Source Multicast model is rendered unusable; SSM interdomain Any Source Multicast model is rendered unusable; SSM
[SSM] avoids there problems. [SSM] avoids there problems.
skipping to change at page 3, line 5 skipping to change at page 3, line 5
multicast address, solving the interdomain multicast problem. The multicast address, solving the interdomain multicast problem. The
problem is three-fold: specify an address format, adjust the problem is three-fold: specify an address format, adjust the
operational procedures and configuration if necessary, and modify operational procedures and configuration if necessary, and modify
receiver-side PIM implementations. In consequence, there would be no receiver-side PIM implementations. In consequence, there would be no
need for interdomain MSDP. need for interdomain MSDP.
The solution is founded upon unicast-prefix-based IPv6 multicast The solution is founded upon unicast-prefix-based IPv6 multicast
addressing [UNIPRFXM] and making some assumptions about IPv6 address addressing [UNIPRFXM] and making some assumptions about IPv6 address
assignment for the RPs in the PIM domain. assignment for the RPs in the PIM domain.
Further, a change in how interdomain PIM operates with these
addresses is presented: multicast receivers' DR's join the RP
embedded in the address -- not their locally configured RP.
It is self-evident that one can't embed, in the general case, two It is self-evident that one can't embed, in the general case, two
128-bit addresses in one 128-bit address. In this memo, some 128-bit addresses in one 128-bit address. In this memo, some
assumptions on how this could be done are made. If these assumptions assumptions on how this could be done are made. If these assumptions
can't be followed, either operational procedures and configuration can't be followed, either operational procedures and configuration
must be slightly changed or this mechanism not be used. must be slightly changed or this mechanism not 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. document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 4, line 22 skipping to change at page 4, line 30
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 PIM RP and follows the semantics defined in [ADDRARCH] and of the PIM RP and follows the semantics defined in [ADDRARCH] and
[UNIPRFXM]. In this context, the value of "RPad" has no meaning. [UNIPRFXM]. In this context, the value of "RPad" has no meaning.
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
addresses, but the scheme could be extended to other forms of addresses, but the scheme could be extended to other forms of
multicast addresses as well. Further, the mechanism cannot be multicast addresses as well. Further, the mechanism cannot be
combined with SSM. combined with SSM, as SSM has no RP's.
To identify whether an address is a multicast address as specified in To identify whether an address is a multicast address as specified in
this memo and to be processed any further, it must satisfy all of the this memo and to be processed any further, it must satisfy all of the
bullets: below:
o it MUST be part of the prefix FF7::/12 o it MUST be a multicast address and have R, P, and T flag bits set
to 1 (that is, be part of the prefix FF7::/12 or FFF::/12)
o "plen" MUST NOT be 0 (ie. not SSM) o "plen" MUST NOT be 0 (ie. not SSM)
o "plen" MUST NOT be greater than 96 o "plen" MUST NOT be greater than 96
The address of the RP can be obtained from a multicast address by The address of the RP can be obtained from a multicast address
taking the following steps: satisfying the above criteria by taking the following steps:
1. take the last 96 bits of the multicast address add 32 zero bits 1. take the last 96 bits of the multicast address add 32 zero bits
at the end, at the end,
2. zero the last 128-"plen" bits, and 2. zero the last 128-"plen" bits, and
3. replace the last 4 bits with the contents of "RPad". 3. replace the last 4 bits with the contents of "RPad".
One should note that there are several operational scenarios when One should note that there are several operational scenarios when
[UNIPRFXM] statement "All non-significant bits of the network prefix [UNIPRFXM] statement "All non-significant bits of the network prefix
field SHOULD be zero" is ignored. This is to allow multicast address field SHOULD be zero" is ignored. This is to allow multicast address
assignments to third parties which still use your RP; see example 2 assignments to third parties which still use your RP; see example 2
below. below.
"Plen" higher than 64 SHOULD NOT be used as that would overlap with "Plen" higher than 64 SHOULD NOT be used as that would overlap with
the upper bits of multicast group-id. the upper bits of multicast group-id.
The implementation MUST perform at least the same address validity The implementation MUST perform at least the same address validity
checks to the calculated RP address as to one received via other checks to the calculated RP address as to one received via other
means (like MSDP), to avoid e.g. the address being "::" or "::1". means (like MSDP), to avoid e.g. the address being "::" or "::1".
One should note that the 4 bits reserved for "RPad" set the upper
bound for RP's per multicast group address; not the number of RP's in
a subnet, PIM domain or large-scale network.
5. Examples 5. Examples
5.1. Example 1 5.1. Example 1
The network administrator of 3FFE:FFFF::/32 wants to set up an RP for The network administrator of 3FFE:FFFF::/32 wants to set up an RP for
the network and all of his customers. He chooses network the network and all of his customers. He chooses network
prefix=3FFE:FFFF and plen=32, and wants to use this addressing prefix=3FFE:FFFF and plen=32, and wants to use this addressing
mechanism. The multicast addresses he will be able to use are of the mechanism. The multicast addresses he will be able to use are of the
form: form:
skipping to change at page 6, line 19 skipping to change at page 6, line 27
"FF7x:y40:3FFE:FFFF:BEEF:FEED::/96", and then their RP address would "FF7x:y40:3FFE:FFFF:BEEF:FEED::/96", and then their RP address would
be "3FFE:FFFF:BEEF:FEED::y". There are still 32 bits of multicast be "3FFE:FFFF: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 Requirements 6. Operational Requirements
6.1. Anycast-RP 6.1. Anycast-RP
One should note that MSDP is also used, in addition to interdomain One should note that MSDP is also used, in addition to interdomain
connections between RPs, in anycast-RP [ANYCASTRP] -technique, for connections between RPs, in anycast-RP [ANYCASTRP] -technique, for
sharing the state information between different RPs in one PIM sharing the state information between different RPs in one PIM
domain. domain. However, there are other propositions, like [ANYPIMRP].
Anycast-RP mechanism is incompatible with this addressing method Anycast-RP mechanism is incompatible with this addressing method
unless unless MSDP is specified and implemented. Alternatively, unless MSDP is specified and implemented. Alternatively, another
another method for sharing state information could be defined. method for sharing state information could be used.
Anycast-RP and other possible RP failover mechanisms are outside of Anycast-RP and other possible RP failover mechanisms are outside of
the scope of this memo. the scope of this memo.
6.2. Guidelines for Assigning IPv6 Addresses to RPs 6.2. 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 (and even beyond, by using the upper bits of multicast up to /64 (and even beyond, by using the upper bits of multicast
group-id). The interface identifier will have to be manually group-id). The interface identifier will have to be manually
configured. configured to match "RPad".
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, that address can be injected into the to the addressing topology, that address can be injected into the
routing system via a host route. This RP address SHOULD be assigned routing system via a host route. This RP address SHOULD be assigned
out of the network's prefix in order to ensure aggregation at the out of the network's prefix in order to ensure aggregation at the
border. border.
7. Required PIM Modifications 7. Required PIM Modifications
The use of multicast addresses with embedded RP addresses requires The use of multicast addresses with embedded RP addresses requires
additional PIM processing. Namely, a PIM router will need to be able additional PIM processing. Namely, a PIM router will need to be able
to recognize the encoding and derive the RP address from the address to recognize the encoding and derive the RP address from the address
using the rules in section 4. using the rules in section 4 and to be able to use the embedded RP,
instead of its own for multicast addresses in this specified range.
The two key places where these modifications are used are the The two key places where these modifications are used are the
Designated Routers (DRs) on the receiver networks and the RPs in the Designated Routers (DRs) on the receiver networks and the RPs in the
receiving domain (see figure below). For the DR's (rtrR1, rtrR23, sending domain (see figure below).
and rtrR4), this would be similar to the RPT -> SPT switchover
scenario. For the RPs (rtrRP_R123 and rtrRP_R4) the scenario would
be the same as building an SPT to a foreign source based on MSDP
information. In particular, there is no need to have all routers on
the path modified: this is a major benefit for quick deployment.
source - rtrS - rtrRP_S - rtrBB - rtrRP_R123 - rtrR1 - receiver1 For the DR's (rtrR1, rtrR23, and rtrR4), this means sending PIM
| | Join/Prune/Register messages to the foreign RP (rtrRP_S). Naturally,
| +------- rtrR23 - receiver2 PIM Register-Stop and other messages must also be allowed from the
| | foreign RP. Receivers in the local PIM domain (receiverS) do the
| +----- receiver3 same, but the RP used is the same as with regular Any-Source
Multicast (ASM).
For the RP (rtrRP_S), this means being able to recognize and validate
PIM messages originated from any DR at all and which use RP-embedded
addressing.
In particular, there is no need to have all routers on the path
modified: this is a major benefit for quick deployment.
source - rtrS - rtrRP_S - rtrBB -----+--- rtrR1 - receiver1
| | |
| | +-- rtrR23 - receiver2
receiverS -+ | |
| +---- receiver3
| |
+---- rtrRP_R4 --- rtrR4 - receiver4 +------------ rtrR4 - receiver4
In addition, the administration of the PIM domain will require a In addition, the administration of the PIM domain will require a
policy decision on where the SPT towards the encoded RP should be policy decision on where the PIM messages to the encoded RP be sent;
built. this is typically assumed to everywhere unless explicitly configured
otherwise.
The extraction of the RP information from the multicast address The extraction of the RP information from the multicast address
should be done during forwarding state creation. That is, if no should be done during forwarding state creation. That is, if no
state exists for the multicast address, PIM must take the embedded RP state exists for the multicast address, PIM must take the embedded RP
information into account when creating forwarding state. Depending information into account when creating forwarding state. Depending
on administrative policy, this could result in a receiver's DR on administrative policy, this would result in a receiver's DR
initiating an SPT towards the foreign RP, or the local RP initiating initiating a PIM Join towards the foreign RP.
an SPT towards the foreign RP.
It should be noted that this approach removes the need to run inter- It should be noted that this approach removes the need to run inter-
domain MSDP. Multicast distribution trees in foreign networks can be domain MSDP. Multicast distribution trees in foreign networks can be
joined by issuing an SPT towards the RP address encoded in the joined by issuing a PIM Join/Prune/Register to the RP address encoded
multicast address. in the multicast address.
7.1. Overview of the Model
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
or a web page)
2. The receiver issues an MLD Report Joining the group
3. The receiver's DR will initiate the PIM Join process towards
the RP embedded in the multicast address
The sender side has two cases:
1. A sender in the local domain. Nothing should be different
here.
2. A sender in a foreign domain. The DR will send the packets
unicast-encapsulated in PIM Register-messages to the RP address
encoded in the multicast address. The messages go on as
before, often with a Register-Stop and SPT Join; there is no
difference in them except for the fact that the RP address is
derived from the multicast address.
Whether a sender is in local or foreign domain can be distinguished
by checking whether the embedded address is one of RP's configured
using conventional mechanisms. Further mechanisms and behaviour is
TBD (also see the appendix).
8. Scalability/Usability Analysis 8. Scalability/Usability Analysis
Interdomain MSDP model for connecting PIM domains is mostly Interdomain MSDP model for connecting PIM domains is mostly
hierarchical. The "embedded RP address" changes this to a mostly hierarchical. The "embedded RP address" changes this to a mostly
flat, full-mesh virtual topology. flat, sender-centered, full-mesh virtual topology.
This may or may not cause some effects; it may or may not be This may or may not cause some effects; it may or may not be
desirable. At the very least, it makes many things much more robust desirable. At the very least, it makes many things much more robust
as the number of third parties is minimized. A good scalability as the number of third parties is minimized. A good scalability
analysis is needed. analysis is needed.
In some cases (especially if e.g. every home user is employing site- In some cases (especially if e.g. every home user is employing site-
local multicast), some degree of hierarchy would be highly desirable, local multicast), some degree of hierarchy would be highly desirable,
for scalability (e.g. take the advantage of shared multicast state) for scalability (e.g. take the advantage of shared multicast state)
and administrative point-of-view. and administrative point-of-view.
Being able to join/send to remote RP's has security considerations
that are considered below, but it has an advantage too: every group
has a "home RP" which is able to control (to some extent) who are
able to send to the group.
One should note that the model presented here simplifies the PIM
multicast routing model slightly by removing the receivers' local RP.
One scalability consideration should be noted: previously foreign
sources sent the unicast-encapsulated data to their local RP, now
they do so to foreign RP. This is especially important with large
multicast groups where there are a lot of heavy senders --
particularly if implementations do not handle unicast-decapsulation
well.
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. Eubanks noted an issue regarding short plen values. Tom Pusateri
noted problems with earlier SPT-join approach. Rami Lehtonen pointed
out issues with the scope of SA-state. The whole MboneD working
group is also acknowledged for the continued support and comments.
10. Security Considerations 10. Security Considerations
The address of the PIM RP is embedded in the multicast address. RPs The address of the PIM RP is embedded in the multicast address. RPs
may be a good target for Denial of Service attacks, and in this way, may be a good target for Denial of Service attacks, and in this way,
the target would be clearly visible. However, it could be argued the target would be clearly visible. However, it could be argued
that if interdomain multicast was to be made work e.g. with MSDP, the that if interdomain multicast was to be made work e.g. with MSDP, the
address would have to be visible anyway (through via other channels, address would have to be visible anyway (through via other channels,
which may be more easily securable). which may be more easily securable).
As any RP will have to accept PIM Join/Prune/Register messages from
any DR's, this might cause a potential DoS attack scenario. However,
this can be mitigated by the fact that the RP can discard all such
messages for all multicast addresses that do not embed the address of
the RP, and if deemed important, the implementation could also allow
manual configuration of which multicast addresses or prefixes
embedding the RP could be used; however, at least with addresses,
this would increase the need for coordination between multicast
sources and administration.
In a similar fashion, DR's must accept similar PIM messages back from
the foreign RP's for which a receiver in DR's network has joined.
One consequence of the 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 MSDP model.
RPs may become a bit more single points of failure as anycast-RP RPs may become a bit more single points of failure as anycast-RP
mechanism is not (at least immediately) available. This can be mechanism is not (at least immediately) available. This can be
partially mitigated by the fact that some other forms of failover are partially mitigated by the fact that some other forms of failover are
still possible, and there should be less need to store state as with still possible, and there should be less need to store state as with
MSDP. MSDP.
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 MSDP), to avoid the address being e.g. "::" or "::1". (like MSDP), to avoid the address being e.g. "::" or "::1".
skipping to change at page 9, line 11 skipping to change at page 10, line 36
[UNIPRFXM] Haberman, B., Thaler, D., "Unicast-Prefix-based IPv6 [UNIPRFXM] 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
[ANYCASTRP] Kim, D. et al, q(Anycast RP mechanism using PIM and [ANYCASTRP] Kim, D. et al, q(Anycast RP mechanism using PIM and
MSDP", work-in-progress, draft-ietf-mboned-anycast- MSDP", work-in-progress, draft-ietf-mboned-anycast-
rp-08.txt, May 2001. rp-08.txt, May 2001.
[MSDP] Farinacci, D. et al, "Multicast Source Discovery Protocol [ANYPIMRP] Farinacci, D., Cai, Y., "Anycast-RP using PIM",
(MSDP)", work-in-progress, draft-ietf-msdp-spec-13.txt work-in-progress, draft-farinacci-pim-anycast-rp-00.txt,
(expired), 2002. January 2003.
[MSDP] Meyer, D., Fenner, B, (Eds.), "Multicast Sourc
Discovery Protocol (MSDP)", work-in-progress,
draft-ietf-msdp-spec-14.txt, November 2002.
[PIM] Fenner, B. et al, "Protocol Independent Multicast - [PIM] 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-05.txt, work-in-progress, draft-ietf-pim-sm-v2-new-06.txt,
March 2002. December 2002.
[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-00.txt, work-in-progress, draft-ietf-ssm-arch-00.txt,
November 2001. November 2001.
[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-00.txt, October 2002. issues-01.txt, November 2002.
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 One Park Drive
Suite 400 Suite 400
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
EMail: bkhabs@nc.rr.com EMail: bkhabs@nc.rr.com
Phone: +1-919-949-4828 Phone: +1-919-949-4828
A. Open Issues/Discussion A. Open Issues/Discussion
The initial thought was to use only SPT join from local RP/DR to
foreign RP, rather than a full PIM Join to foreign RP. However, this
turned out to be problematic, as this kind of SPT joins where
disregarded because the path had not been set up before sending them.
A full join to foreign PIM domain is a much clearer approach.
One could argue that there can be more RPs than the 4-bit "RPad" One could argue that there can be more RPs than the 4-bit "RPad"
allows for, especially if anycast-RP cannot be used. In that light, allows for, especially if anycast-RP cannot be used. In that light,
extending "RPad" to take full advantage of whole 8 bits would seem extending "RPad" to take full advantage of whole 8 bits would seem
reasonable. However, this would use up all of the reserved bits, and reasonable. However, this would use up all of the reserved bits, and
leave no room for future flexibility. In case of large number of leave no room for future flexibility. In case of large number of
RPs, an operational workaround could be to split the PIM domain: for 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 RP example, using two /33's instead of one /32 would gain another 16 RP
addresses. addresses.
Some hierarchy (e.g. two-level, "ISP/customer") for RPs could Some hierarchy (e.g. two-level, "ISP/customer") for RPs could
possibly be added if necessary, but that would be torturing one 128 possibly be added if necessary, but that would be torturing one 128
bits even more. bits even more.
One particular case with a sender in the local domain is where
regular ASM RP would be X, and the embedded RP address would be Y.
This would typically be due to a misconfiguration, but the DR SHOULD
be conservative and use the configured address X. Any other thoughts
on that?
 End of changes. 32 change blocks. 
55 lines changed or deleted 146 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/