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

From: Fernando Gont <[email-masked]>
Date: Wed, 10 Feb 2016 13:21:50 -0300

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: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "Dale W. Carder" <[email-masked]>
Date: Wed, 10 Feb 2016 14:34:11 -0600

> that some random string of bits.

I absolutely do not believe it can be expected that sites will generate 
random prefixes.   This will result in more NAT and all of the horror
stories from rfc1918 getting copied over.  For a while someone (SixXS?)
was running a ULA registry, but I am not sure what came of it.

In 5.1, the last paragraph states "Another important difference is the 
ability to merge two ULA networks without renumbering (because of the 
uniqueness), which is a big advantage over [RFC1918]."  So, should 
section 5.1 emphasize the importance of this uniqueness, or could 
this fit better somewhere else?

> Could you please elaboate a bit on the scenario that you envision?

I thought rfc4193 section 4.4 covered DNS adequately, but I think the
claim here is that the recommendations won't be followed (notice a
theme?).  If a site doesn't (or can't) follow them, the recommendation
is to at least run with split dns views to mitigate.

Dale

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Feb 2016 13:33:31 +1300

On 11/02/2016 09:34, Dale W. Carder wrote:
> random prefixes.

Why not, if it's a built-in feature of the CPE? Obviously, humans shouldn't
be messing around with these things.

> This will result in more NAT

No. ULA is for internal traffic only. You use your ISP-provided prefix for
the Internet.

> and all of the horror

It's still there for people who believe it matters. I've never seen the
point, myself.
https://www.sixxs.net/tools/grh/ula/

   Brian

---

From: Tim Chown <[email-masked]>
Date: Thu, 11 Feb 2016 16:34:10 +0000

> On 11 Feb 2016, at 00:33, Brian E Carpenter <[email-masked]> wrote:
> 

Sure, for a home network maybe. But in a campus you’d probably form an address plan
for your global prefix and map that to ULA space, e.g. 2001:db8:123:456::/64 would have
a corresponding ULA prefix of fc00::123:456::/64.

Not that I’m aware of any campuses yet using ULAs. 

> No. ULA is for internal traffic only. You use your ISP-provided prefix for

Indeed. In theory.

> https://www.sixxs.net/tools/grh/ula/

Dates back to the old ULA-C proposal, that died a death.
I think that’s draft-hain-ipv6-ulac-02.

Tim

> 
>   Brian
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Dale W. Carder" <[email-masked]>
Date: Thu, 11 Feb 2016 11:27:21 -0600

> be messing around with these things.

Oh, I should clarify my concerns are not at the CPE level, but at the 
enterprise scale where ULA may be used with human friendly / poorly chosen 
prefixes that inevitably overlap.

> > This will result in more NAT
...
> No. ULA is for internal traffic only. You use your ISP-provided prefix for

To clarify, to mitigate the ULA prefix overlap internally after a merger of 
two internal networks, nothing related to off-site connectivity.  We
have had this issue at our site on ipv4 when our healthcare system and campus 
enterprise network ended up overlapping in 10/8 and needed NAT just to get 
between the two, completely unrelated to off-site connectivity.  Having 
first-hand experienced getting burned I hope we can emphasize the risk
to avoid poorly chosen ULA prefixes in non-trivial (more than just a CPE) 
networks.

I was going to make a similar comment that I initially withheld about
section "6.1. Used in Isolated Networks" to which I would claim
isolation, though often well-intended in my experience ends up being 
temporary when it is found that devices later need external software
updates, control, logging, or ancillary support systems for which
proxying is too hard.  

If it's not obvious I do not like ULA at all, and I know a lot of the
arguments have already been hashed out.  I am hoping that this
guidance can at least be clear about the corners that people will (in 
my mind) inevitably back themselves into so it can be avoided.  There's
a lot of value getting that out.

Dale

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 12 Feb 2016 13:15:30 +1300

> prefixes that inevitably overlap.

If ULAs are assigned other than as defined in the standard, sure. But that
is just as bad a blunder as stealing a routable prefix and I would have
little sympathy.

The chance of a clash when two networks merge is minute if you apply the standard.

