[v6ops] A few thoughts on draft-smith-v6ops-local-only-addressing

[Fred Baker <[e-mail]>]

I'm passing along some thoughts on the draft. I speak as a random individual, nothing more. I'll identify the sections I am commenting on.

Introduction

The statement in the draft, in the abstract and in the introduction, is that certain types of devices (and, I would argue, more accurately applications) are only appropriately reachable from localized locations, and therefore only using ULA addresses. This troubles me on a couple of counts. I would agree that there are a number of classes of Internet devices and applications that should be reachable only by their operators. But I question whether they are necessarily in their operators' local domains (how about outsourced datacenter etc?), or whether their operators might have operating contracts with others that muddy those waters? In general - and I have said this multiple times - if a device is intended to be reachable only by systems within its local domain, a local address (one not advertised in BGP) make sense. That said, I seriously dispute that this is a result of the nature of the device or its application; it is a policy decision on the part of those who operate it. I don't think I could pass on the draft with this confusion between nature and policy in it.

For the record, I would add that folks in v6ops have commented in the past that using ULA and GUA prefixes within an enterprise network entails the possibility of doubling the address announcement volume - if a given LAN has two subnets and therefore two prefixes, it would have that result. I would therefore expect that networks using this model would be likely to have some LANs with a GUA subnet and some LANs with a ULA subnet, but few if any with both. There is in my view a minor increase in complexity with this model - LANs have, if you will, an additional attribute, which is whether its subnets are local-only or global in nature. 

Default Local Only Addresses

Point of definition: a ULA addresses is global in scope, but may not be advertised globally. They may, if appropriate and agreed between ASNs, be advertised between "consenting adults". There is actually a reasonably common use case, discussed in draft-baker-v6ops-b2b-private-routing. I would prefer that the draft accurately describe a ULA if it wants to talk about them.

Permitted Incoming and Outgoing Connections

In excluding GUA-source sessions, I think this creates unnecessary complexity. First, if a device is using a GUA, one of two situations exists: it is within the network and managed to select the wrong source address, or it is outside the network, has no routing advertisement with which to read the ULA prefix, and can't get there. Anything else (such as the network erroneously advertised the ULA prefix and the neighboring network failed to filter it out) is an error.

My Real Concern:

If I were to read this as an enterprise network operator, I think my first reaction would be to say "I recognize this; a ULA is a private address, and if I choose to I can translate it at the network edge". As such, if we proceed with this, it needs to be with large health warnings about not using translation (cf RFC 2993).