Subject: [v6ops] Request for your two cents: Pros and Cons of IPv6 Transition Technologies for IPv4aaS (464XLAT, DS-Lite, lw4o6, MAP-E, MAP-T)

From: Lencse Gábor <[email-masked]>
Date: Mon, 17 Sep 2018 16:55:49 +0200

Dear v6ops Members,

With Jordi, Lee and Richard, we have put together a table about the 
advantages and disadvantages of the five IPv4aaS technologies (464XLAT, 
DS-Lite, lw4o6, MAP-E, MAP-T), which can serve as a starting point for 
collecting further information. It can be edited by anyone using the 
following URL:

https://docs.google.com/spreadsheets/d/1W3Px8I_RyLA_tnmmNkJj6qJS0tvg93oCU0XfZzlljto/edit#gid=0

For archival purposes, I copy here its current content:

Aspect 	464XLAT 	DS-Lite 	lw4o6 	MAP-E 	MAP-T 	
	Key 	Meaning
Tunnel (T) / Translation (X) ((neither pro nor con)) 	X (46, 64) 	T 
(4in6) 	T (4in6) 	T (4in6) 	X (46, 64) 	
	+ 	Positive
Can carry any protocol, not only TCP/UDP/ICMP 	- 	+ 	+ 	- 	- 	
	- 	Negative
The following header fields are changed 	

	| 	Neutral
- TCP/UDP source port number 	may be replaced 	may be replaced 
restricted 	restricted 	restricted 	
	/ 	Not Applicable
- IP version, source and destination addresses 	4-->6-->4 	/ 	/ 	/ 
4-->6-->4 	

- fields for fragmantation
(DF, MF, fragment offset, identification) 	discarded at
4-->6 translation 	/ 	/ 	/ 	discarded at
4-->6 translation 	

- IP options 	discarded? 	/ 	/ 	/ 	discarded? 	
I think it depends on the implementation if they are discarded or not

- further fields shoud go here 	

	
	
port number efficiency (for ISPs) 	+ 	- 	- 	- 	- 	

unlimited number of ports for users, when used
for public IPv4 address sharing 	+ 	- 	- 	- 	- 	

can keep source port numbers unmodified, when used
without public IPv4 address sharing 	+ 	- 	- 	+ 	+ 	
I think is is implementation dependent, at least in the case of NAT64

Translation at ISP with or without state 	with 	with 	/ 	w/o 	w/o 	

stateless (num. of states may not cause scalability issue) 	- 	- 	+ 	+ 	+ 	

allows unsolicited inbound connections 	- 	
	
	+ 	+ 	
I think is is implementation dependent, at least in the case of NAT64

overhead (Bytes) 	20 	40 	40 	40 	20 	

Impact in IPv6 addressing plan 	no (+) 	no (+) 	no (+) 	yes (-) 	yes (-) 	

backbone traffic is like normal IPv6 traffic 	+, but not exactly {1} 	- 
- 	- 	+, but not exactly {1} 	

logging 	flow/block 	flow/block 	algorithmic 	algorithmic 	algorithmic 	

Client support in Windows 10 	+ 	- 	- 	- 	- 	
Arguably all the other columns should be marked as N/A as opposed to a 
negative?

Client support in Linux 	+ 	- 	- 	- 	- 	
It does raise the question about comparing "end-host"-based methods with 
network-based ones.

Client support in Android 	+ 	- 	- 	- 	- 	
Jordi: From the perspective of "how good is the support" is "-" not N/A 
- For example, if a mechanism is not supported in cellular phones, then 
is a bad option for an ISP to choose it!

Client support in iOS 	- 	- 	- 	- 	- 	

Client support in Windows Mobile 	+ 	- 	- 	- 	- 	

Client support in Chrome OS 	+ 	- 	- 	- 	- 	

Client support in MacOS 	- 	- 	- 	- 	- 	

OpenWRT CPE code in kBs (lower is better) 	17 	15 	35 	35 	48 	

DNS mangling / synthesizing 	- 	
	/ 	/ 	/ 	
Jordi: This is not true. You can deploy 464XLAT with or without DNS64 
see draft-palet-v6ops-nat64-deployment and also the 464XLAT explains it

BR/AFTR Bypass for CDN 	
	/ 	/ 	/ 	+ 	
I think this is applicable to every transition mechanism, so no need for 
this raw as all can do it

