Add enhancement proposal for Prefix IPv6 allocation
#1006
Conversation
github-actions
bot
added
bug
afritzler
force-pushed
the
enh/public-prefix-proposal
branch
2 times, most recently
from
4ad3d41 to
d45d70c
Compare
guvenc
left a comment
guvenc
left a comment
There was a problem hiding this comment.
Thank you Andreas. I have some comments.
| IPv4 or IPv6 `Prefix`, allowing for the free selection of `NetworkInterface` IPs. In the IPv4 realm, it is common | ||
| practice to use a local, non-publicly routable IP range, with internet connectivity ensured via a `NATGateway` for | ||
| egress and a `LoadBalancer` for ingress traffic. However, this approach is not applicable to IPv6. | ||
| Here we need to ensure that either a unique local IPv6 address is being used (`fd00::/8`) or an IP or `Prefix` is derived |
There was a problem hiding this comment.
@MalteJ Do we want to support this non-routable range ? In the same VNI, the VMs can communicate with each other.
| name: my-lb | ||
| spec: | ||
| type: Internal | ||
| ipFamilies: |
There was a problem hiding this comment.
Loadbalancer can be also dual-stack on this API level ? I mean, the LB can be ipv4 only, ipv6 only and dual-stack.
On metalnet level each ip family will need its own metalnet object but this detail can be abstracted away on this level ?
| parentPrefix: | ||
| name: my-prefix | ||
| ``` | ||
|
|
There was a problem hiding this comment.
What about NAT64 ?
Do we need to present it on this API level ? @MalteJ
We already have NAT Gateway object with an ipv4 address, right ? so in case NICs get assigned to that
NAT Gateway, they will simply use the IPv4 NAT Address for their DNS64 resolved targets ?
No need to mark the NAT Gateway with some ipv6 related info on this API level ?
afritzler
force-pushed
the
enh/public-prefix-proposal
branch
from
d45d70c to
1e2673f
Compare
Proposed Changes
Prefixallocation