9:06 a.m.
On Thu, Jun 18, 2009 at 10:46:45AM +0100, Daniel P. Berrange wrote:
On Wed, Jun 17, 2009 at 10:59:20PM +0000, David Lutterkort wrote:
> On Wed, 2009-06-17 at 21:32 +0100, Daniel P. Berrange wrote:
> > How do you deal with IPv6 currently ?
>
> With lots of Aspirin (actually, not at all)
Very very very slowly ... I remember in 96 IETF meetings the
propaganda that we were doomed if we didn't switch *right now* >:->
I also saw major brands of routers failing in faily nefastous ways
when anxious people activated IPv6 a bit before everybody else.
But jokes apart we need to have this working now ...
> > I was thinking of sugesting an attribute
> >
> > <ip type="ipv6" address="2001:23::2"
prefix="24"/>
> >
> > but I think its possibly better to have a different element name
> >
> > <ip6 address="2001:23::2" prefix="24"/>
> >
> > since the former would not work if we ever needed to worry about
> > non-IP based addresses.
>
> Either works for me, with a slight preference for the first version, on
> purely esthetic grounds. And even if we go with that, there's nothing
> keeping us from adding an <ipx> element as an alternative to the <ip>
> element in the future.
Or a 3rd option is to group addresses by family
<addresses family='ipv4'>
<ip address='122.0.0.3' prefix='24'/>
<ip address='24.24.224.4' prefix='24'/>
</addresses>
<addresses family='ipv6'>
<ip address='2001:23::2' prefix='48'/>
<ip address='fe:33:55::33' prefix='64'/>
</addresses>
<adddresses family='ipx'>
<ipx address='2423.4521.66.3.252.'/>
</address>
Hum, right now the syntax is far more restrictive for addressing,
there is one address, period, with an optional route we need to extend
that IMHO.
[...]
The problem with the propsal is that it opens the door to a variety of
errors like using the same familly twice, which I would like to avoid
at the RNG level but it's not trivial.
We should allow standalone IPv4 and IPv6, or both. Each could either
use DHCP or allow one or more IP address and routes.
I think if we have routes, at most one need to be a gateway and the
other ones having destination + prefix.
So I suggest the following rewrite of interface-addressing
<!-- Assignment of IP address to an interface -->
<define name="interface-addressing">
<choice>
<ref name="interface-addr-ipv4"/>
<ref name="interface-addr-ipv6"/>
<group>
<ref name="interface-addr-ipv4"/>
<ref name="interface-addr-ipv6"/>
</group>
</choice>
</define>
This allows one or 2 blocks of addresses ipv4, ipv6 or both
<define name="interface-addr-ipv4">
<element name="addresses">
<attribute name="family">
<value>ipv4</value>
</attribute>
<choice>
<ref name="interface-addr-static"/>
<ref name="interface-addr-dhcp"/>
</choice>
</element>
</define>
An IPv4 addresses block, allows for either static or dhcp
<define name="interface-addr-ipv6">
<element name="addresses">
<attribute name="family">
<value>ipv6</value>
</attribute>
<choice>
<ref name="interface-addr-static"/>
<ref name="interface-addr-dhcp"/>
</choice>
</element>
</define>
same for IPv6
<define name="interface-addr-static">
<oneOrMore>
<element name="ip">
<attribute name="address"><ref
name="ip-addr"/></attribute>
<attribute name="prefix"><ref
name="prefix-pattern"/></attribute>
</element>
</oneOrMore>
<optional>
<ref name="interface-addr-routes"/>
</optional>
</define>
A static addressing scheme is made of one or more <ip> elements with
address and prefix followed by optional routing info
<define name="interface-addr-dhcp">
<element name="dhcp">
<optional>
<attribute name="peerdns">
<ref name="yes-or-no"/>
</attribute>
</optional>
</element>
</define>
For DHCP the only option is the peerdns yes/no attribute
<define name="interface-addr-routes">
<element name="route">
<attribute name="destination">
<value>default</value>
</attribute>
<attribute name="gateway"><ref
name="ip-addr"/></attribute>
</element>
<zeroOrMore>
<element name="route">
<attribute name="destination"><ref
name="ip-addr"/></attribute>
<attribute name="prefix"><ref
name="prefix-pattern"/></attribute>
<optional>
<attribute name="gateway"><ref
name="ip-addr"/></attribute>
</optional>
</element>
</zeroOrMore>
</define>
And for routes we have at least one default route and
then an optional set of routes with prefixes and optional gateways for
that device. To note all the ip/dhcp/route constructs are similar for
IPv4 and IPv6 as we don't check content precisely here. I assume it's
sufficient.
I think this revamps the capabilities quite a bit but I guess it
should make sure we have IPv6 support on equal footing, and also
incorporates I think most of Jim Fehlig remaks noted in the RNG.
Examples of working definitions:
<interface type="ethernet" startmode="onboot">
<name>eth1</name>
<mtu size="1500"/>
<mac address="00:1A:A0:8F:39:A6"/>
<addresses family='ipv4'>
<dhcp peerdns="no"/>
</addresses>
</interface>
<interface type="ethernet" startmode="none">
<name>eth2</name>
<addresses family='ipv4'>
<dhcp/>
</addresses>
<addresses family='ipv6'>
<dhcp/>
</addresses>
</interface>
<interface type="ethernet" startmode="hotplug">
<name>eth3</name>
<mac address="00:1A:A0:8F:50:B7"/>
<addresses family='ipv4'>
<ip address="192.168.0.15" prefix="24"/>
<ip address="192.168.1.10" prefix="24"/>
<route destination="default" gateway="192.168.0.1"/>
<route destination="192.168.1.0" prefix="24"
gateway="192.168.1.1"/>
</addresses>
</interface>
This makes parsing a bit heavier, and I didn't checked if this really
affected bridging and bonding interfaces in a wrong way, but I think
that at least at an ethernet level definition this looks more complete.
That said I have no idea how much of a problem it would be on the netcf
impletmentation side.
Daniel
P.S.: full rng attached, double check the prefix-pattern definition
I have no idea if it's sufficient for Ipv6
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/