Subject: [v6ops] ULA Usage Guide draft requesting for review

From: "Liubing (Leo)" <[email-masked]>
Date: Mon, 25 Feb 2013 13:15:11 +0000

Hi, all

I submitted a new version draft, it is about analysis and recommendations of using ULA.
This document was once presented in v6ops @ietf82, I delayed this work due to personal arrangement.

This new version changes not a few including the title, according to the comments received in the meeting and the mailing list.
The draft is to supplement the ULA definition [RFC4193], since there are people confusing about using ULA. The purposes of the draft are:
- discussing scenarios, providing guide of where to beneficially using ULA, let more people know ULA is a useful tool in some cases
- eliminating the misunderstanding of treating ULA equals to IPv6 version of [RFC1918] (Private IPv4 address space) 

Please read the draft and comment. 
URL:             http://www.ietf.org/internet-drafts/draft-liu-v6ops-ula-usage-analysis-05.txt
Status:          http://datatracker.ietf.org/doc/draft-liu-v6ops-ula-usage-analysis
Htmlized:        http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analysis-05
Diff:            http://www.ietf.org/rfcdiff?url2=draft-liu-v6ops-ula-usage-analysis-05Many thanks!

All the best,
Bing

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, February 25, 2013 8:47 PM
To: Liubing (Leo)
Cc: [email-masked]; Sheng Jiang
Subject: New Version Notification for draft-liu-v6ops-ula-usage-analysis-05.txt

A new version of I-D, draft-liu-v6ops-ula-usage-analysis-05.txt
has been successfully submitted by Bing Liu and posted to the
IETF repository.

Filename:	 draft-liu-v6ops-ula-usage-analysis
Revision:	 05
Title:		 Guidance of Using Unique Local Addresses
Creation date:	 2013-02-25
Group:		 Individual Submission
Number of pages: 10
URL:             http://www.ietf.org/internet-drafts/draft-liu-v6ops-ula-usage-analysis-05.txt
Status:          http://datatracker.ietf.org/doc/draft-liu-v6ops-ula-usage-analysis
Htmlized:        http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analysis-05
Diff:            http://www.ietf.org/rfcdiff?url2=draft-liu-v6ops-ula-usage-analysis-05

Abstract:
   This document provides guidance of how to use ULA. It analyzes ULA
   usage scenarios and recommends use cases where ULA address may be
   beneficially used.

The IETF Secretariat

---

From: Victor Kuarsingh <[email-masked]>
Date: Mon, 25 Feb 2013 08:29:27 -0500

Liubing,

I agree in general with this type of draft/document.  ULAs have caused
quite a bit of confusion from what I have seen and many folks are hesitant
to use them for valid parts of they deployment.

I think a draft which provides useful guidance as to how they can be used
is very useful.  I need to however do a more thorough read through for
better comments/feedback, but here is all I have for now.

- the point in section 2.2.2.1 regarding the notion that ULA != RFC1918
should be moved, or also made in the introduction.  I think this is an
important point.

Regards,

Victor Kuarsingh

On 2013-02-25 8:15 AM, "Liubing (Leo)" <[email-masked]> wrote:

>This new version changes not a few including the title, according to the
>comments received in the meeting and the mailing list.
>The draft is to supplement the ULA definition [RFC4193], since there are
>people confusing about using ULA. The purposes of the draft are:
>- discussing scenarios, providing guide of where to beneficially using
>ULA, let more people know ULA is a useful tool in some cases
>- eliminating the misunderstanding of treating ULA equals to IPv6 version
>of [RFC1918] (Private IPv4 address space)
>
>URL:             
>http://www.ietf.org/internet-drafts/draft-liu-v6ops-ula-usage-analysis-05.
>txt
>Status:          
>http://datatracker.ietf.org/doc/draft-liu-v6ops-ula-usage-analysis
>Htmlized:        
>http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analysis-05
>Diff:            
>http://www.ietf.org/rfcdiff?url2=draft-liu-v6ops-ula-usage-analysis-05Many
> thanks!
>
>All the best,
>Bing
>
>Subject: New Version Notification for
>draft-liu-v6ops-ula-usage-analysis-05.txt
>
>
>URL:             
>http://www.ietf.org/internet-drafts/draft-liu-v6ops-ula-usage-analysis-05.
>txt
>Status:          
>http://datatracker.ietf.org/doc/draft-liu-v6ops-ula-usage-analysis
>Htmlized:        
>http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analysis-05
>Diff:            
>http://www.ietf.org/rfcdiff?url2=draft-liu-v6ops-ula-usage-analysis-05
>
>Abstract:
>_______________________________________________
>v6ops mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/v6ops

