Re: [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

[Ole Troan <[e-mail]>]

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

While that is correct, you can build endpoint dependent NATs that are extremely efficient when it comes to port utilisation.
(Reusing the same port for communication to different end systems).

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

This is incorrect. MAP-T IPv6 traffic is just as 'normal' as 464XLAT IPv6 packets.

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

On the PE side, stateful NAT64 is a lot more complex than any of the MAPs. While MAP-T is somewhat more complex (in number of lines of code) than MAP-E.
You have logging considerations as well as much more complex scaling. Scaling a MAP system is trivial. Scaling a stateful NAT system quickly requires state synchronisation between systems.

On the CPE side complexity is similar. NAT44 -> NAT46 or NAT44 -> tunnel. (Actually the 464XLAT case where even the second NAT is stateful is worse.

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

Yes. At the benefit of transparency and simplicity. 464XLAT/MAP-T adds 20 bytes, encap another 20.
> 
> 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?

Please don't call these IPv6 transition solutions.
These solutions are about keeping IPv4 alive a little longer.

The main "benefit" of 464XLAT is two-fold. It was lighter on provisioning than e.g. MAP-E or MAP-T and it could reuse a stateful NAT64, which could serve IPv6 only hosts reaching the IPv4 Internet.
How easy it is to provision 464XLAT or NAT64 to a CE device has in hindsight been shown to be arguable.

Cheers,
Ole