idnits 2.17.1 draft-ietf-softwire-gateway-init-ds-lite-08.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 (April 28, 2012) is 4378 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) ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SOFTWIRE WG F. Brockners 3 Internet-Draft S. Gundavelli 4 Intended status: Standards Track Cisco 5 Expires: October 30, 2012 S. Speicher 6 Deutsche Telekom AG 7 D. Ward 8 Cisco 9 April 28, 2012 11 Gateway Initiated Dual-Stack Lite Deployment 12 draft-ietf-softwire-gateway-init-ds-lite-08 14 Abstract 16 Gateway-Initiated Dual-Stack lite (GI-DS-lite) is a variant of Dual- 17 Stack lite (DS-lite) applicable to certain tunnel-based access 18 architectures. GI-DS-lite extends existing access tunnels beyond the 19 access gateway to an IPv4-IPv4 NAT using softwires with an embedded 20 context identifier that uniquely identifies the end-system the 21 tunneled packets belong to. The access gateway determines which 22 portion of the traffic requires NAT using local policies and sends/ 23 receives this portion to/from this softwire. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on October 30, 2012. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Gateway Initiated DS-Lite . . . . . . . . . . . . . . . . . . 4 62 4. Protocol and related Considerations . . . . . . . . . . . . . 6 63 5. Softwire Management and related Considerations . . . . . . . . 7 64 6. Softwire Embodiments . . . . . . . . . . . . . . . . . . . . . 7 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 70 10.2. Informative References . . . . . . . . . . . . . . . . . 11 71 Appendix A. GI-DS-lite deployment . . . . . . . . . . . . . . . . 12 72 A.1. Connectivity establishment: Example call flow . . . . . . 12 73 A.2. GI-DS-lite applicability: Examples . . . . . . . . . . . 13 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 76 1. Overview 78 Gateway-Initiated Dual-Stack lite (GI-DS-lite) is a variant of the 79 Dual-Stack lite (DS-lite) [RFC6333], applicable to network 80 architectures which use point to point tunnels between the access 81 device and the access gateway. The access gateway in these models is 82 designed to serve large numbers of access devices. Mobile 83 architectures based on Mobile IPv6 [RFC6275], Proxy Mobile IPv6 84 [RFC5213], or GTP [TS29060], as well as broadband architectures based 85 on PPP or point-to-point VLANs as defined by the Broadband Forum 86 [TR59] and [TR101] are examples for this type of architecture. 88 The DS-lite approach leverages IPv4-in-IPv6 tunnels (or other 89 tunneling modes) for carrying the IPv4 traffic from the customer 90 network to the Address Family Transition Router (AFTR). An 91 established softwire between the AFTR and the access device is used 92 for traffic forwarding purposes. This turns the inner IPv4 address 93 irrelevant for traffic routing and allows sharing private IPv4 94 addresses [RFC1918] between customer sites within the service 95 provider network. 97 Similar to DS-lite, GI-DS-lite enables the service provider to share 98 public IPv4 addresses among different customers by combining 99 tunneling and NAT. It allows multiple access devices behind the 100 access gateway to share the same private IPv4 address [RFC1918]. 101 Rather than initiating the tunnel right on the access device, GI-DS- 102 lite logically extends the already existing access tunnels beyond the 103 access gateway towards the Address Family Transition Router (AFTR) 104 using a tunneling mechanism with semantics for carrying context state 105 related to the encapsulated traffic. This approach results in 106 supporting overlapping IPv4 addresses in the access network, 107 requiring no changes to either the access device, or to the access 108 architecture. Additional tunneling overhead in the access network is 109 also omitted. If e.g., GRE based encapsulation mechanisms is chosen, 110 it allows the network between the access gateway and the AFTR to be 111 either IPv4 or IPv6 and provides the operator to migrate to IPv6 in 112 incremental steps. 114 2. Conventions 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [RFC2119]. 120 The following abbreviations are used within this document: 122 AFTR: Address Family Transition Router. An AFTR combines IP-in-IP 123 tunnel termination and IPv4-IPv4 NAT. 125 AD: Access Device. It is the end host, also known as the mobile 126 node in mobile architectures. 128 CID: Context Identifier 130 DS-lite: Dual-stack lite 132 GI-DS-lite: Gateway-initiated DS-lite 134 NAT: Network Address Translator 136 SW: Softwire [RFC4925] 138 SWID: Softwire Identifier 140 3. Gateway Initiated DS-Lite 142 The section provides an overview of Gateway Initiated DS-Lite (GI-DS- 143 lite). Figure 1 outlines the generic deployment scenario for GI-DS- 144 lite. This generic scenario can be mapped to multiple different 145 access architectures, some of which are described in Appendix A. 147 In Figure 1, access devices (AD-1 and AD-2) are connected to the 148 Gateway using some form of tunnel technology and the same is used for 149 carrying IPv4 (and optionally IPv6) traffic of the access device. 150 These access devices may also be connected to the Gateway over point- 151 to-point links. The details on how the network delivers the IPv4 152 address configuration to the access devices are specific to the 153 access architecture and are outside the scope of this document. With 154 GI-DS-lite, Gateway and AFTR are connected by a softwire [RFC4925]. 155 The softwire is identified by a softwire identifier (SWID). The SWID 156 does not need to be globally unique, i.e. different SWIDs could be 157 used to identify a softwire at the different ends of a softwire. The 158 form of the SWID depends on the tunneling technology used for the 159 softwire. The SWID could e.g. be the endpoints of a GRE-tunnel or a 160 VPN-ID, Section 6 for details. A Context-Identifier (CID) is used to 161 multiplex flows associated with the individual access devices onto 162 the softwire. Deployment dependent, the flows from a particular AD 163 can be identified using either the source IP-address or an access 164 tunnel identifier. Local policies at the Gateway determine which 165 part of the traffic received from an access device is tunneled over 166 the softwire to the AFTR. The combination of CID and SWID must be 167 unique between gateway and AFTR to identify the flows associated with 168 an AD. The CID is typically a 32-bit wide identifier and is assigned 169 by the Gateway. It is retrieved either from a local or remote (e.g. 170 AAA) repository. Like the SWID, the embodiment of the CID depends on 171 the tunnel mode used and the type of the network connecting Gateway 172 and AFTR. If, for example GRE [RFC2784] with "GRE Key and Sequence 173 Number Extensions" [RFC2890] is used as softwire technology, the 174 network connecting Gateway and AFTR could be either IPv4-only, IPv6- 175 only, or a dual-stack IP network. The CID would be carried within 176 the GRE-key field. Section 6 for details on different softwire types 177 supported with GI-DS-lite. 179 Access Device: AD-1 180 Context Id: CID-1 181 NAT Mappings: 182 IPv4: a.b.c.d +---+ (CID-1, TCP port1 <-> 183 +------+ access tunnel | | e.f.g.h, TCP port2) 184 | AD-1 |=================| G | +---+ 185 +------+ | A | | A | 186 | T | Softwire SWID-1 | F | 187 | E |==========================| T | 188 IPv4: a.b.c.d | W | (e.g. IPv4-over-GRE | R | 189 +------+ | A | over IPv4 or IPv6) +---+ 190 | AD-2 |=================| Y | 191 +------+ access tunnel | | (CID-2, TCP port3 <-> 192 | | e.f.g.h, TCP port4) 193 +---+ 195 Access Device: AD-2 196 Context Id: CID-2 198 Figure 1: Gateway-initiated dual-stack lite reference architecture 200 The AFTR combines softwire termination and IPv4-IPv4 NAT. The NAT 201 binding of the AD's address could be assigned autonomously by the 202 AFTR from a local address pool, configured on a per-binding basis 203 (either by a remote control entity through a NAT control protocol or 204 through manual configuration), or derived from the CID (e.g., the 205 CID, in case 32-bit wide, could be mapped 1:1 to an external IPv4- 206 address). A simple example of a translation table at the AFTR is 207 shown in Figure 2. The choice of the appropriate translation scheme 208 for a traffic flow can take parameters such as destination IP- 209 address, incoming interface, etc. into account. The IP-address of 210 the AFTR, which, depending on the transport network between the 211 Gateway and the AFTR, will either be an IPv6 or an IPv4 address, is 212 configured on the Gateway. A variety of methods, such as out-of-band 213 mechanisms, or manual configuration apply. 215 +=====================================+======================+ 216 | Softwire-Id/Context-Id/IPv4/Port | Public IPv4/Port | 217 +=====================================+======================+ 218 | SWID-1/CID-1/a.b.c.d/TCP-port1 | e.f.g.h/TCP-port2 | 219 | | | 220 | SWID-1/CID-2/a.b.c.d/TCP-port3 | e.f.g.h/TCP-port4 | 221 +-------------------------------------+----------------------+ 223 Figure 2: Example translation table on the AFTR 225 GI-DS-lite does not require a 1:1 relationship between Gateway and 226 AFTR, but more generally applies to (M:N) scenarios, where M Gateways 227 are connected to N AFTRs. Multiple Gateways could be served by a 228 single AFTR. AFTRs could be dedicated to specific groups of access- 229 devices, groups of Gateways, or geographic regions. An AFTR could, 230 but does not have to be co-located with a Gateway. 232 4. Protocol and related Considerations 234 o Depending on the embodiment of the CID (e.g. for GRE-encapsulation 235 with GRE-key), the NAT binding entry maintained at the AFTR, which 236 reflects an active flow between an access device inside the 237 network and a node in the Internet, SHOULD be extended to include 238 the CID and the identifier of the softwire (SWID). 240 o When creating an IPv4 to IPv4 NAT binding for an IPv4 packet flow 241 received from the Gateway over the softwire, the AFTR SHOULD 242 associate the CID with that NAT binding. It SHOULD use the 243 combination of CID and SWID as the unique identifier and use those 244 parameters in the NAT binding entry. 246 o When forwarding a packet to the access device, the AFTR SHOULD 247 obtain the CID from the NAT binding associated with that flow. 248 E.g., in case of GRE-encapsulation, it SHOULD add the CID to the 249 GRE Key and Sequence number extension of the GRE header and tunnel 250 it to the Gateway. 252 o On receiving any packet from the softwire, the AFTR SHOULD obtain 253 the CID from the incoming packet and use it for performing the NAT 254 binding look up and for performing the packet translation before 255 forwarding the packet. 257 o The Gateway, on receiving any IPv4 packet from the access device 258 SHOULD lookup the CID for that access device. In case of GRE 259 encapsulation it can for example add the CID to the GRE Key and 260 Sequence number extension of the GRE header and tunnel it to the 261 AFTR. 263 o On receiving any packet from the softwire, the Gateway SHOULD 264 obtain the CID from the packet and use it for making the 265 forwarding decision. 267 o When encapsulating an IPv4 packet, Gateway and AFTR SHOULD use its 268 Diffserv Codepoint (DSCP) to derive the DSCP (or MPLS Traffic- 269 Class Field in case of MPLS) of the softwire. 271 5. Softwire Management and related Considerations 273 The following are the considerations related to the operational 274 management of the softwire between AFTR and Gateway. 276 o The softwire between the Gateway and the AFTR MAY be created at 277 system startup time, OR dynamically established on-demand. 278 Deployment dependent, Gateway and AFTR can employ OAM mechanisms 279 such as ICMP, BFD [RFC5880], or LSP ping [RFC4379] for softwire 280 health management and corresponding protection strategies. 282 o The softwire peers MAY be provisioned to perform policy 283 enforcement, such as for determining the protocol-type or overall 284 portion of traffic that gets tunneled, or for any other quality of 285 service related settings. The specific details on how this is 286 achieved or the types of policies that can be applied are outside 287 the scope for this document. 289 o The softwire peers SHOULD use the correct path MTU value for the 290 tunnel path between the access gateway and the AFTR. This value 291 MAY be statically configured at softwire creation time, or 292 dynamically discovered using the standard path MTU discovery 293 techniques. 295 o A Gateway and an AFTR can have multiple softwires established 296 between them (e.g. to separate address domains, provide for load- 297 sharing etc.). 299 6. Softwire Embodiments 301 Deployment and requirements dependent, different tunnel technologies 302 apply for the softwire connecting Gateway and AFTR. GRE 303 encapsulation with GRE-key extensions, MPLS VPNs [RFC4364], or plain 304 IP-in-IP encapsulation can be used. Softwire identification and 305 Context-ID depend on the tunneling technology employed: 307 o GRE with GRE-key: SWID is the tunnel identifier of the GRE tunnel 308 between the GW and the AFTR. The CID is the GRE-key associated 309 with the AD. 311 o MPLS VPN: The SWID is a generic identifier which uniquely 312 identifies the VPN at either the Gateway or AFTR. Depending on 313 whether the Gateway or AFTR are acting as customer edge (CE) or, 314 provider edge (PE), the SWID could e.g. be an attachment circuit 315 identifier, an identifier representing the set of VPN route labels 316 pointing to the routes within the VPN, etc. The AD's IPv4-address 317 is the CID. For a given VPN, the AD's IPv4 address must be 318 unique. 320 o IPv4/IPv6-in-MPLS: The SWID is the top MPLS label. CID might be 321 the next MPLS label in the stack, if present, or the IP address of 322 the AD. 324 o IPv4-in-IPv4: SWID is the outer IPv4 source address. The AD's 325 IPv4 address is the CID. For a given outer IPv4 source address, 326 the AD's IPv4 address must be unique. 328 o IPv4-in-IPv6: SWID is the outer IPv6 source address. If the AD's 329 IPv4 address is used as CID, the AD's IPv4 address must be unique. 330 If the IPv6-Flow-Label [RFC6437] is used as CID, the IPv4 331 addresses of the ADs may overlap. Given that the IPv6-Flow-Label 332 is 20-bit wide, which is shorter than the recommended 32-bit CID, 333 large scale deployments may require additional scaling 334 considerations. In addition, one should ensure sufficient 335 randomization of the IP-Flow-Label to avoid possible interference 336 with other uses of the IP-Flow-Label, such as Equal Cost Multipath 337 (ECMP) support. 339 Figure 3 gives an overview of the different tunnel modes as they 340 apply to different deployment scenarios. "x" indicates that a certain 341 deployment scenario is supported. The following abbreviations are 342 used: 344 o IPv4 address 346 * "up": Deployments with "unique private IPv4 addresses" assigned 347 to the access devices are supported. 349 * "op": Deployments with "overlapping private IPv4 addresses" 350 assigned to the access devices are supported. 352 * "s": Deployments where all access devices are assigned the same 353 IPv4 address are supported. 355 o Network-type 357 * "v4": Gateway and AFTR are connected by an IPv4-only network 359 * "v6": Gateway and AFTR are connected by an IPv6-only network 361 * "v4v6": Gateway and AFTR are connected by a dual stack network, 362 supporting IPv4 and IPv4. 364 * "MPLS": Gateway and AFTR are connected by a MPLS network 366 +===================+==============+=======================+ 367 | | IPv4 address| Network-type | 368 | Softwire +----+----+---+----+----+------+------+ 369 | | up | op | s | v4 | v6 | v4v6 | MPLS | 370 +====================+====+====+===+====+====+======+======+ 371 | GRE with GRE-key | x | x | x | x | x | x | | 372 | MPLS VPN | x | x | | | | | x | 373 | IPv4/IPv6-in-MPLS | x | x | x | | | | x | 374 | IPv4-in-IPv4 | x | | | x | | | | 375 | IPv4-in-IPv6 | x | | | | x | | | 376 | IPv4-in-IPv6 w/ FL | x | x | x | | x | | | 377 +====================+====+====+===+====+====+======+======+ 379 Figure 3: Tunnel modes and their applicability 381 7. IANA Considerations 383 This specification does not require any IANA actions. 385 8. Security Considerations 387 The approach specified in this document allows the use of Dual-stack 388 lite for tunnel-based access architectures. Rather than initiating 389 the tunnel from the access device, GI-DS-lite logically extends the 390 already existing access tunnel beyond the access gateway towards the 391 Address Family Transition Router, and builds a virtual softwire 392 between the AFTR and the access device. This approach requires the 393 use of an additional context identifier in the AFTR and at the access 394 gateway, which is required for making IP packet forwarding decisions. 396 A packet when received with an Incorrect context identifier at the 397 access gateway/AFTR will result in associating the packet to an 398 incorrect access device. Therefore, care must be taken to ensure an 399 IP packet tunneled between the access gateway and the AFTR is carried 400 with the context identifier of the access device associated with that 401 IP packet. The context identifier is not carried from the access 402 device and it is not possible for one access device to claim the 403 context identifier of some other access device. However, It is 404 possible an on-path attacker between the access gateway and the AFTR 405 can potentially modify the context identifier in the packet, 406 resulting in association of the packet to an incorrect access device. 407 This threat is no different from an on-path attacker modifying the 408 source/destination address of an IP packet. However, this threat can 409 be prevented by enabling IPsec security with integrity protection 410 turned on, between the access gateway and the AFTR, that will ensure 411 the correct binding of the context identifier and the inner packet. 412 This specification does not require any other new security 413 considerations other than those specified in dual-stack lite 414 specification [RFC6333], and in the security considerations specified 415 for the given access architecture, such as Proxy Mobile IPv6, 416 leveraging this transitioning scheme. 418 9. Acknowledgements 420 The authors would like to acknowledge the discussions on this topic 421 with Mark Grayson, Jay Iyer, Kent Leung, Vojislav Vucetic, Flemming 422 Andreasen, Dan Wing, Jouni Korhonen, Teemu Savolainen, Parviz Yegani, 423 Farooq Bari, Mohamed Boucadair, Vinod Pandey, Jari Arkko, Eric Voit, 424 Yiu L. Lee, Tina Tsou, Guo-Liang Yang, Cathy Zhou, Olaf Bonness, Paco 425 Cortes, Jim Guichard, Stephen Farrell, Pete Resnik, Ralph Droms. 427 10. References 429 10.1. Normative References 431 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 432 E. Lear, "Address Allocation for Private Internets", 433 BCP 5, RFC 1918, February 1996. 435 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 436 Requirement Levels", BCP 14, RFC 2119, March 1997. 438 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 439 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 440 March 2000. 442 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 443 RFC 2890, September 2000. 445 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 446 Networks (VPNs)", RFC 4364, February 2006. 448 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 449 Label Switched (MPLS) Data Plane Failures", RFC 4379, 450 February 2006. 452 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 453 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 455 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 456 Routers", RFC 5555, June 2009. 458 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 459 Mobile IPv6", RFC 5844, May 2010. 461 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 462 (BFD)", RFC 5880, June 2010. 464 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 465 in IPv6", RFC 6275, July 2011. 467 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 468 Stack Lite Broadband Deployments Following IPv4 469 Exhaustion", RFC 6333, August 2011. 471 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 472 "IPv6 Flow Label Specification", RFC 6437, November 2011. 474 10.2. Informative References 476 [I-D.draft-ietf-dime-nat-control] 477 Brockners, F., Bhandari, S., Singh, V., and V. Fajardo, 478 "Diameter NAT Control Application", August 2009. 480 [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire 481 Problem Statement", RFC 4925, July 2007. 483 [TR101] Broadband Forum, "TR-101: Migration to Ethernet-Based DSL 484 Aggregation", April 2006. 486 [TR59] Broadband Forum, "TR-059: DSL Evolution - Architecture 487 Requirements for the Support of QoS-Enabled IP Services", 488 September 2003. 490 [TS23060] "3rd Generation Partnership Project; Technical 491 Specification Group Services and System Aspects; General 492 Packet Radio Service (GPRS); Service description; Stage 493 2.", 2009. 495 [TS23401] "3rd Generation Partnership Project; Technical 496 Specification Group Services and System Aspects; General 497 Packet Radio Service (GPRS) enhancements for Evolved 498 Universal Terrestrial Radio Access Network (E-UTRAN) 499 access.", 2009. 501 [TS29060] "3rd Generation Partnership Project; Technical 502 Specification Group Core Network and Terminals; General 503 Packet Radio Service (GPRS); GPRS Tunnelling Protocol 504 (GTP), V9.1.0", 2009. 506 Appendix A. GI-DS-lite deployment 508 A.1. Connectivity establishment: Example call flow 510 Figure 4 shows an example call flow - linking access tunnel 511 establishment on the Gateway with the softwire to the AFTR. This 512 simple example assumes that traffic from the AD uses a single access 513 tunnel and that the Gateway will use local polices to decide which 514 portion of the traffic received over this access tunnel needs to be 515 forwarded to the AFTR. 517 AD Gateway AAA/Policy AFTR 518 | | | | 519 |----(1)-------->| | | 520 | (2)<-------------->| | 521 | (3) | | 522 | |<------(4)------------------->| 523 | (5) | | 524 |<---(6)-------->| | | 525 | | | | 527 Figure 4: Example call flow for session establishment 529 1. Gateway receives a request to create an access tunnel endpoint. 531 2. The Gateway authenticates and authorizes the access tunnel. 532 Based on local policy or through interaction with the AAA/Policy 533 system the Gateway recognizes that IPv4 service should be 534 provided using GI-DS-lite. 536 3. The Gateway creates an access tunnel endpoint. The access tunnel 537 links AD and Gateway. 539 4. (Optional): The Gateway and the AFTR establish a control session 540 between each other. This session can for example be used to 541 exchange accounting or NAT-configuration information. Accounting 542 information could be supplied to the Gateway, AAA/Policy, or 543 other network entities which require information about the 544 externally visible address/port pairs of a particular access 545 device. The Diameter NAT Control Application 546 [I-D.draft-ietf-dime-nat-control] could for example be used for 547 this purpose. 549 5. The Gateway allocates a unique CID and associates those flows 550 received from the access tunnel that need to be tunneled towards 551 the AFTR with the softwire linking Gateway and AFTR. Local 552 forwarding policy on the Gateway determines which traffic will 553 need to be tunneled towards the AFTR. 555 6. Gateway and AD complete the access tunnel establishment 556 (depending on the procedures and mechanisms of the corresponding 557 access network architecture this step can include the assignment 558 of an IPv4 address to the AD). 560 A.2. GI-DS-lite applicability: Examples 562 The section outlines deployment examples of the generic GI-DS-lite 563 architecture described in Section 3. 565 o Mobile IP based access architectures: In a DSMIPv6 [RFC5555] based 566 network scenario, the Mobile IPv6 home agent will implement the 567 GI-DS-lite Gateway function along with the dual-stack Mobile IPv6 568 functionality. 570 o Proxy Mobile IPv6 based access architectures: In a PMIPv6 571 [RFC5213] scenario the local mobility anchor (LMA) will implement 572 the GI-DS-lite Gateway function along with the PMIPv6 IPv4 support 573 [RFC5844] functionality. 575 o GTP based access architectures: 3GPP TS 23.401 [TS23401] and 3GPP 576 TS 23.060 [TS23060] define mobile access architectures using GTP. 577 For GI-DS-lite, the PDN-Gateway/GGSN will also assume the Gateway 578 function. 580 o Fixed WiMAX architecture: If GI-DS-lite is applied to fixed WiMAX, 581 the ASN-Gateway will implement the GI-DS-lite Gateway function. 583 o Mobile WiMAX: If GI-DS-lite is applied to mobile WiMAX, the home 584 agent will implement the Gateway function. 586 o PPP-based broadband access architectures: If GI-DS-lite is applied 587 to PPP-based access architectures the Broadband Remote Access 588 Server (BRAS) or Broadband Network Gateway (BNG) will implement 589 the GI-DS-lite Gateway function. 591 o In broadband access architectures using per-subscriber VLANs the 592 BNG will implement the GI-DS-lite Gateway function. 594 Authors' Addresses 596 Frank Brockners 597 Cisco 598 Hansaallee 249, 3rd Floor 599 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 600 Germany 602 Email: fbrockne@cisco.com 604 Sri Gundavelli 605 Cisco 606 170 West Tasman Drive 607 SAN JOSE, CA 95134 608 USA 610 Email: sgundave@cisco.com 612 Sebastian Speicher 613 Deutsche Telekom AG 614 Landgrabenweg 151 615 BONN, NORDRHEIN-WESTFALEN 53277 616 Germany 618 Email: sebastian.speicher@telekom.de 620 David Ward 621 Cisco 622 170 West Tasman Drive 623 SAN JOSE, CA 95134 624 USA 626 Email: wardd@cisco.com