Sonic.net

A PD length of /64 is broken. Here is why:

Assigning a /64 or longer prefix does not conform to IPv6 standards and will break functionality in customer LANs. With a single /64, the end customer CPE will have just one possible network on the LAN side and it will not be possible to subnet, assign VLANs, alternative SSIDs, or have several chained routers in the same customer network, etc.

Best Current Operational Practice for Operators: IPv6 prefix assignment for end-users - persistent vs non-persistent, and what size to choose

When mapping out the addresses, please allocate for /48, but hand out a /56 by default

dane wrote:We're rolling out with a /64 prefix at this time because we've found that much of the residential equipment, including equipment we've supplied to tens of thousands of customers, will not support a /56. We'll be working with the vendors to resolve that, and if and when that's solved, we'd have the ability to change the allocation to a /56 at that time.

This makes no sense to me as the prefix delegation is for the pool of address blocks to be divided-up by the router. A /64 only contain 2^(64-64) = 1 address block and itself breaks the purpose of it. So in effect, all that residential equipment you mention was already broken. By leaving it at /64 you are breaking my LAN and forcing my security cameras to be on the same subnet as my guest wifi

https://www.ripe.net/publications/docs/ ... r-than--56

This is oldish news. The newer builds are handing out a /56.

davygrvy wrote:

dane wrote:We're rolling out with a /64 prefix at this time because we've found that much of the residential equipment, including equipment we've supplied to tens of thousands of customers, will not support a /56. We'll be working with the vendors to resolve that, and if and when that's solved, we'd have the ability to change the allocation to a /56 at that time.

This makes no sense to me as the prefix delegation is for the pool of address blocks to be divided-up by the router. A /64 only contain 2^(64-64) = 1 address block and itself breaks the purpose of it. So in effect, all that residential equipment you mention was already broken. By leaving it at /64 you are breaking my LAN and forcing my security cameras to be on the same subnet as my guest wifi

https://www.ripe.net/publications/docs/ ... r-than--56

We've actually transitioned to handing out /56 prefixes in all of our newer roll-outs after feedback like this from our customers. The only customers still using a /64 are from our original roll out and we plan to migrate them over to /56 in the near future.

Kind regards,

artakamoose wrote:This is oldish news. The newer builds are handing out a /56.

It got turned on about April 17th to an unusable /64. This issue is current.

AT&T fiber is much worse with their BGW320. It requests a /60 from the upstream, and when used in pass-through mode for a customer supplied router, you have to request multiple PDs up to seven as each are sized to /64 to build-up how your front-end router will pass that around. For me, I used the macvlan driver on OpenWRT to accomplish this, but there was never any consistent relationship maintained between the PDs. AT&T has even gone so far as to enshrine that broken behavior in an informational RFC.

davygrvy wrote:

artakamoose wrote:This is oldish news. The newer builds are handing out a /56.

It got turned on about April 17th to an unusable /64. This issue is current.

AT&T fiber is much worse with their BGW320. It requests a /60 from the upstream, and when used in pass-through mode for a customer supplied router, you have to request multiple PDs up to seven as each are sized to /64 to build-up how your front-end router will pass that around. For me, I used the macvlan driver on OpenWRT to accomplish this, but there was never any consistent relationship maintained between the PDs. AT&T has even gone so far as to enshrine that broken behavior in an informational RFC.

I checked with our Network Engineers and they confirmed that you are on one of the last pieces of equipment we still have provisioned for /64. We are working to have this converted and provisioned for /56 in the next couple weeks, so keep your eye out for that.

We appreciate your patience with us!

Kind regards,

brandonc wrote: We appreciate your patience with us!

Thanks! This has been a source of intense frustration for me for many years as most ISPs don't care to do IPv6 the right way as documented by BCP157/RFC6177 dated 3/2011. AT&T fiber doesn't even bother to advertise their 6RD in a DHCP option. A /56 is the right way, thank you.

I would have stayed with Hurricane Electric's excellent tunnel service forever during these transition times that unfortunately has gone well over a decade, but then Netflix blocked me about 9 years ago. They couldn't determine my country of origin through a tunnel. I even went so far as using an EAP proxy to bypass AT&T's router to fake my router as theirs to get the full /60 (and to fix their UDP throttling), but they discovered my hacking and told me to put it back.

brandonc wrote:We are working to have this converted and provisioned for /56 in the next couple weeks, so keep your eye out for that.

If possible, please allocate the addressing maps for /48, but assign for /56. This looks to the future so that you could give your large business customers a /48 PD with 32K address blocks

Bits available for the subnet ID are very good. The larger the prefix, the smaller the subnets

dane wrote:No, it’s a single dynamically allocated /64 block at this time.

Just want to confirm, dynamically means same as currently IPv4 that the prefix will change every re-connect? In other words, for SSH-ing into our home devices we'd still need to rely on dyndns or tunnels?

nobaq wrote:

dane wrote:No, it’s a single dynamically allocated /64 block at this time.

Just want to confirm, dynamically means same as currently IPv4 that the prefix will change every re-connect? In other words, for SSH-ing into our home devices we'd still need to rely on dyndns or tunnels?

Both allocations are pretty sticky - they're only likely to change if your CPE is offline for some time or if there's some network maintenance that results in the allocations needing to change. So yes, you'd still most likely want dyndns or reverse tunnels up for reliable inbound access.