IPV6 planning

Mailman List Mirror (Read Only)
1

Hiya,

We are currently considering deploying IPv6 for a Lan event in April. We are assigned a /48 which we then split into smaller subnets for each player vlan. That said, what remains to be decided is how we are going to assign the IPv6. Basically, it seems that are two ways, one SLAAC where the endpoints uses RA to generate it's own IP and DHCPv6 which is basically DHCP but for IPv6.

Large events like Dreamhack have used SLAAC and the feedback has been mostly positive. Can anyone comment regarding past experiences with IPv6 gotchas and things that you don't really expect when running dual-stack on a large-ish network?

Thanks!

Laurent

2

SLAAC is the way you want to do, as DHCPv6 does not give you a default
gateway.

If you want IPv6 DNS resolvers, DHCPv6 is a good option, which means a
hybrid of DHCPv6 and SLAAC is reasonable.

Mark.

3

And note that there isn't any problem with a machine getting an IPv6 address
via SLAAC *and* getting another one via DHCPv6 - my laptop is doing that as I
type (plus a privacy address or two as well).

4

That is what our CPEs (from Inteno) do. Every computer has a DHCPv6
assigned address that is short and easy (my laptop has 2a00:7660:5c6::30e).
The DHCPv6 assigned address is also stable. In the CPE admin website the
user can pick the computer (DHCPv6 assigned address) from a dropdown when
configuring inbound firewall rules. It is very easy to eg. allow SSH to my
laptop by using this feature.

But every computer also have SLAAC and usually with privacy extensions. My
laptop prefers the SLAAC/privacy address for outgoing connections. So I am
not as easily tracked as if the computer used the DHCPv6 address. Currently
my outgoing connections are from 2a00:7660:5c6::bd7d:624c:2d8c:c8d0 but
this will change shortly to something new and random.

Short and stable for inbound, random for outbound.

Regards,

Baldur

5

SLAAC is way easier:
- no DHCPv6 server is required
- every IPv6-capable device can do it
- you only have to configure the router

With SLAAC you don't get DNS names, whereas DHCPv6 can update the DNS
for you. You can let player hosts update the DNS directly, but it's
more open to abuse. Or maybe you don't need names anyway.

Other thing with SLAAC is that you get 64-bit subnets and only 64-bit
subnets. This should not be any kind of problem with a flat /48, but if
you will have more complicated subnetting you should keep an eye on it.

Unless you take steps to prevent SLAAC happening, SLAAC will happen.
The simplest way to prevent it happening is to allocate non-64-bit
subnets to the router interfaces.

The biggest gotcha (or gotchas) you will face is/are buggy IPv6
implementations on the router/switch side - especially the switches. A
small test setup to make sure that your expected host operating systems
all work as expected with your planned network infrastructure would be
a Very Good Idea.

Second biggest gotcha will be forgetting to secure IPv6. IPv6 packet
filters, firewall rules etc are all completely separate and independent
from your IPv4 stuff.

Third gotcha - related to the second - is forgetting that your IPv6
-connected hosts are not behind NAT and are thus directly exposed to
the Internet via IPv6 unless you take steps to make it not so. You
should probably provide at least the same basic setup for IPv6 on your
outside router interfaces that NAT provides for IPv4, plus ICMPv6.
I.e.:
- allow established/related inbound
- allow all ICMPv6
- allow all outbound
- block all inbound

A possible gotcha is people using temporary or privacy IPv6 addressing,
which is the default on many modern operating systems. Addresses change
- on boot for temporary addresses, at regular intervals. Whether that
will be a problem or not depends on whether the hosts will be using
long-lived connections.

You may find that some participants have disabled IPv6. Since you are
dual stack this shouldn't be an issue, unless your IPv6 connectivity is
faster than your IPv4 connectivity. Might be worth getting up to speed
on how to enable/disable IPv6 on various operating systems so that you
can advise people.

Regards, K.

6

Technically speaking there is no reason not to support SLAAC on
arbitrary size networks. I believe Cisco happily will autogenerate
address for smaller subnets.

7

To support SLAAC with prefix lengths other than 64 you would have to
break numerous standards. RFC2464 is very clear on the matter, at least
for Ethernet interfaces, though RFC 4862 is carefully non-committal.

Even if the router supports it, as far as I know a standards-conforming
host MUST ignore such prefixes for purposes of SLAAC on Ethernet.

