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

[Lencse Gábor <[e-mail]>]

Dear Lorenzo,

Thank you very much for your answer.

For a balanced view, I think it is useful to point out that the MAP 
protocols have their disadvantages, too.

_1. Port numbers_

As Jordi has already pointed it out, one needs to dedicate a fix number 
of ports per CPE. Some advice that a few hundred will do for this value, 
but I think that it is not so simple:
- The lack of port situation may cause serious problems in the operation 
of certain programs, for more information see [1].
- The port number consumption of different applications is highly 
varying and e.g. in the case of web browsing it depends on several 
factors [2].
- There may be several users behind a CPE, especially in the wired case 
(e.g. Internet is used by different members of a family simultaneously), 
thus sometimes even a few thousands may not be enough.

Stateful NAT64 (used by 464XLAT) can use port numbers (and thus public 
IP addresses) much more economically.

_2. Complexity and security_

The operation of the MAP solution is rather complex, now I give only 
some highlights. Let us consider MAP-T. (MAP-E works similarly, but it 
uses encapsulation.) "First, the MAP-T CE (Customer Edge) device 
performs a NAT44 operation to restrict the available TCP/UDP port 
numbers for the user.  Then the CE device performs a special stateless 
translation from IPv4 to IPv6, where the source IPv4 address and the 
selected port bits are encoded into the source IPv6 address according to 
the MAP-T rules. The IPv6 packets can be destined to other users, where 
similar CEs perform the necessary transformations, or to the outside 
IPv4 Internet, in which case the MAP-T Border Relay performs the 
necessary transformations." [3]

This complexity has performance and security implications:
- Whereas the IPv6 backbone traffic of 464XLAT is normal IPv6 traffic, 
which can be inspected e.g. by firewalls, the IPv6 backbone traffic of 
MAP-T (as well as that of MAP-E) needs to be first "decoded", which 
causes further costs (both CAPEX and OPEX).
-  Complex code may contain more bugs and thus also security holes. (In 
the simplest model, the number of bugs is proportional to the number of 
code lines.)

_3. MAP-T and MAP-E are different_

On the one hand, if double translation may cause the loss of some IPv4 
fields (BTW: What exactly did you mean?), then it is also applies for MAP-T.
On the other hand, MAP-E uses encapsulation, which results in an 
overhead. An IPv6 header is at least 40 bytes, which may be a 
significant overhead in the case of small packets, e.g. TCP acknowledgments.

_4. What other IPv6 transition solutions did you also consider?_

As you have now mentioned only MAP,  I wonder what other solutions you 
could consider better than 464XLAT?

Best regards,

Gábor Lencse

References:
[1] S. Miyakawa, "IPv4 to IPv6 transformation schemes", IEICE Trans. 
Commun., vol.E93-B, no.5, pp.1078-1084, May 2010. 
DOI:10.1587/transcom.E93.B.1078
[2] S. Répás, T. Hajas, and G. Lencse, "Port number consumption of the 
NAT64 IPv6 transition technology", Proc. 37th Internat. Conf. on 
Telecommunications and Signal Processing (TSP 2014), Berlin, Germany, 
pp.66-72, Jul. 1-3, 2014. DOI: 10.1109/TSP.2015.7296411
[3] G. Lencse, Y. Kadobayashi, "Comprehensive survey of IPv6 transition 
technologies for security analysis", unpublished

6/13/2018 12:55 PM keltezéssel, Lorenzo Colitti írta:
> 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
>