Support in cellular networks 	+ 	- 	- 	- 	- 	

Danger of DNS cache poisoning 	somewhat {2} 	somewhat {2} 	high {2} 
high {2} 	high {2} 	

- further aspects should go here 	

	

	

	
Area for footnotes (please use numbers in braces) 	

	
	
{1} Both 464XLAT and MAP-T change the distribution of the port numbers, 
thus they may break the port number rules for RTP (even number) and the 
corresponding RTP (next odd number), see RFC 3605 Section 3.2. How much 
important is that ? Why is not key for cellular?

	

{2} For all five technologies, CE device SHOULD contain a DNS proxy. 
However, the user may change DNS settings. The restricted port set of 
lw4o6, MAP-E and MAP-T makes these techologies less resilient against 
cache poisoning, see RFC 5452.

	

This table is surely neither complete nor error free: This is why we ask 
your help.

As it became evident from the many mails concerning 
draft-ietf-v6ops-transition-ipv4aas (see some of them below) that 
neither of the above 5 technologies are better than all the others in 
all aspects. Perhaps one if them is the best choice for a given 
communication scenario, but another one is much better for another 
scenario. Therefore, an Internet Draft based on a more complete version 
of the table could server as a good selection guide for network operators.

Depending on how much and fast you will contribute, we would like to put 
together the initial version of the draft either for IETF 103 or IETF 104.

Thank you very much for your help in advance,

Best regards,

Gábor

