idnits 2.17.1 draft-ietf-softwire-gateway-init-ds-lite-07.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 22, 2012) is 4386 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 24, 2012 S. Speicher 6 Deutsche Telekom AG 7 D. Ward 8 Cisco 9 April 22, 2012 11 Gateway Initiated Dual-Stack Lite Deployment 12 draft-ietf-softwire-gateway-init-ds-lite-07 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 24, 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 . . . . . . . . . . . . . . . . 11 72 A.1. Connectivity establishment: Example call flow . . . . . . 12 73 A.2. GI-DS-lite applicability: Examples . . . . . . . . . . . 13 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 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 to tunnel-based access architectures. Rather than initiating 389 the tunnel right from the access device, GI-DS-lite logically extends 390 the already existing access tunnel beyond the access gateway towards 391 the Address Family Transition Router, and builds a virtual softwire 392 between the AFTR and the access device. This approach requires the 393 use of additional context identifier in the AFTR and at the access 394 gateway, which is required for making IP packet forwarding decisions. 395 These additional considerations related to the use of context 396 identifiers in the packet forwarding logic does not introduce any new 397 security vulnerabilities. Therefore, this specification does not 398 require any new security considerations other than what are specified 399 in Dual-stack lite specification [RFC6333], and the security 400 considerations specific to the access architecture. 402 9. Acknowledgements 404 The authors would like to acknowledge the discussions on this topic 405 with Mark Grayson, Jay Iyer, Kent Leung, Vojislav Vucetic, Flemming 406 Andreasen, Dan Wing, Jouni Korhonen, Teemu Savolainen, Parviz Yegani, 407 Farooq Bari, Mohamed Boucadair, Vinod Pandey, Jari Arkko, Eric Voit, 408 Yiu L. Lee, Tina Tsou, Guo-Liang Yang, Cathy Zhou, Olaf Bonness, Paco 409 Cortes, Jim Guichard, Stephen Farrell, Pete Resnik, Ralph Droms. 411 10. References 413 10.1. Normative References 415 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 416 E. Lear, "Address Allocation for Private Internets", 417 BCP 5, RFC 1918, February 1996. 419 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 420 Requirement Levels", BCP 14, RFC 2119, March 1997. 422 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 423 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 424 March 2000. 426 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 427 RFC 2890, September 2000. 429 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 430 Networks (VPNs)", RFC 4364, February 2006. 432 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 433 Label Switched (MPLS) Data Plane Failures", RFC 4379, 434 February 2006. 436 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 437 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 439 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 440 Routers", RFC 5555, June 2009. 442 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 443 Mobile IPv6", RFC 5844, May 2010. 445 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 446 (BFD)", RFC 5880, June 2010. 448 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 449 in IPv6", RFC 6275, July 2011. 451 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 452 Stack Lite Broadband Deployments Following IPv4 453 Exhaustion", RFC 6333, August 2011. 455 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 456 "IPv6 Flow Label Specification", RFC 6437, November 2011. 458 10.2. Informative References 460 [I-D.draft-ietf-dime-nat-control] 461 Brockners, F., Bhandari, S., Singh, V., and V. Fajardo, 462 "Diameter NAT Control Application", August 2009. 464 [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire 465 Problem Statement", RFC 4925, July 2007. 467 [TR101] Broadband Forum, "TR-101: Migration to Ethernet-Based DSL 468 Aggregation", April 2006. 470 [TR59] Broadband Forum, "TR-059: DSL Evolution - Architecture 471 Requirements for the Support of QoS-Enabled IP Services", 472 September 2003. 474 [TS23060] "3rd Generation Partnership Project; Technical 475 Specification Group Services and System Aspects; General 476 Packet Radio Service (GPRS); Service description; Stage 477 2.", 2009. 479 [TS23401] "3rd Generation Partnership Project; Technical 480 Specification Group Services and System Aspects; General 481 Packet Radio Service (GPRS) enhancements for Evolved 482 Universal Terrestrial Radio Access Network (E-UTRAN) 483 access.", 2009. 485 [TS29060] "3rd Generation Partnership Project; Technical 486 Specification Group Core Network and Terminals; General 487 Packet Radio Service (GPRS); GPRS Tunnelling Protocol 488 (GTP), V9.1.0", 2009. 490 Appendix A. GI-DS-lite deployment 491 A.1. Connectivity establishment: Example call flow 493 Figure 4 shows an example call flow - linking access tunnel 494 establishment on the Gateway with the softwire to the AFTR. This 495 simple example assumes that traffic from the AD uses a single access 496 tunnel and that the Gateway will use local polices to decide which 497 portion of the traffic received over this access tunnel needs to be 498 forwarded to the AFTR. 500 AD Gateway AAA/Policy AFTR 501 | | | | 502 |----(1)-------->| | | 503 | (2)<-------------->| | 504 | (3) | | 505 | |<------(4)------------------->| 506 | (5) | | 507 |<---(6)-------->| | | 508 | | | | 510 Figure 4: Example call flow for session establishment 512 1. Gateway receives a request to create an access tunnel endpoint. 514 2. The Gateway authenticates and authorizes the access tunnel. 515 Based on local policy or through interaction with the AAA/Policy 516 system the Gateway recognizes that IPv4 service should be 517 provided using GI-DS-lite. 519 3. The Gateway creates an access tunnel endpoint. The access tunnel 520 links AD and Gateway. 522 4. (Optional): The Gateway and the AFTR establish a control session 523 between each other. This session can for example be used to 524 exchange accounting or NAT-configuration information. Accounting 525 information could be supplied to the Gateway, AAA/Policy, or 526 other network entities which require information about the 527 externally visible address/port pairs of a particular access 528 device. The Diameter NAT Control Application 529 [I-D.draft-ietf-dime-nat-control] could for example be used for 530 this purpose. 532 5. The Gateway allocates a unique CID and associates those flows 533 received from the access tunnel that need to be tunneled towards 534 the AFTR with the softwire linking Gateway and AFTR. Local 535 forwarding policy on the Gateway determines which traffic will 536 need to be tunneled towards the AFTR. 538 6. Gateway and AD complete the access tunnel establishment 539 (depending on the procedures and mechanisms of the corresponding 540 access network architecture this step can include the assignment 541 of an IPv4 address to the AD). 543 A.2. GI-DS-lite applicability: Examples 545 The section outlines deployment examples of the generic GI-DS-lite 546 architecture described in Section 3. 548 o Mobile IP based access architectures: In a DSMIPv6 [RFC5555] based 549 network scenario, the Mobile IPv6 home agent will implement the 550 GI-DS-lite Gateway function along with the dual-stack Mobile IPv6 551 functionality. 553 o Proxy Mobile IPv6 based access architectures: In a PMIPv6 554 [RFC5213] scenario the local mobility anchor (LMA) will implement 555 the GI-DS-lite Gateway function along with the PMIPv6 IPv4 support 556 [RFC5844] functionality. 558 o GTP based access architectures: 3GPP TS 23.401 [TS23401] and 3GPP 559 TS 23.060 [TS23060] define mobile access architectures using GTP. 560 For GI-DS-lite, the PDN-Gateway/GGSN will also assume the Gateway 561 function. 563 o Fixed WiMAX architecture: If GI-DS-lite is applied to fixed WiMAX, 564 the ASN-Gateway will implement the GI-DS-lite Gateway function. 566 o Mobile WiMAX: If GI-DS-lite is applied to mobile WiMAX, the home 567 agent will implement the Gateway function. 569 o PPP-based broadband access architectures: If GI-DS-lite is applied 570 to PPP-based access architectures the Broadband Remote Access 571 Server (BRAS) or Broadband Network Gateway (BNG) will implement 572 the GI-DS-lite Gateway function. 574 o In broadband access architectures using per-subscriber VLANs the 575 BNG will implement the GI-DS-lite Gateway function. 577 Authors' Addresses 579 Frank Brockners 580 Cisco 581 Hansaallee 249, 3rd Floor 582 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 583 Germany 585 Email: fbrockne@cisco.com 587 Sri Gundavelli 588 Cisco 589 170 West Tasman Drive 590 SAN JOSE, CA 95134 591 USA 593 Email: sgundave@cisco.com 595 Sebastian Speicher 596 Deutsche Telekom AG 597 Landgrabenweg 151 598 BONN, NORDRHEIN-WESTFALEN 53277 599 Germany 601 Email: sebastian.speicher@telekom.de 603 David Ward 604 Cisco 605 170 West Tasman Drive 606 SAN JOSE, CA 95134 607 USA 609 Email: wardd@cisco.com