4 ms·

Two big reasons that Microsoft says have caused them to start pushing v6 adoption internally from around 2017 are: a) struggling to implement proper IP based a

by ATsch 7y ago

Two big reasons that Microsoft says have caused them to start pushing v6 adoption internally from around 2017 are: a) struggling to implement proper IP based access control with their available address space. b) as everyone uses the same 16 or so bits of Private IPv4 space, every acquisition likely causes new IPv4 address space collisions which must be worked around.

mlyle 7y ago
> b) as everyone uses the same 16 or so bits of Private IPv4 space, every acquisition likely causes new IPv4 address space collisions which must be worked around. I mostly agree, but this overstates thing some. 10/8 offers 24 bits, 192.168 offers 16 bits, and 172.16-172.31 offers 20 bits. The latter are particularly frequently unused; if you pick one of 172.20-172.28 to cram into you have a high chance of not crashing into someone else when you integrate networks. Particularly if you use the upper half of the resultant class b. Of course RFC 4193 for IPv6 is very nice; pick your own random 40 bit prefix, and get to run 65536 subnets of arbitrary size. You need to integrate ~2^20-- a million-- networks before you have a 50% chance of having encountered a collision.
- ATsch 7y ago
  > 172.16-172.31 are particularly frequently unused haha, I wish. We decided to use them two decades ago exactly because we thought they were less frequently used, but then a decade later docker comes along and uses exactly that as a default NAT subnet. So we get multiple tickets about that a week.
  - saurik 7y ago
    What kind of issues is this causing you / your users?
    - ATsch 7y ago
      Well, the complaint usually goes like this: "we recently set up service x, and it seems to be working fine. However, when we try to connect from the campus wifi, or a certain department, the service does not respond". What happens is the server gets a request from a private IP within the range assigned to docker0, and then the container replies, but because the IP is believed to be local, linux correctly tries to find something attached to the docker0 interface with that IP and fails.

by ATsch 7y ago

mlyle 7y ago

> b) as everyone uses the same 16 or so bits of Private IPv4 space, every acquisition likely causes new IPv4 address space collisions which must be worked around. I mostly agree, but this overstates thing some. 10/8 offers 24 bits, 192.168 offers 16 bits, and 172.16-172.31 offers 20 bits. The latter are particularly frequently unused; if you pick one of 172.20-172.28 to cram into you have a high chance of not crashing into someone else when you integrate networks. Particularly if you use the upper half of the resultant class b. Of course RFC 4193 for IPv6 is very nice; pick your own random 40 bit prefix, and get to run 65536 subnets of arbitrary size. You need to integrate ~2^20-- a million-- networks before you have a 50% chance of having encountered a collision.

ATsch 7y ago
> 172.16-172.31 are particularly frequently unused haha, I wish. We decided to use them two decades ago exactly because we thought they were less frequently used, but then a decade later docker comes along and uses exactly that as a default NAT subnet. So we get multiple tickets about that a week.
- saurik 7y ago
  What kind of issues is this causing you / your users?
  - ATsch 7y ago
    Well, the complaint usually goes like this: "we recently set up service x, and it seems to be working fine. However, when we try to connect from the campus wifi, or a certain department, the service does not respond". What happens is the server gets a request from a private IP within the range assigned to docker0, and then the container replies, but because the IP is believed to be local, linux correctly tries to find something attached to the docker0 interface with that IP and fails.