IPV6 Assessment

From EGIWiki
Revision as of 18:32, 11 February 2019 by Msalle (talk | contribs) (UMD: update lcmaps-plugins-scas-client note)
Jump to: navigation, search

Core/EGI services

Core/EGI service Contact point IPv6 readiness Comments
Accounting repositories and portal
Adrian Coveney PARTIAL Portal is OK, APEL-SSM has been updated to support IPv6 but this functionality is untested
Activities and services for the long tail of science
Stéphane Gérard
YES hosted by CYFRONET, check CYFRONET
Application DB Kostas Koumantaros YES
Collaboration tools Martin Kuba YES full support
E-GRANT services hosting and technical operations Tomasz Szepieniec CANCELLED
to be integrated in Marketplace
Helpdesk (GGUS) Guenter Grein YES For production instances IPv6 configuration since GGUS release on July, 26th 2017.
Helpdesk human support Zdeněk Šustr YES human support, no need to assess readiness
Message brokers Christos Kanellopoulos YES
Monitoring services Christos Kanellopoulos YES
Operations Portal Cyril L’Orphelin PARTIAL planning to virtualize and replace a part of the web cluster (the only non-IPv6 compliant part) next year (2nd semester)
Security coordination and security tools David Kelsey UNKNOWN
Service registry (GOCDB) George Ryall PARTIAL Current configuration and software has been tested. Plans in place to make GOCDB IPv6 accessible by April 2018.
Services for AAI Christos Kanellopoulos PARTIAL

The EGI Catch All CA CRL is served only via IPv4 at the moment, but this will be fixed soon

The EGI Catch All VOMS services, do NOT support IPv6 and there is no plan to support it

UMD quality assurance Jorge Gomes NO IFCA/LIP no plans, CESGA partial
UMD software provisioning infrastructure Kostas Koumantaros YES
CheckIn Christos Kanellopoulos YES
CSGF Roberto Barbera YES
CVMFS Stratum-0 Catalin Condurache PARTIAL IPv6 ready, STFC not ready
DIRAC4EGI Andrei Tsaregorodtsev YES The DIRAC software is dual stack already
and supports IPv4/v6 client server communications. However, the hosting infrastructure at
CYFRONET where the DIRAC4EGI servers are running is still IPv4 and not IPv6 ready according
to the local administrators. I do not have time estimations from them about the IPv6 enabling.
EC3 Miguel Caballer YES
Perun Michal Prochazka YES
User registration portal Roksana Dobrzańska CANCELLED to be integrated in Marketplace
WS-PGRADE Zoltán Farkas YES No tests so far, but should be ready.

UMD

The following tables collects the products tested so far during the UMD software provisioning process. Moved from https://wiki.egi.eu/wiki/Middleware_products_verified_for_the_support_of_IPv6


Product name IPv6 support Comments GGUS ticket
CREAM YES

ARC YES

DPM YES

FTS YES

BDII YES

LFC YES

VOMS-SERVER PARTIAL VOMS admin is IPv6 ready, the voms daemon seems not yet IPv6 ready, to be checked

UI YES

StoRM YES


frontier-squid-3 YES

argus-pep-api-c, lcmaps-plugins-c-pep, argus-gsi-pep-callout, argus-pepcli, XACML YES argus-pep-api-c, lcmaps-plugins-c-pep, argus-gsi-pep-callout, argus-pepcli rely fully on libcurl, hence is fully dual-stack. XACML

does not create sockets or do name lookups.


lcmaps-plugins-scas-client YES Since version 0.5.7-1 lcmaps-plugins-scas-client is IPv6 compliant.
dCache
YES All currently supported versions of dCache support IPv6 in dual-stack and stand-alone mode.

Since dCache is a distributed system, it is possible to have a dCache cluster that comprises of a mixture of IPv4-only, dual-stack, and IPv6-only machines.  This, too, is supported, but obviously an IPv4-connected client cannot be redirected to an IPv6-only node. In such cases, dCache will make internal replicas or proxy the data.

CMD and FedCloud product readiness

Infrastructure status and plans

IPv6 infrastructure readiness
NGI
Status and plans Total sites
Sites implementing IPv6
Is NREN ready?
Willing tutorial on IPv6 in general Willing tutorial on IPv6 security Comments
AsiaPacific







CERN







NGI_AEGIS
WILL_DO 0
0
YES
YES
YES

Serbian NREN AMRES provides IPv4 and IPv6 connectivity services. Majority of network equipment was already configured to offer dual-stack IPv4/IPv6 connectivity, and there are no technical issues related to IPv6 implementing. Dedicated training events will speed up the implementation process.

NGI_ARMGRID







NGI_BG







NGI_BY







NGI_CH
WILL_DO 6
4
YES
YES YES
Partially done. Some sites need the Campus infrastructure to comply yet. Not all sites provide storage.
NGI_CZ







NGI_DE







NGI_FI







