Subject: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt

From: [email-masked]
Date: Fri, 14 Feb 2014 01:13:02 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IPv6 Operations Working Group of the IETF.

        Title           : Recommendations of Using Unique Local Addresses
        Authors         : Bing Liu
                          Sheng Jiang
	Filename        : draft-ietf-v6ops-ula-usage-recommendations-02.txt
	Pages           : 15
	Date            : 2014-02-14

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

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-ula-usage-recommendations/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ula-usage-recommendations-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Randy Bush <[email-masked]>
Date: Fri, 14 Feb 2014 18:34:36 +0900

i expected this to be a short draft.  "Don't"

randy

---

From: ek <[email-masked]>
Date: Fri, 14 Feb 2014 19:00:08 +0900

+1

---- On Fri, 14 Feb 2014 18:34:36 +0900 Randy Bush&lt;[email-masked]&gt; wrote ---- 

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

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 15 Feb 2014 14:08:56 +1300

Well, there have always been some people against the existence of ULAs,
but we did reach rough consensus to define them, since other people
see value in them, for reasons that have been aired many times.
So writing words about the best way to use them if you want to use
them seems right to me.

    Brian

On 14/02/2014 23:00, ek wrote:
> ------------------------------------------------------------------------
>

---

From: Sander Steffann <[email-masked]>
Date: Sat, 15 Feb 2014 13:00:20 +0100

Hi,

> So writing words about the best way to use them if you want to use

I think the document is a bit long, but as it describes all the pros/cons in different usage scenarios I think it is necessary to give a balanced view. I think this draft is going to be very useful for operators (many who are new to IPv6 and addicted to RFC1918 addresses so their first idea is ULA+NAT for the entire office) that are planning their IPv6 deployment and need to understand if/how to use ULA. And more importantly: how not to use it. That last bit might need some more emphasis. I think section 3.2.1 is a bit too positive (even though it mentions 'specific situations')

Cheers,
Sander

---

From: Owen DeLong <[email-masked]>
Date: Sat, 15 Feb 2014 10:16:53 -0800

Indeed, the situations where ULA usage is detrimental vastly outnumbers those where it is actually beneficial.

If we're going to move something like this forward, that really should be made clear.

Owen

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 16 Feb 2014 15:41:54 +0100

Le 15/02/2014 19:16, Owen DeLong a écrit :
> Indeed, the situations where ULA usage is detrimental vastly
> outnumbers those where it is actually beneficial.
>

Consider new deployments like IPv6 vehicular networks.

There is an immediate direction to demonstrate an IPv6 vehicle if it 
used ULA.  There is also the alternative to request PI or PA IPv6 
addressing space for these vehicles from some registry, steps which may 
take time.

These two directions are actually head and tail of same snake: it bites 
its end, or otherwise put it's a chicken and egg problem: if the 
deployer sees the prototype works then it may request IPv6 addressing 
space from registry, but not before it sees it works.

At this point I think this draft is good to say that ULAs are useful. 
Later on maybe less so.  But right now that's reflecting real-world 
situation.

That's how I see it, and one's mileage may vary.

But imposing to not do ULA is little reasonable for some test deployments.

Alex
PS:
There are also some intermediary alternatives like IPv4 transitioning 
(6to4 and other tunnels), 64share.  Each has some inconvenients (6to4 
requires both IPv4 and IPv6 on cellular, whereas IPv6-only is easier 
with some operator; 64share only allows one subnet in vehicle).  Also 
one would consider asking the cellular operator to implement DHCPv6 
Prefix Delegation, which may also take time.
>> Well, there have always been some people against the existence of
>> ULAs, but we did reach rough consensus to define them, since other
>> people see value in them, for reasons that have been aired many
>> times. So writing words about the best way to use them if you want
>> to use them seems right to me.
>>
>> Brian
>>
>>> _______________________________________________ v6ops mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>>
>>>
>>>
>>>
>>> v6ops mailing list [email-masked]
>> _______________________________________________ v6ops mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>
>

---

From: Owen DeLong <[email-masked]>
Date: Sun, 16 Feb 2014 10:22:05 -0800

On Feb 16, 2014, at 06:41 , Alexandru Petrescu <[email-masked]> wrote:

> There is an immediate direction to demonstrate an IPv6 vehicle if it used ULA.  There is also the alternative to request PI or PA IPv6 addressing space for these vehicles from some registry, steps which may take time.
> 

It takes about 48 hours to get address space approved from a registry. Even less time to get some from a provider in most cases.

I do not at all buy your argument here.

> These two directions are actually head and tail of same snake: it bites its end, or otherwise put it's a chicken and egg problem: if the deployer sees the prototype works then it may request IPv6 addressing space from registry, but not before it sees it works.
> 
> At this point I think this draft is good to say that ULAs are useful. Later on maybe less so.  But right now that's reflecting real-world situation.
> 

So we disagree. It is not the first time and probably not the last.

> But imposing to not do ULA is little reasonable for some test deployments.

I did not say "don't do ULA". I said that the number of situations where ULA is detrimental vastly outweighs the number where it is useful.

Your description above is one of the few cases where it might not be detrimental. It is not, however, particularly useful vs. PI or PA.

As such, I think it is appropriate for the draft to make it clear that use of ULA should be carefully considered as in most cases it provides greater detriment.

> 
> Alex
> PS:
> There are also some intermediary alternatives like IPv4 transitioning (6to4 and other tunnels), 64share.  Each has some inconvenients (6to4 requires both IPv4 and IPv6 on cellular, whereas IPv6-only is easier with some operator; 64share only allows one subnet in vehicle).  Also one would consider asking the cellular operator to implement DHCPv6 Prefix Delegation, which may also take time.

I'm not sure how any of that relates to the ULA draft in question. ULA certainly isn't useful in any of those scenarios.

Owen

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 16 Feb 2014 19:34:27 +0100

Le 16/02/2014 19:22, Owen DeLong a écrit :
>
> On Feb 16, 2014, at 06:41 , Alexandru Petrescu
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>> addressing space for these vehicles from some registry, steps which
>> may take time.
>>
>
> It takes about 48 hours to get address space approved from a registry.
> Even less time to get some from a provider in most cases.

Is that for free and does it include setting up IPv6 routing to it, in 
Europe?

> I do not at all buy your argument here.

Ok, I need to learn how to do it, so well as to be able to teach 
somebody else who'd do it.  I am only in the middle.

>
>> These two directions are actually head and tail of same snake: it
>> bites its end, or otherwise put it's a chicken and egg problem: if the
> I did not say "don't do ULA". I said that the number of situations where
> ULA is detrimental vastly outweighs the number where it is useful.
>
> Your description above is one of the few cases where it might not be
> detrimental. It is not, however, particularly useful vs. PI or PA.
>
> As such, I think it is appropriate for the draft to make it clear that
> use of ULA should be carefully considered as in most cases it provides
> greater detriment.

Also make it clear that any other alternative is not easy: it involves 
delays and money.

> I'm not sure how any of that relates to the ULA draft in question. ULA
> certainly isn't useful in any of those scenarios.

A vehicle holds a 'mobile router' which may act precisely the same as a 
smartphone and tethering when connecting on cellular.  Except there are 
more subnets in a vehicle than the single subnet a user may carry.

Similar comparisons apply to 6to4 and DHCP Prefix Delegation - it's just 
like a smartphone.

Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 17 Feb 2014 08:16:00 +1300

>>>> outnumbers those where it is actually beneficial.

That's an opinion, but it isn't an argument for abolishing
ULAs. It's actually an argument for improving this draft so
that it describes the cases in which ULAs are beneficial.
Could we have a detailed conversation about whether those cases
are correctly described in the draft?

    Brian

---

From: Owen DeLong <[email-masked]>
Date: Sun, 16 Feb 2014 11:51:58 -0800

