Subject: Simplified NAT-PT

From: Hiroshi MIYATA <[email-masked]>
Date: Wed, 6 Feb 2008 17:43:58 +0900

Hi All,

I submitted this document.

In this document, I intended to simplify old NAT-PT.
It is not yet completed, but I submitted it to introduce the simple
translator solution in my mind.
My another ID <draft-miyata-v6ops-trans-approach-00.txt>.
It was not concrete enough and there were few discussion on it.
This "sNAT-PT" is aiming to introduce concrete image of
"Current translator model description"in <draft-miyata-v6ops-trans- 
approach-00.txt>.

We have not yet concluded how to work on translator, but I submitted
it to make such discussion smoother.

--------------------------------------

A new version of I-D, draft-miyata-v6ops-snatpt-00.txt has been
successfuly submitted by Hiroshi Miyata and posted to the IETF
repository.

Filename:	 draft-miyata-v6ops-snatpt
Revision:	 00
Title:		 sNAT-PT: Simplified Network Address Translation -
Protocol Translation
Creation_date:	 2008-02-01
WG ID:		 Independent Submission
Number_of_pages: 24

Abstract:
This document specifies an IPv4-to-IPv6 transition mechanism to provide
accessibility for IPv6 node to IPv4 node, and vice-versa.
The goal of this document is not providing the most fundamental
technology which could works well with additional technology.
We used to have an technology called NAT-PT[RFC2766]. NAT-PT was
designed to work with problematic DNS Application Level Gateway. So, it
was changed to historical state by [RFC4966].
This document attempts to simplify NAT-PT specification, removing
dependability on Application Layer Gateway as well as resolving problems
pointed in [RFC4966].

--------------------------------------

Actually, it is 24 pages, but if you know the original NAT-PT well, you
can skip some parts.

The major differences from original NAT-PT is as follows.

1) Remove ALG from Original NAT-PT
2) Add conceptual model to clarify the borderline between sAT-PT and  
ALGs.
3) Propose new  Dummy Prefix format.

This is aiming neither total nor perfect solution but aiming most basic
solution.
And it can be extended by additional technologies.
The packet translation technique is same as original NAT-PT.

Roughly speaking added and updated chapters are  2.5, 3, 4, 9, 10, 11.1,
11.2, 11.3, 13.

Thanks for your comment.

....miyata

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Feb 2008 15:05:02 +1300

Miyata-san,

I haven't completely studied this yet, but I have two
quick comments.

>    The prefix PREFIX::/96 is advertised in the IPv6 network by the
>    NAT-PT gateway, and packets addressed to this PREFIX will be routed
>    to the NAT-PT gateway. The pre-configured PREFIX only needs to be
>    routable within the IPv6 network and as such it can be any routable
>    prefix that the network administrator chooses.

This seems to assume that the NAT-PT is at the boundary between
a closed IPv6 routing realm (where it's OK to advertise a /96)
and the IPv4 network. What happens if someone needs to put
a NAT-PT between a closed IPv4 routing realm and the open
IPv6 network?

>
>    The following 32-bit, represented as IDENT MUST be an value assigned
>    by IANA to indicate that translator would exist in the path.
>    More requirement for IDENT is described in Chapter 13.

Why is this useful?

    Brian

---

From: Hiroshi MIYATA <[email-masked]>
Date: Thu, 7 Feb 2008 12:34:02 +0900

Thanks Brian for your comment.

> a NAT-PT between a closed IPv4 routing realm and the open

I think advertising /64 is enough.
Prefix for routing should be 64-bit.
And following 32-bit is indicator used by host to detect the translator.
Sorry, my description maybe confusable.

>>   More requirement for IDENT is described in Chapter 13.

IDENT can help end-node to know the existence of translator.
And it must be unique.
Then the end-node can have some options.
Put dialog to user, quit the session, search other address, etc...
If the end-node does not have function to detect the translator,
like existing implementation, it would connect to the address.

Regards,

...miyata

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 08 Feb 2008 11:06:50 +1300

Hello again,

> Sorry, my description maybe confusable.

But you can't advertise a /64 to the Internet either...

> Put dialog to user, quit the session, search other address, etc...

I don't understand the value of these options. If you wanted the
upper layer protocol to calculate "correct" checksums, you could
play tricks with these "IDENT" bits to achieve that, I suppose.

    Brian

---

From: Hiroshi MIYATA <[email-masked]>
Date: Fri, 8 Feb 2008 08:59:52 +0900

Hi Brian,

> But you can't advertise a /64 to the Internet either...

Aggregated prefix is also fine.
If the packet arrived to the gateway, it works.
I think it is same as router who has stab network below.

> play tricks with these "IDENT" bits to achieve that, I suppose.

Yes, above story supposes upper layer action. ;-)

Thanks,

....miyata