Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info)

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, JORDI PALET M
ARTINEZ writes:
> You can have a DNS validator, aware of DNS64.
>
> In the worst case, if you dont like having a DNS validator aware of
> DNS64, a much simpler solution is to NOT use DNS64.
>
> 464XLAT works also in that scenario, you just force all the IPv4-only
> traffic to be translated at both sides the CLAT and the PLAT. This is not
> worse than when you do NAT44.
>
> As this traffic is going to be less and less IPv4, again this is not an
> issue.
>
> Regards,
> Jordi

Please go and re-read what is below.  You cannot discover the prefix
using correctly configured DNS software as things currently stand.

Now if you tell IANA to add a insecure delegation for ipv4only.arpa
one can discover the prefix but as things currently stand it is
impossible.

Mark

> -----Mensaje original-----
> De: v6ops <[e-mail]> en nombre de Mark Andrews
> <[e-mail]>
> Responder a: <[e-mail]>
> Fecha: jueves, 28 de septiembre de 2017, 9:42
> Para: Mikael Abrahamsson <[e-mail]>
> CC: "Heatley, N, Nick, TQB R" <[e-mail]>, IPv6 Ops WG
> <[e-mail]>, james woodyatt <[e-mail]>
> Asunto: Re: v6ops 464xlat case study (was reclassify 464XLAT as standard
> instead of info)
>
>
>     In message <[e-mail]>,
> Mikael Abrah
>     amsson writes:
>     > So while I sympathize your "breaks DNSSEC" objection, 464XLAT
> actually
>     > doesn't do that. DNS64 does. If all devices had 464XLAT then you
> wouldn't
>     > have to do DNS64 (apart from the well-known "prefix detection"
> zones.
>
>     You do know the RFC 7050 doesn't work with DNSSEC validation enabled.
>     RFC 7050 specifies CD=0.
>
>         ipv4only.arpa/AAAA (CD=0) -> validating recursive server
>     			         (or local validating cache)
>         ipv4only.arpa/AAAA (CD=0) -> DNS64 server
>         ipv4only.arpa/AAAA ANCOUNT>0 -> validating recursive server
>     			        (or local validating cache)
>
>                     rejected as ipv4only.arpa is signed.
>
>         SERVFAIL -> client
>
>     Lets try with CD=1
>
>         ipv4only.arpa/AAAA (CD=1) -> validating recursive server
>     			         (or local validating cache)
>         ipv4only.arpa/AAAA (CD=1) -> DNS64 server (no synthesis as CD=1)
>         ipv4only.arpa/AAAA ANCOUNT=0 -> validating recursive server
>     			            (or local validating cache)
>         ipv4only.arpa/AAAA ANCOUNT=0 -> client (no prefixea found)
>
>     To get it to work the validating recursive server has to detect
>     that prefix discover is occuring.  Perform its own prefix discovery.
>     Synthesis a prefix discover response.
>
>     So yes 464XLAT does require DNSSEC to be broken.
>
>     Mark
>     --
>     Mark Andrews, ISC
>     1 Seymour St., Dundas Valley, NSW 2117, Australia
>     PHONE: [phone]                 INTERNET: [e-mail]
>
>     _______________________________________________
>     v6ops mailing list
>     [e-mail]
>     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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]