[arin-ppml] GUA vs ULA vs ?

[David Farmer]

Steve Bertrand wrote:
> I am overwhelmed with the number of posts regarding the whole
> 'Non-connected networks', so I'll admit freely that I haven't been able
> to keep up.

I don't see anything here that would lead me to believe that you missed 
anything critical in the conversation so far.

> With that said, I would like to share my opinion(s), even if they
> conflict, overlap, or otherwise override what others may have said.

Thank you for providing your opinions.

> Prelim:
> 
> - I am in favour of eliminating NAT from IPv6
> - I do have experience in dealing with both the ISP environment, and the
> small-medium enterprise (across multiple boundaries), so I do see the
> 'value' of NAT (I use the term 'value' loosely)
> - Since I have dealt with both sides, I am willing and able to drop all
> bias toward NAT for the purpose of this discussion
> - I want what is best for everyone
> 
> Understanding:
> 
> - I'm a bit behind the curve on some of the abbreviations, but I believe
> that this is correct:
> --- ULA == Unique Local Address
> --- GUA == Global Unique Address
> 
> If that is the case, here is how I feel...

That is how I have been using them and I believe others are using them 
to mean that too.

> We'll assume that I want to try to exploit a weakness in the policy to
> garner space that I'll "say" won't be routed, but thinking that I'll
> route it eventually anyways.
> 
> If the community decides that ARIN, not IANA, should provide 'private'
> space, it should:
> 
> - be from a large block designated as such.

Personally, I'd like to have the IETF define FC00::/8 for this purpose, 
and delegate it to IANA to allocate to the RIRs for assignment to 
organizations using process similar to those used for GUA today and 
using policies designated by the RIRs.  Among other things, this 
provides a single prefix for all the RIR's to use, and only one filter 
entry to block it globally and ULA-L (FC00::/7), also keeps ARIN from 
having to define routing policy, it comes from the IETF. I think this is 
compatible with what you are saying.

> --- why?
> 
> - So that the maintainers of BOGON lists (eg: Team Cymru) can hold one
> slot in their filters for all entrants, ensuring that enough staggered
> and unpredictable routing breakage will occur to ensure that serious
> network engineers/architects will realize that the `cheap way out' won't
> work

Agreed.  And, FC00::/7 is already in their BOGON list.

> - as has been said, ARIN is not a routing policy maker. However, if
> someone has a block allocated by ARIN that is 'supposed' to be private
> (ie. not globally routable) but it happens to show up in the DFZ, then
> it costs me. Perhaps it costs me for the extra tax hit I pay on my
> filter list, or if I choose to not be diligent, a slot in my routing table
> 
> Although I want the barrier-to-entry for IPv6 to be very low, I don't
> like the idea of ARIN supplying ULA, unless it sits equal in cost to
> GUA, and unless ARIN can supply it in a way that facilitates a very
> simple method for third parties to (help) ensure that the ULA will never
> appear in the DFZ.

I believe GUA-PI and ULA-C should be equal cost and provided under 
either identical or essentially identical policies.  At least I think 
that is what ARIN's policies should be, it would be good if the other 
RIRs followed suite, but that is their call.

> Otherwise, the way I see it, is that the cost of my /32 has the same
> administrative costs to ARIN as someone else's ULA. If ARIN doesn't
> achieve a lower administrative overhead to managing the different IP
> space, then the price should be equal.

Your /32 presumably is a GUA-PA provider allocation not an GUA-PI 
end-user assignment.  I believe that the comparison should be between 
GUA-PI and ULA-C, not between GUA-PA and ULA-C.  Presumably, a providers 
will be making assignments to its customers, which does involve so 
additional interaction and cost for ARIN.  Which I believe is at least 
part of the justification for the different billing models between 
providers and end-users, but that is a whole different discussion and 
not really a policy matter.

> Perhaps IANA should be approached for a 1918 v6. Perhaps I'm out of my
> league ;)

Essentially, ULA RFC 4193 is the IPv6 replacement for RFC 1918, it 
provides for random local assignment within the prefix FD00::/8, it 
provides significant statistical uniqueness, but not a guarantee of 
uniqueness.  ULA-C (Central) is an expansion of this intended to 
guaranteed uniqueness through a centrally registry with assignments made 
within the prefix FC00::/8, and reverse DNS delegation should be 
available if wanted.

> Steve

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