Proposal for IPV6 datapath support #240
Conversation
yboaron
requested review from
Oats87,
skitt,
sridhargaddam,
tpantelis and
vthapar
as code owners
|
🤖 Created branch: z_pr240/yboaron/v6_support |
yboaron
force-pushed
the
v6_support
branch
2 times, most recently
from
3cb6a15 to
842e3c6
Compare
| * Note: gateway should address corner cases related to this change, for example in dual-stack environment only the V4 publicIP address is successfully resolved. | ||
| * run NAT Discovery per IP family in remote Endpoint. | ||
| * advertise in local Endpoint IP details based on cluster networking type, for example in duals-stack cluster both V4 Public IP and V6 Public IP should be advertised in Endpoint. | ||
| * continue advertising a **single** Endpoint. in case of a dual-stack cluster, fields should consist of both V4 and V6 addresses separated. |
There was a problem hiding this comment.
I think we should change the appropriate IP fields to arrays and bump the API version and implement a webhook converter so each version can be served for backwards compatibility.
There was a problem hiding this comment.
If we are changing any CRDs, we should also consider the impact during upgrades as there will be brownfield deployments.
There was a problem hiding this comment.
yes - a webhook converter would handle that, ie convert to and from both versions depending on client requests.
There was a problem hiding this comment.
In that case, I guess we need to be persistent and change also other resources , for example
GlobalnetCIDRRange and ClustersetIPCIDRRange in Broker resource. right ?
There was a problem hiding this comment.
@tpantelis Why not follow the core API example add a new field with xxxIPs which is an array? This makes it easy to handle upgrades and allows us to depricate old xxxIP field over time.
There was a problem hiding this comment.
We could do that but then we’d have to handle both fields in various places in code going forward. A webhook converter handles all that transparently. Webhooks and CRD versioning were designed for cases like this. K8s core API adds new fields and deprecates old ones b/c they’re not CRDs and much harder to bump versions. We can discuss further (next year 🙂)
| And Pod IPV6 egress packets for the same configuration will be: | ||
|  | ||
|
|
||
| **Note**: In future, we may optimize this architecture for a dual-stack case. |
There was a problem hiding this comment.
If the cluster is IPv4 only or dualStack, probably starting with a single V4 VxLAN for both might be a better option from the initial implementation. Otherwise you have to consider the impact on upgrades for subsequent changes in future. Just a suggestion.
| * Note: gateway should address corner cases related to this change, for example in dual-stack environment only the V4 publicIP address is successfully resolved. | ||
| * run NAT Discovery per IP family in remote Endpoint. | ||
| * advertise in local Endpoint IP details based on cluster networking type, for example in duals-stack cluster both V4 Public IP and V6 Public IP should be advertised in Endpoint. | ||
| * continue advertising a **single** Endpoint. in case of a dual-stack cluster, fields should consist of both V4 and V6 addresses separated. |
There was a problem hiding this comment.
If we are changing any CRDs, we should also consider the impact during upgrades as there will be brownfield deployments.
yboaron
force-pushed
the
v6_support
branch
3 times, most recently
from
57dea3c to
4552153
Compare
| * Note: gateway should address corner cases related to this change, for example in dual-stack environment only the V4 publicIP address is successfully resolved. | ||
| * run NAT Discovery per IP family in remote Endpoint. | ||
| * advertise in local Endpoint IP details based on cluster networking type, for example in duals-stack cluster both V4 Public IP and V6 Public IP should be advertised in Endpoint. | ||
| * continue advertising a **single** Endpoint. in case of a dual-stack cluster, fields should consist of both V4 and V6 addresses separated. |
There was a problem hiding this comment.
@tpantelis Why not follow the core API example add a new field with xxxIPs which is an array? This makes it easy to handle upgrades and allows us to depricate old xxxIP field over time.
submariner/IPV6-datapath.md
Outdated
| * Lighthouse ignores processing imported services IP addresses that don’t match local cluster networking configuration. | ||
| * Lighthouse will process imported services regardless of local cluster networking configuration, and rely on local workloads dns requests. |
There was a problem hiding this comment.
Looks like these are contradicting statements. Can you please rephrase.
There was a problem hiding this comment.
I've rephrased it, let me know if it looks OK to you.
| * Lighthouse ignores processing imported services IP addresses that don’t match local cluster networking configuration. | ||
| * Lighthouse will process imported services regardless of local cluster networking configuration, and rely on local workloads dns requests. | ||
| For example, in use case \#3 in the table above, Lighthouse DNS database will store both V4 and V6 addresses. | ||
| However the local dns client will look for the V6 (AAAA) record. |
There was a problem hiding this comment.
Normally, all the clients/apps make DNS requests for both v4/v6 and try connecting to them in parallel with a slight preference for v6. Please see Happy Eyeballs algo - https://datatracker.ietf.org/doc/html/rfc6555
There was a problem hiding this comment.
Is this the case also for single-stack clients?
I mean does V6 client/app try to connect to V4 address returned from DNS ?
There was a problem hiding this comment.
Yes, if the DNS server returns any v4 address, then the client will try to connect to it (which would fail if the server is not listening on it).
Signed-off-by: Yossi Boaron <[email protected]>
No description provided.