6/19/2018 10:29 AM keltezéssel, Richard Patterson írta:
> Hi Lencse,
>
> I'd be happy to help also.
>
> -Richard
> On Tue, 19 Jun 2018 at 08:09, Lencse Gábor <[email-masked]> wrote:
>> Dear Lee,
>>
>> Thank you very much for offering your help and participation. I have decided to write the draft and I invite you to be a co-author.
>>
>> Are there some other people, who would like to join us?
>>
>> I plan to put together a table with the information extracted from past e-mails on the list and send it to Lee (and possibly other participants) first, and send the Google docs URL to the list after we agreed on its initial content.
>>
>> Best regards,
>>
>> Gábor
>>
>>
>> 6/18/2018 4:38 PM keltezéssel, Lee Howard írta:
>>
>> Apparently I'm a week late on this thread. Sorry.
>>
>> I think an internet-draft in this case would be useful for reflecting the current best knowledge about the technologies. Even if it takes two years or more to publish, a draft is useful to collect  and summarize the detailed academic papers being published, and the structure of writing the draft will help point out areas where further research is needed.
>>
>> I'm also interested in supporting this work, up to and including working with your students,  providing my own test results, and/or co-authoring.
>>
>> Lee
>>
>>
>> On 06/15/2018 10:04 AM, JORDI PALET MARTINEZ wrote:
>>
>> I’m not sure it makes sense something that is not published in, let’s say, maximum one year from now.
>>
>>
>>
>> Anyway, I’m happy to help.
>>
>>
>>
>> By the way, I got some private questions about this … The table that I’ve posted yesterday, was developed about 3 years ago, and I’ve not updated it since them. Actually from emails exchanged today, I discovered a couple of mistakes and also things that can be improved, so if needed I can update it as well.
>>
>>
>> Regards,
>>
>> Jordi
>>
>>
>>
>>
>>
>>
>>
>> De: v6ops <[email-masked]> en nombre de Lencse Gábor <[email-masked]>
>> Fecha: viernes, 15 de junio de 2018, 14:25
>> Para: Fred Baker <[email-masked]>
>> CC: <[email-masked]>
>> Asunto: [v6ops] Pros and Cons of IPv6 Transition Technologies for IPv4aaS -- Re: no need to update RFC8026 in draft-ietf-v6ops-transition-ipv4aas
>>
>>
>>
>> Dear Fred,
>>
>> Thank you very much for your invitation. I am willing to accept it, but I would like to clarify your expectations before saying 'yes'.
>>
>> I have several questions.
>>
>> 1. Depth of the analysis
>>
>> - Basic level: well-known advantages and disadvantages, similarly as people wrote about MAP-T/E and 464XLAT, but also about DS-Lite and lw4o6.
>> - Advanced level: basic level + security analysis using the methodology defined in [1] + performance analysis according to RFC 8219.
>>
>> What depth do you recommend?
>>
>> 2. Method for getting the results and their publication
>>
>> As for the information for the basic level, I would prepare a google docs table, fill in the information I have and send the link to the v6ops list asking contributions.
>> After commenting and discussing, I would compile it to an I-D.
>>
>> Do you think that v6ops WG would finally agree to publish it as an RFC?
>>
>> As for the information for the advanced level, I would work together with my students and PhD students, and publish our results first in academic papers and then include their most important lessons into the I-D.
>>
>> What do you think of it?
>>
>> 3. Timeline
>>
>> I think that I could put together the first table in a few weeks. The contribution of the v6ops list members and the discussion could be done in a few months and then I could compile the results into an I-D in a few weeks. Perhaps, it could be presented at IETF 103.
>>
>> The further parts would require much more time and results could be included gradually in 1-2 years.
>>
>> 4. Scope
>>
>> The smallest natural scope includes the technologies for IPv4AAS, that is: 464XLAT, DS-Lite, MAP-T/E and lw4o6.
>>
>> IPv6 transition technologies for other carefully selected scenarios might also be included. E.g. I have significant amount of results in benchmarking DNS64 servers, having a testing tool [2], a well defined methodology [3] and ready to use results concerning the DNS64 performance of BIND, PowerDNS and Unbound [4].
>> One of my PhD students is currently benchmarking some sateless NAT64 implementations according the the dual DUT setup of RFC 8219 using an RFC 2544 compatible Tester. Another PhD student is currently working on a RFC 8219 compliant NAT64 tester program (using DPDK) to be able to perform single DUT setup NAT64 benchmarking tests.
>>
>> Thus, the scope can be widened, if you would like to.
>>
>> What do you think about my recommendations?
>>
>> Best regards,
>>
>> Gábor
>>
>> References:
>>
>> [1] G. Lencse and Y. Kadobayashi, "Methodology for the identification of potential security issues of different IPv6 transition technologies: Threat analysis of DNS64 and stateful NAT64", Computers & Security (Elsevier), vol. 77, no. 1, pp. 397-411, August 1, 2018, DOI: 10.1016/j.cose.2018.04.012
>>
>> [2] G. Lencse, D. Bakai, "Design and implementation of a test program for benchmarking DNS64 servers", IEICE Transactions on Communications, vol. E100-B, no. 6. pp. 948-954, June 2017. DOI: 10.1587/transcom.2016EBN0007
>>
>> [3] G. Lencse, M. Georgescu, and Y. Kadobayashi, "Benchmarking Methodology for DNS64 Servers", Computer Communications (Elsevier), vol. 109, no. 1, pp. 162-175, September 1, 2017, DOI: 10.1016/j.comcom.2017.06.004
>>
>> [4] G. Lencse and Y. Kadobayashi, "Benchmarking DNS64 Implementations: Theory and Practice", Computer Communications (Elsevier), vol. 127, no. 1, pp. 61-74, September 1, 2018, DOI: 10.1016/j.comcom.2018.05.005
>>
>> 6/14/2018 10:42 PM keltezéssel, Fred Baker írta:
>>
>>
>>
>> On Jun 14, 2018, at 1:15 PM, Lencse Gábor <[email-masked]> wrote:
>>
>> I have an idea: perhaps you could add a section about the pros and cons of each transition technology covered by the draft. (It could be helpful for the network operators when selecting the technology matching their need the best. However, I am not sure whether it is in the scope of this draft.)
>>
>> It would be incredibly useful. That said, it often involves value judgements, which are essentially in the eye of the beholder.
>>
>>
>>
>> We have had a recent thread regarding 464xlat and MAP-T. If I can say this without actually putting words into Lorenzo's mouth, his issues with translation in general are probably summarized in RFC 2993, and I would agree with him. The distinction between 464xlat and MAP-T you'll have to find in his emails; they are both services an ISP might deploy, and while they use the same tool (translation) they are not the same service. It seems to be generally agreed that MAP-T is more expensive to deploy than 464xlat; the question is what the extra expense buys, and whether someone agrees that the result is worth the cost.
>>
>>
>>
>> So in your proposed section, I would have to ask Jordi to not only say "MAP-T costs more to deploy than 464xlat", but gives the argument that might lead someone to choose MAP-T.
>>
>>
>>
>> And then we get to the large variety of other technologies, some of which presume an IPv4 core network and some an IPv6 core network (and none of which assume an MPLS core network carrying both kinds of traffic).
>>
>>
>>
>> If you would like to write such a document, please be my guest, by all means. But I'm not going to expect Jordi to do all that in the coming two weeks...
>>
>>
>> _______________________________________________ v6ops mailing list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>>
>>
>> **********************************************
>> IPv4 is over
>> Are you ready for the new Internet ?
>> http://www.consulintel.es
>> The IPv6 Company
>>
>> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
>>
>>
>>
>> _______________________________________________
>> v6ops mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>>
>>
>>
>> _______________________________________________
>> v6ops mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>>
>> _______________________________________________
>> v6ops mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Ole Troan <[email-masked]>
Date: Mon, 17 Sep 2018 20:29:01 +0200