> to avoid poorly chosen ULA prefixes in non-trivial (more than just a CPE) 

Well yes, even Duh!.

> a lot of value getting that out.

Exactly. And we should include a very strong warning against manually
assigning a human-friendly prefix.

    Brian

---

From: Tim Chown <[email-masked]>
Date: Fri, 12 Feb 2016 06:59:01 +0000

> assigning a human-friendly prefix.

Definitely. Even if we know what's likely to happen in practice. And if you are manually picking a ULA /48 at least don't do all zeros - even using some bits of your global /48 in the ULA prefix is better than that.

Tim

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 Feb 2016 13:21:29 +1300

On 12/02/2016 19:59, Tim Chown wrote:
...
> Definitely. Even if we know what's likely to happen in practice. And if you are manually picking a ULA /48 at least don't do all zeros - even using some bits of your global /48 in the ULA prefix is…

Specifically, I believe that the following paragraph of the draft,
in section 4.1, is dangerous:

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.

I believe we should not even suggest that it might be OK to allocate
manually. This draft isn't a BCP so we can use normal English, for
example:

o Prefix generation: prefixes must be randomly generated according
  to the algorithms defined in [RFC4193]. There are on-line tools
  available to do this interactively, if not performed automatically
  by the CPE. Manual assignment of easy-to-remember prefixes must
  never be done because of the high risk of collision, recreating
  the problems of [RFC1918].

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 Feb 2016 13:37:24 +1300

Hi,

I have some comments on section 4.2. "Connected Networks".

1) I think the sub-section "ULAs along with PA Addresses"
should come first because it is the preferred model.

2) The sub-section "ULA-Only Deployment" starts by implying
that this might be a good idea. I suggest rewriting the
first sentence to make it sound like a doubtful idea:

 Operators of a network might be tempted to assign ULAs but not
 Global Unicast Addresses (GUAs), although the nodes also need to
 communicate with the outside network. There are two ways this
 might work:

3) I think the following bullets are in the wrong order.
I suggest putting "Using Application-Layer Proxies" first
(because it may be a decent solution in some security models)
and "Using Network Prefix Translation (NPTv6)" second (because
it is controversial, as discussed in the third bullet).

Regards
   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 16 Feb 2016 10:08:52 +0900

> first sentence to make it sound like a doubtful idea:

Wow. How did we end up with this text?

At the microphone in Yokohama there was very strong opposition to ULA-only
deployments using NPTv6. We got comment after comment saying that NPTv6
should be explicitly not recommended. How can we have text in this document
that so explicitly goes against these opinions?

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 Feb 2016 14:25:19 +1300

> that so explicitly goes against these opinions?

Well, to be fair that section of the document also covers app-level proxies,
so the introduction has to cover that as well as NPTv6. But yes, if I'd been
in Yokohama I would have said the same as you.

   Brian

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 16 Feb 2016 07:17:27 +0000

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

> 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.

> Please remove "firewall". A firewall wouldn't really help with that.
[Bing] Ok, will do.

> > 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.
> 
[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.

> > administrators have to plan the prefixes carefully to avoid collision.
> 
> 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.

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

> 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.

> You need to expand and back these claims...
[Bing] Ok, I guess some quoting from Homenet documents might be helpful.

> 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.

> 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

> 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.

> 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

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 16 Feb 2016 16:43:26 +0900

>   the problems of [RFC1918].

+1. A manually assigned prefix in fc00::/7 is not ULA. It's bogon space.

---

From: [email-masked]
Date: Tue, 16 Feb 2016 08:51:20 +0100 (CET)

>   the problems of [RFC1918].

Assume I want to number my lab using ULA. There's no way I'm going to
be using randomly generated addresses - I want to have an *address
plan*, and predictable addresses acording to a suitable pattern, just
as I would do with regular IPv6 addresses.

Which means I'd probably ignore the above sentence of never doing
manual assignment.

Yes, I understand what you're trying to do here - however, there are
situations where this *will* be ignored.

Steinar Haug, AS2116

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 16 Feb 2016 16:56:13 +0900

> situations where this *will* be ignored.

I suggest you number your lab with 1::/16 instead. It's a bogon just the
same, and the addresses are even shorter and easier to remember.

More to the point: as a procedural matter, this is an informational
document and as such cannot document propose behaviour that is in direct
contrast with a standards track RFC., period.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 16 Feb 2016 03:43:08 -0300

> be messing around with these things.

I guess that the thing is that if for one reason or another you need to
e.g. enforce ACLs or whatever, you want such prefixes to be "stable" --
e.g., what if you replace the CPE?

Thanks,
Fernando (a human who manually messed with ULAs :-) )

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 16 Feb 2016 08:15:03 +0000

Hi Steinar,

> From: v6ops [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Tuesday, February 16, 2016 3:51 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [v6ops] Review of draft-ietf-v6ops-ula-usage-considerations
> 
> Assume I want to number my lab using ULA. There's no way I'm going to be
> using randomly generated addresses - I want to have an *address plan*, and
> predictable addresses acording to a suitable pattern, just as I would do with
> regular IPv6 addresses.
[Bing] There are only 40bit of the ULA prefix to be randomly generated, we still have a 16bit "Subnet ID" to plan the addresses with the same /48 ULA prefix.
I guess 16bit should be enough for a lab to do the address plan?

Best regards,
Bing

> Which means I'd probably ignore the above sentence of never doing manual
> assignment.
>

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 16 Feb 2016 08:19:36 +0000

Hi Brian,

> From: v6ops [mailto:[email-masked]] On Behalf Of Brian E
> Carpenter
> Sent: Tuesday, February 16, 2016 8:21 AM
> To: Tim Chown
> Cc: [email-masked]
> > Definitely. Even if we know what's likely to happen in practice. And if you
> are manually picking a ULA /48 at least don't do all zeros - even using some
> bits of your global /48 in the ULA prefix is better than that.
> 
> Specifically, I believe that the following paragraph of the draft, in section 4.1,
> is dangerous:
> 
> I believe we should not even suggest that it might be OK to allocate manually.
> This draft isn't a BCP so we can use normal English, for
> example:
> 

[Bing] I think the proposed text is better. We do need to encourage people to use tools to generate the decent ULA prefixes.
I'll modify it in the next version accordingly. Thanks.

Best regards,
Bing

---

From: Fernando Gont <[email-masked]>
Date: Tue, 16 Feb 2016 05:23:52 -0300

Hi, Leo,

Thanks so much for your response! -- Comments in-line (only for those
items that needed further comments)...

On 02/16/2016 04:17 AM, Liubing (Leo) wrote:
>> ** 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.

Great!

>> * 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 is a summary of the ULA features, I think your
> consideration could be included in Section 4.

Agreed. My comment is that in practice, humans my take a shortcut and
produce more "human friendly" prefixes -- I've done that (i.e., "guilty"
:-) )

>> * 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.
>> 
> [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.

This is more clear than the text in the I-D. I'd suggest you appy this
to the I-D.

>> * 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.

FWIW, general purpose operating systems (e.e. Linux) do not really have
such a function.

>> * Section 4.2.2, page 7:
>>> Note: ULAs provide more benefit for multiple-segment home
>>> networks;
>> for

Yes.

>> 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

Oops, my bad! Thanks! (no changes needed)

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

One of the main reasons is that applications become tied to a layer-3
protocol. It's better to use names rather than addresses. So I'd remove
the comment on using the addresses as identifiers in the upper layer
protocol.

Thanks!

Cheers,

---

From: joel jaeggli <[email-masked]>
Date: Tue, 16 Feb 2016 07:32:52 -0800

On 2/15/16 11:56 PM, Lorenzo Colitti wrote:
> On Tue, Feb 16, 2016 at 4:51 PM, <[email-masked]
> <mailto:[email-masked]>> wrote:
> 

There are more or less infinite variations on how  a lab might be
numbered, depending on what the affect to be achieved is.  I wouldn't
"recommend"  a ula usage inconsistent with any other recomended ula
usage. various applications such as simulating one's production network
can require prefix ranges much larger than the documentation prefix, or
traditional ULA  assignment are intended to support. that's fine, but
it's up to the developer.

joel

---

From: "Howard, Lee" <[email-masked]>
Date: Tue, 16 Feb 2016 18:25:24 +0000

From: v6ops <[email-masked]<mailto:[email-masked]>> on behalf of Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>
Date: Monday, February 15, 2016 at 8:08 PM
To: Brian Carpenter <[email-masked]<mailto:[email-masked]>>
Cc: 'IPv6 Operations' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] Connected Networks section of draft-ietf-v6ops-ula-usage-considerations-00

