• Welcome to Hurricane Electric's IPv6 Tunnel Broker Forums.

News:

Welcome to Hurricane Electric's Tunnelbroker.net forums!

Main Menu

assign /48 ?

Started by ThomasSchallar, July 04, 2014, 11:23:34 PM

Previous topic - Next topic

ThomasSchallar

Hi!

I can assign a /48 prefix to my tunnel. That are sixty five tousand /64 prefixes! I don't believe that any user of the Tunnelbroker service uses that many networks.

I know, that it was the original deployment plan of IPv6 to assign /48s to the cutomers. But that only burns away the adress space in a completely unnecessary fashion. Please keep in mind, that 2128 is a huge addressing space - but it is still limited and not endless. Back in the 70s nobody thought, that the enormous 232 Bytes of address space will someday be "just" 4GiB RAM - or, for that matter, "just" 4 Billion IPv4 addresses.

All the providers I know assign a /56 to their customers. That are still 256 prefixes/networks and much, much more than even business users will need. I would consider that as more than enough, as long as you don't run an international company with really more than 256 distinct networks.

Some providers use the xxxx:xxxx:xxxx:xxFF::/64 prefix of the xxxx:xxxx:xxxx:xx00::/56 as linknet for the tunnel/uplink. That saves one more network/route and don't really hurt the customer.

So my suggestion would be to statically assign a /56 to every user of the Tunnelbroker service, instead of a (two!) /64s and if one neds a bit more, another huge /48. I don't know the ratio, how many users request a /48, but you could serve 256 "/56 users" for any single user, who requests a /48.

broquea

#1
Or you could drop the IPv4 conservation mentality, and embrace the vast space that is IPv6 :) By that, I'm referring to the fact we've only started allocating out of one /3, and there are several more to go.

HE having both a /32 and /24 of IPv6 won't be hurting to hand it out to customers. So why shortchange their users the way other these other providers do.

jpmahowald

It might be "wasteful" but it also is simple.

You mentioned /56 assignments being possible, except in some large deployments. Who decides what is large? Why bother with size categories at all if the address space is large enough where it doesn't matter?

The "click button get /48" interface was even easier than I anticipated. Also, it can be represented with just 3 digit groups, leaving the rest for me the user to play with.

snarked

I simply can't imagine any client who would need more than a /56 (256 subnets).  Those who usually need more would be asking the RiRs for a /48 or 32 of their own.

sejtam

I agree. I feel bad requesting a /48 when I really just want to subnet my home network.
I would think being able to request a smaller range (/56, heck even a /60)  would
be useful and not let people fall back into a wasteful mindset..

snarked

No one here has to ask for a /48.  One can get 5 /64s before one exhausts that level of resource.

evantkh

Quote from: snarked on April 17, 2015, 07:40:36 PM
No one here has to ask for a /48.  One can get 5 /64s before one exhausts that level of resource.

However, one problem of assigning long prefixes is the routing table can be very large.

gnarlymarley

Quote from: ThomasSchallar on July 04, 2014, 11:23:34 PM
Hi!

I can assign a /48 prefix to my tunnel. That are sixty five tousand /64 prefixes! I don't believe that any user of the Tunnelbroker service uses that many networks.
Sixxs does the /48 thing.

https://www.sixxs.net/faq/connectivity/?faq=onlyonesubnet

gnarlymarley

Quote from: evantkh on April 18, 2015, 07:14:41 AM
Quote from: snarked on April 17, 2015, 07:40:36 PM
No one here has to ask for a /48.  One can get 5 /64s before one exhausts that level of resource.

However, one problem of assigning long prefixes is the routing table can be very large.
Hurricane Electric has already take steps in their routing to prevent a large routing take by aggregation.  It does not matter how big or small the prefix is assigned because the aggregation of BGP routes to a single tunnel server has all possible routes hard coded in.  This is why when moving tunnel servers, you need to delete and create a new tunnel.