idnits 2.17.1 draft-chen-behave-rsnat-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 26, 2009) is 5294 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC4966' is defined on line 397, but no explicit reference was found in the text == Unused Reference: 'I-D.bagnulo-behave-nat64' is defined on line 403, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2766 (Obsoleted by RFC 4966) ** Obsolete normative reference: RFC 3768 (Obsoleted by RFC 5798) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Chen 3 Internet-Draft H. Deng 4 Intended status: Experimental B. Zhou 5 Expires: April 29, 2010 China Mobile 6 M. Xu 7 L. Song 8 Y. Cui 9 Tsinghua University 10 October 26, 2009 12 Reliable and Scalable NAT mechanism (RS-NAT) based on BGP for IPv4/IPv6 13 Transition 14 draft-chen-behave-rsnat-02 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on April 29, 2010. 39 Copyright Notice 41 Copyright (c) 2009 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents in effect on the date of 46 publication of this document (http://trustee.ietf.org/license-info). 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. 50 Abstract 52 For the rapid exhaustion of IPv4 address pool against the slow 53 development of IPv6, IPv4/IPv6 co-existence/transition would be a 54 long period. In the IPv4/IPv6 transition process, there are many 55 NAT- like technologies active in the internet. However, the NAT 56 boxes such as IPv4 NAT, IPv4/IPv6 NAT are so poor in their 57 reliability and scalability, which put a severe threat on the 58 development of IPv4/IPv6 transition. This document defines a 59 reliable and scalable NAT (RS- NAT) mechanism to solve the problem. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. RS-NAT Overview . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. RS-NAT Box . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4. Load Balancing Mechanisms . . . . . . . . . . . . . . . . . . 6 67 4.1. IPv6-IPv4 scenario . . . . . . . . . . . . . . . . . . . . 6 68 4.2. IPv4-IPv6 scenario . . . . . . . . . . . . . . . . . . . . 7 69 5. Redundancy Mechanisms . . . . . . . . . . . . . . . . . . . . 9 70 5.1. Address mapping Attribute . . . . . . . . . . . . . . . . 9 71 5.2. Performance consideration . . . . . . . . . . . . . . . . 10 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 76 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 79 1. Introduction 81 For the rapid exhaustion of IPv4 address pool against the slow 82 development of IPv6, IPv4/IPv6 co-existence/transition would be a 83 long period. In order to facilitate the connectivity between IPv4 84 and IPv6 network, a NAT functionality should be deployed on the edge 85 of different IP family network. 87 However most of the NAT-like functions are stateful, which maintain 88 the state of address mapping for network translation or ALG function. 89 The stateful boxes in the network will bring high risks on 90 reliability and scalability when the network becomes huge. For 91 example the box will be a single point of failure in a large-scale 92 network. Although some advices are proposed such as NAT64 using 93 multi-box, the static configuration and localized mapping information 94 in each box are not able to accommodate the dynamic internet 95 environment. 97 In this document, we proposed a Reliable and Scalable NAT (RS-NAT) 98 mechanism to overcome the stateful NAT problem mentioned above, which 99 include IPv4 NAT and IPv4/IPv6 NAT. 101 2. RS-NAT Overview 103 In the topology shown in Figure 1, the network can be divided into 104 two parts: the User Network and Service Network. User Network is the 105 realm where the users initiate a communication with servers. The 106 Service Network is the realm where the remote destination (e.g., 107 server) is attached. In addition there are some RS-NAT boxes which 108 act as bridges between these networks. 110 ____________ _______________ 111 /. .. .. .. .\ +--------+ /. .. .. .. .. .\ 112 | |--|RS-NAT A|--| | 113 | | +--------+ | | 114 |User Network| | |Service Network| 115 | | +--------+ | | 116 |. .. .. .. .|--|RS-NAT B|--|. .. .. .. .. .| 117 \____________/ +--------+ \_______________/ 119 Figure 1: General Topology of RS-NAT framework 121 The User Network and Service Network could be IPv4,IPv6 or Dual- 122 stack. As a result, there are several communication scenarios could 123 be deduced from the general topology using the form of IPvx-IPvy, 124 which means users with IPvx protocol initiate connections to servers 125 reachable with IPvy protocol. These communication scenarios are 126 (private)IPv4-IPv4, IPv4-IPv6, IPv6-IPv4, and IPv6-IPv6. 127 VRRP[RFC3768] is suitable for IPv4-IPv4 scenarios and there is no 128 need to use NAT for IPv6-IPv6. So in this document we mainly focus 129 on IPv4-IPv6/IPv6-IPv4 interconnection scenarios. 131 The User Network and Service Network are logical concepts, which may 132 be composed of several ASes. For example, the User Network shown in 133 Figure 1 may consist of several IPv4 networks belong to diffrent 134 network providers. The User Network may connect to Service Network 135 separately through RS-NAT boxes on which BGP [RFC4271] is performed . 137 Note that the User Network and Service Network are exchangable 138 because an end user can be regarded as both initiator and server from 139 different views. 141 3. RS-NAT Box 143 The following Sections will discuss the requirements of RS-NAT Box 144 and its basic embedded functions. 146 In order to achieve the role of bridge between the two networks in 147 the studied scenarios, which are depicted in Sections 3, the RS-NAT 148 box is capable of dual-stack and forwording traffic based on IPv4/ 149 IPv6 protocol translator. 151 In the IPv6-IPv4 scenario RS-NAT router advertises different 152 Prefix64s [I-D.miyata-behave-prefix64] routing information to User 153 Network, and advertise the prefix info of static IPv4 address pool to 154 Service Network. In this scenario, DNS64[I-D.bagnulo-behave-dns64] 155 is employed to assign different Prefix64 for each DNS request 156 randomly, which will be discussed in Section 5. In the IPv4-IPv6 157 scenario RS-NAT router advertises its own IPv6 prefix routing 158 information to Service Network, and sends the prefix info of static 159 IPv4 address pool to User Network. In this scenario, DNS ALG 160 mentioned in NAT-PT[RFC2766] will be modified to support the 161 separation of the data plane and control plane, which will be 162 discussed in Section 5. 164 The address mapping modules in RS-NAT is useful not only for the IP 165 head translation, but essential for some application that embed 166 network-layer addresses as well, such as FTP, SIP etc. 168 4. Load Balancing Mechanisms 170 This Section will show how the RS-NAT run and balance the traffic 171 among these RS-NAT boxes. 173 4.1. IPv6-IPv4 scenario 175 Figure 2 illustrates the connection setup in the IPv6-IPv4 scenario. 176 The connection set-up follows two steps: 178 1) User sends DNS query to DNS64 and gets the DNS reply with an IPv4- 179 embedded IPv6 addresses in the form of Prefix64::IPv4 address; 181 2) User sends the packet to the IPv4-embeded IPv6 addresses. The 182 different IPv6 prefix will lead the packet to different RS-NAT 183 routers, which is achieved by the RS-NAT routing function. 185 The Control Plane 186 .................... 187 +-----+ 188 .........|DNS64| 189 . +-----+ 190 +----+. +------+ +------+ 191 |User| --------- |RS-NAT|---------|server| 192 +----+\ +------+ /+------+ 193 \ +------+ / 194 ---------|RS-NAT|------- 195 +------+ 196 -------------------- 197 The Data Plane 199 Figure 2: IPv6-IPv4 Connection Setup 201 As mentioned previously RS-NAT routers run BGP and keep BGP neighbor 202 information with each other. Each RS-NAT router will maintain the 203 IPv6 prefix which is identical with the prefix DNS64 stores. RS-NAT 204 will performe a Prefix-Assignment Algorithm to decide individually 205 which part of Prefix64 they are in charge of. The Prefix-Assignment 206 Algorism follows the new idea that the IPv6 prefix is equally divided 207 into several portions. And, each of them is assigned to RS-NAT 208 routers. 210 For example, there is 2^8 2001::/24 in Prefix64 pool of 2001::/16 and 211 2 RS-NAT routers. The Assignment plan is that prefixes from 2001: 212 0000::/24 to 2001:7f00::/24 will be assigned to the router with 213 larger IPv4 address, and the prefixes from 2001:8000::/24 to 2001: 214 ff00::/24 is in the charge of the other router. If there are more 215 RS-NAT routers, these prefixes can also easy assigned to them 216 according to the IP address sorting. 218 In order to balance the traffic among these RS-NAT routers, each 219 router should advertise the route of its aggregated Prefix64 to User 220 Network. Note that for the redundancy consideration each router 221 could advertise overlapped Prefix64 with low priority in case other 222 RS-NAT routers are failed. 224 Note that once RS-NAT routers are failed or new RS-NAT routers are 225 configured to join in, the routing for load balance can be 226 automatically configured by RS-NAT routers by themselves. Prefix- 227 Assignment Algorithm will be triggered in each RS-NAT router to re- 228 compute the router prefix. BGP KEEPALVE and OPEN messages are used 229 to achieve that trigger. 231 4.2. IPv4-IPv6 scenario 233 The load balancing mechanism in IPv4-IPv6 interconnection scenario is 234 similar to the one in IPv6-IPv4 in that the IPv4 address pool should 235 shared by RS-NAT routers and each RS-NAT router is responsible to 236 advertise the route of their IPv4 address pool, which is similar to 237 the routing procedure of RS-NAT routers in IPv6-IPv4. The IPv4-IPv6 238 connection set-up is shown in Figure 3. 240 The Control Plane 241 ..................... 242 +----+ +-------+ +----+ 243 |DNS4|....|DNS ALG|......|DNS6| 244 +----+ +---|---+ +----+ 245 +----+. +--|---+ +------+ 246 |User| ---------- |RS-NAT| --------|server| 247 +----+\ +--|---+ /+------+ 248 \ +--|---+ / 249 --------- |RS-NAT| ------ 250 +------+ 251 --------------------- 252 The Date plane 254 Figure 3: IPv4-IPv6 connection Set-up 256 Figure 3 illustrates the connection setup in IPv4-IPv6 scenario. The 257 connection setup follows three steps: 259 1) User sends DNS query to DNS4 and the query will be redirected to 260 DNS6 through a DNS-ALG box. Once the DNS reply reachs the DNS-ALG 261 box, the box will pick a IPv4 address from the IPv4 address pool and 262 form a mapping with the IPv6 address form the answer of the DNS 263 reply. A new DNS relpy will be generated and sent to DNS4 and User. 265 2) Because the packet translation will be done in the RS-NAT router, 266 the DNS ALG box should send the mapping info to RS-NAT routers using 267 new BGP attribute which will be defined in Section 5 269 3) User sends the packet to the IPv4 address got from the answer of 270 DNS reply. The different IPv4 addresses will lead the packet to 271 different RS-NAT routers, which is achieved by the RS-NAT routing 272 function. 274 Note that in step 1 the DNS-ALG box acts just as DNS-ALG functions 275 module in NAT-PT box. The difference between the two box is that 276 DNS-ALG box in our plan is only responsible for the control plan 277 without packet translation. In addition DNS-ALG box should in charge 278 of the mapping distribution among those RS-NAT routers 280 The differences between the two scenarios include two parts: 282 o The control plane: In IPv6-IPv4 scenario, it is the DNS64 that 283 synchronizes the IPv6 and IPv4 address for IPv4 hosts, while in 284 IPv4-IPv6 scenario, a DNS ALG server monitors the DNS requests and 285 replies and forms the mapping of IPv4/IPv6 address. 287 o Address mapping advertisement: For the load balancing reason,DNS 288 ALG server is not designed for traffic translation and forwarding, 289 which are in the charge of RS-NAT routers. As a result the DNS 290 ALG server should send the mapping info to RS-NAT routers using 291 new BGP attribute which is defined in Section 5. 293 5. Redundancy Mechanisms 295 If there exits multi-boxes between the two edge of network, problems 296 will arise when some boxes are not stable or failed. The problems 297 are mainly in two aspects. The first problem is in routing aspect: 298 when one box fails, there is no other valid routes to the 299 destination. The second is in address mapping aspect: when one box 300 is failed, the address mapping information in the box is lost. 301 Furthermore, it will cause the flows broke up and reconnection. 303 The first problem is solved in Section 4 in which the routing 304 mechanism makes sure that the taffic will find a way out through 305 another RS-NAT router by setting the different route cost or 306 preference. In this Section we will define a BGP attribute that one 307 RS-NAT can advertise the local address mapping to other neighbors 308 which guarantees the redundancy of mapping info. With that 309 redundancy address mapping information RS-NAT routers are able to 310 translate the new traffic 312 5.1. Address mapping Attribute 314 Address mapping attribute is an optional transitive attribute that is 315 composed of a set of TLVs. The type code of the attribute is to be 316 assigned by IANA. Each TLV contains information corresponding to a 317 particular mapping information. The TLV is structured as follows: 319 0 1 2 3 321 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | mapping Type (2 Octets) | Length (2 Octets) | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | | 326 | Value | 327 | | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 apping Type (2 octets): It identifies the type of the mapping 331 information being transmitted. This document defines the following 332 types: 334 - IPv4-IPv4: mapping Type = 1 336 - IPv4-IPv6/IPv6-IPv4: mapping Type = 2 338 - IPv6-IPv6: mapping Type=3 340 Unknown types are to be ignored and skipped upon receipt. 342 Length (2 octets): the total number of octets of the Value field. 344 Value (variable): The value is composed of the address mapping 345 information. If mapping type is 2, the value contains an IPv4/IPv6 346 address mapping just simply structured as follows: 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | IPv4 address (4 Octets) | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | IPv4 prot nubmer (2 Octets) | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | | 354 | IPv6 address (16 Octets) | 355 | | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | IPv6 prot nubmer (2 Octets) | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 5.2. Performance consideration 362 As the mapping information is tremendous and dynamic. The 363 performance of RS-NAT is an important issue. BGP reflector can be 364 utilized to reduce the BGP update massage. If reflector is deployed, 365 new mechanism should guarantee each RS-NAT routers knowing the number 366 of routers. In addition some optimization of RS-NAT and possible 367 modifications of BGP will be explored in the next version of this 368 document. For example the mapping information should be advertised 369 in a certain refresh-time interval 371 Note that RS-NAT routers are located on the edge of network and they 372 may not connect directly. BGP has its nature advantage to do 373 signaling among edge routers over some intra-domain protocol. 375 6. Security Considerations 377 It needs to be further identified. 379 7. IANA Considerations 381 This memo includes no request to IANA. 383 8. References 385 8.1. Normative References 387 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 388 Protocol 4 (BGP-4)", RFC 4271, January 2006. 390 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 391 Translation - Protocol Translation (NAT-PT)", RFC 2766, 392 February 2000. 394 [RFC3768] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)", 395 RFC 3768, April 2004. 397 [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network 398 Address Translator - Protocol Translator (NAT-PT) to 399 Historic Status", RFC 4966, July 2007. 401 8.2. Informative References 403 [I-D.bagnulo-behave-nat64] 404 Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network 405 Address and Protocol Translation from IPv6 Clients to IPv4 406 Servers", draft-bagnulo-behave-nat64-03 (work in 407 progress), March 2009. 409 [I-D.miyata-behave-prefix64] 410 Miyata, H. and M. Bagnulo, "PREFIX64 Comparison", 411 draft-miyata-behave-prefix64-02 (work in progress), 412 March 2009. 414 [I-D.bagnulo-behave-dns64] 415 Bagnulo, M., Sullivan, A., Matthews, P., Beijnum, I., and 416 M. Endo, "DNS64: DNS extensions for Network Address 417 Translation from IPv6 Clients to IPv4 Servers", 418 draft-bagnulo-behave-dns64-02 (work in progress), 419 March 2009. 421 Authors' Addresses 423 Gang Chen 424 China Mobile 425 53A,Xibianmennei Ave. 426 Beijing 100053 427 P.R.China 429 Phone: +86-13910710674 430 Email: phdgang@gmail.com 432 Hui Deng 433 China Mobile 434 53A,Xibianmennei Ave. 435 Beijing 100053 436 P.R.China 438 Phone: +86-13910750201 439 Email: denghui02@gmail.com 441 Bo Zhou 442 China Mobile 443 53A,Xibianmennei Ave. 444 Beijing 100053 445 P.R.China 447 Phone: +86-13811948723 448 Email: zhouboyj@chinamobile.com 450 Mingwei Xu 451 Tsinghua University 452 Department of Computer Science, Tsinghua University 453 Beijing 100084 454 P.R.China 456 Phone: +86-10-6278-5822 457 Email: xmw@csnet1.cs.tsinghua.edu.cn 458 Linjian Song 459 Tsinghua University 460 Department of Computer Science, Tsinghua University 461 Beijing 100084 462 P.R.China 464 Phone: +86-10-6278-5822 465 Email: songlinjian@csnet1.cs.tsinghua.edu.cn 467 Yong Cui 468 Tsinghua University 469 Department of Computer Science, Tsinghua University 470 Beijing 100084 471 P.R.China 473 Phone: +86-10-6278-5822 474 Email: cuiyong@tsinghua.edu.cn