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

[Lee Howard <[e-mail]>]

So you mean "stateful < stateless"?

I haven't looked recently at which packet headers get munged in what 
ways. Care to save us all half an hour of examining RFCs and tell us 
which ones?


Lee


On 06/13/2018 06:55 AM, Lorenzo Colitti wrote:
> 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.
>   * 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.
>   * 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.
>
>
> On Wed, Jun 13, 2018 at 6:12 PM Lencse Gábor <[e-mail] 
> <mailto:[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
>     <http://www.hit.bme.hu/%7Elencse/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]
>>     <mailto:[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]
>>         <mailto:[e-mail]>> en nombre de Lorenzo Colitti
>>         <lorenzo=[e-mail]
>>         <mailto:[e-mail]>>
>>         *Fecha: *miércoles, 13 de junio de 2018, 4:45
>>         *Para: *<jordi.palet=[e-mail]
>>         <mailto:[e-mail]>>
>>         *CC: *"[e-mail] <mailto:[e-mail]> WG"
>>         <[e-mail] <mailto:[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]
>>         <mailto:[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] <mailto:[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] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/v6ops
>
>     _______________________________________________
>     v6ops mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops