[Lista ArNOG] [lacnog] Fwd: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas

Lun Jun 11 11:59:05 ART 2018

Gracias Fernando!

El problema viene en este caso porque el responsable de desarrollo de Android, se niega *por defecto* a cualquier cosa que implique DHCPv6, que, además, ellos se niegan a soportar ...

En España decimos "es como el perro del hortelano, que ni come ni deja comer", supongo que se entiende.

Si no soportas DHCPv6, entonces porque te niegas a que se soporte una opción (que además NO supone ningún desarrollo nuevo, solo que IANA le asigne un "número" de opción) para que un ISP pueda tener clientes con diferentes mecanismos de transición (464XLAT, DS-LITE, lw4o6, MAP-E, MAP-T) y le pueda decir a cada "CPE" tu usas este, o ahora usas aquel, etc., o bien pasar de un mecanismo a otro, o pasar de tener dual-stack a solo-IPv6 con IPv4 con transición, etc., etc.

Esto es dentro del trabajo de v6ops para definir los requisitos de los CPEs:

https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/

Saludos,
Jordi

-----Mensaje original-----
De: LACNOG <lacnog-bounces en lacnic.net> en nombre de Fernando Gont <fgont en si6networks.com>
Responder a: Latin America and Caribbean Region Network Operators Group <lacnog en lacnic.net>
Fecha: lunes, 11 de junio de 2018, 16:34
Para: "lactf en lacnic.net" <lactf en lacnic.net>, Latin America and Caribbean Region Network Operators Group <lacnog en lacnic.net>, <lista en arnog.com.ar>
Asunto: [lacnog] Fwd: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas

    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 en dmarc.ietf.org>
    To: 	Lorenzo Colitti <lorenzo=40google.com en dmarc.ietf.org>
    CC: 	v6ops en ietf.org WG <v6ops en 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 en ietf.org> en nombre de Lorenzo Colitti
    <lorenzo=40google.com en dmarc.ietf.org>
    *Fecha: *domingo, 10 de junio de 2018, 13:17
    *Para: *<jordi.palet=40consulintel.es en dmarc.ietf.org>
    *CC: *"v6ops en ietf.org WG" <v6ops en 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 en dmarc.ietf.org
    <mailto:40consulintel.es en 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 en 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.

    _______________________________________________
    LACNOG mailing list
    LACNOG en lacnic.net
    https://mail.lacnic.net/mailman/listinfo/lacnog
    Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog

**********************************************
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.