On Feb 16, 2014, at 10:34 , Alexandru Petrescu <[email-masked]> wrote:

> Is that for free and does it include setting up IPv6 routing to it, in Europe?

From the RIR, you would have to pay RIR fees. From an ISP, you probably get it for free, yes.

No. However, since you _CAN'T_ set up routing to ULA, I'm not sure how that applies.

> Ok, I need to learn how to do it, so well as to be able to teach somebody else who'd do it.  I am only in the middle.

I don't think that trying to influence IETF standards is the best way to avoid an education.

> Also make it clear that any other alternative is not easy: it involves delays and money.

I don't buy that argument. Getting it routed is going to cost you money regardless of what space you use. If you use ISP provided space, you probably get the space for free. If you use ULA, then you have to get space from the ISP, NAT the ULA, and still pay the same money.

If you want PI space so that you can move amongst different ISPs, then, you will need to pay the RIR fees for the PI space, but these are relatively minimal.

> A vehicle holds a 'mobile router' which may act precisely the same as a smartphone and tethering when connecting on cellular.  Except there are more subnets in a vehicle than the single subnet a user may carry.

There are more subnets attached to cellular devices in the future, too. I'm still not sure what any of this has to do with ULA.

> Similar comparisons apply to 6to4 and DHCP Prefix Delegation - it's just like a smartphone.

But what does that have to do with ULA? ULA is _NOT_ useful in any of those cases.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Sun, 16 Feb 2014 11:53:15 -0800

> are correctly described in the draft?

I was arguing for an improvement to the draft, not for the abolishment of ULA.

While I would not be sad to see ULA deprecated, that's not a topic of this discussion or even this WG.

Owen

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 16 Feb 2014 21:15:57 +0100

Le 16/02/2014 20:51, Owen DeLong a écrit :
>>> <[email-masked]
>>> <mailto:[email-masked]>> wrote:
>>>
>>>> There is an immediate direction to demonstrate an IPv6 vehicle
>>>> if it used ULA.  There is also the alternative to request PI
>>>> or PA IPv6 addressing space for these vehicles from some
>>>> registry, steps which may take time.
>>>>
>>>
>>> It takes about 48 hours to get address space approved from a
>>> registry. Even less time to get some from a provider in most
>>> cases.
>>

A-ha.

But the ISP is this cellular operator.  How long would it take me to
persuade a cellular operator (which is not related to a vehicle
manufacturer) to obtain so much address space as to give more than one
/64 to a vehicle?  And then to persuade all cellular operators in a
certain country to do the same for all other vehicle?

Talking to cellular operators I hear often this need to not give more 
than one 64 because of billing, and because of augmented security risks.

> No. However, since you _CAN'T_ set up routing to ULA, I'm not sure

In a sense yes and in another no.

Certainly a ULA prefix unique per vehicle would not allow to set routing
to them.  (neither would it if that were a PI space).

