Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Full IPv6 Support #202

Draft
wants to merge 7 commits into
base: master
Choose a base branch
from
Draft

Full IPv6 Support #202

wants to merge 7 commits into from

Conversation

majst01
Copy link
Contributor

@majst01 majst01 commented Jul 14, 2024

References metal-stack/releases#59.

Should be used as a base for discussion

consider https://www.ripe.net/publications/docs/ripe-690/

@metal-robot
Copy link
Contributor

metal-robot bot commented Jul 14, 2024

Thanks for contributing a pull request to the metal-stack docs!

A rendered preview of your changes will be available at: https://docs.metal-stack.io/previews/PR202/

Copy link
Contributor

@Gerrit91 Gerrit91 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for writing this up.

To me it seems like "One network per address family" is less complicated to implement and also clearer to use. With mixed networks we would need to iterate through the prefixes first to find out if the given network is "dual-typed". Then acquire IPs from both types, which is also not very clear from the user perspective because what if the user just wants IPv6 or just IPv4?

docs/src/development/proposals/MEP13/README.md Outdated Show resolved Hide resolved
docs/src/development/proposals/MEP13/README.md Outdated Show resolved Hide resolved
docs/src/development/proposals/MEP13/README.md Outdated Show resolved Hide resolved
@majst01
Copy link
Contributor Author

majst01 commented Jul 15, 2024

Thanks for writing this up.

To me it seems like "One network per address family" is less complicated to implement and also clearer to use. With mixed networks we would need to iterate through the prefixes first to find out if the given network is "dual-typed". Then acquire IPs from both types, which is also not very clear from the user perspective because what if the user just wants IPv6 or just IPv4?

I am actually bias towards the mixed mode, but keep the ip allocation as it is, e.g. only return a single IPv4 address by default even for mixed networks, but add a extra flag --addressfamily which can be used to get a IPv6 address additionally.

The difficulty with different networks per addressfamily is most probable when we want to create dual-stack kubernetes, and each and every machine needs to be attached to multiple networks which will then double the amount of VRFs on the switches to name one problem

@Gerrit91
Copy link
Contributor

Gerrit91 commented Jul 15, 2024

@mwindower
Copy link
Contributor

mwindower commented Jul 15, 2024

For the "Network per Adress Family" approach I see these points:

  • for private networks:
    • we would need to allow private networks to share VRF IDs because a network interface can only have one L2/L3 master dev
    • and would be a change to the really nice constraint that we have up until now: every private network has its own unique VRF ID
  • for public/company networks:
    • it's pretty uncommon that there exist different physical connections for IPv4 and IPv6
    • most of them are already dual-stack enabled and terminate at the exit switch in a single VRF
    • it would be hard or even impossible to split this to seperate VRFs

Because of these points I favor the mixed mode.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants