IPv6 @ INFN

Francesco Prelz

INFN, sezione di Milano

(on behalf of the INFN IPv6 interest group)

Summary

  1. The INFN IPv6 testbed.
  2. We are facing many transition unknowns.
    • Choice of address allocation scheme.
    • Monitoring tools and lack thereof.
    • Choice of transition technique.
    • IPsec, security at large, access authorisation.
    • Use of IPv6 anycast?
    • Mobile IPv6?
  3. Transition timing considerations.
  4. Conclusions

Testbed status
  • Sites participating in the INFN IPv6 testbed (with involvement of the local computing support personnel) are currently:
    1. Catania
    2. Milano (sites at both 1st and 2nd university).
    3. Rome (3rd university, joined for EUChinaGrid project).
    4. Bologna (CNAF, Tier-1 site, should be activating peering shortly).
  • The addressing plan agreed with GARR puts all of INFN under one prefix: 2001:760:4200::/40.
  • This testbed can become part of any HEPix testbed we may be planning for.

Level 3 features


Photo by Articulate Matter 		How much of the technology
  • that's pulling the IPv6 protocol from all sides
  • the we currently don't use over IPv4
would we like to deploy?
  • Transport layer autoconfiguration.
  • Mobile IP applications.
  • Site-, organisation-, NREN- or HEP-wide mobile IP applications.
  • IPSEC (most of transport layer security is now applied either below or above Level 3).
  • Anycast address applications ?

Access authorisation options

  • Maintenance of (long) ACLs allowing only network traffic to and from legitimately assigned IPv6 addresses.
  • IEEE 802.1x enforced everywhere ?
  • IPSEC enforced everywhere (but it may not be enough to protect IPv6 Neighbour Discovery, see rfc 3971) ?
  • Would a NREN-based identity provider be a good trust anchor for these systems ?
  • Would we trust automatic DNS updates if we had strong authentication, authorisation and encryption everywhere ?

Transition scenario: dual stack everywhere.


Transition scenario: IPv6-only hosts? (1)


Transition scenario: IPv6-only hosts? (2)


Monitoring tools for IPv6

  • It's hard to think about a real wide-scale deployment of IPv6 without up-to-date and trusted level-3 network monitoring tools.
  • Both commercial and free tools keep evolving slowly, following market demand (or lack thereof)...
  • But rogue router advertisements carrying arbitrary prefix and route information do hurt us today, with default Windows and Linux installations, and no IPSEC and SEND deployed. (One should at least be running a cleanup tool like ramond).
  • NDPmon, an ARPwatch substitute, started being developed in 2006. As of now (v1.4.0 - August 2009!) it is able to store address-MAC associations in an XML file and send reports via e-mail and syslog. Not much.
  • OpenVAS added initial IPv6 support in December 2009 with version 3.0.0.
  • Any experience with other (commercial) tools ?

Transition: when should we do it ? (1)

Preliminary considerations:
  • Transition is driven by useful services.
    • Likely not the IPv6 cool stuff or any 'killer' IPv6-only application.
    • It may be easier to complete the transition for specialised services (e.g. distributed computing) than for generic users.
  • Once services can be contacted over IPv6 (AAAA record is present in DNS), they are normally preferred (and we need to keep it that way), so they must be as reliable as their IPv4 counterparts
    • Long, accurate testing.
    • Short test runs of default IPv6 access (e.g. 'IPv6 days')
  • It will be a long process. Do drop-dead-deadlines help here ?
  • The 2013 LHC shutdown seems a very close date for general transition.

Transition: when should we do it ? (2)

  • One service that is known to work well on IPv6 is SMTP e-mail handling.
  • Having AAAA MX records for our sites should be painless.
  • But: how many people around us are actually doing this ?
  • Growth rate shown in the graph is 0.06 % per month.
  • Similar to the Google IPv6 statistics, that show a more marked increase in 2011 however.

Conclusions

  • The INFN IPv6 interest group is willing to partecipate in distributed testbed activities.
  • As we are facing various open options for address allocation, network access authorisation, active monitoring, etc., it would help if we could share best practices in this field.
  • There are no approved protocol translation mechanisms that remove the need to have a proper IPv4 public address allocated for hosts that need to communicate with IPv4 services. (NAT-PT was deprecated in rfc 4966, while both SIIT and IVI require an IPv4 address), so a full dual-stack deployment appears to be the only reasonable transition method available for us.
  • We'd welcome not just the IPv6 certification of HEP tools, but also a community effort to advance the dual-stack deployment of general purpose services (web, e-mail, etc.).

The IPv6 World Day last June 8th

  • The day went largely unnoticed. We had no report of any issue from within INFN.
  • Effect visible on the GARR/Global Crossing links:


  • Inbound IPv6 traffic (integrated over 24 hours) increased from 15 GBytes to 105 GBytes.
  • Outbound traffic increased from 3.6 to just 3.8 GBytes.