Multiple IPv4 endpoint for a /48

[TiCPU]

Is it possible to add a new tunnel and route for a /48, I'd really like to assign a /52 to another location under my /48 subnet without wasting (and remembering) another /48, routing between the site would be hard as bandwidth is limited.

[jimb]

You can't have two separate tunnels from HE with a single /48, since the entire /48 is routed to your tunnel end point.  What you could do is assign /64s to the 2nd location, and route them there, perhaps over another 6in4 tunnel.

Alternatively, you could get a separate tunnel going w/ a separate /48, and HE would route between them (or you could establish your own direct tunnels between them).

[TiCPU]

You can't have two separate tunnels from HE with a single /48, since the entire /48 is routed to your tunnel end point.

Well, what I though would be that if they are hosted on the same endpoint, it could create a second tunnel and because /56 is a smaller subnet, that /56 would override the default /48 route for this range of addresses

What you could do is assign /64s to the 2nd location, and route them there, perhaps over another 6in4 tunnel.
Alternatively, you could get a separate tunnel going w/ a separate /48, and HE would route between them (or you could establish your own direct tunnels between them).

With those method, that means I can't share the same /48 for both networks :(  Even with that many IPv6 I still think it is a waste to allocate a /48 for each location.
Right now I did allocate a new /48 meanwhile.

[jimb]

You can't have two separate tunnels from HE with a single /48, since the entire /48 is routed to your tunnel end point.

Well, what I though would be that if they are hosted on the same endpoint, it could create a second tunnel and because /56 is a smaller subnet, that /56 would override the default /48 route for this range of addresses

They could do anything.  But they're not going to do special case routes for individual users.  As I said, if you're set on using the same /48 for both sites, you could simply establish your own tunnel from site A to site B and route whatever space you like across that tunnel.  Obviously, it'd use bandwidth of your inet connection, unless you had a separate link to site B.

What you could do is assign /64s to the 2nd location, and route them there, perhaps over another 6in4 tunnel.
Alternatively, you could get a separate tunnel going w/ a separate /48, and HE would route between them (or you could establish your own direct tunnels between them).

With those method, that means I can't share the same /48 for both networks :(  Even with that many IPv6 I still think it is a waste to allocate a /48 for each location.
Right now I did allocate a new /48 meanwhile.

Don't worry about wasting address space.  That's IPv4 thinking.  Having a /48 per site isn't a big deal.

[TiCPU]

Don't worry about wasting address space.  That's IPv4 thinking.  Having a /48 per site isn't a big deal.

I guess I'm still thinking about IPv4 too much! But doesn't that mean HE can only allocate 65536 /48 for 2001:470::/32 ?
It was also because I wanted some kind of structure between networks.

[jimb]

Don't worry about wasting address space.  That's IPv4 thinking.  Having a /48 per site isn't a big deal.

I guess I'm still thinking about IPv4 too much! But doesn't that mean HE can only allocate 65536 /48 for 2001:470::/32 ?
It was also because I wanted some kind of structure between networks.

Yes.  But let them worry about managing their /32.  In all likelyhood they/ARIN have a reservation for a /30, or more.

[bombcar]

According to http://whois.arin.net/rest/org/HURC/nets 2001:470 is the only IPv6 allocation HE has from ARIN.

I don't think they're worried about running out. ;)

[jimb]

According to http://whois.arin.net/rest/org/HURC/nets 2001:470 is the only IPv6 allocation HE has from ARIN.

I don't think they're worried about running out. ;)

Allocation != Reservation.  IIRC, a reservation is something that done by the RIR in anticipation of future allocations to an entity, sometimes by request of that entity.

In other words, it wouldn't surprise me if say, for example, 2001:471::/32 were skipped over for the next customer in line after HE got its /32 (in this case the /32 could eventually become a /31).  

In fact, if you do some whois-ing, you'll see that the next assigned allocation isn't until 2001:478::/32, perhaps indicating that the ARIN may have reserved 2001:470::/29 (2001:470-477:: ) for HE's future growth.