The only thing PPP actually configures with IPv6 enabled is the link-local address.  fe80::/10 space.  Anything beyond that is up to RA/SLAAC/DHCPv6 unless you want to get much more involved.

So yet another fine example of IPv6 at it's best, and yet another reason why I'm really not surprised that it hasn't taken off.

If we poor geeks are having so much trouble what hope is there for the rest of the world?

I can see NAT living long long into the future until the rest of the bugs are sorted out so IPv6 "just works" for any one under most circumstances.

The underlying PPP doesn't have your tunnel's v6 addresses attached to it in any way.  We looked at ways of doing that to make this whole process even simpler, but the implementation of IPv6 in PPP doesn't lend itself to this application.  IPv6 in PPP only negotiates link-level addresses, and then hands it off to RA for prefix announcements and stateless/stateful configuration.  As there's no nice way to find out what your computer decided to configure itself with the RA/SLAAC, there's no nice way to route your /64 or /48 to it.  DHCPv6 would be an option for stateful configuration tagging along with RA... but DHCPv6 support is spotty on the major operating systems.

It could though, you send IPv4 address information out, you could also send out IPv6 information, when I asked pppd to request IPv6 details I got this back:

Protocol-Reject for 'IPv6 Control Protovol' (0x8057) received

I didn't mean firewall, I meant attaching the IPv6 address to the ppp interface after it comes up, alternatively pppd on linux supports IPv6. So the IPv6 address information could be sent along with the IPv4 IP... However I'm still stumped as to why I can get a connection up, but can't ping the next hop...

I finally figured it out, pptp is no better than using IPv6 directly, since it uses GRE protocol, I was hoping/expecting it to be using UDP instead, and while the control packets keeping the tunnel up is using TCP. Nice idea I guess, but can/does break just as much as regular IPv6, please add l2tp which can use UDP instead.

If set to "No"/"no" you need to have shorewall6 installed if you want firewalling for IPv6, too. This can not done by shorewall. Or you do ip6tables manual firewalling...

I didn't mean firewall, I meant attaching the IPv6 address to the ppp interface after it comes up, alternatively pppd on linux supports IPv6. So the IPv6 address information could be sent along with the IPv4 IP... However I'm still stumped as to why I can get a connection up, but can't ping the next hop...

DISABLE_IPV6=No        # could also work with =Yes, please try afterwards.

I wonder if this is what we need to do, add the IPv6 address to the pptp interface instead of adding a secondary interface to route packets over the pptp interface... Although it's academic at this point in time since I can't ping the first hop.

Gah, I meant if you can ping 172.31.255.1, then it's up.  I think it's too early in the morning.

I can't which is why I was hoping someone would give a working linux pptp config.

The easy test is if you can ping the v4 address of your side of the PPTP connection from somewhere else, then it's up.

While I can ping the IP, no traffic comes over the PPTP link when I use ngrep to sniff packets.

Does anyone have a working pptp config for linux (or even better for debian) they can paste?

The reason I ask is the pptp tunnel is up and passing packets back and forth, but on the tunnel page it always reports the tunnel is down.

You can't pass IPv4, or IPv6 traffic?  You should be able to ping at least the other side of the tunnel via the PPTP interface.

If you can't, it may be a NAT issue if you're behind a NAT.

I can't ping the other side of the PPTP tunnel (172.31.255.1) but packets are being sent back and forth from my end to the remote end of the PPTP connection just fine or the tunnel would keeping timing out and dropping, which is what happened before I realised what was going on with the PPTP/IPv6 tunnel server sharing the same IP and tried to re-route it over the tunnel, which caused the tunnel to drop.

I'm on the LA server, going to try the Freemont server.

I'm having the same problem, I think the problem is the IPv6 tunnel server and the pptp server share the same IP, because when the PPTP tunnel comes the IP is added via the default route, what IPs do I route over the PPTP tunnel?

Fair enough, I hadn't noticed the difference before, I guess I didn't think there would a point in doing something like that if you can get a /48 subnet routed etc.

It'd be nice/useful to have the list available all the time, it makes it much easier to evaluate which end points are closer or what not when new end points come online.

Hmmm I checked for unread messages prior to doing anything, but nothing came up, I should have looked here first.

I think you missed the point about my previous post about the IPs, the 7 and 8 aren't in the same /64 subnet, it's kind of confusing, but in any case everything seems to be working now.

I just noticed that on the tunnel page there is 2 different subnets being displayed:

server IP: 2001:470:7:xxxx::1/64

Then below:

Routed /64:   2001:470:8:xxxx::/64

Can ping the new Ashburn, VA tunnel broker server via IPv4, but can't ping the tunnel end point via IPv6, or send/receive packets past it etc.