[ppml] Policy proposals- my take
Rebecca
dns-tech at buckeye-access.com
Sun Jul 29 11:39:36 EDT 2007
>Rebecca wrote:
>> I just want to
>> keep abreast of the policy situation and get ideas for how best to go
>>about our IPv6 implementation when I read these posts.
Geoff Huston wrote:
>It's still not an easy call - its not a cheap exercise and figuring out
>the right time to make the investment within the available resources you
>have at hand is part of the issue here.
Well, for good or for ill our owners & upper management are very much for
bleeding edge technology, despite being a smaller ISP (We've got a /16, /17,
and /18) and cable operator. We've sunk a lot of money in the past into
projects that went absolutely nowhere, and also into projects that end up
being quite lucrative. Somehow we stay afloat. In this case, DOCSIS 3 will
be needed for the majority of our subscribers to be able to use IPv6.
DOCSIS 3 firmware for our equipment isn't really available in production
yet, but for reasons unrelated to v6 we're in process of changing vendors to
one that *promises* to have a code upgrade within a year. (Personally I'm
not going to hold my breath on that one.) Just recently management began
asking why we didn't already have an IPv6 implementation plan already in
progress. So we finally got the application for an allocation submitted &
approved like I've been asking to be able to do since January. :D (Yay)
And now we've got to do our best to look at IPv6 implementation, starting
with our core network. Since we're still expanding our customer base, and
looking into SIP, I think we would be one of the companies that would be
hurting if/when IPv4 runs out. (Lately we've had to go to ARIN 1-2x a year
for another allocation)
Anyway, enough back history - back on topic.
As far as policies, I'll try to sum up my feelings - keep in mind this may
all change as we get a better idea of what our needs will be, and I'm not
one of the decision-makers for our company - I just give recommendations and
then wait to see what really happens. I see 4 current active policy
proposals on the ARIN site.
1. Policy Proposal 2007-15
Authentication of Legacy Resources
I understand why this was proposed, but in all fairness, I think this
proposal is premature and a bit heavy handed. Overall, I don't support this
proposal. If I were a legacy holder, this would be greatly resented. I
agree with other people that recommend trying to entice the legacy holders
to sign RSA's or at least get current contact info without going about it
this way. First see who responds willingly when ASKED to do so. If there's
little to no response, then re-evaluate. But *as far as I know*, there
hasn't been a concerted effort to contact them, explain the purposes of
updating their info, and get them to join these discussions.
Someone else suggested sending letters requesting confirmation of contact
info/ownership, and terminating rDNS for the ones that don't respond. It
makes more sense to me to remove the entries that can't be confirmed to be
current, as they are more likely erroneous anyway. I personally use ARIN's
rDNS info when researching all sorts of issues. Even if it's not always
CURRENT - it's a starting point. Losing that info for the legacy
allocations all together b/c we're trying to force them to give up
theoretically wasted IPv4 space and/or get them to implement IPv6 doesn't
work for me.
2. Policy Proposal 2007-14
Resource Review Process
Sounds good to me
3. 2007-13:
Removal of ISP Immediate Need from End-User
Sounds good.
4. 2006-7:
Changes to IPv6 initial allocation criteria
Sounds good
Then of course there's a lot of discussions going on that relate to already
abandoned policy proposals or future proposals.
My 2 cents are as follows:
As I said before, our company is probably going to need IPv6 as we expect to
continue to steadily expand our product offerings and customer base over the
next 5 years (which goes beyond even the most conservative estimates for
exhaustion that I've been seeing). And many of our customers would SCREAM if
we started using NAT to get them all online without getting new allocations
as we run out.
*That doesn't mean that other companies should be required to implement IPv6
if they are not expanding their offerings/customer base. I don't support
policies that try to FORCE others to adopt IPv6 to accommodate our needs due
to our growth.*
I do expect our upstream providers to accommodate that traffic, but if they
don't, when our contracts expire, we'll just take our business elsewhere (we
are currently multi-homed with 4 providers). That is what we've done in the
past whenever a vendor can't meet our needs, and has worked thus far.
As far as legacy v4 allocations, I don't see enough benefit in trying to
*make* them give it back/have it managed by ARIN. It's theirs - that cat is
out of the bag, that train has left the station, IMHO. We have new options,
so take them and do what it takes to make it work. HOWEVER. If the legacy
holders want v6 allocations as well, that's a different story. At that
point they should have to sign an RSA with ARIN, and start paying dues.
They should be given the *option* to have their legacy allocation put under
the purview of ARIN, otherwise they should be treated as though the v6
application is a request for a first allocation. At that point I figure
they're either not utilizing the space ideally, and in order to avoid having
to pay dues/sign the RSA they'll do what it takes to renumber to use it more
efficiently when v4 runs out, OR they're already using it efficiently and
now they'll find themselves facing the same crunch as the rest of us. And
even if they're not using their legacy allocation(s) in the most efficient
manner, if they are willing to pay ARIN to join the IPv6 movement - let 'em.
I think this is a decent compromise given the high likelihood of a dual
stack environment (barring extrememe measures like everyone using NAT only
or artificially "ending" IPv4, neither of which I consider to be likely
eventualities).
Anywho, I've got to do some real work now, so I'll stop my rambling here.
Rebecca
More information about the ARIN-PPML
mailing list