Historically, the members of the NET group argued that the decision of having IPv6 on the Long Haul Network (LHN) is a DM decision.
This RFC is to collect opinions about it.
Facts about the LHN
- The LHN is a private network from La Serena to SLAC
- Links are either L1 or L2 using VPLS on some paths.
- There is BGP on top of the links mostly to simplify configurations and to do failover.
- There's no IPv6 enabled inside Rubin Network.
If we can guarantee that we won't have a path inside the LHN in ipv6, I would say that we should stay in ipv4. However, since we can't guarantee that all the links won't have ipv6 requirements, especially the ESNet link between Atlanta and SLAC, we should implement ipv6 now (dual-stack), before the hard requirement comes in the middle of operations.
I also note that LSE-449 ended up with a vague statement that "IPv6 [is] planned for the mid-term."
I don't see any direct benefits of using ipv6 in a private network (LHN), however, we may be forced to be compliant. The scope of this RFC is for LHN only, but there could be consequences in the internal network. Dual stack inside the network should be assessed.
I'll move the planned end in case there are more comments.
It sounds like this is an operations problem and we can withdraw this RFC?
Or do we want to add an acceptance test for the network system to demonstrate we can transfer files to an IPv6 endpoint?
The agreed way forward is that we won't use ipv6 internally or in the LHN. We can return to this topic after the endpoints are ipv6 enabled.
Given that there are no further comments I will withdraw this RFC.
I don't believe there are any restrictions in the DM-developed middleware or application code; everything is using domain names or URLs that can contain IPv4 or IPv6 addresses.
The costs of using IPv6 with underlying tools such as Kubernetes, IPAM, etc. are definitely a factor that needs to be considered.
This goes beyond the RFC scope, but perhaps it might be more acceptable to have these requirements than a fully general "IPv6 everywhere":
The intent would be to allow for internal IPv4-only with translation at the boundaries.