Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 5 Nov 2013 02:27:30 +0000

I have hard time to understand the case described in section 3.1.4 "co-existence of NAT44 and NAT64". Why would a provider use both at the same time? Using NAT44 + native IPv6 is sensible, using IPv6-only + NAT64 is also valuable but I cannot imagine why NAT44 and NAT64 could be use together for the same subscribers.

Thanks for shedding some light for me :-)

-éric

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: dimanche 13 octobre 2013 16:00
> To: [email-masked]
> Cc: [email-masked]
> Subject: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>  This draft is a work item of the IPv6 Operations Working Group of the
> IETF.
> 
> 	Title           : NAT64 Operational Experiences
> 	Author(s)       : Gang Chen
>                           Zhen Cao
>                           Chongfeng Xie
>                           David Binet
> 	Filename        : draft-ietf-v6ops-nat64-experience-04.txt
> 	Pages           : 20
> 	Date            : 2013-10-13
> 
> Abstract:
>    This document summarizes NAT64 function deployment scenarios and
>    operational experience.  Both NAT64 Carrier Grade NAT (NAT64-CGN) and
>    NAT64 server Front End (NAT64-FE) are considered in this document.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-experience
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience-04
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-nat64-experience-04
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 5 Nov 2013 03:30:30 +0100 (CET)

On Tue, 5 Nov 2013, Eric Vyncke (evyncke) wrote:

> I have hard time to understand the case described in section 3.1.4 
> "co-existence of NAT44 and NAT64". Why would a provider use both at the 
> same time? Using NAT44 + native IPv6 is sensible, using IPv6-only + 
> NAT64 is also valuable but I cannot imagine why NAT44 and NAT64 could be 
> use together for the same subscribers.

Mobile.

It's up to the terminal to initiate a connection in the APN, and you don't 
know if it'll be IPv4 only, IPv6 only or dual stack.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Victor Kuarsingh <[email-masked]>
Date: Mon, 04 Nov 2013 18:39:47 -0800

Eric,

On 2013-11-04 6:27 PM, "Eric Vyncke (evyncke)" <[email-masked]> wrote:

>same time? Using NAT44 + native IPv6 is sensible, using IPv6-only + NAT64
>is also valuable but I cannot imagine why NAT44 and NAT64 could be use
>together for the same subscribers.
>

That's a good question. I cannot comment on the original intent of this
section, but one use case I can think of is a APN (with associated routing
contexts etc) which may land both IPv4-only, Dual Stack, or IPv6-only PDP
contexts (depending on what the device asks for and/or what is allowed by
network).

In such a case, if using private IPv6 addresses for the UE, it's possible
that you can have this happen.  Perhaps, as long as it does not break
anything, it's ok?

Regards,

Victor K

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 5 Nov 2013 02:46:47 +0000

