[v6ops] Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas

Dear Lorenzo,

I think it is a rather strong statement that "464XLAT is pretty much the 
worse of the transition mechanisms from a technical perspective."

We have listed 26+ IPv6 transition technologies in our workshop paper 
[1], but there are even more solutions exist.

Which of them do you mean to be better than 464XLAT?

What technical points do you consider when stating that 464XLAT is worse 
than the others? (E.g. resource consumption, scalability, security, ease 
of implementation, etc.)

I think it is important for network operators to have a balanced view of 
the advantages and disadvantages of the different IPv6 transition 
mechanisms, this is why I am asking these questions.

Best regards,

Gábor Lencse

[1] G. Lencse and Y. Kadobayashi, "Survey of IPv6 Transition 
Technologies for Security Analysis", IEICE Communications Society 
Internet Architecture Workshop, Tokyo, Japan, Aug. 28, 2017, /IEICE 
Tech. Rep./, vol. 117, no. 187, pp. 19-24. Available online: 
http://www.hit.bme.hu/~lencse/publications/IEICE-IA-2017-survey.pdf

6/13/2018 9:38 AM keltezéssel, Lorenzo Colitti írta:
> That goes back to my earlier point of that from a technical 
> perspective 464xlat is pretty much the worst of the transition 
> mechanisms.. I don't think we should be recommending running it on 
> wireline at all, let alone prioritizing it over something else .:-)
>
> On Wed, Jun 13, 2018 at 3:50 PM JORDI PALET MARTINEZ 
> <jordi.palet=40consulintel.es@dmarc.ietf.org 
> <mailto:40consulintel.es@dmarc.ietf.org>> wrote:
>
>     Lorenzo, you’re missing the key aspect: Being able to prioritize,
>     when an ISP supports several transition mechanisms.
>
>     RFC8026 key aspect is priority. If we don’t add an option code for
>     464XLAT, then it can’t be managed the same way.
>
>
>     Regards,
>
>     Jordi
>
>     *De: *v6ops <v6ops-bounces@ietf.org
>     <mailto:v6ops-bounces@ietf.org>> en nombre de Lorenzo Colitti
>     <lorenzo=40google.com@dmarc.ietf.org
>     <mailto:40google.com@dmarc.ietf.org>>
>     *Fecha: *miércoles, 13 de junio de 2018, 4:45
>     *Para: *<jordi.palet=40consulintel.es@dmarc.ietf.org
>     <mailto:40consulintel.es@dmarc.ietf.org>>
>     *CC: *"v6ops@ietf.org <mailto:v6ops@ietf.org> WG" <v6ops@ietf.org
>     <mailto:v6ops@ietf.org>>
>     *Asunto: *Re: [v6ops] updating RFC8026 to support 464XLAT in
>     draft-ietf-v6ops-transition-ipv4aas
>
>     On Tue, Jun 12, 2018 at 7:40 PM JORDI PALET MARTINEZ
>     <jordi.palet=40consulintel..es@dmarc.ietf.org
>     <mailto:40consulintel.es@dmarc.ietf.org>> wrote:
>
>         You don’t need RFC7050 neither DNS64, you can use PCP
>         (RFC7225) to tell the CLAT the NAT64 prefix. It also provides
>         additional advantages to the operator to control many related
>         aspects (see section 3 of RFC7225).
>
>         1.If the operator wants to enable 464xlat: they should hand
>         out a DNS64 to the CPE.
>
>         2.If the operator wants to disable 464xlat: they should NOT
>         hand out a DNS64 to the CPE.
>
>         This doesn’t work, because the operator may be using RFC7225
>         instead of RFC7050. You need to try both in that case, and you
>         aren’t providing a “priority” to a possible list of
>         mechanisms, which is what RFC8026 does.
>
>     But it's the same problem again: what's the use case for this
>     DHCPv6 option? An operator that's using RFC7225 has an easy way to
>     tell the CPE not to do 464xlat: don't hand out the prefix64 to
>     those CPEs. So this is already possible today.
>
>         3.If the operator uses 464xlat, they should not allow the user
>         to change the DNS server.
>
>         Let’s be realistic. You can’t “force” the customer to avoid
>         changing the DNS …
>
>     On an operator-managed CPE, you can. On a user-managed CPE, you
>     can't. But on such a CPE you probably shouldn't be disabling
>     464xlat. If the user wants to use it, it's their CPE, right?
>
>     _______________________________________________ v6ops mailing list
>     v6ops@ietf.org <mailto:v6ops@ietf.org>
>     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
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops