idnits 2.17.1 draft-zhang-v6ops-ipv6oa-iwf-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 16, 2012) is 4300 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3122' is defined on line 286, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Zhang 3 Internet-Draft China Telecom 4 Intended status: Standards Track T. Tsou 5 Expires: January 17, 2013 Huawei Technologies (USA) 6 W. Liu 7 Huawei Technologies 8 J. Sun 9 China Telecom 10 July 16, 2012 12 IPv6 over ATM Interworking Function 13 draft-zhang-v6ops-ipv6oa-iwf-01 15 Abstract 17 This document describes an interworking function between IPv6 over 18 ATM (Asynchronous Transfer Mode) and IPv6 over Ethernet. The 19 interworking function enables the communication between ATM and 20 Ethernet by maintaining the multiple states of both of them. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in [RFC2119]. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 17, 2013. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Context and Scope . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.1. Context and Scope . . . . . . . . . . . . . . . . . . . . . 4 66 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . . 4 67 4.1. A general topology for IPv4 and IPv6 networks . . . . . . . 4 68 4.2. Address resolution for downstream . . . . . . . . . . . . . 5 69 4.3. Address resolution for upstream . . . . . . . . . . . . . . 6 70 4.4. Link layer address change in packets . . . . . . . . . . . 6 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 72 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 76 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 79 1. Introduction 81 The IPv4 exhaustion problem draws the attention of the world. There 82 are a number of issues to deal with when network migrates to IPv6. 83 The use of IPoA encapsulation on the U-interface in legacy ATM access 84 networks is predominantly applicable to business users. IP addresses 85 used in the network behind the RG are exchanged using routing 86 protocols that run transparently over the ATM PVCs. Currently, IPoA 87 encapsulation is migrated to an Ethernet aggregation network in 88 [TR101]. This is achieved by means of an IPoA Interworking Function 89 in IPv4 network. This model should continue to be supported in IPv6 90 scenario. 92 In this draft we define an Interworking Function for IPv6 to support 93 IPv6 over ATM, IPv6 over Ethernet, and IPv6 over SDH. In IPv4 94 network, upon receiving a ARP request transmitted from a BNG, the 95 IPoA IWF SHOULD be able to reply with the appropriate MAC address 96 used as the source address for upstream packets. In IPv6 scenario, 97 however, address resolution applies Neighbor Discovery Protocol 98 [RFC4861], which is in a completely different way. As the result, 99 IPv6oA IWF should support both the IPv6 address resolution and the 100 functions of IPv4oA IWF in the following way. 102 For upstream packets, the IPoA IWF MUST use a MAC source address that 103 is under the control of the Access Node (e.g. the MAC address of the 104 Access Node uplink).For upstream unicast packets, the IPoA IWF MUST 105 use a MAC unicast destination address of the BNG. For upstream 106 multicast and broadcast packets, the IPoA IWF MUST derive the MAC 107 destination address using the standard multicast/broadcast IP address 108 to MAC address conversion algorithm. 110 For downstream, BNG need to know which downstream interface that it 111 should forward to when receiving a packet from internet. IPv6 112 address resolution is necessary in this scenario. When there are 113 multiple BNGs in the metro networks, the IPv6oA IWF need to know 114 exactly which BNG it should send to. In this case IPv6oA IWF need do 115 IP address resolution. If Layer 2 information (such as MAC) is 116 included in a Neighbor Discovery packet, IPv6oA IWF need make sure 117 the carried information is identical to the layer 2 information in 118 packet. In a word, IPoA IWF should do some additional work when 119 networks migrate from IPv4 to IPv6. 121 2. Terminology 123 This document makes use of the following terms: 125 IPv6oA IWF: IPv6 over ATM interworking function 126 BNG: Broadband Network Gateway is the IP edge where user services 127 are performed. 128 ATM: Asynchronous Transfer Mode 129 RG: Residential Gateway 130 PVC: permanent virtual circuit 132 3. Context and Scope 134 3.1. Context and Scope 136 There are many kinds of access protocols between CPE and BNG device. 137 When IPv4 network migrates to IPv6 network, the access protocol must 138 be taken into account. This draft outlines how an IPv6 over ATM 139 access network, or an IPv6 over SDH can be migrated to an Ethernet 140 based IPv6 network. 142 This document focuses only on interworking function between IPv6 over 143 ATM networks, IPv6 over SDH, and Ethernet based IPv6 networks. In 144 the following, we use IPv6 over ATM to illustrate our main idea. The 145 scenarios include CPE devices that support Inverse Neighbor Discovery 146 [RFC3122]and BNG devices that support Neighbor Discovery based on 147 Ethernet. The IPv6oA interworking function makes sure the two kinds 148 of devices can communicate smoothly. The IPv6oA IWF may exist in 149 CPEs, BNGs or Access nodes(AN). 151 4. Solution Overview 153 This section describes solutions for problems mentioned above. 155 4.1. A general topology for IPv4 and IPv6 networks 156 ---------- 157 /// \\\ 158 +------+ IPv6 over +-------------+ // \\ +----------+ 159 | | ATM | || || | 160 | CPE +-----------+ IPv6oA IWF | Ethernet base | BNG | 161 | | | | IPv6 network | | 162 +------+ +-------------+| |+----------+ 163 \\ // 164 \\\ /// 165 ---------- 167 Figure 1: Topology for IPv6 over ATM IWF 169 IPv6oA IWF exists in a node that lies between two kinds of networks, 170 IPv6 over ATM and Ethernet base IPv6 network, as shown in Figure 1. 171 [RFC3122]describes extensions to the IPv6 Neighbor Discovery that 172 allow a node to determine and advertise an IPv6 address corresponding 173 to a given link-layer address. These extensions are called Inverse 174 Neighbor Discovery (IND). IPv6 Neighbor Discovery protocol based 175 Ethernet is used to discover each other's presence, to determine each 176 other's link-layer addresses, to find routers, and to maintain 177 reachability information about the paths to active neighbors. The 178 IPv6oA interworking function is proposed to make sure the two kinds 179 of devices, CPE devices that support Inverse Neighbor Discovery and 180 BNG devices that support Neighbor Discovery based on Ethernet, can 181 communicate smoothly. IPv6oA IWF changes packets from IPoA to IPoE 182 in upstream direction and ones from IPoE to IPoA in downstream 183 direction, respectively. The encapsulation specification can be find 184 in [TR101]. 186 4.2. Address resolution for downstream 188 When a BNG receives a packet from internet sent to a CPE, if the BNG 189 does not know the corresponding link-layer address, it checks the 190 neighbor cache entries to get the link layer address, i.e., the MAC 191 address in Ethernet. If the link layer address of corresponding 192 destination IP address can not be found there, the BNG initiates an 193 address resolution as described in charter 7.2 of [RFC4861]. The BNG 194 parses the destination IP address in the packet aiming to the CPE and 195 include the parsed IP address in Target Address field of Neighbor 196 Solicitation Message. Then BNG will send Neighbor Solicitation to 197 its downstream interface. 199 When IPv6oA IWF receives the Neighbor Solicitation Message from a 200 BNG, it have to make sure the IP address that need to be resolved is 201 on link IP address. IPv6oA IWF will initiate an Inverse Neighbor 202 Discovery Solicitation to CPE. When IPv6oA IWF receives the Inverse 203 Neighbor Discovery Advertisements from a CPE for the resolution IP 204 address, it checks the Source/Destination Address List for the IP 205 address to be resolved. If the IP address is in the list, then 206 IPv6oA IWF can response the Neighbor Solicitation Message from BNG 207 with Neighbor Advertisement Message. IPv6oA IWF sets the MAC of 208 node's upstream interface to Source/Destination Link-layer Address 209 option field in Neighbor Advertisement Message. Then IPv6oA IWF can 210 receive packets sent to CPE and forward them according to IPoA 211 encapsulation specification. 213 When IPv6oA IWF sends Inverse Neighbor Discovery Message, it can 214 change the Neighbor Solicitation Message from BNG to Inverse Neighbor 215 Discovery Solicitation message or change the Inverse Neighbor 216 Discovery Advertisements message from CPE to Neighbor Advertisements 217 message since IND protocol is just the extensions to the IPv6 218 Neighbor Discovery. IPv6oA IWF can work in layer 2 nodes. For 219 upstream packets, the IPoA IWF MUST use a MAC source address that is 220 under the control of the Access Node (e.g. the MAC address of the 221 Access Node uplink).For upstream unicast packets, the IPoA IWF MUST 222 use a MAC unicast destination address of the BNG. For upstream 223 multicast and broadcast packets, the IPoA IWF MUST derive the MAC 224 destination address using the standard multicast/broadcast IP address 225 to MAC address conversion algorithm. 227 4.3. Address resolution for upstream 229 When there are multiple BNGs in a metro network, in other word, 230 multiple IP edges in same networks, IPv6oA IWF needs to know which 231 BNG it will send according to destination IP in the packets received 232 from the CPE. IPv6oA IWF could configure the different BNG IPs and 233 MACs as the next hop by filtering the destination IP address of 234 packets to be sent. If we do not configure this information, IPv6oA 235 IWF needs to finish address resolution for upstream packets. For 236 simplicity, it is suggested to manually configure the BNG IP and MAC 237 on IPv6oA IWF node. 239 When IPv6oA IWF receives Inverse Neighbor Discovery Solicitation, it 240 responses Inverse Neighbor Discovery Advertisement with Source/ 241 Destination Address List in the message. The Source/Destination 242 Address List includes the IPv6 address of BNG's downstream interface. 243 Source/Destination Address List can be configured or accessed from 244 Neighbor Cache entries. 246 When IPv6oA IWF receives IPv6 packets sent to a BNG, it makes address 247 resolution. IPv6oA IWF needs to establish Neighbor Solicitation 248 Message and support address resolution mentioned in charter 7.2 of 249 [RFC4861]. After it receives Neighbor Advertisement message, 250 Neighbor Cache entries will be established according to the reply 251 from BNG. IPv6 IWF then changes IPoA packets to IPoE packets 252 according to [TR101]. The destination MAC address and the source MAC 253 address are set as the resolved link address and the upstream link 254 address of IPv6oA IWF, respectively. 256 4.4. Link layer address change in packets 258 Inverse Neighbor Discovery Solicitation, Neighbor Solicitation, 259 Router Solicitation, and Router Advertisement packets may include a 260 Source/Destination Link-layer Address option in the packet. Inverse 261 Neighbor Discovery Advertisement, Neighbor Advertisement and Redirect 262 packets may include a Source/Destination Link-layer Address option in 263 the packet. After IPv6oA IWF gets these packets from CPE or from 264 BNG, it checks whether there is a Source/Destination Link-layer 265 Address option in the packets. If yes, it changes the Source/ 266 Destination Link-layer Address option value to Ethernet Link-layer 267 Address (such as upstream interface MAC address of Access Node that 268 IPv6oA IWF lies in ) for upstream packets or ATM Link-layer Address 269 for downstream packets. 271 5. Security Considerations 273 6. Acknowledgments 275 7. IANA Considerations 277 8. References 279 8.1. Normative References 281 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 282 Requirement Levels", BCP 14, RFC 2119, March 1997. 284 8.2. Informative References 286 [RFC3122] Conta, A., "Extensions to IPv6 Neighbor Discovery for 287 Inverse Discovery Specification", RFC 3122, June 2001. 289 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 290 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 291 September 2007. 293 [TR101] Boardband-forum, "Migration to Ethernet-Based Broadband 294 Aggregation", Jul 2011, . 297 Authors' Addresses 299 Jiexin Zhang 300 China Telecom 301 NO 1835, Dongnan RD, Pudong DIST 302 Shanghai, 303 P.R. China 305 Email: estrellazhang2012@gmail.com 306 Tina Tsou 307 Huawei Technologies (USA) 308 2330 Central Expressway 309 Santa Clara, CA 95050 310 USA 312 Phone: +1 408 330 4424 313 Email: tina.tsou.zouting@huawei.com 315 Will Liu 316 Huawei Technologies 317 Bantian, Longgang DIST 318 Shenzhen 518129 319 P.R. China 321 Phone: +86 755 28972315 322 Email: liushucheng@huawei.com 324 Jianping Sun 325 China Telecom 326 NO 1835, Dongnan RD, Pudong DIST 327 Shanghai, 328 China 330 Email: sunjp@sttri.com.cn