Network Working Group M. Xu Internet-Draft Y. Cui Expires: September 8, 2010 Tsinghua University Chris. Metz Cisco Systems March 7, 2010 Softwire Mesh Multicast draft-xu-softwire-4over6multicast-02 Abstract The client networks could be of different address family with the core network during IPv6 transition period. The client networks may need to run IP multicast applications across the transit core while it's not well supported currently. This memo provides a AFBR-based softwire mesh multicast framework for IPv6 transition. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 8, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Xu, et al. Expires September 8, 2010 [Page 1] Internet-Draft softwire mcast framework March 2010 Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Xu, et al. Expires September 8, 2010 [Page 2] Internet-Draft softwire mcast framework March 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Softwire Mesh Multicast . . . . . . . . . . . . . . . . . . . 6 3.1. Schemes for Unicast core . . . . . . . . . . . . . . . . . 6 3.2. Schemes for Multicast core . . . . . . . . . . . . . . . . 6 3.2.1. Many to one mapping . . . . . . . . . . . . . . . . . 6 3.2.2. One to one mapping . . . . . . . . . . . . . . . . . . 6 4. RPF-Vector-Based Address Translation . . . . . . . . . . . . . 8 5. Inter-AFBR(Address Family Border Router) signaling . . . . . . 10 5.1. Address Mapping . . . . . . . . . . . . . . . . . . . . . 10 5.2. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . 11 5.3. Control Plane . . . . . . . . . . . . . . . . . . . . . . 11 5.4. SPT Scheme . . . . . . . . . . . . . . . . . . . . . . . . 13 5.5. Shared Tree Scheme . . . . . . . . . . . . . . . . . . . . 14 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Xu, et al. Expires September 8, 2010 [Page 3] Internet-Draft softwire mcast framework March 2010 1. Introduction The Internet will need to support IPv4 and IPv6 packets. Both address families and their attendent protocol suites support multicast of the single-source and any-source varieties. As part of the transition to IPv6, there will be scenarios where a backbone network running one IP address family internally (referred to as internal IP or I-IP) will provide transit services to attached client networks running another IP address family (referred to as external IP or E-IP). It is expected that the I-IP core will offer unicast and multicast transit services to the client E-IP client networks.[I-D.draft-metz-softwires-multicast-problem-statement-00] The multicast framework for IPv6 transition can be described like this: As the multicast group members and multicast sources(or RP) of the group may be scattered in different client networks. In order to transfer multicast traffic to the group members, softwire can be used. In the control layer, the distribution trees must cover both the transit core and client networks, so we need to connect the transit core and client distribution trees together for a multicast group in AFBRs. It doesn't need any changes to construct the client distribution trees, but a distribution tree needs to be constructed by the core network, which could support multicast or not. If the core supports multicast, a core tree can be constructed to help transfer multicast traffic efficiently. However, if not, the AFBRs have to replicate the multicast data and transfer them to other AFBRs in mVPN-like mode.. After giving the detailed scenario in the next section, we will give an overview of softwire mesh multicast. Then a detailed introduction of one to one mapping will be given, as many to one or all to one has been realized by mVPN[I-D.ietf-l3vpn-2547bis-mcast]. Here mapping means the relation between multicast groups in client networks and multicast groups in the core network. We mainly talk about PIM-SM(SSM) here as it's a representative multicast protocol. Xu, et al. Expires September 8, 2010 [Page 4] Internet-Draft softwire mcast framework March 2010 2. Scenario -------- |Receiver| -------- | ._._._._. ._._._._. | | | | -------- | E-IP | | E-IP |--|Source S| | network | | network | -------- ._._._._. ._._._._. | | AFBR upstream AFBR Dual-Stack Dual-Stack | | __+____________________+__ / : : : : \ | : : : : | E-IP Multicast | : I-IP transit core : | message should | : : : : | get across the | : : : : | I-IP transit core \_._._._._._._._._._._._._./ + + downstream AFBR downstream AFBR Dual-Stack Dual-Stack | | ._._._._ ._._._._ -------- | | | | -------- |Receiver|-- | E-IP | | E-IP #|--|Receiver| -------- |network | |network | -------- ._._._._ ._._._._ Figure 1: Softwire Multicast Scenario The softwire multicast framework is illustrated in Figure 1. Multicast source S is in one client network, while its receivers may be in the same or different networks. When they are not in the same client network, they have to communicate with each other through the I-IP transit core. There may be several sources at the same time, and they can also reside in different client networks. What's more, when considering about RP, it may be in a different network with any sources. Some terminology is defined as follows: o Softwire (SW) - A "tunnel" that is created on the basis of a Xu, et al. Expires September 8, 2010 [Page 5] Internet-Draft softwire mcast framework March 2010 control protocol setup between softwire endpoints with a shared point-to- point, multipoint-to-point, point-to-multipoint or multipoint-to-multipoing state. Softwires are generally dynamic in nature (they may be initiated and terminated on demand), but may be very long-lived. o Address Family Border Router (AFBR) - The dual-stack router that interconnects two networks that use different address families. In the context of softwires multicast, the AFBR runs E-IP and I-IP control planes to maintain E-IP and I-IP multicast state respectively and performs the appropriate encapsulation/decapsultion client E-IP multicast packets for transport across the I-IP core. o I-IP ("Internal IP"). This refers to the form of IP (i.e., either IPv4 or IPv6) that is supported by the transit (or backbone) network. o E-IP ("External IP") This refers to the form of IP (i.e. either IPv4 or IPv6) that is supported by the client networks. o I-IP core Tree. A single-source or multi-source distribution tree rooted at one or more AFBR source nodes and branching out to one or more AFBR leaf nodes. An I-IP core Tree is built using standard IP or MPLS multicast signaling protocols operating exclusively inside the I-IP core network. An I-IP core Tree is used to tunnel E-IP multicast packets belonging to E-IP trees across the I-IP core. Another name for an I-IP core Tree is multicast or multipoint softwire. o E-IP client tree. A single-source or multi-source distribution tree rooted at one or more hosts or routers located inside a client E-IP network and branching out to one or more leaf nodes located in the same or different client E-IP networks. o upstream AFBR: The AFBR router that located at the upstream of multicast data flow, which connects the transit core and the client network the RP/source S belongs to. o downstream AFBR: The AFBR router that located at the downstream of multicast data flow, which connects the transit core and the client network which a group member of RP/source belongs to while the RP/ source doesn't belongs to. Xu, et al. Expires September 8, 2010 [Page 6] Internet-Draft softwire mcast framework March 2010 3. Softwire Mesh Multicast We face all kinds of scenarios, the I-IP transit core may support multicast, or not. We have multiple choices if it does. However, we have to make use of unicast to transfer the multicast traffic. 3.1. Schemes for Unicast core In some scenarios, the I-IP transit core does not run multicast protocols, and thus AFBRs can not construct multicast distribution trees in the I-IP transit core. Under this condition the multicast control messages and data traffic from client networks are encapsulated and decapsulated as common packets to get across the core. There are two alternative schemes in this scenario. One is the ingress AFBR will replicate the packets to all the other AFBRs, which is an easy solution as the AFBR knows the information of the other AFBRs throught MP-BGP using softwire. The other one is the ingress AFBR will replicate the packets to the necessary AFBRs, that is, the AFBRs behind which have group members. The latter one is more complex because the group members' location must be known. 3.2. Schemes for Multicast core When the I-IP transit core supports multicast, we can build a multicast tree or several multicast trees in the core so as to transfer the traffic from the client network. According to the number of groups in the core corresponding to the groups in the client networks, there are many to one mapping and one to one mapping to construct the multicast trees in the core. 3.2.1. Many to one mapping Using this mapping method, many groups in client networks will be mapped into the same group in the core. Under some conditions, all groups in client networks will be mapped into the same group, as it's the simplest mapping method. Many to one mapping has been well realized by mVPN[I-D.ietf-l3vpn- 2547bis-mcast], where traffic from multiple MVPNs will be aggregated into a single multicast distribution tree. Thus many groups are mapped into the same group in the core. 3.2.2. One to one mapping Using many to one mapping, the management could be easier, but members of different groups may be scattered in different client Xu, et al. Expires September 8, 2010 [Page 7] Internet-Draft softwire mcast framework March 2010 networks and when they are mapped into the same group, some AFBRs may receive unnecessary packets of some group when it doesn't belong to the group. For examle, group A and B which belong to client networks are mapped into the same group C in the core. Assume that in a client network, there are members of A while no member of B. But group C must transfer the traffic whenever it belongs to group A or B of the client networks. So the AFBR of this client network may receive unnecessary packets(like packets of group B) if nothing is done in the upstream. There are several ways to realize one to one mapping. Here we will introduce two of them. One is based on RPF-Vector and the other is through inter-AFBR signaling. Xu, et al. Expires September 8, 2010 [Page 8] Internet-Draft softwire mcast framework March 2010 4. RPF-Vector-Based Address Translation The main idea of address translation is to translate E-IP addresses of the Join/Prune messages to I-IP addresses. Therefore, E-IP multicast messages can be translated to corresponding I-IP multicast messages at ingress AFBRs, and then back to E-IP multicast messages after arriving at egress AFBRs. The translation procedure should follow some predefined rules, so that ingress AFBR and egress AFBR can finish the translation and retranslation procedure correctly without negotiation. For example, if E-IP is IPv4 and I-IP is IPv6, the ingress AFBR uses a predefined IPv6 prefix for any case to translate an IPv4 address to an IPv6 address, and the predefined IPv6 prefix combined with the IPv4 address makes up the new IPv6 address in the IPv6 transit core. Then the egress AFBR can easily retranslate it to the original IPv4 address by simply removing the predefined IPv6 prefix. Since the source and group addresses in the I-IP Join/Prune message are translated from E-IP by adding a predefined I-IP prefix, they can not be recognized by P routers to reach the corresponding egress AFBRs. We use an RPF Vector in the Join/Prune message to route them in the I-IP transit core. The RPF Vector is an optional extended PIM attribution, which designates the routers which router the Join/Prune message must pass by. i.e., AFBR A fills the I-IP address of AFBR B in the RPF Vector of Join/Prune message to help it find a route to AFBR B in the transit core. Then the Join/Prune message builds a multicast tree in the transit core and finally arrives at AFBR B. When some multicast data packet arrives at AFBR B, it will be translated to an I-IP packet, and delivered along the I-IP core Tree constructed by the former Join/Prune message in core and arrive at AFBR A. Then AFBR A will translate it back and forward it to the E-IP client network. The address translation scheme is only available when E-IP is IPv4 and I-IP is IPv6. As IPv6 addresses are 128bit long, it is possible to translate an IPv4 address to an IPv6 address by making IPv4 address part of the IPv6 address algorithmically. AFBRs can translate the IPv4 S and G into corresponding IPv4-mapped IPv6 addresses [RFC4291], and then be translated back. The precise circumstances under which these translations are done would be a matter of policy. But if E-IP is IPv6 and I-IP is IPv4, the translation can't be achieved easily, more research is needed to fit this condition. Also, an additional RPF Vector must be applied to help to construct the I-IP core Tree in the transit core. To sum up, the address translation method is virtually the same multicast message taking on different appearances in different IP address family networks and the I-IP core Tree is part of the E-IP client Xu, et al. Expires September 8, 2010 [Page 9] Internet-Draft softwire mcast framework March 2010 tree while presenting an I-IP feature. Xu, et al. Expires September 8, 2010 [Page 10] Internet-Draft softwire mcast framework March 2010 5. Inter-AFBR(Address Family Border Router) signaling It's called inter-AFBR signaling because unlike the RPF-Vector-Based address translation, here AFBRs has to send signals to the other AFBRs to construct the whole multicast tree. 5.1. Address Mapping There are two kinds of address associated with multicast: source address and group address. Group address will be discussed in this section and source address later when associated with SPT and shared tree scheme. For softwire mesh multicast, there are two different scenarios when talking about address translation, which is also called address mapping here: IPv4-IPv6-IPv4 scenario and IPv6-IPv4-IPv6 scenario. The previous one is easier to implement one to one mapping as the IPv6 address is longer than the IPv4 one. We can simply add a prefix before the IPv4 address when mapping an E-IP address to an I-IP address, just like figure 2 shows. 0 8 16 96 127 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |FF XX| ISP Assigned Prefix | v4 address| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Figure 2: Mapping from IPv4 to IPv6 address The first two octets must be in accordance with the IPv6 multicast address format defined in section 2.7 of [RFC2373]. The following 10 octets are assigned by administrators of ISP and the last 4 octets are the IPv4 address. But for the IPv6-IPv4-IPv6 scenario, due to the shorter length of IPv4 address, it's not that simple to realize one to one mapping. A feasible solution is partial mapping, which maps only part of IPv6 addresses into IPv4 addresses, like the IPv6 address with a fixed prefix. We won't talk about it here as it prohibits the use of some IPv6 group addresses. We will talk about another solution: an IPv6 address will be hashed into another IPv4 address using some hash function. In this manner, two or more IPv6 addresses may be mapped into the same IPv4 address. But at the same time, only part of the IPv6 addresses are in use, so with a proper hash function, we can achieve one to one mapping approximately. For example, we could use the last three octets of Xu, et al. Expires September 8, 2010 [Page 11] Internet-Draft softwire mcast framework March 2010 IPv6 address to fill in the last three octets of IPv4 address, while the first octet is determined by the administrator. 5.2. Data Plane Assume that group source S wants to send packets to a group member in different client network with S. S will send the packets along the multicast tree of client network(where S locates) to the upstream AFBR first. Then AFBR will encapsulate the packets with a header whose destination is an I-IP multicast address. Thus the packets will flow along the multicast tree of transit core to the downstream AFBR. Having received the packets, the downstream AFBR will first decapsulate the packets, and then judge whether the packets are necessary, which means whether it has group members behind it. If not, it will just discard them, else it will send them along the multicast tree of client network(where D locates) to the receivers. Finally, D will receiver these packets. 5.3. Control Plane There are many control messages in PIM protocol. How to deal with them when they are received by routers, especially AFBR routers is really an important problem. When AFBR receives multicast control messages whose destination is in another client network, it has to maintain the multicast tree in the core, in the mean while, it's responsible to send some of them, like Join or Prune messages, to the client network on the other side of the core. Usually, the messages are tunneled to the other side of the core. The tunneling technology can be GRE, IP-in-IP, MPLS etc. Here we use IP-in-IP, other tunneling method is alike. The upstream AFBR treats the downstream AFBRs as the neighbors on the multicast tree when they send tunneled control messages to it. But unlike native PIM protocol, different neighbors are distinguished by their IP addresses but not by interfaces, because tunneled control messages sent by different downstream AFBRs can arrive at the upstream AFBR through the same interface. Usually, for every group, AFBR will keep a table recording which downstream AFBRs have joined it. The key part is how to maintain the multicast tree in the core. Unlike RPF-Vector-Based scheme, it's not just a process of translation, it's more complicate than that. When AFBR receive E-IP Join messages, the AFBR will judge whether it has already joined the multicast group in the core, if not, then it will send I-IP Join Xu, et al. Expires September 8, 2010 [Page 12] Internet-Draft softwire mcast framework March 2010 messages upstream. Note that the multicast group is not the group of the Join message AFBR has received, it's the group which is mapped from the group of the Join message. When AFBR receive E-IP Prune messages, it will judge whether there are any group members in the client network, if not, it will send I-IP Prune messages upstream. ._._._._. | | -------- | E-IP |--|Source S| | network | -------- ._._._._. | upstream AFBR Dual-Stack | __ __________+_________ _ / : : : : \ | : : : : | | : I-IP transit core : | | : : : : | | : : : : | \_._._._._._._._._._._._._./ + downstream AFBR Dual-Stack | ._._._._ ---------- | | ---------- |Receiver a|-- | E-IP | --|Receiver b| ---------- |network | ---------- ._._._._ Figure 3: Maintain the multicast tree in the core For example as in figure 3, receiver a belongs to group A while b belongs to group B, A and B will be mapped into group C in the core. Firstly, a sends a Join(S,A) message to source S(here we only consider about PIM-SSM for the sake of simplicity), when the message arrives at the downstream AFBR, the AFBR find that it hasn't yet joined group C, so it will send a Join(S',C)(S' will be defined in the next sections) to the core and send an encapsulated packet E(Join(S,A)) to the upstream AFBR. But when b sends a Join(S,B) message to S, when the AFBR receives it, it finds that it has joined group C. Thus it just sends an encapsulated packet E(Join(S,B)) to the upstream AFBR. Then b wants Xu, et al. Expires September 8, 2010 [Page 13] Internet-Draft softwire mcast framework March 2010 to quit group B, it will send a Prune(S,G), when downstream AFBR receives it, it finds there are still members of group C, then it just sends an encapsulated packet E(Prune(S,B)) to the upstream AFBR. After that, a also wants to quit, it sends a Prune(S,A) message, when downstream receives it, it finds no member of C exists, so it sends a Prune(S',C) message to the core while sending an encapsulated packet E(Prune(S,A)) to the upstream AFBR. In order to maintain the multicast tree in the core, besides sending messages to the core and upstream AFBRs invoked by messages received from client network, AFBR also has to send some messages periodically, like hello and Join messages, etc. 5.4. SPT Scheme SPT means we will construct a source specific tree in the core where the source will be a AFBR. We use PIM-SSM as the technology to construct the source specific tree in the core. The data traffic will flow along the multicast tree of the client network to the upstream AFBR, then the upstream AFBR will act as the source of the SPT in the core. In this way, data will flow to the other AFBR where receivers locate behind, finnaly data traffic comes back to the multicast tree of another client network and arrives at the receivers. So E-IP Join/Prune(S,G) messages will be mapped into I-IP Join/ Prune(S',G') messages, where S' is the address of the upstream AFBR and G' is the mapped group address which we talked about previously. In this way, all the routers in the core recognize this I-IP address and the I-IP control messages will be sent to the right AFBR. And E-IP Join/Prune(*,G) messages will also be mapped into I-IP Join/ Prune(S',G') messages where S' is the address of AFBR where RP locates behind. E(Join/Prune(S,G)) or E(Join/Prune(*,G)) will be tunneled to the upstream AFBR while Join/Prune(S',G') will be sent to the core. But for dealing with Join/Prune(S,G,rpt), the downstream AFBR just have to tunnel the E(Join/Prune(S,G,rpt)) to the upstream AFBR, there won't be any Join/Prune(S',G',rpt) sent to the core as we use PIM-SSM in the core. If there are many sources of one group in the same client network. Then they will share the same multicast tree in the core. This will cause some data redundancy, but it's less serious than many to one mapping. Xu, et al. Expires September 8, 2010 [Page 14] Internet-Draft softwire mcast framework March 2010 5.5. Shared Tree Scheme Compared with SPT scheme, shared tree scheme constructs a shared tree in the core. The data traffic will flow to the upstream AFBR, then the upstream AFBR will send the data traffic the the RP of the shared tree in the core. The RP in the core will distribute the traffic to the necessary AFBRs, throught which the traffic will arrive at the receivers. Both E-IP Join/Prune(S,G) and Join/Prune(*,G) will be mapped into Join/Prune(*,G') where G' is a mapped group address. The Join/ Prune(*,G') messages will be sent to the core and the core routers will pass them to RP of group G' in the core. The core routers need to know the information(the address) of the RP in the core. The RP in the core is discovered according to [RFC4601]. At the same time, E(Join/Prune(S,G)) or E(Join/Prune(*,G)) will be tunneled to the upstream AFBR. Thus data traffic will flow to the upstream AFBR. When AFBR receives data of group G, it will take those data, unicast-encapsulates them, and sends them directly to the RP of G' in the core. The RP receives these encapsulated data packets, decapsulates them, and forwards them onto the shared tree. This is just like the register process of [RFC4601]. Also like [RFC4601], RP in the core will switch to native forwarding as register-encapsulation of data packets is inefficient. RP will send an Join(S',G') towards S' and in this way packets from S' starts to arrive natively at the RP. Then RP will send register-stop message to S' when it receives two copies of each of data packets. Like the SPT scheme, when dealing with Join/Prune(S,G,rpt), the downstream AFBR just have to tunnel E(Join/Prune(S,G,rpt)) to the upstream AFBR but not send Join/Prune(S',G',rpt) to the core, as the routers in the core can't distinguish between the packets from RP(of client network) with the packets from source. For each group, there is only one shared tree in the core which is less than SPT scheme. If there are many sources in the group, their packets will follow the same multicast tree when they flow through the core. That means it will cause more serious data redundancy than SPT scheme. But it's still less serious than many to one mapping. For both of SPT Scheme and Shared Tree Scheme, we don't have to worry about assert messages, because it can be done with locally. At the AFBRs, the timers that associated with the other AFBRs must be prolonged, as the control messages or the data may have to travel through the core network for quite a long time. Xu, et al. Expires September 8, 2010 [Page 15] Internet-Draft softwire mcast framework March 2010 6. Summary There are a lot of schemes talked above. To some schemes, several mapping methods exist. Which one to choose depends on the actual situation. When the core network only supports unicast, we have to decided whether to transfer the replication to all the other AFBRs or the necessary AFBRs. The former one is simple but may cause higher redundancy while more AFBRs will receive data they haven't asked for. When the core network supports multicast, we have many choices. Many to one mapping has been realized by mVPN, but it may cause serious data redundancy. RPF-Vector-Based scheme provides a translation scheme and can achieve one-to-one mapping between client networks and the core network. But it only adapts to IPv4-IPv6-IPv4 scenario and has to make use of RPF Vector which is an optional extended attribution of PIM, which many networks can't satisfy. Inter-AFBR signaling is another choice to realize one to one mapping which adapts to both IPv4-IPv6-IPv4 and IPv6-IPv4-IPv6 scenarios. Both SPT and shared multicast tree can be used in the core to transfer multicast traffic, and usually, shared tree scheme creates less trees in the core than SPT scheme. Whether more trees or less trees exist in the core is better, it also depends. More trees can reduce data redundancy while increasing the overhead for managing the trees, that is, there will be more states in the router and more resources will be wasted on processing multicast control message. Thus choosing different schemes always means choosing data redundancy or overhead. If you consider that data redundancy is more important, you can choose a scheme that creates more trees, and vice versa. Xu, et al. Expires September 8, 2010 [Page 16] Internet-Draft softwire mcast framework March 2010 7. Security Considerations The AFBR routers could maintain secure communications through the use of Security Architecture for the Internet Protocol as described in[RFC4301]. But when adopting some schemes whose data redundancy is serious, some attacker may use it as a tool for DDoS attack. Xu, et al. Expires September 8, 2010 [Page 17] Internet-Draft softwire mcast framework March 2010 8. IANA Considerations For Inter-AFBR signaling, address mapping is applied, and it should follow some predefined rule, especially the format of IPv6 prefix for address mapping should be predefined, so that ingress AFBR and egress AFBR can finish the mapping procedure correctly. The format of IPv6 prefix for translation can be unified within only the transit core, or within global area. In the later condition, the format should be assigned by IANA. Xu, et al. Expires September 8, 2010 [Page 18] Internet-Draft softwire mcast framework March 2010 9. References 9.1. Normative References [1] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [2] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [3] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [4] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [5] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire Problem Statement", RFC 4925, July 2007. [6] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh Framework", RFC 5565, June 2009. 9.2. Informative References [7] Wijnands, I., Boers, A., and E. Rosen, "The RPF Vector TLV", draft-ietf-pim-rpf-vector-08 (work in progress), January 2009. [8] Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y., Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-10 (work in progress), January 2010. [9] Metz, C., Cui, Y., and M. Xu, "Softwires Mesh Multicast Problem Statement", draft-metz-softwires-multicast-problem-statement-00 (work in progress), February 2008. Xu, et al. Expires September 8, 2010 [Page 19] Internet-Draft softwire mcast framework March 2010 Authors' Addresses Mingwei Xu Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6278-5822 Email: xmw@csnet1.cs.tsinghua.edu.cn Yong Cui Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6278-5822 Email: cuiyong@tsinghua.edu.cn Chris Metz Cisco Systems 170 West Tasman Drive San Jose, California 95134-1706 USA Phone: +1-408-525-3275 Email: chmetz@cisco.com Xu, et al. Expires September 8, 2010 [Page 20]