Re: NM bug 684242 and other stuff

[Dan Williams <dcbw redhat com>]

On Wed, 2012-09-26 at 14:04 -0400, Gene Czarcinski wrote:
> 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?

There's some example keyfiles here:

http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/settings/plugins/keyfile/tests/keyfiles

manual IPv6 is for example:

http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/settings/plugins/keyfile/tests/keyfiles/Test_Wired_Connection_IP6

but that doesn't describe SLAAC.  For that, you just need:

[ipv6]
method=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.
> 
> For the default plugin=keyfile system you got a SLAAC address and a good 
> default route.  If I specify that method=dhcp, then dhcp6 assigns an 
> address and named is updated but there is no good default route.

Yeah, don't use dhcp.  We'll end up aliasing that to 'auto' in the
future, because it was a mistake on my part to add it in the first
place.  DHCPv6-only without Router Advertisements is not a valid IPv6
configuration mechanism and *cannot* give you a default route simply
because DHCPv6 has no mechanism to return a default router.  And that's
intended, because you're supposed to use SLAAC with either the Managed
(AdvManagedFlag) or Other (AdvOtherConfigFlag) flags set.

> 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. 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.  That 
> might be very convenient for the libvirt folks ... if it works or can be 
> made to work.

Check the dnsmasq mailing list this month; there's been a bunch of posts
from people trying to get it to work.  Obviously like radvd the
configuration needs to be exactly right.

> > 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.

DHCPv4 also worked alone because it returned a router.  But with IPv6
the router is given through the router advertisement, which DHCPv6 does
not return, so yeah, a lot has changed.  It's actually both simpler
*and* more complicated all at the same time.

> 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 believe we'll support it for anything other than method=manual,
since the default route is provided automatically when using Router
Advertisements, which almost all IPv6 networks should be using,
regardless of whether they also use DHCPv6 or not.  DHCPv6 and RA work
in concert with each other, not exclusively of each other.

> 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.

Yeah, 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.  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.

Take a  look at merge_dhclient_config() in
src/dhcp-manager/nm-dhcp-dhclient.c which calls
nm_dhcp_dhclient_create_config() in nm-dhcp-dhclient-utils.c.  That does
exactly what you want.  What you'll want to do is replace the s_ip4
argument to both those functions with simply "const char *client_id"
which gets pulled out of the IPv4 config setting in the IPv4 codepaths.

The one complication is the hostname bits, which aren't substituted
unless s_ip4 exists.  I believe that was an oversight, as there will
almost always be an IPv4 setting.  Plus the code removes any existing
hostname from the config if a hostname is passed into the fucntion, but
only writes the new one back if s_ip4 exists?  That doesn't make a lot
of sense.  So just modify the code to always write the new hostname to
the file if it's !NULL.

Since for IPv6 you want to use the fqdn stuff, you'll probably want to
add yet another parameter to nm_dhcp_dhclient_create_config() that
writes the hostname out correctly for fqdn.fqdn and the other options
instead of send-hostname.

> 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 hope I didn't shoot any of those arrows :)  Your effort here is much
appreciated.

Thanks!
Dan