---

From: Arturo Servin <[email-masked]>
Date: Mon, 25 Feb 2013 21:57:56 +0800

+1

	I apologize though. I haven't read this version of the draft (I did the
previous one and I was not very convinced) but I support to make
emphasis in this.

> should be moved, or also made in the introduction.  I think this is an

/as

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 26 Feb 2013 01:36:17 +0000

Hi, Victor

Thanks for your support and the suggestion, I'll do it in the next version.

B.R.
Bing

> From: Victor Kuarsingh [mailto:[email-masked]]
> Sent: Monday, February 25, 2013 9:29 PM
> To: Liubing (Leo); [email-masked]
> Subject: Re: [v6ops] ULA Usage Guide draft requesting for review
> 
> Liubing,
>

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 26 Feb 2013 01:56:50 +0000

Hi, Arturo

This version took in some valuable comments, key points are:
- clearly state ULA!=RFC1918
- make clear recommendations of where to beneficially used

Your review and comments would be appreciated very much.

B.R.
Bing

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Arturo Servin
> Sent: Monday, February 25, 2013 9:58 PM
> To: [email-masked]

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 26 Feb 2013 01:59:04 +0000

Hi, Mark

Thanks for the correction. Will do in the next version.

B.R.
Bing

> From: Mark Andrews [mailto:[email-masked]]
> Sent: Tuesday, February 26, 2013 4:21 AM
> To: Liubing (Leo)
> Old:
>    ULA is a useful tool, it have been successfully deployed in a diverse
> 
> New:
>    ULA is a useful tool, it has been successfully deployed in a diverse
> 
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Owen DeLong <[email-masked]>
Date: Wed, 27 Feb 2013 17:42:55 -0800

Sorry for the delay… Just now getting to this.

Section 1.

Paragraph 1

"…normally they are not used on the publicly routable…"

Suggest should be changed to "…they should not be used on the publicly routable…"

Paragraph 3

"…networks has been confused for network operators."

Suggest should be changed to "…networks has been confusing to network operators."

Paragraph 3

"…while network operators run their entire networks on ULA.."
Can you cite some examples of this? I can't imagine a functional network running entirely on ULA unless it is a completely disconnected network.

Section 2.1.2

Paragraph 1

"ULA is intended to be globally unique to avoid collision"

Suggest should be changed to "ULA is intended to have a low probability of collision, but uniqueness is not guaranteed."

Also paragraph 1

"…Overlapping is cited as a deficiency with how [RFC1918] addresses were deployed, and ULA was designed to overcome this deficiency."

This is somewhat revisionist history IMHO. The whole point of RFC-1918 was to provide overlapping addresses for non-connected and NAT-based networks to allow IPv4 address conservation. Prior to the need for address conservation and re-use in IPv4, no one saw any need for anything like RFC-1918 or ULA. Indeed, I still, even after reading this draft don't see a use case for ULA that would not be served equally well (if not better) by GUA.

Section 2.1.3

Paragraph 2

"On the other hand, many organizations have security policies and architectures based around the local-only routing of [RFC1918] addresses and those policies may directly map to ULA."

Any security policy which depends on the semantics of [RFC1918] is flawed. Routing leaks of [RFC1918] space are commonplace and there are many "crafted packet" attacks perfectly capable of delivering datagrams to [RFC1918] based networks. Any pretense that [RFC1918] is a security mechanism is fictional and should not be codified in an RFC, IMHO.

