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

["Liubing (Leo)" <[e-mail]>]

Hi Fernando,

Many thanks for your throughout review. And please pardon for my late reply due to my holidays in last week.
My replies are inline.

> -----Original Message-----
> From: v6ops [mailto:[e-mail]] On Behalf Of Fernando Gont
> Sent: Thursday, February 11, 2016 12:22 AM
> To: [e-mail]
> Cc: IPv6 Operations
> Subject: [v6ops] Review of draft-ietf-v6ops-ula-usage-considerations
> 
> 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.

[Bing] The original idea was to enumerate all possible use cases in Section4, and sort out the beneficial ones into Section6.
I also had concerned a bit on the section4/6 overlapping issue in previous versions, your comment made me more tendency to merge them. Let me try it in the next version.

> * 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.
[Bing] This is a human practical issue, but ULA itself is innocent:)
Section 3 is a summary of the ULA features, I think your consideration could be included in Section 4.

> * 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.
[Bing] Ok, will do.

> * 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...".
[Bing] These industrial networks might not support common Internet services/functions such as HTTP, DNS etc., and they might not have the requirement to talk to the nodes in the public Internet.

> * 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).
[Bing] I think we're talking the same thing. "Automatic generation" means there is a function which aligns with the rules in 4193 in the device/software to generate the prefixes. We never assign "random" prefixes by our brains, unless there is no software available.
I'll make it more clearer in the next version.

> * 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.
[Bing] I'll consider removing it in the next version.

> * 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...
[Bing] This is in case the ULAs are renumbered, the filtering rules need to be updated accordingly. But as you said, normally people just won't renumber the ULAs. I'll modify the texts.

> * 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...
[Bing] Ok, I guess some quoting from Homenet documents might be helpful.

> * 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?
[Bing] Per RFC6434(IPv6 node requirement),  
   "Small Office/Home Office (SOHO) deployments supported by routers
   adhering to [RFC6204] use RFC 4191 to advertise routes to certain
   local destinations.  Consequently, nodes that will be deployed in
   SOHO environments SHOULD implement RFC 4191."

So, I think we just simply state in the document that for nodes that don't support RFC4191, they won't work in the situation as you said. I'll modify the texts accordingly.

> * 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?
[Bing] [ULA-IN-WILD] provides more detailed situations on this issue. You can see slide 20, which is an instance of "SMTP Received-Via".
[ULA-IN-WILD] link: http://conference.apnic.net/data/36/apnic-36-ula_1377495768.pdf

> * 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?
[Bing] RFC6052 allows the PREF64 shorter than /48, in which case, the embedded IPv4 address would occupy part of the 40bit GLOBAL ID field as required by RFC4193.
I'll improve the readability in the next version.

> * 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.
[Bing] If we merge Section6 into Section4, would you share more opinions of why it's bad to use it as identifier? 


[Bing] The below editorial issues will be addressed as well. Thanks for your so careful review!

Best regards,
Bing

> ** 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
> 
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops