While you could do something similar without the encapsulation this
would require that every router on your network support routing on
port numbers, by using IPv6 packets it can be routed around your
network by existing routers. And it's not like anyone is going to be
deploying such a system without also deploying IPv6, so it's not
adding any additional requirements doing it that way.
Well, not really. As the video pointed out, the system was designed to leverage hierarchy to reduce routing complexity. Using the hierarchy, port number routing is only required at the level where a routes diverge on a port basis - which if you're being sensible about such a deployment would only be at the edge of the access layer.
You can avoid the giant NAT box as long as you don't have to add a new customer for whom you don't have an available IPv4 address.
At that point, you either have to implement the giant NAT box for your future (and possibly an increasing percentage of your existing) customers, or, stop adding new customers.
In terms of the CPE situation, until you solve that, IPv6-only isn't going to work for them, either, so the CPE issues simply can't be avoided no matter what. We need to find a way to get the vendors to make that float.
* Adrian Bool
While you could do something similar without the encapsulation
this would require that every router on your network support
routing on port numbers,
Well, not really. As the video pointed out, the system was designed
to leverage hierarchy to reduce routing complexity. Using the
hierarchy, port number routing is only required at the level where a
routes diverge on a port basis - which if you're being sensible about
such a deployment would only be at the edge of the access layer.
While that might be true, the access network would normally be the
largest part of an SP's network, when it comes to router count. The
access part might have 100s or 1000s of times more routers than the
core/border. The cone gets wider the closer to the customer edge you
get. Slide 6 illustrates this well.
By not doing translation or encapsulation of the IPv4 packets, instead
relying on the access routers to natively route based on A+P, we would
have made sure that the ISPs that have already deployed IPv6 could not
use the technology, and that ISPs that have not yet deployed IPv6 and
think the technology looks interesting have a huge incentive to put off
the entire project for several years, while they wait for new router
products or software images that support A+P to be made available. Not
There are also other problems with the idea - not only do you need the
router to be able to forward based on A+P, you would also need to
distribute these A+P routes in the network. Which means we would need to
update OSPFv2, IS-IS, or whatever else the SP might be using. We would
have to update DHCPv4 (both the protocol and the SP's server) too, as
there is currently no way it can give you a lease for a "partial" IPv4
address. This would also touch on layer 2 devices doing layer 3
inspection and policing, such as DHCP Snooping. You'd also need to
update ARP, as there is currently no way to send an "ARP who-has
192.0.2.1 port 1234" request, which you would have to do. The amount of
changes required is so large that you might as well call the result
IPv4� instead of MAP.
Finally, operating a single-stack network (regardless of that single
stack being IPv4 or IPv6) is much preferable to operating a dual-stack
one. Less complexity, less things to trouble-shoot, less things to set
up, less things to monitor, less things to train staff in, and so forth.
That MAP (and DS-Lite) means single-stack IPv6 in the vast majority of
the network is a very desirable trait, in my opinion. Your proposal
would remove this benefit, instead we'd end up with a dual-stack