<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.2802" name=GENERATOR></HEAD>
<BODY>
<DIV>
<P><SPAN class=653384918-08022006><FONT face=Arial size=2>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.</FONT></SPAN></P>
<P><SPAN class=653384918-08022006><FONT face=Arial size=2>I'm perfectly willing
to be argued off of any position here (except possibly my opionions regarding
DoD and OMB mandates :) </FONT></SPAN><SPAN class=653384918-08022006><FONT
face=Arial size=2>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.</FONT></SPAN></P>
<P><FONT face=Arial size=2></FONT> </P>
<P><FONT face=Arial size=2>Header Sizes and Header Compression</FONT></P>
<P><FONT face=Arial size=2>===================================</FONT></P>
<P><FONT face=Arial size=2>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).</FONT></P>
<P><FONT face=Arial size=2>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.</FONT></P>
<P><FONT face=Arial size=2>----------</FONT></P>
<P><FONT face=Arial size=2>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?</FONT></P>
<P><FONT face=Arial size=2>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.</FONT></P>
<P><FONT face=Arial size=2></FONT> </P>
<P><FONT face=Arial size=2>Network Autoconfiguration</FONT></P>
<P><FONT face=Arial size=2>=========================</FONT></P>
<P><FONT face=Arial size=2>IPv4 networks can implement Dynamic Host
Configuration Protocol (DHCP, RFC2131) to 'automatically' configure DHCP
clients.</FONT></P>
<P><FONT face=Arial size=2>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.</FONT></P>
<P><FONT face=Arial size=2>-----------</FONT></P>
<P><FONT face=Arial size=2>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.</FONT></P>
<P><FONT face=Arial size=2></FONT> </P>
<P><FONT face=Arial size=2>Mobility</FONT></P>
<P><FONT face=Arial size=2>========</FONT></P>
<P><FONT face=Arial size=2>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.</FONT></P>
<P><FONT face=Arial size=2>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.</FONT></P>
<P><FONT face=Arial size=2>---------------</FONT></P>
<P><FONT face=Arial size=2>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).</FONT></P>
<P><FONT face=Arial size=2>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.</FONT></P>
<P><FONT face=Arial size=2>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.</FONT></P>
<P><FONT face=Arial size=2></FONT> </P>
<P><FONT face=Arial size=2>Network Mobility (nemo, RFC3969)</FONT></P>
<P><FONT face=Arial size=2>================================</FONT></P>
<P><FONT face=Arial size=2>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).</FONT></P>
<P><FONT face=Arial size=2></FONT> </P>
<P><FONT face=Arial size=2>Security</FONT></P>
<P><FONT face=Arial size=2>========</FONT></P>
<P><FONT face=Arial size=2>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.</FONT></P>
<P><FONT face=Arial size=2>-----------</FONT></P>
<P><FONT face=Arial size=2>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.</FONT></P>
<P><FONT face=Arial size=2></FONT> </P>
<P><FONT face=Arial size=2>Path MTU Discovery and Fragmentation</FONT></P>
<P><FONT face=Arial size=2>====================================</FONT></P>
<P><FONT face=Arial size=2>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).</FONT></P>
<P><FONT face=Arial size=2>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.</FONT></P>
<P><FONT face=Arial size=2>------------</FONT></P>
<P><FONT face=Arial size=2>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).</FONT></P>
<P><FONT face=Arial size=2></FONT> </P>
<P><FONT face=Arial size=2>Multicast and Anycast</FONT></P>
<P><FONT face=Arial size=2>=====================</FONT></P>
<P><FONT face=Arial size=2>IPv6 multicast has a 'scope' field that might be
useful, especially for service discovery (one thing for which they're used
now).</FONT></P>
<P><FONT face=Arial size=2>Explicit IPv6 anycast support could be useful --
haven't thought about it much. </FONT></P>
<P><FONT face=Arial size=2></FONT> </P>
<P><FONT face=Arial size=2>IPv4 - IPv6 Interoperability</FONT></P>
<P><FONT face=Arial size=2>============================</FONT></P>
<P><FONT face=Arial size=2>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.</FONT></P>
<P><FONT face=Arial size=2></FONT> </P>
<P><FONT face=Arial size=2>Application Support</FONT></P>
<P><FONT face=Arial size=2>===================</FONT></P>
<P><FONT face=Arial size=2>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!).</FONT></P>
<P><FONT face=Arial size=2></FONT> </P>
<P><FONT face=Arial size=2>Mandates to use IPv6 (DoD and OMB)</FONT></P>
<P><FONT face=Arial size=2>==================================</FONT></P>
<P><FONT face=Arial size=2>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!"</FONT></P>
<P><FONT face=Arial size=2>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.</FONT></P>
<P><FONT face=Arial size=2></FONT> </P>
<P><FONT face=Arial size=2>--keith</FONT></P></DIV></BODY></HTML>