Re: [v6ops] Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas

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

This always depends on your perspective, network, user requirements, etc. Different operators have different requirements.

 

Here are a few disadvantages of 464xlat:

·         It consumes lots of state on the NAT64 (one state table entry for every connection). MAP is much better since it uses port ranges.

Some ISPs care less about state and care more about having a better usage of each IPv4 address and providing as many ports as the users need automatically.

With NAT64, you have for each user as many ports as they need, nothing “extra” to configure for each user. With MAP you pre-define a number of ports per user.

·         It doesn't allow any inbound connections unless the NAT cooperates. MAP is better in the sense that you can at least receive connections within your port range.

Some ISPs don’t want inbound connections to be statically managed by users, they offer different services with different prices, etc. I’m not saying I agree with that. Even do, you have ways to cooperate with the NAT64, PCP, etc., to do that. Even for corporate users you can mix that with SIIT-DC or alike functions.

Inbound connections in your port range is useless for most of the users, or apps or devices, because they don’t allow other ports, and yes, you can sometimes play tricks with the CPE port forwarding, etc., etc.

·         The transformation is lossy because there are IPv4 header fields that cannot be translated. MAP-E is better because the encapsulation preserves the original packet header.

None of the transition mechanisms can be perfect, except probably dual-stack, but we know we can’t do dual-stack for every possible network, because we don’t have sufficient addresses, right?

Now, this has been said many times, and I don’t necessarily agree initially, but I’ve started to change my mind in the last few years. ***We DON’T WANT a perfect transition mechanism.***

We want some apps to fail, so indirectly it forces to developers and content providers to move them to IPv6.

So, all them are imperfect in one way or another, but having a single one, is much better, from all the perspectives that having many. Developers will fix easier anything for a single mechanism than for many, everything will happen faster, and of course, since 464XLAT is the one with has more users worldwide, it makes sense to push for that one everywhere, because the problems that the app developers find in the cellular world, will be sorted out, so those apps will be fixed for both, cellular and non-cellular.

Also, an operator with both, cellular and non-cellular networks, is very interested to support a single mechanism instead of two or more. Even an operator without a cellular network, many times need to provide backup by means of LTE and that means hybrid routers with both wired and LTE interfaces. It is much simpler to have a single mechanism for both, because even the cellular network is not its own network, it can use the same NAT64 (or the same outsourced one for both kind of connections).

I was not a fan of 464XLAT initially when it was developed, but market make me change my mind.

In summary, it all depends on your perspective, but if our goal is to push as much as possible for a higher % of IPv6-only traffic, I’m convinced cellular networks, which are the ones with higher % of penetration and growth, clearly defined the path that we must follow. 

 

On Wed, Jun 13, 2018 at 6:12 PM Lencse Gábor <[e-mail]> wrote:

Dear Lorenzo,

I think it is a rather strong statement that "464XLAT is pretty much the worse of the transition mechanisms from a technical perspective."

We have listed 26+ IPv6 transition technologies in our workshop paper [1], but there are even more solutions exist. 

Which of them do you mean to be better than 464XLAT?

What technical points do you consider when stating that 464XLAT is worse than the others? (E.g. resource consumption, scalability, security, ease of implementation, etc.)

I think it is important for network operators to have a balanced view of the advantages and disadvantages of the different IPv6 transition mechanisms, this is why I am asking these questions.

Best regards,

Gábor Lencse


[1] G. Lencse and Y. Kadobayashi, "Survey of IPv6 Transition Technologies for Security Analysis", IEICE Communications Society Internet Architecture Workshop, Tokyo, Japan, Aug. 28, 2017, IEICE Tech. Rep., vol. 117, no. 187, pp. 19-24. Available online: http://www.hit.bme.hu/~lencse/publications/IEICE-IA-2017-survey.pdf

6/13/2018 9:38 AM keltezéssel, Lorenzo Colitti írta:

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
 

_______________________________________________
v6ops mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/v6ops

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