Difference between server/64, client/64, and routed/64 addresses?

[josejimeniz]

i'm trying to understand some of the concepts involved in Hurricane Electric's tunnel service.

i know that the tunnel i create goes from my Internet-connected device (which i'll call a router) to an HE server. In my case i connect to a server in Chicago:

• tserv9.chi1.ipv6.he.net (209.51.181.2)

The other end of the tunnel is me; my public IPv4 address (216.8.130.128) is my end of the tunnel.

That explains two items from the Tunnel Details page:

Code Select Expand

Server IPv4 Address: 209.51.181.2
Client IPv4 Address: 216.8.130.128


With this tunnel created, i now have a mechanism to transport IPv6 packets to "the internet". i can construct an IPv6 packet, send it into the tunnel, and i know they be received by Hurricane Electric's server, and routed off to its final destination on the Internet.

The next question is: What IPv6 address does Hurricane Electric give me? i can have many devices (e.g. computers, phones, handhelds, watches, microwaves) all wanting an IPv6 address. i would assume that HE gives me a /64 address block, e.g.:

2001:470:1f10:1178:xx:xx:xx:xx

Now i can start handing out IPv6 addresses to all my devices, as long as the first 64-bits start with 2001:470:1f10:1178. e.g.

• 2001:470:1f10:1178:0:0:0:1
• 2001:470:1f10:1178:0:0:0:2
• 2001:470:1f10:1178:0:0:0:3
• 2001:470:1f10:1178:0:0:0:4
• 2001:470:1f10:1178:0:0:0:5

Hurricane Electric knows that if it receives a packet from the wider Internet destined for any address starting with 2001:470:1f10:1178, then it should send it through my tunnel. Whereas HE's other customers have different leading 64-bits, e.g.:

• 2001:470:1f10:1178:x:x:x:x -> Send down Ian Boyd's tunnel (i.e. me)
• 2001:470:1f10:1179:x:x:x:x -> Send down Matt Albie's tunnel
• 2001:470:1f10:117a:x:x:x:x -> Send down Danny Tripp's tunnel
• 2001:470:1f10:117b:x:x:x:x -> Send down Jordan McDere's tunnel

So this would mean that i can assign all my devices any IPv6 address, as long as they begin with 2001:470:1f10:1178.

But that's not quite what happens. The Tunnel Details page lists two specific addresses (both one on one subnet), and it lists an entirely different subnet:

• 2001:470:1f10:1178:0:0:0:1 /64: Server IPv6 Address
• 2001:470:1f10:1178:0:0:0:2 /64: Client IPv6 Address
• 2001:470:1f11:1178:x:x:x:x /64: Routed /64

i thought the tunnel details page was just trying to be helpful when it listed a "Client IPv6 Address". i have an entire /64 subnet to myself, so of course i can start at :1. But i'm not starting at 1. The "server" is 1. It specifically says that i (the client) am :2.

What is this "server" address i am seeing? At first i thought it was the tunnel's Chicago endpoint's IPv6 address, but that's not it:

Code Select Expand

C:\Users\Ian> nslookup
> tserv9.chi1.ipv6.he.net

Non-authoritative answer:
Name:    tserv9.chi1.ipv6.he.net
Addresses:  2001:470:0:6f::1
          209.51.181.2


The "server" ipv6 address is 2001:470:0:6f::1; which is different from the address i'm looking at. Is it possible that the Chicago server has multiple address, one for each tunnel on it?


To sum up, there are two /64 subnets associated with my tunnel:

• 2001:470:1f10:1178 (server/client)
• 2001:470:1f11:1170 (routed /64)

Am i not allowed to have any address i want in the "server/client" range? Can only assign addresses in the "routed /64" range? It seems such a waste that the entire 2001:470:1f10:1178 block is allocated to me, but only :1 and :2 are allowed to be used.

So that doesn't make sense.

My question is, what is:

• the server ipv6 address?
• the client ipv6 address?
• the client/server /64 range used for?
• the routed /64 range used for?

Bonus chatter

i assume that the "routed /48" has the same abilities as the "router /64", except you guys don't want to be handing out /48 ranges willy-nilly. The vast majority of users have no need for a /48 address, so that's why you don't create one by default. And while it's simple to create one, i just have to click the "Assign /48" link, it just stops them from being created when they don't have to be.

postscript: whew it took a long time to compose that question; formatting and everything

[cholzhauer]

The server IPv6 address is what you said, the ::1 address listed as the Server IPv6 address...this is the default gateway where you send all of your traffic.

The Client IPv6 address is the ::2 address you assign to your router or endpoint device.  This is in the same /64 as your server address.

The rest of that subnet is unusable.

The routed /64 provided to you by default is what you use to assign to the rest of your devices...eg, computers, cell phones, printers, ect.  You use this if you only have one subnet/network

[josejimeniz]

- the server IPv6 address is :1 - this is the default gateway
- the client IPv6 address is :2 - you assign to your router or endpoint device

This is in the same /64 as your server address. The rest of that subnet is unusable.

The routed /64 is what you use to assign to the rest of your devices

What i'm trying to understand is why are there two /64 blocks at all?

i would think my site would only need the one /64 block (e.g. 2001:470:1f10:1178:x:x:x:x)

- The default gateway of my router applicance is out the IPv6 tunnel interface
- The default gateway of machines on my network is the my router appliance (e.g. fe80::250:bfff:fe91:955f)

In the olden days of IPv4, i am given:
- one publically routable IP address (e.g. 216.8.130.128)
- the address of a default gateway (e.g. 216.8.136.169)

and different customers all use the same default gateway IP (i.e. 216.8.136.169)

Why can it not be, in the IPv6 world, that i am not simply given a single publically routable IP address block (e.g. 2001:470:1f10:1178:x:x:x:x), and then the address of a default gateway (e.g. 2001:470:1f10:1178:x:x:x:x)

i can't think of a reason why i (as one customer) have a single default IPv6 gateway address (that nobody else can use). Nor can i understand why my router applicance needs to have a particular ipv6 address. Surely my endpoint device could pick an address of 2001:470:1f10:1178:0:0:0:254 rather than 2001:470:1f10:1178:0:0:0:2, and everything can still work.

And strictly speaking, shouldn't the client and server addresses be:

- 2001:470:1f10:1178::1/127
- 2001:470:1f10:1178::2/127





It's important to note that everything working. i copy this number here, copy that number there, and everything works. i don't know why it works. i don't know why this particular number goes here, and not that number. i don't know why this particular number even exists.

i'm trying to learn because i want to become a better human being. i want to learn so i can further the limits of human knowledge for all mankind.

i want to learn because if i can understand the why, then the how becomes intuitave and obvious.

[cholzhauer]

The short answer?  Just because.

That's how all tunnelbrokers do it...one /64 for your tunnel traffic and another /64 or /48 for your devices.  I assume it has something to do with routing; the HE staff would be able to fill in the details.  I know I couldn't do it with just one /64.  I have the server /64 between me and HE (applied to the outside interface of my router) and I use the client /64 on the inside interface of my firewall.  Without splitting the /64 into something smaller (bad idea) I wouldn't be able to route traffic.

[jgeorge]

Your questions are all perfectly valid, there's really no reason such a setup *wouldn't* work, really, other than the fact that it's just not done that way.

I know it seems wasteful to assign you an entire /64 just for 2 addresses in a point to point network, but that's just how it's set up here.

Your point to point network allows you to establish connectivity from one router in your network to HE. It's simpler on HE's end to expect all traffic from your tunnel to be coming from one specific known IP address (your side of the tunnel).  Basically making the tunnel endpoint part of your local routed network would put some responsibility for routing across your local network on HE's end, which is a) probably not what everyone operating a tunnel would want, and b) probably more management on HE's side than they'd be willing to give away for free.  Having this point to point subnet gives them one endpoint to manage, and gives you one endpoint to manage as the default route in your own network.

Having everyone else in  your network use the 2nd routed /64 allows you more control over how those addresses get routed around, gives you more control to manage what's actually *going* over that tunnel or not, and allows you to more or less treat that routed /64 completely autonomously from the transport that connects it.

Why is this cool? Because if you then grow to the point of needing a larger subnet, you can get a routed /48 from HE and all you have to do is change the prefix on your routed subnet within your own network - one prefix change in your router and your prefix would propagate over your local network to your autoconfigured hosts, and HE would literally have to change *nothing* on their end - it just works.


Looking at your example in your previous post, you're really comparing apples to oranges. For IPv4 you say you get one routeable IP address and the address of a gateway. Fair enough, you're one part of a larger subnet that is comprised of multiple customers on the network, all funneling through a gateway router that's not yours but your ISPs.

For IPv6 you don't get one address in your ISP's subnet. You get an entire subnet, and you need some place to point your entire subnet to get it to route out to the world.  Simply making HE's "default router" be in your routed subnet doesn't really buy anything on HE's side - since you get the whole subnet it's not like they'd be able to use that router IP address for any other cusomters - they'd have to aggregate your default router IP (and everyone else's) somehow anyway, but it would be more work and a more complex thing to manage than just putting you behind a point to point network as  it is.

As for the point to point network being a /64 and not a /127, you're right, as well, that it *could* easily be a /127, and the only reason for making it a /64 I can think of is basically to manage address blocks.... If your tunnel entpoint was 2001:470:1f10:1178::2/127, that means that the block 2001:470:1f10:1178::4/127 would also be a valid network (and free, since it's not allocated as part of your block) along with the millions of other /127 networks that would fit into the /64. Valid? Sure. Management nightmare? Oh yes. By assigning you the entire /64, if gives HE the ability to programmatically assign you address blocks (2001:470:n:xxxx:: for the tunnel and 2001:470:n+1:xxxx:: for the routed network) and not have to manage really teensy subnets that aren't really needed to be that teensy.

If IPv6 address space were tighter than it is (or ever will be) then those smaller subnets make sense, but it's kind of a generally accepted policy that /64 would be the smallest subnet prefix assigned to a user, to keep from having to do the really twiddly bit flipping math for tiny subnets that aren't really needed.

Cheers,

Joe

[snarked]

You have control over the DNS for the routed 64 (or 48).  You do not have control over the other two - which are addresses of a point-to-point link.

It is correct that the service could use a single /64 for both the tunnel and your local network.  However, except in the case of a single machine, there will be addresses from that range on two different interfaces and that's considered a problem by most, and without IPv6's equivalent to proxy-ARP, other machines could have a problem finding the tunnel gateway.  The local network would still be a /64 with the tunnel P-T-P being a /127 (or /126 to avoid the all zeros entry) slice of that.  Such requires a specific routing exception and I think HE wanted to avoid that.


PS:  If you're not seeing my flying-pigs avatar, then either your reverse DNS or your browser is not set properly.

[mtindle]

A long time ago the old tunnel broker did in fact hand out /127s for the point to point addresses.  However, a purist view would say that a /64 is the smallest block that should be allocated to any network segment, regardless of size.  Turns out there were some devices that expected this purist view and just won't assign anything smaller than a /64 on an interface and would completely freak out at a /127.  So as part of the broker overhaul a few years ago, we moved to handing out /64s for the point to point.  It's not for IP management, but for compatibility.

[josejimeniz]

It's simpler on HE's end to expect all traffic from your tunnel to be coming from one specific known IP address

You mean my IPv4 address, right? Traffic inside the tunnel doesn't come from my assigned client IPv6 address (x::2) - it comes from the IPv6 address of the device sending the packet.

Which then begs the question - what is the purpose of my endpoint devices IPv6 address (x:x:x:x:x:2) when it is quite possible that no traffic will ever come from that IPv6 address?

Strictly speaking i don't even need to know the "server's" IPv6 address (i.e. x::1) address - traffic is placed in the tunnel destined for some far off host on the Internet. No packet is ever sent directly to x::1.

For IPv6 you don't get one address in your ISP's subnet. You get an entire subnet, and you need some place to point your entire subnet to get it to route out to the world.

The address of a default gateway is simply a placeholder - it serves to instruct a router which interface it needs to place traffic on to that it can continue on its journey. In my case that default gateway is HE's default router. There is no other place it can go - it must go to HE.

Simply making HE's "default router" be in your routed subnet doesn't really buy anything on HE's side - since you get the whole subnet it's not like they'd be able to use that router IP address for any other customers - they'd have to aggregate your default router IP (and everyone else's) somehow anyway, but it would be more work and a more complex thing to manage than just putting you behind a point to point network as  it is.

i'm not behind a single IPv6 point as it is. IPv6 packets coming out of the tunnel at their end are not "from" my x::2 address; they are from the /64 address of the device that initially sent the packet.

As for the point to point network being a /64 and not a /127 you're right, as well, that it *could* easily be a /127
...
If IPv6 address space were tighter than it is (or ever will be) then those smaller subnets make sense, but it's kind of a generally accepted policy that /64 would be the smallest subnet prefix assigned to a user, to keep from having to do the really twiddly bit flipping math for tiny subnets that aren't really needed.

i was looking at it from the point of view that they have gone out of their way to allocate an entire 2nd subnet to me; and as far as i can tell there's no reason for it.

Which means either a) there really is no technical reason for it, or b) i am missing something in my understanding of IPv6 and routing.

