Bug 967529 - PPPoE does not attempt DHCPv6 Prefix Delegation
PPPoE does not attempt DHCPv6 Prefix Delegation
Status: NEW
Product: Fedora
Classification: Fedora
Component: ppp (Show other bugs)
26
All Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Michal Sekletar
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-27 07:14 EDT by David Beveridge
Modified: 2017-08-16 07:16 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
proposed changes (5.31 KB, patch)
2013-05-27 07:14 EDT, David Beveridge
no flags Details | Diff
HowTO setup PPPoE with IPv6 PD on Fedora 19 version 1 (1.86 KB, text/plain)
2013-05-27 07:23 EDT, David Beveridge
no flags Details
Patched /etc/ppp/ipv6-up (3.87 KB, text/plain)
2013-05-27 07:35 EDT, David Beveridge
no flags Details
Patched /etc/ppp/ipv6-down (1.73 KB, text/plain)
2013-05-27 07:36 EDT, David Beveridge
no flags Details
Patched /etc/sysconfig/network-scripts/network-functions-ipv6 (27.48 KB, text/plain)
2013-05-27 07:37 EDT, David Beveridge
no flags Details
Documentation Patch - sysconfig.txt (1.33 KB, patch)
2013-05-29 06:52 EDT, David Beveridge
no flags Details | Diff
proposed changes v2 (782 bytes, patch)
2013-05-29 07:33 EDT, David Beveridge
no flags Details | Diff
proposed changes v2 (5.18 KB, patch)
2013-05-29 07:40 EDT, David Beveridge
no flags Details | Diff
Patched /etc/ppp/ipv6-up v2 (3.85 KB, patch)
2013-05-29 07:54 EDT, David Beveridge
no flags Details | Diff
Patched /etc/ppp/ipv6-down v2 (1.88 KB, text/plain)
2013-05-29 08:00 EDT, David Beveridge
no flags Details

  None (edit)
Description David Beveridge 2013-05-27 07:14:28 EDT
Created attachment 753581 [details]
proposed changes

Description of problem: Enhancement
Version-Release number of selected component (if applicable): 9.46
How reproducible: The trouble with this is finding IPv6 connectivity to test on.

Steps to Reproduce:
1. yum install rp-pppoe radvd dhclient wide-dhcpv6
2. pppoe-setup
3. ifup ppp0

Actual results: IPv4 Only Addresses on ppp0
Expected results: IPv6 Addresses on ppp0 and eth0

Additional info: see supplied patches.
See also Bugs 956147 & 626514

In a nutshell I am proposing to extend the DHCPV6C variable to allow the name of the dhcp client package so that we can select the dhcp client.
DHCPV6C=yes (still means dhclient)
DHCPV6C=isc (new means dhclient)
DHCPV6C=wide (new means wide-dhcpv6 client)
DHCPV6C=no (still means no)

The other new variable is DHCP6_PD which is a space separated list of interface names which should received an IPv6 Prefix that has been obtained by DHCPv6 PD.
eg
DHCP6_PD="eth0 eth1"

Other variables that are used by these scripts are not new.
IPV6INIT=yes
IPV6_CONTROL_RADVD=yes
IPV6_RADVD_TRIGGER_ACTION=startstop
PPPD_EXTRA="ipv6 ,"

The modifications to /etc/sysconfig/network-scripts/network-functions-ipv6 are all for the wide-dhcpv6 package and are for generating a config file name in much the same way the function for dhclient works.

The modifications to /etc/ppp/ipv6-up add the scripts to call the relevant dhcp6 client.
The modifications to /etc/ppp/ipv6-down are for cleaning up when the ppp link goes down.

I can only attach a single attachment here so there is more to come.
Comment 1 David Beveridge 2013-05-27 07:20:38 EDT
Discussion Points / Tidy up things

right now /etc/ppp/ipv6-up requires the file /etc/sysconfig/network to exist.  Why?
right now /etc/ppp/ipv6-down requires the file /etc/sysconfig/network to exist.  Why?

I see this in /etc/sysconfig/network-scripts/network-functions-ipv6
	if ! /sbin/chkconfig --list radvd >/dev/null 2>&1; then
Maybe it should be
	if ! systemctl is-enabled radvd >/dev/null 2>&1; then

Do we want a variable IPV6_CONTROL_FORWARDING=yes
which does this for up
	sysctl -w net.ipv6.conf.all.forwarding=1
and this for down
	sysctl -w net.ipv6.conf.all.forwarding=0
?

Would be nice to modify package rp-pppoe (pppoe-setup) to ask a new question: 
Do you want IPv6?  
And do the setup accordingly.  
But that will have to wait for initscripts to support the parameters.

Once the initscripts changes are accepted, 
I have some NetworkManager dispatcher.d scripts to be released.
Comment 2 David Beveridge 2013-05-27 07:23:27 EDT
Created attachment 753586 [details]
HowTO setup PPPoE with IPv6 PD on Fedora 19 version 1

This still needs a lot of beef.
Comment 3 David Beveridge 2013-05-27 07:35:48 EDT
Created attachment 753589 [details]
Patched /etc/ppp/ipv6-up
Comment 4 David Beveridge 2013-05-27 07:36:30 EDT
Created attachment 753590 [details]
Patched /etc/ppp/ipv6-down
Comment 5 David Beveridge 2013-05-27 07:37:24 EDT
Created attachment 753591 [details]
Patched /etc/sysconfig/network-scripts/network-functions-ipv6
Comment 6 Lukáš Nykrýn 2013-05-28 07:44:58 EDT
Generally looks good to me, just two remarks.
1) Can you also provide patch for sysconfig.txt which will document this feature?
2) I don't like using variables DHCPV6C and DHCP6C, they look quite similar. Is there a reason why can't be DHCP6C thrown away and just check "$DHCPV6C" = [Ww2]*" instead?


> right now /etc/ppp/ipv6-up requires the file /etc/sysconfig/network to
> exist.  Why?
> right now /etc/ppp/ipv6-down requires the file /etc/sysconfig/network to
> exist.  Why?
> 
Probably historical reasons, initscripts interprets missing /etc/sysconfig/network as unconfigured network.

> I see this in /etc/sysconfig/network-scripts/network-functions-ipv6
> 	if ! /sbin/chkconfig --list radvd >/dev/null 2>&1; then
> Maybe it should be
> 	if ! systemctl is-enabled radvd >/dev/null 2>&1; then
> 
This is probably wrong, I will look at it.

