Excerpts from Brian E Carpenter on Tue, Dec 02, 2008 12:02:25PM +1300:
1. We know of no alternative to a longest-match based approach to
routing lookup for the inter-AS routing system (commonly known as
the DFZ).
2. To control the long-term scaling of that approach, we need to
control the long-term size of the lookup table and the long-term
rate of dynamic updates to that table.
3. We assume there will be continued unbounded growth in the number
of sites requiring multihoming, but today each site that requires
multihoming thereby requires its own entry in the DFZ lookup table.
In the long term, this is unsustainable. [Digression about numbers
and dates omitted.]
4. The known solutions to this all require some mechanism for
aggregating site prefixes into ISP prefixes. [There's space for a
digression about the related advantages of separating the transport
ID from the network address, and about the application layer's view
of all this, but that doesn't affect what I just said.]
5. One solution to that is a multi-prefix model (a site runs
multiple prefixes), which is of course the IPv6 design assumption.
Another solution is a map-and-encap model. A third solution is a
map-and-translate model. There are many variants of all these
models, but I don't know of a fourth one. All solutions have
advantages and disadvantages.
All good but
IMHO the reason we're hearing about NAT66 is because people
still find the IPv6 multi-prefix model unfamiliar and there is
no consensus-based map-and-encap solution yet. So it's natural
to look at map-and-translate, and NAT66 is one of the solutions
in that category.
My suspicion is that it's seen as easier to deploy, right now. Show
me your IPv6 multiprefix deployments, now show me your NAT
deployments. And NAT66 is just NAT, right?
Scott
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf