idnits 2.17.1 draft-ietf-softwire-gateway-init-ds-lite-06.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 (December 16, 2011) is 4513 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) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force F. Brockners 3 Internet-Draft S. Gundavelli 4 Intended status: Standards Track Cisco 5 Expires: June 18, 2012 S. Speicher 6 Deutsche Telekom AG 7 D. Ward 8 Cisco 9 December 16, 2011 11 Gateway Initiated Dual-Stack Lite Deployment 12 draft-ietf-softwire-gateway-init-ds-lite-06 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 June 18, 2012. 42 Copyright Notice 44 Copyright (c) 2011 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. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 68 10. Change History (to be removed prior to publication as an 69 RFC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 72 11.2. Informative References . . . . . . . . . . . . . . . . . 12 73 Appendix A. GI-DS-lite deployment . . . . . . . . . . . . . . . . 12 74 A.1. Connectivity establishment: Example call flow . . . . . . 12 75 A.2. GI-DS-lite applicability: Examples . . . . . . . . . . . 14 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 78 1. Overview 80 Gateway-Initiated Dual-Stack lite (GI-DS-lite) is a variant of the 81 Dual-Stack lite (DS-lite) [RFC6333], applicable to network 82 architectures which use point to point tunnels between the access 83 device and the access gateway. The access gateway in these models is 84 designed to serve large numbers of access devices. Mobile 85 architectures based on Mobile IPv6 [RFC6275], Proxy Mobile IPv6 86 [RFC5213], or GTP [TS29060], as well as broadband architectures based 87 on PPP or point-to-point VLANs as defined by the Broadband Forum (see 88 [TR59] and [TR101]) are examples for this type of architecture. 90 The DS-lite approach leverages IPv4-in-IPv6 tunnels (or other 91 tunneling modes) for carrying the IPv4 traffic from the customer 92 network to the Address Family Transition Router (AFTR). An 93 established softwire between the AFTR and the access device is used 94 for traffic forwarding purposes. This turns the inner IPv4 address 95 irrelevant for traffic routing and allows sharing private IPv4 96 addresses [RFC1918] between customer sites within the service 97 provider network. 99 Similar to DS-lite, GI-DS-lite enables the service provider to share 100 public IPv4 addresses among different customers by combining 101 tunneling and NAT. It allows multiple access devices behind the 102 access gateway to share the same private IPv4 address [RFC1918]. 103 Rather than initiating the tunnel right on the access device, GI-DS- 104 lite logically extends the already existing access tunnels beyond the 105 access gateway towards the Address Family Transition Router (AFTR) 106 using a tunneling mechanism with semantics for carrying context state 107 related to the encapsulated traffic. This approach results in 108 supporting overlapping IPv4 addresses in the access network, 109 requiring no changes to either the access device, or to the access 110 architecture. Additional tunneling overhead in the access network is 111 also omitted. If e.g., a GRE based encapsulation mechanisms is 112 chosen, it allows the network between the access gateway and the AFTR 113 to be either IPv4 or IPv6 and provides the operator to migrate to 114 IPv6 in incremental steps. 116 2. Conventions 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 The following abbreviations are used within this document: 124 AFTR: Address Family Transition Router. An AFTR combines IP-in-IP 125 tunnel termination and IPv4-IPv4 NAT. 127 AD: Access Device. It is the end host, also known as the mobile 128 node in mobile architectures. 130 CID: Context Identifier 132 DS-lite: Dual-stack lite 134 GI-DS-lite: Gateway-initiated DS-lite 136 NAT: Network Address Translator 138 SW: Softwire (see [RFC4925]) 140 SWID: Softwire Identifier 142 3. Gateway Initiated DS-Lite 144 The section provides an overview of Gateway Initiated DS-Lite (GI-DS- 145 lite). Figure 1 outlines the generic deployment scenario for GI-DS- 146 lite. This generic scenario can be mapped to multiple different 147 access architectures, some of which are described in Appendix A. 149 In Figure 1, access devices (AD-1 and AD-2) are connected to the 150 Gateway using some form of tunnel technology and the same is used for 151 carrying IPv4 (and optionally IPv6) traffic of the access device. 152 These access devices may also be connected to the Gateway over point- 153 to-point links. The details on how the network delivers the IPv4 154 address configuration to the access devices are specific to the 155 access architecture and are outside the scope of this document. With 156 GI-DS-lite, Gateway and AFTR are connected by a softwire [RFC4925]. 157 The softwire is identified by a softwire identifier (SWID). The SWID 158 does not need to be globally unique, i.e. different SWIDs could be 159 used to identify a softwire at the different ends of a softwire. The 160 form of the SWID depends on the tunneling technology used for the 161 softwire. The SWID could e.g. be the endpoints of a GRE-tunnel or a 162 VPN-ID, see Section 6 for details. A Context-Identifier (CID) is 163 used to multiplex flows associated with the individual access devices 164 onto the softwire. Deployment dependent, the flows from a particular 165 AD can be identified using either the source IP-address or an access 166 tunnel identifier. Local policies at the Gateway determine which 167 part of the traffic received from an access device is tunneled over 168 the softwire to the AFTR. The combination of CID and SWID must be 169 unique between gateway and AFTR to identify the flows associated with 170 an AD. The CID is typically a 32-bit wide identifier and is assigned 171 by the Gateway. It is retrieved either from a local or remote (e.g. 172 AAA) repository. Like the SWID, the embodiment of the CID depends on 173 the tunnel mode used and the type of the network connecting Gateway 174 and AFTR. If, for example GRE [RFC2784] with "GRE Key and Sequence 175 Number Extensions" [RFC2890] is used as softwire technology, the 176 network connecting Gateway and AFTR could be either IPv4-only, IPv6- 177 only, or a dual-stack IP network. The CID would be carried within 178 the GRE-key field. See Section 6 for details on different softwire 179 types supported with GI-DS-lite. 181 Access Device: AD-1 182 Context Id: CID-1 183 NAT Mappings: 184 IPv4: a.b.c.d +---+ (CID-1, TCP port1 <-> 185 +------+ access tunnel | | e.f.g.h, TCP port2) 186 | AD-1 |=================| G | +---+ 187 +------+ | A | | A | 188 | T | Softwire SWID-1 | F | 189 | E |==========================| T | 190 IPv4: a.b.c.d | W | (e.g. IPv4-over-GRE | R | 191 +------+ | A | over IPv4 or IPv6) +---+ 192 | AD-2 |=================| Y | 193 +------+ access tunnel | | (CID-2, TCP port3 <-> 194 | | e.f.g.h, TCP port4) 195 +---+ 197 Access Device: AD-2 198 Context Id: CID-2 200 Figure 1: Gateway-initiated dual-stack lite reference architecture 202 The AFTR combines softwire termination and IPv4-IPv4 NAT. The NAT 203 binding of the AD's address could be assigned autonomously by the 204 AFTR from a local address pool, configured on a per-binding basis 205 (either by a remote control entity through a NAT control protocol or 206 through manual configuration), or derived from the CID (e.g., the 207 CID, in case 32-bit wide, could be mapped 1:1 to an external IPv4- 208 address). A simple example of a translation table at the AFTR is 209 shown in Figure 2. The choice of the appropriate translation scheme 210 for a traffic flow can take parameters such as destination IP- 211 address, incoming interface, etc. into account. The IP-address of 212 the AFTR, which, depending on the transport network between the 213 Gateway and the AFTR, will either be an IPv6 or an IPv4 address, is 214 configured on the Gateway. A variety of methods, such as out-of-band 215 mechanisms, or manual configuration apply. 217 +=====================================+======================+ 218 | Softwire-Id/Context-Id/IPv4/Port | Public IPv4/Port | 219 +=====================================+======================+ 220 | SWID-1/CID-1/a.b.c.d/TCP-port1 | e.f.g.h/TCP-port2 | 221 | | | 222 | SWID-1/CID-2/a.b.c.d/TCP-port3 | e.f.g.h/TCP-port4 | 223 +-------------------------------------+----------------------+ 225 Figure 2: Example translation table on the AFTR 227 GI-DS-lite does not require a 1:1 relationship between Gateway and 228 AFTR, but more generally applies to (M:N) scenarios, where M Gateways 229 are connected to N AFTRs. Multiple Gateways could be served by a 230 single AFTR. AFTRs could be dedicated to specifc groups of access- 231 devices, groups of Gateways, or geographic regions. An AFTR could, 232 but does not have to be co-located with a Gateway. 234 4. Protocol and related Considerations 236 o Depending on the embodiment of the CID (e.g. for GRE-encapsulation 237 with GRE-key), the NAT binding entry maintained at the AFTR, which 238 reflects an active flow between an access device inside the 239 network and a node in the Internet, needs to be extended to 240 include the CID and the identifier of the softwire (SWID). 242 o When creating an IPv4 to IPv4 NAT binding for an IPv4 packet flow 243 received from the Gateway over the softwire, the AFTR will 244 associate the CID with that NAT binding. It will use the 245 combination of CID and SWID as the unique identifier and will 246 store it in the NAT binding entry. 248 o When forwarding a packet to the access device, the AFTR will 249 obtain the CID from the NAT binding associated with that flow. 250 E.g., in case of GRE-encapsulation, it will add the CID to the GRE 251 Key and Sequence number extension of the GRE header and tunnel it 252 to the Gateway. 254 o On receiving any packet from the softwire, the AFTR will obtain 255 the CID from the incoming packet and will use it for performing 256 the NAT binding look up and for performing the packet translation 257 before forwarding the packet. 259 o The Gateway, on receiving any IPv4 packet from the access device 260 will lookup the CID for that access device. In case of GRE 261 encapsulation it will for example add the CID to the GRE Key and 262 Sequence number extension of the GRE header and tunnel it to the 263 AFTR. 265 o On receiving any packet from the softwire, the Gateway will obtain 266 the CID from the packet and will use it for making the forwarding 267 decision. There will be an association between the CID and the 268 forwarding state. 270 o When encapsulating an IPv4 packet, Gateway and AFTR can use its 271 Diffserv Codepoint (DSCP) to derive the DSCP (or MPLS Traffic- 272 Class Field in case of MPLS) of the softwire. 274 5. Softwire Management and related Considerations 276 The following are the considerations related to the operational 277 management of the softwire between AFTR and Gateway. 279 o The softwire between the Gateway and the AFTR MAY be created at 280 system startup time OR dynamically established on-demand. 281 Deployment dependent, Gateway and AFTR can employ OAM mechanisms 282 such as ICMP, BFD [RFC5880], or LSP ping [RFC4379] for softwire 283 health management and corresponding protection strategies. 285 o The softwire peers may be provisioned to perform policy 286 enforcement, such as for determining the protocol-type or overall 287 portion of traffic that gets tunneled, or for any other quality of 288 service related settings. The specific details on how this is 289 achieved or the types of policies that can be applied are outside 290 the scope for this document. 292 o The softwire peers must have a proper understanding of the path 293 MTU value. This can be statically configured at softwire creation 294 time. 296 o A Gateway and an AFTR can have multiple softwires established 297 between them (e.g. to separate address domains, provide for load- 298 sharing etc.). 300 6. Softwire Embodiments 302 Deployment and requirements dependent, different tunnel technologies 303 apply for the softwire connecting Gateway and AFTR. GRE 304 encapsulation with GRE-key extensions, MPLS VPNs [RFC4364], or plain 305 IP-in-IP encapsulation can be used. Softwire identification and 306 Context-ID depend on the tunneling technology employed: 308 o SWID is the source address of the GRE tunnel from the GW. The CID 309 is the GRE-key associated 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 CE or PE, the SWID could 314 e.g. be an attachment circuit identifier, an identifier 315 representing the set of VPN route labels pointing to the routes 316 within the VPN, etc. The AD's IPv4-address is the CID. For a 317 given VPN, the AD's IPv4 address must be unique. 319 o IPv4/IPv6-in-MPLS: The SWID is the top MPLS label. CID might be 320 the next MPLS label in the stack, if present, or the IP address of 321 the AD. 323 o IPv4-in-IPv4: SWID is the outer IPv4 source address. The AD's 324 IPv4 address is the CID. For a given outer IPv4 source address, 325 the AD's IPv4 address must be unique. 327 o IPv4-in-IPv6: SWID is the outer IPv6 source address. If the AD's 328 IPv4 address is used as CID, the AD's IPv4 address must be unique. 329 If the IPv6-Flow-Label [RFC6437] is used as CID, the IPv4 330 addresses of the ADs may overlap. Given that the IPv6-Flow-Label 331 is 20-bit wide, which is shorter than the recommended 32-bit CID, 332 large scale deployments may require additional scaling 333 considerations. In addition, one should ensure sufficient 334 randomization of the IP-Flow-Label to avoid possible interference 335 with other uses of the IP-Flow-Label, such as ECMP. 337 Figure 3 gives an overview of the different tunnel modes as they 338 apply to different deployment scenarios. "x" indicates that a certain 339 deployment scenario is supported. The following abbreviations are 340 used: 342 o IPv4 address 344 * "up": Deployments with "unique private IPv4 addresses" assigned 345 to the access devices are supported. 347 * "op": Deployments with "overlapping private IPv4 addresses" 348 assigned to the access devices are supported. 350 * "nm": Deployments with "non-meaningful/dummy but unique IPv4 351 addresses" assigned to the access devices are supported. 353 * "s": Deployments where all access devices are assigned the same 354 IPv4 address are supported. 356 o Network-type 358 * "v4": Gateway and AFTR are connected by an IPv4-only network 360 * "v6": Gateway and AFTR are connected by an IPv6-only network 362 * "v4v6": Gateway and AFTR are connected by a dual stack network, 363 supporting IPv4 and IPv4. 365 * "MPLS": Gateway and AFTR are connected by a MPLS network 367 +====================+==================+=======================+ 368 | | IPv4 address | Network-type | 369 | Softwire +----+----+----+---+----+----+------+------+ 370 | | up | op | nm | s | v4 | v6 | v4v6 | MPLS | 371 +====================+====+====+====+===+====+====+======+======+ 372 | GRE with GRE-key | x | x | x | x | x | x | x | | 373 | MPLS VPN | x | x | x | | | | | x | 374 | IPv4/IPv6-in-MPLS | x | x | x | x | | | | x | 375 | IPv4-in-IPv4 | x | | x | | x | | | | 376 | IPv4-in-IPv6 | x | | x | | | x | | | 377 | IPv4-in-IPv6 w/ FL | x | x | x | x | | x | | | 378 +====================+====+====+====+===+====+====+======+======+ 380 Figure 3: Tunnel modes and their applicability 382 7. Acknowledgements 384 The authors would like to acknowledge the discussions on this topic 385 with Mark Grayson, Jay Iyer, Kent Leung, Vojislav Vucetic, Flemming 386 Andreasen, Dan Wing, Jouni Korhonen, Teemu Savolainen, Parviz Yegani, 387 Farooq Bari, Mohamed Boucadair, Vinod Pandey, Jari Arkko, Eric Voit, 388 Yiu L. Lee, Tina Tsou, Guo-Liang Yang, Cathy Zhou, Olaf Bonness, Paco 389 Cortes, and Jim Guichard. 391 8. IANA Considerations 393 This document includes no request to IANA. 395 All drafts are required to have an IANA considerations section (see 396 the update of RFC 2434 [RFC5226] for a guide). If the draft does not 397 require IANA to do anything, the section contains an explicit 398 statement that this is the case (as above). If there are no 399 requirements for IANA, the section will be removed during conversion 400 into an RFC by the RFC Editor. 402 9. Security Considerations 404 All the security considerations from GTP [TS29060], Mobile IPv6 405 [RFC6275], Proxy Mobile IPv6 [RFC5213], and Dual-Stack lite [RFC6333] 406 apply to this specification as well. 408 10. Change History (to be removed prior to publication as an RFC) 410 Changes from -00 to -01 412 a. clarified the applicability of GI-DS-lite to scenarios with M 413 Gateways and N AFTRs. 415 b. clarification of the nomenclature and use of the identifier of 416 the softwire connecting Gateway and AFTR: Introduced softwire 417 identifier (SWID), updated figure 2 accordingly. 419 c. cleanup of editorial nits. 421 d. added IP-Flow-Label as CID. 423 Changes from -00 to -02 425 a. added considerations for the use of the IP-Flow-Label as CID. 427 b. editorial edits (additional acknowledgements). 429 Changes from -02 to -03 431 a. editorial edits (following WG reviews) 433 b. moved section on GI-DS-lite to the annex 435 Changes from -03 to -04 437 a. clarified the use of MPLS VPN encapsulation 439 Changes from -04 to -05 441 a. added plain IPv4/IPv6-in-MPLS 443 b. allow for the softwire between Gateway and AFTR to be established 444 at any point in time (not just at startup) 446 11. References 447 11.1. Normative References 449 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 450 E. Lear, "Address Allocation for Private Internets", 451 BCP 5, RFC 1918, February 1996. 453 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 454 Requirement Levels", BCP 14, RFC 2119, March 1997. 456 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 457 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 458 March 2000. 460 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 461 RFC 2890, September 2000. 463 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 464 Networks (VPNs)", RFC 4364, February 2006. 466 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 467 Label Switched (MPLS) Data Plane Failures", RFC 4379, 468 February 2006. 470 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 471 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 473 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 474 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 475 May 2008. 477 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 478 Routers", RFC 5555, June 2009. 480 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 481 (BFD)", RFC 5880, June 2010. 483 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 484 in IPv6", RFC 6275, July 2011. 486 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 487 Stack Lite Broadband Deployments Following IPv4 488 Exhaustion", RFC 6333, August 2011. 490 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 491 "IPv6 Flow Label Specification", RFC 6437, November 2011. 493 11.2. Informative References 495 [I-D.draft-ietf-dime-nat-control] 496 Brockners, F., Bhandari, S., Singh, V., and V. Fajardo, 497 "Diameter NAT Control Application", August 2009. 499 [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire 500 Problem Statement", RFC 4925, July 2007. 502 [TR101] Broadband Forum, "TR-101: Migration to Ethernet-Based DSL 503 Aggregation", April 2006. 505 [TR59] Broadband Forum, "TR-059: DSL Evolution - Architecture 506 Requirements for the Support of QoS-Enabled IP Services", 507 September 2003. 509 [TS23060] "3rd Generation Partnership Project; Technical 510 Specification Group Services and System Aspects; General 511 Packet Radio Service (GPRS); Service description; Stage 512 2.", 2009. 514 [TS23401] "3rd Generation Partnership Project; Technical 515 Specification Group Services and System Aspects; General 516 Packet Radio Service (GPRS) enhancements for Evolved 517 Universal Terrestrial Radio Access Network (E-UTRAN) 518 access.", 2009. 520 [TS29060] "3rd Generation Partnership Project; Technical 521 Specification Group Core Network and Terminals; General 522 Packet Radio Service (GPRS); GPRS Tunnelling Protocol 523 (GTP), V9.1.0", 2009. 525 Appendix A. GI-DS-lite deployment 527 A.1. Connectivity establishment: Example call flow 529 Figure 4 shows an example call flow - linking access tunnel 530 establishment on the Gateway with the softwire to the AFTR. This 531 simple example assumes that traffic from the AD uses a single access 532 tunnel and that the Gateway will use local polices to decide which 533 portion of the traffic received over this access tunnel needs to be 534 forwarded to the AFTR. 536 AD Gateway AAA/Policy AFTR 537 | | | | 538 |----(1)-------->| | | 539 | (2)<-------------->| | 540 | (3) | | 541 | |<------(4)------------------->| 542 | (5) | | 543 |<---(6)-------->| | | 544 | | | | 546 Figure 4: Example call flow for session establishment 548 1. Gateway receives a request to create an access tunnel endpoint. 550 2. The Gateway authenticates and authorizes the access tunnel. 551 Based on local policy or through interaction with the AAA/Policy 552 system the Gateway recognizes that IPv4 service should be 553 provided using GI-DS-lite. 555 3. The Gateway creates an access tunnel endpoint. The access tunnel 556 links AD and Gateway. 558 4. (Optional): The Gateway and the AFTR establish a control session 559 between each other. This session can for example be used to 560 exchange accounting or NAT-configuration information. Accounting 561 information could be supplied to the Gateway, AAA/Policy, or 562 other network entities which require information about the 563 externally visible address/port pairs of a particular access 564 device. The Diameter NAT Control Application (see 565 [I-D.draft-ietf-dime-nat-control] could for example be used for 566 this purpose. 568 5. The Gateway allocates a unique CID and associates those flows 569 received from the access tunnel that need to be tunneled towards 570 the AFTR with the softwire linking Gateway and AFTR. Local 571 forwarding policy on the Gateway determines which traffic will 572 need to be tunneled towards the AFTR. 574 6. Gateway and AD complete the access tunnel establishment 575 (depending on the procedures and mechanisms of the corresponding 576 access network architecture this step can include the assignment 577 of an IPv4 address to the AD). 579 A.2. GI-DS-lite applicability: Examples 581 The section outlines deployment examples of the generic GI-DS-lite 582 architecture described in Section 3. 584 o Mobile IP based access architectures: In a MIPv6 [RFC5555] based 585 network scenario, the Mobile IPv6 home agent will implement the 586 GI-DS-lite Gateway function along with the dual-stack Mobile IPv6 587 functionality. 589 o Proxy Mobile IP based access architectures: In a PMIPv6 [RFC5213] 590 scenario the local mobility anchor (LMA) will implement the GI-DS- 591 lite Gateway function along with the PMIPv6 IPv4 support 592 functionality. 594 o GTP based access architectures: 3GPP TS 23.401 [TS23401] and 3GPP 595 TS 23.060 [TS23060] define mobile access architectures using GTP. 596 For GI-DS-lite, the PDN-Gateway/GGSN will also assume the Gateway 597 function. 599 o Fixed WiMAX architecture: If GI-DS-lite is applied to fixed WiMAX, 600 the ASN-Gateway will implement the GI-DS-lite Gateway function. 602 o Mobile WiMAX: If GI-DS-lite is applied to mobile WiMAX, the home 603 agent will implement the Gateway function. 605 o PPP-based broadband access architectures: If GI-DS-lite is applied 606 to PPP-based access architectures the Broadband Remote Access 607 Server (BRAS) or Broadband Network Gateway (BNG) will implement 608 the GI-DS-lite Gateway function. 610 o In broadband access architectures using per-subscriber VLANs the 611 BNG will implement the GI-DS-lite Gateway function. 613 Authors' Addresses 615 Frank Brockners 616 Cisco 617 Hansaallee 249, 3rd Floor 618 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 619 Germany 621 Email: fbrockne@cisco.com 622 Sri Gundavelli 623 Cisco 624 170 West Tasman Drive 625 SAN JOSE, CA 95134 626 USA 628 Email: sgundave@cisco.com 630 Sebastian Speicher 631 Deutsche Telekom AG 632 Landgrabenweg 151 633 BONN, NORDRHEIN-WESTFALEN 53277 634 Germany 636 Email: sebastian.speicher@telekom.de 638 David Ward 639 Cisco 640 170 West Tasman Drive 641 SAN JOSE, CA 95134 642 USA 644 Email: daveward@cisco.com