Hi all,
I've been a long time HE tunnel user, and it's really opened my eyes to the awesomeness that is IPv6, so thanks to HE for providing this service.
I recently switched to an ISP that offers native IPv6, but still uses dynamic /64 prefixes (Comcast if it matters), and I'm trying to figure out the big picture of how IPv6 is expected to work in such an environment.
Sorry if this gets long, reading through RFCs hasn't really helped me. :-[
- What happens when an ISP decides to change your allocated prefix? How does the gateway device know to update?
- How does my router propagate this change to my network? How does a DHCPv6 network differ from a SLAAC network in this regard?
- What about my machines that I've given static addresses to? for example, I've given my backup machine a static IP inside my /64, how is that supposed to work when the prefix changes on me?
I guess the crux of my line of questioning is this: why are dynamic /64's a thing in the IPv6 world? Address exhaustion should be all but impossible, and it seems that by not having a static prefix to create addresses from, a lot of the benefits of IPv6 go away. How am I supposed to have a globally routable host
with a DNS entry if the address is going to keep changing? I know the IPv6 standards make a ton of requirements around things like /64's being the minimum delegated prefix, but what do they say about dynamic addresses?
At least with IPv4 and NAT I could just give my server 10.0.0.2 and be done with it :-[ I know I can do something similar with ULAs, but I want my globally routeable address dammit!
A final question: does anyone run their HE tunnel along side native v6? Could I just continue to use it but not as the default route, and have my cake and eat it to?
thanks!
Quote from: arader on October 19, 2015, 01:34:50 PM
A final question: does anyone run their HE tunnel along side native v6? Could I just continue to use it but not as the default route, and have my cake and eat it to?
No, you cannot source from HE IPv6 space and have it go out Comcast and return either Comcast or HE, nor the other way.
With Comcast setup dhcpv6-PD with a prefered lifetime of infinity and the delegated prefix should be fairly stable.
Quote from: broquea on October 19, 2015, 02:21:55 PM
Quote from: arader on October 19, 2015, 01:34:50 PM
A final question: does anyone run their HE tunnel along side native v6? Could I just continue to use it but not as the default route, and have my cake and eat it to?
No, you cannot source from HE IPv6 space and have it go out Comcast and return either Comcast or HE, nor the other way.
Oh I get that, what I mean is continue to have my tunnel set up on my router, but not configure it as the default route. rtadvd would be configured to hand out the Comcast prefix. I could then just statically add my tunnel's IPv6 addresses to my internal servers. This way HE would route traffic
in to my network, but I'm not sure about traffic leaving it. How does IPv6 handle multiple public addresses on an interface? Would my router somehow have to know to send traffic originating from an HE address out the tunnel, and leave Comcast traffic alone?
Quote from: JRMTL on October 20, 2015, 01:23:04 AM
With Comcast setup dhcpv6-PD with a prefered lifetime of infinity and the delegated prefix should be fairly stable.
Ah that's good news! forgive me but I haven't played with DHCPv6 at all, but would the preferred lifetime setting be something I could set? I'm picturing my router running dhcpv6 on the WAN interface and 'infinity' being some config option I apply.
I'd still like to understand
how prefix updates propagate though, even if it should be rare.
Barring any policy routing, routing would work as it normally does. Find the most-specific matching route to the destination in the routing table. This would mean return traffic from tunnel IPs would try to go out the default route. If that's set to Comcast, uRPF or similar filters on their side should realize that's not an IP they should see traffic from over your link, and discard it. Similar thing if the default was pointed out the tunnel and the source was a Comcast assigned IPv6 address.
Now, depending on the tools available on your side, you might be able to set up policy routing, where you explicitly tell your side's routing that traffic from A should go out default-A and traffic from B should go out default-B.