|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: NANOG 40 agenda posted
Thus spake "Vince Fuller" <[email protected]> Yes, as NAT becomes ubiquitous, a larger number of private networks will be behind ever smaller prefixes that are assigned to sites so the per-site prefix length will decrease. I think you mean increase. Even without NAT, this is going to happen because big blocks will no longer be available, even if someone qualifies for one, and multiple smaller blocks will need to be assigned. Route count will grow increasingly faster as we approach and pass exhaustion as RIRs (or the black markets) have to chop up big blocks into smaller and smaller chunks to meet our needs. The logical end state for this would be /32s. In some cases, multi-homed end-sites may wish to have those /32s advertised into the global routing system. If, on the other hand, those end sites were to transition to ipv6, they would instead obtain "PI" /48s and advertise those into the global routing system. How is the former any worse than the latter? For one thing, the former further weakens the end-to-end principle and entrenches the idea of "servers" on public addresses and "clients" behind NATs, with those clients becoming second-class citizens. Today, this practice is voluntary for most users and under their control, so users are to blame for their own segregation, but tomorrow it will be forced on them by their ISPs*, which is a BadThing(tm). Also, a site will need dozens, perhaps reaching hundreds, of v4 prefixes to address all of their hosts if they do use public addresses, e.g. for content hosters; Already, the average number of v4 prefixes per AS is ~10, and it's rising. In v6, the goal is that every PI site can use a single prefix**, meaning the v6 routing table will be at least one (and two or even three eventually) orders of magnitude smaller than the v4 one. (* If those ISPs also wisely deploy native v6 at the time they deploy NATs for v4, customers would be motivated, or would at least have the option, of getting out of the NAT jail by upgrading to v6. That might end up being the final straw that makes the masses move -- or it might have no effect except on geeks who'd find a way to use v6 even if their ISP didn't offer it natively.) (** Except perhaps for a handful of gargantuan ISPs that manage to assign more than a /32s worth of addresses, most likely residential DSL/cable providers who're going to burn through millions of /56s and /64s per month when they roll out v6. Even so, those ISPs are still going to be rare enough they shouldn't affect the average number of prefixes per AS noticeably.) If you think about it, the NAT approach actually offers the possibility of improved routing scalability: site multihomed with NATs connected to each of its providers could use topologically- significant (read "PA") global addresses on the NATs while using the same private address space on their network. This reduces any renumbering problem to just that for a NAT that moves (or is replaced) during a provider change. This is also what some of the IETF's ideas on v6 multihoming amount to -- though at least they leave ports and the low N bits of the address alone and thus don't break two-way connectivity, just protocols/apps that embed raw addresses in their payload, which is a marked improvement over v4 NAT if not quite perfect. One might question that approach, and it's one of the uses feared for ULAs: since you're translating the top bits anyways, you might as well use private addresses on the back side. Some who opposed SLAs and ULAs did so because they realize such enable and perhaps even encourage IPv6 NAT "solutions" like RFC1918 enables/encourages IPv4 NAT. Yes, this sort of poor man's identifier/locator separation has all sorts of ugliness but it can probably be made to work. It may even be the path of least resistance versus fixing ipv6's routing scalability and deploying ipv6. Unless we fix IPv6's routing and get a real EID/RID split, that's what IPv6 is going to _be_ for folks too small to get PI or who live in regions that don't have PI. That's not what the IETF promised us, and it makes many folks wonder why they should pay the costs of upgrading if the situation with v6 won't be much better than it is with v4+NAT. ARIN partially solved this, i.e. for the larger sites that will probably constitute a critical mass of clients and servers, but it doesn't solve the problem for the growing underclass of folks who are and always will be stuck on PA and have to suffer all the bad side effects of that. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov
|