draft-ietf-softwire-mesh-multicast-04.txt   draft-ietf-softwire-mesh-multicast-05.txt 
Network Working Group M. Xu Network Working Group M. Xu
Internet-Draft Y. Cui Internet-Draft Y. Cui
Expires: July 16, 2013 J. Wu Expires: January 16, 2014 J. Wu
S. Yang S. Yang
Tsinghua University Tsinghua University
C. Metz C. Metz
G. Shepherd G. Shepherd
Cisco Systems Cisco Systems
January 12, 2013 July 15, 2013
Softwire Mesh Multicast Softwire Mesh Multicast
draft-ietf-softwire-mesh-multicast-04 draft-ietf-softwire-mesh-multicast-05
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
expected that the I-IP backbone will offer unicast and multicast expected that the I-IP backbone will offer unicast and multicast
transit services to the client E-IP networks. transit services to the client E-IP networks.
Softwire Mesh is a solution to E-IP unicast and multicast support Softwire Mesh is a solution to E-IP unicast and multicast support
across an I-IP backbone. This document describes the mechanisms for across an I-IP backbone. This document describes the mechanisms for
supporting Internet-style multicast across a set of E-IP and I-IP supporting Internet-style multicast across a set of E-IP and I-IP
networks supporting softwire mesh. networks supporting softwire mesh.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 July 16, 2013. This Internet-Draft will expire on January 16, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 7 skipping to change at page 2, line 34
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Scenarios of Interest . . . . . . . . . . . . . . . . . . . . 7 3. Scenarios of Interest . . . . . . . . . . . . . . . . . . . . 6
3.1. IPv4-over-IPv6 . . . . . . . . . . . . . . . . . . . . . . 7 3.1. IPv4-over-IPv6 . . . . . . . . . . . . . . . . . . . . . 6
3.2. IPv6-over-IPv4 . . . . . . . . . . . . . . . . . . . . . . 8 3.2. IPv6-over-IPv4 . . . . . . . . . . . . . . . . . . . . . 7
4. IPv4-over-IPv6 Mechanism . . . . . . . . . . . . . . . . . . . 10 4. IPv4-over-IPv6 Mechanism . . . . . . . . . . . . . . . . . . 8
4.1. Mechanism Overview . . . . . . . . . . . . . . . . . . . . 10 4.1. Mechanism Overview . . . . . . . . . . . . . . . . . . . 8
4.2. Group Address Mapping . . . . . . . . . . . . . . . . . . 10 4.2. Group Address Mapping . . . . . . . . . . . . . . . . . . 9
4.3. Source Address Mapping . . . . . . . . . . . . . . . . . . 11 4.3. Source Address Mapping . . . . . . . . . . . . . . . . . 9
4.4. Routing Mechanism . . . . . . . . . . . . . . . . . . . . 12 4.4. Routing Mechanism . . . . . . . . . . . . . . . . . . . . 10
5. IPv6-over-IPv4 Mechanism . . . . . . . . . . . . . . . . . . . 13 5. IPv6-over-IPv4 Mechanism . . . . . . . . . . . . . . . . . . 11
5.1. Mechanism Overview . . . . . . . . . . . . . . . . . . . . 13 5.1. Mechanism Overview . . . . . . . . . . . . . . . . . . . 11
5.2. Group Address Mapping . . . . . . . . . . . . . . . . . . 13 5.2. Group Address Mapping . . . . . . . . . . . . . . . . . . 12
5.3. Source Address Mapping . . . . . . . . . . . . . . . . . . 13 5.3. Source Address Mapping . . . . . . . . . . . . . . . . . 12
5.4. Routing Mechanism . . . . . . . . . . . . . . . . . . . . 14 5.4. Routing Mechanism . . . . . . . . . . . . . . . . . . . . 13
6. Control Plane Functions of AFBR . . . . . . . . . . . . . . . 16 6. Control Plane Functions of AFBR . . . . . . . . . . . . . . . 14
6.1. E-IP (*,G) State Maintenance . . . . . . . . . . . . . . . 16 6.1. E-IP (*,G) State Maintenance . . . . . . . . . . . . . . 14
6.2. E-IP (S,G) State Maintenance . . . . . . . . . . . . . . . 16 6.2. E-IP (S,G) State Maintenance . . . . . . . . . . . . . . 14
6.3. I-IP (S',G') State Maintenance . . . . . . . . . . . . . . 16 6.3. I-IP (S',G') State Maintenance . . . . . . . . . . . . . 14
6.4. E-IP (S,G,rpt) State Maintenance . . . . . . . . . . . . . 16 6.4. E-IP (S,G,rpt) State Maintenance . . . . . . . . . . . . 14
6.5. Inter-AFBR Signaling . . . . . . . . . . . . . . . . . . . 16 6.5. Inter-AFBR Signaling . . . . . . . . . . . . . . . . . . 15
6.6. SPT Switchover . . . . . . . . . . . . . . . . . . . . . . 18 6.6. SPT Switchover . . . . . . . . . . . . . . . . . . . . . 17
6.7. Other PIM Message Types . . . . . . . . . . . . . . . . . 19 6.7. Other PIM Message Types . . . . . . . . . . . . . . . . . 17
6.8. Other PIM States Maintenance . . . . . . . . . . . . . . . 19 6.8. Other PIM States Maintenance . . . . . . . . . . . . . . 17
7. Data Plane Functions of AFBR . . . . . . . . . . . . . . . . . 20 7. Data Plane Functions of AFBR . . . . . . . . . . . . . . . . 17
7.1. Process and Forward Multicast Data . . . . . . . . . . . . 20 7.1. Process and Forward Multicast Data . . . . . . . . . . . 17
7.2. Selecting a Tunneling Technology . . . . . . . . . . . . . 20 7.2. Selecting a Tunneling Technology . . . . . . . . . . . . 18
7.3. TTL . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.3. TTL . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.4. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 20 7.4. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 10.1. Normative References . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . . 23 10.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 24 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
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).
The preferred solution is to leverage the multicast functions The preferred solution is to leverage the multicast functions
inherent in the I-IP backbone, to efficiently and scalably forward inherent in the I-IP backbone, to efficiently and scalably forward
client E-IP multicast packets inside an I-IP core tree, which roots client E-IP multicast packets inside an I-IP core tree, which roots
at one or more ingress AFBR nodes and branches out to one or more at one or more ingress AFBR nodes and branches out to one or more
egress AFBR leaf nodes. egress AFBR leaf nodes.
[6] outlines the requirements for the softwires mesh scenario [RFC4925] outlines the requirements for the softwires mesh scenario
including the multicast. It is straightforward to envisage that including the multicast. It is straightforward to envisage that
client E-IP multicast sources and receivers will reside in different client E-IP multicast sources and receivers will reside in different
client E-IP networks connected to an I-IP backbone network. This client E-IP networks connected to an I-IP backbone network. This
requires that the client E-IP source-rooted or shared tree should requires that the client E-IP source-rooted or shared tree should
traverse the I-IP backbone network. traverse the I-IP backbone network.
One method to accomplish this is to re-use the multicast VPN approach One method to accomplish this is to re-use the multicast VPN approach
outlined in [10]. MVPN-like schemes can support the softwire mesh outlined in [RFC6513]. MVPN-like schemes can support the softwire
scenario and achieve a "many-to-one" mapping between the E-IP client mesh scenario and achieve a "many-to-one" mapping between the E-IP
multicast trees and the transit core multicast trees. The advantage client multicast trees and the transit core multicast trees. The
of this approach is that the number of trees in the I-IP backbone advantage of this approach is that the number of trees in the I-IP
network scales less than linearly with the number of E-IP client backbone network scales less than linearly with the number of E-IP
trees. Corporate enterprise networks and by extension multicast VPNs client trees. Corporate enterprise networks and by extension
have been known to run applications that create a large amount of multicast VPNs have been known to run applications that create a
(S,G) states. Aggregation at the edge contains the (S,G) states that large amount of (S,G) states. Aggregation at the edge contains the
need to be maintained by the network operator supporting the customer (S,G) states that need to be maintained by the network operator
VPNs. The disadvantage of this approach is the possible inefficient supporting the customer VPNs. The disadvantage of this approach is
bandwidth and resource utilization when multicast packets are the possible inefficient bandwidth and resource utilization when
delivered to a receiver AFBR with no attached E-IP receivers. multicast packets are delivered to a receiver AFBR with no attached
E-IP receivers.
Internet-style multicast is somewhat different in that the trees tend Internet-style multicast is somewhat different in that the trees tend
to be relatively sparse and source-rooted. The need for multicast to be relatively sparse and source-rooted. The need for multicast
aggregation at the edge (where many customer multicast trees are aggregation at the edge (where many customer multicast trees are
mapped into a few or one backbone multicast trees) does not exist and mapped into a few or one backbone multicast trees) does not exist and
to date has not been identified. Thus the need for a basic or closer to date has not been identified. Thus the need for a basic or closer
alignment with E-IP and I-IP multicast procedures emerges. alignment with E-IP and I-IP multicast procedures emerges.
A framework on how to support such methods is described in [8]. In A framework on how to support such methods is described in [RFC5565].
this document, a more detailed discussion supporting the "one-to-one" In this document, a more detailed discussion supporting the "one-to-
mapping schemes for the IPv6 over IPv4 and IPv4 over IPv6 scenarios one" mapping schemes for the IPv6 over IPv4 and IPv4 over IPv6
will be discussed. scenarios will be discussed.
2. Terminology 2. Terminology
An example of a softwire mesh network supporting multicast is An example of a softwire mesh network supporting multicast is
illustrated in Figure 1. A multicast source S is located in one E-IP illustrated in Figure 1. A multicast source S is located in one E-IP
client network, while candidate E-IP group receivers are located in client network, while candidate E-IP group receivers are located in
the same or different E-IP client networks that all share a common the same or different E-IP client networks that all share a common
I-IP transit network. When E-IP sources and receivers are not local I-IP transit network. When E-IP sources and receivers are not local
to each other, they can only communicate with each other through the to each other, they can only communicate with each other through the
I-IP core. There may be several E-IP sources for some multicast I-IP core. There may be several E-IP sources for some multicast
skipping to change at page 6, line 39 skipping to change at page 6, line 18
protocols operating exclusively inside the I-IP core network. An protocols operating exclusively inside the I-IP core network. An
I-IP core tree is used to forward E-IP multicast packets belonging to I-IP core tree is used to forward E-IP multicast packets belonging to
E-IP trees across the I-IP core. Another name for an I-IP core tree E-IP trees across the I-IP core. Another name for an I-IP core tree
is multicast or multipoint softwire. is multicast or multipoint softwire.
o E-IP client tree: A distribution tree rooted at one or more hosts o E-IP client tree: A distribution tree rooted at one or more hosts
or routers located inside a client E-IP network and branched out to or routers located inside a client E-IP network and branched out to
one or more leaf nodes located in the same or different client E-IP one or more leaf nodes located in the same or different client E-IP
networks. networks.
o uPrefix64: The /96 unicast IPv6 prefix for constructing IPv4- o uPrefix64: The /96 unicast IPv6 prefix for constructing
embedded IPv6 source address. IPv4-embedded IPv6 source address.
o Inter-AFBR signaling: A mechanism used by downstream AFBRs to send o Inter-AFBR signaling: A mechanism used by downstream AFBRs to send
PIM messages to the upstream AFBR. PIM messages to the upstream AFBR.
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
skipping to change at page 7, line 45 skipping to change at page 7, line 16
Figure 2: IPv4-over-IPv6 Scenario Figure 2: IPv4-over-IPv6 Scenario
In this scenario, the E-IP client networks run IPv4 and I-IP core In this scenario, the E-IP client networks run IPv4 and I-IP core
runs IPv6. This scenario is illustrated in Figure 2. runs IPv6. This scenario is illustrated in Figure 2.
Because of the much larger IPv6 group address space, it will not be a Because of the much larger IPv6 group address space, it will not be a
problem to map individual client E-IPv4 tree to a specific I-IPv6 problem to map individual client E-IPv4 tree to a specific I-IPv6
core tree. This simplifies operations on the AFBR because it becomes core tree. This simplifies operations on the AFBR because it becomes
possible to algorithmically map an IPv4 group/source address to an possible to algorithmically map an IPv4 group/source address to an
IPv6 group/source address and vice versa. IPv6 group/source address and vice-versa.
The IPv4-over-IPv6 scenario is an emerging requirement as network The IPv4-over-IPv6 scenario is an emerging requirement as network
operators build out native IPv6 backbone networks. These networks operators build out native IPv6 backbone networks. These networks
naturally support native IPv6 services and applications but it is naturally support native IPv6 services and applications but it is
with near 100% certainty that legacy IPv4 networks handling unicast with near 100% certainty that legacy IPv4 networks handling unicast
and multicast should be accommodated. and multicast should be accommodated.
3.2. IPv6-over-IPv4 3.2. IPv6-over-IPv4
._._._._. ._._._._. ._._._._. ._._._._.
skipping to change at page 10, line 35 skipping to change at page 9, line 9
In this case it is incumbent upon the AFBR routers to perform PIM In this case it is incumbent upon the AFBR routers to perform PIM
message conversions in the control plane and IP group address message conversions in the control plane and IP group address
conversions or mappings in the data plane. It becomes possible to conversions or mappings in the data plane. It becomes possible to
devise an algorithmic one-to-one IPv4-to-IPv6 address mapping at devise an algorithmic one-to-one IPv4-to-IPv6 address mapping at
AFBRs. AFBRs.
4.2. Group Address Mapping 4.2. 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 4 is the [I-D.ietf-mboned-64-multicast-address-format] has already defined an
reminder of the format: applicable format. Figure 4 is the reminder of the format:
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 0-------------32--40--48--56--64--72--80--88--96-----------127| | 0-------------32--40--48--56--64--72--80--88--96-----------127|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| MPREFIX64 |source address | | MPREFIX64 |group address |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 4: IPv4-Embedded IPv6 Multicast Address Format Figure 4: IPv4-Embedded IPv6 Multicast Address Format
The MPREFIX64 for SSM mode is also defined in [11] : The MPREFIX64 for SSM mode is also defined in
[I-D.ietf-mboned-64-multicast-address-format] :
o ff3x:0:8000::/96 ('x' is any valid scope) o ff3x:0:8000::/96 ('x' is any valid scope)
With this scheme, each IPv4 multicast address can be mapped into an With this scheme, each IPv4 multicast address can be mapped into an
IPv6 multicast address(with the assigned prefix), and each IPv6 IPv6 multicast address (with the assigned prefix), and each IPv6
multicast address with the assigned prefix can be mapped into IPv4 multicast address with the assigned prefix can be mapped into IPv4
multicast address. multicast address.
4.3. Source Address Mapping 4.3. Source Address Mapping
There are two kinds of multicast --- ASM and SSM. Considering that There are two kinds of multicast --- ASM and SSM. Considering that
I-IP network and E-IP network may support different kind of I-IP network and E-IP network may support different kind of
multicast, the source address translation rules could be very complex multicast, the source address translation rules could be very complex
to support all possible scenarios. But since SSM can be implemented to support all possible scenarios. But since SSM can be implemented
with a strict subset of the PIM-SM protocol mechanisms [5], we can with a strict subset of the PIM-SM protocol mechanisms [RFC4601], we
treat I-IP core as SSM-only to make it as simple as possible, then can treat I-IP core as SSM-only to make it as simple as possible,
there remains only two scenarios to be discussed in detail: then there remains only two scenarios to be discussed in detail:
o E-IP network supports SSM o E-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 5 is the address that leads to the upstream AFBR. Figure 5 is the
recommended address format based on [9]: recommended address format based on [RFC6052]:
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 0-------------32--40--48--56--64--72--80--88--96-----------127| | 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------------------>| |<------------------uPrefix64------------------>|
Figure 5: IPv4-Embedded IPv6 Virtual Source Address Format Figure 5: 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 an ISP-defined prefix. An existing "Well-Known" prefix prefix or an 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 [RFC6052]; "v4" field is the IP
of one of upstream AFBR's E-IPv4 interfaces; "u" field is defined address of one of upstream AFBR's E-IPv4 interfaces; "u" field is
in [4], and MUST be set to zero; "suffix" field is reserved for defined in [RFC4291], and MUST be set to zero; "suffix" field is
future extensions and SHOULD be set to zero; "source address" reserved for future extensions and SHOULD be set to zero; "source
field stores the original S. We call the overall /96 prefix address" field stores the original S. We call the overall /96
("prefix" field and "v4" field and "u" field and "suffix" field prefix ("prefix" field and "v4" field and "u" field and "suffix"
altogether) "uPrefix64". field altogether) "uPrefix64".
o E-IP network supports ASM o E-IP network supports ASM
The (S,G) source list entry and the (*,G) source list entry only The (S,G) source list entry and the (*,G) source list entry only
differ in that the latter have both the WC and RPT bits of the differ in that the latter have both the WC and RPT bits of the
Encoded-Source-Address set, while the former all cleared (See Encoded-Source-Address set, while the former all cleared (See
Section 4.9.5.1 of [5]). So we can translate source list entries Section 4.9.5.1 of [RFC4601]). So we can translate source list
in (*,G) messages into source list entries in (S'G') messages by entries in (*,G) messages into source list entries in (S'G')
applying the format specified in Figure 5 and setting both the WC messages by applying the format specified in Figure 5 and clearing
and RPT bits at upstream AFBRs, and translate them back at both the WC and RPT bits at downstream AFBRs, and translate them
upstream AFBRs vice versa. back at upstream AFBRs vice-versa.
4.4. Routing Mechanism 4.4. Routing Mechanism
In the mesh multicast scenario, routing information is required to be In the mesh multicast scenario, routing information is required to be
distributed among AFBRs to make sure that PIM messages that a distributed among AFBRs to make sure that PIM messages that a
downstream AFBR propagates reach the right upstream AFBR. downstream AFBR propagates reach the right upstream AFBR.
To make it feasible, the /32 prefix in "IPv4-Embedded IPv6 Virtual To make it feasible, the /32 prefix in "IPv4-Embedded IPv6 Virtual
Source Address Format" must be known to every AFBR, and every AFBR Source Address Format" must be known to every AFBR, and every AFBR
should not only announce the IP address of one of its E-IPv4 should not only announce the IP address of one of its E-IPv4
interfaces presented in the "v4" field to other AFBRs by MPBGP, but interfaces presented in the "v4" field to other AFBRs by MPBGP, but
also announce the corresponding uPrefix64 to the I-IPv6 network. also announce the corresponding uPrefix64 to the I-IPv6 network.
Since every IP address of upstream AFBR's E-IPv4 interface is Since every IP address of upstream AFBR's E-IPv4 interface is
different from each other, every uPrefix64 that AFBR announces should different from each other, every uPrefix64 that AFBR announces should
be different either, and uniquely identifies each AFBR. "uPrefix64" be different either, and uniquely identifies each AFBR. "uPrefix64"
is an IPv6 prefix, and the distribution of it is the same as the is an IPv6 prefix, and the distribution of it is the same as the
distribution in the traditional mesh unicast scenario. But since distribution in the traditional mesh unicast scenario. But since
"v4" field is an E-IPv4 address, and BGP messages are NOT tunneled "v4" field is an E-IPv4 address, and BGP messages are NOT tunneled
through softwires or through any other mechanism as specified in [8], through softwires or through any other mechanism as specified in
AFBRs MUST be able to transport and encode/decode BGP messages that [RFC5565], AFBRs MUST be able to transport and encode/decode BGP
are carried over I-IPv6, whose NLRI and NH are of E-IPv4 address messages that are carried over I-IPv6, whose NLRI and NH are of
family. E-IPv4 address family.
In this way, when a downstream AFBR receives an E-IPv4 PIM (S,G) In this way, when a downstream AFBR receives an E-IPv4 PIM (S,G)
message, it can translate this message into (S',G') by looking up the message, it can translate this message into (S',G') by looking up the
IP address of the corresponding AFBR's E-IPv4 interface. Since the IP address of the corresponding AFBR's E-IPv4 interface. Since the
uPrefix64 of S' is unique, and is known to every router in the I-IPv6 uPrefix64 of S' is unique, and is known to every router in the I-IPv6
network, the translated message will eventually arrive at the network, the translated message will eventually arrive at the
corresponding upstream AFBR, and the upstream AFBR can translate the corresponding upstream AFBR, and the upstream AFBR can translate the
message back to (S,G). When a downstream AFBR receives an E-IPv4 PIM message back to (S,G). When a downstream AFBR receives an E-IPv4 PIM
(*,G) message, S' can be generated according to the format specified (*,G) message, S' can be generated according to the format specified
in Figure 4, with "source address" field set to *(the IPv4 address of in Figure 4, with "source address" field set to *(the IPv4 address of
RP). The translated message will eventually arrive at the RP). The translated message will eventually arrive at the
corresponding upstream AFBR. Since every PIM router within a PIM corresponding upstream AFBR. Since every PIM router within a PIM
domain must be able to map a particular multicast group address to domain must be able to map a particular multicast group address to
the same RP (see Section 4.7 of [5]), when this upstream AFBR checks the same RP (see Section 4.7 of [RFC4601]), when this upstream AFBR
the "source address" field of the message, it'll find the IPv4 checks the "source address" field of the message, it'll find the IPv4
address of RP, so this upstream AFBR judges that this is originally a address of RP, so this upstream AFBR judges that this is originally a
(*,G) message, then it translates the message back to the (*,G) (*,G) message, then it translates the message back to the (*,G)
message and processes it. message and processes it.
5. IPv6-over-IPv4 Mechanism 5. IPv6-over-IPv4 Mechanism
5.1. Mechanism Overview 5.1. Mechanism Overview
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
skipping to change at page 13, line 31 skipping to change at page 12, line 11
possible, one possible solution to this problem is to limit the scope possible, one possible solution to this problem is to limit the scope
of the E-IPv6 source addresses for mapping, such as applying a "Well- of the E-IPv6 source addresses for mapping, such as applying a "Well-
Known" prefix or an ISP-defined prefix. Known" prefix or an ISP-defined prefix.
5.2. Group Address Mapping 5.2. 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.
A recommended multicast address format is defined in [11]. The high A recommended multicast address format is defined in
order bits of the E-IPv6 address range will be fixed for mapping [I-D.ietf-mboned-64-multicast-address-format]. The high order bits
purposes. With this scheme, each IPv4 multicast address can be of the E-IPv6 address range will be fixed for mapping purposes. With
mapped into an IPv6 multicast address(with the assigned prefix), and this scheme, each IPv4 multicast address can be mapped into an IPv6
each IPv6 multicast address with the assigned prefix can be mapped multicast address(with the assigned prefix), and each IPv6 multicast
into IPv4 multicast address. address with the assigned prefix can be mapped into IPv4 multicast
address.
5.3. Source Address Mapping 5.3. Source Address Mapping
There are two kinds of multicast --- ASM and SSM. Considering that There are two kinds of multicast --- ASM and SSM. Considering that
I-IP network and E-IP network may support different kind of I-IP network and E-IP network may support different kind of
multicast, the source address translation rules could be very complex multicast, the source address translation rules could be very complex
to support all possible scenarios. But since SSM can be implemented to support all possible scenarios. But since SSM can be implemented
with a strict subset of the PIM-SM protocol mechanisms [5], we can with a strict subset of the PIM-SM protocol mechanisms [RFC4601], we
treat I-IP core as SSM-only to make it as simple as possible, then can treat I-IP core as SSM-only to make it as simple as possible,
there remains only two scenarios to be discussed in detail: then there remains only two scenarios to be discussed in detail:
o E-IP network supports SSM o E-IP network supports SSM
To make sure that the translated I-IPv4 PIM message reaches the To make sure that the translated I-IPv4 PIM message reaches the
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
Figure 6 is the reminder of the format: [RFC6052]. Figure 6 is the reminder of the format:
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 0-------------32--40--48--56--64--72--80--88--96-----------127| | 0-------------32--40--48--56--64--72--80--88--96-----------127|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| uPrefix64 |source address | | uPrefix64 |source address |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 6: IPv4-Embedded IPv6 Source Address Format Figure 6: IPv4-Embedded IPv6 Source Address Format
In this address format, the "uPrefix64" field starts with a "Well- In this address format, the "uPrefix64" field starts with a "Well-
Known" prefix or an ISP-defined prefix. An existing "Well-Known" Known" prefix or an ISP-defined prefix. An existing "Well-Known"
prefix is 64:ff9b/32, which is defined in [9]; "source address" prefix is 64:ff9b/32, which is defined in [RFC6052]; "source
field is the corresponding I-IPv4 source address. address" field is the corresponding I-IPv4 source address.
o E-IP network supports ASM o E-IP network supports ASM
The (S,G) source list entry and the (*,G) source list entry only The (S,G) source list entry and the (*,G) source list entry only
differ in that the latter have both the WC and RPT bits of the differ in that the latter have both the WC and RPT bits of the
Encoded-Source-Address set, while the former all cleared (See Encoded-Source-Address set, while the former all cleared (See
Section 4.9.5.1 of [5]). So we can translate source list entries Section 4.9.5.1 of [RFC4601]). So we can translate source list
in (*,G) messages into source list entries in (S'G') messages by entries in (*,G) messages into source list entries in (S',G')
applying the format specified in Figure 5 and setting both the WC messages by applying the format specified in Figure 5 and setting
and RPT bits at upstream AFBRs, and translate them back at both the WC and RPT bits at downstream AFBRs, and translate them
upstream AFBRs vice versa. Here, the E-IPv6 address of RP MUST back at upstream AFBRs vice-versa. Here, the E-IPv6 address of RP
follow the format specified in Figure 6. RP' is the upstream AFBR MUST follow the format specified in Figure 6. RP' is the upstream
that locates between RP and the downstream AFBR. AFBR that locates between RP and the downstream AFBR.
5.4. Routing Mechanism 5.4. Routing Mechanism
In the mesh multicast scenario, routing information is required to be In the mesh multicast scenario, routing information is required to be
distributed among AFBRs to make sure that PIM messages that a distributed among AFBRs to make sure that PIM messages that a
downstream AFBR propagates reach the right upstream AFBR. downstream AFBR propagates reach the right upstream AFBR.
To make it feasible, the /96 uPrefix64 must be known to every AFBR, To make it feasible, the /96 uPrefix64 must be known to every AFBR,
every E-IPv6 address of sources that support mesh multicast MUST every E-IPv6 address of sources that support mesh multicast MUST
follow the format specified in Figure 6, and the corresponding follow the format specified in Figure 6, and the corresponding
skipping to change at page 15, line 22 skipping to change at page 14, line 16
translate the message into (S',G') by simply taking off the prefix in translate the message into (S',G') by simply taking off the prefix in
S. Since S' is known to every router in I-IPv4 network, the S. Since S' is known to every router in I-IPv4 network, the
translated message will eventually arrive at the corresponding translated message will eventually arrive at the corresponding
upstream AFBR, and the upstream AFBR can translate the message back upstream AFBR, and the upstream AFBR can translate the message back
to (S,G) by appending the prefix to S'. When a downstream AFBR to (S,G) by appending the prefix to S'. When a downstream AFBR
receives a (*,G) message, it can translate it into (S',G') by simply receives a (*,G) message, it can translate it into (S',G') by simply
taking off the prefix in *(the E-IPv6 address of RP). Since S' is taking off the prefix in *(the E-IPv6 address of RP). Since S' is
known to every router in I-IPv4 network, the translated message will known to every router in I-IPv4 network, the translated message will
eventually arrive at RP'. And since every PIM router within a PIM eventually arrive at RP'. And since every PIM router within a PIM
domain must be able to map a particular multicast group address to domain must be able to map a particular multicast group address to
the same RP (see Section 4.7 of [5]), RP' knows that S' is the mapped the same RP (see Section 4.7 of [RFC4601]), RP' knows that S' is the
I-IPv4 address of RP, so RP' will translate the message back to (*,G) mapped I-IPv4 address of RP, so RP' will translate the message back
by appending the prefix to S' and propagate it towards RP. to (*,G) by appending the prefix to S' and propagate it towards RP.
6. Control Plane Functions of AFBR 6. Control Plane Functions of AFBR
The AFBRs are responsible for the following functions: The AFBRs are responsible for the following functions:
6.1. E-IP (*,G) State Maintenance 6.1. E-IP (*,G) State Maintenance
When an AFBR wishes to propagate a Join/Prune(*,G) message to an I-IP When an AFBR wishes to propagate a Join/Prune(*,G) message to an I-IP
upstream router, the AFBR MUST translate Join/Prune(*,G) messages upstream router, the AFBR MUST translate Join/Prune(*,G) messages
into Join/Prune(S',G') messages following the rules specified above, into Join/Prune(S',G') messages following the rules specified above,
skipping to change at page 16, line 36 skipping to change at page 15, line 4
transit core. Since the translated source address starts with the transit core. Since the translated source address starts with the
unique "Well-Known" prefix or the ISP-defined prefix that should not unique "Well-Known" prefix or the ISP-defined prefix that should not
be used otherwise, mesh multicast won't influence non-transit PIM-SM be used otherwise, mesh multicast won't influence non-transit PIM-SM
multicast at all. When one AFBR receives an I-IP (S',G') message, it multicast at all. When one AFBR receives an I-IP (S',G') message, it
should check S'. If S' starts with the unique prefix, it means that should check S'. If S' starts with the unique prefix, it means that
this message is actually a translated E-IP (S,G) or (*,G) message, this message is actually a translated E-IP (S,G) or (*,G) message,
then the AFBR should translate this message back to E-IP PIM message then the AFBR should translate this message back to E-IP PIM message
and process it. and process it.
6.4. E-IP (S,G,rpt) State Maintenance 6.4. E-IP (S,G,rpt) State Maintenance
When an AFBR wishes to propagate a Join/Prune(S,G,rpt) message to an When an AFBR wishes to propagate a Join/Prune(S,G,rpt) message to an
I-IP upstream router, the AFBR MUST do as specified in Section 6.5 I-IP upstream router, the AFBR MUST do as specified in Section 6.5
and Section 6.6. and Section 6.6.
6.5. Inter-AFBR Signaling 6.5. Inter-AFBR Signaling
Assume that one downstream AFBR has joined a RPT of (*,G) and a SPT Assume that one downstream AFBR has joined a RPT of (*,G) and a SPT
of (S,G), and decide to perform a SPT switchover. According to [5], of (S,G), and decide to perform a SPT switchover. According to
it should propagate a Prune(S,G,rpt) message along with the [RFC4601], it should propagate a Prune(S,G,rpt) message along with
periodical Join(*,G) message upstream towards RP. Unfortunately, the periodical Join(*,G) message upstream towards RP. Unfortunately,
routers in I-IP transit core are not supposed to understand (S,G,rpt) routers in I-IP transit core are not supposed to understand (S,G,rpt)
messages since I-IP transit core is treated as SSM-only. As a messages since I-IP transit core is treated as SSM-only. As a
result, this downstream AFBR is unable to prune S from this RPT, then result, this downstream AFBR is unable to prune S from this RPT, then
it will receive two copies of the same data of (S,G). In order to it will receive two copies of the same data of (S,G). In order to
solve this problem, we introduce a new mechanism for downstream AFBRs solve this problem, we introduce a new mechanism for downstream AFBRs
to inform upstream AFBRs of pruning any given S from RPT. to inform upstream AFBRs of pruning any given S from RPT.
When a downstream AFBR wishes to propagate a (S,G,rpt) message When a downstream AFBR wishes to propagate a (S,G,rpt) message
upstream router, it should encapsulate the (S,G,rpt) message, then upstream, it should encapsulate the (S,G,rpt) message, then unicast
unicast the encapsulated message to the corresponding upstream AFBR, the encapsulated message to the corresponding upstream AFBR, which we
which we call "RP'". call "RP'".
When RP' receives this encapsulated message, it should decapsulate When RP' receives this encapsulated message, it should decapsulate
this message as what it does in the unicast scenario, and get the this message as what it does in the unicast scenario, and get the
original (S,G,rpt) message. The incoming interface of this message original (S,G,rpt) message. The incoming interface of this message
may be different from the outgoing interface which propagates may be different from the outgoing interface which propagates
multicast data to the corresponding downstream AFBR, and there may be multicast data to the corresponding downstream AFBR, and there may be
other downstream AFBRs that need to receive multicast data of (S,G) other downstream AFBRs that need to receive multicast data of (S,G)
from this incoming interface, so RP' should not simply process this from this incoming interface, so RP' should not simply process this
message as specified in [5] on the incoming interface. message as specified in [RFC4601] on the incoming interface.
To solve this problem, and keep the solution as simple as possible, To solve this problem, and keep the solution as simple as possible,
we introduce an "interface agent" to process all the encapsulated we introduce an "interface agent" to process all the encapsulated
(S,G,rpt) messages the upstream AFBR receives, and prune S from the (S,G,rpt) messages the upstream AFBR receives, and prune S from the
RPT of group G when no downstream AFBR wants to receive multicast RPT of group G when no downstream AFBR wants to receive multicast
data of (S,G) along the RPT. In this way, we do insure that data of (S,G) along the RPT. In this way, we do insure that
downstream AFBRs won't miss any multicast data that they needs, at downstream AFBRs won't miss any multicast data that they needs, at
the cost of duplicated multicast data of (S,G) along the RPT received the cost of duplicated multicast data of (S,G) along the RPT received
by SPT-switched-over downstream AFBRs, if there exists at least one by SPT-switched-over downstream AFBRs, if there exists at least one
downstream AFBR that hasn't yet sent Prune(S,G,rpt) messages to the downstream AFBR that hasn't yet sent Prune(S,G,rpt) messages to the
skipping to change at page 19, line 11 skipping to change at page 17, line 26
little as possible, and after the moment that every AFBR has little as possible, and after the moment that every AFBR has
performed the SPT switchover for every S of group G, no data will be performed the SPT switchover for every S of group G, no data will be
forwarded in the RPT of G, thus no more redundancy will be produced. forwarded in the RPT of G, thus no more redundancy will be produced.
6.7. Other PIM Message Types 6.7. Other PIM Message Types
Apart from Join or Prune, there exists other message types including Apart from Join or Prune, there exists other message types including
Register, Register-Stop, Hello and Assert. Register and Register- Register, Register-Stop, Hello and Assert. Register and Register-
Stop messages are sent by unicast, while Hello and Assert messages Stop messages are sent by unicast, while Hello and Assert messages
are only used between dierctly linked routers to negotiate with each are only used between dierctly linked routers to negotiate with each
other. It's no necessary to translate them for forwarding, thus the other. It's not necessary to translate them for forwarding, thus the
process of these messages is out of scope for this document. process of these messages is out of scope for this document.
6.8. Other PIM States Maintenance 6.8. Other PIM States Maintenance
Apart from states mentioned above, there exists other states Apart from states mentioned above, there exists other states
including (*,*,RP) and I-IP (*,G') state. Since we treat I-IP core including (*,*,RP) and I-IP (*,G') state. Since we treat I-IP core
as SSM-only, the maintenance of these states is out of scope for this as SSM-only, the maintenance of these states is out of scope for this
document. document.
7. Data Plane Functions of AFBR 7. Data Plane Functions of AFBR
skipping to change at page 20, line 23 skipping to change at page 18, line 7
should encapsulate/decapsulate this packet and forward it to such should encapsulate/decapsulate this packet and forward it to such
outgoing interface(s), then forward the data to other outgoing outgoing interface(s), then forward the data to other outgoing
interfaces without encapsulation/decapsulation. interfaces without encapsulation/decapsulation.
When a downstream AFBR that has already switched over to SPT of S When a downstream AFBR that has already switched over to SPT of S
receives an encapsulated multicast data packet of (S,G) along the receives an encapsulated multicast data packet of (S,G) along the
RPT, it should silently drop this packet. RPT, it should silently drop this packet.
7.2. Selecting a Tunneling Technology 7.2. Selecting a Tunneling Technology
The choice of tunneling technology is a matter of policy configured Choosing tunneling technology depends on the policies configured at
at AFBRs. It's recommended that all AFBRs use the same technology, AFBRs. It's recommended that all AFBRs use the same technology,
otherwise some AFBRs may not be able to decapsulate encapsulated otherwise some AFBRs may not be able to decapsulate encapsulated
packets from other AFBRs that use a different tunneling technology. packets from other AFBRs that use a different tunneling technology.
7.3. TTL 7.3. TTL
The processing of TTL depends on the tunneling technology, and is out Processing of TTL depends on the tunneling technology, and is out of
of scope for this document. scope of this document.
7.4. Fragmentation 7.4. Fragmentation
The encapsulation performed by upstream AFBR will increase the size The encapsulation performed by upstream AFBR will increase the size
of packets. As a result, the outgoing I-IP link MTU may not 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 accommodate the extra size. As it's not always possible for core
operators to increase every link's MTU, fragmentation and operators to increase the MTU of every link. Fragmentation and
reassembling of encapsulated packets MUST be supported by AFBRs. reassembling of encapsulated packets MUST be supported by AFBRs.
8. Security Considerations 8. Security Considerations
The AFBR routers could maintain secure communications through the use The AFBR routers could maintain secure communications within Security
of Security Architecture for the Internet Protocol as described in Architecture for the Internet Protocol as described in [RFC4301].
[RFC4301]. But when adopting some schemes that will cause heavy But when adopting some schemes that will cause heavy burden on
burden on routers, some attacker may use it as a tool for DDoS routers, some attacker may use it as a tool for DDoS attack.
attack.
9. IANA Considerations 9. 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, such that ingress AFBRs and egress
can finish the mapping procedure correctly. The IPv6 prefix for AFBRs can finish the mapping procedure correctly. The IPv6 prefix
translation can be unified within only the transit core, or within for translation can be unified within only the transit core, or
global area. In the later condition, the prefix should be assigned within global area. In the later condition, the prefix should be
by IANA. assigned by IANA.
10. References 10. References
10.1. Normative References 10.1. Normative References
[1] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
"Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000.
[2] Foster, B. and F. Andreasen, "Media Gateway Control Protocol [RFC3991] Foster, B. and F. Andreasen, "Media Gateway Control
(MGCP) Redirect and Reset Package", RFC 3991, February 2005. Protocol (MGCP) Redirect and Reset Package", RFC 3991,
February 2005.
[3] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998. Architecture", RFC 2373, July 1998.
[4] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[5] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): "Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006. Protocol Specification (Revised)", RFC 4601, August 2006.
[6] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire Problem [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire
Statement", RFC 4925, July 2007. Problem Statement", RFC 4925, July 2007.
[7] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path [RFC5496] 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 [RFC5565] 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, [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
"IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010. October 2010.
[10] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP VPNs", [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP
RFC 6513, February 2012. VPNs", RFC 6513, February 2012.
10.2. Informative References 10.2. Informative References
[11] Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and M. Xu, [I-D.ietf-mboned-64-multicast-address-format]
"IPv6 Multicast Address With Embedded IPv4 Multicast Address", Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and
draft-ietf-mboned-64-multicast-address-format-04 (work in M. Xu, "IPv6 Multicast Address With Embedded IPv4
progress), August 2012. Multicast Address", draft-ietf-mboned-64-multicast-
address-format-05 (work in progress), April 2013.
Appendix A. Acknowledgements Appendix A. Acknowledgements
Wenlong Chen, Xuan Chen, Alain Durand, Yiu Lee, Jacni Qin and Stig Wenlong Chen, Xuan Chen, Alain Durand, Yiu Lee, Jacni Qin and Stig
Venaas provided useful input into this document. Venaas provided useful input into this document.
Authors' Addresses Authors' Addresses
Mingwei Xu Mingwei Xu
Tsinghua University Tsinghua University
Department of Computer Science, Tsinghua University Department of Computer Science, Tsinghua University
Beijing 100084 Beijing 100084
P.R. China P.R. China
Phone: +86-10-6278-5822 Phone: +86-10-6278-5822
Email: xmw@cernet.edu.cn Email: xmw@cernet.edu.cn
Yong Cui Yong Cui
 End of changes. 52 change blocks. 
165 lines changed or deleted 168 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/