On Mar 30, 2009, at 00:17, Mark Townsley wrote:
Certainly, if /48 service (along with a "compatible with IETF NAT66" bullet-point in the SLA) comes at a premium in terms of monthly service fees vs., say, a /56 or otherwise, then you've given an incentive to small router vendors to build something that allows one to get all the advantages of /48-type service with a /56 service contract. Voila, the vendor gets to reap the difference between the service fees for /48 vs. /56... Much like they did for a /32 vs. /30 (or "multiple IP" service) in IPv4.... see where I'm going with this?
This is the argument I attempted to make in the 6AI session in San Francisco last week when I ranted about how we're hand-waving away address amplification as a perceived benefit of NAT deployment for IPv6. I had hoped that hearing it come from a member in the engineering team for a line of small router products made by one of the major vendors in the market might help clarify the issue for some.
I also pointed out that this feature would be deployed by small router vendors to permit networks to obtain something like Internet connectivity from providers who restrict service only to hosts, i.e. those that do not delegate any prefix at all.
Anyone who thinks that captive network service providers (like, say, those serving hotel guests) won't eventually recognize there's a huge incentive for them to charge per host instead of per network demarcation point is willfully ignoring more than a century of telecommunications industry economic history. If one can't find any providers currently thinking that's how they'll sell IPv6 service, then it only means one hasn't asked the ones with mono- or oligopolistic market power.
Or one *has* asked them, they've quite naturally not told the truth, and for some unearthly reason, one has chosen to believe them anyway.
It would be very good if we could stop pretending that address amplification isn't among the reasons users could have for wanting to deploy NAT for IPv6. If the point of this exercise is to set a standard for 6AI before clueless router vendors do something that breaks the Internet for all time, then leaving support for address amplification out of the standard will only delay the inevitable damage you're trying to prevent.
We'll be writing a standard for a NAT that nobody uses, and the NATs that everyone will use will be the non-standard ones we're hoping to make unnecessary. How embarrassing will *THAT* be in retrospect?
If we can find a way for the standard to require A) that address realm gateways MUST implement RSIP servers and B) that hosts in private realms MUST use RSIP clients to obtain public connectivity, then maybe we can make some progress here. But, since RSIP by itself is not NAT-- it's only an *optional* enhancement for NAT clients and gateways-- the first step in making RSIP mandatory for IPv6 address realm traversal instead of NAT66 is to declare, well, that NAT66 Is Evil.
Yet, as we have already decided that "NAT66 Is Evil" is an unwelcome view in this BOF, it seems there is little hope for any productive work to come out of this effort until that changes.
-- james woodyatt <[email protected]> member of technical staff, communications engineering _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
