Network Working Group J. Zhang Internet-Draft China Telecom Intended status: Standards Track T. Tsou Expires: January 17, 2013 Huawei Technologies (USA) W. Liu Huawei Technologies J. Sun China Telecom July 16, 2012 IPv6 over ATM Interworking Function draft-zhang-v6ops-ipv6oa-iwf-01 Abstract This document describes an interworking function between IPv6 over ATM (Asynchronous Transfer Mode) and IPv6 over Ethernet. The interworking function enables the communication between ATM and Ethernet by maintaining the multiple states of both of them. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 17, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. Zhang, et al. Expires January 17, 2013 [Page 1] Internet-Draft IPv6oA-IWF July 2012 This document is subject to BCP 78 and the IETF Trust's Legal 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 Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Context and Scope . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Context and Scope . . . . . . . . . . . . . . . . . . . . . 4 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. A general topology for IPv4 and IPv6 networks . . . . . . . 4 4.2. Address resolution for downstream . . . . . . . . . . . . . 5 4.3. Address resolution for upstream . . . . . . . . . . . . . . 6 4.4. Link layer address change in packets . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Zhang, et al. Expires January 17, 2013 [Page 2] Internet-Draft IPv6oA-IWF July 2012 1. Introduction The IPv4 exhaustion problem draws the attention of the world. There are a number of issues to deal with when network migrates to IPv6. The use of IPoA encapsulation on the U-interface in legacy ATM access networks is predominantly applicable to business users. IP addresses used in the network behind the RG are exchanged using routing protocols that run transparently over the ATM PVCs. Currently, IPoA encapsulation is migrated to an Ethernet aggregation network in [TR101]. This is achieved by means of an IPoA Interworking Function in IPv4 network. This model should continue to be supported in IPv6 scenario. In this draft we define an Interworking Function for IPv6 to support IPv6 over ATM, IPv6 over Ethernet, and IPv6 over SDH. In IPv4 network, upon receiving a ARP request transmitted from a BNG, the IPoA IWF SHOULD be able to reply with the appropriate MAC address used as the source address for upstream packets. In IPv6 scenario, however, address resolution applies Neighbor Discovery Protocol [RFC4861], which is in a completely different way. As the result, IPv6oA IWF should support both the IPv6 address resolution and the functions of IPv4oA IWF in the following way. For upstream packets, the IPoA IWF MUST use a MAC source address that is under the control of the Access Node (e.g. the MAC address of the Access Node uplink).For upstream unicast packets, the IPoA IWF MUST use a MAC unicast destination address of the BNG. For upstream multicast and broadcast packets, the IPoA IWF MUST derive the MAC destination address using the standard multicast/broadcast IP address to MAC address conversion algorithm. For downstream, BNG need to know which downstream interface that it should forward to when receiving a packet from internet. IPv6 address resolution is necessary in this scenario. When there are multiple BNGs in the metro networks, the IPv6oA IWF need to know exactly which BNG it should send to. In this case IPv6oA IWF need do IP address resolution. If Layer 2 information (such as MAC) is included in a Neighbor Discovery packet, IPv6oA IWF need make sure the carried information is identical to the layer 2 information in packet. In a word, IPoA IWF should do some additional work when networks migrate from IPv4 to IPv6. 2. Terminology This document makes use of the following terms: Zhang, et al. Expires January 17, 2013 [Page 3] Internet-Draft IPv6oA-IWF July 2012 IPv6oA IWF: IPv6 over ATM interworking function BNG: Broadband Network Gateway is the IP edge where user services are performed. ATM: Asynchronous Transfer Mode RG: Residential Gateway PVC: permanent virtual circuit 3. Context and Scope 3.1. Context and Scope There are many kinds of access protocols between CPE and BNG device. When IPv4 network migrates to IPv6 network, the access protocol must be taken into account. This draft outlines how an IPv6 over ATM access network, or an IPv6 over SDH can be migrated to an Ethernet based IPv6 network. This document focuses only on interworking function between IPv6 over ATM networks, IPv6 over SDH, and Ethernet based IPv6 networks. In the following, we use IPv6 over ATM to illustrate our main idea. The scenarios include CPE devices that support Inverse Neighbor Discovery [RFC3122]and BNG devices that support Neighbor Discovery based on Ethernet. The IPv6oA interworking function makes sure the two kinds of devices can communicate smoothly. The IPv6oA IWF may exist in CPEs, BNGs or Access nodes(AN). 4. Solution Overview This section describes solutions for problems mentioned above. 4.1. A general topology for IPv4 and IPv6 networks ---------- /// \\\ +------+ IPv6 over +-------------+ // \\ +----------+ | | ATM | || || | | CPE +-----------+ IPv6oA IWF | Ethernet base | BNG | | | | | IPv6 network | | +------+ +-------------+| |+----------+ \\ // \\\ /// ---------- Figure 1: Topology for IPv6 over ATM IWF IPv6oA IWF exists in a node that lies between two kinds of networks, Zhang, et al. Expires January 17, 2013 [Page 4] Internet-Draft IPv6oA-IWF July 2012 IPv6 over ATM and Ethernet base IPv6 network, as shown in Figure 1. [RFC3122]describes extensions to the IPv6 Neighbor Discovery that allow a node to determine and advertise an IPv6 address corresponding to a given link-layer address. These extensions are called Inverse Neighbor Discovery (IND). IPv6 Neighbor Discovery protocol based Ethernet is used to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. The IPv6oA interworking function is proposed to make sure the two kinds of devices, CPE devices that support Inverse Neighbor Discovery and BNG devices that support Neighbor Discovery based on Ethernet, can communicate smoothly. IPv6oA IWF changes packets from IPoA to IPoE in upstream direction and ones from IPoE to IPoA in downstream direction, respectively. The encapsulation specification can be find in [TR101]. 4.2. Address resolution for downstream When a BNG receives a packet from internet sent to a CPE, if the BNG does not know the corresponding link-layer address, it checks the neighbor cache entries to get the link layer address, i.e., the MAC address in Ethernet. If the link layer address of corresponding destination IP address can not be found there, the BNG initiates an address resolution as described in charter 7.2 of [RFC4861]. The BNG parses the destination IP address in the packet aiming to the CPE and include the parsed IP address in Target Address field of Neighbor Solicitation Message. Then BNG will send Neighbor Solicitation to its downstream interface. When IPv6oA IWF receives the Neighbor Solicitation Message from a BNG, it have to make sure the IP address that need to be resolved is on link IP address. IPv6oA IWF will initiate an Inverse Neighbor Discovery Solicitation to CPE. When IPv6oA IWF receives the Inverse Neighbor Discovery Advertisements from a CPE for the resolution IP address, it checks the Source/Destination Address List for the IP address to be resolved. If the IP address is in the list, then IPv6oA IWF can response the Neighbor Solicitation Message from BNG with Neighbor Advertisement Message. IPv6oA IWF sets the MAC of node's upstream interface to Source/Destination Link-layer Address option field in Neighbor Advertisement Message. Then IPv6oA IWF can receive packets sent to CPE and forward them according to IPoA encapsulation specification. When IPv6oA IWF sends Inverse Neighbor Discovery Message, it can change the Neighbor Solicitation Message from BNG to Inverse Neighbor Discovery Solicitation message or change the Inverse Neighbor Discovery Advertisements message from CPE to Neighbor Advertisements message since IND protocol is just the extensions to the IPv6 Zhang, et al. Expires January 17, 2013 [Page 5] Internet-Draft IPv6oA-IWF July 2012 Neighbor Discovery. IPv6oA IWF can work in layer 2 nodes. For upstream packets, the IPoA IWF MUST use a MAC source address that is under the control of the Access Node (e.g. the MAC address of the Access Node uplink).For upstream unicast packets, the IPoA IWF MUST use a MAC unicast destination address of the BNG. For upstream multicast and broadcast packets, the IPoA IWF MUST derive the MAC destination address using the standard multicast/broadcast IP address to MAC address conversion algorithm. 4.3. Address resolution for upstream When there are multiple BNGs in a metro network, in other word, multiple IP edges in same networks, IPv6oA IWF needs to know which BNG it will send according to destination IP in the packets received from the CPE. IPv6oA IWF could configure the different BNG IPs and MACs as the next hop by filtering the destination IP address of packets to be sent. If we do not configure this information, IPv6oA IWF needs to finish address resolution for upstream packets. For simplicity, it is suggested to manually configure the BNG IP and MAC on IPv6oA IWF node. When IPv6oA IWF receives Inverse Neighbor Discovery Solicitation, it responses Inverse Neighbor Discovery Advertisement with Source/ Destination Address List in the message. The Source/Destination Address List includes the IPv6 address of BNG's downstream interface. Source/Destination Address List can be configured or accessed from Neighbor Cache entries. When IPv6oA IWF receives IPv6 packets sent to a BNG, it makes address resolution. IPv6oA IWF needs to establish Neighbor Solicitation Message and support address resolution mentioned in charter 7.2 of [RFC4861]. After it receives Neighbor Advertisement message, Neighbor Cache entries will be established according to the reply from BNG. IPv6 IWF then changes IPoA packets to IPoE packets according to [TR101]. The destination MAC address and the source MAC address are set as the resolved link address and the upstream link address of IPv6oA IWF, respectively. 4.4. Link layer address change in packets Inverse Neighbor Discovery Solicitation, Neighbor Solicitation, Router Solicitation, and Router Advertisement packets may include a Source/Destination Link-layer Address option in the packet. Inverse Neighbor Discovery Advertisement, Neighbor Advertisement and Redirect packets may include a Source/Destination Link-layer Address option in the packet. After IPv6oA IWF gets these packets from CPE or from BNG, it checks whether there is a Source/Destination Link-layer Address option in the packets. If yes, it changes the Source/ Zhang, et al. Expires January 17, 2013 [Page 6] Internet-Draft IPv6oA-IWF July 2012 Destination Link-layer Address option value to Ethernet Link-layer Address (such as upstream interface MAC address of Access Node that IPv6oA IWF lies in ) for upstream packets or ATM Link-layer Address for downstream packets. 5. Security Considerations 6. Acknowledgments 7. IANA Considerations 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [RFC3122] Conta, A., "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification", RFC 3122, June 2001. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [TR101] Boardband-forum, "Migration to Ethernet-Based Broadband Aggregation", Jul 2011, . Authors' Addresses Jiexin Zhang China Telecom NO 1835, Dongnan RD, Pudong DIST Shanghai, P.R. China Email: estrellazhang2012@gmail.com Zhang, et al. Expires January 17, 2013 [Page 7] Internet-Draft IPv6oA-IWF July 2012 Tina Tsou Huawei Technologies (USA) 2330 Central Expressway Santa Clara, CA 95050 USA Phone: +1 408 330 4424 Email: tina.tsou.zouting@huawei.com Will Liu Huawei Technologies Bantian, Longgang DIST Shenzhen 518129 P.R. China Phone: +86 755 28972315 Email: liushucheng@huawei.com Jianping Sun China Telecom NO 1835, Dongnan RD, Pudong DIST Shanghai, China Email: sunjp@sttri.com.cn Zhang, et al. Expires January 17, 2013 [Page 8]