[v6ops] Review of draft-ietf-v6ops-ula-usage-considerations

[Fernando Gont <[e-mail]>]

Folks,

I did a fresh review of the aforementioned I-D. I didn't follow previous
discussions of this topic, so my apologies if I raise something that has
already been discussed to death, etc.


** Technical **

* Meta: Both section 4 and section 6 contain use cases. This is rather
confusing. e.g., not sure what's the criteria to ut some of the use
cases in Section 4, while others in Section 6. Unless I'm missing
something, this should be fixed.


* Section 3.2: Do folks really generate the prefixes as "required"?
Me, I confess I've used things like fc00:1::/64 because they are simpler
that some random string of bits.

* Section 3.4, page 4:
> Externally-destined data can be sent to the Internet or
> telecommunication network by a separate function, through an
> appropriate gateway/firewall.

Please remove "firewall". A firewall wouldn't really help with that.


* Section 4.1, page 4:
> IP is used ubiquitously.  Some networks like industrial control bus 
> (e.g.  [RS-485], [SCADA], or even non-networked digital interfaces 
> like [MIL-STD-1397] have begun to use IP.  In these kinds of 
> networks, the system may lack the ability to communicate with the 
> public networks.

Not sure what you mean by "may lack the ability...".


* Section 4.1, page 5:
> 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.

mm.. what do you mean exactly by "automatic generation"? -- In all those
systems I have employed, the ULA prefixes are not generated
automagically. -- you need to un the algorithm yourself, which means
that the prefix is alwas manually configured (in the routers sending the
RAs).


* Section 4.1, page 5:
> 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]).

This is not specific to ULAs -- hence I'd remove this para.



* Section 4.2.1, page 7:

> -  If the firewall is located inside the NPTv6 translator, the 
> filtering is then based on the ULA prefixes, and the rules need to be
> updated correspondingly.  There is no need to update when the NPTv6
> GUA prefixes are renumbered.

not sure what you mean by "need to be updated"... the whole point of
ULAs is that you'd not renumber them...


* Section 4.2.2, page 7:
>  Note:
>       ULAs provide more benefit for multiple-segment home networks; for
>       home networks containing only one segment, link-local addresses
>       are better alternatives.

You need to expand and back these claims...


* Section 4.2.2, page 8:
>    o  Default Routing: connectivity may be broken if ULAs are used as
>       default route.  When using RIO (Route Information Option) in
>       [RFC4191], specific routes can be added without a default route,
>       thus avoiding bad user experience due to timeouts on ICMPv6
>       redirects.  This behavior was well documented in [RFC7084] as rule
>       ULA-5 "An IPv6 CE router MUST NOT advertise itself as a default
>       router with a Router Lifetime greater than zero whenever all of
>       its configured and delegated prefixes are ULA prefixes." and along
>       with rule L-3 "An IPv6 CE router MUST advertise itself as a router
[...]

If you have a multi-subnet home network, and the CP doesn't advertise
itself as a default router (and nodes don't support RFC4191), how do you
get multi-subnet ULA network to work?


* Section 4.2.2, page 9:
> 
>    o  DNS relevant: if administrators choose not to do reverse DNS
>       delegation inside of their local control of ULA prefixes, a
>       significant amount of information about the ULA population may
>       leak to the outside world.  Because reverse queries will be made
>       and naturally routed to the global reverse tree, so external
>       parties will be exposed to the existence of a population of ULA
>       addresses.  [ULA-IN-WILD] provides more detailed situations on
>       this issue.  Administrators may need a split DNS to separate the
>       queries from internal and external for ULA entries and GUA
>       entries.

This text seems to imply that someone will do reverse mappings for ULAs.
Could you please elaboate a bit on the scenario that you envision?


* Section 6.3.2, pages 11-12:
>    But there is an issue needs to be noted.  The NAT64 standard
>    [RFC6146] specifies that the PREF64 should align with [RFC6052], in
>    which the IPv4-Embedded IPv6 Address format was specified.  If we
>    pick a /48 for NAT64, it happens to be a standard 48/ part of ULA
>    (7bit ULA well-known prefix+ 1 "L" bit + 40bit Global ID).  Then the
>    40bit of ULA is not violated by being filled with part of the 32bit
>    IPv4 address.  This is important, because the 40bit assures the
>    uniqueness of ULA.  If the prefix is shorter than /48, the 40bit
>    would be violated, and this could cause conformance issues.  But it
>    is considered that the most common use case will be a /96 PREF64, or
>    even /64 will be used.  So it seems this issue is not common in
>    current practice.

(Disclaimer: I haven't read RFC6052 any time lately) The text above is
confusing to me... maybe you could expand and elaborate a bit more?


* Section 6.3.3, page 12:
>    ULAs could be self-generated and easily grabbed from the standard
>    IPv6 stack.  And ULAs don't need to be changed as the GUA prefixes
>    do.  So they are very suitable to be used as identifiers by the up
>    layer applications.  And since ULA is not intended to be globally
>    routed, it is not harmful to the routing system.

Using IP addresses as identifiers in upper layers is a really bad idea.




** Editorial **

* Abstract:

> Based on an analysis of different ULA usage scenarios, this document
> identifies use cases where ULA addresses are helpful as well as
> potential problems caused by using them,

Replace the trailing comma with a dot.

* Page 2, intro:
> Unique Local Addresses (ULA) is defined in [RFC4193], and it is an 
> alternative to site-local address (deprecated in [RFC3879]).

"..are defined in... and they are...."

* Section 1, Page 3:
> Thus, the administrators could choose to use ULAs in a certain way
> that considered benificial for them.

"..that is considered..."


* Section 4.2.1, page 6:
> The comunity has strong controversies of ULA-only deployment in 
> connected networks.

s/controversies/concerns/



* Section 4.2.1, page 6:
> For those who are strongly against this usage, the main reason is to
> avoid breaking the end-to-end transparence.  Because people have
> suffered from the NAT/Proxy middle boxes so much in the IPv4 ear

s/ear/era/


Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492