On Tue, Feb 16, 2016 at 9:37 AM, Brian E Carpenter <[email-masked]<mailto:[email-masked]>> wrote:
2) The sub-section "ULA-Only Deployment" starts by implying
that this might be a good idea. I suggest rewriting the
first sentence to make it sound like a doubtful idea:

At the microphone in Yokohama there was very strong opposition to ULA-only deployments using NPTv6. We got comment after comment saying that NPTv6 should be explicitly not recommended. How can we have text in this document that so explicitly goes against these opinions?

The discussion on list has not been as clearly against NPT in every circumstance as the discussion at the meeting. I suggested the authors try to describe the reasons people support or oppose its use, so readers could make well-informed decisions. Even well-informed bad decisions are better than uninformed bad decisions.

Lee

________________________________

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 17 Feb 2016 09:56:57 +1100

In message <EMEW3|dffd12495342609795efc27fa4f472d8s1AGYE03tjc|ecs.soton.ac.uk|55D51005-3098-43C6-9164-5903851133
[email-masked]>, Tim Chown writes:
> Sure, for a home network maybe. But in a campus youd probably form an
> address plan

No.  It would should be fdxx:xxxx:xxxx:0456::/64.  Where the x's
are randomly choosen nibbles (toss a fair coin 40 times - heads 1,
tails 0 to get the prefix bits).  So when you have 2 PA prefixes
you would have:

	2001:0db8:0123:0456::/64	provider 1 prefix 2001:0db8:0123::/48
	2001:0db8:eadf:0456::/64	provider 2 prefix 2001:0db8:eadf::/48
	fdxx:xxxx:xxxx:0456::/64	ULA prefix fdxx:xxxx:xxxx::/48

You DO NOT copy bits 33..48 from the PA address.  Yes, there are
shorter presentation forms of the above prefixes.  The leading zeros
are include for alignment purposes.

Note: that is "fdxx" not "fcxx" as they are Unique Local Assigned
prefixes.

> Not that Im aware of any campuses yet using ULAs.
>
> I think thats draft-hain-ipv6-ulac-02.
>
> Tim
>
> >
> >   Brian
> >

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Wed, 17 Feb 2016 10:25:57 +1100

> to avoid poorly chosen ULA prefixes in non-trivial (more than just a CPE) 

And if you do.  You generate two new ULA prefixes which DO NOT
overlap with any of the existing ULA prefixes and migrate both sides
to using these and then stop advertising the old ULA prefix in RAs.
You mark the common ULA prefix as "not to be used" in case there
is still some configuration stanzas referencing it.  You don't NAT
between the two sites, you just pass routing information for the
new prefixes and block packets with the common prefix at the internal
border routers with a approriate ICMPv6 code returned.

	permit from any to self in ifX
	deny from prefix to any ICMPv6 ... in ifX
	deny from any to prefix ICMPv6 ... in ifX

where ifX is in the prefix site.  This allows applications to know
that the packets have been blocked, for TCP generate RST as it is
more reliable.

If the two sites are using a common border router then the border
router needs to know how to send reply traffic out the correct
interface.  pktinfo is useful for managing this at the application
layer.  For TCP the kernel will do the correct thing.  For UDP you
may need to request it.  We do this in named when managing DNS/UDP
responses.  Most of the time there will be a neutral link in between
two border routers so this is not a issue.

This is similar to how a site border router to the Internet is
configured except the prefix is fc00::/7 as you are blocking all
of the reserved range.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 17 Feb 2016 10:29:02 +1100

> as I would do with regular IPv6 addresses.

