IPv6 Native with Telstra, Australia

[Larrikin]

@derelict said in IPv6 Native with Telstra, Australia:

Telstra chose to be different and refuse to document that difference.

Different to what? My issue with IPv6 is that it's incredibly complex compared to IPv4, and there are many ways to implement it and still be compliant to the standard.

I agree it would be nice for Telstra to document how they run IPv6, but they have made a commercial decision that if you sign up with them, you use their router. Everything that has been done has been unofficial. If we don't like it, then we find another ISP. I'm not arguing that Telstra is right in their approach, it's just the decision they have taken.

They are by far the largest ISP in Australia - they own the market. And that means most people are standard "mums and dads" who just want an end to end service supported - so Telstra can support the router as well given that they control it.

Anyhow, I guess in summary, in part I agree with you in that I'd like them to publish this information, but the moment they do, they are creating a rod for their own back for then getting sucked into supporting third party routers which goes against the grain of the company's position.

I also keep coming back to IPv6 is a very complex beast. Even if they did publish more info on it, each vendor has different ways to configure it, so what then?

[Derelict]

That is true for all ISPs. It is particularly problematic when an ISP chooses to deploy something that requires special treatment and is silent about what that special treatment is.

[Derelict]

Giving people the information necessary to configure their own routers is not stabbing themselves in the back.

They can still say "use our router or we're going to hang up on you."

[Larrikin]

@derelict said in IPv6 Native with Telstra, Australia:

If you search this forum for net.inet6.icmp6.nd6_onlink_ns_rfc4861 you will find this thread.

No other ISP in the world is known to require that default be changed.

Goes to show you how good @Bigmaccius is in finding that particular tunable and getting it working :). I'd rather focus on the positive. This thread started asking the community for help. And it delivered (along with a contact at Telstra). Now we have a publicly available Wiki that shows exactly how to get it working.

To me, that is the true story here.

For future, as IPv6 gets further deployed (and its accelerating now) this situation is going to happen time and time again with other ISP's around the world. If I were netgate (for the thousandth time), I'd be documenting all of these wikis, put them all in one place so as the community works out how each ISP works, they can go to a netgate page and look up their ISP.

If their ISP is missing, that's a commercial opportunity for netgate to monetise helping people sort these things out.

[Derelict]

And zero burden placed on the ISPs who, in the vast majority of cases, is the one actually getting paid $$

[Larrikin]

@derelict said in IPv6 Native with Telstra, Australia:

Giving people the information necessary to configure their own routers is not stabbing themselves in the back.

They can still say "use our router or we're going to hang up on you."

But my issue is still that each vendor configures things differently. The thing is, we actually got the information from Telstra. It just didn't register to any of us the importance of it at the time. Why? Because we didn't know that it directly aligned us to the system tuneables section did it? As you said yourself, it's an obscure setting. Is that Telstra or PFsense? Why does Ubuntu work straight out of the box?

The reality is its a combination of everything and bringing it all together to make it work. That took time and patience, further packet captures to work how how that specifically applied to FreeBSD and PFsense.

I'm not sure that had Telstra provided us any more info, we would have gotten here any faster.

This is complex. Pfsense is complex. IPv6 is complex. Other vendors configure IPv6 differently due to complexity.

[Larrikin]

@derelict said in IPv6 Native with Telstra, Australia:

And zero burden placed on the ISPs who, in the vast majority of cases, is the one actually getting paid $$

I don't know how many times to say the same thing. Netgate has an opportunity to make money here. Ethically, fairly, and appropriately. It should productise an IPv6 consulting service separate to its support contract.

If Netgate choose not to do that, then it's a lost opportunity for Netgate to make money too.

[Bigmaccius]

Thanks @Larrikin - the interesting thing for me with this security fix in FreeBSD that is controlled by the net.inet6.icmp6.nd6_onlink_ns_rfc4861 option is that it (as stated by the authors of the fix here) "causes IPv6 Neighbor Discovery
Neighbor Solicitation messages from non-neighbors to be ignored"

