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

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 <lencse@hit.bme.hu> 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=
> 40consulintel.es@dmarc.ietf.org> 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 <v6ops-bounces@ietf.org> en nombre de Lorenzo Colitti
>> <lorenzo=40google.com@dmarc.ietf.org>
>> *Fecha: *miércoles, 13 de junio de 2018, 4:45
>> *Para: *<jordi.palet=40consulintel.es@dmarc.ietf.org>
>> *CC: *"v6ops@ietf.org WG" <v6ops@ietf.org>
>> *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=
>> 40consulintel..es@dmarc.ietf.org <40consulintel.es@dmarc.ietf.org>>
>> 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
>> v6ops@ietf.org 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 listv6ops@ietf.orghttps://www.ietf.org/mailman/listinfo/v6ops
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>