EGI-InSPIRE RI EGI-InSPIRE EGI-InSPIRE RI EGI IPv6 Report for HEPiX March 16, 2012 HEPiX IPv6 WG Meeting n.14 CERN 1 Mario Reale GARR

EGI-InSPIRE RI Outline 1.EGI goals w.r.t. IPv6 2.Current stand 1.TESTBED 2.GENERAL ISSUES / GGUS TICKETS 3.Plans for next weeks/months 2

EGI-InSPIRE RI EGI goals for IPv6

EGI-InSPIRE RI Goals for EGI w.r.t. IPv6 Get ready for IPv6 Which currently means: Get ready for a Dual Stack world –To ensure switching on the IPv6 stack in Dual Stack nodes won’t break IPv4 provided functionality –To be able to include IPv6-only Grid resources in an IPv6-only Grid without breaking functionality or introducing bottlenecks/single points of failure Still, IPv6-only resources and IPv4-only resources will be partitioned in two separate stack- based pillars : we could however use the same Grid middleware to instantiate services/resources in both pillars –Using A & AAAA records in DNS servers available for both protocols Everywhere hostnames instead of IP addresses The proper programming guidelines and implementation principles for implementing the middleware Only IPv6 compliant external components This is perfectly possible ! Get ready to be able to manage Security using IPv6 –Avoid every risk related to having introduced a new protocol and IPv6-enabled middleware in Grid sites

EGI-InSPIRE RI Goals for EGI w.r.t. IPv6 Get ready for IPv6 Which currently means: Get ready for a Dual Stack world –To ensure switching on the IPv6 stack in Dual Stack nodes won’t break IPv4 provided functionality –To be able to include IPv6-only Grid resources in an IPv6-only Grid without breaking functionality or introducing bottlenecks/single points of failure Still, IPv6-only resources and IPv4-only resources will be partitioned in two separate stack- based pillars : we could however use the same Grid middleware to instantiate services/resources in both pillars –Using A & AAAA records in DNS servers available for both protocols Everywhere hostnames instead of IP addresses The proper programming guidelines and implementation principles for implementing the middleware Only IPv6 compliant external components This is perfectly possible ! Get ready to be able to manage Security using IPv6 –Avoid every risk related to having introduced a new protocol and IPv6-enabled middleware in Grid sites

EGI-InSPIRE RI IPv6-only resources Including IPv6-only resources in the EGI Grid (mostly IPv4) would imply protocol translation Realistically achievable for today is to be able to have a network-agnostic middleware, external dependencies and operational tools enabling us to implement an IPv4-infrastructure and an IPv6-infrastructure  Being able to provide 2 separate Grid pillars / resource-sets “The Final Goal” would be to have everything in place to be able to include IPv6-resources/services and IPv4-resources/services in a unique pool of EGI resources – irrespective of their protocol stack –At this stage / given current manpower/forces this cannot be endorsed by EGI Network Support

EGI-InSPIRE RI Goals translated in practice An applicable approach today – when both IPv4 and IPv6 are available - is having a grid middleware (including all required external dependencies) enabling IPvX Grid nodes to connect to IPvY Grid nodes and vice versa ( where both X = 4 or 6 and Y = 4 or 6 ) in a Dual Stack approach : i.e.: being able to communicate using both protocols –I.e.: having a network protocol stack agnostic middleware available –All EGI Technology Providers have to provide us with IPv6 compliant middleware There are IPv4 / IPv6 translation mechanisms available and possible gateway approaches, but the majority of them –Introduce an overhead w.r.t. grid functionality to be provided –Often represent a single point of failure in a Grid distributed architecture –Do not scale easily We should not be far at all from such a middleware, however no one has certified what is being provided w.r.t. IPv6 compliance and spreads problems are likely to be there What can we do in the meanwhile ?

EGI-InSPIRE RI Goals translated in practice Assess the overall IPv6 status w.r.t. IPv6 compliance of –the grid middleware –The required operational services and tools –Report all sources of problems to EGI and Technology providers –I.e. measure how far are we from the only long-term, sustainable solution –For all EGI-related middleware families ( Globus IGE, ARC, gLite, UNICORE, dCache) UMD released components Check/ Verify that switching on IPv6 does not break IPv4 provided functionality –This is however less than half of our goals: we still need IPv4 addresses/nodes Once IPv6 compliant components are there, test them and verify –They can be deployed ( installed and configured OK ) –They work using IPv4-only, IPv6-only and Dual Stack Evangelize about IPv6 increasing shared know-how on –IPv6 in general –IPv6 security and LAN protection

EGI-InSPIRE RI Some of our “fears” Google or Amazon or EGI will switch on IPv6 (i.e. enable it in their servers and publish AAAA records for them in DNS) and immediately thousands of users will come to us (network and grid administrators) complaining that – They do not manage to reach Google/Amazon any more –They do not manage to submit jobs or transfer data to their favorite Storage Element –They do not access their Grid portal any more –They cannot monitor their sites/jobs/file transfers any more Doing the first less-than-half of our job should be able to let this fear fade away The bad guys will show up: –Rogue devices / routes advertised and used through malicious or wrong RA messages –ping-pong DoS attacks –men-in-the-middle –Erroneous TEREDO tunnels in Win VISTA will show up breaking every sure fact about our LAN /Grid Site

