Am Monday 06 June 2011 schrieb mir Adrian Kägi:
Thx for your replies! Wow! I see, there are tons of vendors! But when they support IPv6 or 6to4 IP6 Tunnel and so on... does they support the 6rd concept?
6to4 and 6rd are not the same and are not compatible. 6to4 has a given prefix while 6rd uses a prefix from the ISP to circumvent the case that a IPv6 packet which should be received by a 6to4 host never traverse a 6to4- gateway and so will never enter the IPv4 net.
In this case the packet will never reach the 6to4 host. There is no way to guarantee that a 6to4 gateway will ever traversed so this indeed a big weakness of 6to4.
Regards Oli
On 2011-Jun-06 14:17, Oliver Schad wrote:
Am Monday 06 June 2011 schrieb mir Adrian Kägi:
Thx for your replies! Wow! I see, there are tons of vendors! But when they support IPv6 or 6to4 IP6 Tunnel and so on... does they support the 6rd concept?
6to4 and 6rd are not the same and are not compatible.
Actually they are very similar, both use protocol-41.
The only differences between the two are how the prefix is calculated which is used for the tunnel endpoints and what the IPv4 address is of the remote tunnel endpoint.
Greets, Jeroen
Am Monday 06 June 2011 schrieb mir Jeroen Massar:
On 2011-Jun-06 14:17, Oliver Schad wrote:
Am Monday 06 June 2011 schrieb mir Adrian Kägi:
Thx for your replies! Wow! I see, there are tons of vendors! But when they support IPv6 or 6to4 IP6 Tunnel and so on... does they support the 6rd concept?
6to4 and 6rd are not the same and are not compatible.
Actually they are very similar, both use protocol-41.
The only differences between the two are how the prefix is calculated which is used for the tunnel endpoints and what the IPv4 address is of the remote tunnel endpoint.
In short: they are not compatible.
Regards Oli
On 2011-Jun-06 14:38, Oliver Schad wrote:
Am Monday 06 June 2011 schrieb mir Jeroen Massar:
On 2011-Jun-06 14:17, Oliver Schad wrote:
Am Monday 06 June 2011 schrieb mir Adrian Kägi:
Thx for your replies! Wow! I see, there are tons of vendors! But when they support IPv6 or 6to4 IP6 Tunnel and so on... does they support the 6rd concept?
6to4 and 6rd are not the same and are not compatible.
Actually they are very similar, both use protocol-41.
The only differences between the two are how the prefix is calculated which is used for the tunnel endpoints and what the IPv4 address is of the remote tunnel endpoint.
In short: they are not compatible.
On a Linux/*BSD box from 10 years ago you can configure both, for 6rd (which did not exist back then) you would just have to figure out the proper prefix, based on your IPv4 address, the IPv6 prefix and the relay address given by the provider, similarly for 6to4 you would based on 2002::/16 + IPv4 + relay. Oh and of course a normal static Protocol-41 tunnel which uses the IPv6 prefix given and a single remote tunnel endpoint.
They both speak protocol-41, they both do full IPv6 in there too, thus they are fully compatible also.
The only thing where it might not be compatible is the user interface for making it easy to configure them.
The fun and joy of 6rd is of course that your IPv6 prefix changes every time you get a new IPv4 address. With IPv4 and NAT this did not matter so much to the internal network, but now when your IP address changes you need to renumber your home network, the joys of that will be awesome for people selling consultancy services and the likes. (Just take a guess when NAT66 becomes standard because of that)
Greets, Jeroen
2011/6/6 Jeroen Massar jeroen@unfix.org:
The fun and joy of 6rd is of course that your IPv6 prefix changes every time you get a new IPv4 address. With IPv4 and NAT this did not matter so much to the internal network, but now when your IP address changes you need to renumber your home network, the joys of that will be awesome for people selling consultancy services and the likes. (Just take a guess when NAT66 becomes standard because of that)
Jeroen, I tought you were a lover of Unique Local Addresses, what happened to you ? :)
Guillaume
On 2011-Jun-06 15:44, Guillaume Leclanche wrote:
2011/6/6 Jeroen Massar jeroen@unfix.org:
The fun and joy of 6rd is of course that your IPv6 prefix changes every time you get a new IPv4 address. With IPv4 and NAT this did not matter so much to the internal network, but now when your IP address changes you need to renumber your home network, the joys of that will be awesome for people selling consultancy services and the likes. (Just take a guess when NAT66 becomes standard because of that)
Jeroen, I tought you were a lover of Unique Local Addresses, what happened to you ? :)
And why would I be that?
Greets, Jeroen
Am Monday 06 June 2011 schrieb mir Jeroen Massar:
The only thing where it might not be compatible is the user interface for making it easy to configure them.
While I agree to your point of view that 6rd and 6to4 are very close to each other and it shoudln't take much time to implement all necessary changes in user land and kernel it is still not compatible because you have to set the prefix.
So if you look for a CPE or whatever which supports 6to4 you can't conclude that it supports 6rd. That is what I mean. Remember, the OP was looking for boxes which supports 6rd and in this context he asked for 6to4.
And the answer is no, it isn't true, that support for 6to4 means support for 6rd.
Regards Oli
On 2011-Jun-06 15:55, Oliver Schad wrote:
Am Monday 06 June 2011 schrieb mir Jeroen Massar:
The only thing where it might not be compatible is the user interface for making it easy to configure them.
While I agree to your point of view that 6rd and 6to4 are very close to each other and it shoudln't take much time to implement all necessary changes in user land and kernel it is still not compatible because you have to set the prefix.
So if you look for a CPE or whatever which supports 6to4 you can't conclude that it supports 6rd. That is what I mean. Remember, the OP was looking for boxes which supports 6rd and in this context he asked for 6to4.
And the answer is no, it isn't true, that support for 6to4 means support for 6rd.
I did not state that, I did state that if you can configure a static protocol-41 tunnel, you can also configure a 6to4 and a 6rd one, just that you will have to do the prefix calculation yourself and not the easy way in the UI.
Greets, Jeroen
2011/6/6 Jeroen Massar jeroen@unfix.org:
On 2011-Jun-06 15:44, Guillaume Leclanche wrote:
2011/6/6 Jeroen Massar jeroen@unfix.org:
The fun and joy of 6rd is of course that your IPv6 prefix changes every time you get a new IPv4 address. With IPv4 and NAT this did not matter so much to the internal network, but now when your IP address changes you need to renumber your home network, the joys of that will be awesome for people selling consultancy services and the likes. (Just take a guess when NAT66 becomes standard because of that)
Jeroen, I tought you were a lover of Unique Local Addresses, what happened to you ? :)
And why would I be that?
Well let's say that was a reference to the work done by sixxs with the ULA repository.
But in the end my point was that ULA, not NAT66 is the answer to this situation (decoupling public from "private"). I did not understand why you mentionned NAT66 then.
Guillaume
On 2011-Jun-06 16:03, Guillaume Leclanche wrote:
2011/6/6 Jeroen Massar jeroen@unfix.org:
On 2011-Jun-06 15:44, Guillaume Leclanche wrote:
2011/6/6 Jeroen Massar jeroen@unfix.org:
The fun and joy of 6rd is of course that your IPv6 prefix changes every time you get a new IPv4 address. With IPv4 and NAT this did not matter so much to the internal network, but now when your IP address changes you need to renumber your home network, the joys of that will be awesome for people selling consultancy services and the likes. (Just take a guess when NAT66 becomes standard because of that)
Jeroen, I tought you were a lover of Unique Local Addresses, what happened to you ? :)
And why would I be that?
Well let's say that was a reference to the work done by sixxs with the ULA repository.
Providing a means for letting people solve a problem they think there might be does not imply any kind of love or even recommendation.
And to make that clearer: folks should get a statically allocated prefix out of the PA block from their provider, or if they care enough to setup proper routing etc get a PI prefix from a RIR.
But in the end my point was that ULA, not NAT66 is the answer to this situation (decoupling public from "private"). I did not understand why you mentionned NAT66 then.
ULA would still require NAT66 if you want those hosts to be able to communicate to the outside, unless of course you want to firewall your internal machines based on the global prefix and update those firewall rules and all other dependencies all the time when your prefix changes... (the prefix change is why I mention NAT66 as renumbering is not funny, anywhere).
Greets, Jeroen
2011/6/6 Jeroen Massar jeroen@unfix.org:
ULA would still require NAT66 if you want those hosts to be able to communicate to the outside, unless of course you want to firewall your internal machines based on the global prefix and update those firewall rules and all other dependencies all the time when your prefix changes... (the prefix change is why I mention NAT66 as renumbering is not funny, anywhere).
So, first of all we talk about sites that would have today a dynamic IPv4 address. That would be residential, mobile, and SOHO.
In the worst case, these sites can deal with LAN communication using ULA addresses, and then any public communication should be handled via public IPv6, which are at the moment all in 2000::/3, so clearly easy to identify and to put in a firewall. Readdressing the public addresses in the LAN is done easily with RAs, or DHCPv6-PD if the LAN is subdivided (an still in that case we've most likely left the normal SOHO, and we're in a bigger company that will have static v4 and most likely IPv6oE or in the home of a geek).
And finally, 6rd is a transition technology, and will be certainly removed in a few years to go to IPv6oE, once incompatible hardware will be phased out. Well, that's a wish, don't take it for granted :)
Guillaume
On 2011-Jun-06 16:18, Guillaume Leclanche wrote:
2011/6/6 Jeroen Massar jeroen@unfix.org:
ULA would still require NAT66 if you want those hosts to be able to communicate to the outside, unless of course you want to firewall your internal machines based on the global prefix and update those firewall rules and all other dependencies all the time when your prefix changes... (the prefix change is why I mention NAT66 as renumbering is not funny, anywhere).
So, first of all we talk about sites that would have today a dynamic IPv4 address. That would be residential, mobile, and SOHO.
In the worst case, these sites can deal with LAN communication using ULA addresses, and then any public communication should be handled via public IPv6, which are at the moment all in 2000::/3, so clearly easy to identify and to put in a firewall. Readdressing the public addresses in the LAN is done easily with RAs, or DHCPv6-PD if the LAN is subdivided (an still in that case we've most likely left the normal SOHO, and we're in a bigger company that will have static v4 and most likely IPv6oE or in the home of a geek).
So did you try the above out? Because if you did you would find the following minor problems:
- what updates the firewall rules that the internal host has it's global changed IPv6 address? Swapping out the first 64bits could work in theory, but might just break existing connections.
- how do you 'address' the internal services, everything goes by address or do you allow people to use hostnames? Who updates those hostnames, and does that hostname mean the internal one or the external address or both?
- when you have printer configured, and you take your laptop to the lake, and you want to print, does it use the internal address or the external one?
And then the other bunch of issues which effectively come down to a split-horizon view of a network. Folks are worried about IPv4+IPv6 fallback-connect issues as their browsers try both IPv6 and IPv4, be very worried when a host is both ULA and global though, which one to pick and when...
One of the biggest things with IPv6 which IPv4 does not allow for everyone on the world (as it works too with IPv4 if you got a large enough chunk of addresses) is that your address is globally unique, and thus you can keep on sending packets to that single address without issues. That concept breaks with ULA.
ULA is nice, it solves some problems, but it does not solve the problem when a host is also connected to a public network and does get a globally unique address through there. ULA does solve the problem when the network is not connected to anything else and you don't want to bother with getting a prefix for a private network.
And finally, 6rd is a transition technology, and will be certainly removed in a few years to go to IPv6oE, once incompatible hardware will be phased out. Well, that's a wish, don't take it for granted :)
Right, because like we have not been doing IPv6 tunneling for about 18 years already... and so much went native.
Greets, Jeroen
Am Monday 06 June 2011 schrieb mir Jeroen Massar:
On 2011-Jun-06 15:55, Oliver Schad wrote:
Am Monday 06 June 2011 schrieb mir Jeroen Massar:
The only thing where it might not be compatible is the user interface for making it easy to configure them.
While I agree to your point of view that 6rd and 6to4 are very close to each other and it shoudln't take much time to implement all necessary changes in user land and kernel it is still not compatible because you have to set the prefix.
So if you look for a CPE or whatever which supports 6to4 you can't conclude that it supports 6rd. That is what I mean. Remember, the OP was looking for boxes which supports 6rd and in this context he asked for 6to4.
And the answer is no, it isn't true, that support for 6to4 means support for 6rd.
I did not state that, I did state that if you can configure a static protocol-41 tunnel, you can also configure a 6to4 and a 6rd one, just that you will have to do the prefix calculation yourself and not the easy way in the UI.
Yes that's true.
But you can implement 6to4 without the possibility to support 6rd. The implementation can be compatible but it's not a must.
So maybe we have to different point of views what the term compatible means.
Regards Oli
2011/6/6 Jeroen Massar jeroen@unfix.org:
On 2011-Jun-06 16:18, Guillaume Leclanche wrote:
2011/6/6 Jeroen Massar jeroen@unfix.org:
ULA would still require NAT66 if you want those hosts to be able to communicate to the outside, unless of course you want to firewall your internal machines based on the global prefix and update those firewall rules and all other dependencies all the time when your prefix changes... (the prefix change is why I mention NAT66 as renumbering is not funny, anywhere).
So, first of all we talk about sites that would have today a dynamic IPv4 address. That would be residential, mobile, and SOHO.
In the worst case, these sites can deal with LAN communication using ULA addresses, and then any public communication should be handled via public IPv6, which are at the moment all in 2000::/3, so clearly easy to identify and to put in a firewall. Readdressing the public addresses in the LAN is done easily with RAs, or DHCPv6-PD if the LAN is subdivided (an still in that case we've most likely left the normal SOHO, and we're in a bigger company that will have static v4 and most likely IPv6oE or in the home of a geek).
So did you try the above out? Because if you did you would find the following minor problems:
No I did not do the test completely, but I've been in the process of seeing how to get things work together in a nice way over the last month. Details below.
- what updates the firewall rules that the internal host has it's
global changed IPv6 address? Swapping out the first 64bits could work in theory, but might just break existing connections.
If you've changed your IPv6 prefix, you will break existing connections anyway.
I think in IPv6 the firewall should be filtering what really has to be filtered, that is LAN stuff: netbios, mDNS, nfs, printing, etc. Such a stateless filter can be done simply by "in/out" interfaces without knowing the real IP addresses. You'd need the addresses to maintain a stateful filter (or want address-specific filters, but then again you can't do it better with NAT, where you use the Layer 4 ID to do port redirection). My personal opinion is that it's not necessary, but I admit that views can differ here.
- how do you 'address' the internal services, everything goes by
address or do you allow people to use hostnames? Who updates those hostnames, and does that hostname mean the internal one or the external address or both?
mDNS should kick in here. That's definitely the way to go for most deployments. Apple did a good job on that one, and it's fair to say that it's a well-thought technology. An mDNS responder should respond with the ULA address of a service (if available of course).
I agree that mDNS is in a developing state, and it's not all working as expected for IPv6.
- when you have printer configured, and you take your laptop to
the lake, and you want to print, does it use the internal address or the external one?
Corner case. If you do that, you start your VPN and you're in your LAN.
And then the other bunch of issues which effectively come down to a split-horizon view of a network. Folks are worried about IPv4+IPv6 fallback-connect issues as their browsers try both IPv6 and IPv4, be very worried when a host is both ULA and global though, which one to pick and when...
There's a major difference here. IPv4 vs IPv6 selection is left to the application, or if available, to a high level library with named based sockets.
ULA vs Global is left to the OS, which will do the selection following IETF standards. This means that applications don't have to be fixed.
One of the biggest things with IPv6 which IPv4 does not allow for everyone on the world (as it works too with IPv4 if you got a large enough chunk of addresses) is that your address is globally unique, and thus you can keep on sending packets to that single address without issues. That concept breaks with ULA.
No, ULA has to be used for LAN-LAN communications, and Global for internet communications. Each equipment should have both addresses. If this is not respected, and ULA is used as RFC1918 with NAT66, then the goal is not reached, and as you say, it doesn't make much sense.
ULA is nice, it solves some problems, but it does not solve the problem when a host is also connected to a public network and does get a globally unique address through there. ULA does solve the problem when the network is not connected to anything else and you don't want to bother with getting a prefix for a private network.
And finally, 6rd is a transition technology, and will be certainly removed in a few years to go to IPv6oE, once incompatible hardware will be phased out. Well, that's a wish, don't take it for granted :)
Right, because like we have not been doing IPv6 tunneling for about 18 years already... and so much went native.
The difference is that in the last year, big ISPs and big content providers have been busy activating it, so the comparison with the last 18 years, where it was a toy and research thing, is no longer relevant.
Guillaume
-
Guillaume Leclanche -
Jeroen Massar -
Oliver Schad