IPV6 planning

Harald F. Karlsen elfkin at gmail.com
Wed Mar 9 12:21:28 UTC 2016



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



More information about the NANOG mailing list