Lencse,

I did a few corrections. You might want to split LW46, MAP-E and MAP-T into “shared address mode” and “full IPv4 address” and possibly IPv4 prefix.
Obviously the first have similar properties to the NAT solutions, while the non-sharing ones are transparent with regards to IP protocol.

A few comments below.

> for public IPv4 address sharing	+	-	-	-	-	

I am not sure what that means. Any solution depending on a CGN will be port restricted in some fashion. Otherwise the operator would open itself to an attack.

> I think is is implementation dependent, at least in the case of NAT64

What does this mean?

> Translation at ISP with or without state	with	with	/	w/o	w/o	

MAP-E should be changed to “/“

> Impact in IPv6 addressing plan	no (+)	no (+)	no (+)	yes (-)	yes (-)	

Perhaps rename this to “IPv4 addresses are dependent on IPv6 addressing"

> backbone traffic is like normal IPv6 traffic	+, but not exactly {1}	-	-	-	+, but not exactly {1}	
> 
> 
> Arguably all the other columns should be marked as N/A as opposed to a negative?
> 
> 
> It does raise the question about comparing "end-host"-based methods with network-based ones.
> 
> 
> Jordi: From the perspective of "how good is the support" is "-" not N/A - For example, if a mechanism is not supported in cellular phones, then is a bad option for an ISP to choose it!
> 
> 
> Jordi: This is not true. You can deploy 464XLAT with or without DNS64 see draft-palet-v6ops-nat64-deployment and also the 464XLAT explains it
> 
> 
> BR/AFTR Bypass for CDN	
> /	/	/	+	
> I think this is applicable to every transition mechanism, so no need for this raw as all can do it

What does this mean? As in IPv4 translated to IPv6 can talk directly to IPV6 services within the network? If so only MAP-T and 464XLAT can do that.

> Support in cellular networks	+	-	-	-	-	

Cause cellular networks are not part of the Internet?

> Danger of DNS cache poisoning	somewhat {2}	somewhat {2}	high {2}	high {2}	high {2}	

See below.

> {1} Both 464XLAT and MAP-T change the distribution of the port numbers, thus they may break the port number rules for RTP (even number) and the corresponding RTP (next odd number), see RFC 3605 Section 3.2. How much important is that ? Why is not key for cellular?

DS-lite and 464XLAT uses whatever policy is set on the CGN.
LW46, MAP-T and MAP-E uses the PSID algorithm which does allocate multiple subsequent ports for this purpose.
Of course no modern RTP application depend on this behaviour any more.

> {2} For all five technologies, CE device SHOULD contain a DNS proxy. However, the user may change DNS settings. The restricted port set of lw4o6, MAP-E and MAP-T makes these techologies less resilient against cache poisoning, see RFC 5452.

a) why SHOULD CE devices contain a DNS proxy?
b) if it did, it would use IPv6 transport of course, and the problems you outline do not exist.

> 
> This table is surely neither complete nor error free: This is why we ask your help.
> 
> As it became evident from the many mails concerning draft-ietf-v6ops-transition-ipv4aas (see some of them below) that neither of the above 5 technologies are better than all the others in all aspects. Perhaps one if them is the best choice for a given communication scenario, but another one is much better for another scenario. Therefore, an Internet Draft based on a more complete version of the table could server as a good selection guide for network operators. 
> 
> Depending on how much and fast you will contribute, we would like to put together the initial version of the draft either for IETF 103 or IETF 104.
> 

Ole

---

