Keith, With some reluctance, I have't changed your cc list. But my conclusion is that this particular discussion belongs on the RRG list as much as anywhere. On 2008-12-02 09:52, Keith Moore wrote: ... > (Because at present the "we need NATs for routing" argument looks, to my > intuition, a bit like handwaving. I don't think that is quite the argument. It is more like this: 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. 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. Brian _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf