headers
Tore Anderson | 1 Apr 2011 10:04

Re: Using NAT64 in front of IPv6-only servers

Hi Gert,

* Gert Doering

> But it's similar to another approach we've been considering, which
> is "only dual-stack the load-balancers in front of the server farm,
> and single-stack the servers".  Dual-stacking the whole platform
> doesn't bring benefits but brings double work - as you said.

Indeed. That's the approach we took when retro-fitting IPv6 capability
to the existing IPv4-only platforms - the dual-stack topology ends at
the public access point - in some cases that's a load balancer, in some
cases a web cache, and in some cases a simple web server. All backend
networks for database and application server traffic remains IPv4-only
and I have no intention on using energy on changing that.

The approach works very well btw.

> Using a NAT64 here could have the advantage of "not having to 
> configure the IPv4 addresses on the load balancers" - and being 
> available for applications that do not already have load balancers
> in front of them.

Yep. For us it would also mean less dual-stack, because our load
balancers are usually found close to the servers (deeper in the
network), while such a NAT64 system could be at the very border of the
data centre.

> Since you're using the NAT64 in the "inverse direction", you're 
> effectively nullifying the benefits of "you get automatic mappings
(Continue reading)

Permalink | Reply | 3 comments |
headers
Gert Doering | 1 Apr 2011 10:10
Favicon

Re: Using NAT64 in front of IPv6-only servers

Hi,

On Fri, Apr 01, 2011 at 10:04:40AM +0200, Tore Anderson wrote:
> > Since you're using the NAT64 in the "inverse direction", you're 
> > effectively nullifying the benefits of "you get automatic mappings 
> > for everything you want to reach" (as the IPv4 space can be embedded 
> > in the IPv6 /96) - so it's "just" a destination-NAT that happens to 
> > be able to d-NAT into the other address family, and source-NAT v4->v6
> > while at it.
> 
> Precisely. That it operates in a stateless per-packet manner is
> crucially important, I do not under any circumstance want a stateful
> device between the public service entry point and the internet.

Oh, good point.  I completely missed that aspect.  

Indeed, if you run the NAT64 "in reverse", and s-NAT the v4 source 
into the NAT64-/96-mapped address, it should be able to completely run 
in a stateless way - so failover to a redundant box is completely 
trivial, nullifying Ted's counter-argument.

(Plus, it only needs to be in the packet path of ingress IPv4 packets
specifically destined to the web services, not in the packet path for 
IPv6 clients, or "other IPv4 traffic")

> That said, an the v6-only servers would probably also have access to a
> traditional NAT64/DNS64 system so that it could acquire security updates
> and such from the vendors' servers. But that would have to be a
> completely independent system with a different NAT64 prefix because it
> has to be a stateful device.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Leen Besselink | 1 Apr 2011 12:07

Re: Using NAT64 in front of IPv6-only servers

On 03/31/2011 09:04 PM, Martin Millnert wrote:
> Tore,
>
> On Thu, 2011-03-31 at 19:51 +0200, Tore Anderson wrote:
>> Hi list,
>>
>> I've been thinking a bit about how to go about deploying IPv6-only
>> applications in the data centre. I don't want to do dual-stack more
>> than necessary; after all, dual-stack means I have to do double work.
>> - Is anyone actually doing something like this already?
> http://sites.google.com/site/ipv6implementors/2010/agenda - check IPv6
> at Facebook.  It is definitely "something like this".
>
> Regards,
> Martin
>

Hi,

This is the 'same' presentation with video if you would prefer that:

http://nanog.org/meetings/nanog50/abstracts.php?pt=MTYzMyZuYW5vZzUw&nm=nanog50

I know nothing about the application(s) which you would like to
deployed, but if you will need protocols like FTP at a later stage, then
I'm afraid you could be out of luck.

That is just something to be aware of.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Smith | 1 Apr 2011 15:04

Re: DAD/tentative addresses vs system boot with network links down

(ok, so you asked for a bit of (maybe not completely thought through)
opinion - I wrote this a week or so ago)

Hi,

On Thu, 24 Mar 2011 16:42:19 +0100
Lutz Preßler <Lutz.Pressler <at> SerNet.DE> wrote:

> Hello,
> 
> the following problem occured on a Linux system with kernel 2.6.32
> (Debian squeeze) and is reproducible with older kernel versions.
> I haven't tested newer ones or other OSes yet.
> 
> If one
> - configures a static IPv6 address on some interface with normal
>   (giving "ip address add ADDRESS dev DEV") config mechanisms
> - uses this address in daemon configurations as "bind address"
> - boots the system with link of DEV down
> ... those daemons will fail to start.
> 
> The reason is, that an address is in state "tentative" until
> duplicate address detection can be completed - which is 
> (per definition?) not possible on an unavailable link.
> 
> The question is: who is at fault (this cannot be the intended
> high level behaviour), and what to do against it apart from having
> distribution mechanisms which try to start a daemon after a
> necessary address is available (don't know if systemd for linux
> is able to do this).
(Continue reading)

Permalink | Reply | 0 comments |
headers
William F. Maton Sotomayor | 1 Apr 2011 17:02
Picon

6to4 stats found, are there other places?


Folks,
 	Given the talk of moving 6to4 in the IETF to historic, I was told 
