<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<font size="-1"><font face="Helvetica, Arial, sans-serif">Obviously,
anything that makes me happy must be good!! :-)<br>
<br>
Seriously, the security that IPv6 brings is no different than the
security in IPv4. In both cases its IPSec. The only difference is
that IPSec is "optional to implement" in conformant IPv4 whereas its
"mandatory to implement" in IPv6. You still don't have to use, but ya
gotta haul it around as extra baggage (if you care about being fully
conformant). <br>
<br>
IPv6 address space will be a lot of bytes increase in overhead - 4
bytes vs. 16 bytes for each address. But in the big scheme of things,
especially if explicit authentication is required (e.g. IPSec AH), then
the Message Authentication Code that will be attached to each packet
will also be 12, 16, or 20 bytes (depending on whether the MAC is
truncated to 96 bits as with the IETF HMAC algorithm, straight MD5 is
used, or straight SHA-1 is used). So is it that big a deal??<br>
<br>
And then we can argue back and forth about whether or not the
additional address space is even needed. We can make arguments that
say we don't ever want to give a spacecraft a routable address. The
spacecraft should be on a private net and therefore a 10. or a 192.168.
address would suffice and protect it against external attacks. Even if
we didn't have such concerns, we could also make arguments that NAT'd
addresses would suffice given the small number of addresses needed.
And so on.....<br>
<br>
I remember my own hesitancy back in the 80s when we had to convert from
the ARPAnet's old NCP protocol that worked so well to this "beast"
called TCP/IP with all of its "horribly overhead." It was a pain back
in the PDP-11 days but we did it. I suspect that given the migration of
space qual processors and memories this won't even be a blip in a few
years - just about when missions might think about using it.<br>
<br>
I think I convinced myself that IPv6 is probably the right answer for
something new coming down the line (as much as it pains me to say it!)<br>
<br>
Howie<br>
</font></font><br>
Keith Hogie wrote:
<blockquote cite="mid43FDCEC8.2090007@gsfc.nasa.gov" type="cite">Keith,
<br>
<br>
This is a nice list of issues but in the end I think your last
<br>
sentence below is probably the real issue. Since it takes many
<br>
years (5-10 or more) for new NASA missions to actually get into
<br>
operation going straight to IPv6 makes lots of sense.
<br>
<br>
We can have lots of technical discussions on the trades you
<br>
mentioned but in the end IPv6 has some nicer functionality
<br>
and makes lots of sense for systems 10 years from now. If we
<br>
start designing and deploying IPv4 for space, lots of things
<br>
will get cast in concrete and making changes in 10 years will
<br>
be very difficult. Then 20 years from now NASA will still be
<br>
running IPv4 and Nascom 4800 bit blocks:).
<br>
<br>
I realize that most of us don't see much IPv6 deployment now
<br>
but at an IPv6 presentation a few weeks ago I heard
<br>
the following:
<br>
<br>
1 - The US owns 70% of all IPv4 address space, doesn't leave
<br>
much for the rest of the world.
<br>
<br>
2 - Organizations like Apple, and MIT each have more IPv4
<br>
address space than all of China
<br>
<br>
3 - Hundreds of millions of mobile devices will be needing
<br>
IP addresses in the future and they will end up with IPv6
<br>
<br>
Since IPv6 is coming and NASA doesn't currently have any
<br>
installed IPv4 space architecture, it seems to make sense
<br>
to just start out with IPv6. Otherwise just when we
<br>
finally get IPv4 in place it will be time to replace it.
<br>
<br>
The only real argument against it is a few more bytes
<br>
of overhead. But then those bytes also provide functionality
<br>
and there are compression options that can greatly
<br>
reduce the overhead. Plus we can all make Howie happy
<br>
if we go with IPv6 since security options are required
<br>
as part of IPv6. This adds bytes but adds functionality too.
<br>
Also, when we had 1 Kbps links, overhead was critical but
<br>
as we move to 100 Mbps links overhead issues are not
<br>
as critical since users won't be fully utilizing the link
<br>
anyway.
<br>
<br>
Keith Hogie
<br>
<br>
<br>
<br>
Scott, Keith L. wrote:
<br>
<br>
<blockquote type="cite">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.
<br>
<br>
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.
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Howard Weiss
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, MD 21046
410.872.1515 x201 || 410.872.8079 (fax)
</pre>
</body>
</html>