Subject: draft for Translator discussion

From: Hiroshi MIYATA <[email-masked]>
Date: Thu, 6 Dec 2007 09:21:18 +0900

Hi all,

Now we have big wave of translator discussion.
As RFC4966 deprecated NAT-PT, it is good thing to discuss on
alternatives.

On the other hand, I have some concerns.

a) Time frame.
	2010 is very close.
	Short term view is desired by the market as well as long term view.

b) Target devices.
	It is good thing to design translation technologies to resolve
	all issues listed in RFC4966.
	Some translator proposals require modification to IPv6 end-devices.
	But we have to be aware that we already have many IPv6 devices  
deployed.

	So, we should take care of following kind of devices.
	- IPv4 devices
	- Existing IPv6 devices
		These does not have special code to work with translator.
	- Future IPv6 devices
		These has special code to work with translator.

To prepare the coming IPv6 deployment, we need to clarify what is  
required for
which kind of device by when.

To ask your opinion, I described my concern briefly.(just as the  
first step)
When we consider the tranlator, this kind of document itself is also  
required not to
produce the missing part, I think.

http://www.tahi.org/~miyata/doc/draft-miyata-v6ops-trans-approach-00.txt
(I submitted it to IETF)

Please take a glance and give your comments. It is very short one.

Thanks,

....miyata

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 5 Dec 2007 17:34:20 -0800

> Please take a glance and give your comments. It is very short one.

Do I understand correctly that your concern is that modifying either  
existing NAT-PT implementations and/or existing IPv6 hosts when we  
update the NAT-PT mechanism would create deployment delays?

Iljitsch

---

From: "Erik Kline" <[email-masked]>
Date: Wed, 5 Dec 2007 21:18:54 -0800

> Please take a glance and give your comments. It is very short one.

