Difference between revisions of "IPV6 Assessment"
Line 250: | Line 250: | ||
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. | 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. | ||
Line 484: | Line 504: | ||
|- | |- | ||
| NGI_SI<br> | | NGI_SI<br> | ||
| WILL_DO | |||
| 4<br> | |||
| 4<br> | |||
| YES<br> | |||
| <br> | | <br> | ||
| <br> | | <br> | ||
| | | | ||
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<br> | | NGI_SK<br> |
Revision as of 15:28, 20 November 2017
Core/EGI services
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 | ||
DPM | YES | ||
FTS | YES | ||
BDII | YES | ||
LFC | YES | ||
VOMS-SERVER | YES | ||
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 | PARTIAL | lcmaps-plugins-scas-client does do a name lookup and socket creation and
is currently not IPv6 compliant, but can only connect over IPv4. This is fixed in our trunk and will be released together with a fix for OpenSSL 1.1, which is currently blocked by VOMS. |
|
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
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 | SHOULD BE |
YES | YES | since our sites serve WLCG only, we will do our best to adhere to their deployment timeline. It would be desirable that the EGI timeline would somehow overlap.
| ||
NGI_CZ |
|||||||
NGI_DE |
|||||||
NGI_FI |
|||||||
NGI_FRANCE |
|||||||
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 |
|||||||
NGI_IT |
|||||||
NGI_MARGI |
|||||||
NGI_MD |
|||||||
NGI_ME |
WON'T_DO | 1 |
0 |
NO |
|||
NGI_NDGF |
|||||||
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 |
3 |
YES |
YES |
YES |
IISAS-Bratislava - testing IPv6 connectivity IEPSAS-Kosice - firewall blocking IPv6, they are working on solution FMPhI-UNIBA - has IPv6 addresses, they plan to implement IPv6 before April 2018 |
NGI_TR |
WILL_DO | 3 |
3 |
YES |
YES |
YES |
|
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 |
|||||||
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
- old wiki https://wiki.egi.eu/wiki/IPv6
- IPv6 test http://ipv6-test.com/
- status of the WLCG Tier0 and Tier 1 sites http://hepix-ipv6.web.cern.ch/sites-connectivity