From: Lee Howard <[email-masked]>
Date: Mon, 17 Sep 2018 16:33:43 -0400

>> I think is is implementation dependent, at least in the case of NAT64

Some NAT devices rewrite the layer 4 source port. Presumably, this is 
because multiple devices inside the NAT might use the same source port 
number. Rewriting the source port isn't required if you aren't doing 
IPv4 address sharing; does the mechanism still rewrite it?

> MAP-E should be changed to “/“
How is MAP-E different from MAP-T with regard to state at the ISP? (I 
think they're both stateless and should say w/o, but I may be confused).

> Cause cellular networks are not part of the Internet?
I think this is an observation of what mechanisms are currently 
supported in cellular architectures.
There's nothing preventing a DS-Lite B4 or MAP client implementation on 
a mobile device, but I don't know of any. As operational advice, I would 
advise an operator to deploy something that exists. :)

Is this not relevant, do you think?

Lee

---

From: Mark Andrews <[email-masked]>
Date: Tue, 18 Sep 2018 10:33:55 +1000

Requires using ISP’s recursive servers

Yes, No, No, No, No

We don’t yet have a NAT64 prefix discovery mechanism for 464XLAT that 
doesn’t use the DNS.  This is not the same as requiring DNS64.  The
mapping can be in a locally served IPV4ONLY.ARPA zone (note this has
all the same DNSSEC issues as DNS64 because IANA’s IPV4ONLY.ARPA zone
is signed and securely delegated).

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Ole Troan <[email-masked]>
Date: Tue, 18 Sep 2018 09:24:03 +0200

> Some NAT devices rewrite the layer 4 source port. Presumably, this is because multiple devices inside the NAT might use the same source port number. Rewriting the source port isn't required if you aren't doing IPv4 address sharing; does the mechanism still rewrite it?

I wonder if it would be cleaner to split out non IPv4 sharing modes into separate columns. Because they behave quite differently.
With regards to protocol transparency (TCP, UDP, ..) with regards to fragmentation behaviour and so on. What thinks?

> How is MAP-E different from MAP-T with regard to state at the ISP? (I think they're both stateless and should say w/o, but I may be confused).

I just triggered on the word “Translation” and why LW46 had a / while MAP-E had a w/o.
There isn’t a difference between MAP-E and LW46 here.

> I think this is an observation of what mechanisms are currently supported in cellular architectures.
> There's nothing preventing a DS-Lite B4 or MAP client implementation on a mobile device, but I don't know of any. As operational advice, I would advise an operator to deploy something that exists. :)
> 

I think it might just have been phrasing. It isn’t the cellular architecture (or specifications), but client support. Which of course is important.

Cheers,
Ole

---

From: Lee Howard <[email-masked]>
Date: Tue, 18 Sep 2018 11:19:44 -0400

I agree with what you say here, and think that if this proceeds to a 
draft we should include these notes and distinctions.

Lee

---

From: Lee Howard <[email-masked]>
Date: Tue, 18 Sep 2018 11:23:23 -0400

> is signed and securely delegated).
As I think about it, Google has public DNS64 servers that return a 
synthesized address using the WKP 64:ff9b::/96. So you might not be 
required to use the ISP's DNS (if the ISP uses the WKP).
Or, as you say, other DNS shenanigans.

Lee

---

From: Edwin Cordeiro <[email-masked]>
Date: Tue, 18 Sep 2018 17:58:26 +0200

I did an analysis on some of the techniques a few years ago, not sure if it
would still be useful:
http://edwin.scordeiro.net/wp-content/uploads/2016/04/ComparisonBetweenIPv4toIPv6TransitionTechniques.pdf

In the unlikely case you speak Portuguese all the details are available at:
http://edwin.scordeiro.net/wp-content/uploads/2016/04/Edwin_Cordeiro_Mestrado_IPT.pdf

Edwin Cordeiro

---

From: Simon Hobson <[email-masked]>
Date: Tue, 18 Sep 2018 20:06:35 +0100

Lee Howard <[email-masked]> wrote:

> Some NAT devices rewrite the layer 4 source port. Presumably, this is because multiple devices inside the NAT might use the same source port number.

Indeed, that is a requirement - though strictly speaking it's possible to share the same source address and port for different destination address/port pairs, the requirement is that the source address-port/dest address-port quartet needs to be unique.

