XMLWordPrintable

    Details

    • Type: RFC
    • Status: Withdrawn
    • Resolution: Done
    • Component/s: DM
    • Labels:
      None

      Description

      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.

      My opinion:

      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.

        Attachments

          Issue Links

            Activity

            Hide
            ktl Kian-Tat Lim added a comment -

            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.

            Show
            ktl Kian-Tat Lim added a comment - 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": Any Rubin host must be able to connect with another host that has only an IPv6 address. 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.
            Hide
            ktl Kian-Tat Lim added a comment -

            I also note that LSE-449 ended up with a vague statement that "IPv6 [is] planned for the mid-term."

            Show
            ktl Kian-Tat Lim added a comment - I also note that LSE-449 ended up with a vague statement that "IPv6 [is] planned for the mid-term."
            Hide
            csilva Cristián Silva added a comment -

            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.

            Show
            csilva Cristián Silva added a comment - 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.
            Hide
            tjenness Tim Jenness added a comment -

            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?

            Show
            tjenness Tim Jenness added a comment - 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?
            Hide
            csilva Cristián Silva added a comment -

            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.

            Show
            csilva Cristián Silva added a comment - 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.

              People

              Assignee:
              csilva Cristián Silva
              Reporter:
              csilva Cristián Silva
              Watchers:
              Andy Clements, Colin Slater, Cristián Silva, Frossie Economou, Heinrich Reinking, John Parejko, Joshua Hoblitt, Julio Constanzo, Kian-Tat Lim, Leanne Guy, Michael Reuter, Michelle Butler [X] (Inactive), Philip DeMar, Robert Lupton, Tim Jenness, Wil O'Mullane
              Votes:
              0 Vote for this issue
              Watchers:
              16 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Planned End:

                  Jenkins

                  No builds found.