Section 2.2.2.1

IMHO, this section should be deleted in its entirety or at least come with a strong cautionary note that such designs are ill-conceived and detrimental in nature. Pretending that NAT or NPT improve security at all is dubious at best. In fact, NPT and especially NAT provide more tall weeds for attackers to hide in, if anything.

AL Proxies can be implemented equally effectively using GUA and there is no significant advantage to ULA in such a case.

Section 3.1

The last sentence should be deleted. GUA is an equally viable option for these networks.

Section 3.3.2

I'm unable to decipher Paragraph 2, so I cannot make a suggestion on rewording it. However, since I can't tell what you're trying to say, I'm pretty sure it needs to be rewritten.

Section 5

IANA considerations should be updated to point to RFC4193 in a similar manner to section 4.

[End of comments]

Owen

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Feb 2013 08:50:26 +0000

Owen,

On 28/02/2013 01:42, Owen DeLong wrote:
...
> Suggest should be changed to "ULA is intended to have a low
> probability of collision, but uniqueness is not guaranteed."

The best thing for this point is to refer to the extensive
discussion in RFC 4193, where it is shown that the probability
of collision is extremely low.

> 
> Also paragraph 1
> 
> "…Overlapping is cited as a deficiency with how [RFC1918]
> addresses were deployed, and ULA was designed to overcome
> this deficiency."
> 
> This is somewhat revisionist history IMHO. The whole point of
> RFC-1918 was to provide overlapping addresses for
> non-connected and NAT-based networks to allow IPv4 address
> conservation. Prior to the need for address conservation and
> re-use in IPv4, no one saw any need for anything like
> RFC-1918 or ULA. Indeed, I still, even after reading this
> draft don't see a use case for ULA that would not be served
> equally well (if not better) by GUA.

Well, there are arguments for stable, non-ISP-dependent and
non-registry-dependent prefixes, but we don't have to justify
ULAs in this draft: that was done by RFC 4193.

I think that the disconnected-network and homenet scenarios need
to be further explored in this draft.

> 
> Section 2.1.3
> 
> Paragraph 2
> 
> "On the other hand, many organizations have security policies
> and architectures based around the local-only routing of
> [RFC1918] addresses and those policies may directly map to
> ULA."
> 
> Any security policy which depends on the semantics of
> [RFC1918] is flawed. 

That whole question is explored in RFC 4864, as well as
the extent to which ULAs fit in. But the objective fact is
as stated here: many organizations base their security
on RFC 1918. I don't like it, you don't like it, but it's
the real world.

> 
> Section 2.2.2.1
> 
> IMHO, this section should be deleted in its entirety or at
> least come with a strong cautionary note that such designs
> are ill-conceived and detrimental in nature. Pretending that
> NAT or NPT improve security at all is dubious at best. In
> fact, NPT and especially NAT provide more tall weeds for
> attackers to hide in, if anything.

Same comment. We could certainly give pros and cons, but it
would be misleading to pretend that such deployments won't
happen.

> AL Proxies can be implemented equally effectively using GUA
> and there is no significant advantage to ULA in such a case.

Well, you can avoid renumbering, and multihome without PI,
for a start.

> option for these networks.

Only if you have an ISP, which by definition you don't.

    Brian

---

From: Owen DeLong <[email-masked]>
Date: Thu, 28 Feb 2013 01:23:48 -0800

> of collision is extremely low.

I'd be fine with that as an alternative as well, but the current language
fails.

> ULAs in this draft: that was done by RFC 4193.

I've heard the arguments and I remain somewhat unconvinced.
However, as you say, 4193 is already on the books, so this draft
doesn't need to be a commercial.

> to be further explored in this draft.

Agreed.

FWIW, My homenet has a stable non-ISP-dependent prefix and
it works just fine. (2620:0:930::/48)

