using "reserved" IPv6 space

Mailman List Mirror (Read Only)
1

OK. I'm pretty sure I'm gonna get some flak for this but I'll share this question and it's background anyway. Please be gentle.

In the past, with IPv4, we have used reserved or "non-routable" space Internally in production for segments that won't be seen anywhere else. Examples? A sync VLAN for some FWs to share state. An IBGP link between routers that will never be seen or advertised. In those cases, we have often used 192.0.2.0/24. It's reserved and never used and even if it did get used one day we aren't "routing" it internally. It's just on segments where we need some L3 that will never be seen.

On to IPv6

I was considering taking the same approach. Maybe using 0100::/8 or 1000::/4 or A000::/3 as a space for this.

Other than the usual "Hey, you shouldn't do that" can anyone give me some IPv6 specific reasons that I may not be forecasting that would make it worse doing this than in an IPv4 scenario. I know, not apples to apples but for this question they are close enough. Unless there is something IPv6 specific that is influencing this....

2

Hammer wrote:

In the past, with IPv4, we have used reserved or "non-routable" space
Internally in production for segments that won't be seen anywhere else.
Examples? A sync VLAN for some FWs to share state. An IBGP link between
routers that will never be seen or advertised. In those cases, we have
often used 192.0.2.0/24. It's reserved and never used and even if it did
get used one day we aren't "routing" it internally. It's just on
segments where we need some L3 that will never be seen.

On to IPv6

I was considering taking the same approach. Maybe using 0100::/8 or
1000::/4 or A000::/3 as a space for this.

Why can't you just generate a ULA and use that?

Regards,

Leo

3

There is this very nice concept called ULA (RFC4193), use it.
If you want to be more sure about uniqueness, use
http://www.sixxs.net/tools/grh/ula/
or you can also just use a chunk of your 'global' prefix and don't
announce a route for it and firewall it off properly.

Greets,
Jeroen

4

Leo/Jeroen,
     Thank you both. That is the simple answer that I wasn't thinking of. I'm not as IPv6 savvy as I need to be (yet) so I haven't put all the pieces together when trying to look at the bigger picture. Thanks again.

-Hammer-

"I was a normal American nerd"
-Jack Herer

5

Would using "just" Link Locals not be sufficient?
*(Failing that, as others noted, ULAs are the next "right" answer ... )*

6

I think they would. I'm just a bit too new to this. Thanks.

-Hammer-

"I was a normal American nerd"
-Jack Herer

7

As an IPv6 newbie myself, I wonder how hosts handle link local, ULA and
global addresses.
For example, if you have some internal web traffic used for intranet use
only, do you bind those servers to use only ULA addresses? This way your
internal users with ULA addressing only have access to those servers? No
need to give intranet-only servers a global address if they're not needed
to be accessed globally.

Is there a way for hosts to "prefer" or "attempt" to connect to a service
by first trying a link-local scope, then a ULA and finally a global address
if its off the AS?
I really like the idea of ULA and think it makes much more sense than
RFC1918 + NAT. I just don't have any deployment experience with it yet so
I'm curious how the host would handle it.

On the router side, I'm sure ULA and global routing just run as
ships-in-the-night side-by-side anyways...right?

8

There is an RFC that describes how hosts should select addresses in such situations,

  http://tools.ietf.org/html/rfc3484

As an side; it would be great if some more IPv6 questions could be put on http://ipv6exchange.net/ - I would love to see that become a useful resource for people starting out with IPv6. If you have an IPv6 question, please do post!

Cheers,

aid

9

I'm having similar thoughts and we are about to implement. Fortunately we are implementing in an isolated lab first for this exact reason. For us to figure things out first before attempting them elsewhere.

I like the ULA approach. I'm not sure about link local being used as strategy for Internal services. I'm finally getting to the point where I'm looking past the vastness of the numbers and just focusing on subnets and masks and subnetting and whatnot.

-Hammer-

"I was a normal American nerd"
-Jack Herer

10

Note that I meant using Link Locals for directly connected devices *(neighbors;
e.g. - routing protocol neighborship formation)*.
If they are not on-link with each other, Link Locals are a non-starter ...
ULAs would be a possible solution for a completely disconnected network.

Note that many are proponents of using Globals even in those situations,
with judicious filtering stopping any inboud/outbound traffic.
The benefit being that "it's never going to be connected " doesn't really,
always mean "it's never going to be connected" :).

