[arin-ppml] Policy Proposal: A Modest Proposal for an Alternate IPv6 Allocation Process

[George, Wes E [NTK]]

This isn't exclusively a policy problem to solve any more than it is just a technology problem to solve.
To be honest, I don't know what the answer is, short of something much more revolutionary like a location/ID split for IPs, or some as yet to be invented method of reducing the DFZ routing table.
However, I don't think that this policy nor the "open access" policy is the correct solution as they are currently written. I would love to be able to do this type of filtering, but I know it will likely not happen because renumbering is a pain, and there will always be some exception that will force a reduction in the filters and blow the routing table up anyway. I would also love for deus ex machina to come along and solve the problem through excellent application of magic technology, but I have to be practical there too. So, I'm stuck with having to continue operating under the concept that there is scarcity in the IPv6 world. Even though it's not IP address scarcity, it does exist, and there are multiple tools in our box to help manage it. This likely means that there will be some folks out there that will have to settle for getting a PD allocation from their upstream that is aggregated before it hits the DFZ, and that others might not get a /32 just because they want one. It might also mean that ISPs will have to do careful filtering of blocks so that they don't blow up the table or blackhole stuff they didn't want to. It's not a pretty picture either way.

Wes

-----Original Message-----
From: Ted Mittelstaedt [mailto:tedm at ipinc.net]
Sent: Friday, June 05, 2009 4:41 PM
To: George, Wes E [NTK]
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Policy Proposal: A Modest Proposal for an Alternate IPv6 Allocation Process

George, Wes E [NTK] wrote:


> but until that happens, I have to assume it won't (or it won't happen fast enough) in order to ensure that I can continue operating my network at a reasonable cost

OK, well go back to my original question, then.  I asked if router
advances would eliminate the need for filtering (or limiting the table)

Your basically saying that they aren't going to.   Yet, your against
the parts of the policy (predefining a block size) that are essential
to being able to define a block, which is needed for filtering.  So,
should I take this to mean that you think heavy filtering (like this
policy appears to assume) isn't the
answer to table bloat, but rather, limiting the table size? ie: limiting
the number of allocated prefixes?


Ted


This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.