IPv6 Transition Technology

Transcription

1 Transition Technology HUAWEI TECHNOLOGIES CO., LTD.

2 Address exhaustion has occurred The address exhaustion has arrived. 4.3 billion addresses are not enough to address the humans and their gears and applications that keep on growing, such as Internet of Things, mobile communications, etc. Moving to is a MUST and imminent. Daily report is recorded at: IANA Unallocated Address Pool Exhaustion: 03-Feb-2011 RIR Unallocated Address Pool Exhaustion is happening: RIR Projected Exhaustion Date Remaining Addresses in RIR Pool (/8s) APNIC: 19-Apr-2011 (actual) RIPE NCC: 14-Sep-2012 (actual) LACNIC: 08-Sep ARIN: 21-Jan AFRINIC: 20-Nov *This report was generated on 05/15/2014 Page 2

3 IP Transitional Technologies Internet Internet Core Dual Stack Core Dual Stack Core Core Core Core NAT Access 6rd BR v6 over v4 6rd LNS Access Core + Access PE AFTR v4 over v6 CGN DS-Lite/464XLAT/NAT64 Access v4 over v6 MAP-E/MAP-T/4rd PE Access NAT Subscriber Subscriber Subscriber Subscriber Subscriber Carrier Grade NAT CE Rapid Deployment CE Dual Stack + CE -Only Access CE -Only Access

4 A Quick Glance at Transitional Technologies Technology NAT444 What are they and what they can/cannot offer? draft-ietf-behave-lsn-requirements-05 draft-shirasaki-nat444-isp-shared-addr-07 Level-2 NAT44 6rd DS-Lite Relieve address pressure No change in home network and CPE Not provide connectivity draft-miles-behave-l2nat-00 Relieve address pressure No change in home network and CPE Not provide connectivity RFC5569 RFC5969 Dual-stack at home CPE requires upgrade RFC6333 RFC6334 Limitation of private space Applications impacts double NAT44 Limitation of private space No additional applications impacts Single level NAT44 No saving on address space NAT64 Dual-stack at home CPE requires upgrade RFC 6146 (NAT64) RFC6147 (DNS64) RFC 6384 (FTP64) For ipv6 subscribers Access network only. Single level NAT44 for address saving Dual-stack 6PE/6vPE host accesses server CPE requires upgrade ( only) Home/Access only Connection initiated from only RFC4213 In the core, aggregation and access network, and run in SIN mode. Support both traffic in native mode No upgrade on equipment No saving on address space Some overhead on operation & management 6PE - RFC4798 6vPE - RFC4659 Core is -MPLS with traffic tunneled through Support both traffic through core No upgrade on equipment Keep -MPLS core as is No saving on address space Page 4

5 Migration Challenges for Mobile User Plane with E-UTRAN UE Um Uu LTE-Uu GERAN UTRAN E-UTRAN Iu Gb S1-U Gxa GPRS CN S12 EPC Swn Gi SGi Translation and / or Tunneling Packet Backbone Applications Applications Application IP PDCP RLC MAC L1 LTE - Uu PDCP RLC MAC L1 Relay GTP - U UDP/IP L2 L1 S1 - U GTP - U UDP/IP L2 L1 Relay GTP - U UDP/IP L2 L1 S5/S8 IP GTP - U UDP/IP L2 L1 SGi Trusted Non-3GPP access Un-trusted Non-3GPP access UE enodeb Serving GW PDN GW The first real User Plane IP-Aware node is PGW/GGSN at Application: Getting to the User Plane includes subscriber management, billing, AAA, DNS, DPI, NAT64 and Firewall etc. It is the emphasis. at Transport: since the User Plane is always tunneled ( GTP is the dominant tunneling protocol ), upgrading mobile transport network and RAN to is typically not business critical at all other interfaces: 3GPP signaling protocol information elements (HLR/HSS, SGSN/GGSN, SGW/PGW, Billing Server, etc) need -Awareness, even when run over Page 5

