[arin-ppml] IPv6 Non-connected networks
farmer at umn.edu
Thu Mar 25 00:18:36 EDT 2010
William Herrin wrote:
> On Tue, Mar 23, 2010 at 9:01 PM, Owen DeLong <owen at delong.com> wrote:
>> On Mar 23, 2010, at 2:04 PM, Chris Engel wrote:
>>> Am I wrong?
>> I think you overestimate
>> the value and underestimate the cost
> I wouldn't bet on it, but in this one respect you're finally talking
> about a value judgment where two competent engineers can reasonably
I'll just say from a technical point of view I can argue both sides to
this with a completely strait face. :|
However, the real factors that decide security issues are not generally
technical, they are risk management issues driven by business factors.
In the EDU networking space, we are generally not fans of NAT or
Firewalls. But, several years ago, many of us realized that we were
spending an order of magnitude more time arguing about how wrong and bad
firewalls, than it would actually take to implement them and operate
them. So, the business issue was it was better to implement firewalls
than to keep arguing about them all the time.
We have been able to avoid NAT most up to now, because in general we
have had enough IPv4 addresses. But we are starting to implement some
NAT for things like open wireless networks, but we use public IP
addresses for our WPA2 wireless network.
Personally, I would prefer to have public PI addressing for everyone.
Even setting aside the global route table politics that creates, in the
enterprise would there are to many auditors, risk managers, security
consultants, and compliance officers, that think they need/want private
addresses. Especially for PCI, HIPPA, and other private protected data.
I don't want to argue with them, it will be easier and better for me to
get ahead of them and provide them what they think want, but in the way
I want to do it.
So while I don't personally like it, some kind of tainted, not to be
routed, address space will be necessary for IPv6. There will be a lot
of different ways we use it, just like we have today with RFC1918. NAT,
not connected networks, infrastructure management networks, VPNs, and
many many more ways, some we haven't even thought of yet.
However, could I suggest that we drop the discussion of competing
technical engineering views of network security. NAT v. no NAT, etc...
There is no one size fits all solution, your mileage will very, I'll do
it my way, you do your way, etc...
Can we just leave it at that and try to bring the conversation back to
how we want policy in this area to work. We need to enable as many
people to implement the right solution for them. And not be arguing
about what those solutions are, which one is best, and who understands
them better then the other guy.
I have seen some good discussion here, but we need to find a consensus
that we all can live with. The only way I see that happening is for
some compromise to start to taking place.
ULA-Random (RFC 4193) with statistical uniqueness seems a slight
improvement on and a basic replacement for RFC 1918 in the IPv6 world.
However, I think something like ULA-Central provides even more
improvement, and would allow a lot of people to rethink the private
addressing issue in the IPv6 world.
I believe such a solution should have the following properties;
- Guaranteed uniqueness, via registration, probably the RIRs
- The registration processes should recover assignments no longer in use
- Reverse DNS for those that want it
- Be designated as not to be routed by default, or only routed by
special agreement, A.K.A not for global reachability
- It should be justified separately from PA or PI addressing, you can
have both one of these and a PI or PA assignment
- The amount of space an end-user organization qualifies for should be
based on the number of sites they have
- The amount of space a service provider qualifies for should be based
on the number of sites they have, not their customer's sites
Personally, I'm agnostic if we do this with FC00::/8 or within Global
Unicast in 2000::/3. But, if we don't use FC00::/8 we shouldn't call it
ULA-C. However, a rose or a cow patty by any other name... Remember we
already have 6.10.2 Micro-allocations for Internal Infrastructure, this
is basically the same thing.
The policies involved should prevent the temptation of turning ULA-C
into a substitute for PI. Declaring it as not routable by default my
not be enough by itself to prevent abuse.
I believe ULA-C is an important part of the IPv6 addressing ecosystem,
but it needs to work in harmony and co-exist with with the rest of the
IPv6 addressing ecosystem, PA, PI, ULA-C, and ULA-L.
We need to define policies that make this whole IPv6 addressing
ecosystem work for everyone, not just the national backbone ISPs, the
regional ISPs, the broadband to the home ISPs, the content providers, or
the enterprise network operators, but all of us equally.
People ask what the killer app for IPv6 is, I believe it is long-term
cost reduction of network operations, IPv4 networks are expensive to
operate. Ask the big cable providers why they want to go to IPv6, it is
to reduce there cost of network operation. As a large scale enterprise
network operator I want to reduce our cost of network operations. Like
eliminating (or avoiding, in our specific case) the cost of NAT, /64
subnets in IPv6 will eliminate a whole class of network management
costs, managing subnets in IPv4 is an expensive pain in the backside,
especially at our scale 2500+ subnets.
So, where do we go from here????
David Farmer Email:farmer at umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 612-626-0815
Minneapolis, MN 55414-3029 Cell: 612-812-9952
More information about the ARIN-PPML