OK, understood, thanks :-) Your (and Victor's one) should be added to the document to make it clearer IMHO

-éric

> From: Mikael Abrahamsson [mailto:[email-masked]]
> Sent: lundi 4 novembre 2013 18:31
> To: Eric Vyncke (evyncke)
> Cc: [email-masked]
> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt
> 
> > "co-existence of NAT44 and NAT64". Why would a provider use both at
> > the same time? Using NAT44 + native IPv6 is sensible, using IPv6-only
> > +
> > NAT64 is also valuable but I cannot imagine why NAT44 and NAT64 could
> > be use together for the same subscribers.
> 
> Mobile.
>

---

From: Victor Kuarsingh <[email-masked]>
Date: Mon, 04 Nov 2013 18:57:48 -0800

All,

Ooops..

>In such a case, if using private IPv6 addresses for the UE, it's possible

Typo - s/private IPv6 addresses/private IPv4 addresses/g

Victor K

---

From: GangChen <[email-masked]>
Date: Tue, 5 Nov 2013 11:15:01 +0800

> document to make it clearer IMHO

Yes. In the draft, we have following description:

   The
   coexistence has already appeared in mobile networks, in which dual
   stack mobile phones normally initiate some dual-stack PDN/PDP
   Type[RFC6459] to query both IPv4/IPv6 address and IPv4 allocated
   addresses are very often private ones.

-Gang

---

From: "Heatley, Nick" <[email-masked]>
Date: Fri, 8 Nov 2013 17:10:39 +0000

Talking further about coexistence of NAT64 and NAT44.
If NAT64 is good enough for IPv6-only clients then it's good enough for all NAT-based clients, right?

A thought experiment.
A network runs subscribers based on:
- IPv4 private addressing only, via NAT44
- IPv6 native, but IPv6-only devices pass via NAT64 to access v4 only content
- The NAT44 and NAT64 is provided by the same platform, the platform capacity is unchanged by v4 and v6 mixes, and the vendor aims to reach parity on ALGs (for the sake of argument, let's say this has been achieved)

The dual stack hosts could all prioritise AAAA and take the v6 path by default.
Happy Eyeballs could override this, and prioritise the v4 path in cases where  based on the client.

I understand the troubleshooting argument of knowing to which NAT path your traffic goes, (but hey, that's Happy Eyeballs).
Other than that, why would this network operator care whether traffic to IPv4 content from dual stack clients goes via NAT64 or NAT44?
If the scope of DNS64 effectively pushes all dual stack clients to favour NAT64, why not?

Regards,
Nick

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of GangChen
Sent: 05 November 2013 03:15
To: Eric Vyncke (evyncke)
Cc: [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt

   The

-Gang

>> > NAT64 is also valuable but I cannot imagine why NAT44 and NAT64 
>> > could be use together for the same subscribers.
>>
>> Mobile.
>>
>> It's up to the terminal to initiate a connection in the APN, and you 
>> don't know if it'll be IPv4 only, IPv6 only or dual stack.
>>
>> --

NOTICE AND DISCLAIMER
This e-mail (including any attachments) is intended for the above-named person(s).  If you are not the intended recipient, notify the sender immediately, delete this email from your system and do not disclose or use for any purpose.  
 
We may monitor all incoming and outgoing emails in line with current legislation. We have taken steps to ensure that this email and attachments are free from any virus, but it remains your responsibility to ensure that viruses do not adversely affect you. 

EE Limited
Registered in England and Wales
Company Registered Number: 02382161
Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9BW

---

From: Gert Doering <[email-masked]>
Date: Fri, 8 Nov 2013 18:27:30 +0100

Hi,

> If the scope of DNS64 effectively pushes all dual stack clients to favour NAT64, why not?

If you have NAT44 and native IPv6, I can't see why you would want to add 
DNS64+NAT64 to the mix.

NAT64 is good when you do *not* want IPv4 at the customer edge.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 9 Nov 2013 09:27:32 +0100 (CET)

> NAT64 is good when you do *not* want IPv4 at the customer edge.

Mobile. You don't know if the client is v4 only, v6 only, or dual stack. 
This is up to the client.

---

From: Gert Doering <[email-masked]>
Date: Sat, 9 Nov 2013 14:25:53 +0100

Hi,

> This is up to the client.

Understood, and I see your issue here - you would want to announce a 
"normal" DNS server to a dual-stack client, not a DNS64 server, and 
you can't do that because you don't know whether he's v6 only or 
dual-stack.

This is somewhat easier in other types of large-scale customer deployments, 
where you can control what the client can get - which will mostly be 
something like "NAT44+IPv6" for many subscribers for the time to come, so
adding DNS64/NAT64 really does not have much benefit here.

Gert Doering
        -- NetMaster

---

From: "Heatley, Nick" <[email-masked]>
Date: Mon, 11 Nov 2013 08:24:10 +0000

Agree, the questions seem only relevant to the mobile use case (with a normal baseline of IPv4 privates + NAT44).
Hopefully you can see that the questions are valid now.
I seek arguments why, in an access network dominated by NAT why to prefer one flavour over another? - other than pushing my NAT vendor to achieve parity NAT64 <--> NAT44 (they claim both translations are in hardware). If NAT64 is good enough for IPv6-only clients its good enough for Dual Stack NAT?
Nick

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gert Doering
Sent: 09 November 2013 13:26
To: Mikael Abrahamsson
Cc: [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt

Hi,

> This is up to the client.

Understood, and I see your issue here - you would want to announce a "normal" DNS server to a dual-stack client, not a DNS64 server, and you can't do that because you don't know whether he's v6 only or dual-stack.

This is somewhat easier in other types of large-scale customer deployments, where you can control what the client can get - which will mostly be something like "NAT44+IPv6" for many subscribers for the time to come, so adding DNS64/NAT64 really does not have much benefit here.

Gert Doering
        -- NetMaster

EE Limited

---

From: GangChen <[email-masked]>
Date: Mon, 11 Nov 2013 22:46:42 +0800

2013/11/11, Heatley, Nick <[email-masked]>:
> Agree, the questions seem only relevant to the mobile use case (with a
> normal baseline of IPv4 privates + NAT44).
> I seek arguments why, in an access network dominated by NAT why to prefer
> one flavour over another?  - other than pushing my NAT vendor to achieve
> parity NAT64 <--> NAT44 (they claim both translations are in hardware). If
> NAT64 is good enough for IPv6-only clients its good enough for Dual Stack
> NAT?
the argument here is to let:

dual-stack UEs go to NAT44+IPv6 or native IPv4+IPv6
IPv6-only UEs go to NAT64/DNS64
IPv4-only UEs go to NAT44 or native IPv4

It doesn't expect that dual-stack UEs go to NAT64, because IPv4 native
connections are preferred over  IPv6+NAT64

BRs

Gang

> "normal" DNS server to a dual-stack client, not a DNS64 server, and you
> can't do that because you don't know whether he's v6 only or dual-stack.
>
> This e-mail (including any attachments) is intended for the above-named
> person(s).  If you are not the intended recipient, notify the sender
> immediately, delete this email from your system and do not disclose or use
> for any purpose.
>
> We may monitor all incoming and outgoing emails in line with current
> legislation. We have taken steps to ensure that this email and attachments
> are free from any virus, but it remains your responsibility to ensure that
> viruses do not adversely affect you.
>
> EE Limited

---

From: Gert Doering <[email-masked]>
Date: Mon, 11 Nov 2013 15:54:52 +0100

Hi,

> connections are preferred over  IPv6+NAT64

How does the UE know that a target can be reached by native IPv4 if 
DNS64 tells it "there is IPv6 for you" and IPv6 is preferred to IPv4?

Gert Doering
        -- NetMaster

---

From: GangChen <[email-masked]>
Date: Tue, 12 Nov 2013 22:35:45 +0800

> DNS64 tells it "there is IPv6 for you" and IPv6 is preferred to IPv4?

UE may not can determine the existence of IPv4 native connections.
However, an network side may could serve the right DNS address
according to the UE connection status, for example the solution
described at http://tools.ietf.org/html/draft-wing-dhc-dns-reconfigure-00

Gang

---

From: <[email-masked]>
Date: Thu, 14 Nov 2013 07:45:22 +0100

Gert,

this needs to be resolved in the provider's network by applying DNS64 only to those UE that have an IPv6-only connection. Usually, IPv6-only connectivity means a separate APN with a dedicated IPv6 pool, so either IPv4 and IPv4v6 UE get a different DNS server than the IPv6-only UE, or the DNS server is the same and it can deduce from the client's IPv6 address whether it's an IPv4v6 or and IPv6-only client.

Holger

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Gert Doering
Gesendet: Montag, 11. November 2013 15:55
An: GangChen
Cc: [email-masked]
Betreff: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt

Hi,

Gert Doering
        -- NetMaster

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 14 Nov 2013 07:58:38 +0100 (CET)

On Thu, 14 Nov 2013, [email-masked] wrote:

> this needs to be resolved in the provider's network by applying DNS64 
> only to those UE that have an IPv6-only connection. Usually, IPv6-only 
> connectivity means a separate APN with a dedicated IPv6 pool, so either 
> IPv4 and IPv4v6 UE get a different DNS server than the IPv6-only UE, or 
> the DNS server is the same and it can deduce from the client's IPv6 
> address whether it's an IPv4v6 or and IPv6-only client.

I oppose this reasoning. It brings in unneeded complexity in the mobile 
core network to handle all this logic, and besides, customers should be 
able to choose if they want IPv4v6 or IPv6 only, meaning you don't know in 
advance.

It's beneficial if standards allow for less complexity in backend systems. 
Complex backend systems is less problem for huge ISPs, but it is for 
smaller ones. Also, even huge ISPs benefit from less complexity in their 
backend systems.

---

From: Tore Anderson <[email-masked]>
Date: Thu, 14 Nov 2013 09:55:37 +0100

* Gert Doering

> DNS64 tells it "there is IPv6 for you" and IPv6 is preferred to IPv4?

One could use a ULA prefix for DNS64/NAT64, which would make native IPv4
be preferred according to RFC 6724.

Tore

---

From: Tim Chown <[email-masked]>
Date: Thu, 14 Nov 2013 09:17:32 +0000

> be preferred according to RFC 6724.

A related discussion came up some time ago when we were discussing 3484-bis that became 6724:
http://www.ietf.org/mail-archive/web/ipv6/current/msg13709.html

That was about the NAT64 WKP appearing - or being added to - the 6724 policy table.  There is now a DHCPv6 option for that.

Tim

---

From: Gert Doering <[email-masked]>
Date: Thu, 14 Nov 2013 10:33:18 +0100

Hi,

> That was about the NAT64 WKP appearing - or being added to - the 6724 policy table.  There is now a DHCPv6 option for that.

Nice approach (both).  Thanks for pointing that out.

Tim, do you know whether there is any implementation that will handle
that, that is, accept that DHCPv6 option and add it to the 6724 policy
table accordingly ("lower than native IPv4")?

Gert Doering
        -- NetMaster

---

From: Tim Chown <[email-masked]>
Date: Thu, 14 Nov 2013 10:14:28 +0000

> table accordingly ("lower than native IPv4")?

I believe that at least both Cisco and ISC are working on implementations.

Tim

---

From: Gert Doering <[email-masked]>
Date: Thu, 14 Nov 2013 11:18:29 +0100

Hi,

> I believe that at least both Cisco and ISC are working on implementations.

That sounds like "the server side" - which is needed, but shouldn't take
a miracle to add.

More interesting to me would be "client side" :-)

Gert Doering
        -- NetMaster

---

From: Tim Chown <[email-masked]>
Date: Thu, 14 Nov 2013 10:23:20 +0000

> More interesting to me would be "client side" :-)

Indeed.  And always the main problem/challenge with any new DHCPv6 option.

Tim

---

From: "Heatley, Nick" <[email-masked]>
Date: Mon, 18 Nov 2013 13:31:56 +0000

In summary of this thread, as best I understand it:
We agree that a mixed environment with IPv6-only and dual stack clients with NAT64 and NAT44 gateways is a "mobile RFC1918 host " use case.
There appear valid concerns about 1) performance on different paths (and clients picking those paths dynamically), 2) traceability for Operations, 3) the relative state of NAT44 and NAT64 ALGs, and 4) capacity or running NAT44 and NAT64 gateways.

