using ULA for 'hidden' v6 devices?

Mailman List Mirror (Read Only)
1

Is anyone using ULA (RFC 4193) address space for v6 infrastructure that does not need to be exposed to the outside world? I understand the concept of having fc00::/8 being doled out by the RIRs never went anywhere, and using space out of fd00::/8 can be a bit of a crap-shoot because of the likelihood of many organizations that do so not following the algorithm for picking a /48 that is outlined in the RFC.

There would appear to be reasonable arguments for and against using ULA. I'm just curious about what people are doing in practice.

jms

2

Is anyone using ULA (RFC 4193) address space for v6 infrastructure that

does not need to be exposed to the outside world? I understand the concept
of having fc00::/8 being doled out by the RIRs never went anywhere, and
using space out of fd00::/8 can be a bit of a crap-shoot because of the
likelihood of many organizations that do so not following the algorithm for
picking a /48 that is outlined in the RFC.

There would appear to be reasonable arguments for and against using ULA.

I'm just curious about what people are doing in practice.

Yes. Uses may include the DNS interface that you only want your customers
to query.... or pretty much any service, as you said, that does not need to
be connected to the internet.

Beware of ULA haters.

Cb

3

Yep. It works great for strictly local devices which don't need Internet access.

4

Our site would be in the against ULA camp. For that matter we had
survived until very recently in the anti-1918 camp, too. So, take
that as an inherent bias.

We have one customer in particular with a substantial non-publicly
reachable v6 deployment with globally assigned addresses. I believe
there is no need to replicate the headaches of rfc1918 in the next
address-family eternity.

Dale

5

I wish you luck selling this notion to enterprise network people, most of
who appear to believe that rfc1918 address space is a feature, not a bug.

Nick

6

We've used RFC1918 space for years (without NAT) for non-routed device
management (switches, printers, IP phones, etc).

The same idea applies to ULA. Just another tool in the box.

The idea behind the random bits was to avoid conflicts should organizations
making use of ULA merge.

Locally managed means locally manage, though. The RFC is more of
a suggestion than a requirement at that point.

Since it's unenforceable, and the standards require it
to function regardless, I do suspect that many will opt for a "random"
value of zero to keep the notation short and sweet, despite the RFC, or
develop an internal addressing schema for ULA space that works for them
operationally.

7

Until they've gone through an M&A where they had to connect multiple sites
using overlapping RFC1918 space, of course. Then the idea of globally
unique addressing, even if it's not globally routable, starts looking
awfully useful.

8

We've used RFC1918 space for years (without NAT) for non-routed device
management (switches, printers, IP phones, etc).

And we've done the same.

The idea behind the random bits was to avoid conflicts should organizations
making use of ULA merge.

I'm also thinking down the road to possible cases where an internal host needs to be able to communicate with an internal host at another organization over a VPN tunnel, and a convincing argument can't be made for using public addresses - something that's pretty common today in the v4 world. The thought of having to something equivalent to NAT-T for v6 doesn't fill my heart (or my VPN termination devices) with joy...

Along somewhat similar lines, I don't know if any of the relevant regulatory bodies have made any specific comments related to securing networks that are interconnected using v6. Also being in the higher-ed world, I'm thinking along the lines of HIPAA, GLB, SOX, and friends. The answer might be out there - I just haven't looked into it yet.

Locally managed means locally manage, though. The RFC is more of
a suggestion than a requirement at that point.

Right, though it's a shame that the registry-assigned ULA concept didn't take off.

Since it's unenforceable, and the standards require it
to function regardless, I do suspect that many will opt for a "random"
value of zero to keep the notation short and sweet, despite the RFC, or
develop an internal addressing schema for ULA space that works for them
operationally.

So it stands a good chance of turning into the wild west :wink:

jms

9

The one big issue I could see with doing that is that the vulnerability exposure, particularly from the outside world, is larger if devices that don't need public addresses have them. For example, if a network engineer or NOC person accidentally removes a "hide my public infrastructure from the outside world" from an interface on a border router...

As others have mentioned, things like management interfaces on access switches, printers, and IP phones would be good candidates to hide with ULA.

jms

10

Isn't this what's made the Internet great? :wink:

11

[..]

Locally managed means locally manage, though. The RFC is more of
a suggestion than a requirement at that point.

Right, though it's a shame that the registry-assigned ULA concept didn't
take off.

What everybody calls "Registered ULA" or ULA-C(entral) is what the RIRs
already provide. Also entities that have such a strict requirement are
perfectly served with address space the RIRs provide.