6 Scenario 1 : -only UE with NAT44 address depletion App/services Legacy UE1 Private Address SGSN GGSN/ PDN-GW Private NAT44 Public Legacy UE2 Most of mobile operators have deployed NAT44 in their network, the address sharing ratio in mobile network is anywhere between 1:100 to 1:300. The public address consumption is not very high To deal with the scalability limitation of RFC 1918 address space (16M), operators have option of reusing RFC1918 address space in non-overlapping regions of network (different GGSNs) or Tunnel Aware NAT. Well-known problems of this approach: Source traceability Real time based CGN logging with large amount of data Page 6

7 Scenario 2 : -only UE (Layer-2 Aware NAT) address depletion App/services Same Private Address Legacy UE2 Legacy UE1 Legacy UE3 SGSN NAT44 GGSN/ PDN-GW With Layer-2 aware CGN Public TEID Private Inside Port Public Outside Port Protocol 0x TCP 0x TCP 0x TCP A single address can be shared by multiple UEs. Layer-2 aware NAT44 will use TEID (Tunnel Endpoint Identifier) for NAT entry map and downstream forwarding. Simplify address management on UE Further reduce address space pressure Page 7

8 Scenario 3 : -only UE with NAT64 App/services App/services Legacy UE1 Address SGSN GGSN / PDN-GW DNS64 NAT64 Public Legacy UE2 address depletion UE is -only. GGSN/PDN-GW interface with -only network. For based application, traffic is routed and forwarded in native mode. UE is allowed to access based server in public network. NAT64 is deployed to perform mapping between and packets where a single address is shared by multiple UEs similar to the NAT44 operation DNS64 is deployed to provide a synthesizing AAAA record from an A record that contains the IPV6 with a prefix Pref64::/n (n<=64) Page 8

9 Scenario 4 : Dual-Stack UE with GI-DS-Lite App/services App/services Legacy UE1 Private Address Address SGSN GGSN/ PDN-GW NAT44 DS-Lite AFTR Public Legacy UE2 GGSN/PDN-GW interface with -only network. UE is -only or - dual-stack capable. On UE, private address is assigned for the applications. traffic is routed and forwarded in native mode. DS-Lite AFTR is deployed to perform tunnel management and NAT44 Tunnel is initiated by GGSN (seen as an extension of GTP tunnel) address depletion Page 9

10 Scenario 5 : Dual-Stack UE & Core App/services Legacy UE1 Private Address Address SGSN GGSN / PDN-GW - App/services NAT44 Public Legacy UE2 address depletion GGSN/PDN-GW interface with - dual-stack network. UE is -only or - dual-stack capable. On UE, private address is assigned for the applications. traffic is routed and forwarded in native mode. NAT44 is deployed allowing public address sharing. Page 10

11 CGN Service Level Hot Standby Service-level hot-standby between boards and equipments User 1 session information synchronized realtime master slave CGN1 User 2 VRRP group1 VRRP gropu 2 BFD CGN2 P VRRP group binding to interface CGN instance binding to VRRP group Internet v4 VRRP group switch result in correlative CGN instance hot switch MPU LPU SPU/NAT SPU/NAT NAT instance1 NAT instance2 NAT state real-time backup using HRP (Huawei Redundancy Protocol) CGN Hot-standby & Load Balancing (VRRP group) Failure detection: 50ms (BFD for VRRP) MPU LPU TCP1(RUI):instance1 flow/nat table TCP1(RUI):instance2 flow/nat table SPU/NAT RUI(Redundancy User Information) SPU/NAT NAT instance1 NAT instance2 Page 11

12 Pioneer at Deployment transition is high priority project at carrier now and for the next few years. HUAWEI has rich deployment experiences and end-to-end solutions to meet operators requirements. BNG, CGN and CPE are key components in end-to-end solution. has been -reachable since June 8th, dual stack network is now in operation in Huawei U.S. R&D center June 8 th June 6 th

13 Layout at Huawei U.S. R&D Center

14 Page 14 Security Level: Thank You HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential