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

[Lorenzo Colitti <[e-mail]>]

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=
[e-mail]> 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 <[e-mail]> en nombre de Lorenzo Colitti
> <lorenzo=[e-mail]>
> *Fecha: *miércoles, 13 de junio de 2018, 4:45
> *Para: *<jordi.palet=[e-mail]>
> *CC: *"[e-mail] WG" <[e-mail]>
> *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=
> [e-mail]> 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
> [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.
>
>