NGI_FRANCE
The sites supporting WLCG experiments will provide IPv6 (it is mostly done), for the other sites, it is not a requirement.
13
11
YES
YES
YES

NGI_GE






In Georgia there is only one Grid site and it is IPv4 only, the same is GRENA network. Currently we are not planing to introduce IPv6 because there is still no demand in it. In this situation mentioned tutorials will not be very useful for our system administrators.
NGI_GRNET







NGI_HR







NGI_HU







NGI_IBERGRID







NGI_IL

WILL_DO

3

2




D.Cohen: Two of three sites in NGI_IL are running all major services in dual stack for months now.

The third site will follow but unfortunately I cannot predict when.

NGI_IT







NGI_MARGI







NGI_MD







NGI_ME
WON'T_DO 1
0
NO



NGI_NDGF
WILL_DO (but see the comments)
5

5

YES

NO

NO
* Storage is on IPv6 already.
* Support systems (like squids, bdii, etc.) are on IPv6 already. The only exception is our voms server (voms.ndgf.org), since the software for some peculiar reason refuses to work properly on IPv6. We hope this will be fixed soon, so we can install a new version and switch on IPv6. --> TO BE INVESTIGATED BY UMD
* Computing however does not have IPv6 enabled, but following the official request by ATLAS at least half of the computing sites will already have it enabled by June. Unclear if another half will follow, since this request is not a strict requirement.
NGI_NL
WILL_DO 3
3
3
NO
NO

If you, and another NGI or site, are offering capabilities and services that are not yet v6 enabled and offer status web content, please consider fronting it with e.g. CloudFlare's free offering to gain such v6 capability at no cost to you and for the benefit of all

Security training is in general always good, but - just if case they did not get it - for IPv6 a pointer to the proper guidance RFCs on v6 security should be good. The HEPiX v6 WG also has relevant materials in this area that can be re-used.

NGI_PL







NGI_RO
WILL_DO

100% YES
YES
YES

Status: All the sites have available IPv6 class, but it is not implemented. We could do the implementation when it would be mandatory. For the moment we have sufficient IPv4 addresses available.

Plans: It is planned one implementation of an IPv6 storage.  There is one other site that plans to implement IPv6 next year, depending on what CERN experiments and EGI is recommending.

Hard to manage both stacks and new bugs introduced because of this.

Before the implementation, extensive tests for the services should be mandatory.

At an earlier IPv6 test, some time ago, we had compatibility issues regarding CREAM and Storage Element. If they are solved by now, we could try again.

Is IPv6 compatible with all software from ATLAS/ALICE/LHCb experiments?

NGI_SI
WILL_DO 4
4
YES


ARNES - dual stack

SIGNET - dual stack (one cluster has IPv6-only worker nodes and runs Atlas)

Atos - dual stack

Cipkebip - dual stack

Central services are not all IPv6-ready. Will reconfigure until the end of the year.

NGI_SK
WILL_DO 8
6
YES
YES
YES

Five sites have IPv6 connectivity, one site is working on enabling IPv6 connectivity, two sites have only IPv4 connectivity. From the services only one SE is on dual stack, other services do not have their IPv6 addresses in DNS yet.

NGI_TR
WILL_DO 3
3
YES
YES
YES

Storage services are running on both IPv4 and IPv6 already.

Support systems squid services and phedex server are running on both IPv4 and IPv6 already.

Other services bdii and argus are running on IPv4 only. They will be on both IPv4 and IPv6 until the end of July.

Computing services and worker nodes does not have IPv6 enabled yet.

NGI_UA
WILL_DO
15
3
YES


bout simplicity and convenience of IPv6 compared to IPv4.
  But for many people, grid site administration is only a small part of their general duties and commonly they are not related to computer networking or IT support - they are scientists, professors or managers at most. Only a few sites have dedicated qualified engineers to support operations.
  That means that site support is provided on best-effort basis and with least action. There even exist unofficial team of volunteers who silently support 1/3 of all the sites just to keep them running, because that sites simply do not have designated local technical administrator.
  So, IPv6 is far off site administrators' interests and until there are no strong reason to migrate (e.g. 10% of web-sites in the Internet will be IPv6-only), I there will be no progress on this.

  IPv6 was planned and/or deployed on the sites where it was a requirement (e.g. of WLCG experiment) and/or there is strong engineer team supporting the whole organization, not only its grid site.

  I think that we do not have much audience interested enough in IPv6 tutorials in NGI_UA, unfortunately.
  Nevertheless, personally I would like to continue promoting IPv6 in grid community.
NGI_UK
Various stages of implementation
19
19
Yes
Yes
Yes

ROC_Canada
WILL_DO
4
4
YES
YES
YES
Four sites: one site has storage testbed with IPv6 enabled and plan to put all production storage services on IPv6 (dual stack) before April 2018. Another 3 sites plan to implement dual stack in 1~2 years.
ROC_LA







Russia
WILL_DO
ALL
YES
YES
YES

IDGF







NGI_CHINA







WLCG plans

References