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

Re: I-D Action:draft-ietf-v6ops-nat64-pb-statement-req-00.txt

On 18 jun 2008, at 8:32, <teemu.savolainen@nokia.com> <teemu.savolainen@nokia.com > wrote: 


In a previous modified-nat-pt draft I wrote about the v4-v6-v4
case where IPv4 clients sit behind a CPE or layer in the stack
that translates their IPv4 packets into IPv6 packets using SIIT (=
stateless) and then the resulting IPv6 packets flow through the same
NAT64 translators that IPv6 hosts that want to talk to the
IPv4 world also use.



Expect to see a new or updated draft on this topic before Dublin.



I'm looking forward to it.
Unfortunately, other work came up so I didn't have time for this before the deadline... This is text from an expired draft: 

http://www.muada.com/drafts/draft-van-beijnum-modified-nat-pt-02.txt

5.  IPv4-IPv6-IPv4 operation

   It would be optimistic to expect that all hosts implement IPv6 and
   the mechanisms outlined above within a limited timeframe.  As such,
   it is useful to support both hosts that don't implement the changes
   set forth in this document, and even hosts that don't implement IPv6
   at all.  In these cases, a gateway device may be employed that
   manages a block of private IPv4 address space using DHCP and
   translates these to IPv6 addresses.  The local device performs SIIT
   between the resulting IPv4 and IPv6 address pairs but not IPv4 NAT.

   Since the remote translator that translates from IPv6 to public IPv4
   requires a unique IPv6 address in order to demultiplex, the local
   gateway MUST use a dedicated IPv6 address for each local IPv4
   address.  Any [RFC1918] address may be used locally as long as the
requirements are met that only a single local IPv4 address maps to an 
   IPv6 address, and that the addresses are equivalent for the purposes
of computing checksums. A way to conform to these requirements is to 
   construct the IPv6 address from the IPv4 address as follows:

   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   | 64-bit subnet prefix  |F0|ID|CHKSM| IPv4 addr |
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

   Bit 70 in the address MUST be set to 0 to indicate a non globally
   unique address.  The ID bits can contain a value that allows
different gateways to live on the same subnet. In the absence of any administrative settings or the detection of duplicate addresses, this 
   could be the lower 8 bits of the gateway's MAC address.  The CHKSM
   bits are chosen such that they compensate for the differences in the
   checksum generated over the IPv4 pseudo-header and the checksum
generated over the IPv6 pseudo-header. This means that this value is 
   the one's complement of the one's complement addition of the 16-bit
   words from the top 96 bits of the address of remote modified NAT-PT
   translator and all the 16-bit words from the top 80 bits of IPv6
   address that is being constructed.
The local gateway SHOULD also perform IPv6 routing or otherwise allow 
   IPv6 connectivity so that hosts that do support IPv6, but not
   MNAT-PT, have the ability to communicate directly over IPv6 in
   addition to being able to use translated IPv4 connectivity.

   There are two open issues: how do IPv4 hosts using different local
gateways but the same modified NAT-PT translator communicate, and how 
   do NAT traversal protocols such as uPnP, NAT-PMP and others work.


We should have a solution available that
includes client side changes
Hm, client side modifications for 4-6-4 operation doesn't seem very useful...