To understand this we need to understand what is a "neighbour" and what is a "non-neighbour" - as far as I can tell any host with a link-local address (starting with fe80::) is a neighbour (since those addresses are not-routable), and therefore anything else can be considered a non-neighbour.

So back when we were trying to get pfSense talking to Telstra, we kept seeing this type of solicitation (from a non link-local address on Telstra's side):

22:15:10.179879 IP6 2001:8003:0:bdf:f0:3:9:0 > ff02::1:ffe7:b52f: ICMP6, neighbor solicitation, who has fe80::20c:29ff:fee7:b52f, length 32

The question for Telstra could be here, why are you sending a neighbour solicitation from a non link-local address? Could this be a simple case that they have not configured the source IPv6 addressing properly?

And even better if FreeBSD is the only OS to have limited solicitations from non-neighbours does this mean that all the other OS's and platforms are allowing this security vulnerability?

Food for thought.

[Derelict]

Exactly.

[Larrikin]

@bigmaccius said in IPv6 Native with Telstra, Australia:

The question for Telstra could be here, why are you sending a neighbour solicitation from a non link-local address? Could this be a simple case that they have not configured the source IPv6 addressing properly?

And even better if FreeBSD is the only OS to have limited solicitations from non-neighbours does this mean that all the other OS's and platforms are allowing this security vulnerability?

Food for thought.

You raise some excellent points. I'll chat to my Telstra contact in the next couple of days on the phone and ask him specifically about that. See what he says. I may or may not be able to disclose the substance of that conversation depending if there is actually a security vulnerability that they need to address. If there is, I'll email you privately about it.

If I have permission to disclose whatever we speak about, I'll also post here.

[randomaustralian]

@larrikin to be honest i had a similar experience with someone on the crowd forums who provided me with the ports to forward to make the Telstra provided router function behind my 3rd party gateway...

i was referring to most of Telstra staff

[Larrikin]

@randomaustralian said in IPv6 Native with Telstra, Australia:

@larrikin to be honest i had a similar experience with someone on the crowd forums who provided me with the ports to forward to make the Telstra provided router function behind my 3rd party gateway...

i was referring to most of Telstra staff

Oh, I agree with you.

The thing is though, what I am trying to avoid here is ISP bashing on a topic such as this (not saying you are doing that either - I'm more just saying that in general).

The reality is as I've posted, that there are a number of complexities involved in getting IPv6 working, one of them is FreeBSD / PFSense and the multitude of variables that are available to configure it, another is the ISP, another is the knowledge a person has doing the troubleshooting, another is the complexity of IPv6 itself. It a gross over-simplification for anyone to focus on any one of those things in particular, single them out, and apportion blame as to why it's not working.

That's more my point in this. I'm not trying to defend Telstra - I'm actually more trying to make the point to people to stop trying to find someone or something to blame. The only thing I'd blame (if someone is determined to blame something) is the complexity of IPv6 itself. That's the reason we are all in this thread. It's not because of stupidity of people, decisions, or any one thing in particular.

Again, what I've written above isn't directed at you. It's directed at everyone :)

[randomaustralian]

Could this have to do with why there are weirdsettings about allowing local only communication?

pfSense reports that my wan_dhcp6 is a local IPv6 address even though i have internet rout-able addresses on my interfaces and my local network.

maybe Telstra are using local local link addresses on their internal network to distribute internet addresses? would that not be a thing?

[JKnott]

@randomaustralian said in IPv6 Native with Telstra, Australia:

maybe Telstra are using local local link addresses on their internal network to distribute internet addresses? would that not be a thing?

That's entirely normal with IPv6. Routing is usually done with link local addresses. If there's a routeable address on an interface, it's only there for testing, management, etc. It plays no part in routing.

Here's what mine shows:

Internet6:
Destination Gateway Flags Netif Expire
default fe80::217:10ff:fe9 UG re0

[Bigmaccius]

@randomaustralian as @JKnott has already stated it is normal to have a gateway that is a link-local address (i.e. fe80::). Thought it might be worth explaining this a little more in-depth. Also, what did you mean by "weird settings about allowing local only communication"?

Every IPv6 interface must have a link-local address (it is a stated requirement in RFC4291), and it is usually derived from the MAC address of the interface (as per RFC4862). For example, a MAC of 11:22:33:44:55:66 will have a link-local address of fe80::1122:33ff:fe44:5566 - here's a nice site that explains it. Also these addresses can be randomised (but must be unique within the same segment/broadcast domain), and you might see this in pfSense on the LAN interface when it gets an address fe80::1:1 being assigned as a link-local address; this is a nice way of being able to refer to the main router/gateway on the LAN and is easy to remember!

Having fe80::1:1 for your router on a LAN is useful also because what if you needed to replace your pfSense hardware? The new hardware would have a different MAC and hence a different default link-local address (i.e. imagine restoring your config to a new firewall). Just makes it easier and less disruptive to a network that might contain a lot of active hosts trying to route their traffic out through a link-local that has disappeared.

Back to your gateway example screenshots. What's happening here is that your gateway points to the fe80:: (link-local) address of your ISP's router and pfSense will be forwarding outbound IPv6 packets to that address - those packets will contain the source and dest IPv6 addresses that are publicly routable.

If you flip this around and think about what your ISP is doing to send IPv6 packets to your pfSense firewall - they will either be forwarding them to your WAN's fe80:: (link-local) address or may be sending them to the pfSense WAN's publicly routable (i.e. 2001:8003:f00...) address - it could be either, I'm not exactly sure which is more common - if your WAN doesn't have a public IPv6 address (which is possible if it never requested an IA_NA and only an IA_PD) then your ISP would be routing to your WAN's fe80:: (link-local) address since it would have no other choice.

If you want further reading on this I did find an RFC7404 that discusses using link-local addresses inside IPv6 networks for links between routers and the advantages and disadvantages. From what I have seen so far in IPv6 networks there's no single answer that is right, and network engineers will often have very strong opinions about how one approach is right and vice-versa. I like to subscribe to the simple rule: if it's working don't touch it!

[JKnott]

@bigmaccius said in IPv6 Native with Telstra, Australia:

they will either be forwarding them to your WAN's fe80:: (link-local) address or may be sending them to the pfSense WAN's publicly routable (i.e. 2001:8003:f00...) address - it could be either, I'm not exactly sure which is more common

Both resolve to the same MAC address, which is what is used to send frames over Ethernet or other layer 2. All a router needs to know is which interface to use. In fact, on point to point links there's not even a need for any IP address. Using either IPv6 address can be used to obtain the MAC address for forwarding, but my understanding is that it's usually the link local. As you mentioned, it's always going to be available.

Incidentally, I've been through this sort of thing, trying to explain a problem to my ISP. While I get a prefix on my LAN, it's not usable, as there is no correct route back to my network. If I, for example ping www.yahoo.com, I can see the pings go out, but nothing comes back. However, pinging from the firewall, rather than a computer behind it works. One guy Iwas speaking to insisted that proved IPv6 was working properly, although in fact it wasn't. It's real "fun" trying to explain to the support people how IPv6 actually works.

[biggsy]

Just wanted to say thanks to all involved with finding a solution to this. Excellent work.

It looks like I'll be getting NBN/HFC some time between April and June (this year, they say).

Having this IPv6 configuration information in advance will be a huge help. Unless Telstra change their end, of course.

[Larrikin]

@biggsy said in IPv6 Native with Telstra, Australia:

Having this IPv6 configuration information in advance will be a huge help. Unless Telstra change their end, of course.

We will keep up with them, so no need to worry. I've already been in contact with my Telstra contact this morning. All good.

[Larrikin]

@bigmaccius @Derelict

Check out how much traffic is flowing on IPv6 since I switched it on:

[randomaustralian]

@larrikin

not so much here. but i am only a single user