> on RFC 1918. I don't like it, you don't like it, but it's

No, they don't. They base their security on stateful inspection.

They don't realize that the mutilation of the packet header doesn't
actually help their security beyond its default stateful inspection
behavior, but, the reality is that the stateful inspection behavior
is what provides security. Without that behavior, (for example,
an NPT that doesn't maintain a state table), there is no security.

However, there are still additional tall weeds for the bad guys
to hide in provided by the obfuscation layer.

> would be misleading to pretend that such deployments won't

Then Let's put a strong cautionary not in and acknowledge that
in spite of our best efforts at education, people will do profoundly
dumb things.

> Well, you can avoid renumbering, and multihome without PI,

What is the significant benefit to "without PI"?

PI seems to be very nice as near as I can tell. It is working very
well here.

> Only if you have an ISP, which by definition you don't.

?? I know of a number of networks that are using GUA for those
purposes without involving an ISP. Could you explain why you
think that's not possible?

Owen

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Feb 2013 11:29:48 +0000

...
> What is the significant benefit to "without PI"?

Saving BGP4. Using a PI prefix is selfish as far as the
Internet is concerned, so we need to encourage alternatives.

> think that's not possible?

You need to get your prefix either from an ISP or from an LIR.
You don't need to talk to anyone, or pay anyone, to get your ULA
prefix. In fact, it can be generated automatically in a SOHO
scenario, so that the user doesn't have to know anything.

   Brian

---

From: Victor Kuarsingh <[email-masked]>
Date: Thu, 28 Feb 2013 07:51:27 -0500

>to hide in provided by the obfuscation layer.

Where I agree that blind/basic policy around RFC1918 is poor, I think
there is some validity in having well known ranges and applying certain
types of perimeter and routing protection around it.

Speaking from an SP view, there are many functions which are served well
by RFC1918 and with some loose association to ULAs (can be used for
equivalent function).

If a network admin uses ULAs for certain functions, it's a lot easier to
filter/protect agains a well known contiguous range.  However, other
security mechanisms need to be in place - basic filtering is a poor single
form of security.

One of the comments I had before on this draft was that the notion of ULA
!= RFC1918 is an important distinction (hopefully that would get network
administrators to re-think any loose security they may have around RFC1918
before applying it to ULAs if used).

Regards,

Victor K

---

From: Victor Kuarsingh <[email-masked]>
Date: Thu, 28 Feb 2013 08:01:34 -0500

>Internet is concerned, so we need to encourage alternatives.

PA space can be applied to a network, distributed, routed and provided to
customers in a very efficient manner.    It's actually quite easy to apply
and route IPv6 PA space very efficiently in a large network.

PI space diverges from this and lives on it's own along side all the PA
optimizations.  This is a bit outside the context of the ULA draft, but
just throwing my opinion out there on this topic.

Regards,

Victor K

---

From: Owen DeLong <[email-masked]>
Date: Thu, 28 Feb 2013 12:14:32 -0800

> Internet is concerned, so we need to encourage alternatives.

We can agree to disagree. We eventually need to come up with a scaleable routing solution.

In the meantime, if we do IPv6 right, we'll have a much smaller routing table even with
many thousands of new multi-homers using PI.

> scenario, so that the user doesn't have to know anything.

Sure, there are tradeoffs either way. It's really pretty easy to get
IPv6 space from an RIR, so I really don't see circumventing the RIR
process as being a particularly significant benefit.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Thu, 28 Feb 2013 12:19:40 -0800

> by RFC1918 and with some loose association to ULAs (can be used for

Speaking as someone who has had many different roles at many different SPs over
the years, I've never found a need for RFC-1918 in the SP environment.

> security mechanisms need to be in place - basic filtering is a poor single

Actually, not so much. It' a lot easier to filter/protect against a
contiguous range. This is further easier if the range is well known
within the filtering domain. There is no benefit to the range being well
known outside of the filtering domain. A /48 carved out of one's GUA would
serve equally well to a /48 from ULA. If you really were concerned about
ease of identification, it wouldn't be hard to get a non-contiguous /48
for that purpose.

> before applying it to ULAs if used).

My concern is that I do not want to see IETF putting out documents that
encourage the use of NPT or other hacks that were made necessary by IPv4
address shortage and are particularly disruptive in the IPv6 world with
little or no benefit.

Owen

---

From: Victor Kuarsingh <[email-masked]>
Date: Thu, 28 Feb 2013 16:14:25 -0500

>the years, I've never found a need for RFC-1918 in the SP environment.

DOCSIS Modem addressing is served well by RFC1918.  They are IP managed,
but have no need to have outside world communication (in fact you don't
want people getting to them).  RFC1918 fit well and did not require such
operators to go to the trough for global addresses for a function that had
not global connectivity requirements.

ULAs can play a similar role in this case given the devices have no global
connectivity requirement and fit into existing rules which are put on the
perimeter anyway.

There is also an operational simplicity associated with having a
distinctive range which can be looked after (filtered, policed and
managed) by various groups.

I understand this may not apply to all SPs, but I would suggest valid use
cases do exist. 

I agree, however, that I don't want valid use cases of ULA usage to turn
into a world where you see massive deployment of ULAs with NPT as the glue
to the Internet for endpoints that require global connectivity.

Regards,

Victor K

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 28 Feb 2013 21:27:38 +0000

> >>Speaking from an SP view, there are many functions which are served
> >>well by RFC1918 and with some loose association to ULAs (can be used
> >>for equivalent function).
> >
> >Speaking as someone who has had many different roles at many different
> >SPs over the years, I've never found a need for RFC-1918 in the SP
> >environment.
> 
> operators to go to the trough for global addresses for a function that had not
> global connectivity requirements.
> 
> There is also an operational simplicity associated with having a distinctive
> range which can be looked after (filtered, policed and
> I understand this may not apply to all SPs, but I would suggest valid use cases
> do exist.
> 
> I agree, however, that I don't want valid use cases of ULA usage to turn into a
> world where you see massive deployment of ULAs with NPT as the glue to
> the Internet for endpoints that require global connectivity.

I agree with Victor. I'm aware of SPs who include support for RFC1918 numbers for LAN addressing in "Residential Gateways" that they ship to consumers, as well as using RFC1918 addresses in closed management system networks. In the case of the LAN, consumers seem to like for their home network to operate properly in the complete absence of WAN/Internet connectivity. The closed management system networks are not intended to be connected to the Internet, ever.
Barbara

---

From: Owen DeLong <[email-masked]>
Date: Thu, 28 Feb 2013 16:28:46 -0800

On Feb 28, 2013, at 13:14 , Victor Kuarsingh <[email-masked]> wrote:

>> SPs over

Comcast disagrees with you... RFC-1918 was far too small.

Admittedly, ULA doesn't have that problem, but, neither would a /48 or /32 or
whatever set aside from GUA for that purpose.

> connectivity requirement and fit into existing rules which are put on the

They don't fit into existing rules, they need new rules. ULA does not match
10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16. You have to apply an additional
rule for fc00::/7.

> managed) by various groups.

Yes. I've already agreed with this. My point is that it is irrelevant whether that
distinctive range is fc00::/7 or some fraction of GUA space assigned uniquely
to the organization.

> I understand this may not apply to all SPs, but I would suggest valid use

I would suggest use cases exist. Validity is a loaded term on which we are
unlikely to agree. I did not, however, say that the use cases were invalid.
I merely said they could be served equally well (or better) by GUA.

> to the Internet for endpoints that require global connectivity.

Right.

Any draft advocating ULA usage MUST, IMHO, include something to this effect.

If it's in the current draft, I missed it.

Owen

---

From: joel jaeggli <[email-masked]>
Date: Thu, 28 Feb 2013 16:40:22 -0800

>> Internet is concerned, so we need to encourage alternatives.
Strictly speaking PI holders are not the obnoxious polluters in the 
routing system to today. there are ~43K AS in my internet today. 
somewhat less then half of them announce only one route yet there are 
445K routes in my ipv4 table.

Is is plausble to assert that there a potentially a lot more multihomers 
out there then there are ISPs. but when you have something like AS FOO 
that announces ~3k routes that could be maximally aggregated as 9 routes 
well there you are, why is bgp4 being destroyed again?

---

From: Victor Kuarsingh <[email-masked]>
Date: Thu, 28 Feb 2013 21:33:46 -0500

On 2013-02-28 7:28 PM, "Owen DeLong" <[email-masked]> wrote:

>>>>well

I don't think they disagree, they just ran out of RFC1918 due to number of
modems.  I don't think that invalidates the use of it for this purpose.
Even if some very large operators ran out of RFC1918 and had to supplement
with globals, the majority of DOCSIS operators were good with RFC1918 and
did not stress the global pools needlessly (in IPv4 land).

>10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16. You have to apply an additional

I think (opinion alert) most operators will put in rules for ULAs on the
perimeter similar to RFC1918.  So if those rules are in place anyway, then
it works quite well.  I suspect I have no need to accept ULA routes or
traffic from outside the AS, so those rules will be in.  Exceptions (if
any) can be managed as exceptions.

> My point is that it is irrelevant whether that

True.  But if you are putting in rules for ULAs anyway, then it's simpler
then adding more space and rules (I guess this will be an operator by
operator evaluation).  Also fc00::/7 is massive, so one can carve out many
::/48 as needed over time and still fit into a clean rule.  Carving out
::/48s from GUA space may get messy if it's not contiguous.  Not that it's
impossible to manage dis-contiguous block ranges, but the cleaner the
rules, the easier it is to maintain.  I am not suggesting one architect
based on simplicity, but if there is no good reason not to use it.. then I
default to simple.

But I do agree with the notion that text needs to be present to make sure
the end reader understands the potential issues with using ULA space (if
we are going to give people rope, let's help them not tie a noose).

Victor K

---

From: Owen DeLong <[email-masked]>
Date: Thu, 28 Feb 2013 19:27:24 -0800

> any) can be managed as exceptions.

I think that will be true until customer A and customer B want to talk to
each other's ULAs over provider C and then those rules will get an
exception added. And then E and F will come along. Pretty soon, the
ULA rules end up looking like swiss cheese.

> based on simplicity, but if there is no good reason not to use it.. then I

Big if. See above. ULA rules are going to become complicated and
error prone in the future, IMHO.

Integrating your internal security into that customer quagmire seems
ill advised at best to me.

> we are going to give people rope, let's help them not tie a noose).

At least we agree on this.

Owen

---

From: Mark Andrews <[email-masked]>
Date: Fri, 01 Mar 2013 14:59:01 +1100

In message <[email-masked]>, Owen DeLong write
> ULA rules end up looking like swiss cheese.
 
In which case customer A and customer B create a VPN using PA/PI
addresses.  The ISP doesn't need to be, nor should it be, involved.
Or better still they use PA/PI addresses to talk to each other.
ULA are a adjuct to PA/PI not a alternative.

---

From: Owen DeLong <[email-masked]>
Date: Thu, 28 Feb 2013 21:51:25 -0800

> ULA are a adjuct to PA/PI not a alternative.

I certainly hope so. Let's see how it plays out in the real world.

Owen

---

From: "Liubing (Leo)" <[email-masked]>
Date: Fri, 1 Mar 2013 07:56:53 +0000

Hi, Owen

Thanks for your detailed review, it would help to improve the draft a lot.
Please see replies inline.

> From: Owen DeLong [mailto:[email-masked]]
> Sent: Thursday, February 28, 2013 9:43 AM
> To: Victor Kuarsingh
> Cc: Liubing (Leo); [email-masked]
> Sorry for the delay... Just now getting to this.
> 
> Section 1.
> 
> Paragraph 1
> 
> "...normally they are not used on the publicly routable..."
> 
> Suggest should be changed to "...they should not be used on the publicly
> routable..."
[Bing] Ok, will do.

> 
> Paragraph 3
> 
> "...networks has been confused for network operators."
> 
> Suggest should be changed to "...networks has been confusing to network
> operators."
[Bing] Ok
> 
> Paragraph 3
> 
> "...while network operators run their entire networks on ULA.."
> Can you cite some examples of this? I can't imagine a functional network
> running entirely on ULA unless it is a completely disconnected network.

[Bing] In some environments (e.g. information security sensitive enterprise or government), the endpoints are default disconnected to the Internet, and need the proxies to connect. In IPv4, RFC1918+proxies is an effective practice for this purpose, and it is natural to pick ULA in IPv6.  In last time discussion someone just feedback they were using ULA-only+Proxy in their lab networks. However, this was not an official production operating. I can delete the sentence here or add some description in the scenarios section.  

> Suggest should be changed to "ULA is intended to have a low probability of
> collision, but uniqueness is not guaranteed."

[Bing] I'll refer RFC4193 for more accurate description.

> Also paragraph 1
> 
> "...Overlapping is cited as a deficiency with how [RFC1918] addresses were
> deployed, and ULA was designed to overcome this deficiency."
> 
> This is somewhat revisionist history IMHO. The whole point of RFC-1918 was
> to provide overlapping addresses for non-connected and NAT-based
> networks to allow IPv4 address conservation. Prior to the need for address
> conservation and re-use in IPv4, no one saw any need for anything like
> RFC-1918 or ULA. Indeed, I still, even after reading this draft don't see a use
> case for ULA that would not be served equally well (if not better) by GUA.
> 

[Bing] I also agree Brian's comment: "I think that the disconnected-network and homenet scenarios need to be further explored in this draft." Will do in the next version. Thanks.

> Section 2.1.3
> 
> Paragraph 2
> 
> "On the other hand, many organizations have security policies and
> architectures based around the local-only routing of [RFC1918] addresses
> and those policies may directly map to ULA."
> 
> Any security policy which depends on the semantics of [RFC1918] is flawed.
> Routing leaks of [RFC1918] space are commonplace and there are many
> "crafted packet" attacks perfectly capable of delivering datagrams to
> [RFC1918] based networks. Any pretense that [RFC1918] is a security
> mechanism is fictional and should not be codified in an RFC, IMHO.

[Bing] I'll reply this after reviewing RFC4864.

> Section 2.2.2.1
> 
> IMHO, this section should be deleted in its entirety or at least come with a
> strong cautionary note that such designs are ill-conceived and detrimental in
> nature. Pretending that NAT or NPT improve security at all is dubious at best.
> In fact, NPT and especially NAT provide more tall weeds for attackers to hide
> in, if anything.

[Bing] Such designs come from special requirements such as the abovementioned information security sensitive enterprises or governments. If you want the endpoints disconnected as default and only connected via central control, it is quite reasonable to pick ULA+Proxy. 
However, normally we won't recommend to use ULA in this model. But I think it might not be proper to justify such scenarios as ill. My point is: if you really have special requirements, just use it in this model; but please don't misunderstanding ULA was just designed for this kind of use.

> AL Proxies can be implemented equally effectively using GUA and there is no
> significant advantage to ULA in such a case.

[Bing] If require endpoints default disconnected, egress filtering would be easier and more stable for ULA than GUA. And can save some operation to apply PA/PI.

> I'm unable to decipher Paragraph 2, so I cannot make a suggestion on
> rewording it. However, since I can't tell what you're trying to say, I'm pretty
> sure it needs to be rewritten.

[Bing] It is only a corner case, that is, if the NAT64 prefix is shorter than 48/, it would divide the 40bit of ULA into two parts. But in most of the practices NAT64 just use 96/. I'll rewritten it for ease of reading. 

> IANA considerations should be updated to point to RFC4193 in a similar
[Bing] Ok, thanks.