draft-ietf-softwire-mesh-multicast-00.txt   draft-ietf-softwire-mesh-multicast-01.txt 
Network Working Group M. Xu Network Working Group M. Xu
Internet-Draft Y. Cui Internet-Draft Y. Cui
Expires: March 16, 2012 S. Yang Expires: May 1, 2012 S. Yang
J. Wu J. Wu
Tsinghua University Tsinghua University
C. Metz C. Metz
G. Shepherd G. Shepherd
Cisco Systems Cisco Systems
September 13, 2011 October 29, 2011
Softwire Mesh Multicast Softwire Mesh Multicast
draft-ietf-softwire-mesh-multicast-00 draft-ietf-softwire-mesh-multicast-01
Abstract Abstract
The Internet needs to support IPv4 and IPv6 packets. Both address The Internet needs to support IPv4 and IPv6 packets. Both address
families and their attendant protocol suites support multicast of the families and their attendant protocol suites support multicast of the
single-source and any-source varieties. As part of the transition to single-source and any-source varieties. As part of the transition to
IPv6, there will be scenarios where a backbone network running one IP IPv6, there will be scenarios where a backbone network running one IP
address family internally (referred to as internal IP or I-IP) will address family internally (referred to as internal IP or I-IP) will
provide transit services to attached client networks running another provide transit services to attached client networks running another
IP address family (referred to as external IP or E-IP). It is IP address family (referred to as external IP or E-IP). It is
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 16, 2012. This Internet-Draft will expire on May 1, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 17 skipping to change at page 3, line 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Scenarios of Interest . . . . . . . . . . . . . . . . . . . . 7 3. Scenarios of Interest . . . . . . . . . . . . . . . . . . . . 7
3.1. IPv4-over-IPv6 . . . . . . . . . . . . . . . . . . . . . . 7 3.1. IPv4-over-IPv6 . . . . . . . . . . . . . . . . . . . . . . 7
3.2. IPv6-over-IPv4 . . . . . . . . . . . . . . . . . . . . . . 8 3.2. IPv6-over-IPv4 . . . . . . . . . . . . . . . . . . . . . . 8
4. IPv4-over-IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 10 4. IPv4-over-IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Source Address Mapping . . . . . . . . . . . . . . . . . . 10 4.2. Source Address Mapping . . . . . . . . . . . . . . . . . . 10
4.3. Group Address Mapping . . . . . . . . . . . . . . . . . . 12 4.3. Group Address Mapping . . . . . . . . . . . . . . . . . . 12
4.4. Actions performed by AFBR . . . . . . . . . . . . . . . . 12 4.4. Actions performed by AFBR . . . . . . . . . . . . . . . . 12
4.5. Distribution of Routing Information among AFBRs . . . . . 13
5. IPv6-over-IPv4 . . . . . . . . . . . . . . . . . . . . . . . . 14 5. IPv6-over-IPv4 . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2. Source Address Mapping . . . . . . . . . . . . . . . . . . 14 5.2. Source Address Mapping . . . . . . . . . . . . . . . . . . 14
5.3. Group Address Mapping . . . . . . . . . . . . . . . . . . 16 5.3. Group Address Mapping . . . . . . . . . . . . . . . . . . 15
5.4. Actions performed by AFBR . . . . . . . . . . . . . . . . 16 5.4. Actions performed by AFBR . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 5.5. Distribution of Routing Information among AFBRs . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6. Other Consideration . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 6.1. Selecting a Tunneling Technology . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 6.2. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 20 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
The Internet needs to support IPv4 and IPv6 packets. Both address The Internet needs to support IPv4 and IPv6 packets. Both address
families and their attendant protocol suites support multicast of the families and their attendant protocol suites support multicast of the
single-source and any-source varieties. As part of the transition to single-source and any-source varieties. As part of the transition to
IPv6, there will be scenarios where a backbone network running one IP IPv6, there will be scenarios where a backbone network running one IP
address family internally (referred to as internal IP or I-IP) will address family internally (referred to as internal IP or I-IP) will
provide transit services to attached client networks running another provide transit services to attached client networks running another
IP address family (referred to as external IP or E-IP). IP address family (referred to as external IP or E-IP).
skipping to change at page 6, line 26 skipping to change at page 6, line 26
o I-IP (Internal IP): This refers to the form of IP (i.e., either o I-IP (Internal IP): This refers to the form of IP (i.e., either
IPv4 or IPv6) that is supported by the core (or backbone) network. IPv4 or IPv6) that is supported by the core (or backbone) network.
An I-IPv6 core network runs IPv6 and an I-IPv4 core network runs An I-IPv6 core network runs IPv6 and an I-IPv4 core network runs
IPv4. IPv4.
o E-IP (External IP): This refers to the form of IP (i.e. either IPv4 o E-IP (External IP): This refers to the form of IP (i.e. either IPv4
or IPv6) that is supported by the client network(s) attached to the or IPv6) that is supported by the client network(s) attached to the
I-IP transit core. An E-IPv6 client network runs IPv6 and an E-IPv4 I-IP transit core. An E-IPv6 client network runs IPv6 and an E-IPv4
client network runs IPv4. client network runs IPv4.
o I-IP core tree: A single-source or multi-source distribution tree o I-IP core tree: A distribution tree rooted at one or more AFBR
rooted at one or more AFBR source nodes and branched out to one or source nodes and branched out to one or more AFBR leaf nodes. An
more AFBR leaf nodes. An I-IP core Tree is built using standard IP I-IP core tree is built using standard IP or MPLS multicast signaling
or MPLS multicast signaling protocols operating exclusively inside protocols operating exclusively inside the I-IP core network. An
the I-IP core network. An I-IP core Tree is used to tunnel E-IP I-IP core tree is used to tunnel E-IP multicast packets belonging to
multicast packets belonging to E-IP trees across the I-IP core. E-IP trees across the I-IP core. Another name for an I-IP core tree
Another name for an I-IP core Tree is multicast or multipoint is multicast or multipoint softwire.
softwire.
o E-IP client tree: A single-source or multi-source distribution tree o E-IP client tree: A distribution tree rooted at one or more hosts
rooted at one or more hosts or routers located inside a client E-IP or routers located inside a client E-IP network and branched out to
network and branched out to one or more leaf nodes located in the one or more leaf nodes located in the same or different client E-IP
same or different client E-IP networks. networks.
o uPrefix64: The /96 unicast IPv6 prefix for constructing IPv4-
embedded IPv6 source address.
3. Scenarios of Interest 3. Scenarios of Interest
This section describes the two different scenarios where softwires This section describes the two different scenarios where softwires
mesh multicast will apply. mesh multicast will apply.
3.1. IPv4-over-IPv6 3.1. IPv4-over-IPv6
._._._._. ._._._._. ._._._._. ._._._._.
| IPv4 | | IPv4 | -------- | IPv4 | | IPv4 | --------
skipping to change at page 10, line 45 skipping to change at page 10, line 45
multicast, and the source address translation rules may vary a lot. multicast, and the source address translation rules may vary a lot.
There are four scenarios to be discussed in detail: There are four scenarios to be discussed in detail:
o E-IP network supports SSM, I-IP network supports SSM o E-IP network supports SSM, I-IP network supports SSM
One possible way to make sure that the translated I-IPv6 PIM One possible way to make sure that the translated I-IPv6 PIM
message reaches upstream AFBR is to set S' to a virtual IPv6 message reaches upstream AFBR is to set S' to a virtual IPv6
address that leads to the upstream AFBR. Figure 4 is the address that leads to the upstream AFBR. Figure 4 is the
recommended address format based on [9]: recommended address format based on [9]:
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 0-------------32--40--48--56--64--72--80--88--96--104---------| | 0-------------32--40--48--56--64--72--80--88--96-----------127|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| prefix |v4(32) | u | suffix |source address | | prefix |v4(32) | u | suffix |source address |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|<------------------uPrefix64------------------>|
Figure 4: IPv4-Embedded IPv6 Virtual Source Address Format Figure 4: IPv4-Embedded IPv6 Virtual Source Address Format
In this address format, the "prefix" field contains a "Well-Known" In this address format, the "prefix" field contains a "Well-Known"
prefix or a ISP-defined prefix. An existing "Well-Known" prefix prefix or a ISP-defined prefix. An existing "Well-Known" prefix
is 64:ff9b, which is defined in [9]; "v4" field is the IP address is 64:ff9b, which is defined in [9]; "v4" field is the IP address
of one of upstream AFBR's E-IPv4 interface; "u" field is defined of one of upstream AFBR's E-IPv4 interface; "u" field is defined
in [4], and MUST be set to zero; "suffix" field is reserved for in [4], and MUST be set to zero; "suffix" field is reserved for
future extensions and SHOULD be set to zero; "source address" future extensions and SHOULD be set to zero; "source address"
field stores the original S. field stores the original S. We call the overall /96 prefix
("prefix" field and "v4" field and "u" field and "suffix" field
altogether) "uPrefix64".
To make it feasible, the /32 prefix must be known to every AFBR, To make it feasible, the /32 prefix must be known to every AFBR,
and AFBRs should not only announce the /96 prefixes of S' to the and every AFBR should not only announce the IP address of one of
I-IPv6 network, but also announce the IP addresses of upstream its E-IPv4 interface presented in the "v4" field to other AFBRs by
AFBRs' E-IPv4 interface presented in the "v4" field to other AFBRs MPBGP, but also announce the corresponding uPrefix64 to the I-IPv6
by MPBGP. In this way, when a downstream AFBR receives a (S,G) network. Since every IP address of upstream AFBR's E-IPv4
interface is different from each other, every uPrefix64 that AFBR
announces shoud be different either, and uniquely identifies each
AFBR. In this way, when a downstream AFBR receives a (S,G)
message, it can translate it into (S',G') by looking up the IP message, it can translate it into (S',G') by looking up the IP
address of the corresponding AFBR's E-IPv4 interface. Since S' is address of the corresponding AFBR's E-IPv4 interface. Since the
globally unique and the /96 prefix of S' is known to every router uPrefix64 of S' is unique, and is known to every router in the
in I-IPv6 network, the translated message will eventually arrive I-IPv6 network, the translated message will eventually arrive at
at the corresponding upstream AFBR, and the upstream AFBR can the corresponding upstream AFBR, and the upstream AFBR can
translate the message back to (S,G). translate the message back to (S,G).
o E-IP network supports SSM, I-IP network supports ASM o E-IP network supports SSM, I-IP network supports ASM
Since any network that supports ASM should also support SSM, we Since any network that supports ASM can also support SSM, we can
can construct a SSM tree in I-IP network. The operation in this construct a SSM tree in I-IP network. The operation in this
scenario is the same as that in the first scenario. scenario is the same as that in the first scenario.
o E-IP network supports ASM, I-IP network supports SSM o E-IP network supports ASM, I-IP network supports SSM
ASM and SSM have the same PIM message format. The main ASM and SSM have the same PIM message format. The main
differences between ASM and SSM are RP and (*,G) messages. To differences between ASM and SSM are RP and (*,G) messages. To
make this scenario feasible, we must be able to translate (*,G) make this scenario feasible, we must be able to translate (*,G)
messages into (S',G') messages at downstream AFBRs, and translate messages into (S',G') messages at downstream AFBRs, and translate
it back at upstream AFBRs. Assume RP' is the upstream AFBR that it back at upstream AFBRs. Assume RP' is the upstream AFBR that
locates between RP and the downstream AFBR. When a downstream locates between RP and the downstream AFBR. When a downstream
AFBR receives an E-IPv4 PIM (*,G) message, S' can be generated AFBR receives an E-IPv4 PIM (*,G) message, S' can be generated
according to the format specified in Figure 4, with "v4" field according to the format specified in Figure 4, with "v4" field
setting to the IP address of one of RP's E-IPv4 interface and setting to the IP address of one of RP's E-IPv4 interface and
"source address" field setting to *(the IPv4 address of RP). The "source address" field setting to *(the IPv4 address of RP). The
translated message will eventually arrive at RP'. RP' checks the translated message will eventually arrive at RP'. RP' checks the
"source address" field and finds the IPv4 address of RP, so RP' "source address" field and finds the IPv4 address of RP, so RP'
judges that this is originally a (*,G) message, then it translates judges that this is originally a (*,G) message, then it translates
the message back to (*,G) message and forwards it to RP. the message back to (*,G) message and forwards it to RP.
Traveling all the way from sources to the RP, and then back down
the shared tree may result in the multicast data packets passing
through RP' twice, which brings about undesirable increased
latency or bandwidth consumption. For this reason, RP' MAY
perform a "cut-through", namely when RP' receives multicast data
packets sent from sources to RP, it not only forwards them to RP,
but also forwards them directly onto the multicast tree built in
the I-IPv6 network. (S,G,rpt) messages should be sent towards RP
to avoid reduplication.
o E-IP network supports ASM, I-IP network supports ASM o E-IP network supports ASM, I-IP network supports ASM
To keep it as simple as possible, we treat I-IP network as SSM and To keep it as simple as possible, we treat I-IP network as SSM and
the solution is the same as the third scenario. the solution is the same as the third scenario.
4.3. Group Address Mapping 4.3. Group Address Mapping
For IPv4-over-IPv6 scenario, a simple algorithmic mapping between For IPv4-over-IPv6 scenario, a simple algorithmic mapping between
IPv4 multicast group addresses and IPv6 group addresses is supported. IPv4 multicast group addresses and IPv6 group addresses is supported.
[11] has already defined an applicable format. Figure 5 is the [11] has already defined an applicable format. Figure 5 is the
skipping to change at page 14, line 5 skipping to change at page 13, line 14
o Process and forward multicast data o Process and forward multicast data
On receiving multicast data from upstream routers, the AFBR looks On receiving multicast data from upstream routers, the AFBR looks
up its forwarding table to check the IP address of each outgoing up its forwarding table to check the IP address of each outgoing
interface. If there exists at least one outgoing interface whose interface. If there exists at least one outgoing interface whose
IP address family is different from the incoming interface, the IP address family is different from the incoming interface, the
AFBR should encapsulate/decapsulate this packet and forward it to AFBR should encapsulate/decapsulate this packet and forward it to
the outgoing interface(s), then forward the data to other outgoing the outgoing interface(s), then forward the data to other outgoing
interfaces without encapsulation/decapsulation. interfaces without encapsulation/decapsulation.
4.5. Distribution of Routing Information among AFBRs
It is described in [8] that AFBRs take advantage of BGP to distribute
the E-IP routing information to each other by I-IP transport. In
IPv4-over-IPv6 scenario of softwire mesh multicast in addition, every
AFBR should not only announce the IP address of one of its E-IPv4
interface presented in the "v4" field to other AFBRs, but also
announce the corresponding uPrefix64 to the I-IPv6 network to ensure
the softwire mesh multicast mechanism functions properly. This
should also be done by BGP.
As uPrefix64 is an IPv6 prefix, the distribution of uPrefix64 is the
same as the the distribution in unicast scenario. But since "v4"
field is an E-IPv4 address, and BGP messages are NOT tunneled through
softwires or through any other mechanism as specified in [8], AFBRs
MUST be able to transport and encode/decode BGP messages that are
carried over I-IPv6, whose NLRI and NH are of E-IPv4 address family.
5. IPv6-over-IPv4 5. IPv6-over-IPv4
5.1. Mechanism 5.1. Mechanism
Routers in the client E-IPv6 networks contain routes to all other Routers in the client E-IPv6 networks contain routes to all other
client E-IPv6 networks. Through the set of known and deployed client E-IPv6 networks. Through the set of known and deployed
mechanisms, E-IPv6 hosts and routers have discovered or learned of mechanisms, E-IPv6 hosts and routers have discovered or learned of
(S,G) or (*,G) IPv6 addresses. Any I-IP multicast state instantiated (S,G) or (*,G) IPv6 addresses. Any I-IP multicast state instantiated
in the core is referred to as (S',G') or (*,G') and is certainly in the core is referred to as (S',G') or (*,G') and is certainly
separated from E-IP multicast state. separated from E-IP multicast state.
skipping to change at page 14, line 44 skipping to change at page 14, line 44
upstream AFBR, we need to set S' to an IPv4 address that leads to upstream AFBR, we need to set S' to an IPv4 address that leads to
the upstream AFBR. But due to the non-"one-to-one" mapping of the upstream AFBR. But due to the non-"one-to-one" mapping of
E-IPv6 to I-IPv4 unicast address, the upstream AFBR is unable to E-IPv6 to I-IPv4 unicast address, the upstream AFBR is unable to
remap the I-IPv4 source address to the original E-IPv6 source remap the I-IPv4 source address to the original E-IPv6 source
address without any constraints. address without any constraints.
We apply a fixed IPv6 prefix and static mapping to solve this We apply a fixed IPv6 prefix and static mapping to solve this
problem. A recommended source address format is defined in [9]. problem. A recommended source address format is defined in [9].
Figure 6 is the reminder of the format: Figure 6 is the reminder of the format:
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 0-------------32--40--48--56--64--72--80--88--96--104---------| | 0-------------32--40--48--56--64--72--80--88--96-----------127|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| prefix(96) | v4(32) | | uPrefix64 |source address |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 6: IPv4-Embedded IPv6 Source Address Format Figure 6: IPv4-Embedded IPv6 Source Address Format
In this address format, the "prefix" field contains a "Well-Known" In this address format, the "uPrefix64" field starts with a "Well-
prefix or a ISP-defined prefix. An existing "Well-Known" prefix Known" prefix or a ISP-defined prefix. An existing "Well-Known"
is 64:ff9b, which is defined in [9]; "v4" field is the prefix is 64:ff9b/32, which is defined in [9]; "source address"
corresponding I-IPv4 source address. field is the corresponding I-IPv4 source address.
To make it feasible, the /96 prefix must be known to every AFBR, To make it feasible, the /96 uPrefix64 must be known to every
every E-IPv6 address of sources that support mesh multicast MUST AFBR, every E-IPv6 address of sources that support mesh multicast
follow the format specified in Figure 6, and the corresponding MUST follow the format specified in Figure 6, and the
upstream AFBR should announce the I-IPv4 address in "v4" field to corresponding upstream AFBR should announce the I-IPv4 address in
the I-IPv4 network. In this way, when a downstream AFBR receives "source address" field to the I-IPv4 network. In this way, when a
a (S,G) message, it can translate the message into (S',G') by downstream AFBR receives a (S,G) message, it can translate the
simply taking off the prefix in S. Since S' is known to every message into (S',G') by simply taking off the prefix in S. Since
router in I-IPv4 network, the translated message will eventually S' is known to every router in I-IPv4 network, the translated
arrive at the corresponding upstream AFBR, and the upstream AFBR message will eventually arrive at the corresponding upstream AFBR,
can translate the message back to (S,G) by appending the prefix to and the upstream AFBR can translate the message back to (S,G) by
S'. appending the prefix to S'.
o E-IP network supports SSM, I-IP network supports ASM o E-IP network supports SSM, I-IP network supports ASM
Since any network that supports ASM should also support SSM, we Since any network that supports ASM can also support SSM, we can
can construct a SSM tree in I-IP network. The operation in this construct a SSM tree in I-IP network. The operation in this
scenario is the same as that in the first scenario. scenario is the same as that in the first scenario.
o E-IP network supports ASM, I-IP network supports SSM o E-IP network supports ASM, I-IP network supports SSM
ASM and SSM have the same PIM message format. The main ASM and SSM have the same PIM message format. The main
differences between ASM and SSM are RP and (*,G) messages. To differences between ASM and SSM are RP and (*,G) messages. To
make this scenario feasible, we must be able to translate (*,G) make this scenario feasible, we must be able to translate (*,G)
messages into (S',G') messages at downstream AFBRs and translate messages into (S',G') messages at downstream AFBRs and translate
it back at upstream AFBRs. Here, the E-IPv6 address of RP MUST it back at upstream AFBRs. Here, the E-IPv6 address of RP MUST
follow the format specified in Figure 6. Assume RP' is the follow the format specified in Figure 6. Assume RP' is the
upstream AFBR that locates between RP and the downstream AFBR. upstream AFBR that locates between RP and the downstream AFBR.
When a downstream AFBR receives a (*,G) message, it can translate When a downstream AFBR receives a (*,G) message, it can translate
it into (S',G') by simply taking off the prefix in *(the E-IPv6 it into (S',G') by simply taking off the prefix in *(the E-IPv6
address of RP). Since S' is known to every router in I-IPv4 address of RP). Since S' is known to every router in I-IPv4
network, the translated message will eventually arrive at RP'. network, the translated message will eventually arrive at RP'.
RP' knows that S' is the mapped I-IPv4 address of RP, so RP' will RP' knows that S' is the mapped I-IPv4 address of RP, so RP' will
translate the message back to (*,G) by appending the prefix to S' translate the message back to (*,G) by appending the prefix to S'
and forward it to RP. and forward it to RP.
Traveling all the way from sources to the RP, and then back down
the shared tree may result in the multicast data packets passing
through RP' twice, which brings about undesirable increased
latency or bandwidth consumption. For this reason, RP' MAY
perform a "cut-through", namely when RP' receives multicast data
packets sent from sources to RP, it not only forwards them to RP,
but also forwards them directly onto the multicast tree built in
the I-IPv6 network. (S,G,rpt) messages should be sent towards RP
to avoid reduplication.
o E-IP network supports ASM, I-IP network supports ASM o E-IP network supports ASM, I-IP network supports ASM
To keep it as simple as possible, we treat I-IP network as SSM and To keep it as simple as possible, we treat I-IP network as SSM and
the solution is the same as the third scenario. the solution is the same as the third scenario.
5.3. Group Address Mapping 5.3. Group Address Mapping
To keep one-to-one group address mapping simple, the group address To keep one-to-one group address mapping simple, the group address
range of E-IP IPv6 can be reduced in a number of ways to limit the range of E-IP IPv6 can be reduced in a number of ways to limit the
scope of addresses that need to be mapped into the I-IP IPv4 space. scope of addresses that need to be mapped into the I-IP IPv4 space.
skipping to change at page 17, line 5 skipping to change at page 16, line 40
o Process and forward multicast data o Process and forward multicast data
On receiving multicast data from upstream routers, the AFBR looks On receiving multicast data from upstream routers, the AFBR looks
up its forwarding table to check the IP address of each outgoing up its forwarding table to check the IP address of each outgoing
interface. If there exists at least one outgoing interface whose interface. If there exists at least one outgoing interface whose
IP address family is different from the incoming interface, the IP address family is different from the incoming interface, the
AFBR should encapsulate/decapsulate this packet and forward it to AFBR should encapsulate/decapsulate this packet and forward it to
the outgoing interface(s), and then forward the data to the other the outgoing interface(s), and then forward the data to the other
outgoing interfaces without encapsulation/decapsulation. outgoing interfaces without encapsulation/decapsulation.
6. Security Considerations 5.5. Distribution of Routing Information among AFBRs
Since uPrefix64 is static and unique in IPv6-over-IPv4 scenario,
there is no need to distribute it using BGP. The distribution of
"source address" field of multicast source addresses is a pure I-IPv4
process and no more specification is needed.
6. Other Consideration
6.1. Selecting a Tunneling Technology
The choice of tunneling technology is a matter of policy configured
at AFBRs.
In most cases, the policy of choosing tunneling technologies will be
very simple, such as all AFBRs use the same technology. But it's
possible that there doesn't exist one technique that all AFBRs
support. A recommanded solution is described in [8], which divides
AFBRs into one or more classes, and each of these classes is assigned
a technology that every AFBR in this class supports. In this way,
all the AFBRs in the same class can choose the right technology to
communicate with each other.
6.2. Fragmentation
The encapsulation performed by upstream AFBR will increase the size
of packets. As a result, the outgoing I-IP link MTU may not
accommodate the extra size. As it's not always possible for core
operators to increase every link's MTU, fragmentation and
reassembling of encapsulated packets MUST be supported by AFBRs.
7. Security Considerations
The AFBR routers could maintain secure communications through the use The AFBR routers could maintain secure communications through the use
of Security Architecture for the Internet Protocol as described of Security Architecture for the Internet Protocol as described
in[RFC4301]. But when adopting some schemes that will cause heavy in[RFC4301]. But when adopting some schemes that will cause heavy
burden on routers, some attacker may use it as a tool for DDoS burden on routers, some attacker may use it as a tool for DDoS
attack. attack.
7. IANA Considerations 8. IANA Considerations
When AFBRs perform address mapping, they should follow some When AFBRs perform address mapping, they should follow some
predefined rules, especially the IPv6 prefix for source address predefined rules, especially the IPv6 prefix for source address
mapping should be predefined, so that ingress AFBR and egress AFBR mapping should be predefined, so that ingress AFBR and egress AFBR
can finish the mapping procedure correctly. The IPv6 prefix for can finish the mapping procedure correctly. The IPv6 prefix for
translation can be unified within only the transit core, or within translation can be unified within only the transit core, or within
global area. In the later condition, the prefix should be assigned global area. In the later condition, the prefix should be assigned
by IANA. by IANA.
8. References 9. References
8.1. Normative References 9.1. Normative References
[1] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, [1] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina,
"Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[2] Foster, B. and F. Andreasen, "Media Gateway Control Protocol [2] Foster, B. and F. Andreasen, "Media Gateway Control Protocol
(MGCP) Redirect and Reset Package", RFC 3991, February 2005. (MGCP) Redirect and Reset Package", RFC 3991, February 2005.
[3] Hinden, R. and S. Deering, "IP Version 6 Addressing [3] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998. Architecture", RFC 2373, July 1998.
skipping to change at page 19, line 38 skipping to change at page 20, line 38
[7] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path [7] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path
Forwarding (RPF) Vector TLV", RFC 5496, March 2009. Forwarding (RPF) Vector TLV", RFC 5496, March 2009.
[8] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh [8] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh
Framework", RFC 5565, June 2009. Framework", RFC 5565, June 2009.
[9] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, [9] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li,
"IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010. October 2010.
8.2. Informative References 9.2. Informative References
[10] Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y., [10] Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y.,
Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in MPLS/ Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in MPLS/
BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-10 (work in BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-10 (work in
progress), January 2010. progress), January 2010.
[11] Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and M. Xu, [11] Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and M. Xu,
"IPv4-Embedded IPv6 Multicast Address Format", "IPv4-Embedded IPv6 Multicast Address Format",
draft-boucadair-behave-64-multicast-address-format-02 (work in draft-boucadair-behave-64-multicast-address-format-02 (work in
progress), June 2011. progress), June 2011.
 End of changes. 27 change blocks. 
79 lines changed or deleted 122 lines changed or added

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