Catching up ...
On 2007-08-30 14:08, [EMAIL PROTECTED] wrote:
Brian D,
You seem to be assuming that PI will be the dominant mode.
Not at all. I am assuming that prefixes in the DFZ won't be deaggregated
to any significant degree. All PA are aggregated, in theory at least,
under PI prefixes.
OK, so we see this roughly the same.
I am in fact only assuming PI prefixes as numerous as ASNs.
Or maybe two or three times that many? But yes, of the order of
tens of thousands.
And that more multihoming for true "end-users" will be enabled by
the ability to have duplicative PA blocks big enough to cover end sites
N times over.
Which was indeed the starting assumption for multi6 and shim6.
I am assuming that the *vast* majority of networks will have PA native,
or ULA-* native and 1:1 NAT onto PA, or "unannounced" PI internally
with 1:1 NAT facing multiple upstream PA blocks.
Here we differ; I hope we never see NAT between ULA and PA; such a site
should simply use its ULA prefix for internal services and its PA
prefix(es) for offering and accessing external services.
This seems very unlikely, since the vast majority of users
(i.e. SOHO) have no interest in what their IP address is and
no motivation to pay extra for PI.
(I don't disagree on the latter, making this moot. And you mis-speak
for me on what I assume.)
Clearly, for which I appologise.
We have no possible
difficulty in supporting a few million PI prefixes in the
/48 or /56 world currently planned (apart from BGP4 blowing
up, of course, but that's being discussed elsewhere).
I disagree strongly.
Yes, I'm aware, and I'm participating in those discussions.
And I didn't mean to imply that those discussions are easy or
anywhere near finished; my assertion is that address assignment
in itself is not a problem. More below...
The size of the autoconf prefix is out of scope for *those* venues.
However, it *directly* impacts assignments in those areas.
Which is why I raised the question, here.
Whether autoconf uses /64 or /68 or /80, has direct implications on
the minimum prefix assignable to an end-user should be, and what the
typical minimum minimum PI block size should be.
Yes, but given that we can manufacture 35 trillion /48s if we need them,
and that the RIRs are applying very conservative policies which
even lead to assigning /56s to sites, I just don't get why there
is a supply problem. (Setting aside current allocation guidelines
for PI, which could clearly be changed if they had to be.)
A "few million" PI prefixes is not actually something we should plan for,
I should explain. My view is that there is no reasonable scenario
where we would need more than ten million multihomed sites in the world
(that would amount to one multihomed enterprise network or local
ISP per thousand people in about 2050). So *if* we come up with no
better multihoming solution than straight PI, as per RFC 4116, *then*
we'd need a way to route 10^7 prefixes. It's the worst case scenario,
not a plan. The reason I've been putting thought into multi6, shim6,
RAM, etc for several years is indeed to avoid the need for that scenario.
even if it fits into the range of space between /3 and /32 (as in,
2000::/3, and /32 LIR PI assignments.)
Here's why:
On the biggest iron currently deployed in most networks, the size
of the DFZ in IPv6 that can *reasonably* supported has an upper bound
dictated by deployed TCAM size and per-prefix TCAM allocation needed.
These days, for example, on an IPv6-*only* Cisco 7600 with 3BXL, will
only hold a theoretical maximum of 119,000 prefixes. Bigger iron may
support double that, but again, only as IPv6-ONLY. When you add IPv4
onto the same platform, the huge IPv4 DFZ eats most of the capacity
for IPv6 prefixes. Most providers will need to have dual-stack for
a considerable period of time (3-5 years minimum, IMHO.)
10 to 20 years, IMHO.
And on that basis, how many end-user assignments fit into PI prefixes
which are sized sufficiently to grow vertically inside reserved space,
rather than multiply and bloat the DFZ, is very important.
Agreed.
Too big an end assignment, and it results in a squeeze play, where either
too few PI blocks can be reserved to go around (fairly), or too many small
PI blocks end up being used.
Adding 16 more bits to the range between PI block size and end-user
assignment prefix length, and the squeeze effect is relaxed considerably.
What do you mean by end-user? I thought that PI was for assignment to
end-user sites in the majority of cases. Are you discussing consumer ISPs?
Why wouldn't they just get appropriate size PA prefixes?
In any case, if it does turn out that we need a lot more PI space than
the current PI guidlines assume, I'm sure the community will
change the guidelines. Architecturally, PI and PA aren't really
any different anyway.
Making really big assignments (say /20 to /42) to handle end-assignments
of /80, gives a much longer life span to each PI block, and keeps the
PI per ASN down to a nice low value of "1".
As Jinmei-san pointed out, we don't really have that option.
Regards
Brian Carpenter
University of Auckland
Brian Dickson
Regards
Brian Carpenter
On 2007-08-30 03:17, [EMAIL PROTECTED] wrote:
Iljitsch wrote:
On 29-aug-2007, at 16:23, Thomas Narten wrote:
(I suppose it's a bit late in the game to go back to MAC-48 as II?)
Yes. The difficulty is figuring out how to move to something different
in a backwards-compatable way. I.e., we'd need a transition strategy.
But what would be the point of doing that now?
The point, which I have avoided making until now, is that II has direct
impact on the available range of assignments by RIRs to LIRs, for PI
blocks,
that also allow for very long timescale predictive assignments.
Basically, the minimum prefix size * number of assignments * LIRs,
when projected over a timeframe of decades, while preserving a global
DFZ consisting of one PI block per LIR, has a problem fitting into the
number of bits per RIR.
Right now, RIRs are reserving only an additional 2 bits per LIR
assignment,
for "growth". Alternative allocation policies (bisection) don't
guarantee
the ability to assign arbitrarily large blocks indefinitely - while that
is in fact the long-term requirement. Block sizes *should* increase over
time, even as the frequency of their assignment decreases.
What works best is, a best-fit approach, where any organization gets way
more space than they need, sized according to their own best guess as to
long-term growth *potential*.
Then, reserve even more space for each, in a consistent manner.
Take all these requests, and fill them in an optimized space-packing
manner.
At some point, growth requests get filled via "growing" the assignment
for
a given LIR into its reserved space.
And, long-term periodic reviews of those growth patterns may result in
bisecting *some* of those reserved blocks to make more space available
for similar assignments.
This can be shown to meet the requirements of individual LIRs to within
a few orders of magnitude of their long-term projections (pretty good),
and at the same time, optimize the packing efficiency, meaning the truly
free space will not be fragmented except to the degree absolutely
necessary
for the existing assignments.
This means that new assignments have the largest possible potential
prefix
size available, compared to other allocation methods. This can even be
demonstrated or possibly even proven mathematically, by modeling the
problem space.
The fact that we have so many local bits in the IPv6 address is our
insurance policy against address policy screwups because a single /64
is enough to run a network of arbitrary size if you forego stateless
autoconfig.
The same would be true of /80, which is what MAC-48 would result in, for
minimum prefix size for autoconf (and thus the standard end-user
assignment
size).
Of the 16 bits reclaimed via this change, I would propose to the RIRs,
that 4 bits be added to initial allocations, 4 bits to reservations
above
the initial allocations (for long-term growth), and the other 8 bits add
to the total space available for the RIRs to allocate to LIRs - by
adjusting
the minimum and initial allocation sizes by 8 bits.
The numbers (4 bits and 8 bits) are not accidental - they are one nibble
in size, which matches up with the boundaries for reverse address
lookups,
via ip6.arpa - which uses nibbles.
It seems to me, that while it would be an uphill battle, the main two
issues
are transition and compatibity, and inertia (e.g. deployed code and
networks.)
The overall benefits to address space assignment, IMHO, outweigh that
cost,
especially when considering the long-term health of the DFZ and the cost
to member organizations when having to do expensive upgrades to their
entire infrastructure to support bloat in the DFZ.
Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
