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":

1. Any Rubin host must be able to connect with another host that has only an IPv6 address.
2. Any Rubin host directly accessible from non-Rubin hosts must be capable of being assigned an IPv6 address (instead of or in addition to an IPv4 address).

The intent would be to allow for internal IPv4-only with translation at the boundaries.

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.