1. Briefer: Mr. David Green SRI International David.Green@sri.com (732) 532-6715 IPv6 Optimized Networks and Support for IPv4 Legacy Applications

2. Problem Statement IPv6 networks that continue to support IPv4 may not achieve many of the netcentric benefits of IPv6 if backwards compatibility limits IPv6 because of poor choices in the deployment of transition mechanisms. If we want the full netcentric benefits of a network optimized for IPv6 network protocols and services, we must run an “IPv6 Dominant” network core and push IPv4 transition mechanisms from the IPv6 network core to the legacy network edge.

3. Presentation Overview V6 Dominant Networks The case for V6-only cores Approaches to backwards compatibility -DSTM -Configured Tunnels -Application Gateways -Translation IPv6 Dominant Architecture Conclusions Q&A

4. V6 Dominant Networks Network has majority of network traffic in IPv6 format Critical mass of applications pushed to IPv6 IPv4 services maintained for backwards compatibility with legacy applications/systems When IPv6 Dominance? (My guesses) -2010 Selected US DoD networks & backbones, Gen3 PCS, new ISPs in Asia/3 rd world -2012 US DoD networks, Major ISPs offering service -2015-2020 Worldwide Dominance, GEN4 PCS Eventually IPv4 services begin to be shut off Maybe eventually (2030?) a “flag day” like 1983 shut off of NCP in favor of TCP/IPv4

5. Optimizing Networks for IPv6 - V6 Only Cores Some networks will want to quit supporting IPv4 before a final Internet “flag day” for the following reasons: -Supporting 2 protocols has an inherently higher O&M cost (25%??) -IPv6 should have a lower O&M due to auto-configuration features -V4 has limited scalability due to security and stateful configuration models -New services like MIPv6 are and NEMO are V6 only – a network application built on this may not be IPv4 compatible at all -V6 is a better protocol for E2E P2P applications -New E2E wireless services may be born v6 only due to the lack of v4 address space If a network turns off IPv4 support in its routers, or is born without IPv4 support in it’s routers, V4 services can still be accessed through transition mechanism at the network edges

6. Approaches to Backwards Compatibility Five mechanisms: 1.Dual stacks on the edges 2.DSTM & DSTM Tunnel Broker 3.Configured Tunnels 4.Application Gateways 5.Translation All mechanisms sit at the edge of a network or as software on a host and act as a gateway to v6 domains.

7. Mechanism Review: Dual Stack Dual Stack Net Dual Stack Host IPv4 Only Network IPv6 Only Network Dual Stack Global Backbone IPv6 Native Router Dual Stack Border Router IPv4 Native Router IPv4 Only Host IPv6 Only Host IPv6Connection IPv4Connection Defined in RFC 2893 “ Transition Mechanisms for IPv6 Hosts and Routers” Every node has two connected stacks (v4 and v6) Applications must be modified to be “dual stack aware” to decide which IP service (v6 preferred!) to use if DNS query may return either v4 or v6. Dual stack routers must run routing protocol capable of handling both v4 & v6 Preferred v4/v6 interoperability solution for network edges – all other mechanisms require a dual stack somewhere!!!

8. Mechanism Review: Dual Stack Performance Security Scalability Cost/Complexity Basic mechanism for v4/v6 interoperability Complete solution for interoperability - if applications are dual-stacked Requires more memory/CPU utilization – trivial in hosts, less trivial in routers Throughput down, delay up as routers must handle two IP address families No known security problems but: -Like any new code, implementations may have security flaws -Must have security on both v4 and v6 stacks – may double security work! -Should protect from flaws in one side of stack compromising the other side DOD routing protocols require both IPv4 and IPv6 (ex OSPFv2,OSPFv3,RIP, RIPNG) Doubles routing overhead if dual stack routing is not integrated (IS-IS is integrated) New IETF proposed extension of OSPFv3 can carry both v4 & v6 like IS-IS routing With a dual stack in place, a network is ready to move to native IPv6 by simply turning off IPv4 half of stack Minimal with normal tech refresh Increase in network O&M costs ~25% while operating both stacks Operational costs expected to drop with pure IPv6 due to autoconfig features Once IPv6 becomes dominant, option to save O&M costs by turning off IPv4 half of stack and add DSTM & ALGs for v4 access