But a ULA in the vehicle in same space as a ULA in a separate
infrastructure (not operator's), would allow to set up tunnelling, and 
query the services offered by that infrastructure.  And yes, that would 
work with a PI space as well (instead of ULA).

Also, a translating mechanism in the vehicle (from ULA prefix to the /64
publicly routable provided by the operator) would allow for this to 
work.  This address translating mechanism may take various forms such as 
IPv6 NAT, NPT, and others which would allow network-layer reverse 
reachability.  I am not proposing this mechanism here, but it would rely 
on the easiness to make up ULAs.

> way to avoid an education.

That is right.

>>>> These two directions are actually head and tail of same snake:
>>>> it bites its end, or otherwise put it's a chicken and egg
>>>> problem: if the deployer sees the prototype works then it may
>>>> request IPv6 addressing space from registry, but not before it
>>>> sees it works.
>>>>
>>>> At this point I think this draft is good to say that ULAs are
>>>> useful. Later on maybe less so.  But right now that's
>>>> reflecting real-world situation.
>>>>
>>>
>>> I did not say "don't do ULA". I said that the number of
>>> situations where ULA is detrimental vastly outweighs the number
>>> where it is useful.
>>>
>>> Your description above is one of the few cases where it might
>>> not be detrimental. It is not, however, particularly useful vs.
>>> PI or PA.
>>>
>>> As such, I think it is appropriate for the draft to make it
>>> clear that use of ULA should be carefully considered as in most
>>> cases it provides greater detriment.
>>
> I don't buy that argument. Getting it routed is going to cost you
> money regardless of what space you use.

In a sense yes, but one could plan for that, independently of any other
organization.

> If you use ISP provided space, you probably get the space for free.

If this were ISP of 802.11p (WAVE) then yes, but these operators are in 
their very inceptive form these days.  In a few years maybe yes.

> If you use ULA, then you have to get space from the ISP, NAT the ULA,
> and still pay the same money.

Ok, again, this is a cellular operator, (not ADSL, not lab) which does 
give a /64 to an end user.  I think it is very hard to persuade a 
cellular operator to give more than 1 64, not in the immediate future. 
64share is there for this reason, no?

>
> If you want PI space so that you can move amongst different ISPs,
> then, you will need to pay the RIR fees for the PI space, but these
> are relatively minimal.

If I get PI space from an organization, I doubt cellular operator will 
route it for me.  So I end up with again a need to set an anchor 
somewhere else in the infrastructure.  And, if I can do that, I can do 
it for an ULA as well.

>>>> Alex PS: There are also some intermediary alternatives like
>>>> IPv4 transitioning (6to4 and other tunnels), 64share.  Each
>>>> has some inconvenients (6to4 requires both IPv4 and IPv6 on
>>>> cellular, whereas IPv6-only is easier with some operator;
>>>> 64share only allows one subnet in vehicle).  Also one would
>>>> consider asking the cellular operator to implement DHCPv6
>>> I'm not sure how any of that relates to the ULA draft in
>>> question. ULA certainly isn't useful in any of those scenarios.
>>
>> A vehicle holds a 'mobile router' which may act precisely the same
>> as a smartphone and tethering when connecting on cellular.  Except
>> there are more subnets in a vehicle than the single subnet a user
>> may carry.
>
> There are more subnets attached to cellular devices in the future,
> too. I'm still not sure what any of this has to do with ULA.

More subnets attached with a smartphone?  I dont doubt the need exists, 
but 64share won't work there.

> But what does that have to do with ULA? ULA is _NOT_ useful in any

_If_ a smartphone can obtain more than one 64, with DHCP Prefix 
Delegation, then of course ULA is not needed, PI space is not needed, 
64share is not needed.

If a smartphone can not, then one of the above is needed.

Among these: 64share does not work with multiple subnets, PI space 
requires time.

Alex

---

From: Mark ZZZ Smith <[email-masked]>
Date: Sun, 16 Feb 2014 12:26:10 -0800 (PST)

----- Original Message -----
> From: Brian E Carpenter <[email-masked]>
> To: Alexandru Petrescu <[email-masked]>
> Cc: V6 Ops List <[email-masked]>
> Sent: Monday, 17 February 2014 6:16 AM
> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt
> 

+1

A big drawback of Owen's global only model is that it creates further disincentive to deploy IPv6, because to do so requires a commercial arrangement with an IPv6 address provider and annual fees, in addition to the costs of the equipment that can talk IPv6.

It would in effect create an annual licencing fee for the use of IPv6 addresses and technology. I don't know if that has been tried before, however for the popular layer 3 protocols of the past, there has never been a mandatory fee for using addresses. Their low or absent technology use costs are probably one of the reasons why they've been popular.

These annual IPv6 address use fees may make charitable projects which use donated networking equipment infeasible, such as this sort of project - http://villagetelco.org/about/ - when IPv6 might be better to use than IPv4.

Regards,
Mark.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 16 Feb 2014 15:50:29 -0500

> I did not say "don't do ULA". I said that the number of situations where ULA is detrimental vastly outweighs the number where it is useful.

Can you give an example of a case where ULAs are detrimental?

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 17 Feb 2014 10:47:38 +1300

On 17/02/2014 09:15, Alexandru Petrescu wrote:
...
> on the easiness to make up ULAs.

That's exactly the use case we should be trying to block IMHO. An operator
that only provides a single /64 shouldn't be used for any scenario,
such as a vehicle, that needs subnets.

   Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 17 Feb 2014 10:48:46 +0100 (CET)

> Can you give an example of a case where ULAs are detrimental?

RFC3484 device with IPv4 connectivity but not IPv6 Internet connectivity. 
It will then try to use its ULA address to reach Internet addresses using 
IPv6.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Jan-Frode Myklebust <[email-masked]>
Date: Mon, 17 Feb 2014 12:00:13 +0100

> are correctly described in the draft?

Yes please.

My use case is that we have a set of datacenter internal services/servers
that should *never* be routed out. When not using ULA we've had a couple
of incidents where the routes did leak out and servers that shouldn't
have been available on the Internet was. So we've decided to use ULA for
the same set of servers as we previously used rfc1918-adresses for. No
NAT involved. No servers should reach Internet directly. Yes we could
achieve the same by putting proper ACLs in place on the borders, but since
we've failed to do that in the past, the belt and suspenders approach is
attractive.

Is this a "valid" ULA usage? 

  -jf

---

From: Gert Doering <[email-masked]>
Date: Mon, 17 Feb 2014 13:13:22 +0100

Hi,

> Is this a "valid" ULA usage? 

I'd say so.  Some of our network management stuff is done via ULAs, 
as it will ensure that machines will only be able to communicate with 
exactly our network, and nobody else.  (There are ACLs in addition to
that, before someone starts shouting at me)

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Mark Andrews <[email-masked]>
Date: Tue, 18 Feb 2014 01:01:56 +1100

In message <[email-masked]>, Mikael Abrah
amsson writes:
> >> I did not say "don't do ULA". I said that the number of situations where U
> LA is detrimental vastly outweighs the number where it is useful.
> >

And it will still work pretty well.  Longest match selects the right
IPv6 address when you have GUA most of the time.  If it doesn't the
ICMPv6 admin prohibited message should cause the app to fall over
to IPv4 as will HE apps or any well written multi-homed client.

Mark

-- 
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: Mon, 17 Feb 2014 06:35:16 -0800

> Is this a "valid" ULA usage? 

Sure... As long as you don't mind renumbering when the connectedness (or not) requirement changes, then that is one of the few cases where ULA is not detrimental.

Cases that propose NPT, NAT, or other translation mechanisms are examples where it is detrimental.

Cases where it ends up getting routed amongst "cooperating" parties are likely to eventually lead to detrimental usage because the natural trend is for them to become increasingly routed across more and more ASNs and eventually to become a form of de facto registered address space not administered by any structured or reliable registry and without any form of community based policy process (such as the current RIRs).

Owen

---

From: Ted Lemon <[email-masked]>
Date: Mon, 17 Feb 2014 11:38:22 -0500

> Cases that propose NPT, NAT, or other translation mechanisms are examples where it is detrimental.

This is clearly true, but we can't do much about it other than to encourage people to avoid this, and help them to avoid it by giving them alternatives.

> Cases where it ends up getting routed amongst "cooperating" parties are likely to eventually lead to detrimental usage because the natural trend is for them to become increasingly routed across mor…

This is a fun doomsday scenario, but we don't have this with RFC 1918 addresses today; why would we have it with ULAs tomorrow?   In fact, ULAs fix one of the really big problems with RFC 1918 addresses: there are so few of the latter that when two corporations that use RFC 1918 numbering internally merge, you have a really bad renumbering problem, and wind up doing more NATs than you otherwise would have.

So I think this use case is one where ULAs actually do really well.

Do you have some reason for thinking that your doomsday scenario is likely, or is it sufficient to you that it's possible, and therefore you want to avoid it?

---

From: joel jaeggli <[email-masked]>
Date: Mon, 17 Feb 2014 09:11:31 -0800

On 2/17/14, 8:38 AM, Ted Lemon wrote:
> This is clearly true, but we can't do much about it other than to
> encourage people to avoid this, and help them to avoid it by giving
> them alternatives.
> 
>> Cases where it ends up getting routed amongst "cooperating" parties
>> are likely to eventually lead to detrimental usage because the
>> natural trend is for them to become increasingly routed across more
>> and more ASNs and eventually to become a form of de facto
>> registered address space not administered by any structured or
>> reliable registry and without any form of community based policy
>> process (such as the current RIRs).
> 
> This is a fun doomsday scenario, but we don't have this with RFC 1918
> addresses today; why would we have it with ULAs tomorrow?

we route rfc 1918 between cooperating parties today. as noted it
requires coordination and is painful.

>   In fact,
> ULAs fix one of the really big problems with RFC 1918 addresses:
> there are so few of the latter that when two corporations that use
> RFC 1918 numbering internally merge, you have a really bad
> renumbering problem, and wind up doing more NATs than you otherwise
> would have.

what consenting adults do within the privacy of their own asns is really
none of my business.

If widely deployed in an uncoordinated fashion it becomes toxic for
globally coordinated use, which precludes owen's scenario. the fact that
we have 41 bits instead of 23.5 doesn't really obviate that.

> Do you have some reason for thinking that your doomsday scenario is
> likely, or is it sufficient to you that it's possible, and therefore
> you want to avoid it?
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Feb 2014 08:24:29 +1300

> requires coordination and is painful.

Yes, but it's painful because of ambiguity. With ULAs all you have to
coordinate is which prefixes are announced between the cooperating
parties. No coordination is needed for prefix assignment, which
is the real hassle with RFC 1918.

    Brian

---

From: joel jaeggli <[email-masked]>
Date: Mon, 17 Feb 2014 11:45:25 -0800

> is the real hassle with RFC 1918.

you're assuming that humans allocate prefixes via the procedures
described in the rfc and that utlization of a sparse address space is
sufficently difuse the you don't have to worry about collisions or that
more specfic routes will win out when someone has the bad taste to use
fc00::/7 or 8 in a routing policy contribution to aggregate and so on.

I kinda have my doubts. operational considerations around internal
aggregation and the human need to group things together in sets as well
as semantic uses (which I continue to assert are a bad idea) are going
to cause these things to be used inside organizations on boundries other
than /48.

My basic assertion is that if ula is widely and obiquitously  employed,
owen's scenario is unlikely to come to pass because the results are
messy and risky. If it isn't widely employed then who cares?

---

From: Mark ZZZ Smith <[email-masked]>
Date: Mon, 17 Feb 2014 12:42:48 -0800 (PST)

----- Original Message -----
> From: Gert Doering <[email-masked]>
> To: Jan-Frode Myklebust <[email-masked]>
> Sent: Monday, 17 February 2014 11:13 PM

+1

It would also reduce the likelihood of loosing remote connectivity to devices when performing changes to global prefixes, which are more likely to need be changed than ULAs (decoupling ULA and global subnet allocation would be a good idea). Even more robust management could be achieved by routing global and ULA prefixes in separate IGP instances or IGPs, further lowering the likelihood of ULA disruption when global prefix changes are being made.

I think that is one of the strong values of ULAs. It seems to me that reducing or avoiding external dependencies makes things more robust. Using ULAs internally means your network's internal addressing and reachability isn't dependent on external global prefix(es). This is actually one of the values of RFC1918 addresses, however, the trouble with them is that they aren't globally unique and it isn't easy to run concurrent RFC1918 and public addressing in an IPv4 network. ULAs and IPv6 overcome those drawbacks.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Feb 2014 10:56:22 +1300

On 18/02/2014 08:45, joel jaeggli wrote:
> described in the rfc 

People who don't will be punished automatically.

> and that utlization of a sparse address space is

People who do will be punished automatically.

> messy and risky. If it isn't widely employed then who cares?

Exactly right.

    Brian

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 18 Feb 2014 02:09:59 +0000

Hi Jan,

Thanks for sharing the information. Please see inline.

> > Could we have a detailed conversation about whether those cases are
> > correctly described in the draft?
> 
> Yes please.
> 
> My use case is that we have a set of datacenter internal services/servers that
> should *never* be routed out. When not using ULA we've had a couple of
> incidents where the routes did leak out and servers that shouldn't have been
> available on the Internet was. So we've decided to use ULA for the same set
> of servers as we previously used rfc1918-adresses for. No NAT involved. No
> servers should reach Internet directly. Yes we could achieve the same by
> putting proper ACLs in place on the borders, but since we've failed to do that
> in the past, the belt and suspenders approach is attractive.
> 
[Bing] This is one of the scenarios described in Section 3.2.2, where ULAs are used along with GUAs in a connected network. There are two cases in this scenario: 
1) internal-only nodes, configured with ULAs only. 
2) nodes configured with both ULA and GUA, and ULA is for internal communication while GUA for the outside.
I think your case fits the former one.

