Re: NM bug 684242 and other stuff

[Pavel Simerda <psimerda redhat com>]

> On 09/25/2012 07:55 PM, Pavel Simerda wrote:
> > I'll divide my reaction into four parts and post it also to NM
> > mailing list so that anyone can
> > benefit.
> >
> > 1) DHCPv6 currently works according to IETF standards and has been
> > tested with NetworkManager
> > commit 70f64fbc4277c636c0a373d6e6eddf0574d53827 before merging the
> > 'ipv6' branch into
> > master. The problem with setting default route has been fixed in
> > the previous commit
> > 70f64fbc4277c636c0a373d6e6eddf0574d53827. You can look at them for
> > more details.
> >
> > I have just checkout out 0.9.6.0, ran ./autogen.sh, make, make
> > install and ran NetworkManager.
> >
> > DHCPv6 works like a charm including RA-originated default route. It
> > even works without any
> > configuration (just delete it or move it away).
> >
> > # ip address show dev eth1
> > 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
> > pfifo_fast state UP qlen 1000
> >      link/ether 52:54:00:eb:e9:fb brd ff:ff:ff:ff:ff:ff
> >      inet 192.168.25.12/24 brd 192.168.25.255 scope global eth1
> >      inet6 2001:abcd:1:1::1:115b/128 scope global
> >         valid_lft forever preferred_lft forever
> >      inet6 fe80::5054:ff:feeb:e9fb/64 scope link
> >         valid_lft forever preferred_lft forever
> >
> > # ip -6 route show default
> > default via fe80::5054:ff:fe44:5d16 dev eth1  proto static  metric
> > 1
> > default via fe80::20c:42ff:fe13:857b dev eth0  proto kernel  metric
> > 1024  expires 57sec
> > default via fe80::5054:ff:fe44:5d16 dev eth1  proto kernel  metric
> > 1024  expires 252sec
> >
> > The routes with metric 1024 are from kernel. NetworkManager wants
> > to make eth1 the default
> > interface so it creates the same route with metric 1.
> >
> > The testing server environment is as described in:
> >
> > https://fedoraproject.org/wiki/Tools/NetworkManager/IPv6#DHCPv6_address_and_DNS_configuration
> >
> > I'm doing first tests with firewall and selinux disabled (if
> > applicable). If your tests show
> > different results, please present them in their full beauty.
> When you are right, you are right!  Yes, Pavel you very much right!
>
> The small difference between what I had and what is specified for the
> test is  radvd.conf.  The configuration that works adds
> "AdvManagedFlag
> on;", deletes most of the rest, and has "AdvAutonomous off;".  What a
> difference that made.
> 
> Now, my next question.  The above was with plugin=ifcfg-rh and I also
> have a virtual system using plugin=keyfile (I want to made sure that
> my
> ddns works).  What parameters do I need to add to the keyfile
> definition
> so that it works too?

The proper keyfile configuration is for example:

[connection]
id=Ethernet
uuid=d880f3bb-8c51-4ca4-aef7-1954e022820f
type=802-3-ethernet
[802-3-ethernet]
mac-address=52:54:00:eb:e9:fb
[ipv4]
method=auto
[ipv6]
nmmethod=auto

> When I tested both virtual systems I removed all previous
> configuration
> stuff and let NM create some default configuration files.  The
> results
> were that plugin=ifcfg-rh worked and
>
>plugin=keyfile did not.

Works for me (if we're still talking about addresses and routing).

Testing 0.9.6.0, no firewall, no selinux, ip configuration clean,
interfaces down, dhclients killed.

Be careful, NetworkManager can misbehave for various reasons. It's
good to run it --no-daemon --log-level=debug and see what's going
on. I'm gradually trying to make the processing and the logging
of NM-kernel interactions cleaner and easier to read but it takes
time.

> For the default plugin=keyfile system you got a SLAAC address

I'm still getting DHCP address.

> and a good default route.

Correct.

> If I specify that method=dhcp,

Don't do that. It doesn't work. It never worked. It will be most
probably removed (I'm already removing it in 'pavlix/next' branch).

> then dhcp6 assigns an
> address and named is updated but there is no good default route.
> 
> BTW, my testing that worked was using named/dhcpd/dhcp6 on the
> server. I now need to test dnsmasq to make sure that it works too.

As far as I understand, you're now happy with your patch when using
bind. That's great.

> It is possible that for a small network (which is the primary use of
> dnsmasq), you might not need radvd because dnsmasq does some RA support
> too.

There are also other projects that do RA.

> That might be very convenient for the libvirt folks ... if it works or can
> be made to work.

If they want DNS, DHCP and TFTP in one program, it's only natural to include
RA too.

> > 2) NetworkManager supports the following methods:
> >
> > method=auto (this is the automatic configuration described in IPv6
> > standards including DHCPv6)
> > method=manual (you can set up addresses here)
> > method=link-local (global addressing is disabled)
> >
> > It doesn't currently support all sorts of hybrids. If you want it
> > to support something more than
> > autoconf (including DHCP) and manual configuration, please file a
> > RFE in bugzilla (if it's not
> > filed already).
> >
> > Don't use method=dhcp (aka DHCP only). It never worked.
> >
> > Don't use method=ignore, it was there to leave everything up to the
> > kernel when NetworkManager
> > didn't have such good support for IPv6.
> DHCP worked for IPv4 because there was a lot of "just make it work"
> stuff done.   But IPv6 is a new ballgame.

DHCP worked for IPv4 and RA or RA+DHCP works for IPv6. This is how it is
designed. It's a bit more complicated than the IPv4 configuration, that's
why I was trying to document it a bit more.

> I do not know if implementing support for a static, specified default
> route if worth the effort or not,  I do not know that it is needed
> other than when you do a manual, static configuration.

I don't know either. But if people need it we'll implement it.

> BTW, I found that I could make some interesting entries in
> nm-applet's
> route specification for IPv6 when crashed NetworkManager real hard
> ...
> took a reboot to get it back.  I will have to collect more info and
> bugzilla that.

Please do.

> > 3) http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-03
> >
> > This draft is recycling something that has been proposed for
> > *years*. In my opinion, there is no
> > need to care about this at all at this point of time. I think
> > mostly only need to care about
> > the current IPv6 node requirements:
> >
> > http://tools.ietf.org/html/rfc6434
> >
> > This is what you can expect from IPv6 configuration daemon. If this
> > document is updated/obsoleted,
> > then there's time for implementing the change in NetworkManager.
> > Unless, of course, you have a very
> > good reason to do otherwise.
> >
> > 4) Looking forward to seeing your IPv6 dynamic DNS patch merged.
> > Even though I'm not using dyndns at
> > all, I'm glad that you are trying to make IPv6 work like IPv4 did
> > for you.
> I am looking forward to it too.  Unfortunately, while what I have
> works, it will only work on a Fedora or other RHEL system.

That's better than nothing. It might also work in distros that accept
RH patches.

> I did not realize
> that the "-F" dhclient command line specification was a Red Hat only
> patch.  So I need to go back and put stuff into a conf file ... that
> is probably the better way anyway.

If you can make it work with pristine dhclient, it will be great!

> With this IPv6 stuff I do feel like I am out in front with a few
> arrows in my back.  My hope is to provide more opportunity to test
> IPv6 by adding "full" support to qemu/kvm/libvirt virtualization.

I'm curious about any news in this field.

Cheers,

Pavel

> 
> Gene
>