With regular addresses the first 48 bits are given to you by the RIR
or ISP.  With ULA addresses we are saying generate the first 40 of the
first 48 bits randomly.  What is your issue here?

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 17 Feb 2016 14:03:18 +1300

On 16/02/2016 19:43, Fernando Gont wrote:
> e.g. enforce ACLs or whatever,

The ACL in the CPE needs to filter fc00::/7 anyway. Internally,
the ULA prefix is a /48 so any internal ACLs will be based on
a longer prefix than the /48.

On 16/02/2016 20:51, [email-masked] wrote:
...
> plan*, 

Yes, within the /48 that would be normal procedure. But the /48
itself is just an opaque bit string, like the GUA prefix that
my ISP gives me each time I restart the CPE. Yesterday it was
2406:e007:6fe2::/48, the day before it was 2406:e007:413e::/48.
I log it but I absolutely don't care about it.

> and predictable addresses acording to a suitable pattern, just

You generate an opaque value with https://www.sixxs.net/tools/grh/ula/
and use for the rest of your life, if you want. However, it will
be cut-and-paste unless you enjoy memorizing hex digits.

> situations where this *will* be ignored.

Very likely, but we must warn people anyway. However...

On 16/02/2016 19:43, Fernando Gont wrote:
...
> you want such prefixes to be "stable" --

This is an important point. In some contexts like a SOHO network, we
surely want any usage of ULAs to be fully automatic, even autonomic,
with no human intervention - dynamic DNS, automatic prefix assignment,
etc. So it's fine if replacing the CPE generates a new ULA prefix.
But in other contexts, such as a large enterprise network wishing
to use ULAs for all traffic inside the firewall, a fully automatic
solution may be unreasonable and we want the ULA prefix to be perennial.
In that case it needs to be handled by the same address management
mechanism or IPAM tool that's used for PA or PI prefixes.

This is a topic that we partly discussed in 6renum (RFC 6879and 7010).

   Brian

---

From: "Liubing (Leo)" <[email-masked]>
Date: Wed, 17 Feb 2016 08:25:50 +0000

Hi Fernando,

> > services/functions such as HTTP, DNS etc., and they might not have the
> > requirement to talk to the nodes in the public Internet.
> 
> This is more clear than the text in the I-D. I'd suggest you appy this to the
> I-D.
[Bing] Ok, thanks.

> >> that the prefix is alwas manually configured (in the routers sending
> >> the RAs).
[Bing] Ok, this is a useful note which could be included in the text. 

> protocol. It's better to use names rather than addresses. So I'd remove the
> comment on using the addresses as identifiers in the upper layer protocol.
[Bing] I agree it's a layer violation in general consideration, although sometimes it really works. Maybe in the next version I don't rank it as "beneficial", but as controversial, just like the ULA+NPTv6 case.

Thank again for your valuable comments.

Best regards,
Bing

---

From: "Liubing (Leo)" <[email-masked]>
Date: Wed, 17 Feb 2016 09:13:57 +0000

Hi Dale,

Thanks much for your elaborating explanation. 
Replies inline.

> To clarify, to mitigate the ULA prefix overlap internally after a merger of two
> internal networks, nothing related to off-site connectivity.  We have had
> this issue at our site on ipv4 when our healthcare system and campus
> first-hand experienced getting burned I hope we can emphasize the risk to
> avoid poorly chosen ULA prefixes in non-trivial (more than just a CPE)
> networks.

> I was going to make a similar comment that I initially withheld about section
> "6.1. Used in Isolated Networks" to which I would claim isolation, though
> often well-intended in my experience ends up being temporary when it is
> found that devices later need external software updates, control, logging, or
> ancillary support systems for which proxying is too hard.
> 
> If it's not obvious I do not like ULA at all, and I know a lot of the arguments
> have already been hashed out.  I am hoping that this guidance can at least
> be clear about the corners that people will (in my mind) inevitably back
> themselves into so it can be avoided.  There's a lot of value getting that
> out.

