12.00 - Dr. Tim Chown - University of Southampton

IPv6 campus deployment experience Tim Chown University of Southampton Irish IPv6 Summit, Dublin 19th May 2010

Topics • Scope/scenario • Why IPv6 • Phased deployment steps • Managing a dual-stack network • Lessons learnt • The future

Scope • Context of our deployment is a large Electronics and Computer Science department – Approx 3,000 staff/student users – Up to 5,000 systems (>3,000 wireless) – Over 1,000 physical data ports – 4 buildings – Run all our own network and system services – See http://www.ecs.soton.ac.uk • ISP is JANET, the UK academic network – Connectivity via regional academic network (LeNSE)

Why IPv6? • Not due to immediate lack of address space – Established UK universities have pre-CIDR /16’s • Rather because universities are places of learning – Important to gain early insights into IPv6 impact – Teach IPv6 to students who will be using it – IPv6 capability for research projects – Prove new technologies in a production environment – Attract students from outside the UK • Network security aspects – manage the change – Deploy/manage IPv6 proactively

Deployment • In practice this has happened over many years – IPv6 was first run on our site in 1997 – Valuable experience gained through many projects such as 6NET (http://www.6net.org) • But while most academic backbone networks support IPv6, there are very few end- site/campus deployments • From our current position we can say – What we would do if starting from scratch now – What we think is working well – What remains to be done

Phased approach • IPv6 deployment should be undertaken with a phased approach, broadly: – Advance planning/preparation – Trial/pilot service – Production deployment – Ongoing operation • There’s no reason not to begin planning now – Gain early experience/insight – Minimise future costs by including requirements in future procurements

Dual stack vs IPv6-only • Dual-stack – Continue to operate existing IPv4 systems – Run ‘two networks’ as closely coupled as possible – Allow IPv6-only devices to operate internally – Additional complexity lies within the network • IPv6-only – Run only IPv6 internally – Complexity lies at the edge in the ‘NAT64’ function • Currently dual stack is the most viable option

Advance planning • Begin appropriate training for staff – Need to understand strategic and technical aspects • Determine IPv6 requirements and ensure these are cited in procurement exercises – Important, but not an easy task • Survey existing software/systems for IPv6 capability – Assess effort to port to support IPv6 where necessary • Review policies/processes for IPv6 implications – Security, management, etc.

Trial/pilot service • Speak to (existing) ISP about connectivity and address allocations (site /48) – Does your current ISP offer IPv6? • Form internal IPv6 addressing plan – Likely to be administratively congruent with IPv4 plan • Deploy a limited testbed system – Perhaps single router, on isolated dual-stack DMZ – Gain basic operational experience – Test software and application porting – Understand possible issues in fuller deployment • Discuss any arising IPv6-specific policy issues

Production deployment • Determine where to deploy – Specific subnets? WLAN? DMZ? • Enable IPv6 on the wire in routing infrastructure, host subnets and security components – Firewalls, IDS, … • Enable IPv6 in network services – DNS, monitoring tools, … • Enable appropriate application services – Might initially only be web-based services • Enable clients

Ongoing operation • Understand where you are • Indentify and track gaps in deployment – Ongoing review/action plans – Dialogue with vendors where necessary • Identify/evaluate new opportunities – IPv6-only network management – IPv6 multicast – Mobile IPv6? – IPv6-only applications – MS DirectAccess?

What we found ‘easy’ • Getting IPv6 connectivity and address space – Thanks to prior work done by JANET • General support in host/router platforms – Mac OSX lagging a bit behind • Enabling core services – DNS, MXes, web servers • Porting our software/tools to support IPv6 – Easier when the software is well-written • Host (address) autoconfiguration • IPv6 wireless access control via eduroam – Uses 802.1X authentication, independent of IP version

What’s been ‘harder’ • Managing a dual-stack environment • IP address accountability without DHCPv6 – Support for DHCPv6 improving – Admins are comfortable with current DHCP- based accountability model • Living with multi-addressed hosts – Including dynamic privacy addresses • Support in some MS applications – Again improved with recent releases • Some LAN security issues – e.g. rogue RAs have been problematic

Dual stack ‘cost’ • Main operational cost lies in managing a dual- stack infrastructure – Need to manage and monitor IPv4 and IPv6 • Consistency in applying configurations and policy – Monitoring (Nagios) – Firewalls – Integrated DHCPv4 and DHCPv6 • Troubleshooting • Do not want to use different tools/interfaces to manage each protocol – Some improvements to be made in commercial apps

Security aspects • Currently run two firewalls – Commercial IPv4 platform, open source IPv6 platform – Allows experimentation in IPv6 filtering • Avoiding use of transition tools internally – Simplifies internal network management/security – Support tunnel broker for external access • Running in-house tools to monitor IPv6-specific attacks – e.g. to detect DAD denial of service (cf. THC toolkit) – Only ‘badness’ seen to date is rogue RAs

Service examples • Some examples in next few slides of service graphs and management/monitoring tools • Shows open source solutions in operation – IPv6 transport external web traffic – IPv6 transport external emails – Switch/router configuration monitoring – Packet flow analysis • Again, it’s important to have these tools managed consistently via one interface

IPv6 web traffic • Very slow growth on external IPv6 web visits – Advertise web presence via IPv4 and IPv6 DNS records – Less than 1% of IPv6 accesses are via 6to4

IPv6 email • We also advertise our MXes with both IPv4 and IPv6 DNS records – As per RFC 3974 • Average 250,000 external IPv4 emails per day – 88% spam • Average 500 external IPv6 emails per day – Currently less than 25% spam • IPv6 transport email is 0.2% of total email – Again, a very small fraction

IPv6 email traffic

Switch/router monitoring • NAV – Open source – http://metanav.uninett.no • Dual-stack aware – Multi-addressed hosts

Integrated dual-stack monitoring • NAV determines most network properties automatically – e.g. dual-stack subnets on the same vlan

Network flows • Desirable to collect network flow records – Useful for many tasks • Netflow v9 includes IPv6 support – Configurable on our Cisco router(s) • Need to also run a collector/viewer – We use nfsen (http://nfsen.sourceforge.net) • Allows detailed flow queries, e.g. – Summary of external port 53 DNS flows – Views of individual external port 25 SMTP flows

IPv6 port 53 summary flows

IPv6 port 25 individual flows

New services? • What can you do beyond deploying IPv6 just to be ‘ready’? – IPv6 Multicast – simpler, more agile? – Mobile IPv6 – improved mobility support? – Applications – from engaged users? – Google IPv6 – is something big on the horizon? – Community/ad-hoc networks – interest here – New use cases – e.g. sensor networks • Seeing some interesting ‘green shoots’ but no single ‘killer app’

IPv6 multicast • Used for all our multicast services • Some nice benefits: – Improved, explicit scoping – Embedded RP (RFC 3956) for global groups • Some new projects building on IPv6 multicast – Student work, e.g. file-sharing applications • Freeview TV/radio (ECS-TV) – Using VideoLAN tools – Scoped within research buildings only

Issues experienced • Deploying per se is not the challenge – Managing a dual-stack environment is – You need good, consistent tools – There is increased complexity • Don’t underestimate staff training – IPv6 will touch on all areas of systems support – Staff who don’t understand will proliferate FUD • Do understand IPv6 differences – Multi-addressing, rogue RAs, … • Don’t expect full dual-stack deployment from day 1 – It’s perfectly fine to enable IPv6 in stages

The future? • Still some internal services left to make dual-stack • Integrate IPv4 and IPv6 firewall functions • DHCPv6 deployment – Unless we can improve autoconfiguration accountability, perhaps by wider use of 802.1X • Wider use of external services – IPv6 transport to root DNS – Google IPv6 Programme • Possibility of new IPv6-only devices – These would put some focus on ‘NAT64’ solutions • Plan for IPv6 deployment on wider campus network

Conclusions • If you’re not actively planning for IPv6, begin now – Checking capabilities in procurements as a minimum – Consider security implications – IPv6 is in your network anyway • Dual stack IPv6 deployment is possible today – Running here 4+ years without significant issues – There are some missing bits, but you don’t have to dual-stack everything from the outset • Look for tools that offer integrated management of IPv4/IPv6 networks – Even if that might mean changing the tools you use • Don’t forget training and awareness in your organisation • Don’t expect huge IPv6 traffic volumes (yet)

References • 6NET (2002-2005 Pan-European project) – http://www.6net.org • 6DEPLOY (IPv6 training and resources) – http://www.6deploy.org • JANET IPv6 Technical Guide (under revision) – http://www.webarchive.ja.net/services/publicatio ns/technical-guides/ipv6-tech-guide-for-web.pdf

12.00 - Dr. Tim Chown - University of Southampton

by IPv6 Summit 2010 on May 21, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 6

Statistics

12.00 - Dr. Tim Chown - University of Southampton — Presentation Transcript