[Sis-csi] IPv4 and IPv6

[Scott, Keith L.]

Now that we're coming to the end (again) of justifying an end-to-end,
routed, automated, networked architecture, one of the big questions
looming on our horizon will be the choice of network layer.  Taking
just the low-RTT, connected, low-error rate connected
(terrestrial-like) environments, the Internet Protocol seems like it
would certainly deserve consideration.  The choice of IP version 4, IP
version 6, or dual-stack implementations is sure to come up.  What's
below is my first cut at trying to figure out what a trade between v4
and v6 would look like.

I'm perfectly willing to be argued off of any position here (except
possibly my opionions regarding DoD and OMB mandates :)  I'm hoping
this can be a starting point for a discussion and possibly fodder for a
later trade study.  What's NOT here is an evaluation of complexity/cost
of starting with IPv4 on space links and then deciding that we really
*do* have to go with IPv6.

 

Header Sizes and Header Compression

===================================

IPv4 headers are 20 bytes plus options (uncompressed). "VJ" header
compression uses delta encoding that is very sensitive to loss but
which can reduce TCP/IP header sizes to around 2 bytes. If a loss
occurs, it usually causes the loss of one TCP Window of data (can be a
lot if the round trip time and data rates are large).

IPv6 headers are 40 bytes plus any additional v6-related headers
(uncompressed). TCP/IPv6 header compression in RFC2507 is similar to VJ
header compression in RFC1144. Compression of TCP/IPv6 headers should
get down to ~5 bytes (contextID, flags, 2 bytes tcp checksum, probably
at least one seq/ack delta). There are also additional 'profiles' for
dealing with things like RTP/UDP/IPv6 and ESP/IPv6. v6 defines a way
(twice algorithm) to try to be a bit better at dealing with loss, but
IMHO it's not toooo much better. I think one could do uncompressed TCP
headers with compressed IPv6 headers -- an interesting combination that
eliminates the extra address overhad ov IPv6 and maintains robustness
to errors.

----------

Header size goes directly to the 'how much overhead is all this
protocol stuff going to cost me' argument. What the network layer is
buying you is really end-to-end addressability, with some QoS
capabilities. For space networks, I just don't see the need for that
many addresses. I'm also a firm believer in header compression and
think that arguing over the difference between even the uncompressed
header sizes on a 1200- or 1500-byte packet is sort of silly (even 72
bytes for an uncompressed TCP/IPv6 header with TCP timestamps on a
1260-byte packet is still under 6% overhead). Do we really think the
space link is going to be 100% utilized a lot of the time, especially
if it's sized to support very high data rates like video? Maybe. BTW:
all that payload data is compressed too, right?

