On 2007-07-03 16:53, Paul Vixie wrote:
[paul vixie]
... i don't have objective measurements, but i know that a lot of table
size control is achieved by limiting the horizon of announcements.
[brian carpenter]
Absolutely. And from what I've heard, "a lot" may in fact be as much
as 90% for some ISPs.
so, we share a supposition that the DFZ is now a minority of "the Internet".
Or possibly that we don't know what "the Internet" is any more...
ULA-C with my proposed diffs is just a way to take this a lot further, to
legitimize it, to scale it up to planetary size.
And actually that is where we seem to be at odds. I fear that ULA-G will
leak. That's all.
consider a spectrum of possibilities:
--------------------------------------------------------
O(10^4) O(10^6) O(10^8)
in the leftmost cast, the number of ULA-G prefixes is so small that we could
accomodate them in the DFZ, and the only "problem" would be that it was an end
run around regional (RIR) policymaking.
in the rightmost case, the number of ULA-G prefixes is so large that no single
routing table can hold them, not even the much vaunted 2-megaroute machinery
that's now on various drawing boards.
Certainly. And that is roughly the scale that the RAM debate is
considering, although the working hypothesis there is more like
10^7 prefixes.
in the middle, there's a range of size that's large enough to hurt a lot but
small enough to be practical if everybody sends cisco and juniper a great deal
of money.
what is the size of your fear? i ask because my supposition is that the DFZ
is already a minority and that something like ULA-G (or even ULA-C) would make
it an even smaller minority. and i consider the rightmost case the likeliest
number of ULA-G routes, and that the number of likely DFZ leaks to be zero.
Well, my hypothesis is a network with 10^10 nodes and with 10^7 prefixes
in need of multihoming across the DFZ. But no ULA-* prefixes should be
in the DFZ; so these hypotheses seem to be compatible.
in the DFZ today are many competitors and thin margins. for a "leak" to be
successful, one provider has to want to emit a ULA-G route, and virtually all
other providers have to be willing to accept it. this is so unlikely that i
can't imagine it. it's not equivilent to the RFC1918 or non-BGP38 emissions
problems, since every "leak" in this case means a competitor signs recurring
revenue for a customer who was in play. "that is sooooo not going to happen."
I have to say that sounds convincing. I suppose there will be
exceptions, but not enough to matter. (An exception is where BigBadCorporation
insists on being accessible only via its junk /48, but every customer
of every ISP wants to reach www.BigBadCorporation.com. Then the incentive
exists to route that /48.)
We need to encourage the former and discourage the latter (as far as
seeing them in BGP is concerned).
if you mean by "BGP", the DFZ, then i'd agree with this statement in
isolation from the one that came before it.
Yes, I mean the DFZ - as above, I fully understand that there are already
vast numbers of private routes.
then we really do agree that when it comes to the DFZ, aggregation is a MUST.
and our area of disagreement is simply whether deaggregated ULA-G will enter
the DFZ. i have several times shown why i think that can't happen. most BGP
operators are looking for any excuse to filter inbound routes, especially TE
routes whose only purpose is to improve the efficiency and service quality of
competitors. an RFC that strongly recommends that FC00::/7 be filtered will
be an excuse that most of these operators will be thankful for (hopefully
that could mean "beer as in free").
Ack, as already stated in RFC 4193 section 4.1 para 3.
... the tier-1 providers ... can afford 2-megaroute forwarding machinery,
they compete aggressively for end-sites against both other tier-1's and
all of the regional or value-add or low-cost tier-2's, and they really
like the PA concept because the renumbering penality gives them a form of
lock-in that even microsoft and apple can only dream about.
As an aside, that's why the normal model in IPv6 is for a user site to
run several PA prefixes simultaneously, and that's why we designed shim6.
on that aside, when i connect up my end host to a LAN that has multiple router
advertisements, it selects exactly one as my default route. there's no LCR as
in the telephony world. there's no intent to import the entire routing table
into every host -- the router advertisements i don't select are backups not
competitors. the shim6 idea makes it more interesting -- how's that working
out in the field? any significant deployment experiences to report? (i'm
not just still bitter about the A6/DNAME debacle -- i really want to know.)
No. It's really too soon. The shim6 documents are in WG Last Call right now.
if the tier-1's decide to exchange ULA-C routes with each other, then the
rest of the internet has to do likewise. and if some really large cash
cow of a customer puts out an RFP to tier-1 saying "we'll buy bandwidth
from whoever will route our ULA-C into the internet core" then it'll be
very interesting. is this your proposed "pressure to stick" comes from?
because i can think of a dozen reasons why it can't happen, all based on
business strategy and self-interests of every single party involved in
that money chain.
I hope you're right. My argument against structured ULA prefixes is only to
make it less likely to happen.
the benefit of ULA-G away from the DFZ is so much greater than the risk of
ULA-G to the DFZ that i can't even consider them simultaneously long enough
to let them compete. from what you're saying, i don't know if you can either.
Agree
What's your estimate of the total number of ULA-C prefixes needed?
approximately one per family, worldwide, counting only the population who
has electric power. much much higher than the 2-megaroute level, or the
number of domain names registered in .COM and .DE (the two largest TLDs).
I don't get that. Customers need routeable prefixes. Why do you need a
ULA-C prefix for a customer?
the idea of an internet made up only of customers was never part of the early
vision as it's been told to me. every device needs a unique identifier for
any number of reasons. if the DFZ is intolerant of these identifiers, then
they'll show up in other ways, like non-DFZ routing, 1:1 NATv6, ad-hoc IPSEC
tunnel innards, software key/serial numbers, and things we've not imagined.
the DFZ is one way to internet. only one way. and it's not the only reason
one might need a registered unique addresses.
Here we do get into the ID/Loc split discussion that's going on over
in RAM and RRG. *If* that concludes that
a) a split is needed
b) the IDs should be in IPv6 address format
c) they don't need to be cryptographically generated
and d) they do need to be registered and DNS-able
then ULA-G would clearly be a candidate, and ULA-C wouldn't.
Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
