What IPv6 default gateway does open wrt use for a 6to4 protocol? Does it use the IPv4 default gate (set up via negotiation when setting up IPv4) or does it use the default 192.88.99.1 ?
I can't find this documented anywhere!
If it uses 192.88.99.1, can I get equivalent doing 6in4 with the gateway as 192.88.99.1 ?
Really just getting ready for if plus.net ever switches on IPv6, which seems unlikely ....
And to answer my own question (in part) ip -6 r gives:
default from 2002:2ed0:99b4::/48 via ::c058:6301 dev 6to4-wan6 metric 1024
default from 2002::/16 via ::c058:6301 dev 6to4-wan6 metric 1024
And ::c058:6301 corresponds to 192.88.99.1 - so the default route is via there!
It's a Layer 3 tunnel, there is no gateway. You just route packets towards it.
And you found the route.
Ummmm...OK.
Just not sure why you're mixing IPv4 and IPv6.
Your router is going to encapsulate all IPv6 traffic into IPv4 packets, and forward them to other routers, using the standard routing algorithms.
Well 6to4 and 6in4 is a mixture of IPv6 and IPv4; both put IPv6 packets into IPv4 containers, and then send over IPv4. The question though here is how you route packets. What is clear is that 6to4, when enclosed into an IPv4 packet, it sends the packet via IPv4 to 192.88.99.1 - but this isn't really documented.
Only place I could find the routing information is in the IPv6 routing table ip -6 r - I can't find it elsewhere. In the IPv6 routing table it is shown as an IPv6 number (which expanded is the 192.88.99.1) but how does the machine use this on a 6to4 connection, something somewhere expands it to an IPv4 packet - as thats all you can send across an IPv4 network, until you reach an IPv6 gateway.
@eduperez question is not the routing algorithms, but what is the default route. So where packets get sent.
6to4 has the convention that 192.88.99.1 is a IPv4 to IPv6 gateway, but one needs to know this to make jump from one network to the other ...
To be clear, are you referring to 6to4 ot 6in4?
Can we see your interface config?
It would use your gateway, since you have IPv6.
My current ISP routes 192.88.99.1 packets via he.net; and he.net provides the IPv6-IPv4 gateway. If I were to get a tunnel broker I'd go via he.net. So as concerns outgoing packets in make no difference if I use 6to4 or 6in4 via he.net - both via he.net.
The difference is what happens to returning packets - 6to4 and the 2002:: packets can be sent to any IPv6 to IPv4 gateway - who can take the IPv6 packet and enclose it inside and IPv4 packet - then send direct to my IPv4 router as the IPv4 address is in the 2002:: packet. With 6in4 I guess the packet gets sent to the broker, so probably he.net.
None of this transitional technology is good. For me a speed test says IPv4 takes 38ms and IPv6 takes 180ms.
config interface 'wan6'
option proto '6to4'
option tunlink 'wan'
The only IPv6 that I have is 6to4; there is no native IPv6. plus.net does not provide native IPv6
OK, I think we crossed responded to one another.
That IP you keep quoting belongs to HE. OK, so let's clarify - to make sure you know which protocol:
So this is incorrect - delete it.
I'm lost at all of your phrasing.
Lets see your interface, that should be 6in4.
config interface 'henet'
option proto '6in4'
#...
HE actually gives you an example config as well on the Tunnelbroker.net site. They even offer an IPv6 certification path, where you setup the tunnel in the process (see: https://ipv6.he.net/certification/).
Wrong RFC BTW.
See: RFC 4213
3.1. Encapsulation
The encapsulation of an IPv6 datagram in IPv4 is shown below:
+-------------+
| IPv4 |
| Header |
+-------------+ +-------------+
| IPv6 | | IPv6 |
| Header | | Header |
+-------------+ +-------------+
| Transport | | Transport |
| Layer | ===> | Layer |
| Header | | Header |
+-------------+ +-------------+
| | | |
~ Data ~ ~ Data ~
| | | |
+-------------+ +-------------+
Encapsulating IPv6 in IPv4
My route (and yours) should look similar to:
default from 2001:xxxx:xxxx::/48 dev 6in4-henet proto static metric 1024 pref medium
This reaches the IPv6 Internet. The IPv4 destination would be configured in the 6in4 network interface config. That HE IP address would be added as the DST IPv4 address in the IPv4 header from Figure 3.1. For return packets, HE's IP would be the SRC and you would be the DST IPv4 address in the header.
Your router is the device that adds/strips the IPv4 header - the other router resides at HE, who routes the packet onward to the IPv6 Internet as a broker.
My understanding is that 192.88.99.1 is an anycast address that can be attached to many machines in the internet, one of which is inside he.net - my ISP (plus.net) routes 192.88.99.1 traffic to he.net; I don't believe this is the only gateway, just the one used by plus.net.
plus.net is IPv4 only. I do use 6to4 as transitional technology for using IPv6 on an IPv4 network. This works with plus.net because although they don't provide IPv6, then do route 192.88.99.1 traffic (to he.net) plus.net are under no obligation to forward such traffic, but in practice they do. So 6to4 works on the plus.net network even though it is only IPv4.
I don't have a he.net account. I don't see what benefit it would bring. For me 6to4 works fine for now. To use 6in4 I'd need a broker account such as he.net, so its more hassle.
I think we are going off topic here - my question was how open wrt routes 6to4 traffic on an IPv4 network, it was not what is a suitable transitional technology is, or what I should have implemented. I am just interesting in the workings of 6to4 as it is implemented in openwrt. I'm sorry if this was not clear.
It uses IP Protocol No. 41 in instances to transfer the packet to the other version router.
That header would use 192.88.99.1 as the DST IP on an IPv4 network (whatever you call it, account or not).
Anycast is a phrase that means the DST IP could be physically located in many places (i.e. 8.8.8.8). So your inquiries about that are unclear. If your ISP (or whomever) told you to use 192.88.99.1 , then you would use that, it doesn't matter to you if it's anycasted or not.
More specifically, your ISP would know about their 6to4 service in detail, we wouldn't.
See: https://en.wikipedia.org/wiki/6to4#Routing_between_6to4_and_native_IPv6
Lastly: https://datatracker.ietf.org/doc/html/rfc7526
I think you're quoting an IP that is no longer a special use IP - per RFC 7526, perhaps this is why I'm confused.
This document formally deprecates the anycast 6to4 transition mechanism defined in [RFC3068] and the associated anycast IPv4 address 192.88.99.1. It is no longer considered to be a useful service of last resort.
The servers they connected to were also deprecated. So I'm still confused as to what's working fine. It hasn't been required functionality for network OSes since 2015 (OpenWrt/LEDE 17).
I think Hurricane Electric is running a legacy 6to4 service at 192.88.99.1, now I understand.
Thank you for the clarity, I was just taken aside that you use a transition technology that no longer exists [in RFC] - or rather is legacy and deprecated.
Yes, you are right RFC7526 Deprecating the Anycast Prefix for 6to4 Relay Routers deprecated RFC3068 and RFC6732. and in particular
It recommends that future products should not support 6to4 anycast
Which I take that to mean 192.88.99.1 should not be supported.
Yet the IPv4 6to4 anycast addresse propagates on the internet, the IPv4 anycast on my ISPs network; and also the IPv6 2002:: anycast more generally.
So I take it for what it is - a stop gap solution, that works for now, may stop working at any time; but also may bidge the gap for when IPv6 is more generally supported.
That time has past; but yes - that's what it was for.
To state this more clearly "Hurricane Electric maintains a Global legacy 6to4 anycast service."
EDIT:
You shoulda understood this to mean - "do not configure your router with 6to4". It is a legacy system, and no longer sustained by the Internet Engineering community by backed RFCs. It's really sad that many ISPs don't have any IPv6 yet.
Ok - lets see if we can reach conclusion here. 6to4, and in particular the 192.88.99.1 anycast is deprecated by RFC7526 - so the only remaining question is how openwrt reacts.
Now your point if I appreciate it is that means that 192.88.99.1 anycast is deprecated everywhere. I also suspect you mean that the 2002:: anycast is also deprecated (can't find an RFC for that - but objections are the same, the 2002:: anycast needs some routers to pad the IPv6 packet in a protocol 41 IPv4 packet, and propagate on the IPv4 network - but the router that does this isn't specified).
I don't think you have a problem with Protocol type 41 IPv4 packets as a general package for IPv6 packets over an IPv4 network.
So where does this leave 6to4 in openwrt; the 6to4 package hasn't really changed since 2015, than this implements the deprecated algorithm. So does think mean that in openwrt we should mark the 6to4 package as to be removed, then in say two release time - just totally remove the package? I guess we need to involve @jow in this discussion - as he maintains the package.
And where does it leave me, as someone whose ISP only provides IPv4. It suggests my local lan, a IPv6 island should either be removed. Or go via an he.net broker tunnel using 6in4 - I'll need to check how packages there are constructed - specifically are the returning packets forced to route via he.net where they transition from IPv6 to IPv4.
It's really difficult when you're making up information and terminology. I honestly thought this was clear enough:
I think you slightly misunderstand. The RFCs clearly state the status of the 2002:: network.
So it's clear you haven't looked up or traced the 192.88.99.1 IP yet. Again:
The IP is currently maintained by Hurricane Electric. Obviously, so they can continue offering the Global 6to4 anycast service. Just review the RFC.
No, we don't. You setup a legacy technology, and wanna complain to the maintainer about what?
EDIT:
Why don't you contact Hurricane Electric instead of jow with your complaints?
Then maybe they'll explain it exists for the benefit of users such as yourself - who setup legacy technologies without knowing or understanding RFCs in their entirety - and who honestly still don't have IPv6 from their home ISP/AS.
You don't wanna complain to your ISP that they've yet to offer IPv6, instead (as June 6, 2012 was the day major companies permanently launched IPv6 - over 11 years ago)?
(EDITED to correct IP to 192.88.99.1)
Think its easiest here to just quote RFC7526 :
Current operators of an anycast 6to4 relay with the IPv4 address 192.88.99.1 SHOULD review the information in [RFC6343] and the present document, and then consider carefully whether the anycast relay can be discontinued as traffic diminishes. Internet service providers that do not operate an anycast relay but do provide their customers with a route to 192.88.99.1 SHOULD verify that it does in fact lead to an operational anycast relay, as discussed in Section 4.2.1 of [RFC6343]. Furthermore, Internet service providers and other network providers MUST NOT originate a route to 192.88.99.1, unless they actively operate and monitor an anycast 6to4 relay service as detailed in Section 4.2.1 of [RFC6343].
Operators of a 6to4 return relay responding to the IPv6 prefix 2002::/16 SHOULD review the information in [RFC6343] and the present document, and then consider carefully whether the return relay can be discontinued as traffic diminishes. To avoid confusion, note that nothing in the design of 6to4 assumes or requires that return packets are handled by the same relay as outbound packets. As discussed in Section 4.5 of RFC 6343, content providers might choose to continue operating a return relay for the benefit of their own residual 6to4 clients. Internet service providers SHOULD announce the IPv6 prefix 2002::/16 to their own customers if and only if it leads to a correctly operating return relay as described in RFC 6343. IPv6-only service providers, including those operating a NAT64 service [RFC6146], are advised that their own customers need a route to such a relay in case a residual 6to4 user served by a different service provider attempts to communicate with them.
Which seems clear enough.
I think we have different views here, to me 192.88.99.1 is an anycast address - and the "anycast" is fundamental. To you 192.88.99.1 is implemented as a unicast address - that inside my isp seems to resolve to inside of he.net - I actually can't prove that, haven't yet got the internet to tell me which machine has the alias 192.88.99.1
Anyway for me the "anycast" just means that many machines can actually reply to that ip number, they can be on many networks, in many countries. We shouldn't focus on he.net in isolation - they are just one provider who route 192.88.99.1 onto the IPv6 network; but I expect other companies to exist.
Because I don't have a compliant, my original question was how does 6to4 route the outgoing packets? The authoritative answer I've decided is to just look at the source code - where you can see it is hard coded as 192.88.99.1.
Anyway discussion evolved into the status of 6to4 as a whole. I got to
And I gave up. I registered with he.net for the broker service. Changed into 6in4, and moved to a 2001:: address - I'll just use that until I get native IPv6; and just will never use 6to4 ever again. So this should close this element of the discussion.
And as to do we need to involve @jow - I think we do. The discussion here has evolved into usage of 6to4 and its future. This question should also be in an openwrt context, and @jow is the package maintainer. So @jow view is important here, and what he says we should listen to.
I don't see any need to complain to he.net - as far as I can tell they are implementing RFC7526 to the letter - and I'm fine with that. Actually more than fine - I'd say I'm happy with that.
You must be misreading:
It doesn't appear to be unicast. They anycast Globally and offer the service.
Gave up what, you said 6to4 was working?
It's really difficult when you seem to be representing opinions.
I disagree that the discussion as evolved into that. The time for that past years ago. You seem over 8 years late to the discussion.
And you seem to have overlooked my question:
You setup 6to4 on your router, not jow.
Excellent!
If you insist, we already discussed 6in4 earlier - but you insisted that 6to4 was viable. Then I guess you reviewed the RFCs. I'm glad you understood.
So lets be clear on what I mean by viable:
These three mean that for me at least that 6to4 technology was still working.
No I knew about the RFC back when I switched on 6to4 maybe 5 years ago. The status then was as now, it was deprecated in the RFC, but was functional. That situation has continued - 6to4 is still functional but depreciated.
What has changed now is its clear there there is a segment of the openwrt community that believes that 6to4 should not be used by users
This was the first time I had heard that we should not use 6to4, it was new to me. I reflected and decided to save the argument I would just change to a tunnel broker and use 6in4. So the change was that I heard how strongly a view was held.
Now this brings a question. Openwrt provides a 6to4 package - this package has no warnings, but there is a segment of the openwrt community that believes it should not be used in operational systems.
To my mind this opens the discussion of should openwrt continue to provide a 6to4 package? If it does should that package have a warning attached? What should that warning be? Should there be a timetable for removing the package?
Thats discussion needs to be had, and needs to involve the wider openwrt community, and definitely the package maintainer, so @jow
This is my reason for saying we need @jow input here, it is not a complaint (I have already said that) - but there is a discussion that is needed here, because there is a view that 6to4 should not be used any more.
Does this answer the question?
I really don't think we are going anywhere with this discussion. It is one of my motivations to switch to 6in4 with a tunnel broker. 6to4 is no longer a concern of mine, and a discussion over if we should keep this as a package in openwrt - I would remove myself from the discussion.
Is this any clearer? If not I'm not sure I can explain any better. so think it best that I just leave the discussion at this point. I do hope though that the community as a whole, finds an agreed way forward on 6to4, and how it is presented. I will say thank you though, for giving me the choice over solutions that I could choose to use in openwrt - it is why I like it.