> Do we want a variable IPV6_CONTROL_FORWARDING=yes
> which does this for up
> 	sysctl -w net.ipv6.conf.all.forwarding=1
> and this for down
> 	sysctl -w net.ipv6.conf.all.forwarding=0
> ?
I think that this should be in sysctl.conf, not in network scripts.
Comment 7 Bill Nottingham 2013-05-28 11:44:21 EDT
Is there a specific reason to need a second DHCPv6 client? We have explicitly moved to only supporting one DHCPv4 client from the 2/3 we had prior.
Comment 8 David Beveridge 2013-05-28 21:39:46 EDT
(In reply to Bill Nottingham from comment #7)
> Is there a specific reason to need a second DHCPv6 client? We have
> explicitly moved to only supporting one DHCPv4 client from the 2/3 we had
> prior.

I think the end game would be to have the existing dhclient do it all but there are gaps in its capabilities.

see https://bugzilla.redhat.com/show_bug.cgi?id=956147#c11

WHY USE WIDE-DHCPv6?

Generally speaking the main DHCP package for RedHat from ISC is 
a much more complete implementation with a nearly full set of features.

Unfortunately there are a few things it does not do, or does not do well (yet!).  

This is where it might be appropriate to use an alternative such as wide-dhcpv6.

Things wide-dhcpv6 is not.
 1. Being further developed.
 2. Fully RFC compliant.
 3. Able to do prefix delegation from a pool of addresses.
 4. Able to service (serve to) more than one interface per instance.


Reasons to choose wide dhcp for IPv6.
 1. Your ISP wants to assign you a static /128 link address 
    and a /64 or greater prefix for your LAN, both by DHCP. (eg comcast cable)
    (until https://bugzilla.redhat.com/show_bug.cgi?id=836702 is finished)
 2. You need the client to assign IP addresses to your LAN interfaces for radvd.
    (until https://bugzilla.redhat.com/show_bug.cgi?id=626514 is finished)
 3. Your ISP gave you a working sample configuration file for wide-dhcpv6
 4. You want a basic dhcpv6 server to run many separate instances 
    on a range of interfaces (eg in a VPN concentrator)

...
Comment 9 David Beveridge 2013-05-28 21:46:44 EDT
(In reply to Lukáš Nykrýn from comment #6)
> Generally looks good to me, just two remarks.
> 1) Can you also provide patch for sysconfig.txt which will document this
> feature?

Will do.

> 2) I don't like using variables DHCPV6C and DHCP6C, they look quite similar.
> Is there a reason why can't be DHCP6C thrown away and just check "$DHCPV6C"
> = [Ww2]*" instead?
> 

Agreed, What do you think of the idea that if set to "yes" it defaults to dhclient (if installed) and falls back to wide-dhcp if it's the only one installed?

> 
> > Do we want a variable IPV6_CONTROL_FORWARDING=yes
> > which does this for up
> > 	sysctl -w net.ipv6.conf.all.forwarding=1
> > and this for down
> > 	sysctl -w net.ipv6.conf.all.forwarding=0
> > ?
> I think that this should be in sysctl.conf, not in network scripts.

I just found this in sysconfig.txt
    IPV6FORWARDING=yes|no
      Enable or disable global forwarding of incoming IPv6 packets
      Note: Obsolete in interface specification!
      Default: no

So we definitely don't want another variable around to do this.
Comment 10 Bill Nottingham 2013-05-28 22:07:42 EDT
Those 'why use wide-dhcpv6' sections seem to cry out for just fixing ISC dhcpv6 (wide dhcpv6 caveats: not rfc compliant?!?!), rather than forcing users to modify their configuration in ways that won't work with NM, for example.

Also, unless I'm missing something, wide-dhcpv6 isn't packaged for Fedora?
Comment 11 David Beveridge 2013-05-28 22:54:10 EDT
(In reply to Bill Nottingham from comment #10)
> Those 'why use wide-dhcpv6' sections seem to cry out for just fixing ISC

I have submitted a patch which I think goes a long way to fixing one problem.
https://bugzilla.redhat.com/attachment.cgi?id=743452&action=diff

> dhcpv6 (wide dhcpv6 caveats: not rfc compliant?!?!), 
ISC is not fully compliant either.  Wide DHCP seems to be the package of choice despite this, because it is much easier to get working.

> rather than forcing
> users to modify their configuration in ways that won't work with NM, for
> example.

I'd really like to help out here, but my knowledge of NM is a little bit lacking, but I am getting there slowly.

> 
> Also, unless I'm missing something, wide-dhcpv6 isn't packaged for Fedora?
Not yet: It's my first Package: Bug 956147 
Review Request: wide-dhcpv6 - DHCPv6 Prefix Delegation client that works on PPP
Comment 12 Lukáš Nykrýn 2013-05-29 06:15:30 EDT
I spoke with maintainer of dhclient and they have some issues to get things into the upstream so they will discuss this bug and tell us their recommendation.
Comment 13 David Beveridge 2013-05-29 06:52:34 EDT
Created attachment 754296 [details]
Documentation Patch - sysconfig.txt

   IPv6-only option to enable DHCPv6 client:
       Two dhcp6 clients are supported: isc dhcp (default) and wide-dhcpv6
     DHCPV6C=yes|no|isc|wide
       This will enable the DHCPv6 features of dhclient or dhcp6c to be run for the interface.
       See man dhclient(8) and dhclient.conf(5) for yes|isc
       See man dhcp6c(8) and dhcp6c.conf(5) for wide-dhcpv6
     DHCPV6C_OPTIONS=...
       This will pass given arguments to the DHCPv6 client.  For example,
       "-S" option will request network information (e.g., DNS addresses)
       only, not IPv6 addresses.
     DHCP6_PD="<interface> ..."
       A list of interfaces which will receive a delegated /64 prefix.
       This enables DHCPv6 Prefix Delegation requests.
Comment 14 David Beveridge 2013-05-29 07:33:23 EDT
Created attachment 754312 [details]
proposed changes v2

I've done a lot more testing with dhclient and found some bugs in the original patch which were mainly tested with wide-dhcpv6

I've also included some changes as suggested "Get rid of DHCP6C variable"

BTW: if you want to test with dhclient-script, do "setenforce 0", there are still unresolved selinux issues.
Comment 15 David Beveridge 2013-05-29 07:40:41 EDT
Created attachment 754313 [details]
proposed changes v2

Let's try this again
Comment 16 David Beveridge 2013-05-29 07:54:19 EDT
Created attachment 754315 [details]
Patched /etc/ppp/ipv6-up v2
Comment 17 David Beveridge 2013-05-29 08:00:17 EDT
Created attachment 754317 [details]
Patched /etc/ppp/ipv6-down v2

Now shuts down dhclient -6 using killproc -p PID
Comment 18 Fedora Admin XMLRPC Client 2013-09-04 10:51:18 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 19 Fedora End Of Life 2013-09-16 10:01:43 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle.
Changing version to '20'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20
Comment 20 Fedora End Of Life 2015-05-29 05:04:59 EDT
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 21 David Beveridge 2015-05-29 06:19:37 EDT
(In reply to Bill Nottingham from comment #10)
> Those 'why use wide-dhcpv6' sections seem to cry out for just fixing ISC
> dhcpv6 (wide dhcpv6 caveats: not rfc compliant?!?!), rather than forcing
> users to modify their configuration in ways that won't work with NM, for
> example.
> 
> Also, unless I'm missing something, wide-dhcpv6 isn't packaged for Fedora?

It is now
Comment 22 Jan Kurik 2015-07-15 10:47:37 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
Comment 23 Fedora End Of Life 2016-11-24 05:59:07 EST
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 24 Fedora End Of Life 2017-02-28 04:34:08 EST
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.
Comment 25 David Kaspar [Dee'Kej] 2017-08-16 07:16:39 EDT
PPP is now living in a package separate from initscripts. Switching to 'ppp'.

Note You need to log in before you can comment on or make changes to this bug.