[arin-ppml] IPv6 Non-connected networks

[David Farmer]

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
> 
> Owen,
> 
> 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
> disagree.

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
===============================================