idnits 2.17.1 draft-daniel-scalable-natpt-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 384. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 361. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 368. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 374. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 390), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 424 lines 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 45 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (March 13, 2005) is 6978 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: 'Trans' is defined on line 320, but no explicit reference was found in the text == Unused Reference: 'DSTM' is defined on line 327, but no explicit reference was found in the text == Unused Reference: 'DNSALG' is defined on line 333, but no explicit reference was found in the text == Unused Reference: 'NDP' is defined on line 337, but no explicit reference was found in the text == Unused Reference: 'ISSUE' is defined on line 340, but no explicit reference was found in the text == Unused Reference: 'IPV6' is defined on line 346, but no explicit reference was found in the text == Unused Reference: 'LINK' is defined on line 349, 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: 17 errors (**), 0 flaws (~~), 10 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Daniel Park 2 Internet-Draft SAMSUNG Electronics 3 Expires: September 12, 2005 S. Sivakumar 4 Cisco 5 P. Srisuresh 6 Caymas Systems 7 March 13, 2005 9 Scalable NAT-PT Solution 10 draft-daniel-scalable-natpt-00.txt 12 Status of this Memo 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 and any of which I become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on July 19, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). All Rights Reserved. 41 Abstract 43 This document provides scalability extension to NAT-PT. The extension 44 is based on the use of DNS-ALG and exchange of load metrics amongst a 45 cluster of NAT-PT devices. We refer such a NAT-PT device as mNAT-PT. 46 mNAT-PT is valuable in connecting large V6 domains to legacy V4 47 domain. 49 1. Introduction 51 In order to widely deploy IPv6 network, V4/V6 transition mechanisms 52 are essential. NAT-PT and TRT transition solutions are proposed for 53 enable connectivity between IPv6-only and IPv4 networks. However, 54 both these solutions have limitations for large size V6 networks. 55 This draft focuses on scaling extensions for traditional NAT-PT. 56 Specifically, a method to permit outbound sessions for IPv6 57 hosts in a large IPv6-only domain to the legacy IPv4 domain using 58 multiple mNAT-PT translators. 60 2. Scaling Considerations 62 The NAT-PT solution defined in [NATPT] does not address scalability 63 issue. Although TRT [TRT] considered scaling, it mandates 64 reconfiguration of existing systems such as host and DNS-server by 65 the network administrator. This may not be feasible or desirable in 66 many circumstances, especially when the V6 domain is constituted 67 of mobile nodes. In this document, we propose mNAT-PT as an 68 efficient scalable solution to address such environments. Unlike 69 TRT, mNAT-PT will not mandate changes to existing end-nodes. 71 3. Terminology 73 The following terminology is used throughout the document. 75 o NAT-PT device A device that implements traditional 76 NAT-PT function as described in [NATPT]. 78 o mNAT-PT function Stands for "Multiple NAT-PT". mNAT-PT 79 function makes use of NAT-PT, DNS-ALG 80 and real-time load monitoring functions 81 to scale NAT-PT function to multiple 82 NAT-PT devices. 84 o mNAT-PT device A device that implements mNAT-PT function. 86 o Address Pool IPv4 addresses to translate between IPv6 87 and IPv4 realms. 89 o Mapping Table Mapping between IPv4 and IPv6 addresses 90 in the NAT-PT (or) mNAT-PT device. 92 o Load threshold This is an upper ceiling of NAT BINDings 93 configured for a given mNAT-PT device. 94 When a mNAT-PT device reaches the 95 threshold, the mNAT-PT device attempts to 96 assign a different mNAT-PT device for new 97 sessions crossing the realms. 99 o ALG Application layer gateway. 101 o DNS-ALG DNS Application layer gateway, as 102 described in [NATPT]. 104 4. V4/V6 topology with a single NAT-PT device 106 +--------------------------------+ +-----------------+ 107 | | | | 108 | IPv6 domain | | | 109 | | | | 110 | [IPv6-only host]----------[NAT-PT]--------| IPv4 domain | 111 | . | | | | 112 | . | | | | 113 | | | | | 114 | [DNSv6 Server] | | | 115 | | | | 116 +--------------------------------+ +-----------------+ 118 Figure 1 : single NAT-PT topology 120 As described in figure 1 above, IPv6-only hosts in the IPv6 domain 121 are translated into IPv4 address by the NAT-PT device. NAT-PT is 122 listed as the default router in IPv6 network. Also, there may be a 123 DNSv6 Server within the IPv6 domain. The above solution cannot 124 scale to support large no. of V6 hosts. 126 5. V4/v6 topology with multiple mNAT-PT devices 128 With growing deployment of IPv6-only networks, a single NAT-PT 129 will not be able to scale. Support for large number of mobile 130 users is a requirement in a 3GPP mobile network. We propose 131 deploying multiple mNAT-PT devices on the border of the IPv6 132 domain as described below in figure 2. Each mNAT-PT device 133 will perform NAT-PT function, host one or more unique IPv6 134 prefixes and advertise the prefixes within the IPv6 domain. 136 +------------------------------+ +----------------+ 137 | | | | 138 | IPv6 domain | | | 139 | | | | 140 | [IPv6-only host]--------[mNAT-PT]--------| | 141 | . | | | | 142 | . | | | | 143 | | | | | 144 | [DNSv6 Server] | | | 145 | | | | IPv4 domain | 146 | [IPv6-only host]--------[mNAT-PT]--------| | 147 | . | | | | 148 | . | | | | 149 | [IPv6-only host]--------[mNAT-PT]--------| | 150 | . . | | 151 | . . | | 152 | . | | | 153 +------------------------------+ +----------------+ 155 Figure 2 : mNAT-PT topology 157 6. Method of operation for mNAT-PT devices 159 The following layout describes how mNAT-PT function may be 160 accomplished with the aid of DNS-ALG and Cluster Load-Monitor 161 as an extension to NAT-PT function. 163 +----------------+ 164 | DNS-ALG | 165 | | 166 +-----+--------+-------+-----+---------+ 167 | | Traditional |Interface| 168 | Cluster-wide | NAT-PT | to | ______[IPv4 Domain] 169 | Load Monitor | function | IPv4 |___\ 170 | | |network | 171 +----------------------------+--------+ 172 | Interface to IPv6-network | 173 +----------------------------+ 174 | 175 |/| 176 | 177 | 178 [IPv6 domain] 180 Figure 3 : mNAT-PT functional framework 182 A cluster of mNAT-PT devices may be configured to provide a scalable 183 mNAT-PT solution to large V6 networks. All member nodes within a 184 mNAT-PT cluster carry the same Cluster Identifier (ClusterId). The 185 Load-Monitor entity within each mNAT-PT is responsible for relaying 186 the real-time load on the hosting mNAT-PT periodically and in turn, 187 collecting the load from member nodes within the cluster. The 188 Load-monitor supplies real-time up-uo-date load data of member 189 nodes to the DNS-ALG. 191 The NAT-PT entity is required to invoke DNS-ALG for all DNS queries 192 and responses traversing the domains. While processing the DNS 193 response, the DNS-ALG will use load on member nodes as the basis to 194 assign a IPv6 prefix in the AAAA response to the V6-node that 195 originated the DNS query. The IPv6 prefix assignment will be based 196 on the load on the mNAT-PT node associated with the prefix. 198 6.1. Load-monitor and Communication amongst mNAT-PT cluster members 200 The following assumptions are made throughout the document. A few 201 of these assumptions may be changed to suit specific deployment 202 scenarios. 204 * Communication amongst the cluster members may take place 205 within the IPv6 domain. 207 * It is assumed that each of the mNAT-PT member nodes have 208 non-conflicting address maps and host a IP-v6 prefix that 209 is also non-conflicting. 211 * This document uses NAT-BINDing load on member nodes as the 212 criteria for determining which of the mNAT-PT devices is 213 assigned to carry out a NAT-PT translation. However, load 214 need not be the criteria or the only criteria to make the 215 device selection. There may be other criteria or policies 216 that decide the right mNAT-PT device. 218 * The document assumes that all mNAT-PT devices equal access 219 to all V4 routes in the V4 domain. This need not be the 220 case. In such a case, the mNAT-PT devices must either 221 setup V4-over-V6 VPNs between themselves so this is 222 ensured (or) exchange the V4 route reachability between 223 themselves so the right prefix is assigned based on route 224 reachability. The former is the preffered and recommended 225 choice. 227 * The document assumes that the Cluster-ID, 228 Cluster-controller and member nodes within a cluster are 229 preconfigured on the mNAT-PT device. Dynamic discovery of 230 Cluster members is out of the scope of this document. 231 Election of initial or subsequent cluster controller is 232 also outside the scope of this document. Cluster 233 controller is assumed to be the first node of the cluster 234 to come up. A cluster controller is required to be alive 235 throughout the duration of the cluster. 237 * The document assumes there exists a V6 path for any of 238 the V6-only hosts to reach any of the mNAT-PT devices. 240 * Lastly, [NIQ] does not seem like the right choice for 241 cluster communication. Cluster communication requires 242 reliable point-to-point data communication (say, TCP 243 based sessions to a well-knwon port) and reliable 244 point-to-multipoint communication. The document does 245 not address the transport or message formats used for 246 cluster communication at this time. 248 * The communication amongst mNAT-PT cluster memebers 249 devices should be properly authenticated to avoid any 250 malicious devices trying to add a IPv6 prefix in the 251 active list and thereby causing the traffic to be 252 directed to the malicious device. 254 An mNAT-PT node joins the cluster by sending a message with 255 the following mNAT-PT configuration data to Cluster controller. 256 The cluster controller, in turn, accepts the node into cluster 257 by sending the existing cluster membership info, Load-data 258 polling duration and mNAT-PT configuration for each of the 259 member nodes. The periodic load-data update will also be used 260 to validate the liveness of a memeber node. Alternately, 261 member nodes may terminate their memebership by explicitly 262 sendign a termination message to the cluster controller. 264 - The Cluster ID 265 - Hosted IP-V6 Prefix 266 - NAT-PT address map configuration 267 - BINDings threshold limit 269 Further to joining the cluster, the mNAT-PT nodes report their 270 load-data to the cluster controller periodically. The load-data is 271 essentially the count of active NAT-PT BINDings at the time of 272 reporting. 274 6.2. Redirection using DNS-ALG 276 Each mNAT-PT must be configured with a threshold of NAT BINDings 277 and one or more IP-v6 prefixes (as desccribed in the previous 278 section) in advance. The DNS-ALG is supplied with this information 279 from the Load-Monitor. 281 Typically, all the communications between a IPv4 device and IPv6 282 device starts with a DNS request. DNS-ALG receives the DNS request and 283 converts the A query to a AAAA query and vice versa. When the DNS-ALG 284 receives the reply then it will decide which IPv6 prefix to use to 285 translate the IPv4 address. If the load on the hosting mNAT-PT is 286 within threshold configured for the node, then the prefix assigned 287 to the host mNAT-PT is included in the DNS response. Otherwise, 288 DNS-ALG will select a member node with the least percentage of load 289 utilization vis-a-vis the threshold setting. 291 7. Security Considerations 293 Cluster communication between cooperatign mNAT-PT devices must be 294 authenticated so that sessions are not hijacked by a rogue node 295 that pretends to be a member mNAT-PT device. 297 Authors' Addresses 299 Soohong Daniel Park 300 Mobile Platform Laboratory, SAMSUNG Electronics 301 416, Maetan-3dong, Yeongtong-gu 302 Suwon, KOREA 303 Email:soohong.park@samsung.com 305 Senthil Sivakumar 306 Cisco Systems, Inc. 307 170 West Tasman Dr. 308 San Jose CA 95134, US 309 Email: ssenthil@cisco.com 311 Pyda Srisuresh 312 Caymas Systems, Inc 313 1179-A North McDowell Blvd. 314 petaluma, CA 94954 315 USA 316 Email: srisuresh@yahoo.com 318 References 320 [Trans] Gilligan, R. and E. Nordmark, "Transition Mechanisms 321 for IPv6 Hosts and Routers", RFC 1933, April 1996. 323 [NATPT] Tsirtsis G. and P. Srisuresh "Network Address 324 Translation-Protocol Translation(NAT-PT)", RFC 2766, 325 February 2000. 327 [DSTM] Bound, J, et al. "Dual Stack Transition Mechanism 328 (DSTM)" draft-ietf-ngtrans-dstm-08.txt. 330 [TRT] J.Hagino, K.Yamamoto, "An IPv6-to-IPv4 Transport Relay 331 Translator", RFC 3142, June 2001. 333 [DNSALG] Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A. 334 Heffernan, "DNS extensions to Network Address 335 Translators(DNS_ALG)", RFC 2694, September 1999. 337 [NDP] Narten, T, Nordmark, E, Simpson, W "Neighbor Discovery 338 for IP Version 6 (IPv6)", RFC 2461, December 1998. 340 [ISSUE] Durand, A., "Issues with NAT-PT DNS ALG in RFC2766" 341 Internet-Draft, January 2003, work in progress. 343 [NIQ] Crawford, M, "IPv6 Node Information Queries", Internet- 344 Draft, May 2002, work in progress. 346 [IPV6] Deering, S, Hinden, R, "Internet Protocol, Version 6 347 (IPv6) Specification", RFC 2460, December, 1998. 349 [LINK] Hinden, R, et. al. "An IPv6 Aggregatable Global Unicast 350 Address Format", RFC 2374, July 1998. 352 Intellectual Property Statement 354 The IETF takes no position regarding the validity or scope of any 355 Intellectual Property Rights or other rights that might be claimed to 356 pertain to the implementation or use of the technology described in 357 this document or the extent to which any license under such rights 358 might or might not be available; nor does it represent that it has 359 made any independent effort to identify any such rights. Information 360 on the procedures with respect to rights in RFC documents can be 361 found in BCP 78 and BCP 79. 363 Copies of IPR disclosures made to the IETF Secretariat and any 364 assurances of licenses to be made available, or the result of an 365 attempt made to obtain a general license or permission for the use of 366 such proprietary rights by implementers or users of this 367 specification can be obtained from the IETF on-line IPR repository at 368 http://www.ietf.org/ipr. 370 The IETF invites any interested party to bring to its attention any 371 copyrights, patents or patent applications, or other proprietary 372 rights that may cover technology that may be required to implement 373 this standard. Please address the information to the IETF at 374 ietf-ipr@ietf.org. 376 Disclaimer of Validity 378 This document and the information contained herein are provided on an 379 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 380 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 381 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 382 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 383 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 384 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 386 Copyright Statement 388 Copyright (C) The Internet Society (2005). This document is subject 389 to the rights, licenses and restrictions contained in BCP 78, and 390 except as set forth therein, the authors retain all their rights. 392 Acknowledgment 394 Funding for the RFC Editor function is currently provided by the 395 Internet Society.