Best regards,
Bing

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 18 Feb 2014 03:16:44 +0000

Hi Owen,

Thanks for your suggestion.

> If we're going to move something like this forward, that really should be

[Bing] The main content of the draft is: 
- provide neutral pros/cons analysis and operational considerations for the ULA usage cases. (I think the cons and some operational considerations could cover what you meant "detrimental")
- eliminate the misunderstanding of ULA=1918 and recommend some use cases that we thought ULAs could be mostly beneficial (that's the main goal of this draft)

Best regards,
Bing
 
> > people see value in them, for reasons that have been aired many times.

---

From: Owen DeLong <[email-masked]>
Date: Mon, 17 Feb 2014 19:39:00 -0800

> we have 41 bits instead of 23.5 doesn't really obviate that.

I would argue that the current situation with RFC-1918 proves that with
additional bits (it’s 105, not 41), it is, in fact possible for people to do
really bad things which later merge after it is too late.

>> likely, or is it sufficient to you that it's possible, and therefore

Yes.

Case in point, the observed leakage of RFC-1918 into various parts of the internet,
the deliberate routing of boron space among several cooperating entities that I have
observed over my career (I can’t name names due to NDA, but a very large Telco
is using 100.0.0.0/8 for the VOIP interactions and demanding that their suppliers
route that network with them, for example).

Given the history of what happens with uncoordinated space in IPv4, legitimately or
otherwise, I have no reason to believe that ULA isn’t simply a larger, less inconvenient
opportunity to create a much larger problem of the same form without any of the
inherent drawbacks and limitations which prevented RFC-1918 from getting truly
out of hand.

Owen

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Feb 2014 10:14:38 +1300

On 18/02/2014 16:39, Owen DeLong wrote:
...
> inherent drawbacks and limitations which prevented RFC-1918 from getting truly

But ULAs aren't bogons. They aren't supposed to be routed, but
if some people break that rule, is a ULA prefix objectively any
more harmful than an "official" PI prefix?

I think we all realise that if you tell people not to stick
beans up their noses, they will try it out to see what happens.
I have no suggestion on how to prevent that.

   Brian

---

From: Ted Lemon <[email-masked]>
Date: Tue, 18 Feb 2014 17:27:23 -0500

> more harmful than an "official" PI prefix?

To expand on that, one of the big problems with RFC 1918 bogons is that the address might well wind up on some network on which it is valid, but refers to a different host.   This is _much_ less likely with ULAs.

So the sense in which ULAs are less harmful than PIs is that in principle at least, this cannot happen with PIs—if they escape their designated network, they are valid nowhere else.

---

From: Randy Bush <[email-masked]>
Date: Wed, 19 Feb 2014 14:30:39 +0800

> more harmful than an "official" PI prefix?

guatanteed no colision

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 19 Feb 2014 15:07:43 +0100

Le 19/02/2014 07:30, Randy Bush a écrit :
> guaranteed no colision

ULA presence in the wild - a bad thing - may be detected faster if it 
were colliding with another.  Whereas PI presence in the wild is not 
known whether it is a good or a bad thing in the first place.

Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Feb 2014 11:08:03 +1300

> known whether it is a good or a bad thing in the first place.

ULA collisions can occur in two cases:

1. More than one party not following the spec on how to generate
a ULA prefix - so they will be punished for their own mistakes.

2. A piece of remarkably bad luck, rather less likely than
winning any lottery I'm aware of.

Are we really going to worry about this? Especially since neither
case applies in in wide-area routing, where ULAs should always be
filtered anyway.

    Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 20 Feb 2014 10:17:48 +0900

> a ULA prefix - so they will be punished for their own mistakes.

How are they punished? And what will they do when they are punished? I
guarantee that renumbering will not be the solution, NAT will be the
solution.

> winning any lottery I'm aware of.

You assume that people will actually follow the rules instead of saying
"let's just do this like IPv4, and use NAT at the border".

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Feb 2014 20:32:59 -0500

On Feb 19, 2014, at 8:17 PM, Lorenzo Colitti <[email-masked]> wrote:
> You assume that people will actually follow the rules instead of saying "let's just do this like IPv4, and use NAT at the border".

If they are having a collision between ULAs because they used a bad algorithm for choosing their prefix, and if this is in any sense an inconvenience for them, then they have already deployed IPv6 in a fairly widespread fashion, and they aren't just going to back it out and go to IPv4.   Renumbering would be no more work.

I agree that a NAT is another likely outcome, but come on, Lorenzo.   How realistic is this scenario?   The RFC1918 collision/merger problem is well enough known that I've heard of it, and I don't do corporate numbering.   Of course this could happen, but if it does it will happen infrequently, and people will get fired over it, and it will ultimately stop happening.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 20 Feb 2014 12:35:16 +1100

> guarantee that renumbering will not be the solution, NAT will be the

Both sites just generate a NEW ULA prefixes.  They can continue to
use the collision prefix until the heat death of the universe if
they wish to or they can migrate to the new prefix.  IPv6 is NOT
IPv4.  Running parallel prefixes is *standard* proceedure.  They
just need to talk to each other using the NEW prefixes which should
be no more complicated than pushing new address selection tables.

If they really want to they can choose to use the same new prefix
and create a site that covers both of the old sites splitting the
address space.  If they do that they don't even need to push new
address selection tables.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 20 Feb 2014 10:40:13 +0900

On Thu, Feb 20, 2014 at 10:32 AM, Ted Lemon <[email-masked]> wrote:

> I agree that a NAT is another likely outcome, but come on, Lorenzo.   How
> realistic is this scenario?   The RFC1918 collision/merger problem is well
> enough known that I've heard of it, and I don't do corporate numbering.
> Of course this could happen, but if it does it will happen infrequently,
> and people will get fired over it, and it will ultimately stop happening.
>

To paraphrase Owen, "you are ignoring the realities of modern corporate IT
staffing". Saying that people will get fired for picking the wrong ULA
range is simply ludicrous.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 20 Feb 2014 10:46:24 +0900

> be no more complicated than pushing new address selection tables.

No, sorry. One of the main reasons people are advocating ULAs here is
"because we'll have stable space and will never have to renumber!!11". Once
you buy into that mantra, you'll be hardcoding IP addresses into
configuration again, exactly like we do in IPv4 today. And exactly like in
IPv4 today, renumbering will be prohibitively expensive.

As for multiple ULA prefixes... again, I think you're ignoring the
realities of corporate IT staffing, corporate IT systems, and vendor
capabilities.

I think it's obvious that the path of least resistance (and thus, the
solution that most admins would choose) will be NAT/NPT. After all, if you
want to use ULAs to talk to the outside world (And why wouldn't you, right?
It's what we do in IPv4, right?), you have to do NAT or NPT anyway.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Feb 2014 14:52:51 +1300

On 20/02/2014 14:17, Lorenzo Colitti wrote:
> How are they punished? 

They'll be punished because it won't work. Assuming this happens
when a network attempts to route a new prefix that (in some limited
domain) collides, then changing the new prefix shouldn't really
be an issue. Remember this will only occur inside a domain, since I
really think ISPs will filter these things (except for specific
/48s if forced to route them by money).

If they don't simply change the new prefix, ...

> And what will they do when they are punished? I

Yes, they might go to the *extra* work of configuring NPTv6 or worse.
Not a good thing. But we know we can't stop people doing bad things.
By the time they've misconfigured their ULA prefix, they're already
on a bad road.

> "let's just do this like IPv4, and use NAT at the border".

If CERs do the right thing the ULA prefix will be generated
correctly. But you're right, there will be a generation of
old-time IPv4 operators who will do exactly that whatever we
put in RFCs.

    Brian

---

From: Mark Andrews <[email-masked]>
Date: Thu, 20 Feb 2014 12:59:50 +1100

> realities of corporate IT staffing, corporate IT systems, and vendor

I already run multiple prefixes at home and have for years.  Vendors
*already* support multiple prefixes.  Corperate IP systems will be
supporting ULA1 + GUA1 (+ GUA2 + GUA3 for multi-homers).  ULA1 +
ULA2 + GUA1 (+ GUA2 + GUA3) is not a big streach.  Now as for
corporate IP staff you teach them what to do when teaching the how
to run IPv6 networks.

> It's what we do in IPv4, right?), you have to do NAT or NPT anyway.

It's a matter of education.  Adding "How to deal with a ULA prefix
collisions" to this document would be a good first step.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 20 Feb 2014 11:00:17 +0900

> >> winning any lottery I'm aware of.

Can you elaborate on exactly how bad this luck is as a function of how many
ULA prefixes you use your organization?

For example - if two large organizations that each use 200 ULA /48s (one
per site) merge, what is the chance that one of them will collide?

I don't feel it's satisfactory to say "the probability of a collision is
low" without saying how low it actually is. In fact, I think the draft
should not be published without giving a few examples of these numbers. If
*nobody* among the authors or on this list knows what the numbers actually
are, then we should not advocate using ULAs. It is not good engineering
practice to recommend something that you do not understand.

> old-time IPv4 operators who will do exactly that whatever we

I'm not talking about home networks here, I'm talking about corporate IT
environments.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 20 Feb 2014 11:02:54 +0900

> corporate IP staff you teach them what to do when teaching the how

Frankly, I believe you are being hopelessly optimistic. What you are able
to do and what a resource-constrained IT department in a small company will
do are so many standard deviations apart that you might as well not be on
the same planet.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 20 Feb 2014 13:35:50 +1100

>From RFC4193 (1 in x added by myself).

      Connections      Probability of Collision

          2                1.81*10^-12 (1 in 552486187845)
         10                4.54*10^-11 (1 in 22026431718)
        100                4.54*10^-09 (1 in 220264317)
       1000                4.54*10^-07 (1 in 2202643)
      10000                4.54*10^-05 (1 in 22026)

> I'm not talking about home networks here, I'm talking about corporate IT

Which should have trained staff who should know better.

If you have 200 odd sites pick the top 32 bits of the 40 bits
randomly and allocate the bottom 8 bits sequentually.  That doesn't
change the probability of collision when connecting to other sites
though the amount of work if there is a collision is likely to be
more. It avoids the top 32 bits being zeros and helps with human
factors like wanting address space to be clumped.

fde9:4d65:f9XX:: is just as easy to work with as fd00:0:XX::
especially when you are likely to have +200 GUA prefixes as well
to deal with which won't be sequentually assigned.

Mark

---

From: Ray Hunter <[email-masked]>
Date: Thu, 20 Feb 2014 08:40:09 +0100

Lorenzo Colitti wrote:
> On Thu, Feb 20, 2014 at 10:52 AM, Brian E Carpenter 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> Can you elaborate on exactly how bad this luck is as a function of how 
> many ULA prefixes you use your organization?
>
> For example - if two large organizations that each use 200 ULA /48s 
> (one per site) merge, what is the chance that one of them will collide?
>
> I don't feel it's satisfactory to say "the probability of a collision 
> is low" without saying how low it actually is. In fact, I think the 
> draft should not be published without giving a few examples of these 
> numbers. If *nobody* among the authors or on this list knows what the 
> numbers actually are, then we should not advocate using ULAs. It is 
> not good engineering practice to recommend something that you do not 
> understand.
>
> I'm not talking about home networks here, I'm talking about corporate 
> IT environments.
Having being involved in a number of mergers, de-mergers, and 
acquisitions, I suspect that a ULA clash will be the least of your worries.
[Although I have to admit I've never actually merged or de-merged 
multiple IPv6 ULA's]

IMHO I think the real worry would be any remaining hard coded addresses 
and ranges [in firewalls, load balancers, name servers, hot standby 
systems, WAN optimizers, Active Directory servers (which LANs does each 
DC serve), licence servers .... ]

Is there any serious effort underway to solve how exactly you specify 
network security zones and firewall rules for ULA based systems, and for 
systems running multiple IPv6 prefixes?

Does a ULA prefix need to map 1:1 to a network security zone?
Do you also have to map the ULA space onto your GUA space(s) to ensure 
the classification and filtering rules for different prefixes remain in 
synch?
When de-merging a single ULA into 2 enterprises, how do you draw a line 
in the sand to separate A from B?

Does the "corporate firewall" function have to become distributed so 
that the filtering really does sit at the network security zone borders 
(rather than relying on anti-spoof filters, and a single centralised 
pair of firewalls)

At this point, I'd much rather merge or de-merge two sets of GUA space, 
and have predictable behaviour during any transition.

-- 
Regards,
RayH

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 20 Feb 2014 13:15:41 +0000

> "let's just do this like IPv4, and use NAT at the border".

people will not just do this: they will assign everything from fd00::/48
and will view NAT as a feature.

Nick

---

From: David Farmer <[email-masked]>
Date: Thu, 20 Feb 2014 07:33:30 -0600

On 2/19/14, 19:46 , Lorenzo Colitti wrote:
> On Thu, Feb 20, 2014 at 10:35 AM, Mark Andrews <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> "because we'll have stable space and will never have to renumber!!11".
> Once you buy into that mantra, you'll be hardcoding IP addresses into
> configuration again, exactly like we do in IPv4 today. And exactly like
> in IPv4 today, renumbering will be prohibitively expensive.

I wouldn't say networks using ULAs will never need to be renumbered. 
But, they provide address stability independent of provider based GUA. 
You could get unlucky, you can screw up, but even if you don't, you will 
probably want to eventually consolidate your ULA prefixes just for 
simplicity of managing your networks.  If you acquire enough other 
companies there will eventually be a big enough win to justify the work 
of consolidating your ULA prefixes.

> solution that most admins would choose) will be NAT/NPT. After all, if
> you want to use ULAs to talk to the outside world (And why wouldn't you,
> right? It's what we do in IPv4, right?), you have to do NAT or NPT anyway.

The evolution to mobile devices and their transitory nature are
chaining the dynamics of most client network.  Fewer and fewer devices 
have even a semi-permanent relationships with an individual IP address. 
  Mobility and the consumerization of IT is driving more and more 
dynamic configuration of devices loosening the bonds between most 
devices and their IP addresses.

Further, the evolution toward cloud computing, elastic services models, 
and deployment orchestration are causing similar changes in server 
networks and data centers.  Old school corporate IT models are by no 
means dead.  But things are changing, you can't swing a dead cat without 
hitting a CIO who is talking about BYOD or Cloud Computing.

Renumber is never going to happen without some pain, but between these 
fundamental changes in the way we use networks and the capabilities of 
IPv6, renumbering is much more doable.

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

---

From: David Farmer <[email-masked]>
Date: Thu, 20 Feb 2014 07:45:31 -0600

> and will view NAT as a feature.

Do we think not talking about ULA will stop people from doing NAT with ULA?

Get over it.  This draft is necessary, we need to tell people how to 
properly use ULA.  It is not telling them to do NAT.  I think it should 
more strongly tell them to NOT do NAT.  However, they are going to do 
what they are going to do.  But, if we don't tell them what the proper 
use cases for ULA are, then our silence is consent for them to go ahead 
and do NAT with ULA.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 20 Feb 2014 23:58:14 +0900

On Thu, Feb 20, 2014 at 10:45 PM, David Farmer <[email-masked]> wrote:

> more strongly tell them to NOT do NAT.  However, they are going to do what
> they are going to do.  But, if we don't tell them what the proper use cases
> for ULA are, then our silence is consent for them to go ahead and do NAT
> with ULA.
>

We don't know what the use cases for ULAs are, because nobody has actually
used them in real deployments. The people who are deploying IPv6 are saying
"ugh, ULA sucks, let's do global instead" and the ones who aren't deploying
IPv6 are using IPv4.

I will be the first to support a draft that documents *real* experience of
ULA in a *real* deployment. But documenting use cases without having
actually used them for real... sorry, that's hubris.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 20 Feb 2014 15:41:35 +0000

To come back to the draft itself...

Section 2.2 'globally unique', should stress that the randomization
process MUST be followed to the letter. Also, as discussed in the list,
the 40 bits of entropy are for a single /48, if hundreds of /48 need to be
generated, this will reduce the entropy to 30 bits or so... (which is
still 8 billions though).

Section 4.2 'limited scope', as a security person, I would really love to
read it clearly articulated that ULA does not provide isolation per se...
Bi-directional ACL are required + route map to avoid polluting your BGP
neighbors. Jan-Frode, I am sure that you know that strict policy routing
(without anti-spoofing or ACL) will not prevent packets from you DC to
leak to the Internet (to the NSA or any other 'interested' party ;-))

-éric

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Feb 2014 09:03:09 +1300

On 20/02/2014 20:40, Ray Hunter wrote:
...
> and have predictable behaviour during any transition.

Ray, ULA prefixes *are* global unicast prefixes; their only special
characteristic is that they are not routed outside a given administrative
domain.

Also, it is common for large enterprises to run multiple disjoint prefixes
within the corporate network, and has been for many years.

I think the issues you're concerned about are all due to the fact that
in IPv6, it is bog standard to run more than one prefix on the same
phsyical subnet. The fact that one of them might be delegated from
a ULA /48 seems to me to be a side issue.

    Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 20 Feb 2014 21:20:04 +0100 (CET)

On Thu, 20 Feb 2014, Lorenzo Colitti wrote:

> I will be the first to support a draft that documents *real* experience 
> of ULA in a *real* deployment. But documenting use cases without having 

At least one of the top10 residential deployments on 
http://www.worldipv6launch.org/measurements/ uses ULAs and reportedly 
hasn't seen any customer complaints related to ULAs.

This isn't really the corporate use case I believe we're discussing here 
but...

Just to be clear, I am not a ULA fan, but I am all for documenting things.

---

From: Gert Doering <[email-masked]>
Date: Thu, 20 Feb 2014 22:44:56 +0100

Hi,

On Thu, Feb 20, 2014 at 11:58:14PM +0900, Lorenzo Colitti wrote:
> used them in real deployments. 

I have.  To reach other people's RFC1918 IPv4 networks over VPNs...

We assign a /64 out of "our" ULA /48 to each VPN partner, and NAT64
the last 32 bits at our IPSEC gateway into IPv4.  So it really doesn't 
matter what they use inside their network, we can reach the full IPv4 
range in there, nicely isolated into a single collision free prefix on 
our side...

Now I agree that using ULAs as life support for IPv4 might not be the
*best* use case, but you were asking for "real deployment".

Gert Doering
        -- NetMaster

---

From: Ray Hunter <[email-masked]>
Date: Thu, 20 Feb 2014 22:53:51 +0100

> Brian E Carpenter <mailto:[email-masked]>
> 20 February 2014 21:03
So how do they set up firewall rules?

> a ULA /48 seems to me to be a side issue.

So you see no problems with a machine running multiple prefixes, where 
the IID for each may also be different (stable privacy addresses), and 
each session may source from a different prefix depending on where it's 
terminating (address selection + address rotation of privacy addresses)?

How will the firewall even know it's the same machine sending the 
packets, never mind the same user, so that the communication stream can 
be authorised or blocked?

Will users have to re-authenticate for every prefix + IID combination?

-- 
Regards,
RayH

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Feb 2014 13:25:10 +1300

> So how do they set up firewall rules?

I'm not sure why you ask, and when I worked for such a company
(IBM) it wasn't something I ever looked at. However, I assume
that the filters for every border device to the Internet cited
all the internal prefixes in use. Certainly the config file for
the call-home VPN on my company laptop included a very long list of
prefixes, and I guess that was pretty much the same list as they
needed in the border firewalls.

> terminating (address selection + address rotation of privacy addresses)?

That's the design of IPv6.

> be authorised or blocked?

You're talking about a firewall that censors outgoing sessions?
Well, that's bound to be a pain. But you'll find the MAC address
in the ND cache, so you could check that way.

> Will users have to re-authenticate for every prefix + IID combination?

If it's a firewall that authenticates users, yes, I would think so.
But I don't see why that would require user action; it should just be
automatic after the user's initial authentication. If not, the
authentication mechanism is not well designed for IPv6.

   Brian

---

From: "Liubing (Leo)" <[email-masked]>
Date: Fri, 21 Feb 2014 08:24:39 +0000

Hi David,

Thank you for the comment. Please see replies below.

> >> You assume that people will actually follow the rules instead of
> >> saying "let's just do this like IPv4, and use NAT at the border".
> >
> > people will not just do this: they will assign everything from
> > fd00::/48 and will view NAT as a feature.
> 
> Get over it.  This draft is necessary, we need to tell people how to properly
> use ULA.  It is not telling them to do NAT.  I think it should more strongly
> tell them to NOT do NAT.  However, they are going to do what they are
> going to do.  But, if we don't tell them what the proper use cases for ULA
> are, then our silence is consent for them to go ahead and do NAT with ULA.

[Bing] The WG used to discuss ULA+NPTv6 use case a lot. Some people suggested to clearly state in the draft "NOT recommended to do ULA+NAT"; while some argued "NOT recommended" was too strong, just provide pros/cons and cautions on it. We agreed with the latter one, since we thought ULA+NPTv6 might be a valid use case in some situations. 
However, one of the main goals of this draft is to eliminate the mis-understanding of ULA is supposed to be binding with NAT. This point is clearly described in Section 4. And the ULA+NPTv6 is not listed in the recommended use cases. We thought this is a way to strike the balance.

Best regards,
Bing

---

From: "Liubing (Leo)" <[email-masked]>
Date: Fri, 21 Feb 2014 08:38:14 +0000

Hi Eric,

Thanks for your comments to draft itself. Please see replies below.

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of Eric Vyncke
> (evyncke)
> Sent: Thursday, February 20, 2014 11:42 PM
> To: Jan-Frode Myklebust; Brian E Carpenter
> Cc: V6 Ops List
> Subject: Re: [v6ops] I-D Action:
> draft-ietf-v6ops-ula-usage-recommendations-02.txt
> 
> Section 2.2 'globally unique', should stress that the randomization process
> MUST be followed to the letter. Also, as discussed in the list, the 40 bits of
> entropy are for a single /48, if hundreds of /48 need to be generated, this
> will reduce the entropy to 30 bits or so... (which is still 8 billions though).

[Bing] Yes, this is a good argument. Will do in the next version. Thanks.

> Section 4.2 'limited scope', as a security person, I would really love to read it
> clearly articulated that ULA does not provide isolation per se...
> neighbors. 

[Bing] This could be a good point to add in the security considerations. Thanks.

Best regards,
Bing

> Jan-Frode, I am sure that you know that strict policy routing
> (without anti-spoofing or ACL) will not prevent packets from you DC to leak
> to the Internet (to the NSA or any other 'interested' party ;-))

> >> That's an opinion, but it isn't an argument for abolishing ULAs. It's
> >> actually an argument for improving this draft so that it describes
> >> the cases in which ULAs are beneficial.
> >
> >My use case is that we have a set of datacenter internal
> >services/servers that should *never* be routed out. When not using ULA
> >we've had a couple of incidents where the routes did leak out and
> >servers that shouldn't have been available on the Internet was. So
> >we've decided to use ULA for the same set of servers as we previously
> >used rfc1918-adresses for. No NAT involved. No servers should reach
> >Internet directly. Yes we could achieve the same by putting proper ACLs
> >in place on the borders, but since we've failed to do that in the past,
> >the belt and suspenders approach is attractive.
> >

---

From: Owen DeLong <[email-masked]>
Date: Fri, 21 Feb 2014 01:14:21 -0800

> old-time IPv4 operators who will do exactly that whatever we

That doesn’t make giving them an RFC which tacitly allows or recommends these actions a good thing.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Fri, 21 Feb 2014 01:16:06 -0800

> collisions" to this document would be a good first step.

No, it’s a good second or third or … step.

A good first step is teaching them that the best way to avoid a ULA collision is to use GUA in most circumstances and only use ULA where GUA is infeasible.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Fri, 21 Feb 2014 01:20:37 -0800

