idnits 2.17.1 draft-park-scalable-multi-natpt-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 87 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2003) is 7652 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) == Missing Reference: 'Bradner' is mentioned on line 308, but not defined -- Looks like a reference, but probably isn't: '1996' on line 308 == Unused Reference: 'Trans' is defined on line 387, but no explicit reference was found in the text == Unused Reference: 'DSTM' is defined on line 394, but no explicit reference was found in the text == Unused Reference: 'DNSALG' is defined on line 400, but no explicit reference was found in the text == Unused Reference: 'NDP' is defined on line 404, but no explicit reference was found in the text == Unused Reference: 'ISSUE' is defined on line 407, but no explicit reference was found in the text == Unused Reference: 'IPV6' is defined on line 413, but no explicit reference was found in the text == Unused Reference: 'LINK' is defined on line 416, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1933 (ref. 'Trans') (Obsoleted by RFC 2893) ** Obsolete normative reference: RFC 2766 (ref. 'NATPT') (Obsoleted by RFC 4966) -- Possible downref: Non-RFC (?) normative reference: ref. 'DSTM' ** Downref: Normative reference to an Informational RFC: RFC 3142 (ref. 'TRT') ** Downref: Normative reference to an Informational RFC: RFC 2694 (ref. 'DNSALG') ** Obsolete normative reference: RFC 2461 (ref. 'NDP') (Obsoleted by RFC 4861) -- Duplicate reference: RFC2766, mentioned in 'ISSUE', was also mentioned in 'NATPT'. ** Obsolete normative reference: RFC 2766 (ref. 'ISSUE') (Obsoleted by RFC 4966) -- Possible downref: Non-RFC (?) normative reference: ref. 'NIQ' ** Obsolete normative reference: RFC 2460 (ref. 'IPV6') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2374 (ref. 'LINK') (Obsoleted by RFC 3587) Summary: 12 errors (**), 0 flaws (~~), 9 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission S. Daniel Park 3 INTERNET-DRAFT SAMSUNG Electronics 4 Expired: November 2003 Senthil Sivakumar 5 Filename: Cisco Systems, Inc 6 draft-park-scalable-multi-natpt-00.txt Pyda Srisuresh 7 Caymas Systems, Inc 8 May 2003 10 Scalable mNAT-PT Solution 12 Status of This Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet-Drafts 25 as reference material or to cite them other than as "work in 26 progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This document provides scalability extension to NAT-PT. The extension 37 is based on the use of DNS-ALG and exchange of load metrics amongst a 38 cluster of NAT-PT devices. We refer such a NAT-PT device as mNAT-PT. 39 mNAT-PT is valuable in connecting large V6 domains to legacy V4 40 domain. 42 Table of Contents 44 1. Introduction .................................................. 2 45 2. Scaling Considerations ........................................ 2 46 3. Terminology ................................................... 3 47 4. V4/v6 topology with a single NAT-PT device .................... 3 48 5. V4/v6 topology with multiple mNAT-PT devices .................. 4 49 6. Method of operation for mNAT-PT devices ...................... 5 50 6.1 Load monitor & Communication amongst mNAT-PT cluster members... 5 51 6.2 Redirection using DNS-ALG ..................................... 7 52 7. Security Considerations ....................................... 7 53 8. Intellectual Property ......................................... 8 54 9. Copyright ..................................................... 8 55 10. Authors' Addresses ............................................ 9 56 11. References .................................................... 10 58 1. Introduction 60 In order to widely deploy IPv6 network, V4/V6 transition mechanisms 61 are essential. NAT-PT and TRT transition solutions are proposed for 62 enable connectivity between IPv6-only and IPv4 networks. However, 63 both these solutions have limitations for large size V6 networks. 64 This draft focuses on scaling extensions for traditional NAT-PT. 65 Specifically, a method to permit outbound sessions for IPv6 66 hosts in a large IPv6-only domain to the legacy IPv4 domain using 67 multiple mNAT-PT translators. 69 2. Scaling Considerations 71 The NAT-PT solution defined in [NATPT] does not address scalability 72 issue. Although TRT [TRT] considered scaling, it mandates 73 reconfiguration of existing systems such as host and DNS-server by 74 the network administrator. This may not be feasible or desirable in 75 many circumstances, especially when the V6 domain is constituted 76 of mobile nodes. In this document, we propose mNAT-PT as an 77 efficient scalable solution to address such environments. Unlike 78 TRT, mNAT-PT will not mandate changes to existing end-nodes. 80 3. Terminology 82 The following terminology is used throughout the document. 84 o NAT-PT device A device that implements traditional 85 NAT-PT function as described in [NATPT]. 87 o mNAT-PT function Stands for "Multiple NAT-PT". mNAT-PT 88 function makes use of NAT-PT, DNS-ALG 89 and real-time load monitoring functions 90 to scale NAT-PT function to multiple 91 NAT-PT devices. 93 o mNAT-PT device A device that implements mNAT-PT function. 95 o Address Pool IPv4 addresses to translate between IPv6 96 and IPv4 realms. 98 o Mapping Table Mapping between IPv4 and IPv6 addresses 99 in the NAT-PT (or) mNAT-PT device. 101 o Load threshold This is an upper ceiling of NAT BINDings 102 configured for a given mNAT-PT device. 103 When a mNAT-PT device reaches the 104 threshold, the mNAT-PT device attempts to 105 assign a different mNAT-PT device for new 106 sessions crossing the realms. 108 o ALG Application layer gateway. 110 o DNS-ALG DNS Application layer gateway, as 111 described in [NATPT]. 113 4. V4/V6 topology with a single NAT-PT device 115 +--------------------------------+ +-----------------+ 116 | | | | 117 | IPv6 domain | | | 118 | | | | 119 | [IPv6-only host]----------[NAT-PT]--------| IPv4 domain | 120 | . | | | | 121 | . | | | | 122 | | | | | 123 | [DNSv6 Server] | | | 124 | | | | 125 +--------------------------------+ +-----------------+ 127 Figure 1 : single NAT-PT topology 129 As described in figure 1 above, IPv6-only hosts in the IPv6 domain 130 are translated into IPv4 address by the NAT-PT device. NAT-PT is 131 listed as the default router in IPv6 network. Also, there may be a 132 DNSv6 Server within the IPv6 domain. The above solution cannot 133 scale to support large no. of V6 hosts. 135 5. V4/v6 topology with multiple mNAT-PT devices 137 With growing deployment of IPv6-only networks, a single NAT-PT 138 will not be able to scale. Support for large number of mobile 139 users is a requirement in a 3GPP mobile network. We propose 140 deploying multiple mNAT-PT devices on the border of the IPv6 141 domain as described below in figure 2. Each mNAT-PT device 142 will perform NAT-PT function, host one or more unique IPv6 143 prefixes and advertise the prefixes within the IPv6 domain. 145 +------------------------------+ +----------------+ 146 | | | | 147 | IPv6 domain | | | 148 | | | | 149 | [IPv6-only host]--------[mNAT-PT]--------| | 150 | . | | | | 151 | . | | | | 152 | | | | | 153 | [DNSv6 Server] | | | 154 | | | | IPv4 domain | 155 | [IPv6-only host]--------[mNAT-PT]--------| | 156 | . | | | | 157 | . | | | | 158 | [IPv6-only host]--------[mNAT-PT]--------| | 159 | . . | | 160 | . . | | 161 | . | | | 162 +------------------------------+ +----------------+ 164 Figure 2 : mNAT-PT topology 166 6. Method of operation for mNAT-PT devices 168 The following layout describes how mNAT-PT function may be 169 accomplished with the aid of DNS-ALG and Cluster Load-Monitor 170 as an extension to NAT-PT function. 172 +----------------+ 173 | DNS-ALG | 174 | | 175 +-----+--------+-------+-----+---------+ 176 | | Traditional |Interface| 177 | Cluster-wide | NAT-PT | to | ______[IPv4 Domain] 178 | Load Monitor | function | IPv4 |___\ 179 | | |network | 180 +----------------------------+--------+ 181 | Interface to IPv6-network | 182 +----------------------------+ 183 | 184 |/| 185 | 186 | 187 [IPv6 domain] 189 Figure 3 : mNAT-PT functional framework 191 A cluster of mNAT-PT devices may be configured to provide a scalable 192 mNAT-PT solution to large V6 networks. All member nodes within a 193 mNAT-PT cluster carry the same Cluster Identifier (ClusterId). The 194 Load-Monitor entity within each mNAT-PT is responsible for relaying 195 the real-time load on the hosting mNAT-PT periodically and in turn, 196 collecting the load from member nodes within the cluster. The 197 Load-monitor supplies real-time up-uo-date load data of member 198 nodes to the DNS-ALG. 200 The NAT-PT entity is required to invoke DNS-ALG for all DNS queries 201 and responses traversing the domains. While processing the DNS 202 response, the DNS-ALG will use load on member nodes as the basis to 203 assign a IPv6 prefix in the AAAA response to the V6-node that 204 originated the DNS query. The IPv6 prefix assignment will be based 205 on the load on the mNAT-PT node associated with the prefix. 207 6.1. Load-monitor and Communication amongst mNAT-PT cluster members 209 The following assumptions are made throughout the document. A few 210 of these assumptions may be changed to suit specific deployment 211 scenarios. 213 * Communication amongst the cluster members may take place 214 within the IPv6 domain. 216 * It is assumed that each of the mNAT-PT member nodes have 217 non-conflicting address maps and host a IP-v6 prefix that 218 is also non-conflicting. 220 * This document uses NAT-BINDing load on member nodes as the 221 criteria for determining which of the mNAT-PT devices is 222 assigned to carry out a NAT-PT translation. However, load 223 need not be the criteria or the only criteria to make the 224 device selection. There may be other criteria or policies 225 that decide the right mNAT-PT device. 227 * The document assumes that all mNAT-PT devices equal access 228 to all V4 routes in the V4 domain. This need not be the 229 case. In such a case, the mNAT-PT devices must either 230 setup V4-over-V6 VPNs between themselves so this is 231 ensured (or) exchange the V4 route reachability between 232 themselves so the right prefix is assigned based on route 233 reachability. The former is the preffered and recommended 234 choice. 236 * The document assumes that the Cluster-ID, 237 Cluster-controller and member nodes within a cluster are 238 preconfigured on the mNAT-PT device. Dynamic discovery of 239 Cluster members is out of the scope of this document. 240 Election of initial or subsequent cluster controller is 241 also outside the scope of this document. Cluster 242 controller is assumed to be the first node of the cluster 243 to come up. A cluster controller is required to be alive 244 throughout the duration of the cluster. 246 * The document assumes there exists a V6 path for any of 247 the V6-only hosts to reach any of the mNAT-PT devices. 249 * Lastly, [NIQ] does not seem like the right choice for 250 cluster communication. Cluster communication requires 251 reliable point-to-point data communication (say, TCP 252 based sessions to a well-knwon port) and reliable 253 point-to-multipoint communication. The document does 254 not address the transport or message formats used for 255 cluster communication at this time. 257 * The communication amongst mNAT-PT cluster memebers 258 devices should be properly authenticated to avoid any 259 malicious devices trying to add a IPv6 prefix in the 260 active list and thereby causing the traffic to be 261 directed to the malicious device. 263 An mNAT-PT node joins the cluster by sending a message with 264 the following mNAT-PT configuration data to Cluster controller. 265 The cluster controller, in turn, accepts the node into cluster 266 by sending the existing cluster membership info, Load-data 267 polling duration and mNAT-PT configuration for each of the 268 member nodes. The periodic load-data update will also be used 269 to validate the liveness of a memeber node. Alternately, 270 member nodes may terminate their memebership by explicitly 271 sendign a termination message to the cluster controller. 273 - The Cluster ID 274 - Hosted IP-V6 Prefix 275 - NAT-PT address map configuration 276 - BINDings threshold limit 278 Further to joining the cluster, the mNAT-PT nodes report their 279 load-data to the cluster controller periodically. The load-data is 280 essentially the count of active NAT-PT BINDings at the time of 281 reporting. 283 6.2. Redirection using DNS-ALG 285 Each mNAT-PT must be configured with a threshold of NAT BINDings 286 and one or more IP-v6 prefixes (as desccribed in the previous 287 section) in advance. The DNS-ALG is supplied with this information 288 from the Load-Monitor. 290 Typically, all the communications between a IPv4 device and IPv6 291 device starts with a DNS request. DNS-ALG receives the DNS request and 292 converts the A query to a AAAA query and vice versa. When the DNS-ALG 293 receives the reply then it will decide which IPv6 prefix to use to 294 translate the IPv4 address. If the load on the hosting mNAT-PT is 295 within threshold configured for the node, then the prefix assigned 296 to the host mNAT-PT is included in the DNS response. Otherwise, 297 DNS-ALG will select a member node with the least percentage of load 298 utilization vis-a-vis the threshold setting. 300 7. Security Considerations 302 Cluster communication between cooperatign mNAT-PT devices must be 303 authenticated so that sessions are not hijacked by a rogue node 304 that pretends to be a member mNAT-PT device. 306 8. Intellectual Property 308 The following notice is copied from RFC 2026 [Bradner, 1996], 309 Section 10.4, and describes the position of the IETF concerning 310 intellectual property claims made against this document. 312 The IETF takes no position regarding the validity or scope of any 313 intellectual property or other rights that might be claimed to 314 pertain to the implementation or use other technology described in 315 this document or the extent to which any license under such rights 316 might or might not be available; neither does it represent that it 317 has made any effort to identify any such rights. Information on the 318 IETF's procedures with respect to rights in standards-track and 319 standards-related documentation can be found in BCP-11. Copies of 320 claims of rights made available for publication and any assurances 321 of licenses to be made available, or the result of an attempt made 322 to obtain a general license or permission for the use of such 323 proprietary rights by implementers or users of this specification 324 can be obtained from the IETF Secretariat. 326 The IETF invites any interested party to bring to its attention any 327 copyrights, patents or patent applications, or other proprietary 328 rights which may cover technology that may be required to practice 329 this standard. Please address the information to the IETF Executive 330 Director. 332 9. Copyright 334 The following copyright notice is copied from RFC 2026 [Bradner, 335 1996], Section 10.4, and describes the applicable copyright for this 336 document. 338 Copyright (C) The Internet Society July 12, 2001. All Rights 339 Reserved. 341 This document and translations of it may be copied and furnished to 342 others, and derivative works that comment on or otherwise explain it 343 or assist in its implementation may be prepared, copied, published 344 and distributed, in whole or in part, without restriction of any 345 kind, provided that the above copyright notice and this paragraph 346 are included on all such copies and derivative works. However, this 347 document itself may not be modified in any way, such as by removing 348 the copyright notice or references to the Internet Society or other 349 Internet organizations, except as needed for the purpose of 350 developing Internet standards in which case the procedures for 351 copyrights defined in the Internet Standards process must be 352 followed, or as required to translate it into languages other than 353 English. 355 The limited permissions granted above are perpetual and will not be 356 revoked by the Internet Society or its successors or assignees. 358 This document and the information contained herein is provided on an 359 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 360 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 361 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 362 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 363 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 365 10. Authors' Addresses 367 Soohong Daniel Park 368 Mobile Platform Laboratory 369 SAMSUNG Electronics, KOREA 370 Email:soohong.park@samsung.com 372 Senthil Sivakumar 373 Cisco Systems, Inc. 374 170 West Tasman Dr. 375 San Jose CA 95134, US 376 Email: ssenthil@cisco.com 378 Pyda Srisuresh 379 Caymas Systems, Inc 380 1179-A North McDowell Blvd. 381 petaluma, CA 94954 382 USA 383 Email: srisuresh@yahoo.com 385 11. References 387 [Trans] Gilligan, R. and E. Nordmark, "Transition Mechanisms 388 for IPv6 Hosts and Routers", RFC 1933, April 1996. 390 [NATPT] Tsirtsis G. and P. Srisuresh "Network Address 391 Translation-Protocol Translation(NAT-PT)", RFC 2766, 392 February 2000. 394 [DSTM] Bound, J, et al. "Dual Stack Transition Mechanism 395 (DSTM)" draft-ietf-ngtrans-dstm-08.txt. 397 [TRT] J.Hagino, K.Yamamoto, "An IPv6-to-IPv4 Transport Relay 398 Translator", RFC 3142, June 2001. 400 [DNSALG] Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A. 401 Heffernan, "DNS extensions to Network Address 402 Translators(DNS_ALG)", RFC 2694, September 1999. 404 [NDP] Narten, T, Nordmark, E, Simpson, W "Neighbor Discovery 405 for IP Version 6 (IPv6)", RFC 2461, December 1998. 407 [ISSUE] Durand, A., "Issues with NAT-PT DNS ALG in RFC2766" 408 Internet-Draft, January 2003, work in progress. 410 [NIQ] Crawford, M, "IPv6 Node Information Queries", Internet- 411 Draft, May 2002, work in progress. 413 [IPV6] Deering, S, Hinden, R, "Internet Protocol, Version 6 414 (IPv6) Specification", RFC 2460, December, 1998. 416 [LINK] Hinden, R, et. al. "An IPv6 Aggregatable Global Unicast 417 Address Format", RFC 2374, July 1998.