EGI-InSPIRE RI Some of our sure problems The EMI Middleware repository is not (yet) available in IPv6: – how do I install the middleware ? EGI UMD repository is now available though Certification Authorities related files are not reachable ( CA-files, CRLs..) –How do I set up the Grid nodes and the User/Sites/Grid Security Infrastructure ? (FZU’ s talk yesterday) Some external dependencies are not IPv6 compliant or compiled without the required options We do not have a 100 % clear picture of what should be the expected degree of IPv6 compliance of all UMD middleware families and components –Would help guiding us to verify things Sites are a bit reluctant to enable IPv6 if not really needed given lower level of security control / LAN protection expertise

EGI-InSPIRE RI Some of our “hopes” Using IPv6 everything works just as well as using IPv4 IPv4 addresses will completely run out: who cares ? We have infinite IPv6 addresses Using IPv6 rate of security accidents won’t increase

EGI-InSPIRE RI Goals of EGI IPv6 testbed 1.Allow general purpose testing of UMD components using the IPv6 protocol 2.Enable specific IPv6 test campaigns on selected UMD components or required external dependencies 3.Provide an hands-on IPv6 testbed for possible IPv6 tutorials for the EGI site administrators community, both on IPv6 in general and IPv6 Security 4.Enable IPv6 testing of specific applications relevant to the EGI UCB / User Community 5.Allow the IPv6 testing of EGI-Inspire JRA1 Operational Tools components 6.Provide support and exploit synergies for the EGI Federated Clouds task force w.r.t. IPv6 ( to be defined, just started) 7.Complement the work done by the HEPiX IPv6 WG, focusing on the middleware

EGI-InSPIRE RI Current Status of testbed and recent achievements

EGI-InSPIRE RI Recent steps ahead EGI UMD repository has now been IPv6-enabled (GGUS Ticket 78290) ( repository.egi.eu ) New net.egi.eu VO created New VOMS for EGI Network Support community available at : it will be thehttps://vomsmania.cnaf.infn.it:8443/voms/net.egi.eu/ reference one for IPv6 testing Started listing available resources on Initial strategy for testing defined First workload sharing and action items identified

EGI-InSPIRE RI Current Testbed Resources gLite 3.2 UI, gridFTP server, gLite CREAM CE (in progress) at GARR (NGI_IT) ARC CE at ARNES (NGI_SI) Still to be identified: –UNICORE –Globus IGE –d-Cache ARC being tested by ARNES gLite being tested by GARR

EGI-InSPIRE RI Current Strategy We decided to start focusing on Site Computing and InfoSys resources First full cycles of installation / configuration / smoke testing will be reported by single test reports Detailed test reporting template under definition What will follow: –Grid Collective services for operations and monitoring: SAM-NAGIOS, GOCDB, GSTAT, GridMap, xGUS/GGUS, Accounting Portal… (Activities to be carried out jointly with EGI-inspire JRA1 ) –Synergies and joint actions with EGI Fed Clouds TF still to be defines

EGI-InSPIRE RI Testing Site Computing resources Complete test of installation, configuration deployment procedures Smoke testing of grid services –Are all required daemons/services properly starting ? Functional test of Workload job management chain –Job Submission / Monitoring / Cancel / Execution / Output retrieval Correct publication of Site resources in the Site BDII /InfoSys Correct publication of s/w tags, RTE variables, static and dynamic information in both Site and Top BDII Test of LRMS system local to the farm (Torque/Maui, SGE, LSF..) Test of proper execution of MPI jobs and MPISTART package Test of WMS server (“Broker”): deployment, smoke and basic functional behavior Test of MyProxy and full proxy behavior /cycle

EGI-InSPIRE RI IPv6-related GGUS tickets 80103ops urgent VO Services involved involved solved COD Operations VO net.egi.eu has been registered and is waiting none less urgentGOC DBverified Operations Use of the GOCDB for the IPV6 compliance task 78290none urgent EGI Software Provisioning Support verified Other trying to set up a ipv6 enabled UMD repository 76907none less urgentEMIin progress Installation EMI repository is not accessible on IPv6 18

EGI-InSPIRE RI Plans for next weeks

EGI-InSPIRE RI Next steps Complete set of both gLite and ARC CE and corresponding Worker Nodes Torque/MAUI likely to be first LRMS System in the row Test in both Dual Stack and IPv6-only environment and provide detailed reports : deployment / smoke / basic functionality Identify responsible NGIs/Teams for UNICORE, IGE Globus and d-Cache Agree on exact strategy / synergies with EGI Fed Cloud TF and EGI- Inspire JRA1 Update strategy for collaboration with HEPiX IPv6 WG in some weeks/months from now Update global picture and strategy with EMI and Tech Providers

EGI-InSPIRE RI References EGI Network Support coordination: EGI IPv6 IPv4 address report Contact: