IPv6, and it’s FutureHannes Tschofenig

Nokia Siemens Networks

Status

• Standardization on IPv6 began a long time ago (around ‘91/’92).

• Benefit from IPv6 is the larger address space– But: “IPv6 deployment is like the Y2K project - without a predefined

deadline”– Costs and benefits are, however, not aligned equally.– If feature was truly useful then it was made available for IPv6

deployments first (e.g. IPsec)• Lots of technology was developed assuming that IPv6 is

widely deployed (e.g. Mobile IPv6, CGA).• Endless number of talks had been given about the increasing

exhaustion of the IPv4 address space.

Allocation of the last five /8s(February 3rd, 2011)

http://www.nro.net/media-center/video-archive-3-february-2011

Technology & Incentives

• Without doubt it is difficult to change an large installed base even if there are good reasons to do so.

• Examples (outside the IPv6 space): – DNSSEC– Routing Security– Source Address Validation

• What can we learn from these examples? • Where does this leave the “future Internet

initiatives / Clean Slate FIA designs”?

IPv6 Maturity• Standardization Status

– IPv6 as a technology has been mature for a long time– IPv6 basic specs done over ten years ago– Other relative SDOs ready or getting ready– 3GPP has been ready for a long time (since Rel-97)– BroadBand Forum is finishing their specifications

• Products and Implementations– Operating Systems

• Windows Vista, Windows 7, Windows XP supports IPv6 with limitations• Apple Mac OS X, Linux, BSD, Symbian, ...• Mobile phone OSs – see next slides.

– Router support• Juniper, Cisco, Other major router vendors

• Deployment• Usage (i.e. turning it on)

– Main purpose of this IPv6 day

Nokia 5140

Nokia 6630

Nokia 9500 Communicator

Nokia 5230

Nokia N95

Nokia N8

Nokia E732004

2010

2011

IPv6 in Nokia Devices

Other Mobile Device Vendors

• Android– IPv6 on WLAN. No IPv6 on cellular – a radio modem issue.

• Apple iPhone– IPv6 on WLAN. No IPv6 on cellular – a radio modem issue.

• RIM– No IPv6 at all.

• Windows Mobile 7– IPv6 on WLAN. No IPv6 on cellular.

• LGE and Samsung– Provided IPv6 capable LTE devices for VzW’s LTE launch.

• General market message is that early 2012 there will be flood of IPv6 and dual-stack enabled cellular devices.

Deployment: IPv6 Support in Networks

Transit

• IPv6 transit is widely supported by providers• NTT/Verio, AT&T, Verizon, TeliaSonera, Tata, …

Access

•Fixed (DSL/Cable)•Some operators (Comcast, Free.fr, NTT “Hikari”, Softbank, HE, Nebula)

•Mobile•First mobile operators have gone live (e.g. Mobitel Slovenia)

Deployment: IPv6 in End-User Facing Services

Reference: Jari Arkko, IETF #79 IAB Technical Plenary presentation.

• End user service providers have started to introduce support

• Google has extensive IPv6 support (ipv6.google.com)

• Netflix is streaming movies over IPv6 (ipv6.netflix.com)

• Yet, most of the services do not support IPv6

Usage Example: IAB’s Attempt to use an IPv6 enabled Chat Server

• Assumption: – Clients have IPv6 connectivity (e.g. via a tunnel http://www.sixxs.net/) – Server has IPv6 connectivity (including AAAA RR installed)

• The Web is far better prepared for IPv6 than most other protocols. So, we went for the Web. – Also true for internationalization as well …

• Bernard Aboba got a web server running over IPv6 (http://ipv6.internaut.com/~baboba/), serving up example code from Jack Moffit's book Professional XMPP Programming.

• The JavaScript code itself has a dependency on a BOSH connection manager (punjab) that doesn't support IPv6.– Connection manager is needed to bypass the JavaScript same-origin policy.

• punjab depends on the twistd python library, which does not support IPv6.

Summary

• IPv6 got more attention and more progress can be observed.

• Standards work in good shape. • More work needed on the product/implementation

and on the deployment side. • Usage is the biggest problem.• Another problem: “Legacy equipment”– Upgrading devices has always been a problem.– One of the main reason for lack of better Internet

security

The Plan

• Goal: Have IPv6 deployment• Problem: Cannot happen immediately because of the

chicken-and-egg problem. • Dual stack is the main story towards IPv6. – Does not help immediately with address shortage itself. – If users use IPv6 with big service provider then traffic can

stay on IPv6 natively and does not need to use IPv6 (and potentially NAT).

• Various transition tools have been developed to help if for one reason or the other dual stack cannot be used. These are temporary fixes only.

Transition to IPv6

• Two groups can be identified:

• Group #1: Those who have enough addresses for the next two years, operating in a saturated market for instance or can recycle addresses (corporate customers).

• Group #2: Those who are too late and only got a /22 from their RIR – or even nothing. Includes those who are experiencing growth and don’t have enough addresses available for the growth expectations.

Group #1 – Enough IPv4 Addresses• If you think you can cope for the next two years with the number

of addresses you have:• No immediate problems to be expected.• Focus on dual-stack deployment and don’t delay it.• Consider offering a tunnel server just in case you get confronted with

IPv6 only hosts.

• Profile your subscribers and plan transition differently for each type of subscriber group:• Subscriptions that has no human involvement and limited set of

applications and insignificant traffic volumes (e.g. M2M).• Simple users that mostly send short messages and use voice.• Heavy users.. (10% of subscribers generate 90% of the traffic).• Smart phones vs. simpler device users..

Group #2 – Not Enough IPv4 Addresses• If you don’t have enough IPv4 addresses left to cope with your

expected growth.• Smart phones and LTE devices (each LTE device consumes at least

one address when powered on) are going to eat addresses.

• Focus on the two problems:• Maintain IPv4 connectivity with e.g. NAT44.• Find a path towards IPv6 deployment i.e. pick up the transition tool

of choice.. • Plan the transition based on the subscriber profiles (see previous

slide).

• IPv4 connectivity might be your biggest problem for now.

Classification of IPv6 Transition Solutions

Tunneling

Stateless

SP Managed

End Host Impact

Translation

Stateful

Non-SP Managed

Transparent to End Host

Transition Toolbox(Some Solutions Are Outdated, or Deprecated)

Tunneling or alike

• IPv6 in IP configured tunnel• 6RD/4RD• DS-Lite• 6to4• Teredo• ISATAP• A+P• (MOB)IKEv2/IPsec• DSMIPv[46]• TSP• L2TP, GRE

Translation of some form

• NAT64/NAT46 & DNS46/DNS46

• IVI• BIH• ALG – Proxying at application

level (HTTP Transparent Proxy, SIP Proxy)

• NAT-PT• SIIT• TRT

Transition Mechanisms, cont.

• Deployment happening today:– Dual Stack– 6rd (or end-user ISP)

• Relevant for near future: – NAT64– IPv6-only networks with Dual Stack Light (IPv4

traffic tunneled over IPv6 network)

Summary Recommendations

• Dual stack preferred mode of operation for existing deployments.

• Lots of transition tools ... no solution fits all scenarios, requirements and environments.

• Plan for future consumer needs: Do not only think how they used IPv4 past decades!– For example, IPv6-only use in the IoT space

possible.

Carrier Grade NAT

• Idea: – Deploy another layer of NAT or a big NAT (if you

do not yet have one).• Work done in V6OPS:– http://datatracker.ietf.org/wg/v6ops/– Impact also for other groups. For example, DIME

with draft-ietf-dime-nat-control-07

Consequences: Keeping State in Middleboxes

• Applications today already need to deal with NAT traversal anyway.• Keeping multiple connections alive through a NAT is more expensive because

of connectivity tests and ensuring that the state is kept alive.– For connectivity tests ICE may be used. Not complexity free.

• Tutorial: http://www.jdrosen.net/papers/ice-ietf-tutorial.pdf

– Tests have to be repeated every time environment changes (e.g. mobility) for every address pair!

• Would be great to tell NAT how long to keep bindings or to learn other NAT characteristics– Many attempts to standardize protocols to talk with NATs have been

made but none widely deployed.– I had my fun with NSIS (see RFC 5793)– Other’s are now trying the Port Control Protocol (PCP):

http://datatracker.ietf.org/wg/pcp/ • Keeping state alive in the network consumes energy

– http://www.pasieronen.com/publications/haverinen_siren_eronen_vtc2007.pdf

Reducing Number of Connections: Adding another Layer of Multiplexing

• Imagine a VoIP application that has to exchange voice between two end hosts Alice and Bob. – Alice -> Bob: RTP– Bob -> Alice: RTP

• Additionally, there is a control channel for the RTP traffic (in addition to SIP itself):– Alice -> Bob: RTCP – Bob -> Alice: RTCP

• Finally, add DTLS exchange for key establishment for SRTP end-to-end security.

• STUN packets need to mimic these exchanges to test connectivity. • This is lot of packets: “DTLS-SRTP Framework”, RFC 5763

– "Symmetric RTP / RTP Control Protocol (RTCP)”, RFC 4961– "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761– Multiplexing DTLS, SRTP and STUN on the same port, RFC 5764

• SIP is fun but what about a widely deployed protocol? HTTP

HTTP: Reducing the Number of Connections• A typical Web page requires

– a huge number of resources between retrieved (mixed content model),

– multiple HTTP request / responses, and – typically multiple TCP connections.

• Check yourself: http://www.webpagetest.org • More TCP connections are typically used to bypass various

constraints with TCP slow start.• Efforts to change current status:

– SCTP (failed because of inability to get through firewalls and NATS)– SPDY: http://code.google.com/speed/

“Multiplexed streams: SPDY allows for unlimited concurrent streams over a single TCP connection.”http://www.chromium.org/spdy/spdy-whitepaper

Conclusion• We have been working on Plan A for a very long time. – Making progress – although much slower than expected. – Still lots of bugs and interoperability problems.

• There is a Plan B as well. – Not as good as Plan A since it introduces another layer into the

stack. – Recently published http

://tools.ietf.org/html/draft-tschofenig-post-standardization argues that HTTP/HTTPS is the new waist of the hour glass (& more importantly JavaScript changes the way we do standardization).

– Maybe already outdated?• My biggest worry: With Internet of Things we are currently creating

the next generation of legacy devices. – Quite likely that most developers will not care little about IPv6– Most likely no easy way for upgrading the software on these

devices.