NANOG 40 agenda posted
stephen at sprunk.org
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
(** 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
> 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.
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov
More information about the NANOG