Hacker News new | past | comments | ask | show | jobs | submit login

> I really don't get the point of PD for IPv6. Or atleast, do PD but always assign the same prefix.

IPv6 allocation rules. They wanted to avoid the situation that happened with IPv4, so the address block are licensed for use and renewed on regular basis, so they can change. There's no such thing as fixed or static IPv6 address, it is dynamic, turtles all the way down. Hence DHCP-PD.

See also "Address space not to be considered property" (section 4.1) in the "IPv6 Address Allocation and Assignment Policy" (https://www.ripe.net/publications/docs/ripe-552#property)




> They wanted to avoid the situation that happened with IPv4,

This is directly contrary to what I've heard. Maybe my information is bad, or out of date, but I had thought that IPv6 addresses were meant to be static. I thought one of the selling points was that we couldn't run out of IPv6 addresses, as they were so numerous. If we're going to keep them dynamic, why even force this monstrous 128-bit number on us?


As far as I've understood, they wanted a little of everything.

IPv6 addresses should be more static short to medium term, because you don't have to reassign. Your local pool is basically infinite, so e.g. a client logging off the WiFi doesn't mean you immediately have to recycle the address. The local part (the latter 64 bits) is enough for everything and everyone.

Now, the first 64 bits should be used for routing, which should preferably be more hierarchical than with IPv4. The idea was that a customer/company/small ISP would get a prefix assigned that was below the hierarchy of the upstream ISP (with IPv4, that hierarchy isn't possible because there aren't enough address bits, and lots of lower-tier customers got their own subnets). So a large ISP might be assigned 2345::/16, assign 2345:6789::/32 to a smaller ISP who might assign 2345:6789:abcd::/48 to a customer (who then will do more subnetting with that). That keeps the global and local routing table small, since everyone just needs to look at the address prefix to know where to route to. If the customer now moves to another ISP, he is assigned a new prefix (e.g. 4711:f0f0:666::/48) by the new ISP and needs to renumber, meaning that all the customers addresses keep their suffix but change their prefix. Protocols like SLAAC where designed as stateless to support (among other things) quick and easy renumbering. Just announce the new prefix, wait a TTL and you are done. Clients automatically switch over to the new addresses, in an ideal world this is mostly transparent to the end user.

In the new millenium, especially after Snowden, the argument of privacy got stronger, meaning that randomised local /64 suffixes are now en vogue, as opposed to the earlier MAC-based static suffixes.

Therefore everything is more dynamic and also more static ;)




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: