Subject: [nemo] NAT/PAT transfersal over IPv4 networks

From: ivancic <[email-masked]>
Date: Tue, 03 Aug 2004 18:21:37 -0400

Thierry and/or TJ asked if there was additional work that NEMO should 
address prior to closing or rechartering.

I strongly believe that the group should standardize on a NAT/PAT 
transversal over IPv4 backbones.   This will greatly increase the 
ability to deploy NEMO IPv6 networks.  The US DoD, Japan, Korea, the 
European Nations and just about any Industrial nations is trying to help 
kick-start IPv6 deployments.  However, the ISP's and industry do not yet 
have a good business case.  Making the transission easier will help ALL 
of IPv6 deployments.   I used some of Pascal's IPv6  NEMO code with the 
"Doors" protocol and demonstrated this to the CIO of the US DoD.  The 
ability to run IPv6 over IPv4 and mix networks was very very important.

See:
http://roland.grc.nasa.gov/~ivancic/ICNS2004_Demo/ICNS2004_Demo.htm
Note, the "off-site demonstrations in Washington D.C. area" was for the 
Office of Secretary of Defense in order to show a migration path from 
IPv4 to IPv6.

Will

-- 
******************************
William D. Ivancic
Phone 216-433-3494
Fax  216-433-8705
Lab  216-433-2620
Mobile  440-503-4892
http://roland.grc.nas.gov/~ivancic

---

From: Thierry Ernst <[email-masked]>
Date: Wed, 4 Aug 2004 08:40:49 +0900

Hi Will,

Actually, the draft-iett-nemo-requirements mention NAT traversal and
IPv4-IPv6 transitin, so that is something we do care about. This said,
we concluded last year that there wasn't NEMO-specific issues. If there
is one, I think the WG should defintely address it. If these are issues
not specific to NEMO, we need to make sure these issues are addressed by
the relefvant WG.

In any case, I agree with your statement.

Thierry.

On Tue, 03 Aug 2004 18:21:37 -0400

---

From: ivancic <[email-masked]>
Date: Wed, 04 Aug 2004 14:27:39 -0400

Thierry Ernst wrote:

>we concluded last year that there wasn't NEMO-specific issues. 
>

Thierry,

I agree that NAT traversal and IPv4-IPv6 transition are not NEMO
specific.  Many protocols will have this problem.  However, to
"seamlessly" utilize a NEMO, the problem probably has to be solved in
the mobile router.   For example, in MIP4, they developed a NAT
transversal specification basically saying use a  IP-in-UDP tunnel 
rather than an IP-in-IP tunnel because you need a port number for the 
NAT to understand the translation.  This is performed in the mobile host 
or mobile router for Collocated Care of Address.

Note, I used the "Doors" implementation, but would expect that other
methods may work just as well  and get around the IPR problem.  I really
beleive this should be solved here and may be applicable to MIP6 also.
Until IPv6 is supported by the ISPs, we will need to do the 6-to-4
tunneling and until NATs misterioulsy disappear we will need to do NAT
transversal.

(Actually, when we used T-Mobile's links, we originally had a non-NATted
pubilic address.  However, they administratively filtered to stop
Internet Worms.  Thus, only traffic originating from T-Mobile could
return (basically acting like a NAT).  Thus, the NAT solution worked  as
you needed a port number on the tunnel for the ISP to map bidirectional
transferes.  Otherwise, the ipv4 NEMO would register using UDP port 434,
but the tunneled data would not pass!)

I reviewed the draft
www.ietf.org/internet-drafts/draft-ietf-v6ops-assisted-tunneling-requirements-00.txt
as suggested by Tim Chown (thanks for the reference). This may (???) 
work.  However there are some assumptions and issues.

1)  Code must be deployed in a NEMO to utilize the assisted-tunneling. 
This code is potentailly more complex than developing our own 
Tunneling/NAT Transversal implementation.

2)  Assisted-Tunnelling must be deployed by all ISP's one wishes to use. 
  (Personal experinece has shown that one will wish to use any ISP they 
can get.)

3)  The assisted-tunnelling draft is just that, a draft.  When and if it 
will get deployed are unknows.

Will

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 5 Aug 2004 08:07:13 +0900

Hi,

Basically, I do not oppose that this be done in the NEMO WG if this is
what the WG wants to do. A first step would be to have someone writing a
draft, and then we could possibly include a new WG item.

My own view,
Thierry,

On Wed, 04 Aug 2004 14:27:39 -0400

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 05 Aug 2004 15:34:22 +0200

ivancic wrote:
> European Nations and just about any Industrial nations is trying to 
> help kick-start IPv6 deployments.  However, the ISP's and industry do
>  not yet have a good business case.  Making the transission easier 
> will help ALL of IPv6 deployments.

Yes I agree with this.  As you say, in addition to Doors which is not
standardized, we also have a different method IPv6-in-UDPv4 that was
prototyped and demonstrated and not standardized.

