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

[Lorenzo Colitti <[e-mail]>]

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?