As an aside, I've come across NAT implementations that deliberately change (randomise) source port even when not required. A right PITA when trying to get SIP devices to work - STUN finds one translation but the SIP connection gets given another. Thank you Zyxel with your "never mind what it breaks, it's secure" approach :-/

---

From: Fred Baker <[email-masked]>
Date: Tue, 18 Sep 2018 20:44:28 -0400

> On Sep 18, 2018, at 11:23 AM, Lee Howard <[email-masked]> wrote:
> 
> As I think about it, Google has public DNS64 servers that return a synthesized address using the WKP 64:ff9b::/96. So you might not be required to use the ISP's DNS (if the ISP uses the WKP).

Of course, if you have an ISP-supplied DNS server that is doing the same but with a different prefix, and you're overriding to the Google server, you have a protocol failure.

--------------------------------------------------------------------------------
Victorious warriors win first and then go to war,
Defeated warriors go to war first and then seek to win.
     Sun Tzu

---

From: Fred Baker <[email-masked]>
Date: Tue, 18 Sep 2018 20:45:05 -0400

Or for that matter, if your ISP has no translator at any prefix and you're using the Google server, you have an outage.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 19 Sep 2018 10:50:47 +1000

> On 19 Sep 2018, at 1:23 am, Lee Howard <[email-masked]> wrote:
> 
> 
> 

Which only works if your ISP is using the WKP which requires apiary knowledge (i.e. test your ISP’s nameservers or look it up on a web page).

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 19 Sep 2018 12:05:47 +0200

Thank you for this opportunity.

I added a column head called
'IPv4 and IPv6 side-by-side, or Double Stack'.

It is a way without any tunnelling, translation, routing header, 
explicit routing, DNS faking.

I have not yet filled the corresponding lines, and put 'TBD'.   Maybe later.

Alex

Le 17/09/2018 à 16:55, Lencse Gábor a écrit :
>> On Tue, 19 Jun 2018 at 08:09, Lencse Gábor<[email-masked]>  wrote:
>>> Dear Lee,
>>>
>>> De: v6ops<[email-masked]>  en nombre de Lencse Gábor<[email-masked]>
>>> Para: Fred Baker<[email-masked]>
>>> CC:<[email-masked]>
>>> On Jun 14, 2018, at 1:15 PM, Lencse Gábor<[email-masked]>  wrote:
>>>
>>> _______________________________________________ v6ops mailing [email-masked]  https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 19 Sep 2018 12:08:33 +0200

Le 18/09/2018 à 17:58, Edwin Cordeiro a écrit :
> I did an analysis on some of the techniques a few years ago, not sure if 
> it would still be useful:

In that paper there is photo of skype session on transition technologies.

Is skype now working on IPv6?

Alex

> On Tue, Sep 18, 2018 at 5:23 PM Lee Howard <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
> 
>     [email-masked] <mailto:[email-masked]>

---

From: Lee Howard <[email-masked]>
Date: Wed, 19 Sep 2018 09:51:30 -0400

As both you and Fred said. . .

> Which only works if your ISP is using the WKP which requires apiary knowledge (i.e. test your ISP’s nameservers or look it up on a web page).

Absolutely true.
Except I don't know what birds have to do with it.

I'm only pointing out that there is a way out of DNS capture by the ISP, 
so it doesn't *require* ISP's recursive resolvers, except in every 
instance known in production.

Lee

---

From: Lee Howard <[email-masked]>
Date: Wed, 19 Sep 2018 10:19:15 -0400

On 09/19/2018 06:08 AM, Alexandre Petrescu wrote:
>> I did an analysis on some of the techniques a few years ago, not sure 
>> if it would still be useful:

I started to test it (the web app, at least), but no AAAA for 
www.skype.com or web.skype.com
So, still no IPv6 support for Skype.

Lee

>>      > Requires using ISP’s recursive servers
>>      >
>>      > Yes, No, No, No, No
>>      >
>>      > We don’t yet have a NAT64 prefix discovery mechanism for 
>> 464XLAT that
>>      > doesn’t use the DNS.  This is not the same as requiring 
>> DNS64.  The
>>      > mapping can be in a locally served IPV4ONLY.ARPA zone (note 
>> this has
>>      > all the same DNSSEC issues as DNS64 because IANA’s 
>> IPV4ONLY.ARPA zone
>>      > is signed and securely delegated).
>>      >