And from my POV unless one is deploying devices which set up ad-hoc
networks, there is no real reason to use ULA at all. Just take a chunk
from your RIR assigned space, firewall it off, or simply do not route it
and presto, you got a globally registered unique block of address space.

From that POV the only reason one might not want RIR space is that one

has to pay a wee bit of money for the RIR space, guess what, any kind of
ULA-C space with guarantees for being global unique will have that same
problem.

But if you want to stick to ULA anyway and you want a bit more certainty
that your ULA prefix does not clash, you can generate a random one as
per the RFC and register it:

As long as everybody looks at that list, one will be clash free.

And yes, ULA comes in chunks of /48 if you need more than that you can
just register multiple disjunct ones or... what about that RIR space?
Likely one site or another will start using that thing called the
Internet anyway at one point.

Greets,
Jeroen

12

[..]

Locally managed means locally manage, though. The RFC is more of
a suggestion than a requirement at that point.

Right, though it's a shame that the registry-assigned ULA concept didn't
take off.

What everybody calls "Registered ULA" or ULA-C(entral) is what the RIRs
already provide. Also entities that have such a strict requirement are
perfectly served with address space the RIRs provide.

Jeroen,

Not so. The registries provide GUA, not ULA. Not everybody considers
the difference significant, but many if not most of the folks who want
to use ULA for anything at all do.

But if you want to stick to ULA anyway and you want a bit more certainty
that your ULA prefix does not clash, you can generate a random one as
per the RFC and register it:

IPv6 ULA (Unique Local Address) RFC4193 registration :: SixXS - IPv6 Deployment & Tunnel Broker

My "registration" was erased from that page. Don't know when. Don't
know why. But it speaks poorly for its function as a registry.

Regards,
Bill Herrin

13

A lot has to do with whether you have PA addresses of not. As for picking
a random prefix I suspect most home CPE devices will do the right thing.
It's also easy to do the right thing. I just did

  "dd if=/dev/random count=1 bs=5 | od -x"

and pulled the hex dig digits out to construct the ULA I use at home. A
little bit prettier version is below.

  #!/bin/sh
  dd bs=5 count=1 if=/dev/random 2> /dev/null |
  od -t x1 |
  awk 'NF == 6 { print "f8" $2 ":" $3 $4 ":" $5 $6 }'

  If you don't want to use /dev/random

  (ifconfig -a ; date ; netstat -na) | md5 |
  sed 's/\(..\)\(....\)\(....\).*/f8\1:\2:\3/'

  There are lots of ways to generate a suitable prefix.

14

We have one customer in particular with a substantial non-publicly
reachable v6 deployment with globally assigned addresses. I believe
there is no need to replicate the headaches of rfc1918 in the next
address-family eternity.

The one big issue I could see with doing that is that the vulnerability exposure, particularly from the outside world, is larger if devices that don't need public addresses have them. For example, if a network engineer or NOC person accidentally removes a "hide my public infrastructure from the outside world" from an interface on a border router...

Use different GUA ranges for internal and external. It's easy enough to get an additional prefix.

As others have mentioned, things like management interfaces on access switches, printers, and IP phones would be good candidates to hide with ULA.

Or non-advertised, filtered GUA. Works just as well either way.

Owen

15

[..]

Locally managed means locally manage, though. The RFC is more of
a suggestion than a requirement at that point.

Right, though it's a shame that the registry-assigned ULA concept didn't
take off.

What everybody calls "Registered ULA" or ULA-C(entral) is what the RIRs
already provide. Also entities that have such a strict requirement are
perfectly served with address space the RIRs provide.

Jeroen,

Not so. The registries provide GUA, not ULA. Not everybody considers
the difference significant, but many if not most of the folks who want
to use ULA for anything at all do.

I think you misunderstood my terminology, which is afaik the one used by
the relevant documents, but lets see where we go astray.

ULA consists out of two portions inside fc00::/7 which are:
  fd00::/8 for ULA-L (local) as the one defined by RFC4193
  fc00::/8 reserved for ULA-C which for instance is mentioned
           in draft-hain-ipv6-ulac-02

ULA-L is the one everybody uses and what most people just call ULA.

ULA-C is very close to GUA as they are both registered at some entity.
ULA-C does not exist though, the prime reason for that being that nobody
could come up with extensive reasons why it would be any different from
GUA and thus why anyone would bother having a registry for it (well,
apart from earning more money by registering numbers of course, like
what the rest of the industry is doing).

