Briefer: Mr. David Green SRI International David.Green@sri (732) 532-6715

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

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/3rd 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: • Dual stacks on the edges • DSTM & DSTM Tunnel Broker • Configured Tunnels • Application Gateways • 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. IPv6 Only Network Dual Stack Host IPv4 Only Host IPv6 Only Host Mechanism Review: Dual Stack • 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!!! Dual Stack Global Backbone IPv4 Only Network Dual Stack Border Router IPv4 Native Router Dual Stack Net IPv6 Native Router IPv6Connection IPv4Connection

8. Mechanism Review: Dual Stack Security Performance • 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 Cost/Complexity Scalability • 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. Interface ID 128-n-m bits Network ID n + m bits n bit global prefix (48 bit) m bits (16 bits) 64 bits Global Routing Prefix Subnet ID FFFF:IPv4 Address IPv6 Only Net 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 DSTM Server or DHCPv6 with DSTM enhancement Dual Stack Host + DSTM Client Software IPv6 Dominant Global Backbone IPv4 Only Net IPv4 Only Host IPv6 Only Router DSTM Router V4 V6 DSTM Tunnel (4 in 6)

10. IPv6 Only Net DSTM + Tunnel Broker 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 Dual Stack Host with DSTM Tunnel Broker Client Software Using V4 Net IPv6 Dominant Backbone IPv4 Only Net IPv4 Only Host DSTM Tunnel Broker IPv6 Only Router V4 V6 DSTM Tunnel (4 in 6) TSP Tunnel (6 in 4)

11. Mechanism Review: DSTM Performance Security • 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 Cost/Complexity 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 • Since interoperability is at the edge, this is highly scalable on V6 network • Native IPv6 address prefix allows global routing scalability

12. IPv4 Only Network IPv4 Only Network IPv6 Only Network IPv4 Only Host Dual Stack Host IPv6 Only Host IPv4 Only Host 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 Dual Stack Global Backbone Dual Stack Border Router Dual Stack Border Router TEP Dual Stack Border Router TEP Dual Stack Border Router Dual Stack Border Router TEP TEP IPv6 Native Router Dual Stack Net IPv6 Native Router IPv6Connection IPv4Connection 4 in 6 Tunnel

13. Mechanism Review: Configured Tunnels Security Performance • 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 Cost/Complexity Scalability • 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 • 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)

14. IPv6 Only Net 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 Dual Stack Host Running V6 only IPv6 Dominant Global Backbone IPv4 Only Net IPv4 Only Host IPv6 Only Router Application Gateway

15. Mechanism Review: Application Gateway Security Performance • 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 Cost/Complexity Scalability • 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 • 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

16. IPv6 Only Network IPv4 Only Host IPv6 Only Host Mechanism Review: Translators • 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 Dual Stack Global Backbone Dual Stacked Router IPv6 Only Router IPv4 Only Router IPv4 Only Imbedded Device v6/v4 Stateful Application Translator v6/v4 General Translator IPv4 Only Network IPv6Connection IPv4Connection

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 Security Performance • 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 • Blocks most IPSEC – BAD! • Single point of failure? Cost/Complexity Scalability • 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 • 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

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 Security Performance • 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 • Blocks most IPSEC – BAD! • Single point of failure? Cost/Complexity Scalability • 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 …

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. Architecture For IPv6 Dominance Current DISR MAndated Mechanisms in order of preference: • Dual Stack OS and applications on all edges where possible • DSTM (With or without Tunnel Broker) • Configured Tunnels • Application Gateways (Use for Client-Server Apps) • Translation (Last resort – Breaks E2E Model and IPSEC) Tunnel Tunnel DSTM Gate DSTM Client DSTM Server DSTM Client Tunnel DSTM Tunnel Broker TEP TEP ALG Trans Trans

23. IPv6 Only Network Dual Stack Global Backbone IPv4 Only Network IPv4 Only Host 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)

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.