[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".
> > 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.
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.
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."
> >> 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").
> > ... 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.)
> > 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.
> >> 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.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
