Re: [v6ops] Possible issue with source address selection for ULAs...

[Fred Baker <[e-mail]>]

> On Jan 18, 2022, at 5:10 AM, Vasilenko Eduard <vasilenko.eduard=[e-mail]> wrote:
> On 18/1/22 08:24, Vasilenko Eduard wrote:
>> I did not say about depreciation. For sure not.
> 
> What I mean is that there seems to be a group of people being very vocal about how bad ULAs are (which is probably the reason why we never got guidance on ULAs). But my take is that if they are so bad, they should be deprecated. But if they are not, guidance should be provided.

I would agree that guidance would be valuable. 

That said, to my small mind, the guidance is pretty straightforward: a ULA is only intended two be usable within a domain or to other domains that one has direct links to and supporting agreements with. In general, a BGP session should neither advertise nor accept advertisement of such a prefix apart from specific configuration resulting from such an agreement.

Rumination: A ULA is not a GUA. A person who assumes it is and configures a ULA when s/he should have had a GUA deserves the experience of figuring that fact out.

Rumination: A ULA could be used for a business-to-business relationship such as to a provider of a contracted service as described in https://datatracker.ietf.org/doc/html/draft-baker-v6ops-b2b-private-routing. 

I got all of that from reading RFC 4193.

What would you want to say that isn't intuitively obvious from that specification? Better, what guidance would you want to give that derives from operational experience?

BTW, when I read "ULA is bad" emails, what comes through is that the writer assumes that anything with an address is globally reachable or should be, and objects that a ULA is not globally reachable, "so service is denied to someone and they will be frustrated". I wonder whether the writer assumes that a ULA will be used in a manner similar to an RFC 1918 address behind a NAPT, and is motivated by "NAT is bad" considerations (RFC 2993). My sense is that if the entity assigning the address has the intention of denying service to the great unwashed, that will not be surprising. My next thought is that a system that has a ULA and a GUA should only use the ULA when communicating with a peer that also has a ULA in the same prefix - and I'm not sure that I know of an OS that understands that aspect of RFC 6724.