As far as "technically speaking" goes, recall that the host generates
its own address; the only information supplied by the router is the
prefix and an A flag. There is no way for the router to tell hosts
*how* to generate the address. The hosts would have work out where in
the shorter (or longer) prefix the MAC address should go. If the prefix
is too short the hosts would have to work out which bits to discard,
and would have to work out which bit (if any) should be complemented to
indicate local vs global assignment. Might be a good idea to keep least
significant bits, to minimise impacts on solicited node multicast
addresses. Dunno what would happen to solicited node multicast if you
increased the prefix length beyond 104.

Temporary and privacy addresses might be easier - all you would need to
do would be randomise whatever bits were available to you, though as
prefixes got longer your protection would decrease.

There might be more to it than that - haven't really thought it
through.

So to change the prefix length for SLAAC I think you would have to own
the whole ecosystem including host stacks. So while Cisco may support
it on router interfaces, I suspect it wouldn't actually *work* in
practice. But I have been wrong oh, so many times...

Regards, K.

8

And note that there isn't any problem with a machine getting an IPv6
address via SLAAC *and* getting another one via DHCPv6 - my laptop is doing that as I type (plus a privacy address or two as well).

That is what our CPEs (from Inteno) do. Every computer has a DHCPv6
assigned address that is short and easy (my laptop has 2a00:7660:5c6::30e).
The DHCPv6 assigned address is also stable. In the CPE admin website the
user can pick the computer (DHCPv6 assigned address) from a dropdown when
configuring inbound firewall rules. It is very easy to eg. allow SSH to my
laptop by using this feature.

But every computer also have SLAAC and usually with privacy extensions. My
laptop prefers the SLAAC/privacy address for outgoing connections. So I am
not as easily tracked as if the computer used the DHCPv6 address. Currently
my outgoing connections are from 2a00:7660:5c6::bd7d:624c:2d8c:c8d0 but
this will change shortly to something new and random.

Short and stable for inbound, random for outbound.

Just because this often seems to get overlooked:

In a SLAAC-only environment, even with privacy extensions enabled, client operating systems still generate a stable address for inbound connections...at least the ones I generally interact with and that you'd be likely to find in a LAN event. For Linux and OS X, this will be an EUI-64 address; Microsoft decided to be special and generates a random interface ID for this rather than use EUI-64, but that random interface ID is still stable.

This doesn't get you the "short" part of the "short and stable for inbound, random for outbound" DHCPv6 + SLAAC w/ privacy addresses scenario, but it does get you "stable for inbound" as well as "random for outbound", since privacy/temporary addresses are still preferred for outbound.

You don't get the benefit of the CPE being aware of the user's stable address in a nice, user-friendly drop-down, but that's your call wrt how much value that provides.

Back to the original question:

Basically, it seems that are two ways, one SLAAC where the endpoints uses RA to generate it's own IP and DHCPv6 which is basically DHCP but for IPv6.

Pretty much, but with some nuances.

At the very least, you will want:

1. an IPv6 address
2. a default gateway
3. resolvers and possibly a dns domain / search suffix

Assuming you're not making everyone do static config, your options for #1 are:
i) stateful DHCPv6 (IA_NA)
ii) SLAAC, with the assumption that your users will in all likelihood have privacy extension enabled

#2, as has already been stated, comes from your RA.

#3 is the trick. You *can* technically get resolver info from the RA with RDNSS, but that assumes (a) your network gear can put RDNSS in its RAs and (b) your clients all support RDNSS. You still can't bank on either of those. So, that means you're running stateless DHCPv6 for resolver info.

...or, given that you're going dual-stack, you can be a lazy bum, assume everyone will be dual stack and do DHCPv4 as well, and stick resolver info in your DHCPv4 options and call it a day...but then we'd have to hunt you down for IPv6 heresy, plus if you have any single-stack v6 users, you're leaving them out in the cold.

My personal recommendation/preference:
SLAAC + stateless DHCPv6, plus RDNSS if your network gear supports it because why not,
i.e. RA flags are: M=0 & O=1, and A=1 for your onlink prefix.

Large events like Dreamhack have used SLAAC and the feedback has been mostly positive. Can anyone comment regarding past experiences with IPv6 gotchas and things that you don't really expect when running dual-stack on a large-ish network?

Karl already pointed out some good bits.

Unless you take steps to prevent SLAAC happening, SLAAC will happen.
The simplest way to prevent it happening is to allocate non-64-bit
subnets to the router interfaces.

...or don't set the A flag in your RAs and hope the clients respect that; I've not personally run big issues with clients going all SLAAC-y when A=0, but due diligence etc.

- allow all ICMPv6

Folks that haven't pushed out v6 nets yet often miss this one. Friends don't let friends break PMTUD. If people get all uppity about allowing in ICMPv6 from the WAN side because they're used to discarding WAN-side ping in v4 and you can't put your foot down heavy enough, at *least* get them to give you ICMPv6 types 1-4 and 128,129 inbound.

Whether or not temporary addresses are a concern for your LAN event are a factor of how long-lived sessions need to be for your application(s) and how your clients are config'd. You can't guarantee the clients' configs for TEMP_VALID_LIFETIME, though if they haven't futzed with it that should be a week.

Cheers, and here's wishing you a great event!

9

To support SLAAC with prefix lengths other than 64 you would have to
break numerous standards. RFC2464 is very clear on the matter, at least
for Ethernet interfaces, though RFC 4862 is carefully non-committal.

Yes, SLAAC, 4862 clearly does not forbid it, and there is no technical reason.
But as you state, 2464 does not specify other behaviour. Writing new
draft which specifies behaviour for arbitrary size wouldn't be a
challenge, marketing it might be.

From implementation POV, arbitrary prefix-size from 4862 is fairly

obvious and logical, and dictating 64 is very weird, with no obvious
benefits at all. I suspect the 64 must have come into IPv6 ethernet
standard before people thought of DAD, and assumption was uniqueness
was guaranteed by use of BIA (HAH!), that's only background that I can
imagine where mandating /64 might be remotely sane thought process.
Post-DAD it's just artificial complexity which reduces expressiveness.

Even if the router supports it, as far as I know a standards-conforming
host MUST ignore such prefixes for purposes of SLAAC on Ethernet.

I can't recall where it would be worded so harshly. But I agree that
it's not good idea /NOW/ to use it, even if it works on some
implementations.

10

* Saku Ytti

Yes, SLAAC, 4862 clearly does not forbid it, and there is no
technical reason. But as you state, 2464 does not specify other
behaviour. Writing new draft which specifies behaviour for arbitrary
size wouldn't be a challenge, marketing it might be.

FYI: RFC 7421 is an in-depth discussion of the fixed 64-bit boundary.

Tore

11

Yes, SLAAC, 4862 clearly does not forbid it, and there is no
technical reason.

Well - yes, there are some, and I think I pointed out several.

Writing new
draft which specifies behaviour for arbitrary size wouldn't be a
challenge

I think you may find it more difficult than you think. But by all means
write that draft.

From implementation POV, arbitrary prefix-size from 4862 is fairly
obvious and logical, and dictating 64 is very weird, with no obvious
benefits at all.

/64 has a lot of benefits (some one which would be shared by any fixed
-length prefix, some not), but I'm not sure detailing them here would
be appreciated. They've all been gone over at length here and elsewhere
many times before. As Tore just wrote before I finished this :slight_smile:
there's even a collected summary of many of pros and cons in RFC 7421,
which by the way has lots of good references.

that's only background that I can imagine where mandating /64 might
be remotely sane thought process.

The argument from personal incomprehension is not a very powerful one.

I can't recall where it would be worded so harshly.

Dunno about "harsh", but RFC 2464, section 4 says that the prefix must
be 64 bits. By (extremely strong) implication, a host must not use a
prefix of any other length to perform SLAAC. I say "extremely strong"
because the entire description of how an IPv6 Ethernet interface
identifier is formed depends on it being composed of the prefix plus an
EUI-64 identifier. Later RFCs firm up the requirement and apply it in
other contexts.

BUT: Other prefix lengths are fine for anything except automatically
formed interface identifiers, as far as I know.

Regards, K.

12

Just to amplify what Hugo wrote, there is DNS support with SLAAC (see RFC 6106), but router and client support mixed. In the end, I would recommend support DHCPv6 and SLAAC, and if your router support RFC 6106, stuff the DNS information in there, too.

Frank

13