> Which should have trained staff who should know better.

In an ideal world, sure… In the real world where some of us have to live…

I think Lorenzo’s use of the term hopelessly optimistic is kind. I would go so far as to say somewhat detached from reality.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Fri, 21 Feb 2014 01:41:40 -0800

On Feb 20, 2014, at 5:45 AM, David Farmer <[email-masked]> wrote:

> Get over it.  This draft is necessary, we need to tell people how to properly use ULA.  It is not telling them to do NAT.  I think it should more strongly tell them to NOT do NAT.  However, they are going to do what they are going to do.  But, if we don't tell them what the proper use cases for ULA are, then our silence is consent for them to go ahead and do NAT with ULA.

I don’t think anyone is advocating not talking about ULA… I think some of us just want to make sure that the drawbacks, pitfalls, and problems it creates are explicitly mentioned in the draft rather than painting an optimistic and unrealistically rosy picture.

Owen

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 21 Feb 2014 19:02:54 +0900

> hasn't seen any customer complaints related to ULAs.

Yes, sorry. But they use ULA in addition to global addresses. I think we do
understand that.

The use cases I'm worried about (and I should have said this explicitly,
sorry) are the ones which use ULA without global addresses. We don't know
how those can be made to work.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 21 Feb 2014 11:07:22 +0100 (CET)

