Re: IPV6 planning

[Hugo Slabbert <hugo () slabnet com>]

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

Attachment: signature.asc
Description: