Ipv6 and it s future
Sponsored Links
This presentation is the property of its rightful owner.
1 / 24

IPv6, and it ’s Future PowerPoint PPT Presentation

  • Uploaded on
  • Presentation posted in: General

IPv6, and it ’s Future. Hannes 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 ”

Download Presentation

IPv6, and it ’s Future

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

IPv6, and it’s Future

Hannes Tschofenig

Nokia Siemens Networks


  • 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)


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

IPv6 in Nokia Devices

Nokia 5140

Nokia N8

Nokia 9500 Communicator

Nokia 6630

Nokia 5230


Nokia N95



Nokia E73

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

  • IPv6 transit is widely supported by providers

  • NTT/Verio, AT&T, Verizon, TeliaSonera, Tata, …


  • 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

  • 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

Reference: JariArkko, IETF #79 IAB Technical Plenary presentation.

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 Abobagot 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.


  • 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



SP Managed

End Host Impact



Non-SP Managed

Transparent to End Host

Transition Toolbox(Some Solutions Are Outdated, or Deprecated)

Tunneling or alike

Translation of some form

NAT64/NAT46 & DNS46/DNS46



ALG – Proxying at application level (HTTP Transparent Proxy, SIP Proxy)




  • IPv6 in IP configured tunnel

  • 6RD/4RD

  • DS-Lite

  • 6to4

  • Teredo


  • A+P

  • (MOB)IKEv2/IPsec

  • DSMIPv[46]

  • TSP

  • L2TP, GRE

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.”



  • 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.

  • Login