9. DSTM Dual Stack Transition Mechanism (DSTM) defined IETF draft-bound-dstm-exp Allows “dual stack” node on IPv6 only network to talk to an IPv4 only node on an IPv4 only network by tunneling from a dual stacked node to an IPv4 network Uses IPv4-over-IPv6 tunnels to carry IPv4 through IPv6 dominant backbone network to a tunnel endpoint at a DSTM router/translation gateway Can be added to a tunnel broker to automate the process and enforce security policy Global Routing PrefixFFFF:IPv4 AddressSubnet ID Network ID n + m bits 64 bits m bits (16 bits) Interface ID 128-n-m bits n bit global prefix (48 bit) IPv6 Dominant Global Backbone DSTM Router IPv4 Only Net IPv4 Only Host IPv6 Only Router IPv6 Only Net Dual Stack Host + DSTM Client Software DSTM Server or DHCPv6 with DSTM enhancement V4 V6 DSTM Tunnel (4 in 6)

10. DSTM + Tunnel Broker IPv6 Dominant Backbone DSTM Tunnel Broker IPv4 Only Net IPv4 Only Host IPv6 Only Router IPv6 Only Net Dual Stack Host with DSTM Tunnel Broker Client Software Using V4 Net Added Benefit to DSTM+Tunnel Broker: Single box serves dual stacked nodes behind v4-only net and behind v6-only net Dual Stack Host with TSP Tunnel Broker Client Software Using IPv6 Net V4 V6 DSTM Tunnel (4 in 6) TSP Tunnel (6 in 4)

11. Mechanism Review: DSTM Performance Security Scalability Cost/Complexity Tunnel at DSTM host on IPv6 domain allows for high scalability of IPv6-end TEP Interoperability between v4-only & dual stack hosts across IPv6-only backbone Using a tunnel broker, hosts and small sites can set up DSTM and discover tunnel endpoints Pays tunneling overhead of at least 40 bytes per IPv4 packet due to V4 in V6 overhead Good, but tunnel brokered DSTM adds even better security via Authorization, Authentication, Accounting (AAA) to determine who can set up the tunnel Can use native IPv6 IPSEC only up to IPv4 tunnel TEP Like all host tunnels, potential vector for network security compromise, but can be hardened by securing TEP router Since interoperability is at the edge, this is highly scalable on V6 network Native IPv6 address prefix allows global routing scalability Can be offered as an enterprise service with tunnel broker & router in one box Requires client software on hosts, but this can be distributed via DSTM tunnel broker To reduce cost/complexity can use a DHCPv6 server, tunnel broker, or static assigned IPv4 addresses in place of DSTM address server on IPv6 domain Administrators must set up DSTM, then tunnels can be set up and torn down automatically as needed

12. Configured IPv4 in IPv6 Tunnels Tunneling encapsulated IPv4 in IPv6 packets (IPv6 next header ID = = 4) Most modern dual-stacked routers can act as tunnel endpoint (TEP) Hand configured mechanism – useful for static networks Could be incorporated into a tunnel brokering mechanism to automate setup IPv4 Only Network IPv6 Only Network Dual Stack Net Dual Stack Host Dual Stack Global Backbone IPv6 Native Router IPv6 Only Host IPv4 Only Host IPv6Connection IPv4Connection 4 in 6 Tunnel IPv4 Only Host IPv6 Native Router Dual Stack Border Router Dual Stack Border Router Dual Stack Border Router Dual Stack Border Router Dual Stack Border Router TEP

13. Mechanism Review: Configured Tunnels Performance Security Scalability Cost/Complexity No IPv4 / V6 Interoperability – just passing IPv4 through IPv6 Double IP header overhead – about 18% overhead with ave. 300 byte datagrams Static - Not usable in mobile networks!!! No auto-reconfiguration – only manual No known security problems Extremely safe as v6 and v4 traffic and networks can be completely segregated Can be highly secure as v4 and v6 networks can be separated and tunnel data protected by tunnel IPSEC Administrators must set up each tunnel endpoint manually and this makes the labor requirements difficult to scale to large numbers of tunnels Does not add any routing protocol overhead in IPv6 network (static routing) Cheap in router hardware – tunneling available in even low-end routers Labor intensive to set up Labor intensive to re-establish In order to reconfigure networks, administrator must re-enter all tunnels TEPs if network topology or addressing changes Can add a tunnel broker to automate part of tunnel setup and maintenance

14. Application Gateway A dual stacked application server that sits on a dual-stacked network and runs as a gateway system between v4 & v6 networks Ideal for client-server architectures where clients exchange information without P2P connections (Examples: E-mail, Weblogs) A legacy v4 client program can connect to the dual-stacked server and send/receive data, a v6 client program on an IPv6-only network can connect to the same server Where proxy servers exist in an architecture, they can be dual stacked and turned into an ALG. (Example: SOCKS HTTP caching proxy) Application gateways are application specific, not general translators IPv6 Dominant Global Backbone IPv4 Only Net IPv4 Only Host IPv6 Only Router IPv6 Only Net Dual Stack Host Running V6 only Application Gateway