The issue of how compressed streams handle loss is, I believe, more
important. Losing a whole window's worth of data whenever you have
enough loss to lose synchronization (1 packet in 'vanilla' 1144, a few
if you're using the twice algorithm) could be a real problem, depending
on link loss rates.

 

Network Autoconfiguration

=========================

IPv4 networks can implement Dynamic Host Configuration Protocol (DHCP,
RFC2131) to 'automatically' configure DHCP clients.

IPv6 can do DHCP-like autoconfiguration, and also supports "stateless"
autoconfiguration (RFC2462). Stateless autoconfiguration has the
advantage that you don't have to run DHCP servers/forwarders to reach
all segements of the network that might contain DHCP clients.

-----------

Many people I've spoken with regarding space networking are
uncomfortable with dynamic routing protocols, fearing that they will
foul up and render endpoints unreachable. Given this and the general
desire to not just be able to but to actually manually manage every bit
of configuration, it seems that allowing routers to autoconfigure their
interface addresses won't fly. I would argue for DHCP support for some
small elements, like if you wanted to have wireless networks on shuttle
and station, I'd like laptops that could move between them to be DHCP
clients, e.g. I suspect that running a server that uses IPv6 stateless
autoconfiguration would require dynamic DNS (or some other service
location device), another piece of not-necessarily-fully-controlled
infrastructure that could break.

 

Mobility

========

IPv4: IP Mobility (RFC2131) defines mechanisms for single nodes to
attach at different points to "the Internet". The Network Mobility
(nemo) working group has defined IETF standards to effect mobile
networks (RFC3963, the IETF follow-on to Cisco's Mobile Router work).
For large mobile networks containing lots of end systems, basic
mobileIP involves a lot of state in both home and foreign agents. The
Cisco mobile router support required (I think) two extra encapsulating
tunnels; nemo may require only one, I'm not sure.

IPv6: It is often claimed that IPv6 has "advanced mobility support." I
would push back on this a bit; the IPv6 spec (RFC2460) doesn't say
anything at all about mobility support. Support for mobility in IPv6 is
defined in RFC3775. The base IPv6 protocol does have the ability to do
route optimization that removes the 'dog-leg' of standard IP
Mobility-style routing, using a capability very similar to loose source
routing in IPv4. I suspect that MobileIP for v4 chose to use
encapsulation rather than loose source routing is because many public
routers (larger ISPs) won't forward loose source rotued packets because
they're a security risk. I need to figure out if there's some reason
for thinking that this isn't an issue with IPv6. IPv6 mobility requires
that the mobile node and home agents IPSEC.

---------------

The inefficiencies of dog-leg routing would be extremely cumbersome if
a packet ever had to be routed from space back to a home agent on Earth
just to be forwarded back across the space link (think two rovers on
the Moon that want to communicate with each other and whose home agents
are in different control centers on Earth). If the dog-leg is entirely
within the ground segment, its inefficiency may be completely swamped
by the rest of the network (ground is fiber, space is lower rate RF,
ground RTTs are 10s of ms, space RTTs are 100s of ms or seconds).

There are ways around dog-leg routing, such as to run a MANET-like
routing protocol in those areas that might have mobile stuff. Note that
'MANET-like' could be quite optimized for space applications wrt
terrestrial MANET thinking that usually includes LOTS of broadcasting
looking for neighbors; the 'space MANET' might be much more oriented
towards propagaging routing information that is largely dictated by
things like antenna pointing.

For very simple cases, configured IP-in-IP tunnels from the 'home
networks' of things in space to the appropriate ground stations might
also work.

 

Network Mobility (nemo, RFC3969)

================================

Nemo handles mobile NETWORKS (like spacecraft), where the "head end"
router for the S/C could handle the mobility aspects and leave the
individual endpoints to do 'standard' IP. All traffic between the nodes
on the Mobile Network and Correspondent Nodes passes through the Home
Agent. This sort of argues against using nemo on board two separate
spacecraft that might want to communicate with each other in LEO, e.g.,
since that would incur about 1 second latency (4 one-way TDRSS hops).

 

Security

========

IPv4, IPv6: IP Security (IPSEC, RFC2402, RFC2406) define standard,
algorithm-independent security mechanisms at the network layer for
authentication and confidentiality. The same headers are used in IPv4
and IPv6.

-----------

Not really a win here for either, except that support for 2402 and 2406
is mandatory in the IPv6 specification. Note that there is an issue
relating security and round trip time if internet key exchange (IKE) is
used. This (and the strong desire for manual configuration) argues for
pre-placed keys.

 

Path MTU Discovery and Fragmentation

====================================

IPv4: In IPv4 path MTU discovery depends on passage of ICMP messages
that are black-holed by many firewalls. Senders are still free to send
large IP packets which then have to be fragmented inside the network.
This is a problem due to: increased overhead (more headers per data
byte), increased sensitivity to loss (loss of a fragment requires all
of the data to be retransmitted, if it's TCP), and complexity (routers
in the middle of the network need to be able to fragment packets, end
systems need to be able to reassemble them).

IPv6: Fragmentation happens at the source only; there is no in-network
fragmentation. IPv6 senders who want to take advantage of path MTUs
greater than the IPv6-defined minimum (1280 bytes) need to do path MTU
discovery (RFC1982). PMTU discovery in IPv6 also relies on ICMP
messages, which may get black-holed by routers.

------------

The arguments against being able to do PMTU discovery above are invalid
if one knows that the network(s) in question pass ICMP. This would be
the case if one controlled the network, e.g. For wholly-owned networks
where the end systems can be configured to just KNOW the MTU of "the
network" the end system MTUs can be set accordingly. All this goes out
the window if one attempts to connect the space network to an
uncontrolled ground network (e.g. to flow packets out of the space
segment over the Internet).

 

Multicast and Anycast

=====================

IPv6 multicast has a 'scope' field that might be useful, especially for
service discovery (one thing for which they're used now).

Explicit IPv6 anycast support could be useful -- haven't thought about
it much. 

 

IPv4 - IPv6 Interoperability

============================

It is possible to tunnel IPv4 over and IPv6 network as well as the
other way around. There are also gateways to bridge v4 and v6 networks.

 

Application Support

===================

IPv6 does require some application support; the App/TCP/IP layers are
not quite as decoupled as most layer stack diagrams present. For any
new applciations (spacecraft command and control, e.g.) this isn't an
issue; it _could_ be an issue for legacy applications, but given that
most things are moving to support IPv6 and that there's not a big
infrastructure of legacy applications, this isn't likely to be a
problem. The thing that WOULD be a requirement here would be that if
IPv4 is chosen for the space segment, new applications really SHOULD be
written to be v4/v6 campatible (i.e., let's not build a big
infrastructure of v4-only programs!).

 

Mandates to use IPv6 (DoD and OMB)

==================================

My OPINION of the DoD and particularly the OMB mandates is that they
got a bit over-excited. DoD is now backing away from its 2008
transition date to IPv6, and I think OMB just looked at DoD and the
other agencies and said "Hey, DoD has this wonderful transition plan,
you other agencies should do it too!"

Regardless of what I may think, a mandate is a mandate and presumably
has to be obeyed or waived. I don't think OMB intended to saddle space
networking with a technology (IPv6) that *might not* be appropriate for
it. If the end decision of NASA (and possibly the international
community) is that IPv4 is the way to go, I would expect a waiver would
be granted. IPv6 could well be the agency's "Corporate Network" with
gateways connecting it (and/or the open Internet) to the space network.

 

--keith

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/sis-csi/attachments/20060208/08894e51/attachment-0001.html