Subject: [v6ops] review of draft-ietf-v6ops-ula-usage-recommendations-01

From: Lee Howard <[email-masked]>
Date: Tue, 05 Nov 2013 18:38:57 +0200

I confess, I skipped to Section 3, "Enumeration of Scenarios Using ULAs"

I'd like some qualification on this sentence:"And since ULA support
multiple subnets, it is scalable."

ULA scales to /48, which is admittedly pretty good, but isn't what I think
of when I describe something as "scalable."  Unless you mean multiple ULA
prefixes, but I don't think that's what you're describing here; more on
routing in a minute.

"The global uniqueness of prefixes is not guaranteed, however,
      the probability is extremely low"
Actually, the probability (of uniqueness) is extremely high.  The
probability of collision is low.

The "Prefix Announcement" section is a problem.  You want to say that ULAs
can be freely routed between networks, but that has significant technical
issues:
* As you point out, you could extend RAs.  Unless that's done, this is
actually a drawback to ULAs.
* Scaling is limited, again, to however many route entries devices can
handle.
* And all the problems of an ad hoc, non-hierarchical networks.

Home network:  I understand the use case described, though it's worth
repeating that ULA fits between LLA and GUA; in other words, only provides
a benefit for a multiple-segment home network.  There may be other issues
in the home network, still being discovered by Homenet, like source
selection for service advertsiements, and naming.

I like the use of ULA for an enterprise's management network.

There's also the consideration (raised in the NAT64-experience draft) that
a dual-stack node with IPv4, GUA and ULA may get confused about source
address selection.   Especially in the renumbering case; IPv6 connectivity
works, but IPv4 will be used in preference to ULA. . .

There's another consideration in 3.2.2, ULA+GUA: if you run forward DNS,
you may need a split DNS, where depending on where the query comes from
(inside or outside) you return a ULA or GUA.  You might just use GUAs for
everything that is externally available, or you might have different
policies depending on whether you use the GUA or ULA (for instance,
internal vs external firewall policy).  You do mention this later in 4.2.

There are several places where the address selection problem is mentioned,
and there's a suggestion to configure policy to force the desired
behavior.  This may be possible in an enterprise (using a group policy
object, or maybe other configuration mechanisms) but I don't think it's
realistic in a home network, and I think you should say so.

The first paragraph of 4.1 says "on the other hand," but I think the point
is consistent with the previous point.  Don't say "on the other hand"
here.  :-)

Please clarify the case of using ULA as the internal prefix for NAT64.  If
you do that with no GUA, you are giving IPv6-only hosts IPv4-only access;
there's no native IPv6 (because of ULA) and all IPv4 will use the NAT64.
It's the worst of both worlds.

THe point made in 5.3.3 is a good one.  So good that more words may be
needed.  A GUA would be a good identifier in the same way, except that a
GUA prefix may change.

Security considerations probably needs more.  There are several places in
the document describing NAT and (enterprise) security considerations.
These should at least be referenced.  It also improves security for
hosts/nodes that are not intended to be globally reachable; instead of
applying a filter, there is simply no route from outside the network.

I do agree that this document is striking the right balance in its
considerations.

Lee