[BEHAVE] NAT selection by DNS for SIPNAT [catching up]

Hello Zhen,

In the scenario outlined, an IPv6-only destination needs to get
an IPv4 interface address so that it can receive packets from the
IPv4 Internet.  It is fair to assume that IPv6 routing works on the
IPv6-only side of all the NAT boxes.  The proposal does not
need to divide the IPv6-only hosts into separate routing domains,
one per NAT box.  This would be needed for IPv4 private
address destinations, but not for IPv6.  So, I reckon that the
IPv6-only destination would be reachable from any one of the
NAT boxes providing connectivity between the IPv6-only
domain and the IPv4 Internet.

Regards,
Charlie P.

Zhen Cao wrote:
> Hi all, 
>
> I also have one comment. In the example of the draft, fooNS (name 
> server for foo.net <http://foo.net>) needs to contact the NAT box to 
> get an IPv4 address. But the fooNS may not know the address of the NAT 
> box. There might be multiple NAT boxes, but only one name server for 
> the foo.net <http://foo.net>. The name server does not know which NAT 
> box to contact and get the address. 
>
> Thanks,
> Zhen
> On Sat, Dec 12, 2009 at 10:48 AM, Dave Thaler <dthaler@microsoft.com 
> <mailto:dthaler@microsoft.com>> wrote:
>
>     > -----Original Message-----
>     > From: behave-bounces@ietf.org <mailto:behave-bounces@ietf.org>
>     [mailto:behave-bounces@ietf.org <mailto:behave-bounces@ietf.org>] On
>     > Behalf Of Charles E. Perkins
>     > Sent: Monday, October 19, 2009 2:16 PM
>     > To: behave@ietf.org <mailto:behave@ietf.org>
>     > Subject: [BEHAVE] SIPNAT documents posted
>     >
>     >
>     > Hello folks,
>     >
>     > At 1:59:30pm Pacific Time today, I posted the following draft:
>     >     "Payload-assisted Delivery for SIPNAT"
>     >     http://www.ietf.org/internet-drafts/draft-perkins-behave-dpinat-
>     > 00.txt
>     >
>     > There is also a revision to the base SIPNAT document:
>     >     "Translating IPv4 to IPv6 based on source IPv4 address"
>     >     http://www.ietf.org/internet-drafts/draft-perkins-sourceipnat-
>     > 01.txt
>     >
>     > Comments are appreciated.  Thanks to those who have helped
>     > me to improve these documents before submission.
>     >
>     > Regards,
>     > Charlie P.
>
>     Two comments:
>
>     1) The documents do not address the problem whereby some recursive
>       resolvers (aka DNS servers) used by clients cache answers for
>       some time (like 30 seconds) even if the record TTL is less.
>       Multiple clients can get the same answer and only the first one
>       will work and the rest will break.
>
>     2) In the dpinat document, it discusses using the HTTP GET in the
>       NAT for demultiplexing.  However, it can't get an HTTP GET until
>       after a TCP connection is established, which means it would need
>       to terminate the TCP connections itself and act more like an
>       HTTP proxy rather than a NAT.  (Which is what is discussed in
>       http://tools.ietf.org/html/draft-wing-behave-http-46-relay)
>
>     -Dave
>     _______________________________________________
>     Behave mailing list
>     Behave@ietf.org <mailto:Behave@ietf.org>
>     https://www.ietf.org/mailman/listinfo/behave
>
>