idnits 2.17.1 draft-chen-behave-nat64-radius-extension-00.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 : ---------------------------------------------------------------------------- ** There are 46 instances of too long lines in the document, the longest one being 9 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 08, 2013) is 3944 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-10) exists of draft-ietf-v6ops-nat64-experience-01 Summary: 2 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 G. Chen 3 Internet-Draft China Mobile 4 Intended status: Experimental D. Binet 5 Expires: January 09, 2014 France Telecom-Orange 6 July 08, 2013 8 Radius Attributes for Stateful NAT64 9 draft-chen-behave-nat64-radius-extension-00 11 Abstract 13 This document proposes new radius attributes for stateful NAT64. The 14 extensions are used to provide geo-location services with an exact 15 IPv6 soruce address. The message flow to deliver the NAT64 binding 16 information between radius clients and servers is also described. 17 Therefore, accurate location could be traced out depending on the 18 radius method. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 09, 2014. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 56 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Delivery Methods for NAT64 Binding Information . . . . . . . 3 58 5. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 5.1. NAT64-Binding-Capable . . . . . . . . . . . . . . . . . . 4 60 5.2. Requested-Binding-Info . . . . . . . . . . . . . . . . . 5 61 5.3. NAT64-Binding-Information . . . . . . . . . . . . . . . . 6 62 6. Diameter Considerations . . . . . . . . . . . . . . . . . . . 8 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 64 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 67 9.2. Informative References . . . . . . . . . . . . . . . . . 9 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 70 1. Introduction 72 Stateful NAT64[RFC6146] has been specified to provide IPv4 services 73 access when IPv6-only connectivity is enabled. This NAT64 function 74 could be implemented into routers or firewalls and deployed in 75 broadband access networks or mobile core networks. A public IPv4 76 pool is configured in a NAT64 device to represent IPv6 subscribers in 77 the IPv4 realm. Since the public IPv4 address is shared by several 78 subscribers, it's hardly for a geo-location service to retrieve 79 accurate location information just depending on mapped IPv4 source 80 address. Therefore, it may impact geo-location service provisioning 81 in such case due to unsatisfactory inputs. 83 [RFC6269] mentions that in order to resolve the location of a host 84 based on IP address, "It will be necessary for users of such systems 85 to provide more information (e.g., TCP or UDP port numbers), and for 86 the systems to use this information to query additional network 87 resources (e.g., Network Address Translation - Protocol Translation 88 (NAT-PT) binding tables)." Current geo-location systems may rely on 89 a radius database to inspect location information, for example the 90 information provided in [RFC5580]. A radius based method may be 91 desirable to convey original IPv6 source address in such system 92 because it's rather convenient for a geo-location to get actual IPv6 93 source address through the same message bus. This document proposes 94 to provide those information using radius methods. 96 2. Requirements Language 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in RFC 2119 [RFC2119]. 102 3. Problem Statement 104 IP address sharing solution raises some issues dealing with the 105 capability to reveal the actual source address. A use of stateful 106 NAT64 likely has same issues once geo-location systems seek an 107 accurate input of a source address. Unlike NAT44, it may make more 108 significances to trace the IPv6 source address other than the mapped 109 IPv4 address to locate the 110 subscribers.[I-D.ietf-v6ops-nat64-experience] provided more 111 descriptions on stateful NAT64 uses. Once the stateful NAT64 112 function is built at a load balancer, XFF (X-Forwarded-For) 113 [I-D.ietf-appsawg-http-forwarded] is likely to be adopted to transmit 114 the IPv6 source address in HTTP headers. Those messages would be 115 passed on to web-servers for the geo-location processing. However, 116 XFF only handles HTTP-based traffic and may not be implemented, for 117 example if the NAT64 function is integrated within routers or 118 firewall in an broadband fixed network or a mobile network. 119 Requiring NAT64 devices providing some application aware functions to 120 insert IPv6 source addresses for each data flow would introduce 121 overwhelming complexity and performance degradation. It's also 122 possible to extend Port Control Protocol (PCP) to support those 123 network information queries from external servers. This method can 124 be treated as an "out-band" approach. However, it may require 125 additional correlations between different systems. Therefore, the 126 document proposes a radius-based solution to fit into geo-location 127 systems with following benefits. 129 o It has few impacts to the NAT64 performance since the radius is a 130 independent system which doesn't interact with NAT64 process 132 o Geo-location systems already rely on the radius database. The 133 extended attributes could be transmitted in the same message as 134 already occurs over RADIUS[RFC5580] 136 4. Delivery Methods for NAT64 Binding Information 138 The Figure 1 takes an example to show the message exchanges when the 139 NAT64 function is implemented in a Broadband Network Gateway(BNG). 141 If the RADIUS client provides a NAT64-Binding-Capable Attribute in 142 the Access-Request, then the RADIUS server MAY request NAT64 Binding 143 information from the RADIUS client. The inclusion of the Location- 144 Capable Attribute in an Access-Request message indicates that the BNG 145 with stateful NAT64 functions is capable of providing binding 146 information in response to an Access-Challenge. The subsequent 147 Access-Challenge message sent from the RADIUS server to the BNG 148 provides a hint regarding the desired NAT64 Binding Attributes. BNG 149 would search the corresponding binding information regarding to 150 mapped IPv4 address contained in the Requested-Binding-Info 151 attribute. In the shown message flow, the NAT64-Binding-Information 152 attributes including IPv6 source address and life-time of the binding 153 are then provided in the subsequent Access-Request message. 154 Afterwards, RADIUS server should take a authorization procedure to 155 evaluate this Access-Request message. 157 +---------------+ +---------------+ 158 |BNG with NAT64 | |Geo-Loc Radius | 159 | Function | | Server | 160 +---------------+ +---------------+ 161 | | 162 | Access-Request | 163 | +NAT64-Binding-Capable | 164 |--------------------------------------------->| 165 | Access-Challenge | 166 | +Requested-Binding-Info | 167 |<---------------------------------------------| 168 | Access-Request | 169 | +NAT64-Binding-Information | 170 |--------------------------------------------->| 172 Figure 1: NAT64 Binding Information Delivery 174 5. Attributes 176 5.1. NAT64-Binding-Capable 178 The NAT64-Binding-Capable Attribute allows a network node with 179 stateful NAT64 functions to indicate support for the functionality 180 specified in this document. The NAT64-Binding-Capable Attribute MUST 181 be sent with the Access-Request messages. A RADIUS server MAY 182 challenge for additional network information once the NAT64-Binding- 183 Capable Attribute has been received. 185 0 1 2 3 186 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 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Type | Length | M | Reserved | | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 Type (8 bits) 192 TBD - NAT64-Binding-Capable 194 Length (8 bits) 196 4 198 M flag (2 bits) 200 This flag indicates the type of address mapping. 201 00 -- Endpoint-Independent Mapping 202 01 -- Address-Dependent Mapping 203 10 -- Address and Port-Dependent Mapping 205 Reserved (6 bits) 207 The bits are reserved for the future uses 209 5.2. Requested-Binding-Info 211 The Requested-Binding-Info Attribute MUST be sent with the Access- 212 Challenge depending on the received NAT64-Binding-Capable attributes. 213 A stateful NAT64 function with Radius clients SHOULD reply to the 214 Access-Challenge with Access-Request message. 216 0 1 2 3 217 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 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Type | Length | Protocol | Reserved | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Mapped IPv4 address | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Mapped Port Number | Peer's IPv4 address(Optional) | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Peer's IPv4 address(Optional) | Peer's Port Number(Optional) | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 Type (8 bits) 230 TBD - Requested-Binding-Info 232 Length (8 bits) 234 It indicates the length of attributes 236 Protocol (8 bits) 238 It indicates the Upper-layer protocol associated with the mapping. 240 Values are taken from the IANA protocol registry. For example,17 241 represents UDP mappings while 6 represents TCP mapping 243 Reserved (8 bits) 245 The bits are reserved for the future uses 247 Mapped IPv4 address (32 bits) 249 It contains the IPv4 address which represents the IPv6 host 250 in the IPv4 Internet. 252 Mapped Port Number (16 bits) 254 It indicates the assigned port number correlated with the Mapped 255 IPv4 address. 257 Peer's IPv4 address (32 bits) 259 It indicates the IPv4 address that internal hosts connect with. 260 The IPv4 address MAY be only carried when Address-Dependent Mapping 261 and Address and Port-Dependent Mapping are indicated within the 262 received Access-Request message. 264 Peer's Port Number (16 bits) 266 It indicates the port number correlated with the Peer's IPv4 267 address. The Peer's Port Number MAY be only carried when Port-Dependent 268 Mapping are indicated within the received Access-Request message. 270 5.3. NAT64-Binding-Information 272 The NAT64-Binding-Information Attribute MUST be sent with the Access- 273 Request responding to Access-Challenge from a radius client to a 274 Radius server. 276 0 1 2 3 277 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 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Type | Length | Protocol | Reserved | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | | 282 | IPv6 Source Address | 283 | | 284 | | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Lifetime | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Mapped IPv4 address | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Mapped Port Number | Peer's IPv4 address(Optional) | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Peer's IPv4 address(Optional) | Peer's Port Number(Optional) | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 Type (8 bits) 297 TBD - NAT64-Binding-Information 299 Length (8 bits) 301 It indicates the length of attributes 303 Protocol (8 bits) 305 It indicates the Upper-layer protocol associated with the mapping. 306 Values are taken from the IANA protocol registry.For example,17 307 represents UDP mappings while 6 represents TCP mapping 309 Reserved (8 bits) 311 The bits are reserved for the future uses 313 IPv6 Source Address (128 bits) 315 It indicates the IPv6 source address corresponding to mapped IPv4 316 address and port number 318 Lifetime (32 bits) 320 It indicates how long the geo-location should assume the IPv6 321 address is still correlated with the mapped IPv4 address and port. 323 Mapped IPv4 address (32 bits) 325 It contains the IPv4 address which represents the IPv6 host 326 in the IPv4 Internet. 328 Mapped Port Number (16 bits) 330 It indicates the assigned port number correlated with the Mapped 331 IPv4 address. 333 Peer's IPv4 address (32 bits) 334 It indicates the IPv4 address that internal hosts connect with. 335 The IPv4 address MAY be only carried when Address-Dependent Mapping 336 and Address and Port-Dependent Mapping are indicated within the 337 received Access-Request message. 339 Peer's Port Number (16 bits) 341 It indicates the port number correlated with the Peer's IPv4 342 address. The Peer's Port Number MAY be only carried when Port-Dependent 343 Mapping are indicated within the received Access-Request message. 345 6. Diameter Considerations 347 This attribute is usable within either RADIUS or Diameter[RFC6733] . 348 Since the Attributes defined in this document will be allocated from 349 the standard RADIUS type space, no special handling is required by 350 Diameter entities. 352 7. IANA Considerations 354 This document requires the assignment of RADIUS Attribute Type in the 355 "Radius Types" registry (currently located at http://www.iana.org/ 356 assignments/radius-types for the following attributes: o 358 o NAT64-Binding-Capable TBD 360 o Requested-Binding-Info TBD 362 o NAT64-Binding-Information TBD 364 IANA should allocate the numbers from the standard RADIUS Attributes 365 space using the "IETF Review" policy [RFC5226]. 367 8. Security Considerations 369 The proposed method is RECOMMENDED to be used with [RFC5580]. 370 Therefore, it shares all the considerations at Section 7 of 371 [RFC5580]. 373 9. References 375 9.1. Normative References 377 [I-D.ietf-appsawg-http-forwarded] 378 Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", 379 draft-ietf-appsawg-http-forwarded-10 (work in progress), 380 October 2012. 382 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 383 Requirement Levels", BCP 14, RFC 2119, March 1997. 385 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 386 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 387 May 2008. 389 [RFC5580] Tschofenig, H., Adrangi, F., Jones, M., Lior, A., and B. 390 Aboba, "Carrying Location Objects in RADIUS and Diameter", 391 RFC 5580, August 2009. 393 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 394 NAT64: Network Address and Protocol Translation from IPv6 395 Clients to IPv4 Servers", RFC 6146, April 2011. 397 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 398 "Diameter Base Protocol", RFC 6733, October 2012. 400 9.2. Informative References 402 [I-D.ietf-v6ops-nat64-experience] 403 Chen, G., Cao, Z., Byrne, C., Xie, C., and D. Binet, 404 "NAT64 Deployment Considerations", draft-ietf-v6ops- 405 nat64-experience-01 (work in progress), January 2013. 407 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 408 Roberts, "Issues with IP Address Sharing", RFC 6269, June 409 2011. 411 Authors' Addresses 413 Gang Chen 414 China Mobile 415 53A,Xibianmennei Ave., 416 Xuanwu District, 417 Beijing 100053 418 China 420 Email: phdgang@gmail.com 421 David Binet 422 France Telecom-Orange 423 Rennes 424 35000 425 France 427 Email: david.binet@orange.com