that it may be a good idea to share some stats of what one public 6to4 
relay in Canada is doing.  Originally this page was meant to get the 
institutions listed moving with IPv6 adoption, rather than languishing 
with tunnels and inviting (erroneous) criticism over IPv6.

 		http://stats.ottix.net/ipv6/

 	Does anyone else have public web pages of 6to4 stats that can be 
shared?  Data as well?

Thanks,

wfms
Permalink | Reply | 20 comments |
headers
Gavin McCullagh | 4 Apr 2011 15:45
Picon
Favicon

removing stateless auto-configured addresses/routes?

Hi,

I was just wondering, is there a convention for how and when an
autoconfigured IPv6 address should be disabled?  I imagine the address
should go away when the link drops?

When I plug my Debian Linux laptop into most of our networks, an IPv6
address is autoconfigured as expected.  However, if I disconnect, the
address persists.  If I then plug into another network, that address still
persists and if I try to connect to remote IPv6 hosts, the connection will
fail until I delete the stale address.

I'm going to report a bug, I'm just not clear who to yet.  The
network-manager on linux seems logical (as it does this job for IPv4) but
network-manager doesn't configure the IPv6 address (I guess the kernel
does?), so perhaps it's unfair to expect network-manager to remove it.

Many thanks for any suggestions.

Gavin
Permalink | Reply | 7 comments |
headers
Mikael Abrahamsson | 4 Apr 2011 16:27
Picon
Favicon

Re: removing stateless auto-configured addresses/routes?

On Mon, 4 Apr 2011, Gavin McCullagh wrote:

> I was just wondering, is there a convention for how and when an
> autoconfigured IPv6 address should be disabled?  I imagine the address
> should go away when the link drops?

Yes.

> When I plug my Debian Linux laptop into most of our networks, an IPv6
> address is autoconfigured as expected.  However, if I disconnect, the
> address persists.  If I then plug into another network, that address still
> persists and if I try to connect to remote IPv6 hosts, the connection will
> fail until I delete the stale address.

Correct.

> I'm going to report a bug, I'm just not clear who to yet.  The
> network-manager on linux seems logical (as it does this job for IPv4) but
> network-manager doesn't configure the IPv6 address (I guess the kernel
> does?), so perhaps it's unfair to expect network-manager to remove it.

I doubt you'll get much interest, in my opinion, what you describe hasn't 
been a focus for neither Debian nor Ubuntu. Anyhow, the connection manager 
needs to clear IPv6 address just like it clears the IPv4 address when the 
link goes down.

Ubuntu behaves exactly the same one, one might say they got IPv6 for free 
with the kernel and it seems nobody cares more than that. People have 
logged bug cases afaik, and even though the connection manager in Ubuntu 
10.10 nowadays seem to have IPv6 support (it has an ipv6 tab), so far I
(Continue reading)

Permalink | Reply | 6 comments |
headers
Simon Perreault | 4 Apr 2011 16:29
Picon
Favicon

Re: Using NAT64 in front of IPv6-only servers

On 2011-03-31 14:00, Ted Mittelstaedt wrote:
> And so when you put this nat64 in, your wicking all access to
> this redundant farm to a single, non-redundant nat64 box.

Our OpenBSD NAT64 implementation benefits from all of pf's features,
including redundancy (using carp and pfsync). So your argument does not
apply.

See here: http://ecdysis.viagenie.ca

Simon
--

-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca
Permalink | Reply | 0 comments |
headers
Gavin McCullagh | 4 Apr 2011 16:35
Picon
Favicon

Re: removing stateless auto-configured addresses/routes?

Hi,

On Mon, 04 Apr 2011, Mikael Abrahamsson wrote:

> I doubt you'll get much interest, in my opinion, what you describe
> hasn't been a focus for neither Debian nor Ubuntu. Anyhow, the
> connection manager needs to clear IPv6 address just like it clears
> the IPv4 address when the link goes down.

I've reported a bug myself

	https://bugzilla.gnome.org/show_bug.cgi?id=646703

but I'm not sure it's reasonable to expect network-manager to remove this
address given it didn't set it?  What happens where someone isn't using
network-manager?

I just wonder if the thing that configures the v6 address (the kernel,
right?) shouldn't also take responsibility for cleaning it up -- in which
case my bug is misplaced.

Gavin
Permalink | Reply | 5 comments |
headers
Bernhard Schmidt | 4 Apr 2011 16:45
Picon

Re: removing stateless auto-configured addresses/routes?

On 04.04.2011 16:35, Gavin McCullagh wrote:
> Hi,
> 
> On Mon, 04 Apr 2011, Mikael Abrahamsson wrote:
> 
>> I doubt you'll get much interest, in my opinion, what you describe
>> hasn't been a focus for neither Debian nor Ubuntu. Anyhow, the
>> connection manager needs to clear IPv6 address just like it clears
>> the IPv4 address when the link goes down.
> 
> I've reported a bug myself
> 
> 	https://bugzilla.gnome.org/show_bug.cgi?id=646703

I have reported a bug for this, too:

	https://bugzilla.gnome.org/show_bug.cgi?id=643414

Basically, it sort of supports IPv6 today if configured appropriately.
However, the default configuration is to completely ignore IPv6. Which
also means it does not flush the config on disconnect.

Bernhard
Permalink | Reply | 0 comments |

Gmane