K, need the #ipv6 gang.

I'm hanging on the edge of being That Guy here.

The k8s network model always seemed to me to map really nicely onto a simple /64 per worker. Containers in a pod share a network namespace, not allocating discrete IP addresses to individual containers.

But, reading the proposed draft for DC v6 deployment, and specifically the section at https://www.ietf.org/archive/id/draft-martin-deploying-ipv6-data-center-02.html#name-prefix-allocation-for-hosts re container hosts, and taking some pause here:

A common data center pattern assigns a /56 to each physical host (or rack entity), providing 256 /64 subnets --- one /64 for the host itself and up to 255 /64 prefixes for containers, virtual machines, or Kubernetes pods.

Does it? Like, is that actually "common"? I don't want to just port IPv4 thinking over here, but I honestly struggle to think of scenarios where I would specifically want a /64 per pod.

Assigning only a /64 per host (or per rack entity without further delegation) is often insufficient when multiple containers each need their own address space.

Eh? That...seems to run counter to the common k8s network model? How often are folks finding this "insufficient"? Are we running a bunch of weird VNF workloads I'm not yet encountering?

In a closed data center with explicit routing and no SLAAC on container segments, some designs assign one /64 per physical host and carve /72 (or longer) subnets from that host prefix for container tiers. That pattern is not suitable on the public Internet or where hosts expect standard /64 semantics; use it only with operator-wide agreement and tested CNI or orchestrator support.

Maybe I'm missing something, but any CNI patterns I've come across so far seem to basically expect an address per pod, not a prefix per pod with multiple discrete container addresses within that. Who's running SLAAC between the worker and containers? Are we the exception here with "explicit routing"?

Honestly I was originally perhaps a bit conservative with just an address for the worker itself in a rack-local uplink /64, and then a /64 per worker for pods. Perhaps a /64 or two for the worker itself and then a /64 for its pods is more suitable. But a /56 per worker to support a /64 per pod seems...a bit much?

A /52 podCIDR supernet gives us 4,096x /64s, so 4k workers at a /64 per worker. That's still a good chunk to work with if we have big clusters. Shifting to a /56 per worker would put us at a /44 podCIDR supernet for a 4k node cluster limit.

I know we should work from our base address needs and then work out way up rather than trying to "fit" within a predefined sizing. But this seems like a good chunk of hierarchy bits that don't actually fit with my understanding of the intended (k8s) network model.

Are folks really out here dropping a /64 per k8s pod?

I'm helping a nonprofit get started with their greenfield multi site #k8s cluster, using a /48 #IPv6 GUA subnet for each site. But sadly, the upstream ISP for each site will only delegate a /56 subnet at best. Some as small as a /60.

They're not yet large enough to set up an AS and peer using BGP, so I was hoping to use #NPTv6 between their GUA prefix and the ISP's prefix. But I think the only sensible way forward is, ugh, #NAT66 from the /48 to the ISP's /56 or /60.

Anyone have better ideas?

Finally, Hutch has deployed IPv6! 🎉 All 3 mobile ISPs now support IPv6, meaning all major ISPs in Sri Lanka now offer native IPv6 support.

https://stats.labs.apnic.net/ipv6/LK

#IPv6 #Hutch #SriLanka

>>You can simply become the owner of an Internet address block.

Problem solved.

It's the networking equivalent of complaining about your hotel bill and being told:

"Have you considered buying the hotel?"<<

https://www.linkedin.com/pulse/ipv6-going-save-internet-any-day-now-manoj-joshi-w6lbc

#blog about #ipv6 , funny, but don't expect new things

I really need to learn #ipv6 better. At the house, I have a Verizon business line (not their residential service). I've got dedicated ipv4 addresses. I also have an ipv6 range that gets mapped by them.

The same line runs my ISP stuff and I'm trying to do a bit of segmentation. At first I thought I'd get a hurricane electric range, because it would be stable. I could count on it. Silly me, I went and got 3 HE ranges assigned to 3 different segments. That's dumb and the router doesn't like it.

I'm winding down the HE tunnels. That doesn't seem to be very effective. But I'm not sure (a) how to configure my #mikrotik to pick up whatever v6 range my ISP is sending, and (b) partition it into a couple predictable ranges. I think they delegate a /64. and then (c) assign those ranges to certain sets of systems. (They're already segregated on IPv4 /24s)

I also don't know how stable the Verizon assignment is. I'm nervous about possibly publishing AAAA records for stuff only to find that VZ delegates a new prefix one day and all that stops working.

I really want to learn, but there's so much randomness introduced by ISPs who don't document how stuff works.

so i enabled DHCP option 108 on our home/office wireless network, spend a couple of hours thinking about it, then turned it off again.

why:

- using NAT64 instead of native IPv4 makes the network more complicated and issues more difficult to diagnose

- removing IPv4 would offset that, but we can't remove IPv4 since not everything on the wireless network supports 464XLAT.

- it did save about 5-10 IPv4 addresses, which is not nothing, but we aren't particularly short of IPv4 addresses.

i think if the wireless was only phones/laptops i'd probably leave it enabled, but as long as people keep putting their shitty IoT devices / TVs / etc. on the network, it's definitely going to break something.

#ipv6