On 27-9-2013 18:13, Adam Thompson wrote: > I firmly agree with previous posts that outline why this allocation > policy is suboptimal. > However, I do *not* want to be renumbering my IPv6 hosts down the road > simply because I wanted to be the most efficient guy on the block. Nor > do I want to be the guy who can't run protocol XYZ because I didn't use > /64s.
Wait, what? Renumbering in IPv6 is different from IPv4 how? I had to renumber my IPv4 connections 6 times in the past decade, and I mean in the globally routed way, not the internal LAN. Now the size here is a fair bit of external servers, and those have public addresses, firewall rules and/or NAT mappings. Then there is the host config etc. I finally bit the bullet and signed up for PI space with a ASN and hopefully that's that. In retrospect, I should have done that ages ago. It would have saved the company tons of money in labor. You see, cheaping out with the smaller plans seemed like a good idea (cheap multiwan) but it turns out to be far more expensive in the long run with migration. Renumbering is cumbersome but it's really no different now then it was before. For all that it matters, I expect this not to happen so much with IPv6, because the default /48 allocation is so much larger. It's easy to do some aggregated routing without ending up with /29's everywhere. A IPv4 /24 was effectively 254 hosts, until you wanted to do routing and the effective number of hosts go downhill very fast from there. I had to renumber twice in IPv4 alone because I got a larger netblock. This because you needed to provide a reasonable requirement, and you can't get larger without a decent motivation and actually using those addresses. I think the default IPv6 size of /48 is well chosen. The moral is: If your company is Multiwan and has about 100 desktops, apply for a ASN and get BGP connections. It is the right business decision. Regards, Seth _______________________________________________ List mailing list [email protected] http://lists.pfsense.org/mailman/listinfo/list
