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

[JORDI PALET MARTINEZ <[e-mail]>]

I don’t think is fair to judge if 464XLAT is better or worse than other transition mechanism because it was not included in RFC8026 …

 

By the way, I realized also that some CLAT implementations are taking by default the NAT64 WKP (64:ff9b::/96, and other prefixes can be manually configured by GUI or CLI), so in fact, one more example that DNS64 is not needed and you may not need to implement at all RFC7050 neither RFC7225, so one more reason for requiring this change.

 

Note that I’m not saying is good a CLAT with by default the WKP NAT64, because it means the operator is forced to use the WKP, however, I ‘ve the feeling that in 99% of the NAT64 deployments is done that way ...


Regards,

Jordi

 

 

 

De: v6ops <[e-mail]> en nombre de Lorenzo Colitti <lorenzo=[e-mail]>
Fecha: miércoles, 13 de junio de 2018, 9:39
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

 

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.

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