But the most popular OS (Windows) completely ignores all of that and makes
up an identifier not based on EUI-64. Everyone are happy anyway. The RFC
should have let identifier selection as an implementation detail as the
risk of collision is almost non existent given a sufficient random
selection and we have duplicate address detection as a safeguard.

Regards

Baldur

14

Privacy and temporary addresses are two of the three SLAAC types. One
critical requirement for the original SLAAC is that the address doesn't
change; for devices without writable storage, that requires a
deterministic algorithm to generate the address. A further critical
requirement was that devices be able to get connected with zero host co
nfiguration - globally and locally.

For temporary and privacy addresses, where permanence is not an issue,
you can use any prefix length, though as I said in my original
response, your protection diminishes the longer the prefix gets.

I'm not trying to be an apologist for those who designed IPv6, but I
really don't think they were stupid, and it's not as simple a situation
as people seem to think.

My initial response was to someone who said they thought Cisco
supported varying prefix lengths with SLAAC. I said it wan't just up to
Cisco, the hosts had to play ball too, and I don't think they do. But,
as already noted, I could be wrong :slight_smile:

Regards, K.

15

Hiya,

We are currently considering deploying IPv6 for a Lan event in April.
We are assigned a /48 which we then split into smaller subnets for
each player vlan. That said, what remains to be decided is how we are
going to assign the IPv6. Basically, it seems that are two ways, one
SLAAC where the endpoints uses RA to generate it's own IP and DHCPv6
which is basically DHCP but for IPv6.

Large events like Dreamhack have used SLAAC and the feedback has been
mostly positive. Can anyone comment regarding past experiences with
IPv6 gotchas and things that you don't really expect when running
dual-stack on a large-ish network?

SLAAC is the way you want to do, as DHCPv6 does not give you a default
gateway.

Though you will inherently get one from the RA packet that tells you to
ask DHCPv6 for information anyway.

If you want IPv6 DNS resolvers, DHCPv6 is a good option, which means a
hybrid of DHCPv6 and SLAAC is reasonable.

Or you can use RFC6106 in your RAs on SLAAC.

Owen

16

To the best of my knowledge, Windows actually generates three addresses…

1. Subnet Stable quasi-randomized address unrelated (or at least not reversable to) MAC address.
2. Privacy address which rotates frequently (for some definition of frequently).
3. Stable address related to MAC address.

The 3rd one is standard SLAAC.
The second one is standard privacy extensions.
THe first one is unique to Windows. You’ll get the same address every time you connect to the same subnet, but you won’t see that suffix for that host on any other subnet.

Owen

17

It’s not exactly specific to Windows, dhcpcd use a something like that
(my IPv6 is 2a00:5884:8316:2653:fd40:d47d:556f:c426). And at least,
there is a RFC related to that, https://tools.ietf.org/html/rfc7217.

18

Yes, but in the case of Windows, that happens with SLAAC without DHCP.

TTBOMK, this is unique to windows.

Owen

19

It appears that RFC 7217 does not actually demand a 64 bit interface
identifier. One could therefore do a non-64 bit RFC 7217 SLAAC on operating
systems that support that.

"We note that [RFC4291] requires that the Interface IDs of all
          unicast addresses (except those that start with the binary
          value 000) be 64 bits long. However, the method discussed in
          this document could be employed for generating Interface IDs
          of any arbitrary length, albeit at the expense of reduced
          entropy (when employing Interface IDs smaller than 64 bits)."

Regards,

Baldur

20

Owen DeLong <owen@delong.com> writes:

It’s not exactly specific to Windows, dhcpcd use a something like that
(my IPv6 is 2a00:5884:8316:2653:fd40:d47d:556f:c426). And at least,
there is a RFC related to that, RFC 7217 - A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC).

Yes, but in the case of Windows, that happens with SLAAC without DHCP.

Yes, and SLAAC is what rfc7217 is about

TTBOMK, this is unique to windows.

Nope. See for example the stable_secret setting in
https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt

But Linux doesn't create this in addition to the EUI-64 derived
address. It creates in instead. And it won't happen by default. Only
if you configure a secret. Except for weird interfaces without any
EUI-64 identifier, like raw IP interfaces, which will use this code to
support SLAAC.

How does Windows manage to *use* three addresses? I can understand how
the rfc7217 address and the privacy address can be use for different
purposes, but what do they use the EUI-64 address for?

Bjørn