6 Jun
2011
6 Jun
'11
2:17 p.m.
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
6 Jun
6 Jun
2:24 p.m.
New subject: Experience with 6rd Hardware
On 2011-Jun-06 14:17, Oliver Schad wrote:
Am Monday 06 June 2011 schrieb mir Adrian Kägi:
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
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.
2:38 p.m.
New subject: Experience with 6rd Hardware
Am Monday 06 June 2011 schrieb mir Jeroen Massar:
On 2011-Jun-06 14:17, Oliver Schad wrote:
In short: they are not compatible.
Regards
Oli
Am Monday 06 June 2011 schrieb mir Adrian Kägi:
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. 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.
3:25 p.m.
New subject: Experience with 6rd Hardware
On 2011-Jun-06 14:38, Oliver Schad wrote:
Am Monday 06 June 2011 schrieb mir Jeroen Massar:
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
On 2011-Jun-06 14:17, Oliver Schad wrote:
In short: they are not compatible. Am Monday 06 June 2011 schrieb mir Adrian Kägi:
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. 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. 
3:44 p.m.
New subject: Experience with 6rd Hardware
2011/6/6 Jeroen Massar <jeroen(a)unfix.org>rg>:
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
3:49 p.m.
New subject: Experience with 6rd Hardware
On 2011-Jun-06 15:44, Guillaume Leclanche wrote:
2011/6/6 Jeroen Massar <jeroen(a)unfix.org>rg>:
And why would I be that?
Greets,
Jeroen
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 ? :)
4:03 p.m.
New subject: Experience with 6rd Hardware
2011/6/6 Jeroen Massar <jeroen(a)unfix.org>rg>:
On 2011-Jun-06 15:44, Guillaume Leclanche wrote:
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
2011/6/6 Jeroen Massar <jeroen(a)unfix.org>rg>:
And why would I be that? 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 ? :)
4:08 p.m.
New subject: Experience with 6rd Hardware
On 2011-Jun-06 16:03, Guillaume Leclanche wrote:
2011/6/6 Jeroen Massar <jeroen(a)unfix.org>rg>:
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.
On 2011-Jun-06 15:44, Guillaume Leclanche wrote:
Well let's say that was a reference to the work done by sixxs with the
ULA repository. 2011/6/6 Jeroen Massar <jeroen(a)unfix.org>rg>:
And why would I be that? 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 ? :) 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
4:18 p.m.
New subject: Experience with 6rd Hardware
2011/6/6 Jeroen Massar <jeroen(a)unfix.org>rg>:
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
4:46 p.m.
New subject: Split-horizon addressing (Was: Experience with 6rd Hardware)
On 2011-Jun-06 16:18, Guillaume Leclanche wrote:
2011/6/6 Jeroen Massar <jeroen(a)unfix.org>rg>:
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.
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 :)
Right, because like we have not been doing IPv6 tunneling for about 18
years already... and so much went native.
Greets,
Jeroen
5:57 p.m.
New subject: Split-horizon addressing (Was: Experience with 6rd Hardware)
2011/6/6 Jeroen Massar <jeroen(a)unfix.org>rg>:
On 2011-Jun-06 16:18, Guillaume Leclanche wrote:
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.
2011/6/6 Jeroen Massar <jeroen(a)unfix.org>rg>:
So did you try the above out? Because if you did you would find the
following minor problems: 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). - 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.
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
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.
3:55 p.m.
New subject: Experience with 6rd Hardware
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
4 p.m.
New subject: Experience with 6rd Hardware
On 2011-Jun-06 15:55, Oliver Schad wrote:
Am Monday 06 June 2011 schrieb mir Jeroen Massar:
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
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.
5:13 p.m.
New subject: Experience with 6rd Hardware
Am Monday 06 June 2011 schrieb mir Jeroen Massar:
On 2011-Jun-06 15:55, Oliver Schad wrote:
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
Am Monday 06 June 2011 schrieb mir Jeroen
Massar:
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. 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.
4377
days inactive
4377
days old
13 comments
3 participants
participants (3)
-
Guillaume Leclanche -
Jeroen Massar -
Oliver Schad