So as not to re-invent the wheel - if you are currently doing NAT64 in
production and are willing to share:
What software/hardware are you using?
Why?
TIA
Elliot
I need a cheat sheet.
nat64
6to4nat
6in4nat
etc...
-Hammer-
"I was a normal American nerd."
-Jack Herer
6to4 and 6in4 are not NAT. They're tunnels (VPNs) that allow two IPv6
nodes to talk to each other via an IPv4 backbone.
nat64 is NAT. It allows IPv6 endpoints to communicate with IPv4 endpoints.
nat44 is the IPv4 NAT you're used to.
nat444 is carrier NAT (translated once by the customer and once again
by the ISP, get it?)
A little better. So what's the difference between 6to4 and 6in4? Isn't 6in4
what HE uses?
-Hammer-
"I was a normal American nerd."
-Jack Herer
6in4 is IPv6 encapsulated in IPv4 = protocol 41, typically used in manual
tunnelling configuration and also in tunnel brokers and some other type of
tunnels.
6to4 is an automatic transition mechanism that uses 6in4 to automatically
create IPv6 tunnels using a special IPv6 prefix 2002::/16, appending the
IPv4 public address to obtain a /48 for each IPv4 public address. It works
very well for peer-to-peer, but it requires 6to4 relays for connecting to
end-sites using any other kind of IPv6 connectivity (anything not-6to4).
See:
http://www.ipv6tf.org/index.php?page=using/connectivity/6to4
Regards,
Jordi
I would be interested in this, too. Right now I am considering TAYGA
but would be interested in the experience of others.
George
From: Elliot Finley
Sent: Thursday, March 03, 2011 12:31 PM
To: nanog@nanog.org
Subject: Real World NAT64 deploymentsSo as not to re-invent the wheel - if you are currently doing NAT64 in
production and are willing to share:What software/hardware are you using?
Why?
TIA
Elliot
Ok, apparently there is NAT64 and there is NAT64. I don't believe the
poster was talking about a v6 load balancer VIP with v4 servers. I
think the OP is talking about the NAT64 portion of NAT64/DNS64 where
native v6 source and destination IPs are NATed to v4 destination and
source IPs for communicating with v4 resources from a v6 host.
But I might be projecting my own needs here. So, what kind of NAT64 are
we talking about?
George
I haven't used 6in4 so I couldn't tell you.
6to4 is a stateless tunnelling protocol. You have a dual-stacked
router. It has an IPv4 address, 1.2.3.4. Therefore it supports a 6to4
IPv6 network numbered 2002:0102:0304::/48. Somebody tries to send a
packet to 2002:0102:0304::1, it goes to a 6to4 router which
encapsulates the IPv6 packet in an IPv4 packet and sends it to
1.2.3.4.
6to4 is handy as a toy or for experimenting, but it relies on a loose
network of generous volunteers who, while generous, are neither
generous nor numerous enough to support production traffic.
-Bill
Ok, apparently there is NAT64 and there is NAT64. I don't believe the
poster was talking about a v6 load balancer VIP with v4 servers. I
think the OP is talking about the NAT64 portion of NAT64/DNS64 where
native v6 source and destination IPs are NATed to v4 destination and
source IPs for communicating with v4 resources from a v6 host.But I might be projecting my own needs here. So, what kind of NAT64 are
we talking about?George
You are correct. I'm talking about the NAT64 portion of NAT64/DNS64.
Elliot
Any ISP that is delivering IPv6 to their clients would be insane
to not run a 6to4 relays for return traffic to 2002::/16.
Mark
There's no assurance that the content provider will use the ISP's 6to4
relay. In fact, there's a good chance it won't use the ISP's 6to4 relay for
return traffic.
Frank
More accurately:
NAT44 is consumer NAT you're used to.
LSN/CGN is NAT at the carrier level.
DS-LITE is native IPv6 with private IPv4 tunneled over IPv6 to reach
an LSN/CGN for IPv4 connectivity.
NAT444 is NAT44 + LSN/CGN
Owen
HE uses 6in4. 6in4 is basically the same protocol as 6to4, but, with defined
end-points for point-to-point tunneling packets from multipoint to multipoint.
6to4, conversely, uses anycast to identify the tunnel exit point towards the
IPv6 network or to identify the tunnel entry point towards the IPv4 segment.
It depends on encoding the IPv4 address of the local encapsulating host
sending the packet inside of the IPv6 source address in order to be able
to identify the IPv4 destination after encapsulation. For 6to4, one end is
almost always a single specific host which both generates the packets
and does he IPv4 encapsulation.
Owen
> 6to4 is handy as a toy or for experimenting, but it relies on a loose
> network of generous volunteers who, while generous, are neither
> generous nor numerous enough to support production traffic.Any ISP that is delivering IPv6 to their clients would be insane
to not run a 6to4 relays for return traffic to 2002::/16.
Given the number of ISPs that will need to turn on IPv6 the next few
years, I believe the only conclusion here is that we'll see a large
number of "insane" ISPs ...
Steinar Haug, Nethelp consulting, sthaug@nethelp.no
Andrews & Arnold (http://aaisp.net.uk) have a NAT64 gateway which is
operated by a Firebrick 6202, IIRC.
As an ISP this is really for a handful of IPv6-only customers, but it
seems to be working well.
I've been considering the smaller Firebrick models (2700/2500) to do
something similar for IPv6-only connectivity to an army of older
Parallels Plesk installations, which of course Parallels has zero
intention of bringing up to date.
(Plesk 10.2 'preview' is floating about with IPv6 support -- it'll
likely take them another 3-4 releases before any of it works properly,
based on their performance to date.)
Tom
6to4 is an automatic transition mechanism
^ non-
which allows an end site to have horrible v6 pseudo-connectivity over a
provider who has not deployed ipv6
randy
Hi Randy,
I don't advocate for 6to4. I'm for dual-stack, even with IPv4 private
addresses and NAT, which is what we have today.
However, we like it or not 6to4 is there in many platforms, and the best
we can do is to deploy 6to4 relays in both sides, ISPs and content
providers. That will minimise the problem. I think some other folks in the
list already said it many times.
I think is much much much better having 6to4 and relays than nothing. Same
observations for Teredo.
Regards,
Jordi
So as not to re-invent the wheel - if you are currently doing NAT64 in
production and are willing to share:What software/hardware are you using?
Why?
Dogfooding.
http://en.wikipedia.org/wiki/Eating_your_own_dog_food
Simon
What about its integration in upstream software ?
The dns64 part is integrated in the newly released Bind 9.8 but I've not
seen any real information for the nat part in pf or iptables.
Could you enlighten us ?
What about its integration in upstream software ?
None of it is integrated yet.
The dns64 part is integrated in the newly released Bind 9.8
That's not our code. ISC made their own DNS64 implementation for Bind 9.8.
As for Unbound, everybody wants it merged. It's just a matter of
actually doing it.
but I've not
seen any real information for the nat part in pf or iptables.
Pf has changed a lot between OpenBSD 4.6 and 4.7. We will need to
updated our patch quite significantly.
As for iptables, it's a different story. Our code does not use the
regular conntrack NAT infrastructure. This is intentional. We wanted to
be 100% RFC-compliant, and the conntrack stuff is very un-compliant.
Because of this I doubt that it would be included upstream.
Simon