[188041] in North American Network Operators' Group
Re: IPV6 planning
daemon@ATHENA.MIT.EDU (Hugo Slabbert)
Sun Mar 6 00:46:07 2016
X-Original-To: nanog@nanog.org
Date: Sat, 5 Mar 2016 21:46:02 -0800
From: Hugo Slabbert <hugo@slabnet.com>
To: Baldur Norddahl <baldur.norddahl@gmail.com>
In-Reply-To: <CAPkb-7CPphnuTcfAeouzOAkc6C630GgZDDhOV_NXFfzWnbeDaQ@mail.gmail.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
--zbGR4y+acU1DwHSi
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sat 2016-Mar-05 23:30:10 +0100, Baldur Norddahl <baldur.norddahl@gmail.c=
om> 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=20
>> 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=
=20
operating systems still generate a stable address for inbound=20
connections...at least the ones I generally interact with and that you'd be=
=20
likely to find in a LAN event. For Linux and OS X, this will be an EUI-64=
=20
address; Microsoft decided to be special and generates a random interface=
=20
ID for this rather than use EUI-64, but that random interface ID is still=
=20
stable.
This doesn't get you the "short" part of the "short and stable for inbound,=
=20
random for outbound" DHCPv6 + SLAAC w/ privacy addresses scenario, but it=
=20
does get you "stable for inbound" as well as "random for outbound", since=
=20
privacy/temporary addresses are still preferred for outbound.
You don't get the benefit of the CPE being aware of the user's stable=20
address in a nice, user-friendly drop-down, but that's your call wrt how=20
much value that provides.
Back to the original question:
>>>>Basically, it seems that are two ways, one SLAAC where the endpoints=20
>>>>uses RA to generate it's own IP and DHCPv6 which is basically DHCP but=
=20
>>>>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=
=20
are:
i) stateful DHCPv6 (IA_NA)
ii) SLAAC, with the assumption that your users will in all likelihood have=
=20
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=
=20
RDNSS, but that assumes (a) your network gear can put RDNSS in its RAs and=
=20
(b) your clients all support RDNSS. You still can't bank on either of=20
those. So, that means you're running stateless DHCPv6 for resolver info. =
=20
=2E..or, given that you're going dual-stack, you can be a lazy bum, assume=
=20
everyone will be dual stack and do DHCPv4 as well, and stick resolver info=
=20
in your DHCPv4 options and call it a day...but then we'd have to hunt you=
=20
down for IPv6 heresy, plus if you have any single-stack v6 users, you're=20
leaving them out in the cold.
My personal recommendation/preference:
SLAAC + stateless DHCPv6, plus RDNSS if your network gear supports it=20
because why not,
i.e. RA flags are: M=3D0 & O=3D1, and A=3D1 for your onlink prefix.
>>>>Large events like Dreamhack have used SLAAC and the feedback has been=
=20
>>>>mostly positive. Can anyone comment regarding past experiences with=20
>>>>IPv6 gotchas and things that you don't really expect when running=20
>>>>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.
=2E..or don't set the A flag in your RAs and hope the clients respect that;=
=20
I've not personally run big issues with clients going all SLAAC-y when A=3D=
0,=20
but due diligence etc.
>>> - allow all ICMPv6
Folks that haven't pushed out v6 nets yet often miss this one. Friends=20
don't let friends break PMTUD. If people get all uppity about allowing in=
=20
ICMPv6 from the WAN side because they're used to discarding WAN-side ping=
=20
in v4 and you can't put your foot down heavy enough, at *least* get them to=
=20
give you ICMPv6 types 1-4 and 128,129 inbound.
Whether or not temporary addresses are a concern for your LAN event are a=
=20
factor of how long-lived sessions need to be for your application(s) and=20
how your clients are config'd. You can't guarantee the clients' configs=20
for TEMP_VALID_LIFETIME, though if they haven't futzed with it that should=
=20
be a week.
Cheers, and here's wishing you a great event!
--=20
Hugo Slabbert | email, xmpp/jabber: hugo@slabnet.com
pgp key: B178313E | also on Signal
--zbGR4y+acU1DwHSi
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBCgAGBQJW28QaAAoJEJqxD/2xeDE+pEoP/RcQev2TGbpg+dFCGnlMRA8M
mNMZQydmMhOPdsuM0MmLYBIEfZsHXTAknLZr+F8OlyRLVDspDNVEFpyVsKaWugWQ
+k0YgMIPLYPkRXRinBKZKRY8mr9HFp0y+MjLXIsdvXYpIIt7Kzr9FvCMOQPueNhA
OlNnV7t1Y07VAG3+PbBQ3AI5k9qHz7AJ1uP+uWrRNjkXXWXvCPBcgWG/w6V9EBH8
4IzF9zSKFU1NFB7q4YCIofRaycVBjCD9kach8OYe+f+mZHY2YbTCQegYgjsErDH9
3o+izGenv6wiOTbE/CDQdPOn8J7cxEyI9Bf4aK8kgxBHiLMsvK3lHppIeI9r3D6h
owHYc6jfBEyn3Anv6yBYcdtFX/njl2wTaeN87j8fisZ1N+5qIiQSYZyhrMMAT5kf
tl0KXOe7lTkmkgYd5SmgGexYEwDddVSju5WXtz9aniBIOTpUAY6VcsYapgoMKazC
6QH+lKsyOqIv4TOxEnnLCiJmh8RYRQ5Mqv3tFI7yxSGVV+Y6T72jPRjrGnSDvxqv
6ovA58SXL3txV4GjtQuTgbRpMW7mgL/zx0Akclj/HpzYAFW+eI5KHm6I937LLQae
OBPFlPg12GFHpJ9vlVD9hyVlwA3fX+iz8SF0SYFSv6IpAgjkFvN9jytI0d8o2xSs
CC+og1r8CKQvFLuNU5Rx
=4GK9
-----END PGP SIGNATURE-----
--zbGR4y+acU1DwHSi--
