I know this invites some eye-rolling, but can somebody explain to me why the k8s people insist on ignoring IPv6 and the possibilities of large address fields?
Down the bottom, which is where 'things we probably will never do' is when IPv6 comes in the door.
Azure (for instance) is a fully IPv6 enabled fabric. Microsoft "get" IPv6. They are all over it. They understand it, its baked into the DNA. So how come K8s people just kind of think "yea.. nah.. not right now"?
Because proxy Ipv6 at the edge is really sucky. We should be using native IPv6, preserve e2e under whatever routing model we need for reliability, and gateway the V4 through proxies in the longer term.
"not ignoring it" .. "actively worked on" .. "for over 3 years" ..
Not to diminish the very real challenges in getting IPv6 implemented, but this is an interesting turn of phrase.. especially because rolling out IPv6 would actually solve a whole class of problems (and I'm not even a particularly big advocate of the need for IPv6, since most things should still be NATed anyway.)
(And especially considering parent's phrase "baked into the DNA" at Azure.)
Independently from this, IPv6 doesn't really work in AWS VPC. For example, ELB / ALB breaks under IPv6 endpoints. A lot of VPC services aren't available on IPv6. Metadata service has no IPv6 equivalent. I'm sure someone at AWS is thinking of these problems, but unfortunately, there are turtles all the way down.
Is the lack of e2e IP networking a chicken and egg problem? The built-in assumption of NAT islands w/ ambiguous addresses seems to be widespread in container and virtualization platforms, with little support for Internet style networking despite the obvious security and simplicity advantages.
I guess even today many people have problems getting more than a /64 in the office or home network (edit: it's supported usually with the prefix delegation option in DHCPv6 by most ISPs), so it's not frictionless in the dev environment.
yes. we jumped ship from self-deployed kubes on Linode, to Google Cloud once they provided an external V6 face in the LB. the v6 story in google is complicated. (we jumped to google because the integration of their tools and kubectl was too good to ignore. Most things just work. Alas ipv6 inside the pod ecosystem is not one of them yet)
Do you have any resources that expand on the IPv6 support in Azure?
Alas no. When I looked at k8s/Azure the IPv6 support was new.
My comment about IPv6 'baked into the DNA' of Microsoft is about Microsoft not Azure -A lot of the work on privacy addresses, the deployment of Teredo, adoption of ULA addresses, comes from people inside Microsoft, And they have been presenting recently at NANOG and IETF on IPv6 only deployments in the Redmond campus.
Comments
I know this invites some eye-rolling, but can somebody explain to me why the k8s people insist on ignoring IPv6 and the possibilities of large address fields?
Down the bottom, which is where 'things we probably will never do' is when IPv6 comes in the door.
Azure (for instance) is a fully IPv6 enabled fabric. Microsoft "get" IPv6. They are all over it. They understand it, its baked into the DNA. So how come K8s people just kind of think "yea.. nah.. not right now"?
Because proxy Ipv6 at the edge is really sucky. We should be using native IPv6, preserve e2e under whatever routing model we need for reliability, and gateway the V4 through proxies in the longer term.
(serious Q btw)
They're not ignoring it. It's being actively worked on, and is expected to be in alpha for the 1.9 release [1].
The issue [2] has existed for over 3 years, so it's not a new suggestion.
[1] https://github.com/kubernetes/features/issues/508
[2] https://github.com/kubernetes/kubernetes/issues/1443
Not to diminish the very real challenges in getting IPv6 implemented, but this is an interesting turn of phrase.. especially because rolling out IPv6 would actually solve a whole class of problems (and I'm not even a particularly big advocate of the need for IPv6, since most things should still be NATed anyway.)
(And especially considering parent's phrase "baked into the DNA" at Azure.)
(And especially considering parent's phrase "baked into the DNA" at Azure.)
S/Azure/Microsoft/ -Azure has IPv6 but I think its Immature.
https://azure.microsoft.com/en-au/updates/ipv6-for-azure-vms... Is about the underlying VM architecture, not support for Kubernetes network models.
Independently from this, IPv6 doesn't really work in AWS VPC. For example, ELB / ALB breaks under IPv6 endpoints. A lot of VPC services aren't available on IPv6. Metadata service has no IPv6 equivalent. I'm sure someone at AWS is thinking of these problems, but unfortunately, there are turtles all the way down.
Is the lack of e2e IP networking a chicken and egg problem? The built-in assumption of NAT islands w/ ambiguous addresses seems to be widespread in container and virtualization platforms, with little support for Internet style networking despite the obvious security and simplicity advantages.
I guess even today many people have problems getting more than a /64 in the office or home network (edit: it's supported usually with the prefix delegation option in DHCPv6 by most ISPs), so it's not frictionless in the dev environment.
Part of it is that Google took forever to migrate to IPv6 internally, well after the user facing support.
yes. we jumped ship from self-deployed kubes on Linode, to Google Cloud once they provided an external V6 face in the LB. the v6 story in google is complicated. (we jumped to google because the integration of their tools and kubectl was too good to ignore. Most things just work. Alas ipv6 inside the pod ecosystem is not one of them yet)
Do you have any resources that expand on the IPv6 support in Azure?
Everything I've seen in their networking configuration screens and APIs appears to only allow IPv4 addresses.
Do you have any resources that expand on the IPv6 support in Azure?
Alas no. When I looked at k8s/Azure the IPv6 support was new.
My comment about IPv6 'baked into the DNA' of Microsoft is about Microsoft not Azure -A lot of the work on privacy addresses, the deployment of Teredo, adoption of ULA addresses, comes from people inside Microsoft, And they have been presenting recently at NANOG and IETF on IPv6 only deployments in the Redmond campus.