1 / 24

IPv6, and it ’s Future

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 ”

lam
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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IPv6, and it’s Future Hannes Tschofenig Nokia Siemens Networks

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

  3. Allocation of the last five /8s(February 3rd, 2011) http://www.nro.net/media-center/video-archive-3-february-2011

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

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

  6. IPv6 in Nokia Devices Nokia 5140 Nokia N8 Nokia 9500 Communicator Nokia 6630 Nokia 5230 2004 Nokia N95 2010 2011 Nokia E73

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

  8. Deployment: IPv6 Support in Networks • IPv6 transit is widely supported by providers • NTT/Verio, AT&T, Verizon, TeliaSonera, Tata, … Transit • Fixed (DSL/Cable) • Some operators (Comcast, Free.fr, NTT “Hikari”, Softbank, HE, Nebula) • Mobile • First mobile operators have gone live(e.g. Mobitel Slovenia) Access

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

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

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

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

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

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

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

  16. Classification of IPv6 Transition Solutions Tunneling Stateless SP Managed End Host Impact Translation Stateful Non-SP Managed Transparent to End Host

  17. Transition Toolbox(Some Solutions Are Outdated, or Deprecated) Tunneling or alike Translation of some form NAT64/NAT46 & DNS46/DNS46 IVI BIH ALG – Proxying at application level (HTTP Transparent Proxy, SIP Proxy) NAT-PT SIIT TRT • IPv6 in IP configured tunnel • 6RD/4RD • DS-Lite • 6to4 • Teredo • ISATAP • A+P • (MOB)IKEv2/IPsec • DSMIPv[46] • TSP • L2TP, GRE

  18. 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)

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

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

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

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

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

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

More Related