Dual-Stack lite Alain Durand May 28th, 2009 Part I: Dealing with reality A dual-prong strategy IPv4 reality check: completion of allocation is real Today Uncertainty IPv6 reality check: the IPv4 long tail • Post IPv4 allocation completion: ƒ Many hosts in the home (eg Win 95/98/2000/XP, Playstations, consumer electronic devices) are IPv4only. – They will not function in an IPv6-only environment. – Few of those hosts can and will upgrade to IPv6. ƒ Content servers (web, email,…) hosted on the Internet by many different parties will take time to upgrade to support IPv6. Dealing with both realities: a two prong approach ① Embrace IPv6 ƒ Move as many devices/services to IPv6 as possible to lower dependency on IPv4 addresses ② Build an IPv6 transition bridge for the IPv4 long tail ƒ Goal: – Provide IPv4 service without providing a dedicated IPv4 address ƒ Technology: – Leverage IPv6 access infrastructure – Provide only IPv6 addresses to endpoint – Share IPv4 addresses in the access networks – DS-lite: IPv4/IPv6 tunnel + provider NAT Part II: Plan A, B, C, … Lessons learned Provisioning color code IPv4‐only dual stack provisioned dual stack*, IPv6‐only provisioned device link router network * devices with pure IPv6-only code are out of scope Plan zero: dual‐stack After IPv4 IANA completion, there will not be enough IPv4 addresses to sustain this model. IPv6 IPv4 ISP legacy customer global v4 address home gateway NAT v4‐>v4 192.168/16 IPv4&IPv6 home gateway 192.168/16 IPv4&IPv6 home gateway 192.168/16 Today such deployments do not see much IPv6 traffic, mainly because there is little content reachable with IPv6. lots of broken paths… Plan A: dual-stack core new customers are provisioned with IPv6-only but no IPv4 support IPv4 ISP legacy customer global v4 address home gateway NAT v4‐>v4 IPv6 provisioned home gateway 192.168/16 IPv6 provisioned home gateway 192.168/16 192.168/16 impact on new customers: ‐ legacy IPv4 devices can’t get out of the home. ‐ new IPv6 devices can’t get to the IPv4 Internet. ‐ two layers of NAT ‐ no evolution to IPv6 ‐ network gets increasingly complex to operate. ‐ Intersections of Net 10 overlays are prone to failures. Plan B: double NAT new customers are provisioned with overlays of RFC1918 IPv4 ISP carrier‐grade NAT Net 10 legacy customer global v4 address home gateway NAT v4‐>v4 private v4 address home gateway NAT v4‐>v4 192.168/16 Net 10 private v4 address home gateway NAT v4‐>v4 192.168/16 192.168/16 complex internal routing (source based?) to handle both legacy & RFC1918 customers on the same access router. Plan C: dual‐stack lite ‐ simplifies network operation ‐ provides an upgrade path to IPv6 new customers can be provisioned with IPv6‐only + IPv4 support IPv4 Dual-stack lite provides IPv4 support using an IPv4/IPv6 tunnel to a IPv4/IPv4 NAT. ISP carrier‐grade NAT IPv6 legacy customer IPv4 provisioned home gateway NAT v4‐>v4 v4 IPv6 provisioned home gateway v4 192.168/16 v4 v4/v6 192.168/16 Part III: DS-lite technology Combining two well-known technologies: NAT + Tunneling Gateway‐based scenario: IGD are provisioned with IPv6‐only + IPv4 support for the home PC from a carrier‐grade NAT IPv6 packet IPv6 src: IPv6 address of home gateway (IGD) IPv6 dst: IPv6 address of tunnel concentrator, discovered with DHCPv6 IPv4 src: 192.168.1.3 IPv4 dst: www.nanog.org (198.108.95.21) IPv4 src port: 1001 IPv4 dst port: 80 PC 192.168.1.3 SRC port 1001 IGD Tunnel concentrator IPv4 packet IPv4 src: from the pool of the ISP IPv4 dst: www.nanog.org (198.108.95.21) IPv4 src port: 45673 IPv4 dst port: 80 carrier‐grade NAT NAT binding IN: IPv6 src: IPv6 address of IGD + 192.168.1.3 + port1001 OUT: IPv4 src address: from pool of the ISP + port: 45673 IPv4 End‐node scenario: Dual‐stack capable end‐nodes are provisioned with IPv6‐only + IPv4 support from a carrier‐grade NAT IPv6 packet IPv6 src: IPv6 address of end‐node IPv6 dst: IPv6 address of tunnel concentrator, discovered with DHCPv6 IPv4 src: well known IPv4 address: (IANA defined) IPv4 dst: www.nanog.org (198.108.95.21) IPv4 src port: 1001 IPv4 dst port: 80 Host Tunnel concentrator IPv4 packet IPv4 src: from the pool of the ISP IPv4 dst: www.nanog.org (198.108.95.21) IPv4 src port: 45673 IPv4 dst port: 80 carrier‐grade NAT IPv4 NAT binding IN: IPv6 address of end node + well known IPv4 address of end‐node (IANA defined) + port1001 OUT: IPv4 src address: from pool of the ISP + port: 45673 Part IV: TCP/UDP port consumption Measurements Measurements • Measurement campaign performed on 2008-11-10 • Data collected behind a CMTS with 8000 subscribers • Caveats: ƒ ƒ ƒ ƒ 16 Data was collected on only one point in the network Measurement methodology still needs to be tuned Results need to be compared to other studies “Your mileage may vary” TCP ‘outgoing’ ports statistics on a 8000 subscriber sample TCP ‘incoming’ ports statistics on a 8000 subscriber sample 17 UDP ‘outgoing’ ports statistics on a 8000 subscriber sample UDP ‘incoming’ ports statistics on a 8000 subscriber sample 18 Analysis • Maximum average: 40,000 ports/protocol/direction • It translates into a maximum of 5 ports consumed per user on average in each direction for both TCP & UDP. Total: 20 ports/user on average • This needs to be compared with the hundreds/thousands of ports that can be consumed at peak by a single user browsing a Web 2.0/AJAX site. • One needs to keep this analysis in mind when designing a port distribution mechanism for a carrier-grade NAT. 19 Part V: DS-lite standardization Draft-ietf-softwire-dual-stack-lite-00.txt DS-lite Status • IETF ƒ Latest draft: – draft-ietf-softwire-dual-stack-lite-00.txt ƒ IETF softwire WG has been re-chartered to standardize DS-lite. • Implementations ƒ IGD: Open source code (Open-WRT) for a Linksys home router ƒ CGN: Vendor code, open source project started IPv4 port distribution • Measurements: ƒ Average #ports/customer < 10 (per transport protocol) ƒ Peak #ports/customer > 100? > 1000? > 5000? • Do not dimension for peaks, but for average! ƒ No cookie cutter approach ƒ Large dynamic pool of ports shared by many customers • Customers want to choose their own applications 22 ƒ CGN MUST not interfere with applications, eg avoid ALGs,… ƒ Need to support incoming connections ƒ Small static pool of reserved ports under the control of customers Port forwarding & A+P extensions Dst: 1.2.3.4 Port 3000 ISP portal Dst: 1.2.3.4 Port 3002 Provisioning Port forwarding A+P Address & port control tab User: X CGN External IPv4 address: 1.2.3.4 No NAT 23 Port A+P 3000 x Port forwarding Internal IP Port 3001 x 3002 x 192.168.1.6 3003 x 3004 … x 192.168.1.5 80 5080 NAT to 192.168.1.7 Port 5567 NAT to 192.168.1.6 Port 5080 A+P Home gateway Home gateway PC PC 192.168.1.7 Port 5567 192.168.1.6 Port 5080 Issues with MTU MTU 1500 PC MTU 1460 Home gateway MTU 1500 CGN IPv4 Internet pMTU discovery does NOT work over the tunnel IPv4 fragmentation needs to be avoided 24 Dealing with MTU MTU 1500 PC MTU 1460 Home gateway MTU 1500 CGN IPv4 Internet For TCP: CGN rewrites the TCP MSS in the SYN packet For UDP: HGW & CGN do IPv6 fragmentation/reassembly over the tunnel 25 Part VI: Generic issues with CGN Applies to DS-lite, NAT444, NAT64, IVI,… UPnP • Typical UPnP application will: ƒ Decide to run on port X ƒ Ask IGD to forward port X traffic ƒ If IGD declines, try again with X+1 – After 10 or so attempts, abort • This will NOT work with any IPv4 address sharing mechanism (NAT444, DS-lite, NAT64, IVI, A+P,…) • NAT-PMP has a better semantic: IGD can redirect the application to use an alternate available port • UPnP forum is reported to be addressing this issue 27 Security issues relative to CGN • Port number information is necessary for full identification ƒ Need to log port numbers on the receiving side ƒ Need to log NAT bindings on CGN • CGN needs to enforce per customer limits either on new connection rate or maximum number of sessions • User authentication on service provider CGN may not be necessary, users get authenticated at the IPv6 access layer. A simple ACL on the CGN to limit access to the service provider customers seems to be sufficient. 3rd party CGNs may have different requirements. • HGW & CGN need to enforce that customer IPv4 addresses inside of IPv6 tunnel are indeed RFC1918 addresses 28 Other security issues • The Internet community needs to deal with Web sites that put IPv4 address in penalty box after a number of unsuccessful login attempts. • More generally, the community need to revisit notion that an IPv4 address uniquely identifies a customer. 29 Part VII DS-lite deployment model Horizontal Scaling Scaling issue Service provider with CGN network CGN Access 2X thousand router users Access router X thousand users 31 Access router X thousand users Access router Access router X/2 thousand users X/2 thousand users Horizontal scaling with DS-lite • DHCPv6 option to configure tunnel end-point • Enable sending the traffic to as many CGNs as necessary Service provider network CGN CGN CGN CGN CGN Access 2X thousand router users Access router X thousand users 32 Access router X thousand users Access router Access router X/2 thousand users X/2 thousand users Part VIII DS-lite demo at LACNIC XII Thanks to: Yiu Lee, Carl Williams, Anthony Veiga ISC LACNIC, Roque Gagliano LACNIC/Comcast DS‐lite demo Lacnic v4/v6 Router Lacnic dual-stack wired network 1 IPv6 1 IPv4 address address /56 IPv6 prefix IPv6 static route to /56 IPv6 prefix DHCPv6: - IPv6 address of home GW - /64 DHCPv6 prefix delegation - DNS server IPv6 address - CGN IPv6 address IPv6 router DNS/DHCPv6 server DS‐lite CGN /64 DHCPv6-PD /32 IPv4 addresses for NAT pool Color code IPv6 Dual‐ stack Home GW IPv4 Wifi SSID Lacnicxii‐dslite PC 1 PC 20 /64 IPv6 prefix Lacnic IPv6 network 35