15. Mechanism Review: Application Gateway Performance Security Scalability Cost/Complexity Depends heavily on design: Proxy may be a performance bottleneck, simple application server like e-mail can handle high performance Proxy as an core enterprise service often requires great memory and processor resources – deploy on network edge Often DoD tactical applications have client- server gateways/fusion points at operation centers and these servers can make natural ALG deployment points Can be excellent as gateway or proxy site can be firewalled on both v4 and v6 sides If proxy interoperability is at the network edges, this is highly scalable on V6 network Separate application gateway needed for each possible application – fine for a simple network like DoD lower TI with limited ABCS systems, bad for complex Internets with many P2P applications High cost of complex application gateways was one of the drivers of moving from the NCP model to E2E IPv4 in 1980s. Avoid using this mechanism as the general solution for all interoperability Cost can be cheap for simple dual stacked networked servers, especially applications that already employ gateways between domains or between units

16. Mechanism Review: Translators IPv4 Only Network Dual Stack Global Backbone IPv4 Only Host IPv4 Only Router Many Mechanisms: SIIT, NAT-PT, BIA, BIS (Stateless) TRT, Socks (Stateful) Strip IPv4 header off datagram and replace with IPv6 header (and vice-versa) Need translators modified for IPv6 native routing prefix for IPv6 dominant networks Translation breaks E2E model and will break IPv6 E2E IPSEC Best reserved for adding IPv6 capability to imbedded devices that cannot use ANY other transition mechanism. Ex: Legacy webcams, sensors, printers, storage arrays IPv6 Only Network IPv6 Only Host IPv6 Only Router IPv6Connection IPv4Connection v6/v4 General Translator IPv4 Only Imbedded Device v6/v4 Stateful Application Translator Dual Stacked Router

17. Mechanism Review: SIIT/NAT-PT/BIA/BIS Stateless IP/ICMP Translation Algorithm (SIIT) [RFC 2765] is the basis for many translators like NAT-PT, BIA, BIS SIIT strips IPv6 header and replaces with IPv4 header (& vice-versa) Uses “non-native6” IPv4-translated addresses to refer to IPv6-enabled nodes 0:0:ffff:0:0:0/96 + 32-bit IPv4 address Uses “non-native6” IPv4-mapped addresses to refer to IPv4-only nodes 0:0:0:0:0:ffff/96 + 32-bit IPv4 address ALGs (Application-Level Gateways) required to translate embedded IP addresses, re-compute checksums, etc.. Not accomplished by simple translation Breaks true “end-to-end” model and introduces a single point of failure NAT-PT [RFC 2766] like common NAT, but uses SIIT to translate between v4&v6 NAT inhibits the ability to deploy security at the IP layer Bump in the API (BIA), and Bump in the Stack (BIS) are local host-level implementations of NAT-PT SIIT address prefix is not native IPv6 Breaks true “end-to-end” model and introduces a single point of failure Not “popular” with many IPv6 engineers who want end-to-end model

18. Mechanism Review: SIIT/NAT-PT/BIA/BIS Performance Security Scalability Cost/Complexity Addressing not currently compatible with native IPv6 global addressing so local Ipv6 domain use only Specialty service Single point of failure? Interoperability of last resort Non-native IPv6 addressing severely limits reachability - service must be located on local IPv6 domain and rely on IPv4 for global reach Multiple IPv6 sources can share a single IPv4 address – good for scaling Fairly cheap translators ($1K – $8K) but support local domain only... If address generation is changed to globally reachable address scheme could be an Enterprise service Blocks most IPSEC – BAD! Single point of failure?

19. Mechanism Review: TRT & SOCKS Transport Relay Translator (TRT) uses a similar infrastructure and concept to SIIT but is “Stateful” unlike SIIT Support bidirectional socket traffic only Translates specific transport sockets – specialized service IPv6 host establishes connection to IPv4 host service via local TRT gateway Single point of failure at gateway unless some redundancy can be built in… Gateway performance may not scale well as stateful processing is more intensive Cannot use IPv6 IPSEC in current forms Use as a service on a local IPv6 domain SOCKS is a transport relay translator in “informational” RFC 3089 A form of application proxy – similar to application gateway concept! Proprietary NEC SOCKSv5 protocol for special proxy use only Relies on SOCKS clients and servers Single point of failure at gateway Gateway performance may not scale well as stateful processing can be intensive Socks commonly used for HTTP proxy in web-browsers Use as a service on a local IPv6 domain

20. Mechanism Review: TRT & SOCKS Performance Security Scalability Cost/Complexity TRT addressing not currently compatible with native IPv6 global addressing so local use only Stateful processing may limit speed Single point of failure? SOCKS – specialty service? Interoperability of last resort Non-native IPv6 addressing severely limits reachability - service must be located on local IPv6 domain and rely on IPv4 backbone for global reach Local or specialty services only Stateful processing may limit scaling Fairly cheap translators ($1K – $8K) but support local domain only... If address generation is changed to globally reachable IPv6 address scheme could be an Enterprise service … Blocks most IPSEC – BAD! Single point of failure?

