Hi,
Firstly, huge thanks to the good people at HE for providing their professional tunnel brokering service for free for all this time!
I'm posting to ask HE's policy regarding private peering with the IPv6 prefixes they allocate tunnel users. My situation: I'm in Africa where international Internet access is slow, and IPv6 is scarce, but there are a handful of us who are starting to think about peering privately with tunnels (and other means) to avoid the high RTT of routing via EU/US. By "us" I mean a collection of South African entities ranging from individuals like me, and small-medium ISPs with their own ASNs and IPv6 space.
Do you have a policy for authorising private peering of your IP space?
Thanks,
Aragon
For the peering session itself? Why not use Link-Locals or ULA rather than an allocation registered to a company if its just for use with private peering.
Quote from: broquea on June 04, 2012, 03:15:45 PMFor the peering session itself?
No, more so from the perspective of exchanging routes with one another so that, for instance, traffic to my HE prefix (from local peers here) flows via the private peering sessions rather than international transit.
This is all the terms has to say on that matter:
Quote from: http://www.tunnelbroker.net/tos.phpAddresses assigned to Customer by Hurricane may only be used in association with the service under which they were assigned and only while a Hurricane Electric customer.
The wording is a bit vague. What does in association with cover? I expect that every host and network you give addresses out of the HE provided address space will still route some of its traffic through the tunnel service, so the addresses would have been assigned in association with the service. The terms don't require you to have every single packet used with those addresses go through the tunnel service. Packets between two hosts on your LAN with addresses out of the same prefix assigned from HE, will never reach the tunnel service.
Enough about the wording of the terms, lets for a moment consider what the intent of that sentence might be. I think what that sentence is mainly supposed to disallow is the following situation. You register a tunnel and get a /48 assigned. But instead of using the tunnel service at all, you publish that prefix through a BGP peering, which could in theory reach all of the world. Being a more specific route than the one published by HE, it would attract the traffic. Such usage would clearly be a violation of the terms. And if that's how you want to use the address space, then you should be getting address space from a RIR, not from HE.
So I have given one example, which is clearly permitted, and another which is clearly not. Your question is about a setup which is somewhere between those two extremes. It would be nice with an official response about where that line is drawn. There are two questions that seem important in answering the question about which side of the line you are on:
- Do you have a tunnel to the tunnel server?
- Are you advertising the addresses through BGP?
If the answer to those questions are, yeas you do have the tunnel, and no you are not advertising the prefix through BGP, then I cannot think of a reason for HE to say you are on the wrong side of the line.
The traffic that goes through the peering would never touch any of HE's systems, and as such I'd say it should be outside of the scope of the agreement. And apart from the one sentence mentioned above, I couldn't find anything in the terms that would apply to your setup.
I don't know if you would intend to use BGP for your peerings, and I think HE will consider that important. Even if you don't intend those prefixes to leak outside of your peering, there is always a risk of that happening by accident.
Thank you for the great summation!
Quote from: kasperd on June 05, 2012, 02:25:40 AMSo I have given one example, which is clearly permitted, and another which is clearly not. Your question is about a setup which is somewhere between those two extremes. It would be nice with an official response about where that line is drawn. There are two questions that seem important in answering the question about which side of the line you are on:- Do you have a tunnel to the tunnel server?
- Are you advertising the addresses through BGP?
My HE tunnel will always stay. If I get international transit through someone else, I'll renumber into their range.
As for BGP, I'd guess that some of the ISPs will definitely be exchanging prefixes with it, or some other routing protocol.
Quote from: acrg on June 05, 2012, 10:23:12 AMAs for BGP, I'd guess that some of the ISPs will definitely be exchanging prefixes with it, or some other routing protocol.
An ISP that does not make use of BGP seems somewhat unlikely. The question is, would any of the HE prefixes be announced over BGP? Would they be announced with some other routing protocol, that could potentially be fed into BGP? How exactly do you intend to setup the peerings in the first place?
Would the individuals, who take part in such peerings with address space from a tunnel provider, be running any BGP sessions? Or do they register a static peering configuration with ISPs? Are the peerings going to be physical links or 6in4 tunnels? (The last questions probably isn't important policy-wise, but it may help understand what kind of setup you have in mind)
Quote from: kasperd on June 05, 2012, 02:49:54 PM
The question is, would any of the HE prefixes be announced over BGP?
I think BGP is a bit of a loaded term. On the one hand, it's just a routing protocol. Local ISPs here will be using it to announce routes to each other across private and public peering points. On the other hand, it's also the routing protocol from which the global routing table is built by carriers. The intention is not to announce any HE prefixes to the global routing table. If that were to happen by accident, it would be considered an error and rectified. The ISPs in question are trying to do this for free for the sake of more efficient routing, not to provide free intl transit.
Quote from: kasperd on June 05, 2012, 02:49:54 PMHow exactly do you intend to setup the peerings in the first place?
I'm just one player so I can't speak for everyone else, but I would use a 6in4 tunnel to a local ISP here and collect other local prefixes by whatever means they prescribe while keeping my v6 default route via my HE tunnel.
Quote from: kasperd on June 05, 2012, 02:49:54 PMWould the individuals, who take part in such peerings with address space from a tunnel provider, be running any BGP sessions?
Some will, some won't. In the case of a local ISP providing someone with both address space and intl transit, a BGP session wouldn't be relevant.
Quote from: kasperd on June 05, 2012, 02:49:54 PMAre the peerings going to be physical links or 6in4 tunnels?
Both.
Quote from: acrg on June 07, 2012, 01:05:42 AMThe intention is not to announce any HE prefixes to the global routing table. If that were to happen by accident, it would be considered an error and rectified. The ISPs in question are trying to do this for free for the sake of more efficient routing, not to provide free intl transit.
That's also the impression I had all along. Even nobody intend to route them to the global routing table in your setup, there is always a risk that it can happen by mistake. I won't try to asses that risk neither how much it grows by using BGP for both purposes. This risk is the only reason I can think of that HE could have for saying no.
The ISPs shouldn't be announcing those prefixes upstream. Taking prefixes from a peer and announcing them to your upstream just doesn't make sense economically. Additionally the upstreams of those ISPs should have filters in place, that would filter those routes even if they did leak by accident. Finally if both companies screw up and the routes do leak, the packets will still end up on the same network eventually as they would have done in the first place. So personally, I don't see any significant risk.
To me what you want to do sounds fine, but I have no authority to give you an official answer. If you want an official answer, you should probably send an email to ipv6@he.net and ask for it, as it doesn't seem like any official answer is going to be posted to this thread without asking for it. I think this thread already contains sufficient information about the intended usage to base an answer on.
I should mention that I sell a product, which can do something similar to what you intend to do, although I do not make any use of BGP whatsoever. So I will be paying attention to any answers.
Quote from: kasperd on June 07, 2012, 03:58:44 AMsend an email to ipv6@he.net
Done, and the response is "not allowed."
Quote from: acrg on June 08, 2012, 11:13:12 AMDone, and the response is "not allowed."
That's not a very detailed answer. I still don't know where they draw the line between what is permitted and what is not permitted.
It isn't that complicated. HE doesn't want tunnel users to go start announcing specific chunks of HE's IPv6 allocation randomly at wild on the internet.
If this "private peering" and announcement of address space isn't intended for public use let alone the global routing table, THEN USE ULA or get your own RIR allocation.
Would you go use Google's IPv6 allocations for this? No, so why would you use HE's.
Quote from: broquea on June 08, 2012, 02:18:55 PMIf this "private peering" and announcement of address space isn't intended for public use let alone the global routing table, THEN USE ULA or get your own RIR allocation.
You don't seem to understand the intent. The intent is that the different parties who have IPv6 addresses from different sources and have AAAA records pointing at their servers can communicate efficiently with each other.
Assigning ULA addresses is not going to help. As long as the AAAA records are pointing at public addresses, those addresses are what is going to be used for the actual communication. And putting ULA addresses in AAAA records supposed to be reachable by the entire Internet is not going to work well.
I can understand if HE don't want users to announce their assigned prefix through BGP or other routing protocols. It would be a perfectly sensible policy, however I have not seen any official statement saying that this is what the policy says. The wording in the terms is open for interpretation. It didn't say BGP.
Getting your own RIR allocation is a perfectly valid response for ISPs involved in such peerings. But for individuals I am not sure if it is feasible to do so at a reasonable price. You both need to pay to the RIR for the allocation, and you'll need for an upstream to provide you transit. I know HE has some tunnels with BGP support as well, I haven't checked if those are free and whether they offer transit. And I haven't checked how much it costs for an individual to get an allocation from a RIR. But it sounds a lot more expensive and a lot more complicated.
If announcing routes is what is not allowed by the policy, then there are ways to achieve roughly what acrg asked for without announcing any routes at all, thus achieving roughly the same end result without violating the policy.
Suffice to say it falls under a policy of common sense and netiquette when it comes to using temporarily allocated ranges from someone else's address space. The tunnels can be revoked at any time as explained in the TOS/AUP and other reasons perhaps not covered but easily explained if you email ipv6@he.net (like general asshattery on IRC as an easy valid example). If you want a network you already communicate with over IPv4 (local region) to see you over IPv6 via tunnels you set up directly with them, then why would you use 2001:470:xxxx::/48 versus fd01:470:xxxx::/48, if only to force them to either set connected/static routes for specifics to a chunk of HE range that they already learn from peers/upstreams? What I read in the OP's post is they are located in a region without a local tunnel-server, want to avoid a RTT nightmare via US/EU, to communicate with other local people/networks via 6in4 tunnels (let us assume p41). You don't need to use HE's address space to solve that. However if they still want real world connectivity, then they can set up something like an IPv6 firewall/nat66 that handles the transport between ULA and globally routed space. What happens when it all gets town down at the HE tunnel side, and then all those networks now have static routes pointing to an invalid path, and someone else creates a tunnel with that range? They become unreachable to anyone sitting behind that setup.
Quote from: broquea on June 08, 2012, 04:26:35 PMIf you want a network you already communicate with over IPv4 (local region) to see you over IPv6 via tunnels you set up directly with them, then why would you use 2001:470:xxxx::/48 versus fd01:470:xxxx::/48
Because you don't want ULA addresses in AAAA records that are served not only to your peers, but to all of the world. And because the client doing source address selection for a TCP connection won't know that the public IPv6 address it is connecting to is routed through a peering and thus a ULA address will work.
What is going to happen if you set up a peering using ULA addresses like you mentioned is that it is not going to be used at all. Let's say both client and server have public and ULA addresses, only the public address of the server is in DNS records. Thus the client will connect to the public address. The client doesn't know about routing and by connecting to a public address it should prefer to use its own public address. Thus none of the packets being sent will have a ULA destination address, and the routing table entries for the ULA addresses will not match any packets.
Quote from: broquea on June 08, 2012, 04:26:35 PMHowever if they still want real world connectivity, then they can set up something like an IPv6 firewall/nat66 that handles the transport between ULA and globally routed space.
Frankly I think they'd rather stay with IPv4 than deploying IPv6 in a way that requires that sort of NAT.
Quote from: broquea on June 08, 2012, 04:26:35 PMWhat happens when it all gets town down at the HE tunnel side, and then all those networks now have static routes pointing to an invalid path, and someone else creates a tunnel with that range? They become unreachable to anyone sitting behind that setup.
That's a valid concern. But I still don't know where to draw the line, and the terms don't say.
Assume I have a router with a route to ::/0 through my tunnel to HE, a route to 2002::/16 that automatically sends directly to the appropriate IPv4 address, a route to 2001::/32 that sends to my own Teredo relay, and routes to 2001:db8:123::/64 and fd91:3022:179a::/64 that were configured in a way that was completely unrelated to my HE tunnel. Am I violating the terms if my router uses one of those more specific routes for a packet that has a source IPv6 address from within the address space assigned to me by HE? Or is it fine as long as I don't advertise the HE IPv6 addresses and let packets coming back to me take the standard route?
QuoteBut I still don't know where to draw the line, and the terms don't say.
You don't have to draw the line, HE.NET does. If you are uncertain about specific or a randomly generated set of circumstances YOU ASK HE.NET. I promise they will reply, maybe not with a diatribe about their reasoning, but them saying yes/no with regards to their address space and services should be the final word on the matter. You can wish and hope for detailed explanations, but in the end a free service isn't obligated to provide one despite people's sense of entitlement.
QuoteAssume I have a router with a route to ::/0 through my tunnel to HE, a route to 2002::/16 that automatically sends directly to the appropriate IPv4 address, a route to 2001::/32 that sends to my own Teredo relay, and routes to 2001:db8:123::/64 and fd91:3022:179a::/64 that were configured in a way that was completely unrelated to my HE tunnel. Am I violating the terms if my router uses one of those more specific routes for a packet that has a source IPv6 address from within the address space assigned to me by HE? Or is it fine as long as I don't advertise the HE IPv6 addresses and let packets coming back to me take the standard route?
The tunnel-server has RPF upstream of it and will not let improperly sourced IPs get past (this was true when I left, and appears to remain so after testing with someone else that found Comcast doesn't have upstream RPF for residential native IPv6 as of this writing). If 6to4 and teredo relays are letting you source HE.NET space and traverse them and returning back down your HE.NET tunnel, THEN THOSE RELAYS ARE IMPROPERLY CONFIGURED. That is no fault of your own, but rather the relay operators (assuming not you, if it is you, then yes you are at fault but it's OK, you'll fix it :)). That kind of issue needs to be reported to both HE.NET and the relay operator.
Quote from: broquea on June 08, 2012, 05:23:45 PMIf 6to4 and teredo relays are letting you source HE.NET space and traverse them and returning back down your HE.NET tunnel, THEN THOSE RELAYS ARE IMPROPERLY CONFIGURED.
I believe you are mistaken. As far as I am aware it is perfectly valid according to the standards to announce 2002::/16 and 2001::/32 and relay packets without knowing which source addresses packets will be arriving from. If you believe otherwise, please point to a relevant RFC supporting it.
http://tools.ietf.org/html/rfc3704 comes to mind as well as BCP38. Swap out IPv4 for IPv6 regarding this convo.
I didn't find any mention of 6to4 or Teredo relays in those documents.
If you think your asymmetric routing is correct, then when your HE.NET tunnel is down, your routing is broken even more so than just those relays violating the RFC and BCP for proper routing of address space. You want something 6to4 or teredo specific, but this isn't about those particular tunneling protocols themselves, it's about the actual relay router processing the src/dst packets, and not deciding "Hey, I only handle 2002::/16 via this interface, this 2001:470::/32 shouldn't be accepted inbound from it, only 2002::/16."
So I'll put it to you then, show the RFC/BCP that specifically states that either the 6to4 or teredo PROTOCOL calls for an exception and allows the relays/routers to accept packets from any and all source address and fling them out into the internet. I already provided the RFC/BCP for routing policy that clearly explains why you don't accept any IPv4/6 address as source on an interface configured for a specific range.
Generally we do not want the address space handed out by the tunnel broker to be used in the manner described by the OP. We do appreciate him asking us ahead of time and checking with us since it's an unusual requested use of the address space.
As a rule of thumb, the space handed out is meant to be used for a single network as a stub. When more complicated routing gets introduced, we strongly suggest that the networks involved speak to their RIR to get a delegation directly to them to prevent a lot of trouble down the road. We will even happily setup a BGP session and provide service for their new delegation if they contact ipv6@he.net. This is the preferred method.
For the Teredo / 6to4 discussion; RPF is meant to prevent abuse. While it's perfectly possible to accept traffic from a source "interface" that does not have a return path, in practice it's not a wise thing to do. Our use of RPF on those servers is a direct result of observed abusive traffic.
Also like to point out that Teredo and 6to4 are meant to be "last chance" connectivity for IPv6. All up to date OSes are configured to use everything else possible first before attempting connectivity on a 6to4 or Teredo IP. Unless the client is misconfigured or (more likely in our observations) maliciously configured, it should never be sending those packets to a relay if it has a normal globally routable IPv6 address as well.
Quote from: broquea on June 08, 2012, 06:40:47 PMit's about the actual relay router processing the src/dst packets, and not deciding "Hey, I only handle 2002::/16 via this interface, this 2001:470::/32 shouldn't be accepted inbound from it, only 2002::/16."
Are you talking about the source or the destination address?
Normal packets going through a 6to4 relay router has either the source address being a 6to4 address or the destination address, but never both. Routing between 6to4 and non-6to4 hosts is inherently asymmetric. Even if all the relays would route traffic in both directions it is still unlikely that traffic would go through the same relay in both directions, and it is entirely plausible that a relay that would otherwise have routed traffic in both directions just doesn't get to route traffic in more than one direction because it all flows a different way in the other direction.
A relay router can advertise either 2002::/16 or 192.88.99.1/24 or both, and how far the advertisements propagate is a matter of policies. They can be for a single LAN in which case a routing protocol may not even be necessary, or they can be propagated through BGP to the entire world.
When discussing by which rules a 6to4 relay operates we need to be specific about which direction of packets we are talking about, as they are separate issues handled by two different routers. What I am talking about is only the case of a 6in4 router having built in a 6to4 relay responsible for one stub network. Regardless of whether the router has any 6to4 relay capabilities or not, packets are routed to this router in the same way. In the end it is just a question of which source and destination IPv4 address it puts on the protocol 41 packets it is sending.
There may be filtering to ensure that the source IPv6 address is valid for the interface it arrived on. That part is already taken care of, what I am talking about is how the router routes the packets when it has already ensured the source address is valid. The source address may be a 6to4 address, but those packets are completely outside the scope of the terms of usage for the HE tunnel, assuming that they don't go through the tunnel to HE. The source address may be a public IPv6 address assigned by somebody other than HE, those are also outside the scope of the terms, again assuming they don't go through that tunnel.
What is left to discuss is only packets from the LAN where the source IPv6 address is in the range assigned by HE, and the router has already established that the source address is valid. The default route is obviously the one going down the tunnel. The question is, are the terms supposed to forbid having any more specific routes available on this router? And in this case specifically the 2002::/16 route, which a 6to4 relay would have.
If the router does act as 6to4 relay router for the stub network, then packets with destination address in 2002::/16 won't go to HE, rather they will go directly to the IPv4 address corresponding to the destination IPv4 address. And there is really no doubt about where a relay router is supposed to send the packets. The only question is whether HE users are allowed to have a 6to4 relay configured to service their own stub network. I know of multiple HE users, who do.
I think this is not at all what you were talking about. Your statement sounds like something that something which was meant for ingress filtering, while in fact the question was about the routing that happens after any ingress filtering has been applied.
Quote from: mtindle on June 08, 2012, 08:36:04 PMAlso like to point out that Teredo and 6to4 are meant to be "last chance" connectivity for IPv6. All up to date OSes are configured to use everything else possible first before attempting connectivity on a 6to4 or Teredo IP.
Avoiding 6to4, yes many systems do. Avoiding Teredo, not so much. 6to4 tends to be more reliable than Teredo, yet systems seem to prefer using Teredo rather than 6to4. Also in case somebody had the crazy idea of running a server on a Teredo address clients given the choice between using their own native IPv6 address or their own Teredo address will tend to use the Teredo address when connecting to said server. That in spite of the fact that Teredo to Teredo communication is what Teredo is worst at doing.
QuoteAre you talking about the source or the destination address?
I was pretty clear in explaining that this was a matter of IPv6 source addresses being transported over the incorrect path/interface:
QuoteThe tunnel-server has RPF upstream of it and will not let improperly sourced IPs get past...If 6to4 and teredo relays are letting you source HE.NET space and traverse them and returning back down your HE.NET tunnel [then the relays are misconfigured]
QuoteGiant wall of text that appears to not be relevant to you stating that 6to4/teredo relays should accept traffic sourced from your HE address space: QuoteAs far as I am aware it is perfectly valid according to the standards to announce 2002::/16 and 2001::/32 and relay packets without knowing which source addresses packets will be arriving from.
BGP announcements are irrelevant to the relay absolutely knowing that on its 6to4 interface, source IPv6 address packets should be from 2002::/16. The RFC/BCP I pointed out is about making certain that there is a proper routing policy in place to stop improperly sourced IPv6 address packets from being retransmitted by the relay.
Now, you had described a setup using HE tunnel + address space and using that tunnel for default route, and then configuring a specific 6to4 route, and a specific teredo route, and that you posed a question about violating tos/aup. My point was that it isn't a tos/aup violation issue but rather neither the 6to4 or teredo relay should be configured to allow that HE IPv6 address sourced packet any father than having received it over either the 6to4 or teredo interface. It should be discarded right there. That relay isn't getting a 6to4 or teredo IPv6 address sourced packet.
QuoteThere may be filtering to ensure that the source IPv6 address is valid for the interface it arrived on. That part is already taken care of
There should be, but when you talked about you sourcing from HE IPv6 address space and sending out along your specific 6to4 route and that being valid, you are contradicting yourself.
QuoteThe question is, are the terms supposed to forbid having any more specific routes available on this router? And in this case specifically the 2002::/16 route, which a 6to4 relay would have.
The terms absolutely won't forbid you from configuring specific routes to remote destinations, that is silly, no one would expect that. However if you are going to communicate with 6to4 hosts from your HE IPv6 address space, the interface that traffic should go out is your HE tunnel, not a 6to4 interface or static route to ::192.88.99.1 configured on the router (because that relay should be filtering IPv6 source addresses on its 6to4 interface, my entire point).
Quote...the question was about the routing that happens after any ingress filtering has been applied.
You source a packet from an address in 2001:470::/32 destined for something in 2002::/16 and send it out to the 6to4 relay via the specific 6to4 route you said you created --> relay gets the packet, strips the encapsulation (assuming your static route was to ::192.88.99.1), sees that it isn't sourced from 2002::/16 and applies ingress filtering --> this is what happens after that ingress filtering: nothing, packet discarded, wasn't sourced from 2002::/16.
Quote from: broquea on June 09, 2012, 10:04:51 AMBGP announcements are irrelevant
Agreed. In my case there wouldn't even be any BGP announcements.
Quote from: broquea on June 09, 2012, 10:04:51 AMthe relay absolutely knowing that on its 6to4 interface, source IPv6 address packets should be from 2002::/16.
None of what I wrote was concerned with such packets. You keep talking about something else than me. I don't know how to explain that I am talking about packets going in the
other direction. I have explained that a few different ways already, but I don't seem to be getting that point through.
Quote from: broquea on June 09, 2012, 10:04:51 AMThe RFC/BCP I pointed out is about making certain that there is a proper routing policy in place to stop improperly sourced IPv6 address packets from being retransmitted by the relay.
By now you have convinced me that the document is not relevant to what I was asking about.
Quote from: broquea on June 09, 2012, 10:04:51 AMyou talked about you sourcing from HE IPv6 address space and sending out along your specific 6to4 route and that being valid, you are contradicting yourself.
No. You are making some incorrect assumptions about what I am trying to say, and then say I am contradicting myself, once I say something different from what you assumed.
Packet in question is sent from an HE IPv6 address to a 6to4 address. There is nothing in the terms that forbids using an HE IPv6 address from communicating with 6to4 addresses. Now the question is how that packet gets routed to the destination. The router will check the
source address and find that it arrived from the LAN and has a
source address within the range assigned by HE to this network, thus the
source address is valid.
Next the router checks the
destination address of the packet against its routing table, and in this case match a route to 2002::/16, which causes the router to act as 6to4 relay and extract the IPv4 address from the
destination address and send the IPv6 packet to that IPv4 address.
Quote from: broquea on June 09, 2012, 10:04:51 AMThe terms absolutely won't forbid you from configuring specific routes to remote destinations, that is silly, no one would expect that.
I was expecting this to be permitted by the terms. And I was considering this to be obvious enough that I shouldn't even have to read the terms to know if it is permitted. However I did ask, and you said there was supposed to be filters preventing it.
Quote from: broquea on June 09, 2012, 10:04:51 AMHowever if you are going to communicate with 6to4 hosts from your HE IPv6 address space, the interface that traffic should go out is your HE tunnel, not a 6to4 interface or static route to ::192.88.99.1 configured on the router (because that relay should be filtering IPv6 source addresses on its 6to4 interface, my entire point).
Sending such packets to 192.88.99.1 would be pointless. Sending such packets through the tunnel is what is most routers would do. However there is another option, which is for the router to send it directly to the IPv4 address extracted from the destination IPv6 address. I believe such functionality is standard in some routers, at least I have seen multiple HE users with a router, which would behave like that.
Quote from: broquea on June 09, 2012, 10:04:51 AMassuming your static route was to ::192.88.99.1
That assumption is incorrect. I don't know what would happen to the packet if I did send it like that. Rather the router would either be able to extract the IPv4 address of the final destination and send it directly there, which is what a 6to4 relay router will do with such a packet, or I could route it to another node that I control (using 6in4 or native connectivity) and have that node figure out the destination IPv4 address.
QuoteNext the router checks the destination address of the packet against its routing table, and in this case match a route to 2002::/16, which causes the router to act as 6to4 relay and extract the IPv4 address from the destination address and send the IPv6 packet to that IPv4 address.
No, sorry, a router doesn't just decide to suddenly become a 6to4 relay. You either have specifically configured a router to be a 6to4 relay, or it routes the packets to the nearest node announcing 2002::/16 over native IPv6. Having deployed actual production 6to4/teredo relays used by folks everywhere, I can promise you nothing just magically happens on the router. It needs to be configured to perform the task.
It would be awesome if all this started off with a less vague notion of "HE tunnel + 6to4 specific route + teredo specific route", and had actual example routing statements and configurations. I think the convo would have ended like 9 posts ago :)
Quote from: broquea on June 09, 2012, 12:54:05 PMNo, sorry, a router doesn't just decide to suddenly become a 6to4 relay. You either have specifically configured a router to be a 6to4 relay
For a 6in4 endpoint it is a trivial task to act as 6to4 relay for any packets it would have routed through the tunnel. If the tunnel endpoint is implemented in C, it can be done with just two lines of code:
if ((IPv6_header[24] == 0x20)&&(IPv6_header[25] == 2)) {
memcpy(IPv4_header+16, IPv6_header+26, 4);
}I don't know which products on the market would do so by default. I know of people who have used such a setup with HE, but I don't know whether those people had to configure it manually, or if they were using a router that did it automatically. I have send a message to one of those users asking how much work it was to set up the 6to4 relay.
Quote from: broquea on June 09, 2012, 12:54:05 PMor it routes the packets to the nearest node announcing 2002::/16 over native IPv6.
But that doesn't have to mean through the tunnel to HE. There could be a 6to4 relay located on the same LAN. Though if you do want to have a 6to4 relay on the same LAN, it makes more sense to let the 6in4 gateway be the 6to4 relay as well.
Quote from: broquea on June 09, 2012, 12:54:05 PMHaving deployed actual production 6to4/teredo relays used by folks everywhere, I can promise you nothing just magically happens on the router. It needs to be configured to perform the task.
I don't think you have worked with every single kind of CPE equipment that HE users might use as their 6in4 tunnel endpoint, so I'd say you cannot know if there are some of them which will do so automatically when configured to work as 6in4 endpoint.
Of course a router that is not a 6in4 endpoint may not even have IPv4 connectivity, and obviously such a router shouldn't act as 6to4 relay automatically. But I can promise you, there are routers around that magically does things with 6in4 packets, which makes no sense. My ISP actually has one that under some circumstances will decapsulate the 6in4 packets I send to HE such that the packets will enter the IPv6 network in a different location from what was expected and take an entirely different route, which may never touch the HE network. Luckily this has never happened to the return traffic, otherwise the packets would have entered a routing loop on the way to me.
Quote from: broquea on June 09, 2012, 12:54:05 PMIt would be awesome if all this started off with a less vague notion of "HE tunnel + 6to4 specific route + teredo specific route", and had actual example routing statements and configurations.
I don't think it would have helped much to show you a configuration file for an IPv6 stack that you have never seen. Instead I explained exactly what it would do.
I said the route to 2002::/16 would send it to the appropriate IPv4 address. I thought everybody on this forum would know that means using the third through the sixth octet of the destination IPv6 address as the destination IPv4 address.
I also said the route to 2001::/32 would route the traffic to my own Teredo relay. That's just an instance of miredo configured to work as relay. I didn't think it was important to state that it is a miredo instance, but I can post the configuration for that if it is any help to the discussion.