> I used some of Pascal's IPv6  NEMO code with the "Doors" protocol and
>  demonstrated this to the CIO of the US DoD.

Sidenote on this DoD demo.  Will, does this demo relate anyhow to the
Card/Zabele/DoD Linux demo and to the Connexion by Boeing CONOPS
mentioned previously on this list?

Alex

---

From: ivancic <[email-masked]>
Date: Fri, 06 Aug 2004 10:29:50 -0400

Alexandru Petrescu wrote:

> ........

Alex,

Yes and No.   Yes, in the fact that NASA, the DoD, and the FAA are all 
trying to get their hands around Network Centric Architectures and the 
potential to improve operations.  DoD is far far far ahead of the other 
agencies.  NASA and FAA are extremely conservative.   NASA and FAA 
communications for air (or space) to ground is largely point-to-point 
and circuit based.  The techniques and technology that are in place were 
developed in the 50's, 60's and maybe even into the 70's.  The decision 
makers really do not understand networking.  The FAA and NASA also have 
this idea that space and aeronautics is somehow unique.  However, one 
usually does not have to look far to similar problems in terrestial 
networks (delay, high BER, need for low power devices, intemitant 
connectivity, etc....).

Most of the FAA's and ICOA's (International Civil Aviation 
Organisation)  needs can be met more than adequately with today's 
technology.  However, in order to deploy solutions,  the aerospace 
community needs to be educated in what can be done with networking and 
shown that thier concerns have been addressed.   The other area that is 
of even greater importance, is the need to change policy.   POLICY 
drives everything.  If regulations say that I cannot send command and 
control data through someone elses network over a 2 Mbps, but rather, I 
have to send it over a low-rate 8 kbps shared link(VHF radio link)  that 
is easily jammed or congested,  I have no choice even though the 2 Mbps 
may be far supperior.   If I am told that I must be able to do 
policy-based routing in order to ensure that command and control goes 
over the VHF or INMARSAT Aero-H  link, then I am force to design a 
system that meets these mandates.  Note, the intentions are good, but 
the requirements are overspecifed.  Telling someone how do something 
versus telling someone what needs have to be fulfilled may result in 
drastically different implementations.   For example, requireing command 
and control to have highest priority and guarenteed delirery of 99.999% 
of all command and control messages within 2 seconds is far different 
than requireing that command and control be sent over a particular link.

The world is changing rapidly, and the Aeronautics community my well be 
forced to catch up.  The FAA and ICAO what to go digital voice and 
command, but the currently do not authenticate or encrypt  such 
messages.   I sincerely doubt that they have the necessary bandwidth in 
the VHF spectrum.   So, something will have to be done.  Hopefully  in a 
proactive manner, rather than reactive. 

Stewart has to make money for his company regarding the Air Traffic 
Management system.  Thus, he is forced to meet thier requirements and 
mandates. 

The aerospace industry is also very "code" consious.  They would like to 
have comfort that all code is fully tested for every possible case.  
This is obviously desirable, but gets much more difficult in a network 
centric environment as one cannot predict how the network will evolve.   
Thus, IMHO this POLICY will have to be modified somewhat in future 
systems deploying Commercial Off The Shelf (COTS) solutions.

NO, in that I am pushing for a fully  standards-based solution for Air 
Traffic Management, Aerospace, Space (Near-Planetary) and DoD.  I 
believe that having hundreds of thousands of man-hours in code 
development and millions of users testing the code via daily use in an 
unimaginable amount of architectures and environments is probably more 
robust then have 6 of the smartest people in the world writing a piece 
of code and then testing it in as many environments and they can think 
of (and afford to put together) for 6 months.    For example, I am 
working jointly on space-based research with Cisco.  They put a 3250 
PC-104 router in Low Earth Orbit.  The network connections are located 
at Glenn Research Center.   The router is working and configured for 
both static routing and mobile networking using IPv4.  If we did not 
have the entire IOS stack onboard, it would have been very difficult to 
configure and debug the system.  Note, I had 5 to 8 minute passes, 2 to 
3 times per week and about 5 weeks to configure and validate the entire 
secure network.  The router was launched with the most basic of 
configurations - for the most part, unconfigured.  Having standard-based 
tools enabled us to be successful.  I did not have access to this router 
until May and we did a demonstration of Network Centric Warfare June 
7-16.  (Please note, this is not intended as a commercial, rather it is 
intended to show what is possible when you stick to the standards.)
http://www.lompocrecord.com/articles/2004/06/16/news/news03.prt

Next goal is to move to IPv6.

Will

PS.  I am working on an internal paper with all the details.  Once that 
is completed, it needs to be sanitized for public distribution.  So, it 
will be a few months before I can release anything.   Sorry, but I have 
to protect the interestes of all parites that worked this including 
Surrey Satellite Technology Ltd, Cisco, General Dynamics, the Army and 
Air Force Battle Labs and Universal Space Networks.