[josejimeniz]

in the case of a single machine, there will be addresses from that range on two different interfaces and that's considered a problem by most.

Without IPv6's equivalent to proxy-ARP, other machines could have a problem finding the tunnel gateway.

Why is that a problem?

Assume my subnet is 1:2:3:4:x:x:x:x (which i'll just shorten to 1:2:3:4:: ). All devices on my subnet are 1:2:3:4::. They are all given router advertisements (RAs) saying that 1:2:3:4:0:1:7:9 is their default gateway.

If one of these devices wants to send a packet youtube.com, it constructs a packet:

Code Select Expand


+---------------------------------------+
|IPv6 header                            |
|     From: 1:2:3:4:0:3:99:6 (pc)       |
|       To: 2001:4860:b007::be (youtube)|
| Protocol: 6 (TCP)  other flags        |
|           ...                         |
+---------------------------------------+
|TCP Header                             |
|       Source Port: 55381              |
|  Destination Port: 80                 |
|  more stuff (seq#, syn, etc)          |
+---------------------------------------+
| GET / HTTP/1.1                        |
+---------------------------------------+


Now my device has to send this packet somewhere. Since this device is connected over Ethernet, it wraps it in an Ethernet header. But the question is: what ethernet address (MAC) on the network should it send it to?

In the old IPv4 world, the device knew the IPv4 address of the "default gateway" (e.g. 192.168.1.1). But the packet isn't sent to that address. That address is simply used as a placeholder so it can find the physical (i.e. ethernet) address of where to send the packet. The IPv4 address (e.g. 192.168.1.1) was converted into a physical ethernet address (e.g. 00:01:3C:9f:28:37) using an ARP broadcast.

In the IPv6 world the same "default gateway IPv6 address"-to-"default gateway physical address" conversion happens, but it happens through an ICMP ND Neighbor Solicitation broadcast. The result is the same; i know where to send the packet (i.e. 00:01:3C:9f:28:37). So the constructed packet is wrapped in an Ethernet header and placed on the wire:

Code Select Expand


+---------------------------------------+
|Ethernet Frame header                  |
|  From: 00:01:3c:93:88:ab (pc)         |
|    To: 00:01:3C:9f:28:37 (router)     |
+---------------------------------------+
|IPv6 header                            |
|     From: 1:2:3:4:0:3:99:6 (pc)       |
|       To: 2001:4860:b007::be (youtube)|
| Protocol: 6 (TCP)  other flags        |
|           ...                         |
+---------------------------------------+
|TCP Header                             |
|       Source Port: 55381              |
|  Destination Port: 80                 |
|  more stuff (seq#, syn, etc)          |
+---------------------------------------+
| GET / HTTP/1.1                        |
+---------------------------------------+ 


My tunnel endpoint device receives this packet, and sees that it's destined for 2001:4860:b007::be (youtube.com). It realizes that this destination address is on a different subnet than it is configured for (1:2:3:4:x:x:x:x), and so needs to send the packet to its default gateway. In this case its default gateway is an IPv6-over-IPv4 tunnel. My router knows how to wrap this IPv6 packet in an IPv4 packet for transmission through the tunnel:

Code Select Expand


+---------------------------------------+
|IPv4 header                            |
|     From: 216.8.130.128 (me)          |
|       To: 209.51.181.2 (HE Chicago)   |
| Protocol: 41 (IPv6 encapsulation)     |
+---------------------------------------+
|IPv6 header                            |
|     From: 1:2:3:4:0:3:99:6 (pc)       |
|       To: 2001:4860:b007::be (youtube)|
| Protocol: 6 (TCP)  other flags        |
|           ...                         |
+---------------------------------------+
|TCP Header                             |
|       Source Port: 55381              |
|  Destination Port: 80                 |
|  more stuff (seq#, syn, etc)          |
+---------------------------------------+
| GET / HTTP/1.1                        |
+---------------------------------------+ 


Hurricane strips off the IPv4 header and now has a full IPv6 packet. It sees that the destination address (2001:4860:b007::be) is on a different subnet, and has set of routes defined so it knows on which wire/cable/fiber it should send the packet to next - so that their peering backbone provider will pick it up, and eventually give it to Youtube.

When youtube sends its response, the destination address is my device on my network (e.g. 1:2:3:4:0:3:99:6). Hurricane Electric received the packet because peers know that HE own's the destination address block 1:2:3.

Hurricane then knows to send me the packet, because they know that i own own the destination address block 1:2:3:4. They wrap the packet in the same IPv4 header for transmission through the tunnel:

Code Select Expand


+---------------------------------------+
|IPv4 header                            |
|     From: 209.51.181.2 (HE Chicago)   |
|       To: 216.8.130.128 (me)          |
| Protocol: 41 (IPv6 encapsulation)     |
+---------------------------------------+
|IPv6 header                            |
|     From: 2001:4860:b007::be (youtube)|
|       To: 1:2:3:4:0:3:99:6 (pc)       |
| Protocol: 6 (TCP)  other flags        |
|           ...                         |
+---------------------------------------+
|TCP Header                             |
|       Source Port: 80                 |
|  Destination Port: 55381              |
|  more stuff (seq#, syn ack, etc)      |
+---------------------------------------+
| 200 OK                                |
+---------------------------------------+ 


Where my router device picks it up, because it is the device listening at the other end of the tunnel. It unwraps the IPv4 encapsulation, and sees an IPv6 packet destined for an address on the local subnet (1:2:3:4:0:3:99:6).

Because it is on the local subnet, it knows it needs to place the packet inside an ethernet frame header and place it on the wire, but it needs to know the physical ethernet (MAC) address of the device it should send it to. So it does the same IPv6 neighbour solicitation, and gets a response from the original device with address (00:01:3c:93:88:ab). It then wraps it in the ethernet frame for transport over the twisted pair:

Code Select Expand


+---------------------------------------+
|Ethernet Frame header                  |
|  From: 00:01:3C:9f:28:37 (router)     |
|    To: 00:01:3c:93:88:ab (pc)         |
+---------------------------------------+
|IPv4 header                            |
|     From: 209.51.181.2 (HE Chicago)   |
|       To: 216.8.130.128 (me)          |
| Protocol: 41 (IPv6 encapsulation)     |
+---------------------------------------+
|IPv6 header                            |
|     From: 2001:4860:b007::be (youtube)|
|       To: 1:2:3:4:0:3:99:6 (pc)       |
| Protocol: 6 (TCP)  other flags        |
|           ...                         |
+---------------------------------------+
|TCP Header                             |
|       Source Port: 80                 |
|  Destination Port: 55381              |
|  more stuff (seq#, syn ack, etc)      |
+---------------------------------------+
| 200 OK                                |
+---------------------------------------+ 



All took place with everyone only needing to know one subnet (1:2:3:4:x:x:x:x), and nobody needing to have a fixed "server" or "client" IPv6 address.

Obviously my understanding is fundamentally flawed somewhere; but i don't know where.

PS:  If you're not seeing my flying-pigs avatar, then either your reverse DNS or your browser is not set properly.

Which i am not. :(

[jgeorge]

Which means either a) there really is no technical reason for it, or b) i am missing something in my understanding of IPv6 and routing.

Meaning no offense, I think the likely possibility is option b. HE.net has done IPv6, done it well, and done it for a long time, so I'm willing to bet that the tunnel setup you get today is quite likely the result of a fair amount of design on their end.  I'm not trying to insult, I'm just saying that there's likely more to the tunnelling protocol that's not particularly clear to you (to me, either, while I'm comfortable with IPv6 on my local network end, the actual protocol for tunnelling 6to4 is more or less a black box to me... it just works, so I leave it alone).

While it's true hat you would not normally see traffic coming to/from your "tunnel" subnet addresses, my understanding is that those addresses are encapulated in the 6to4 protocol in order to make the transport "look" like you're routing your routed/64 network straight out to the network. They *are* used, and they are important, but looking at your network as a whole you shouldn't see them because they're the underlying transport that gives you the connectivity you see.

The address of a default gateway is simply a placeholder - it serves to instruct a router which interface it needs to place traffic on to that it can continue on its journey. In my case that default gateway is HE's default router. There is no other place it can go - it must go to HE.

Well, no, not really. In your case (in all of our cases) our default router for the routed/64 subnet is on OUR side. It's the device that contains an IPv6 address on your routed/64 and the IPv6 address of your tunnel endpoint. That device, whatever it is - router, PC, whatever - is acting as a router to direct traffic from your routed subnet out the tunnel to HE's network. You don't have a default router on HE's side - the tunnel is a point to point protocol that doesn't need any routing - there's no other place for that traffic to go other than the other side of the tunnel.

Cheers,

Joe

[michadom]

I suggest this thread to be Sticky. It's very useful for anyone, made me understand everything about the HE Tunnel, the Routed /64 and /48 prefixes, Server IP(4,6) Address and Client IP(4,6) Address.  ;)

[josejimeniz]

It never really answered the question.

i was hoping someone would eventually come along and explain it all.

[mtindle]

You mean my IPv4 address, right? Traffic inside the tunnel doesn't come from my assigned client IPv6 address (x::2) - it comes from the IPv6 address of the device sending the packet.

Correct.

Which then begs the question - what is the purpose of my endpoint devices IPv6 address (x:x:x:x:x:2) when it is quite possible that no traffic will ever come from that IPv6 address?

Helps us have something to test to on your side.  And yes, when you ping or trace from your router, it WILL source packets from ::2.

Strictly speaking i don't even need to know the "server's" IPv6 address (i.e. x::1) address - traffic is placed in the tunnel destined for some far off host on the Internet. No packet is ever sent directly to x::1.

Sure, the packet will get forwarded by our side correctly.  Traffic can come to our router on the tunnel, and while our router would get the packet, unencap it, and then likely forward it correctly, your router (or more correctly, your forwarding engine) should have no expectation that it will happen that way. Theoretically it does have to go to the gateway ::1 or more specifically, to our layer 2 address, but in this case the existence of the tunnel removes the need to find the layer 2 address.  Using a correct gateway IP just makes the forwarding decision easier / saner on your router / you.  In this case, it just happens to be out an interface that only has one host.

On some platforms, you even can just specify an interface as a destination for a route (default,) but that is not as common or intuitive and we're trying to make this easy.  We're not trying to do unnumbered tunnels or save v6 address space.  It also makes troubleshooting much harder when the packets disappear into an unnumbered tunnel or the routing tables don't match up with the configured interface IPs.

I will however throw all packets destined for your point to point /64 down the wire at you as well.  Your router will unencap the packet and see the destination is ::7.  It usually doesn't just blindly throw the frame out another interface but makes it's own routing decision at this stage.  In this case, your router would see the packet for ::7 and say "ah hah, my route for that is this tunnel interface," dutifully wrap it back up and punt it back to our router... routing loop ensues and the TTL kills it finally.

Yes, you can probably still get your tunnel to work by setting your default gateway to some other IP on the point to point /64.

Yes, you can probably put the /64 on a LAN internally and then make a more specific /126 interface on the tunnel.  It probably would work but I've never tried it and it's well outside the range of what most folks are willing to do since it's kind of a hack, it's sketchy, violates the subnetting we expect, and almost always ends up in tears unless you have a very specific reason for doing it and understand fully what you are doing.

I encourage you to try!  For science!

(Don't do both of the above at the same time :) )

The address of a default gateway is simply a placeholder - it serves to instruct a router which interface it needs to place traffic on to that it can continue on its journey. In my case that default gateway is HE's default router. There is no other place it can go - it must go to HE.

Not quite.  The address of the default gateway isn't only a placeholder to point to an interface.  It certainly helps resolve the next hop to a layer 2 (often mac) address, which also usually signals an interface.  But no, it doesn't always have to go to us.  Just because many tunnels are simplified and have a single default route out, that's not always true.  Many other tunnels we have provisioned go to more complex networks and actually run routing protocols making the routing to a next hop IP very important.

Simply making HE's "default router" be in your routed subnet doesn't really buy anything on HE's side - since you get the whole subnet it's not like they'd be able to use that router IP address for any other customers - they'd have to aggregate your default router IP (and everyone else's) somehow anyway, but it would be more work and a more complex thing to manage than just putting you behind a point to point network as  it is.

i'm not behind a single IPv6 point as it is. IPv6 packets coming out of the tunnel at their end are not "from" my x::2 address; they are from the /64 address of the device that initially sent the packet.

Yep, the packets would most likely get forwarded correctly because of this. But it's not "pretty."

As for the point to point network being a /64 and not a /127 you're right, as well, that it *could* easily be a /127
...
If IPv6 address space were tighter than it is (or ever will be) then those smaller subnets make sense, but it's kind of a generally accepted policy that /64 would be the smallest subnet prefix assigned to a user, to keep from having to do the really twiddly bit flipping math for tiny subnets that aren't really needed.

i was looking at it from the point of view that they have gone out of their way to allocate an entire 2nd subnet to me; and as far as i can tell there's no reason for it.

Which means either a) there really is no technical reason for it, or b) i am missing something in my understanding of IPv6 and routing.

As mentioned above.  Using a numbered tunnel requires we assign IPs.  It just happens that in IPv6, any numbered network segment expects a /64 and a lot of equipment balks at anything else.  Then we also assume that people are going to want to put things on the end of the tunnel without having to jump through all the hoops of setting up the forwarding tables so it doesn't just loop.  So we assign a separate, new /64 for the LAN on the far side of the tunnel. 

Yes you can set it up with (almost) the whole point to point /64 inside the LAN but the majority of devices/people cannot handle the unnecessary complexity it requires.

Yes we could have a button that setup the tunnel unnumbered where we just point the /64 out the tunnel interface, (and you point default out yours) but we don't bother with the unnecessary complexity in the tunnel provisioning, especially when it's much nicer to have IPs on the ends for troubleshooting.  And we're not worried about running out of /64s. :)

[lfoothome]

Another excellent thread for Newbies and Explorers still setting up their ipv6.  At least it was for me.