Subject: [v6ops] Brian's review of draft-ietf-v6ops-ula-usage-considerations-02

From: Brian E Carpenter <[email-masked]>
Date: Tue, 2 May 2017 14:52:20 +1200

Hi,

We're specifying the use of ULAs in Anima and I've been
using them in tests with no problem. So here is my review
of draft-ietf-v6ops-ula-usage-considerations-02.
(There are also a few issues of English, but let's work out
the technical content first.)

> 1.  Introduction
...
>  -  Globally Unique
>
>      ULAs are defined as a global scope address space.  However, they
>      are not intended to be used globally on the public Internet; in
>      contrast, they are mostly used locally, for example, in isolated
>      networks, internal networks, or VPNs.

Because of draft-bchv-rfc6890bis-06 (just approved as BCP), I suggest
revising this paragraph:

ULAs are defined as having global scope.  However, they are not
intended to be used globally on the public Internet, so they are
not considered globally routable [I-D.bchv-rfc6890bis]. In contrast,
they are mostly used locally, for example, in isolated networks,
internal networks, or VPNs.

...
>  -  Well Known Prefix
>
>     The prefixes of ULAs are well known thus they are easily
>     identified and filtered.

I suggest:

The prefix (fc00::/7) of all ULAs is well known, so they are easily
identified and filtered at a border router. Individual /48 ULA
prefixes may be filtered by normal configuration.

...
> 3.1.  Do Not Treat ULA Equal to RFC1918
...
> (People may still
> have a requirement for NAT with ULA, this is discussed in
> Section 4.3.  But people also need to keep in mind that ULA is not
> intentionally designed for this kind of use case.)

I think this parenthesis does more harm than good, so I would
prefer to delete it. Let's keep the tricky discussion in one place.

>  Another important difference is the ability to merge two ULA networks
>  without renumbering (because of the uniqueness), which is a big
>  advantage over [RFC1918].

I suggest:

Another important difference is the ability to merge two ULA networks
without renumbering (because of their unique /48 prefixes), which is
a big advantage over [RFC1918].

> 4.1.  ULA-only in Isolated Networks

A general comment on this section: should we include virtual networks
here, or add a section "ULA-only in Virtual Networks"? (I'm thinking
of draft-ietf-anima-autonomic-control-plane as a use case, but
there will certainly be others.)  
...
> o  Prefix generation: randomly generated according to the algorithms
>    defined in [RFC4193] or manually assigned.  Normally, automatic
>    generation of the prefixes is recommended, following [RFC4193].
>    If there are some specific reasons that call for manual
>    assignment, administrators have to plan the prefixes carefully to
>    avoid collision.

This text seems to encourage manual assignment, which is against
the MUST in Section 3.2.1 of RFC4193. I suggest:

o  Prefix generation: randomly generated according to the algorithms
   defined in [RFC4193]. Note that this may be an automatic process.
   Alternatively, prefixes may be randomly generated off-line,
   checked for uniqueness within the domain concerned, and then
   configured by administrators.

> o  Prefix announcement: in some cases, networks might need to
>    announce prefixes to each other.  For example, in vehicle networks
>    with infrastructure-less settings such as Vehicle-to-Vehicle (V2V)
>    communication, prior knowledge of the respective prefixes is
>    unlikely.  Hence, a prefix announcement mechanism is needed to
>    enable inter-vehicle communications based on IP.  As one
>    possibility, such announcements could rely on extensions to the
>     Router Advertisement message of the Neighbor Discovery Protocol
>    (e.g., [I-D.petrescu-autoconf-ra-based-routing] and
>    [I-D.jhlee-mext-mnpp]).

I suggest deleting the last sentence. It's not very solid and I
suspect that we should leave the question open for now.

> 4.2.  ULA+PA in Connected Networks
...
> [RFC7084] requires the CPE to support ULA.

I suggest adding:

and [RFC7368] recommends using them in home networks.

...
>  Benefits of Using ULAs in this scenario:
>
>  o  Separated local communication plane:...

To be clear, this is a different case from my suggestion
above to add "ULA-only in Virtual Networks", although
the argument is similar.

...
>  Drawbacks:
>
>  o  Operational Complexity: there are some arguments that in practice
>     the use of ULA+PA creates additional operational complexity.  This
>     is not a ULA-specific problem; the multiple-addresses-per-
>     interface is an important feature of IPv6 protocol.

Add a reference to [RFC7157] ?

> 4.3.  ULA-Only in Connected Networks

Could we get consensus to say simply:

There is no recommended mechanism for connecting a ULA-only
network to the Internet; see previous section.

> 4.5.  IPv4 Co-existence Considerations
...
> However,
> there are still lots of hosts using the old standard [RFC3484]

Is that still true? If so, I suggest s/lots of/many/

...
> Happy Eyeballs [RFC6555] solves this connection failure problem

Only for applicaions that support it!

> 5.  Security Considerations
...
>  As mentioned in Section 4.2, when using NPTv6, the administrators
>  need to know where the firewall is located to set proper filtering
>  rules.

I think this refers to some deleted text and so it should also
be deleted.

Regards
   Brian