[LAC-TF] Fwd: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas

[Fernando Gont]

FYI:

Aquellos que esten trabajando en despliegue de IPv6, o piensen hacerlo
es sugieron que participen de esta discusión.

Muchos de los problemas que Uds luego encuentran tienen mucho que ver
con no participar en las discusiones correspondientes a la hora en que
se escriben diversos documentos de IETF.

Slds, y gracias!
Fernando




-------- Forwarded Message --------
Subject: 	Re: [v6ops] updating RFC8026 to support 464XLAT in
draft-ietf-v6ops-transition-ipv4aas
Date: 	Sun, 10 Jun 2018 15:07:05 +0200
From: 	JORDI PALET MARTINEZ <jordi.palet=40consulintel.es at dmarc.ietf.org>
To: 	Lorenzo Colitti <lorenzo=40google.com at dmarc.ietf.org>
CC: 	v6ops at ietf.org WG <v6ops at ietf.org>



Hi Lorenzo,

 

There are now many ISPs that have 464XLAT in the celular, and they will
like to use the same mechanism for the wireline. This is very
convenient, if you are using also an LTE interface on a wireline router
as a backup of the wired link.

 

I don’t agree is the worst IPv4-in-IPv6 mechanism, in fact it is the
most successful one, thanks in part to Android and Windows having
implemented it.

 

The point is not to discover the NAT64, this is easily done, as you
indicated by using RFC7050 or even with PCP. This is already described
in the document.

 

The point is the ISP to be able to turn on or off each mechanism
(464XLAT, MAP, DS-Lite, etc.), and this is easily done if all them share
the same DHCP option.

 

I will like to understand if we still have such opposition, why.


Regards,

Jordi

 

 

 

*De: *v6ops <v6ops-bounces at ietf.org> en nombre de Lorenzo Colitti
<lorenzo=40google.com at dmarc.ietf.org>
*Fecha: *domingo, 10 de junio de 2018, 13:17
*Para: *<jordi.palet=40consulintel.es at dmarc.ietf.org>
*CC: *"v6ops at ietf.org WG" <v6ops at ietf.org>
*Asunto: *Re: [v6ops] updating RFC8026 to support 464XLAT in
draft-ietf-v6ops-transition-ipv4aas

 

On Sun, Jun 10, 2018 at 6:03 PM JORDI PALET MARTINEZ
<jordi.palet=40consulintel.es at dmarc.ietf.org
<mailto:40consulintel.es at dmarc.ietf.org>> wrote:

    So, the alternative I'm asking is, from a procedural point of view:
    Can v6ops WG, just include an update in
    draft-ietf-v6ops-transition-ipv4aas to add the option code for 464XLAT?

 

ISTR that the last time this was discussed in v6ops there was
substantial opposition to a DHCPv6 option for 464xlat.

 

To be honest, as a wireline ISP I don't see why you'd want to do 464xlat
at all. It's pretty much the worst of all the IPv4-over-IPv6
mechanisms.. Its only advantage is that it's easy to deploy on mobile
networks.

 

If you do want to do 464xlat, it's much better to do discovery using RFC
7050. That way, hosts behind the CPE can discover the NAT64 by
themselves, and do smart things like AAAA synthesis and DNSSEC, and also
provide input to their happy eyeballs mechanisms that IPv4 is not native
and thus may be less reliable.

_______________________________________________ v6ops mailing list
v6ops at 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.