*YMMV, as always!*
/TJ

11

See RFC 3849 - http://tools.ietf.org/html/rfc3849

Which pre-scribed the range: 2001:DB8::/32 for use in Documentation. I
suppose this could be used for lab testing.

*ducks flames*

12

[..]

As an IPv6 newbie myself

Play with it and get your ears wet, it is still not entirely too late to
start to learn to swim :wink:

, I wonder how hosts handle link local, ULA and
global addresses.
For example, if you have some internal web traffic used for intranet use
only, do you bind those servers to use only ULA addresses? This way your
internal users with ULA addressing only have access to those servers? No
need to give intranet-only servers a global address if they're not needed
to be accessed globally.

You could do that indeed, thus have clients have only a global (and
link-local address) and only make a certain prefix, be that ULA or a
specific chunk of your global prefix only available to your internal
network that are used for your internal services.

As long as the prefix is stable you likely do not care if it is global
or ULA, this as when a misconfiguration happens in such a way that that
prefix is not properly firewalled away or gets routed it happened. As
can be clearly seen in various routing tables filtering is not happening
everywhere, thus it won't buy you that much; proper policy, automation
and verification will avoid fat fingers much better though.

Also, not that a firewalled prefix only brings one that much security,
the higher chance is that the client host gets infected or compromised.

Is there a way for hosts to "prefer" or "attempt" to connect to a service
by first trying a link-local scope, then a ULA and finally a global address
if its off the AS?

RFC3484, aka /etc/gai.conf and friends on other OSs. It is not easy to
distribute this though.

I really like the idea of ULA and think it makes much more sense than
RFC1918 + NAT. I just don't have any deployment experience with it yet so
I'm curious how the host would handle it.

ULA is meant for non-internet connected devices. As such NAT does not
come into play as one will have a unique ULA prefix that will not clash
when you inter connect them privately with other networks.

RFC1918 + NAT primarily makes sense as it allows one to hookup devices
to the Internet without 'wasting' more public addresses, that problem
does not exist with IPv6 though.

Greets,
Jeroen

13

-Hammer- <bhmccie@gmail.com> a écrit sur 13/07/2012 12:21:13 PM :

I like the ULA approach.

Global and ULA are two approach, but there's a third one: GUA + ULA. We
actually put a GUA on servers speaking publicly, a ULA on servers speaking
in our domain only and *both* ULA and GUA on servers which talk both ways.
Our datacenter firewalls are configured to enforce GUA-GUA and ULA-ULA
connections only (just simple URPF over two interfaces).

This setup works very well, surprisingly we've had very little source
address selection problems so far (knock on wood). We're very happy that
the separation between public and "private" networks is clear, it helps a
lot with debugging and service separation.

/JF

14

Of the top of my head, the first problem you might hit there is
WRT multicast ...
*(ULA might "win" some source address selections that you want GUA to win)*
/TJ

15

TJ <trejrco@gmail.com> a écrit sur 13/07/2012 02:47:26 PM :

Of the top of my head, the first problem you might hit there is
WRT multicast ...
(ULA might "win" some source address selections that you want GUA to

win)

/TJ

Good point, thanks for pointing that out. We'll see when we deploy
network-wide IPv6 multicast... not there (yet).

/JF

16

keep life simple. use global ipv6 space.

randy

17

Though it is rare, this is one time when I absolutely agree with Randy.

Owen

18

It's even more rare for me to agree with Randy AND Owen at the same time.

19

If it is a hostile lab environment, then pre decide on the address space to be used by the company and auto include that into all production routers policies to drop it like a hot potatoes covered in lava.

20

Le 13/07/12 16:38, -Hammer- a �crit :

In the past, with IPv4, we have used reserved or "non-routable"

I guess "non-routable IPv4" translates well to "non-routable IPv6", thus
putting Link-Local addresses on top of the list.

Thought you may use th auto-configured addresses for that purpose, you
also may set LLAs to your liking. I use fe80::zone_ID:interface_ID , and
set such LLA to every gateways to make routing tables more legible,
those ID beeing arbitrary 16bit values.

Any other address class will work well, but I'd rather not use reserved
space outside of GUA, ULA our LLA scopes to avoid bug-hunting on poorly
implemented IPv6 stacks.