<!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.&nbsp; Taking just the low-RTT, connected, low-error rate 
connected (terrestrial-like) environments, the Internet Protocol seems like it 
would certainly deserve consideration.&nbsp; The choice of IP version 4, IP 
version 6, or dual-stack implementations is sure to come up.&nbsp; 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 :)&nbsp; </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.&nbsp; 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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</P>
<P><FONT face=Arial size=2>--keith</FONT></P></DIV></BODY></HTML>