[ppml] IPv6 PI space for addressing
brian.knight at us.mizuho-sc.com
brian.knight at us.mizuho-sc.com
Thu Apr 20 18:35:23 EDT 2006
I've been watching the debate over IPv6 PI space for well over a year
(mostly on NANOG), and one thing stands out to me. Many moons ago, if an
organization intended to run IPv4 in their network, they could secure an
IPv4 allocation even if they did not intend to route that prefix over the
Internet.
I believe address depletion is still a valid concern with IPv6, and the
draft policies do address this concern. However, I believe the restrictions
on IPv6 PI space should recognize the need for such space outside of the
Internet routing table.
I'm part of a financial organization that deals in futures and other
securities. We do not presently qualify for IPv4 PI space - our network is
simply not large enough. However, we could benefit greatly from PI space.
Without going into too much detail, our network has two border zones: one to
the Internet and one to our business partners. Our partners include
financial exchanges, software vendors, and our customers. We use PA space
for our Internet addressing, and RFC1918 for nearly all B2B connections.
It's quite challenging for us and for our business partners to manage our
routing. We use NAT at nearly every entry and exit point, sometimes forcing
us to buy extra equipment just to support that function.
If we could reserve PI space and deploy that throughout our network, rather
than more-dynamic PA space or some non-unique range, it would obviate the
need for NAT within our more complex border zone, and eliminate the problems
of readdressing there. We wouldn't attempt to announce this prefix within
the global routing table. We would simply translate our internal PI
addresses to the PA block our ISP will have provided. In fact, as I
envision our network 10 years from now, the only need for NAT would be at
the Internet border of our network, where we'll be translating our PI space
into PA space. :)
Being tied to PA space within our internal net would not be a good thing for
us. Yes, DNS makes transitions much easier, but address-centric issues
remain. We would need to coordinate with every one of our business partners
to have them update their routing for whichever private subnets we've chosen
to route. (That, or we would adjust NAT definitions for each partner.)
We'd also have to adjust our IPSec tunnels, which means more coordination.
We may also need to renumber point-to-point links, which means more
coordination. We have all the pain of renumbering should we choose to
change ISP's. A change in one zone would require a change in the other.
Non-unique addressing has all the problems of today: NAT, possible
overlapping ranges, renumbering, etc. This is the least desirable option of
all three addressing schemes, IMO.
Couldn't the draft policies / amendments under consideration recognize the
need for PI space outside of the realm of Internet routing? Perhaps a
policy could be crafted that allows allocations for entities which have
permanent (leased-line, IPSec site-to-site VPN, or equivalent), routed
connectivity to more than, say, 15-20 separate non-ISP entities. Couldn't
ARIN offer that to my company, possibly with the caveat that the allocation
will NOT be permitted in the global routing table?
I have to say that it seems ARIN and the other RIRs are getting co-opted
into policing the routing table on behalf of ISP's. And maybe that's the
best way to do it if any other solution would result in massively ugly
peering battles. I admit, I don't know the ISP business very well. But if
I can leverage IPv6 PI space for my company's network, should we be denied
because of an unrelated issue?
At the moment, this would be the only driver I can think of for my company
to adopt IPv6 quickly. Even then, I would depend on other organizations to
enable IPv6 on their networks before the benefit could be fully realized.
-Brian Knight
Sr. Network Engineer
Mizuho Securities USA
http://www.mizuho-sc.com/
* Please note that I do not speak for my employer - only for myself.
More information about the ARIN-PPML
mailing list