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
On 5/Mar/16 23:19, Laurent Dumont wrote:
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. If you want IPv6 DNS resolvers, DHCPv6 is a good option, which means a hybrid of DHCPv6 and SLAAC is reasonable. Mark.
On Sat, 05 Mar 2016 23:46:59 +0200, Mark Tinka said:
If you want IPv6 DNS resolvers, DHCPv6 is a good option, which means a hybrid of DHCPv6 and SLAAC is reasonable.
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).
On 5 March 2016 at 22:54, <Valdis.Kletnieks@vt.edu> wrote:
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. Regards, Baldur
On Sat 2016-Mar-05 23:30:10 +0100, Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
On 5 March 2016 at 22:54, <Valdis.Kletnieks@vt.edu> wrote:
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! -- Hugo Slabbert | email, xmpp/jabber: hugo@slabnet.com pgp key: B178313E | also on Signal
On Mar 5, 2016, at 13:46 , Mark Tinka <mark.tinka@seacom.mu> wrote:
On 5/Mar/16 23:19, Laurent Dumont wrote:
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
On Sat, 2016-03-05 at 16:19 -0500, Laurent Dumont wrote:
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.
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. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4
On 6 March 2016 at 00:59, Karl Auer <kauer@biplane.com.au> wrote:
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.
Technically speaking there is no reason not to support SLAAC on arbitrary size networks. I believe Cisco happily will autogenerate address for smaller subnets. -- ++ytti
On Sun, 2016-03-06 at 01:57 +0200, Saku Ytti wrote:
Technically speaking there is no reason not to support SLAAC on arbitrary size networks. I believe Cisco happily will autogenerate address for smaller subnets.
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. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4
On 6 March 2016 at 03:08, Karl Auer <kauer@biplane.com.au> wrote:
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. -- ++ytti
* 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
On Sun, 2016-03-06 at 13:53 +0200, Saku Ytti wrote:
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 :-) 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. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4
Den 6. mar. 2016 13.41 skrev "Karl Auer" <kauer@biplane.com.au>:
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 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
On Mon, 2016-03-07 at 02:57 +0100, Baldur Norddahl wrote:
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.
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 :-) Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4
On Mar 6, 2016, at 17:57 , Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
Den 6. mar. 2016 13.41 skrev "Karl Auer" <kauer@biplane.com.au>:
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 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.
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
On Mon Mar 7 15:51:06 2016, Owen DeLong wrote:
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.
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. -- alarig
On Mar 7, 2016, at 16:01 , Alarig Le Lay <alarig@swordarmor.fr> wrote:
On Mon Mar 7 15:51:06 2016, Owen DeLong wrote:
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.
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.
Yes, but in the case of Windows, that happens with SLAAC without DHCP. TTBOMK, this is unique to windows. Owen
Owen DeLong <owen@delong.com> writes:
On Mar 7, 2016, at 16:01 , Alarig Le Lay <alarig@swordarmor.fr> wrote:
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.
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
Hi, On Tue, Mar 08, 2016 at 07:35:55PM +0100, Bj??rn Mork wrote:
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?
Windows doesn't use/create a third EUI-64 address. By default it only creates that "kind-of random, kind-of stable" address (unrelated to RFC 2117) and a temporary address. No EUI-64 address (by default). It *can* create, by a specific setting, an EUI-64 address but that would replace the above mentioned 1st (non-temporary) one. best Enno
Bj??rn
-- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator =======================================================
On 8 March 2016 at 01:01, Alarig Le Lay <alarig@swordarmor.fr> wrote:
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.
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
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 -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Karl Auer Sent: Saturday, March 05, 2016 5:00 PM To: nanog@nanog.org Subject: Re: IPV6 planning On Sat, 2016-03-05 at 16:19 -0500, Laurent Dumont wrote:
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.
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. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4
On 05.03.2016 22:19, Laurent Dumont wrote:
Hiya,
Hi,
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?
For The Gathering 2015 we used DHCPv6 for IPv6. The reason for this was both tracability and security with IPv6 first-hop security (DHCPv6-guard, IPv6 source-guard, etc). We did the same for both wired and wireless clients which caused Android devices to not get IPv6 connectivity, but it worked great on iOS devices and Windows Phones. You can run SLAAC for wireless clients if you want Android-devices to get IPv6 as well, but we wanted the same setup for all clients. IMHO it's really up to Google (Lorenzo?) to get their OS to support the same standards as everyone else does now. We had around 5000 participants, ~160 edge switches (Juniper EX2200) and we had no issues with dual-stacked clients at all. First-hop security worked like a charm and I think more than 85% of all wired clients had IPv6 connectivity. Here are a graph for the IPv4:IPv6 traffic ratio on the internet connection for the event (30Gbit/s total capacity): http://bgp.no/stuff/rs1.tele-tg.png As you can see we weren't near filling the pipe even though each client had 1Gbit/s wired connection and each edge switch had 3*1Gbit/s LAG toward the distribution layer (Juniper EX3300-VC). The IPv6 traffic ratio are also fairly low, but this is only natural as people attending these kinds of event uses a lot of services not available over IPv6 (Valves Steam, EAs Origin, Torrents, etc). I also see other people in the thread mentions firewalling. We didn't do any sort of inbound filtering. We've always provided the clients with public IPv4 addresses (borrowed PI-space from RIPE) and at events like this we feel it's up to the participants to secure their machines. We do still have a support crew that can assist participants with computer issues, but we haven't really had any issues with this since back in the days of WinNuke and the Blaster virus. Feel free to ask any further questions regarding our setup either on- or off-list. We're all about openness and all code/config created for the event is publicly available online. :-) Good luck with your event! -- Harald
participants (14)
-
Alarig Le Lay -
Baldur Norddahl -
Bjørn Mork -
Enno Rey -
frnkblk＠iname.com -
Harald F. Karlsen -
Hugo Slabbert -
Karl Auer -
Laurent Dumont -
Mark Tinka -
Owen DeLong -
Saku Ytti -
Tore Anderson -
Valdis.Kletnieks＠vt.edu