[Bing] From your above comments, I read two warnings:
1. Warning people that when they use human-friendly/poorly-chosen ULA prefixes, it might result in renumbering or ULA-to-ULA NAT if collision happens when sites merging.
2. Warning people that isolation would be probably temporary, when connected, they either deal with ULA+PA, or they'll have to let NAT/proxy involved.

In current Section 4.1, there is some text discuss the two points a bit, but I think the text needs to be tilt up and be put at a more noteworthy place in the next version. Thanks for raising these issues up.

Best regards,
Bing

---

From: Owen DeLong <[email-masked]>
Date: Wed, 17 Feb 2016 15:30:33 -0800

> On Feb 15, 2016, at 23:51 , [email-masked] wrote:
> 

You’re supposed to randomly select a /48 from fc00::/7

You’re not required to number randomly within the /48.

If you need multiple /48s, then you should select multiple /48s at
random.

Read RFC4193 for further clarification.

> Which means I'd probably ignore the above sentence of never doing

Perhaps clarification that it is only the top 41 bits of the prefix that
are randomized would help?

Perhaps not. I’m still trying to wrap my head around a case where ULA is
somehow more useful than GUA and failing.

> situations where this *will* be ignored.

Then it should be as clear as possible to people that choose to do so that
they are pointing a loaded gun at their own foot and they should exercise
caution in pulling the trigger.

Owen

---

From: Tom Coffeen <[email-masked]>
Date: Wed, 17 Feb 2016 15:52:08 -0800

> You’re supposed to randomly select a /48 from fc00::/7

My understanding from RFC4193 is that the L bit (8th MSB) is not yet
defined (i.e., not "locally defined") when set to 0. Should this impact at
all one's confidence in allocating /48s from fc00::/8?

Tom

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 18 Feb 2016 13:19:08 +1300

> all one's confidence in allocating /48s from fc00::/8?

You should only allocate in fd00::/8. fc00::/8 is reserved for future use.
I think this detail should be added to the IANA registry, which only
mentions fc00::/7 .

   Brian

---

From: Owen DeLong <[email-masked]>
Date: Wed, 17 Feb 2016 16:25:29 -0800

Correct… Technically it should be from fd00::/8, but since fc00::/8 has been rendered into an undefined state as a result of I-D expiration without consensus of one of three I-Ds in a 3-part harmony of I-Ds, and since ULA to begin with is pretty much YAFBS (Yet Another Form of Bogon Space), I’m not sure that little technicality has much meaning in the real world.

Owen

> On Feb 17, 2016, at 15:52 , Tom Coffeen <[email-masked]> wrote:
> 
> On Wed, Feb 17, 2016 at 3:30 PM, Owen DeLong <[email-masked] <mailto:[email-masked]>> wrote:
> 
> > On Feb 15, 2016, at 23:51 , [email-masked] <mailto:[email-masked]> wrote:
> >
> My understanding from RFC4193 is that the L bit (8th MSB) is not yet defined (i.e., not "locally defined") when set to 0. Should this impact at all one's confidence in allocating /48s from fc00::/8?
> 
> Tom

---

From: Mark Andrews <[email-masked]>
Date: Thu, 18 Feb 2016 11:35:03 +1100

In message <[email-masked]>
> all one's confidence in allocating /48s from fc00::/8?

fc00::/8 is reserved - DO NOT USE
fd00::/8 is where you should be generating your prefixes in.

If you need to simulate a /32 then generate bits 9..32 randomly and
prefix with 11111101.  Repeat if you are simulating more than one
ISP.

There is never a valid case for not generating the high bits randomly.
You don't get "nice" upper bits from RIR's unless you are very lucky.

Mark

---

From: Tom Coffeen <[email-masked]>
Date: Wed, 17 Feb 2016 16:52:11 -0800

On Wed, Feb 17, 2016 at 4:35 PM, Mark Andrews <[email-masked]> wrote:

>
> In message <
> [email-masked]>
> , Tom Coffeen writes:

Thanks. The consensus tracks with my prior understanding (and should
prevent any unintended confusion with fc00::/7 mentioned as a source for
ULA /48s).

Also FWIW, I'm with Bing that, when using a ULA /48, 16 bits should be
enough "headroom" for a sufficiently flexible intrasite address plan.

Tom