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

From: Ron Bonica <[email-masked]>
Date: Wed, 11 Jan 2017 15:39:27 +0000

Folks,

D raft-ietf-v6ops-ula-usage-considerations was introduced 3.5 years ago, but has made little progress in the last year. Therefore, it become necessary for the chairs to reevaluate whether this draft should continue to be a WG item.

If you have an opinion on this subject, please post it to the mailing list by 1/25/17. Options are:

1) Continue to work on the draft with an eye toward publication in 2017
2) Allow the draft to expire

Silence or limited response will be interpreted as a lack of interest in the draft.

                                            Ron, Lee and Fred

---

From: Mark Smith <[email-masked]>
Date: Thu, 12 Jan 2017 06:20:07 +1100

Hi,

I think it would should be continued to be worked on and published.

I know of a Smartgrid Mesh network with around 200k+ meters on it that is
using ULA addresses. However, from memory they used a single prefix shorter
than a /48 rather than multiple /48s, losing random part bits. A document
such as this could provide advice on scenarios such as this.

Regards,
Mark.

On 12 Jan. 2017 2:39 am, "Ron Bonica" <[email-masked]> wrote:

> Folks,
>
> D raft-ietf-v6ops-ula-usage-considerations was introduced 3.5 years ago,
> but has made little progress in the last year. Therefore, it become
> necessary for the chairs to reevaluate whether this draft should continue
> to be a WG item.
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Jan 2017 09:31:19 +1300

Agreed. ULAs just work in simple scenarios, but running with multiple
prefixes should be standard practice for IPv6 so we need to tie down
the loose ends.

    Brian

---

From: joel jaeggli <[email-masked]>
Date: Wed, 11 Jan 2017 18:03:54 -0800

For me personally, the presence of npt6 or indeed any form of ula only
deployment, save  perhaps for ephemeral private networks is a bright
line not to be crossed. I find it hard to support a document that treats
the subject without recommending never to do those things.

joel

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 11 Jan 2017 21:36:47 -0500

Ron, et al,

I would go for option 1, but with modifications to content of draft.

