Jeroen Massar wrote:
[this is going to be a long and sort of whiny one, apologies in advance]
No problem - succinct and on-topic long and whiny is fine.
It's off-topic, dogmatic, or ad-hominem stuff that is not okay.
Fortunately for us all, yours is not the latter. :-)
Even if space is available, there is no guarantee that ISPs getting
multiple /32's will announce them only as aggregates. (IPv4 deaggregates
are the demonstrable support for that particular argument.)
There are already a couple ISP's who got prefixes between /20 and /32
who are currently de-aggregating it.
As a community, we should express our collective concern, whenever
*anybody* deaggregates.
Not doing so at the first instance, implicitly establishes a precedent
and our collective willingness
to accept deaggregates - something which will, sooner or later, hurt
nearly everyone in the DFZ.
If you know of ISPs doing this, would you please identify them? I think
we all want to know...
Changing where the user-bits are, is not going to change that. That is
is in the hands of the ISPs who either accept or don't accept those
prefixes.
It's a cause-and-effect thing, that I don't think you grasp.
Basic logic stuff goes:
If the conditional conjunctive, "A -> B" is true, then "!B -> !A" is
also true.
If the things we are talking about are:
A = "ISP X gets additional PA IPv6 space from an RIR"
B = "ISP X announces the two prefixes, which would be aggregatable, as
separate prefixes rather than as a single aggregate"
If we want to achieve "!B", i.e. to not have any ISP X announce two
blocks without aggregating them, then
the simplest way to achieve this is to figure out ways to prevent any
ISP X from *needing* additional PA space.
(Ever.)
Changing where the user bits, changes the allocation units, which in
turn changes the number of allocations of "typical"
size that a given PA block can supply.
So, changing where the user bits, *does* directly impact whether, or
when, any ISP will need to get a second PA block.
Which directly affects (by making moot) the question of whether ISPs
will or will not aggregate adjacent PA blocks given to them.
You are mixing up Addressing with Routing. You are trying to solve a
Routing issue by changing Addressing.
No. I am making distinctions between Addressing, Aggregation,
Allocation, and Routing.
Routing is announcing reachability of IP(v4 or v6) prefixes.
Prefixes are the building blocks of routing.
Prefixes may or may not be aggregates of more-specific prefixes.
It is only possible to aggregate, where allocation of address space
permits it, whether by design or by accident.
Aggregation can be done externally (e.g. in BGP), or internally (e.g.
OSPF areas), or both.
Aggregation follows topology, or topology follows aggregation. Pick
which one you do, if you aggregate at all, is the general rule.
Here's the thing:
I am trying to solve an inherently *unsolvable* problem, by *changing
the rules* - which is the only way the problem *can* be solved.
If you don't have enough bits for aggregation, you can't aggregate.
If you can't aggregate, you have serious scaling problems in routing.
And scaling problems *cannot* be worked around.
Please see the [EMAIL PROTECTED] and [EMAIL PROTECTED] who are attempting to
solve
that issue.
Yes, I'm following rrg threads on LISP et al. I understand that there is
a problem, and that they are trying to solve it.
However, it's largely a "I have a hammer, and everything looks like a
nail" problem. They may come up with solutions
for the problem they see, but that doesn't mean it's the *real* problem
that exists, or that their solution will work
outside the lab environment.
...oooOO( If you have no interest in actually correctly presenting and
thus defending your draft, then why do it? )
It's a question of knowing your audience. I don't believe anyone at
NANOG would have the
patience to put up with a 30 minutes or longer talk on somewhat esoteric
aspects of protocol
stuff. They want the bottom line.
(I know *I* would walk out of my own presentation at NANOG, if it were
30 minutes long :-))
BTW - I plan on presenting and defending the draft in Vancouver, at
IETF, which is its natural home.
Note also that there are still not 1000 IPv6 prefixes globally...
And, should experience at some later point show that my proposition on
the impact of /64 holds true, what then?
Which exact impacts of /64's? Or are you wanting to stuff /64's into
global BGP? ISPs are getting /16-/32's and for PI /40-/48 are being
allocated by the RIRs. How is this going to affect global prefixcount?
The impact I'm talking about, what the whole draft talks about, is ISPs
getting multiple PA blocks
from RIRs, and increase above 1.0000 the average number of PA blocks per
ASN.
The way /64 affects this is, if the smallest end-user assignment
permitted under RIR rules, is a /64,
then all allocations to end-users will be /64 or shorter prefixes.
The RIRs use autoconfiguration as a justification for setting the limit
of allocations to /64 or shorter.
The impact of >> 1.0000/ASN is, that as IPv6 is globally deployed in the
DFZ as a dual-stack
along side IPv4, the combined prefix counts of IPv4 (already bloated)
and IPv6 (now slightly
bloated and continuing to bloat as more ASNs get additional PA blocks)
begin to hit hardware
limits on routers in ASNs in the DFZ.
The possible consequences of this include:
- ISP "withering" - many smaller ISPs or ISPs with thin margins, cease
operations
- IPv6 abandonment - IPv6 fails to achieve critical mass, and is
effectively ignored as a "saviour" for the IPv4 Internet
- Internet balkanization - partitioning of portions of IPv4 or IPv6
based on filtering
Look forward to ongoing discussions on this topic....
But, please, tell me if/when you have read the draft-dickson... itself?
Please show me a network design at a single site which will use more
than a /48 and completely fill it up. (which would produce 65k routes in
your internal routing tables if you would not properly aggregate, which
you can easily do, but that is left as an exercise to the reader).
That's too easy.
A large company with a large number of engineering desktops, linux boxes
which are centrally administered.
A reasonably paranoid network scheme, places one desktop per VLAN, and
1:1 relationship between VLANs and subnets.
Regardless of the infrastructure topology, 65K desktops with
autoconfiguration (which is what such an enterprise would do),
means 65K /64's in total, on 65K VLANs. The 4K VLAN per node limit,
means that at least 16 switches would be needed.
I knew of such a company - at a Usenix conference, one attendee was
discussing scalably maintaining that quantity of desktops.
The secret was, don't give them root, and use "ghost" to build
replacement drives. The drive is the computer.
Autoconfiguration fits that model extremely well - no host-specific info
is needed at all, to get IP addresses and routing working.
The whole point: if you need more address space go to your RIR and
justify it and get it. Note also that the whole idea of IPv6 allocations
is that an ISP will *never* come back again. Take a guess why some ISPs
got a /20 and there are rumors of this $organization getting a /13...
Your comment here is a glimmer of hope - you almost grasp what I'm
talking about.
Yes, yes, yes - the idea for preventing IPv6 routing table bloat, at
least bloat caused by PA assignments,
is making *sure* that *every* ISP can operate for effectively an
indefinite period (decades), without
needing additional PA blocks.
In a period of decade(s), do we know which ISPs will be huge? We know
which ISPs are big now,
but as every financial analysis says, "Past performance is no guarantee
of future performance".
We don't know who will be really really big, from among the current
not-so-big ISPs.
There are 10,000's of ISPs. If even 10% of them grow significantly in 10
years, above the expected
worst-case based on RIR assignments, that means 1000's of extra PA
blocks. And in the next
5-10 years, PA-caused routing table bloat in the DFZ, can be globally
hazardous.
The idea is to promote conservationism globally - make it so that even
astronomical growth, from
the smallest ISPs, will have *no* impact on the DFZ. Make it a level
playing field, for *all*
the ISPs, by minimizing growth of the DFZ.
I would suggest taking a real live ISP network and making a network
diagram for that and how you would chunk up that /32 or larger that you
get from the RIR. Then see if you still have possible 'growth' issues.
You're missing the point.
It isn't what *I* do that hurts me, it is what *he/she* does that hurts me.
If a relatively small proportion of the ISPs give away /48's like candy,
and the RIRs let them,
they run out of space in their /32 and need another block.
Every ISP that does that, eats up space in every *other* ISP's router slots.
And, every ISP that does that, creates a *stupid* mentality among
end-sites, that the value
to them is the size of the prefix they get. "He gave me a /48, why are
you suggesting a /112?",
ignoring that the end-user only plans to have 200 hosts and will
statically configure them.
This "conspicuous consumption" mentality evolves into an arms race, much
like that of the
cold war, with its own "mutual assured destruction" the only inevitable
outcome.
It is that kind of mentality, that I hope to prevent from even being
possible, by reducing
the largest block given out from a no-documentation-required /48, to
something in the
way of a "please tell us what you plan on using", and extending that by
lots of bits per end-site.
Rather than giving a big blank check, give a small check with a few
extra zeros.
End-user wants a /120, give them a /112 (or a /104 or a /96.)
End-user wants a /80, give them a /72 (or a /64.)
Now that I read the draft, and pointed out a few of my concerns, did I
totally miss the picture or what? As I really still don't see the need
for changing any of the current way things work.
I think the comment from the Area Director was, we (6man) should be
reasonably open to changes,
unless there is good reason to oppose.
My view is, "not seeing the need", isn't the same as seeing a problem
with the draft.
Examples of a problem:
- would break something
- not backward compatible
- cannot be easily implemented
- incompatible with certain devices (hardware etc.)
I don't believe there are any problems of those nature, but if I am
mistaken, I *really* want to know about it.
And, if there aren't problems like those, I would suggest deferring to
the AD's advice, and permit it to be adopted as a WG matter.
Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
