ipv6 and it s future n.
Skip this Video
Download Presentation
IPv6, and it ’s Future

Loading in 2 Seconds...

play fullscreen
1 / 24

IPv6, and it ’s Future - PowerPoint PPT Presentation

  • Uploaded on

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 ”

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'IPv6, and it ’s Future' - lam

Download Now 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

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 3 rd 2011
Allocation of the last five /8s(February 3rd, 2011)


technology incentives
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
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
IPv6 in Nokia Devices

Nokia 5140

Nokia N8

Nokia 9500 Communicator

Nokia 6630

Nokia 5230


Nokia N95



Nokia E73

other mobile device vendors
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.