I'm sure I'll be derided for eternity and my eat my words, but at the
moment it looks like the old NAT-PT (2766, iirc) works just fine for
my deployment/transition needs (for IPv6-only corporate networks).
None of the objections in 4966 actually apply in my situation.  I may
be the only one, but I intend to keep using the deprecated method
until I have to change.  Perhaps my company is degenerately simple,
but I'm fairly sure I can reap IPv4 networks (once I've achieved wide
dual-stack deployment and healthy IPv6 transit, etc.).  Of course
there are Operating System *platform* issues (like why do I have run
DHCPv4 for certain OSes if I'm trying to run an IPv6-only network?).

-Erik

---

From: Hiroshi MIYATA <[email-masked]>
Date: Thu, 6 Dec 2007 14:48:29 +0900

Hi Iljitsh,

Thanks for your reading.
If we have only one approach that we require modification of existing
IPv6 hosts, it may create deployment delay.

Modifying NAT-PT itself may not create delays, as far as it does not
require IPv6 host modification.

Also we have to be aware that there are some translator implementation
based on NAT-PT, but not fully compliant NAT-PT, since vendors already
realized that implementations fully compliant to NAT-PT does not work
well.
The advantage of it is not requiring modification on IPv6 hosts. ;-)
The disadvantage of it is not resolving all issues listed on  
RFC4966. ;-(

I implicitly think that some vendors may think it is too expensive to
implement IPv6 host which fully support perfect and/or multipurpose
tranlator.

My another point is directing document is also required.

Thanks,

...miyata

On 2007/12/06, at 10:34, Iljitsch van Beijnum wrote:

>> When we consider the tranlator, this kind of document itself is  
>> also required not to
> Do I understand correctly that your concern is that modifying  
> either existing NAT-PT implementations and/or existing IPv6 hosts  
> when we update the NAT-PT mechanism would create deployment delays?
>
> Iljitsch

---

From: Hiroshi MIYATA <[email-masked]>
Date: Thu, 6 Dec 2007 16:18:41 +0900

Erik,

Thanks, for your comment.

I can agree deprecating NAT-PT since it is fully combined with
controversial DNS-ALG.

I think there would be some translation solutions, depending on the  
requirement.
So some portion of NAT-PT works well in some limited environment.

Then it is one of the approaches to sprit apart NAT-PT and pickup  
some portion
and give some simple modification if required.
Of course adding some notification what is the advantage/disadvantage,
recommended usage/unrecommended usage.

....miyata

---

From: "Erik Kline" <[email-masked]>
Date: Thu, 6 Dec 2007 02:57:36 -0800

Miyata,

To be clear I'm actually in favour of 2766, and not a big fan of 4966.
 4966 seems like cutting off the nose to spite the face, to me.  But I
wasn't participating in the IETF when all this was decided so I can't
really comment.

Maybe I'm just too naive or just not smart enough, but I'm
contemplating the start of a future endgame where I begin to turn off
IPv4 networks inside my company one at a time.  I'll need dual stack
for a long time but once I've got IPv6 broadly available then I should
be able to start examining networks and the applications my users are
hitting and identify subnets that have no real need for IPv4 anymore
(as long as something like NAT-PT is in place).

I'm imagining these would be the sort of corporate networks where the
traffic is principally HTTP, maybe some CIFS/NFS, and perhaps some
SMTP.  Heck even ssh traffic would work just fine on an IPv6-only
network (with some extra known_hosts key accepting).  For these users'
traffic 2766 is basically OK.  Perhaps I just haven't run into
something that will make me see sense, but it seems the needs are
pretty simple for us.  Again: perhaps our needs are degenerately
simple or perhaps my thinking is degenerately simple.

Of course if I run into problems described in 4966 (or not mentioned
there, for that matter) I have a line of defense lots of people may
not have: I get to ask "Is there a legitimate business need for this
to work?"  (the old "defer to higher authority" negotiation tactic)

Let me say though that any solution that involves an update to the
IPv6 stack *on the hosts* is not a solution for me (I *fully respect*
that it may well be wonderful for other users, networks, applications,
or purposes and could deserve considerable attention from the WG).  My
host IPv6 stacks are deployed (it's just the routing isn't all there
yet, and perhaps IPv6 is disabled administratively).  I don't want to
have to upgrade my entire fleet of VendorOS desktops and servers to
get the lastest shim/nat-aware ipv6 stack.  I want to buy a device.  I
already have (or will eventually :-) a bunch of IPv6-capable hosts; I
just want to buy something to stick between them and the IPv4 world
until it's safe to let it die (in 10 years time, or whenever).

I've probably wandered well off topic and much of what I've said may
utterly lack relevance so I'll stop now.

Thanks,
-Erik

---

From: Hiroshi MIYATA <[email-masked]>
Date: Fri, 7 Dec 2007 03:10:22 +0900

Hi all,

I failed to add one issue.

There is well-known issue for generic translator, which is numeric  
address
embedded contents.
Typically, some html files contain link like
http://[numeric address]/something

So, we need to make some guidelines for "translation friendly contents".

Let me raise one more action item in my document.

5.4. Guideline for "Translation Friendly Contests"

Thanks,

....miyata

---

From: Arifumi Matsumoto <[email-masked]>
Date: Fri, 07 Dec 2007 03:35:04 +0900

> my deployment/transition needs (for IPv6-only corporate networks).

My boss is in IPv6-only(NAT-PTed) network and has several problems:

- he cannot use Google cache and not a small number of web pages,
  because IPv4 address is embedded in URL.
- he cannot use MSN messenger, because the protocol isn't IPv6 enabled.
- he cannot use Skype and other several softwares, because the protocol
  or software probably don't support IPv6.

IMHO, I agree with Miyata-san in that NAT-PT itself maynot be evil
iff it is placed in the right place and situation.

Regards,
Arifumi Matsumoto

---

From: Masahito Endo <[email-masked]>
Date: Fri, 07 Dec 2007 17:34:19 +0900

> realized that implementations fully compliant to NAT-PT does not work

We (Yokogawa) have a translator that based on NAT-PT. But It is not fully compliant NAT-PT.
We tried to operate an IPv6 only network using our translator.
At that time, there were some problems and we implemented the functions to solve them. 

> The disadvantage of it is not resolving all issues listed on RFC4966. ;-(

About our translator, some issues of RFC4966 were already solved. In limited environment, it works well.
But, there are some applications and contents that depended on IPv4 address.
I think we must consider about it to communicate between IPv4 and IPv6 network and to deploy IPv6.

thanks,

// masaxmasa