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

[<teemu.savolainen@nokia.com>]

 >The problem with IPv4-only applications in an IPv6 world is 
>that there is no way to encode all possible IPv6 destinations 
>into an IPv4 header. However, the case where the ultimate 
>destination is also IPv4 and it's just the network in the 
>middle that's IPv4 is much easier.

True, but I wonder if it is a required feature that IPv4-only
applications can connect to IPv6 destinations? I.e. if application has
to connect to IPv6-destinations, the application should be updated to
support IPv6. The more common case could be network operator to upgrade
the access network to IPv6 while applications & services could still
continue use IPv4 - in that case the IPv4 connectivity should be
provided over the IPv6 cloud.

>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. We should have a solution available that
includes client side changes, as I believe those can be more efficient
e.g. in wireless systems than the "CPE" based solutions (if the "CPE" is
actually at the other side of the air interface).

>I'm currently looking at defining a new DHCPv6 option that would allow
>NAT464 devices/layers to discover the 96 upper bits used by 
>the NAT64 translator. Would DHCPv6 be fast enough for your use case?

It would (and often needed anyway e.g. for DNS discovery).

Best regards,
	
	Teemu