[arin-ppml] ULA-C

[David Farmer]

Kevin Kargel wrote:
> The danger I see with ULA peer relationships is that if I advertise my ULA-* to a peer for private uses I have no control over my peers BGP policies and they may through design or neglect advertise my ULA to their peers, which would/could pollute the global table.  This could get *me* in trouble through no fault of my own.  

You are right you don't have ultimate control of this issue, your peer 
does, and their other peer has control over what they accept.  This is 
not that much different the GUA though.  Yes, since your peer's, peer's, 
peer is not seeing your ULA route in the global table it is more likely 
they will believe the route, if they are not filtering ULA.

However, you can at least try to help you peer do the right thing and 
add the well-known community "no-export" when sending any routes you 
don't want your peer to announce to anyone else.  They can alway strip 
the community off and do what ever they want but it would help prevent 
them from accidentally announcing it to someone else.

Even with that there is no substitute for good peering practices.

> On a local (personal)level I just don't see the need for dedicated ULA pools when anyone can roll their own ULA-* out of their GUA.  

As I said my local (personal) reasons for wanting this are not 
technical, they are political and to allow me to appease others, both 
within my large organization and at numerous business partners all over 
the world.

> My interpretation is that ULA-ish GUA consumption would count toward utilization requirements, so it would not handicap further allocation requests.  Perhaps I am wrong on this one.

Good question, I do not thinking there should be such thing as PA ULA-C, 
in other words as a provider you don't get a ULA-C allocation and give 
some to your customer.  If your customer wants ULA-C they get it from an 
RIR.  You as a provider could get ULA-C for your internal use only, 
sized appropriately for your network infrastructure.

For a end-user they could get ULA-C equivalent to what they would 
qualify for PI.  An example, if an end-user qualified for a /46 of PI 
they could get a /46 of ULA-C.  In fact I believe they should be able to 
have both at the same time.

Further, it is entirely possible from a policy point of view for a 
end-user site to have a PI /46, a ULA /46, a PA /46 assigned from a 
provider, additional PA /46s from any number of providers, and be 
completely justified.  And, each of those prefixes could have an RA on 
every one of the subnets within the end-users network.  I'm not sure how 
the hosts are going to know how to select the right prefix to use, but 
that is not an number resource policy question, that is an operational 
one. From a policy point of view this should be valid.

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