NANOG 40 agenda posted

Sat Jun 2 03:57:41 UTC 2007

Thus spake "Vince Fuller" <vaf at cisco.com>
> 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 