On Fri, 21 Feb 2014, Lorenzo Colitti wrote:

> sorry) are the ones which use ULA without global addresses. We don't 
> know how those can be made to work.

Do you mean which never has GUA addresses, even when the Internet 
connection is up? The use-case for ULA I have been told is "need to reach 
printer when Internet connection is down".

I am worried about this as well, because old-style RFC3484 devices will 
probably rely on ICMP unreachables and happy eyeballs to avoid giving a 
super crappy user experience when accessing dual stack resources on the 
Internet. I welcome further research into this topic.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 21 Feb 2014 11:13:02 +0100 (CET)

> Internet. I welcome further research into this topic.

Gah, clarification: I meant when IPv4 Internet connectivity is up, but 
IPv6 GUA isn't available, meaning RFC3484 style devices with RFC1918+ULA.

---

From: Tore Anderson <[email-masked]>
Date: Fri, 21 Feb 2014 11:35:03 +0100

* Mikael Abrahamsson

>> I am worried about this as well, because old-style RFC3484 devices
>> will probably rely on ICMP unreachables and happy eyeballs to avoid
>> giving a super crappy user experience when accessing dual stack
>> resources on the Internet. I welcome further research into this topic.
> 

This should be fine as long RFC 7084 reqs G-4, G-5, and ULA-5 are
implemented, as then the ULA-numbered hosts would be without a default
route, and does a fast failover (happening entirely within the hosts' IP
stack) to IPv4 when trying to communicate with internet destinations.

If req L-3 is implemented it should even work if the printer is on a
different link than the device trying to print to it (assuming both
implement RFC 4191).

Tore

---

From: Ray Hunter <[email-masked]>
Date: Fri, 21 Feb 2014 11:43:44 +0100

> 21 February 2014 01:25
>>> Brian E Carpenter<mailto:[email-masked]>
>>> 20 February 2014 21:03

OK ULA = Globally unique with high probability of uniqueness, and 
limited reachability scope.

RFC 6887 states "These IP addresses may have distinct reachability 
scopes (e.g., if IPv6, they might have global reachability scope as is 
the case for a Global Unicast Address (GUA) [RFC3587] or limited scope 
as is the case for a Unique Local Address (ULA) [RFC4193])." which 
suggests to me that they are distinct.

And RFC 3587 refers to "The TLA/NLA scheme has been replaced by a 
coordinated allocation policy defined by the Regional Internet 
Registries (RIRs) [IPV6RIR]" which does not cover self-generated ULA.

So I'm not the first to blur that particular boundary.
> all the internal prefixes in use.
Nope. Especially at private NNI's, the enterprises have a duty to 
protect each other from attack by e.g. virus storms.
Only authorised machines should communicate.

> Certainly the config file for
Nope. Many businesses have a requirement for controlled and tracked 
outbound access. e.g. to see which machine FTPed a copy of the corporate 
development code to the Internet, and when.
Yes.
> in the ND cache, so you could check that way.
They are not connected at L2.
> authentication mechanism is not well designed for IPv6.
Is there any IETF standard for this authentication?

When I check PCP it doesn't seem to explicitly correlate requests from 
the same machine, and ULA's should not be used as the source of the PCP 
message.
 > IPv6 addresses without global reachability (e.g., ULAs) SHOULD NOT be 
used as the source interface when generating a PCP request.

What about internal firewalls within an enterprise? ULA only networks? 
Ignore the SHOULD?
GUA prefix that arrives after the ULA is configured? Before ULA is 
configured?

I still expect operational issues with synchronising access requests 
from a single machine across multiple prefixes:
GUA rule times out, but the ULA rule doesn't or vice versa. It's going 
to be a nightmare to debug.

To my mind, there definitely seems to be operational gaps in the 
assumptions made for GUA + ULA operation in parallel.

-- 
Regards,
RayH

---

From: Ted Lemon <[email-masked]>
Date: Fri, 21 Feb 2014 07:01:31 -0500

> I don’t think anyone is advocating not talking about ULA… I think some of us just want to make sure that the drawbacks, pitfalls, and problems it creates are explicitly mentioned in the draft rathe…

Can you propose some text you'd like to see added, so that we can discuss it?   :)

---

From: Owen DeLong <[email-masked]>
Date: Fri, 21 Feb 2014 09:06:40 -0800

On Feb 20, 2014, at 12:20 PM, Mikael Abrahamsson <[email-masked]> wrote:

>> I will be the first to support a draft that documents *real* experience of ULA in a *real* deployment. But documenting use cases without having actually used them for real... sorry, that's hubris.
> 
> At least one of the top10 residential deployments on http://www.worldipv6launch.org/measurements/ uses ULAs and reportedly hasn't seen any customer complaints related to ULAs.
> 