21. New Directions in Translation Translation is not a good general solution – IETF is downgrading NAT-PT to experimental for this reason Translation is currently deployed at the network core/enterprise level (NAT-PT) but instead should be pushed out of to the legacy network edge Translation at the edge can be highly customized to fit the specific IPv4 application/device needing translation Think of this translation as a way to achieve a “Dual Stack” capability using: -“Bump in the Wire” box for imbedded devices -“Bump in the API” for V4-only applications that are no longer code-maintained Ref: Fiuczynski, Green, Jankiewicz “IPv6 Translation For IPv4 Imbedded Systems”to be presented at AFCEA/IEEE MILCOM 2005

22. Current DISR MAndated Architecture For IPv6 Dominance Application/Host-1 OSHost 1 Network Service Provider Backbone Host 2 Network Application/Host-2 OSTransition Mechanism Dual/Dual Dual Stack or Native v6 Only Native IPv6 OnlyIPv4 OnlyIPv4/IPv4DSTM for V4 thru v6 Dual/DualDual Stack or Native v6 Only Native IPv6 OnlyIPv4 OnlyIPv4/IPv4DSTM Tunnel Broker IPv4/IPv4 Or Dual/Dual IPv4 only Or Dual/Dual Native IPv6 OnlyIPv4 OnlyIPv4/IPv44in6 Configured Tunnel IPv6/IPv6Dual Stack or Native v6 Only Native IPv6 OnlyIPv4 OnlyIPv4/IPv4Application Level Gateway (ALG) IPv6/IPv6Native IPv6 OnlyDual Stack or Native v6 Only IPv4 Imbedded Device Stateless (SIIT) translator or similar general translator IPv6/IPv6Native IPv6 on Dual Stack Native IPv6 OnlyIPv4 OnlyIPv4/IPv4Stateful Proxy Translator (SOCKS Caching ALG) Mechanisms in order of preference: 1.Dual Stack OS and applications on all edges where possible 2.DSTM (With or without Tunnel Broker) 3.Configured Tunnels 4.Application Gateways (Use for Client-Server Apps) 5.Translation (Last resort – Breaks E2E Model and IPSEC) DSTM Gate ALG Trans TEP Trans DSTM Server DSTM Tunnel Broker DSTM Client Tunnel

23. What is missing? IPv6 only backbones – How to support IPv4-only sites? -Dual-stacked end-hosts on an IPv6 dominant network can use DSTM for automatic tunneling -What about IPv4-only networks that connect? Do not want to fragment Internet or cause un-reachability problems for legacy networks that might need to be supported through an IPv6-only backbone What type of transition mechanisms would be suitable -Automated Tunneling (BGP tunnels?) for IPv4-in-IPv6 -GRE Manual tunnels (Static configuration) IPv6 Only Network Dual Stack Global Backbone IPv4 Only Network IPv4 Only Host

24. Conclusions Without optimizing networks for IPv6 we lose many of IPv6’s benefits IPv6-only core networks can still service traffic from dual stacked hosts through the use of transition mechanisms New ISPs in developing nations and emerging GEN3/4 PCS wireless may be born IPv6-only due to address shortage New advanced mobile networks, being deployed by defense and emergency services enterprises, are ideal for IPv6-dominant designs High IPv4 operations and maintenance (O&M) cost may be a large factor in pushing to IPv6 dominance & IPv6 only networks At some point in the future after IPv6 dominance pervades, IPv6-only networks may be created where there is only an IPv6 stack (2020?) Some transition mechanisms for IPv6 dominant networks are at a lower state of maturity than current mechanisms for v4 dominant networks, but a focused engineering effort can quickly prepare them for deployment

25. Acknowledgements: The author wishes to thank Jim Bound and SMEs from the NAv6TF for help in developing technical concepts for IPv6 dominant networks. This author wishes to thank the government members of the US Army CERDEC S&TCD IPv6 transition team: Larry Levine, Kwai Chan, and Ranga Reddy for their support of transition mechanism studies, experimental network design, and modeling and simulation work necessary to fully develop IPv6 dominant networks architectures and concepts. Much of the work to develop these concepts was funded through the Army CIO/G6 IPv6 transition program. This author wishes to thank Ralph Liquori of the DISA IPv6 Standards WG in the DISA Interoperability Standards Division for supporting the standards work that lead to much of the transition mechanism deployment guidance in this paper. The techniques developed in this paper will be documented in IETF IPv6 transition guidance in support of DISA’s IPv6 standards work in support of the DoD IPv6 Transition.