[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: WG last call on NAT-PT to Experimental



Thanks for your remarks.

My impression is that you are thinking of a different case.

The v6-to-v4 translation I am after concerns:
-  called v4 devices which have AAAA record in the DNS in order to be
reachable from outside their site. ( If such a device has also to be reached
by hosts in the same sites, a local DNS may also contain an A record giving
its local v4- address. But this is not the subject at hand.)
-  called sites the entrance node of which are dual-stack
-  calling hosts which have v6 connectivity (and access to  AAAA records).
 (The translation therefore works in the reverse direction from that of a
NAT-PT used for v6 hosts to reach v4 hosts at global v4-addresses.)

Other point-by-point comments follow.

Having limited ourselves to those applications for which it works without
changing application data, there are four requirements:

- that DNS be made to work (the far device is only advertising an A or MX
record; we need to set up relevant state and advertise a AAAA record
referencing the translator)
* No DNS record translation is needed here because the calling host is
assumed to have v6 connectivity, and access to v6 DNS, and because the
called host has a v6 address in the DNS.


 - that the assigned IPv6 address correlate with the IPv4 address+port in
question (let me think hard, I'll bet the IPv4 address+port get embedded
in the IPv6 address)
* The port which may be modified by the translator is that of the  calling
host.
 It has no relationship with this host's address, which is any v6 address.
 The port of the called device is that of the application.
 It is not subject to any translation, and has therefore no reason to
appear in any address.

 - that the router not be required to re-assemble datagrams (use Path MTU,
MSS modification, etc to effect this)
* On the v6 side, the v6-to-v4 translator could simply reject any v6 packet
longer than 1280.
 On the v4 side, it could simply reject any v4 packet which contains a
fragment of an incomplete datagram.

- TCP/UDP/SCTP works (adjust the transport checksum appropriately)
* Yes. Due to pseudo-header inclusion in UDP and TCP checksums, the
translator has to adjust these checksums (like NAT-PT has to).
 On the other hand, SCTP, which has in my understanding checksum adjustment
problems also with IPv4 NATs, should remain out of the scope of the proposed
mechanism.
 (Incidentally, we can assume that there should be a negligible number of
v4 devices which are both SCTP capable and not easily dual-stack
upgradeable.)

I'm not opposed to necessary work being done, but I'm not so sure what
work needs to *be* done. We seem to have a lot of transition efforts
around, but there must be a way to bring them together into a single
simple solution. Bring us that one simple path, and then we'll talk.
* In my understanding, the proposal I bring forward is orthogonal with other
questions being worked on (in particular with tunnel configurations of
v6tc), and does satisfy a real need.
 Its main new implication is an address format variant, which contains a
specific indication if the addressed node has to be reached in IPv4.
 Besides that, unless I am mistaken, complete specification of the
translator should not be difficult, starting from the work already made for
NAT-PT and from the comments above.


*Last but not least, and to keep maintaining everything on the table, an Intellectual Property implication is part of the picture. This was made known as early as in November 2004, when http://ops.ietf.org/lists/v6ops/v6ops.2004/msg01660.htmlt pointed to an early and first document. Its introduction was clear on IP rights (and its section 4.3 is still somewhat relevant). I obviously hope that this should not be blocking. If, as I do expect, the practical value of the approach is eventually appreciated, my plan is not more than getting a fair and reasonable return for the significant work I did. (This work was a personal investment, without any compensation from anywhere). The goal is besides that to make the benefits of that work available to the community of whoever may take advantage of it.

RD