LVS
lvs-devel
Google
 
Web LinuxVirtualServer.org

Re: ldirectord: a new format of ldirectord.conf for IPv6

To: Sohgo Takeuchi <sohgo@xxxxxxxxxxxxxxxx>
Subject: Re: ldirectord: a new format of ldirectord.conf for IPv6
Cc: lvs-devel@xxxxxxxxxxxxxxx
From: Simon Horman <horms@xxxxxxxxxxxx>
Date: Tue, 3 Aug 2010 10:03:42 +0900
On Mon, Aug 02, 2010 at 06:35:49PM +0900, Sohgo Takeuchi wrote:
> 
> Hi,
> 
>   I have been working on improving IPv6 support of ldirectord
> for a few weeks. I would like to hear your opinion or ideas
> about how to write ldirectord.conf.

A tricky topic, thanks for thinking it through.

> Q1. Should ldirectord support an IPv6 hostname in ldirectord.conf?
> 
>     A manual of ldirectord says that a hostname can be written
>     in "virtual", "real", "fallback" and so on. Current
>     implementation of ldirectord handles the hostname as only
>     IPv4. It partially supports IPv6, and can write only IPv6
>     addresses. But it does not have a way to write a hostname as
>     IPv6. Because there is no way to distinguish between IPv4
>     and IPv6. Should ldirectord support an IPv6 hostname in
>     ldirectord.conf?
> 
> Q2. If the answer of Q1 is yes, how do you want to write?
> 
>     [Candidate 1] Adding a new keyword like a "ipversion".
>       A default value of "ipversion" is 4 (IPv4).
> 
>       fallback=fallback.example.com
>       fallback6=fallback.example.com
>         virtual=virtual.example.com:daytime
>           real=real1.example.com:daytime gate
>           real=10.10.10.10:daytime gate
>       
>       virtual=virtual.example.com:daytime
>           ipversion=6
>           real=real1.example.com:daytime gate
>           real=[2001:db8::10]:daytime gate
> 
>     This way cannot handle a global "fallback" variable. We must
>     have a way to distinguish between IPv4 and IPv6 when a
>     hostname is specified in the global "fallback" variable. To
>     achieve this, there is a way to add a new variable of
>     "fallback6". Any other good ideas?

This "fallback" problem seems to be the most difficult issue.

>     [Candidate 2] Adding new keywords of "virtual6" and
>       "fallback6".
> 
>     "virtual6" is an IPv6 version of "virtual". If a hostname
>     and an IP address are specified in the "virtual6" line and
>     in its section, they are treated as an IPv6 address and the
>     hostname will be resolved into an IPv6 address.
> 
>     "fallback6" is just a global variable. It cannot be
>     specified in a virtual section. If no "fallback" in a
>     "virtual6" section is defined, the variable of "fallback6"
>     will be used.  If "fallback" in the "virtual6" section is
>     defined, it is treated as an IPv6 address.
>     
> 
>       fallback=fallback.example.com
>       fallback6=fallback.example.com
>         virtual=virtual.example.com:daytime
>           real=real1.example.com:daytime gate
>           real=10.10.10.10:daytime gate
>       
>       virtual6=virtual.example.com:daytime
>           real=real1.example.com:daytime gate
>           real=[2001:db8::10]:daytime gate
> 
>     This way breaks a backward compatibility. Current ldirectord
>     can write an IPv6 address in a "virtual" line. But this way
>     cannot.

I'm not particularly concerned about backwards compatibility here,
IPv6 for ldirectord is pretty green.

>     [Candidate 3] Completely separate IPv4 and IPv6 using
>       "hoge6" keywords.
>     
>     Adding new keywords which denote IPv6. These keywords can
>     handle IPv6 only and have a name "hoge6".
> 
>       fallback=fallback.example.com
>       fallback6=fallback.example.com
>         virtual=virtual.example.com:daytime
>           real=real1.example.com:daytime gate
>           real=10.10.10.10:daytime gate
>       
>       virtual6=virtual.example.com:daytime
>           real6=real1.example.com:daytime gate
>           real6=[2001:db8::10]:daytime gate
>           fallback6=localhost:daytime
> 
>     This way is very similar to [Candidate 2]. But it is
>     consistent and easy to read. A demerit is a bit redundant?

I like candidate 3. Yes, it is redundant, but it is also very clear
and consistent.

N.B: I think that all of the proposals would fwmark services without
any extra magic.

--
To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

<Prev in Thread] Current Thread [Next in Thread>