The only other reason would be that one can filter fc00::/7 away
completely and be done with both of them in one go. But, the moment that
one is using ULA space in one's network one is likely not applying that
rule, also, it does not come per default in boxes. And as we all know,
folks don't filter per BCP-38 either, thus it will be very unlikely that
there will be a global fc00::/7 block (and if that was one's line of
defense in their network then good luck with that :wink:

But if you want to stick to ULA anyway and you want a bit more certainty
that your ULA prefix does not clash, you can generate a random one as
per the RFC and register it:

IPv6 ULA (Unique Local Address) RFC4193 registration :: SixXS - IPv6 Deployment & Tunnel Broker

My "registration" was erased from that page. Don't know when. Don't
know why. But it speaks poorly for its function as a registry.

This was likely caused by the little note at the bottom:

"Prefixes which are not generated using the ULA generator will be
silently removed; ULAs are not supposed to look pretty."

Various folks are registering fd00::/48 or 'fun' stuff like
fd00:b00b::/48 or whole series of /48s (fd01::/48, fd02::/48 etc) and
then claim that they generated that prefix. For some obvious reason the
system does not agree with those statements.

Unfortunately there is no drop log, thus in case that the system did
make a wrong decision, there is a contact page where one can notify to
and we'll dig into it.

Greets,
Jeroen

16

What everybody calls "Registered ULA" or ULA-C(entral) is what the RIRs
already provide. Also entities that have such a strict requirement are
perfectly served with address space the RIRs provide.

Not so. The registries provide GUA, not ULA. Not everybody considers
the difference significant, but many if not most of the folks who want
to use ULA for anything at all do.

I think you misunderstood my terminology, which is afaik the one used by
the relevant documents,

Jeroen,

I knew I should have used the longer explanation.

From what I've been able to determine, the folks who want Unique Local

Addresses usually want a block of addresses which only function on
private networks. Should their packets ever leak on to the public
Internet, the ULA users want them to fail. By contrast, the registries
hand out Global Unicast Addresses. If packets with these addresses
make it to the public Internet, they'll probably work. This is not a
good thing if you're implementing a SCADA network whose hosts may need
to talk to another company network, or even a remote monitoring
company's network, but should never talk to hosts on the public
Internet.

I don't want to get into an argument over the security implications
(or non-implications) of addresses which are or are not publicly
routable. Suffice it to say there are networking professionals to whom
a GUA address is not a satisfactory substitute for a ULA address.
Hence, a registered ULA address IS NOT equivalent to what the RIRs
provide.

IPv6 ULA (Unique Local Address) RFC4193 registration :: SixXS - IPv6 Deployment & Tunnel Broker

My "registration" was erased from that page. Don't know when. Don't
know why. But it speaks poorly for its function as a registry.

This was likely caused by the little note at the bottom:

"Prefixes which are not generated using the ULA generator will be
silently removed; ULAs are not supposed to look pretty."

Various folks are registering fd00::/48 or 'fun' stuff like
fd00:b00b::/48

Hey, do you realize how many tries it took me to randomly generate
fd00:b00b::/48?

In all seriousness, though, while protecting against someone blindly
registering lots of naughts is probably reasonable, a registry isn't
worth much if it won't record the address ranges folks actually choose
to use. Regardless of how closely the RFC was followed in those
ranges' selection. In a sense, such a registry makes a net negative
contribution because its existence discourages the creation of another
organized effort.

Regards,
Bill

17

What everybody calls "Registered ULA" or ULA-C(entral) is what the RIRs
already provide. Also entities that have such a strict requirement are
perfectly served with address space the RIRs provide.

Not so. The registries provide GUA, not ULA. Not everybody considers
the difference significant, but many if not most of the folks who want
to use ULA for anything at all do.

I think you misunderstood my terminology, which is afaik the one used by
the relevant documents,

Jeroen,

I knew I should have used the longer explanation.

From what I've been able to determine, the folks who want Unique Local
Addresses usually want a block of addresses which only function on
private networks.

You mean similar to the fact that the RFC1918 prefixes people use at
home can be reached because they are using NAT-PMP or uPNP on their NAT box?

Should their packets ever leak on to the public
Internet, the ULA users want them to fail.

If one does not want packets to get to the Internet then don't connect
it to the Internet.

By contrast, the registries
hand out Global Unicast Addresses. If packets with these addresses
make it to the public Internet, they'll probably work.

Unless they are firewalled or the route is simply not announced at all.

Please remember that there is no requirement for a RIR-provided prefix
to be announced onto the Internet.

[..]

I don't want to get into an argument over the security implications
(or non-implications) of addresses which are or are not publicly
routable. Suffice it to say there are networking professionals to whom
a GUA address is not a satisfactory substitute for a ULA address.
Hence, a registered ULA address IS NOT equivalent to what the RIRs
provide.

Hmmm ah, yes, "Network professionals", they obviously know what they are
doing as they call them self professional, it is at least a very nice
imaginary line they have :wink:

But yes, there are people who bill their customers a lot for things that
are not correct. People need to earn money one way or another.

IPv6 ULA (Unique Local Address) RFC4193 registration :: SixXS - IPv6 Deployment & Tunnel Broker

My "registration" was erased from that page. Don't know when. Don't
know why. But it speaks poorly for its function as a registry.

This was likely caused by the little note at the bottom:

"Prefixes which are not generated using the ULA generator will be
silently removed; ULAs are not supposed to look pretty."

Various folks are registering fd00::/48 or 'fun' stuff like
fd00:b00b::/48

Hey, do you realize how many tries it took me to randomly generate
fd00:b00b::/48?

It is indeed possible, but it likely took you a lot of time on a very
nice fat supercomputer. Better spend your resources on something else I
would say.

In all seriousness, though, while protecting against someone blindly
registering lots of naughts is probably reasonable, a registry isn't
worth much if it won't record the address ranges folks actually choose
to use.

It is a registry for ULA addresses, these are random, not hand-picked.
If one cannot simply use the button which is located a bit above it,
then well, that is not the purpose of it.

We could have opted to allow only to register prefixes that where
generated by that output, but we chose to allow people who have
generated the prefixes locally to submit those too.

Regardless of how closely the RFC was followed in those
ranges' selection. In a sense, such a registry makes a net negative
contribution because its existence discourages the creation of another
organized effort.

I don't see how it makes a negative contribution. The people registering
non-ULA registered prefixes are doing so though, then again, they
automatically disappear thus it is a non-issue.

The script for generating the ULA is linked at the bottom of the page
and I am sure that anybody with 30 minutes of time can fix up a way of
storing prefixes into a file/db from a HTTP form... next to the complete
list being downloadable so if people want to clone it, it would be quite
easily done, note also that the offer for a RIR to take it over still
stands as stated on the page.

Greets,
Jeroen

18

Jeroen,

I once worked with an otherwise brilliant gentleman who in his rigid
mindset earnestly believed that the correct solution to contingency
planning was: don't make mistakes. He gave notice when he figured out
that hiring me was the owner's contingency plan.

Regards,
Bill Herrin

19

Use different GUA ranges for internal and external. It's easy enough to
get an additional prefix.

> As others have mentioned, things like management interfaces on access
switches, printers, and IP phones would be good candidates to hide with
ULA.

Or non-advertised, filtered GUA. Works just as well either way.

Owen

If one is obtaining "another" prefix for local addressing, I see no benefit. I am assuming that anyone that is using ULA is using it for things that don't communicate off the site such as management interfaces of things, etc. This won't be a subnet you are connecting by VPN to another organization, usually, but even if you do the chances of collision is pretty low if you select your nets properly. But for the most absolutely paranoid site, I can see some appeal in using ULA in conjunction with DNS64/NAT64 and see them giving the devices internet access via v4. Not that I agree with the notion, mind you, just that I can see someone looking at that as an appealing solution for some things. Even if someone managed to get through the NAT device via v4, they would have nothing to talk to on the other side as the other side is all v6.

20

So the issue of ULAs has come up in the IETF homenet WG. The homenet WG is considering routing, prefix delegation, security, naming and service discovery.

ULA support is written into RFC6204 (basic IPv6 requirements for CPE routers) so home CPEs should have the capability, and should be able to generate "random" ULA prefixes.

The potential advantage of ULAs is that you have a stable internal addressing scheme within the homenet, while your ISP-assigned prefix may change over time. You run ULAs alongside your PA prefix. ULAs are not used for host-based NAT. The implication is that all homenet devices carry a ULA, though whether some do not also have a global PA address is open for debate.

There's a suggestion that ULAs could be used to assist security to some extent, allowing ULA to ULA communications as they are known to be within the homenet.

The naming and service discovery elements should remove the need to ever manually enter a ULA prefix; thus the temptation to use 0 instead of random bits for the ULA prefix should be reduced (even if the CPE allows it).

Prefix delegation of ULAs within a homenet would be done the same way as for the global PA prefix.

There is a proposal (not from within the homenet WG) to use ULAs with NPT66 (RFC6296). That obviously has some architectural implications.

Tim