IPv6 Optimized Networks and
Support for IPv4 Legacy Applications
Briefer:
Mr. David Green
SRI International
David.Green@sri.com
(732) 532-6715
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.
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
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
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
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.
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
IPv4 Only
Host
IPv4 Native
Router
Dual Stack
Border Router
IPv6 Only
Network
Dual
Stack Net
IPv6 Native
Router
Dual Stack
Host
IPv6 Only
Host
IPv6Connection
IPv4Connection
Mechanism Review: Dual Stack
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
Security
•
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
Scalability
Cost/Complexity
•
•
•
•
•
•
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
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
Interface ID 128-n-m bits
Network ID n + m bits
n bit global prefix
(48 bit)
Global Routing Prefix
Subnet ID
64
bits
FFFF:IPv4 Address
DSTM Server
or DHCPv6 with DSTM enhancement
Dual Stack Host +
DSTM Client Software
IPv6 Only
Net
m bits
(16 bits)
IPv6 Dominant
Global Backbone
IPv6 Only
Router
DSTM
V4
Router
V6
DSTM Tunnel (4 in 6)
IPv4 Only
Net
IPv4 Only
Host
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 DSTM
Tunnel Broker Client Software
Using V4 Net
IPv6 Only
Net
Dual Stack Host with TSP
Tunnel Broker Client Software
Using IPv6 Net
IPv6 Dominant
Backbone
IPv6 Only
Router
V4
V6
DSTM Tunnel (4 in 6)
TSP Tunnel (6 in 4)
DSTM
Tunnel Broker
IPv4 Only
Net
IPv4 Only
Host
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
•
•
Cost/Complexity
Scalability
•
•
•
Since interoperability is at the edge, this
is highly scalable on V6 network
Native IPv6 address prefix allows global
routing scalability
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
•
•
•
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
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 RouterTEP
Dual Stack
Border Router
TEP
IPv4 Only
Network
IPv4 Only
Host
TEP Dual Stack
Border Router
IPv6 Only
Network
IPv6 Native
Router
IPv6 Native
Router
IPv6 Only
Host
Dual Stack
Border Router
TEP
Dual
Stack Net
Dual Stack
Host
Dual Stack
Border Router
IPv4 Only
Network
IPv4 Only
Host
IPv6Connection
IPv4Connection
4 in 6 Tunnel
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
•
•
•
Cost/Complexity
Scalability
•
•
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)
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
•
•
•
•
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
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 Only
Net
IPv6 Dominant
Global Backbone
IPv6 Only
Router
IPv4 Only
Net
Application Gateway
IPv4 Only
Host
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 clientserver gateways/fusion points at operation
centers and these servers can make natural ALG
deployment points
•
•
•
Cost/Complexity
Scalability
•
•
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
Can be excellent as gateway or proxy site can
be firewalled on both v4 and v6 sides
•
•
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
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
Network
IPv4 Only
Router
IPv4 Only
Host
IPv4 Only
Network
IPv6 Only
Router
v6/v4 Stateful
Application
Translator
IPv6 Only
Host
IPv4 Only
Imbedded Device
v6/v4
General
Translator
IPv6Connection
IPv4Connection
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
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
•
•
•
•
•
Cost/Complexity
Scalability
•
•
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
Blocks most IPSEC – BAD!
Single point of failure?
•
•
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
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
Mechanism Review: TRT & SOCKS
Performance
•
Security
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?
Scalability
Cost/Complexity
•
•
•
•
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 …
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
Architecture For IPv6 Dominance
Mechanisms in order of preference:
1.
2.
3.
4.
5.
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)
Application/Host-1 OS
Dual/Dual
DSTM Client
Dual/Dual
DSTM Client
Host 1
Network
Dual Stack or
Service Provider
Backbone
Native IPv6 Only
Tunnel
Native v6 Only
IPv4 only
Or Dual/Dual
IPv6/IPv6
Dual Stack or Native Native IPv6 Only
v6 Only
IPv6/IPv6
Transition Mechanism
IPv4/IPv4
DSTM for V4 thru v6
IPv4 Only
IPv4/IPv4
DSTM Tunnel Broker
IPv4 Only
IPv4/IPv4
4in6 Configured Tunnel
IPv4 Only
IPv4/IPv4
Application Level Gateway
(ALG)
DSTM Tunnel Broker
Tunnel
IPv4/IPv4
Or Dual/Dual
IPv6/IPv6
Application/Host-2 OS
DSTM Gate
DSTM Server
Native IPv6 Only
Dual Stack or
Native v6 Only
Host 2
Network
IPv4 Only
Native IPv6 Only
TEP
Native IPv6 Only
Tunnel
TEP
ALG
Dual Stack or Native Dual Stack or Native
IPv4 Imbedded
v6 Only
v6 Only
Trans Device
Native IPv6 on Dual Native IPv6 Only
IPv4 Only
IPv4/IPv4
Trans
Stack
Stateless (SIIT) translator or
similar general translator
Stateful Proxy Translator
(SOCKS Caching ALG)
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)
IPv4 Only
Network
IPv4 Only
Host
IPv6 Only
Network
Dual Stack
Global Backbone
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
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.