My perspective is that there is utility in describing real world
[valid] use cases of ULAs, however, avoiding statements of scenarios
which we know are problematic (unless we specifically describe the
situation/use case, then note - "this is considered to be harmful" or
preferably text which explains why it's limiting or harmful)

Given ULAs are out there, and more networks may wind up having them
inserted, providing information on usage of such addresses (especially
noting known issues) may help avoid inappropriate use of such
addresses.  Sure, some may still do it, but we can't stop that.

Use cases such as ULAs in Isolated networks (and/or nodes/hosts which
have no Internet connectivity requirements) is a valid use case in my
mind and we have working examples where this can be valuable in
networks.  There are however uses cases in section 4.2.1 and 4.2.2
which can still be described, but perhaps we should spend less text
discussing the benefits here and stress the drawbacks (e.g. "Ease of
Management" as a support to use ULAs is weak as a need to use them,
and given it would then need some form of translation to connect those
hosts to the Internet is adding more burden then benefit by my
calculations).

Just because we know the issues people can get themselves into with
using ULAs should not limit us form documenting good/valid uses of
such and also highlighting the dangers of other cases.

regards,

Victor K

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Jan 2017 15:52:12 +1300

> the subject without recommending never to do those things.

I agree with that and with Victor's comment. But do you think we could
elevate this to BCP? I'm not comfortable that we have enough experience
to do that.

    Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 12 Jan 2017 14:12:46 +0900

Right. ULA-only deployments and (worse) ULA+NPTv6 for multihoming are very
contentious points and are part of the reason this document has been around
for so long.

Some WG participants, including the authors would like to document these
scenarios, but other participants (not just Joel; I remember quite a line
at the mike in Yokohama, and I was one of them) are not willing to see this
document published without strong language recommending against such
deployments.

I don't think the people who oppose ULA-only deployments have changed their
minds in any meaningful way since then. It's possible that this time around
it will be easier to reach a compromise, but I wouldn't bet on it.

I agree with Brian that we don't have enough operational experience for
this document to be a BCP. There are no case studies in this document, and
I am not aware of any publicly-available operational reports of substantial
ULA deployments.

On Thu, Jan 12, 2017 at 11:03 AM, joel jaeggli <[email-masked]> wrote:

> > D raft-ietf-v6ops-ula-usage-considerations was introduced 3.5 years
> ago, but has made little progress in the last year. Therefore, it become

---

From: Mark Smith <[email-masked]>
Date: Thu, 12 Jan 2017 20:38:56 +1100

On 12 Jan. 2017 1:04 pm, "joel jaeggli" <[email-masked]> wrote:

I'm nearly in entire agreement with that.

The specific use case I was referring to is an AMI smartgrid network with
the meters only having a ULA address. They never should be reachable from
the Internet, and only need to be reachable to/from their management
applications. Providing them with GUAs, even if protected by a network
firewall somewhere, creates the possibility of reachability to/from the
Internet, which is an unacceptable risk.

Although hosts having and choosing between multiple addresses increases
complexity, I think the ability to create domains of different reachability
based on address types is a useful security feature.

If a host is to have global and local network reachability, give it a GUA
and ULA address. Local reachability only; a ULA only, no GUA. Link only; a
link local address only.

Alternatively, applications can make that choice by choosing which address
type(s) to use to connect with, or to listen to and accept connections from.

Regards,
Mark.

joel

---

From: Fernando Gont <[email-masked]>
Date: Thu, 12 Jan 2017 06:53:51 -0300

Hi, Mark,

On 01/12/2017 06:38 AM, Mark Smith wrote:
> 
> 
> On 12 Jan. 2017 1:04 pm, "joel jaeggli" <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> The specific use case I was referring to is an AMI smartgrid network
> with the meters only having a ULA address. They never should be
> reachable from the Internet, and only need to be reachable to/from their
> management applications. Providing them with GUAs, even if protected by
> a network firewall somewhere, creates the possibility of reachability
> to/from the Internet, which is an unacceptable risk.
> 
> complexity, I think the ability to create domains of different
> reachability based on address types is a useful security feature.

+1

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

---

From: Mark Smith <[email-masked]>
Date: Thu, 12 Jan 2017 20:58:25 +1100

On 12 Jan. 2017 8:54 pm, "Fernando Gont" <[email-masked]> wrote:

Hi, Mark,

> to/from the Internet, which is an unacceptable risk.

And just to make sure it's clear, it's not a hypothetical network.

http://www.silverspringnet.com/article/uncategorized/ausnet-services-selects-silver-spring-networks-for-advanced-metering-roll-out/

+1

Cheers,

---

From: Tim Chown <[email-masked]>
Date: Thu, 12 Jan 2017 15:17:16 +0000

> On 12 Jan 2017, at 02:52, Brian E Carpenter <[email-masked]> wrote:
> 

I agree with Joel, Brian, Lorenzo and Victor’s comments.  

I think work should continue on the document, but as Brian suggests BCP is likely premature; Informational is more appropriate, if we can condense the text towards consensus. 

The challenge is finding the minimum set of messages to include in the document to achieve that consensus to publish.  For example, I’m not comfortable with Section 4.2.1 on NPTv6. But differentiating ULA-only from ULA+GUA is important, as is emphasising the difference between IPv6 ULA and IPv4 RFC1918 assumptions.

Tim

---

From: Victor Kuarsingh <[email-masked]>
Date: Thu, 12 Jan 2017 10:59:53 -0500

Tim/all,

As a way to condense the document and attempt to consolidate the
information.  Would concentrating on the following three models
(listed below) be worth considering?  We can also keep what is
currently section 5 (general considerations) as well.

(1). Isolated Networks.
Brief: potential valid use.  Not intended for (or specifically denied)
Internet connectivity.  We have a couple of solid use cases here, list
key considerations
(2). Multi-homed / Multi-addressed (i.e. ULA+GUA). Brief: potential
valid use, other ways to solve problem (

---

From: Victor Kuarsingh <[email-masked]>
Date: Thu, 12 Jan 2017 11:01:42 -0500

Sorry, pulled trigger too fast on last email.

 (1). Isolated Networks.
 Brief: potential valid use.  Not intended for (or specifically denied)
 Internet connectivity.  We have a couple of solid use cases here, list
 key considerations
(2). Multi-homed / Multi-addressed (i.e. ULA+GUA). Brief: potential
valid use, other ways to solve problem
(3) Internet connected.  Not valid choice, harmful, limiting, avoid.

regards,

Victor K

---

From: james woodyatt <[email-masked]>
Date: Wed, 18 Jan 2017 11:30:05 -0800

On Jan 11, 2017, at 21:12, Lorenzo Colitti <[email-masked]> wrote:
> 
> There are no case studies in this document, and I am not aware of any publicly-available operational reports of substantial ULA deployments.

Reminder: Understanding Apple’s Back to My Mac Service [RFC 6281].

--james woodyatt <[email-masked] <mailto:[email-masked]>>

---

From: "Liubing (Leo)" <[email-masked]>
Date: Mon, 23 Jan 2017 08:08:53 +0000

Hi Victor,

Sorry for the late response. Your following comments are very constructive, thanks a lot.
Please see replies inline.

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of Victor Kuarsingh
> Sent: Friday, January 13, 2017 12:02 AM
> To: Tim Chown
> Cc: [email-masked]
> Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-considerations
> 
> information.  Would concentrating on the following three models  (listed
> below) be worth considering?  We can also keep what is  currently section
> 5 (general considerations) as well.
> 
>  (1). Isolated Networks.
> Internet connectivity.  We have a couple of solid use cases here, list  key
> considerations 

[Bing] I can add another solid use case, which is the ULA addressing of ACP in Anima WG's work. (See https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-05#section-5.8.1 ) This is not only under standardization, but also already in Cisco's commercial products.

Btw, I guess we could make the statement a bit more stronger, that we remove the word "potential"?

(2). Multi-homed / Multi-addressed (i.e. ULA+GUA). Brief:
> potential valid use, other ways to solve problem

[Bing] Agreed. I think the word "potential" is justified here.

> (3) Internet connected.  Not valid choice, harmful, limiting, avoid.

[Bing] The original intention of documenting ULA+NPTv6/Proxy is not to promote such use cases, rather, to consider it as "helpless" choice in some situation. But according to the WG's opinion, I think the justification of ULA+NPTv6/Proxy needs to be more explicit and stronger in this document.

Best regards,
Bing

> >>>> For me personally, the presence of npt6 or indeed any form of ula
> >>>> only deployment, save  perhaps for ephemeral private networks is a
> >>>> bright line not to be crossed. I find it hard to support a document
> >>>> that treats the subject without recommending never to do those
> things.
> >>>
> >>> I agree with that and with Victor's comment. But do you think we
> >>> could elevate this to BCP? I'm not comfortable that we have enough
> >>> experience to do that.
> >>
> >> I think work should continue on the document, but as Brian suggests BCP
> is likely premature; Informational is more appropriate, if we can condense
> the text towards consensus.
> >>
> >> The challenge is finding the minimum set of messages to include in the
> document to achieve that consensus to publish.  For example, I’m not
> comfortable with Section 4.2.1 on NPTv6. But differentiating ULA-only from
> ULA+GUA is important, as is emphasising the difference between IPv6 ULA
> and IPv4 RFC1918 assumptions.
> >>
> >> Tim
> >>
> >>>>
> >>>> joel
> >>>>
> necessary for the chairs to reevaluate whether this draft should continue to
> be a WG item.
> >>>>>
> >>>>>                                            Ron, Lee and
> Fred