Most residential customers don’t even realize that an internet without NAT is possible.

Many ISPs run NAT IPv4 solutions with zero customer complaints.

Lack of customer complaints, especially in residential, is really not the bar I think we should be striving for here. A big part of the point of IPv6 is to provide the ability to restore an end-to-end internet. Aiming for an internet that merely avoids uninformed non-technical users complaining about the service being worse than the degraded service they have always experienced until now is not going to allow us to come anywhere near that goal.

> This isn't really the corporate use case I believe we're discussing here but...
> 

I’m all for documenting reality. I’m not for advocating solutions that are unproven or discussing poor choices in a bizarrely positive light which is, IMHO, the current state of this draft.

Owen

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 22 Feb 2014 08:36:57 +1300

> Only authorised machines should communicate. 

In such a regime you're bound to have stateful or static address
assignment, so if you have N prefixes each machine will need to have
N stateful or static addresses. I understand that it's N times the
hassle and that you might not want to do it.

However, an address derived from a ULA prefix would never be
authorised to communicate with the Internet. If you had a subclass
of machines that were allowed to communicate with a business
partner via ULA but not with the Internet, a ULA would just be
one of the N.

Regards
   Brian

---

From: Ray Hunter <[email-masked]>
Date: Fri, 21 Feb 2014 22:48:10 +0100

> 21 February 2014 20:36

And then maintain correlation of Semantically Opaque Interface 
Identifiers to machine for each prefix?

No thanks.

I think the only sensible operational advice is "Do not split a ULA /48 
prefix across a firewall or other network security zone boundary"

That way the default address selection rules will ensure that no two 
nodes will use ULA's for communication across that boundary, and you can 
maintain a single ACL/firewall rule based on the GUA RIR registered 
addresses.

-- 
Regards,
RayH

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 22 Feb 2014 14:03:34 +1300

> Identifiers to machine for each prefix?

That seems to be the necessary implication of the restricted access
model that Ray describes, regardless of what kind of prefix or
how many of them you have.

> prefix across a firewall or other network security zone boundary"

I agree. That's not the model. If company A has a prefix ULA-A
and company B has a prefix ULA-B, then A announces a route to ULA-A
on the private link between the companies, and B announces ULA-B.

> maintain a single ACL/firewall rule based on the GUA RIR registered

You need different rules on the inter-company link.

   Brian

---

From: "Liubing (Leo)" <[email-masked]>
Date: Sat, 22 Feb 2014 09:53:26 +0000

Hi Owen,

> I'm all for documenting reality. I'm not for advocating solutions that are
> unproven or discussing poor choices in a bizarrely positive light which is,
> IMHO, the current state of this draft.

[Bing] There are several recommended use cases in the draft:
1. used in isolated networks
2. used along with GUA
3. some specific cases (as private routing prefixes, as up-layer identifiers, as NAT64 prefixes)

Would you mind providing more information about "bizarrely positive light"? Do you mean the above recommended use cases, or some other things?

Thanks,
Bing

---

From: Mark ZZZ Smith <[email-masked]>
Date: Sun, 23 Feb 2014 22:32:08 -0800 (PST)

>________________________________
> From: Lorenzo Colitti <[email-masked]>
>To: David Farmer <[email-masked]> 
>Cc: "[email-masked] WG" <[email-masked]> 
>Sent: Friday, 21 February 2014 1:58 AM
>We don't know what the use cases for ULAs are, because nobody has actually used them in real deployments. The people who are deploying IPv6 are saying "ugh, ULA sucks, let's do global instead" and the ones who aren't deploying IPv6 are using IPv4.
>
>

Anybody using the Apple "Back to my Mac" service is apparently using them:

"Understanding Apple's Back to My Mac (BTMM) Service"
https://tools.ietf.org/html/rfc6281

---

From: Owen DeLong <[email-masked]>
Date: Mon, 24 Feb 2014 02:22:37 -0800

> Anybody using the Apple "Back to my Mac" service is apparently using them:

Correction…

Anybody using the Apple “BTMM” service without native IPv6 is apparently using them. People who have real IPv6 addresses, OTOH, do not need ULA for BTMM.

Owen

---

From: Victor Kuarsingh <[email-masked]>
Date: Mon, 24 Feb 2014 19:18:59 -0500

Lorenzo,

> actually used them for real... sorry, that's hubris.

I am aware of at least one use real case that I have experience with for
ULA-only.  This use case is for Cable Modem Management.   I guess I should
provide text to the draft on this (as it's a use case for "Connected
Network: ULA-Only deployment").

In this case the IPv6 device as no global connectivity requirements and the
use of the IP address for management purposes is very well scoped.  Using
ULAs in this case is quite safe since the devices will never need global
connectivity (in fact its specifically guarded against).

Using GUA in this case is possible, I know the blowing 1000s of /64s likely
won't get anybody excited, but managing the filters on the modems is much
easier with ULAs.  Using GUAs, one may need to add a few filter lines in
the modem config which is a precious resource (config file space).  Whereas
doing a deny FC00::/7 is easy and very clear.   It's also visually obvious
to the operator which is important in troubleshooting (where you have 100s
of ops people) It's a clean use of the ULA space.

As for documenting use cases, my input is

1) we should document real world use cases where we have real experience (I
am a bit worried about what-if or no-experience areas)

2) I think we should soften the language of the draft to not "recommend"
ULA usage, but more along the lines of if we use them, here is how they
have been used, and here  are the risks.

regards,

Victor K

regards,

Victor K

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 25 Feb 2014 09:35:20 +0900

On Tue, Feb 25, 2014 at 9:18 AM, Victor Kuarsingh <[email-masked]> wrote:

> In this case the IPv6 device as no global connectivity requirements and
> the use of the IP address for management purposes is very well scoped.
>  Using ULAs in this case is quite safe since the devices will never need
> global connectivity (in fact its specifically guarded against).
>

That seems like a reasonable use case, yes. I think the draft should
document it, perhaps also noting that often over time we tend to discover
that devices need more connectivity that we previously think they needed,
and in that case the devices have to be renumbered.

> 1) we should document real world use cases where we have real experience
> (I am a bit worried about what-if or no-experience areas)
>

Agreed. What worries me about the current text is that few of the scenarios
in the draft seem to come from real experience. In fact, one of the earlier
versions of the draft documented a use case that doesn't even work as
intended (the "use ULA as a NAT64 prefix").

---

From: Mark Andrews <[email-masked]>
Date: Tue, 25 Feb 2014 12:35:20 +1100

ULA along side GUA basically just works.  In the last 69 days there
have been ~800 packets that hit my firewall rules to stop ULA packets
transiting the upstream link in either direction.  This is with
MacOS, IOS and Windows clients as well as what I daughter's friends
bring along and connect to the net.

I've been running like this for yonks now.

bsdi# uptime
12:27PM  up 69 days,  1:20, 1 user, load averages: 0.87, 0.90, 0.93
bsdi# ip6fw -a list | grep fc00
01600          1        306 unreach admin ipv6 from any to fc00::/7 via gif0
01700        794      42946 unreach admin ipv6 from fc00::/7 to any via gif0
bsdi# 

[rock:~] marka% traceroute6 -In -s fd92:7065:b8e::2acf:e9ff:fe1b:508f bikeshed.isc.org
traceroute6 to bikeshed.isc.org (2001:4f8:3:d::19) from fd92:7065:b8e::2acf:e9ff:fe1b:508f, 64 hops max, 16 byte packets
 1  fd92:7065:b8e::2e0:29ff:fe19:c02d  3.964 ms  1.228 ms  5.056 ms
 2  fd92:7065:b8e::2e0:29ff:fe19:c02d  1.196 ms !P  1.180 ms !P  1.133 ms !P
[rock:~] marka%