How to provide connectivity to IPv4-only content in such a mixed NAT44/NAT64 environment?
- one approach is to try to keep dual stack hosts unchanged / on a pure NAT44 path (the recommendation of the draft)
- another documented approach is to add more sophisticated functionality to steer the different clients to suitable DNS as per draft http://tools.ietf.org/html/draft-wing-dhc-dns-reconfigure-00

I am thinking I will trial another approach for the NAT44/NAT64 environment; to let RFC1918 dual stack hosts prefer the NAT64 path.
To address the concerns above, this approach would rely on:
a) parity of NAT44 and NAT64 ALGs (I need to push my vendor)
and b) from a capacity and traceability perspective, will run on a combined NAT44/NAT64 platform.

A trial will be in a mobile environment, it will be a mix of IPv4-only UEs, dual stack UEs and IPv6-only + 464xlat UEs (hats off to Cameron there).
Any other pointers/concerns would be gratefully received.
Regards,
Nick

-----Original Message-----
From: GangChen [mailto:[email-masked]] 
Sent: 12 November 2013 14:36
To: Gert Doering
Cc: Heatley, Nick; Mikael Abrahamsson; [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt

2013/11/11, Gert Doering <[email-masked]>:
>> It doesn't expect that dual-stack UEs go to NAT64, because IPv4 
>> native connections are preferred over  IPv6+NAT64
>

UE may not can determine the existence of IPv4 native connections.
However, an network side may could serve the right DNS address according to the UE connection status, for example the solution described at http://tools.ietf.org/html/draft-wing-dhc-dns-reconfigure-00

Gang

NOTICE AND DISCLAIMER

EE Limited

---

From: Dan Wing <[email-masked]>
Date: Tue, 19 Nov 2013 12:04:03 -0800

> Indeed.  And always the main problem/challenge with any new DHCPv6 option.

"Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis" [RFC7050 (previously draft-ietf-behave-nat64-discovery-heuristic)] does not rely on the DHCP option.  Folks say it works.  But there is a general dislike for heuristics, for lots of good reasons. 

-d

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 20 Nov 2013 15:20:43 +0900

On Thu, Nov 14, 2013 at 5:55 PM, Tore Anderson <[email-masked]> wrote:

> One could use a ULA prefix for DNS64/NAT64, which would make native
> IPv4 be preferred according to RFC 6724.
>

But then if you have IPv6-only with 464xlat you end up preferring 464xlat
over NAT64.

---

From: <[email-masked]>
Date: Wed, 20 Nov 2013 08:53:23 +0100

Hello Mikael,

I agree, but are there any other choices? 

One could argue that the UE is responsible by itself to use NAT64 correctly when attaching to an IPv6-only context, e.g. by performing automatic NAT64 prefix detection and performing DNS64 internally (which would have the benefit to work with DNSSEC) in addition to 464Xlat.

Holger

-----Ursprüngliche Nachricht-----
Von: Mikael Abrahamsson [mailto:[email-masked]] 
Gesendet: Donnerstag, 14. November 2013 07:59
An: Metschulat, Holger
Cc: [email-masked]; [email-masked]; [email-masked]
Betreff: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt

On Thu, 14 Nov 2013, [email-masked] wrote:

> IPv4 and IPv4v6 UE get a different DNS server than the IPv6-only UE, 
> or the DNS server is the same and it can deduce from the client's IPv6 

I oppose this reasoning. It brings in unneeded complexity in the mobile core network to handle all this logic, and besides, customers should be able to choose if they want IPv4v6 or IPv6 only, meaning you don't know in advance.

It's beneficial if standards allow for less complexity in backend systems. 
Complex backend systems is less problem for huge ISPs, but it is for smaller ones. Also, even huge ISPs benefit from less complexity in their backend systems.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 20 Nov 2013 09:09:01 +0100 (CET)

> I agree, but are there any other choices?

We could provide the problem case and have "someone" develop standards to 
fix it? I think it's a pretty common case going forward that the network 
supports a combination of IPv4, DS and IPv6 devices being connected even 
to a wifi network or LAN (not necessarily mobile). Then one doesn't have 
the choice to have different APNs.

One way would be to have a recommendation to detect NAT64 and then detect 
NAT44, and in the case of both being present, prefer one of them 
consistently?

Hardest case to handle would be GUA IPv4 and IPv6 with NAT64, then there 
would have to be heuristics to actively detect the DNS64 doing A->AAAA and 
not use the AAAA pointing to the NAT64 prefix, but instead use A records 
for those.... if that's what we want.

---

From: Tore Anderson <[email-masked]>
Date: Wed, 20 Nov 2013 10:16:21 +0100

* Lorenzo Colitti

> On Thu, Nov 14, 2013 at 5:55 PM, Tore Anderson <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> But then if you have IPv6-only with 464xlat you end up preferring
> 464xlat over NAT64.

True, although the question was about dual-stack UEs with native IPv4.

I suppose that if one additionally has to support single-stack UEs with
NAT64/464XLAT one can't have it both ways, unless those UEs modify their
RFC6724 policy table to add a separate low-precedence entry for the
464XLAT address (and possibly one for the NAT64 prefix as well).

But then again, it might not matter much these days, as it becomes more
and more uncommon to provision UEs with native IPv4.

Tore

---

From: Simon Perreault <[email-masked]>
Date: Wed, 20 Nov 2013 10:18:57 -0500

Le 2013-11-20 03:09, Mikael Abrahamsson a écrit :
> One way would be to have a recommendation to detect NAT64 and then
> detect NAT44, and in the case of both being present, prefer one of them
> consistently?

The current state-of-the-art in NAT traversal expressly discourages this 
kind of one-size-fits-all discovery. You need to think about NAT on a 
per-flow basis, not on a per-host basis. The presence or kind of NAT 
that you will discover may depend on IP source or destination, transport 
protocol, port number, load on the NAT device, time of day, phase of the 
moon, etc.

ICE for every flow? Built into the OS? Yuck!

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Simon Perreault <[email-masked]>
Date: Wed, 20 Nov 2013 10:21:41 -0500

> protocol, port number, load on the NAT device, time of day, phase of the

I forgot to finish my thoughts: but it might be good enough if we scope 
what we want to accomplish with discovery tightly enough. For example, 
using the information for prioritization in happy eyeballs might be more 
than fine.

Simon

---

From: <[email-masked]>
Date: Sat, 30 Nov 2013 23:54:03 +0100

Hi Mikael,

sorry for the late reply. 

What I am thinking: Should the network be set up to offer an unabiguous access method to the end device , or should the end device be able to detect the "Internet Access toolset" (public IPv4, private IPv4 with NAT, NAT64, native IPv6) that the network it is connected to offers and pick the most appropriate methods by itself?

I am fearing that we get into a similar trouble as with SIP when using NAT/PAT, which failed because the client, NAT gateway and/or SIP server tried to fix the NAT/PAT translation in SIP signalling sometimes by only by "guessing"?

Holger

-----Ursprüngliche Nachricht-----
Von: Mikael Abrahamsson [mailto:[email-masked]] 
Gesendet: Mittwoch, 20. November 2013 09:09
An: Metschulat, Holger
Cc: [email-masked]
Betreff: Re: AW: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt

> I agree, but are there any other choices?

We could provide the problem case and have "someone" develop standards to fix it? I think it's a pretty common case going forward that the network supports a combination of IPv4, DS and IPv6 devices being connected even to a wifi network or LAN (not necessarily mobile). Then one doesn't have the choice to have different APNs.

One way would be to have a recommendation to detect NAT64 and then detect NAT44, and in the case of both being present, prefer one of them consistently?

Hardest case to handle would be GUA IPv4 and IPv6 with NAT64, then there would have to be heuristics to actively detect the DNS64 doing A->AAAA and not use the AAAA pointing to the NAT64 prefix, but instead use A records for those.... if that's what we want.