Bug 143452 - static-routes-ipv6 for default ipv6 route on ppp0 not honored
static-routes-ipv6 for default ipv6 route on ppp0 not honored
Status: CLOSED NEXTRELEASE
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: initscripts (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Brock Organ
:
Depends On:
Blocks: FC5Target
  Show dependency treegraph
 
Reported: 2004-12-20 20:24 EST by Eric Moret
Modified: 2014-03-16 22:51 EDT (History)
5 users (show)

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


Attachments (Terms of Use)
patch for /etc/ppp/ipv6-up (3.94 KB, patch)
2006-08-02 01:53 EDT, Peter Bieringer
no flags Details | Diff
patch for /etc/ppp/ipv6-down (2.38 KB, patch)
2006-08-02 01:55 EDT, Peter Bieringer
no flags Details | Diff
cosmetic changes to some IPv6 related initscript files (8.14 KB, patch)
2006-08-02 02:16 EDT, Peter Bieringer
no flags Details | Diff

  None (edit)
Description Eric Moret 2004-12-20 20:24:12 EST
Description of problem:
My ISP provides native ipv6 ppp connectivity. I have configured ppp0
(recompiled pppd with fix described in #85450) for ipv6 support and
added static route for default gw through creation of file:

# cat /etc/sysconfig/static-routes-ipv6
ppp0    2000::/3

links comes up with IPv6 address as expected

# ifconfig ppp0 | grep inet6
inet6 addr: fe80::XXXX:XXXX:XXXX:XXXX/10 Scope:Link

However when I restart network services, default gateway does not
appear in the list of routes

Version-Release number of selected component (if applicable):
initscripts-7.31.16.EL-1

How reproducible:
Always

Steps to Reproduce:
1. Get native ipv6 ppp link from ISP
2. recompile pppd with fix #85450
3. Create static-routes-ipv6 file with default gateway through ppp0
4. issue route command to list ipv6 routes
    

Actual Results:  Static route does not appear in list

# route -A inet6 | grep ppp0
fe80::/64     *      U     256    0        0 ppp0
fe80::/10     *      U     1      0        0 ppp0
fe80::/10     *      U     256    0        0 ppp0
ff00::/8      *      U     256    0        0 ppp0

Expected Results:  Manual setting of route results in list appearing
as expected in list

# route add -A inet6 2000::/3 dev ppp0

# route -A inet6 | grep ppp0
2000::/3      *      U     1      0        0 ppp0
fe80::/64     *      U     256    0        0 ppp0
fe80::/10     *      U     1      0        0 ppp0
fe80::/10     *      U     256    0        0 ppp0
ff00::/8      *      U     256    0        0 ppp0

Additional info: none
Comment 1 Eric Moret 2004-12-21 02:20:40 EST
After giving it more thought, because ifcfg-ppp0 includes both:
1) DEFROUTE=yes and
2) PPPD_EXTRA="ipv6, "
users should not be required to manually specify an IPv6 static 
default route. Rather, network startup scripts should automatically 
set the default static route through ppp0 as is the case for IPv4.
Comment 2 Peter Bieringer 2005-09-21 18:23:34 EDT
I will dig into this issue, unfortunatly I have no IPv6 enabled PPP ISP here.
Perhaps I would ask for more information in the next days. Is it possible that
you can provide temporary login data for that IPv6 enabled ISP to me? Otherwise
I have to work on setup my own IPv6-enabled dial-in here (currently I only have
IPv4-enabled ipppd [ISDN], which doesn't support IPv6 at all...missing support
in daemon and afair also in kernel - but that's another issue). But I'm able to
setup a modem dial-in also...only need more time.
Comment 3 Eric Moret 2005-09-21 19:21:42 EDT
Hi Peter,

I just double checked my ISP number (in France) from the US and it looks like 
their dialup number is not accessible from abroad (meaning outside France) :( I 
can try to get in touch with my ISP and check with them if they could provide 
you with an international number to reach.

I'll get back to you as soon as I get more info.
Thanks,
__
Eric
Comment 4 Eric Moret 2005-09-22 04:34:55 EDT
Just got an answer to the international dialup number availability question and 
there is unfortunately no available number from abroad. You will have to come 
up with your own IPv6 setup.
Comment 5 Pekka Savola 2005-09-22 08:36:13 EDT
I guess remove SSH access might have simplified debugging..

I think what may behappening here is that 'service network restart' does not
bring down/up the PPP interfaces, but
/etc/sysconfig/network-scripts/init.ipv6-global or some other part of
/etc/init.d/network deletes the routes in any case..

I didn't analyze this at depth, but these are the things I'd start tracing first..
Comment 6 Peter Bieringer 2005-09-22 15:51:58 EDT
So, I have set up now here my own IPv6-enabled ppp server (FC4).

First, looks like your ISP isn't fully IPv6 enabled:

links comes up with IPv6 address as expected
# ifconfig ppp0 | grep inet6
inet6 addr: fe80::XXXX:XXXX:XXXX:XXXX/10 Scope:Link

That doesn't help you much, because you got only a link-local address assigned.
So you can ping6 the ppp server on the other side, but never reach the IPv6 world. 

Now remembering and digging through the scripts and written document
http://www.deepspace6.net/projects/initscripts-ipv6.html#id2867720 (contain some
bugs, but anyway)

I solve the missing global prefix issue some time ago by triggering radvd to
distribute RAs over the PPP link, so client gets prefix and default route.

I will start now digging around whether current ppp-2.4.2 has already a feature
to distribute a global IPv6 prefix to client (but I don't believe).
If not, we have to implement the call of dhcpv6 client after IPv6 PPP comes up 
on client side called by "/etc/ppp/ipv6-up"...

Comment 7 Peter Bieringer 2005-09-22 16:15:23 EDT
Bad news, it looks like in IPV6CP only interface identifier and compression was
defined:
http://www.networksorcery.com/enp/protocol/IPv6cp.htm
http://www.networksorcery.com/enp/rfc/rfc2472.txt

So currently no global prefix can be distributed via IPV6CP.

There exists a new draft, but I can find nothing about definition of additional
addresses:
http://www.rfc-editor.org/internet-drafts/draft-ietf-ipv6-over-ppp-v2-02.txt

Hmm, that's very strange at all because DHCPv6 is working since some month, PPP
over IPv6 is defined (and working) since some years...looks like nobody has ever
thought how to assign a global prefix to the PPP client over the years in an
easy way like in IPv4 - what now?
Comment 8 Pekka Savola 2005-09-23 00:30:40 EDT
Yes, PPP in v6 is not really meant for address assignment -- that has been
intentional -- PPP designers haven't wanted to extend it any further.  You'll
need to use manual configuration, Router Advertisements, DHCPv6, or other
mechanisms for it.
Comment 9 Peter Bieringer 2005-09-23 01:26:39 EDT
I digged further in my scripts and found, that default route for ppp is already
supported. If using e.g.

File: /etc/sysconfig/network-scripts/ifcfg-ppp0:
DEVICE="ppp0"
ONBOOT="no"
DEMAND="no"
MODEMPORT="/dev/ttyS4"
LINESPEED="115200"
DEBUG="yes"
PAPNAME="yourPPPaccount"
PPPOPTIONS="debug nomp ipcp-accept-local ipcp-accept-remote ipv6cp-accept-local
+ipv6 ipv6cp-use-ipaddr"

IPV6INIT="yes"
IPV6_DEFAULTDEV="ppp0"

Then a default route should be set.

It's also possible to configure a dedicated IPv6 address:
IPV6ADDR="2001:db8:0123:4567::1/64"

But I also found, that there is a major problem if more then one ppp interface
exists or the name for config file is e.g. ifcfg-ppp2. Looks like it's not
possible to hardwire the real name of a ppp device. This is already partially
solved, /etc/ppp/ipv6-up uses arg #6 to get the config device name.
Unfortunatelly, it only source the config and call ifup-ipv6 with the real
device name (which now try to read e.g. ifcfg-ppp0 and setup given values on
ppp0 also...). That's a mis-design and mean, that the required parts for proper
interface setup (around 100 lines of code) need to be copied from ifup-ipv6 to
/etc/ppp/ipv6-up (fortunatly, all the 6to4 stuff is not needed here).

This issue also prevents the proper use of /etc/sysconfig/static-routes-ipv6 also.

I will rewrite /etc/ppp/ipv6-{up,down} next week to solve this issues completly
for client and server side (where similar problems exist).

@Pekka: what do you think about that instead of triggering radvd all the time if
ppp for client come up starting a new instance of radvd only for that interface
with a generated config? Or is there any other tool available for sending some
RAs through the new ppp interface using very long lifetime (something like 
send_ipv6_ra <device> <count> <prefix> <lifetime> <flags>).
Comment 10 Pekka Savola 2005-09-23 01:50:01 EDT
Umm, wasn't the original problem that 'service network restart' results in the
v6 default route getting lost (at the client side).  We should focus on that first..

What you write about multiple PPP devices may be true, but I'm not sure that's
something that needs to be fixed (or at least fixed now).  That is, I think
multiple ppp interfaces should be pretty rare, except for the PPP terminator
boxes (which very rarely run Linux, and likely already need to adapt their
scripts already).  If that's the case, we don't need to deal with radvd, because
it's being run manually by the admin of the ppp terminator box.

Now, radvd could be run at the ppp client as well, but only if prefix has been
delegated (using dhcpv6 or manually).

Yes, unfortunately for Linux, there isn't really a command-line tool to send
single RA's, RS's, or similar :-( but that shouldn't be needed here.
Comment 11 Peter Bieringer 2005-09-23 02:21:01 EDT
@Eric: could you please specify whether you're using persistent PPP connection
with dial-on-demand?

I'm asking because the IPv4 default route is set by pppd itself (option
"defaultroute") and not by any script. Such support is missing in pppd for IPv6
at the moment.

If you need the default route even if PPP link is still down at least ifup-ppp
or ifup-routes needs to be extended. But here we run into a consistency problem:
Let say you configure ifcfg-ppp2, pppd on setup creates ppp0. This information
cannot be retrieved by script after starting pppd, only in /etc/ppp/ip{v6}-up,
the information REALDEVICE=$1 (here: ppp0) and LOGDEVICE=$6 (here: ppp2) is
given and only here we have enough information to set default route through the
proper device.

My opinion: support for default route in case of manual client dialup is not a
problem (and will be better supported next days...), in demand case, pppd needs
to be extended like for IPv4.
Comment 12 Eric Moret 2005-09-23 04:38:26 EDT
I am running a persistent ppp connection over a DSL line with PPPoE and native 
IPv6. AFAIR, bringing up a ppp link only assigns a link local address, this is 
by design to save on unused IP addresses kind of like running an unumbered 
interface in IPv4 to save addresses. Global/public IPv6 addresses are assigned 
either by radvd or dhcpd, both of which require manual configuration on the 
client side.

The problem I am having here is that I need to manually assign a default ipv6 
route despite the fact that both DEFROUTE=yes and PPPD_EXTRA="ipv6, " are set 
in ifcfg-ppp0. When I do "service network restart" I should not loose my 
default route and I should not have to manually add the default route as I 
currently do in /etc/ppp/ipv6-up.local like:
ip route add 2000::/3 dev ppp0

Your suggestion of reassigning to ppp package for matching the IPv4 default 
route assignment might just be what needs to be done here.
Comment 13 Peter Bieringer 2005-09-23 04:56:55 EDT
Indeed, pppd needs to be extended here because of a second reason: ADSL setup
never comes back to ifup-ppp, so if it would be possible with some magic to add
IPv6 default route by script after ppp setup, ifup-ppp and the adsl-connect
script need to to be extended - not nice.

Anyway, I will fix the ppp setup to remove the device name inconstency. It
wouldn't help you 100%, but it should solve your current workaround by adding
default route in /etc/ppp/ipv6-up.local.

I had already began working on that, I will send you a note if committed to
initscripts-ipv6 cvs.
Comment 14 David Woodhouse 2005-09-23 05:48:29 EDT
On a related note... my ISP is about to deploy native IPv6 over PPP, and they're
wondering how to do address allocation. 

Ideally, DSL routers using 6to4 could automatically assign a /64 to each
internal interface, derived from the 6to4 2002:xxxx:yyyy::/48 network. 

Is there anything we could do for IPv6 over PPP which is analogous -- where the
ISP's side of the PPP link could tell the DSL router the IPv6 network which is
assigned to it, for it to assign to _its_ clients?
Comment 15 Pekka Savola 2005-09-23 05:57:39 EDT
The ISP basically has to deploy DCHPv6 prefix delegation on top of the PPP link
(RFC3633) if manual config is too much of a pain..
Comment 16 Peter Bieringer 2005-09-23 06:07:51 EDT
I will play around with dhcp6s on Linux for ppp next days (for eth-links I got
already success...have to update howto next days also).

But I think, it can't be done with dhcp6s on Linux PPP server side...this
software also has interface scopes, e.g.:

interface eth0 {
...
        link AAA {
                range fec0:0:0:f101::1000 to fec0:0:0:f101::ffff/64;
                prefix fec0:0:0:f101::/64;
        };
};

How tell dhcp6s that listen on interfaces, which aren't currently exist (like
dialin ppp1, ppp2, ...) - same problem rises up like in radvd.

Anyone knowing about another DHCPv6 solution which covers this already?
Comment 17 Peter Bieringer 2005-09-23 06:25:26 EDT
FYI, taking a look into Cisco's IOS 12.4 manual it looks like they uses RAs per
dial-in interface, and are able to fetch prefix from RADIUS:

http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/products_command_reference_chapter09186a00801d660f.html
http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/products_command_reference_chapter09186a00801d660f.html#wp1763205

Don't know, how other vendors will solve the problem.
Comment 18 Peter Bieringer 2005-09-23 10:54:22 EDT
@Eric: can you please try newest /etc/ppp/ipv6-{up,down} from initscripts-ipv6 CVS 
http://www.deepspace6.net/projects/initscripts-ipv6.html

ipv6-up should be fixed now.

BTW: I have already replaced the radvd trigger mechanism by dedicated radvd
start per dial-in (with autogenerated config). Works fine here, should easily
support up to 256 ppp lines, each got it's own /64 - anyone out who can test it??
Comment 19 Eric Moret 2005-11-21 19:17:15 EST
(In reply to comment #18)
> @Eric: can you please try newest /etc/ppp/ipv6-{up,down} from initscripts-ipv6
CVS 

Sorry I cannot test from CVS. I don't have any other host that runs an ipv6
gateway with ipv6 ppp and the one I am using is in production environment so
cannot go down :(
Comment 20 Bill Nottingham 2006-08-01 10:36:31 EDT
Sorrt about the delay. Peter, can you attach a patch for /etc/ppp for current
Fedora releases? I don't think we can realisitically push this for earlier RHEL,
but we can get it in the tree for RHEL 5.
Comment 21 Peter Bieringer 2006-08-01 11:28:36 EDT
The current ones are really rather old (2002). 

Should this patch also include the new radvd trigger setup? The current
implementation of radvd triggering is not working proper. The one I implemented
now (one radvd is started per ppp server interface is working for IPv6 dial-in
servers).

For clients, this is not an issue and can be left out.

Current files are available here:
http://cvs.deepspace6.net/view/initscripts-ipv6/common.stripped/etc/ppp/

BTW: should we use this chance to update more of the IPv6 related initscripts?
Looks like they are small and are only minor.
Comment 22 Bill Nottingham 2006-08-01 11:47:02 EDT
If the triggering isn't working properly, no, don't include it. We can update
more of the other scripts, but that's probably best left as a separate bug.
Comment 23 Peter Bieringer 2006-08-02 01:53:40 EDT
Created attachment 133462 [details]
patch for /etc/ppp/ipv6-up

as requested, new radvd trigger mechanism is currently left out in this patch
Comment 24 Peter Bieringer 2006-08-02 01:55:22 EDT
Created attachment 133463 [details]
patch for /etc/ppp/ipv6-down

as requested, new radvd trigger mechanism is currently left out in this patch
Comment 25 Peter Bieringer 2006-08-02 02:16:24 EDT
Created attachment 133464 [details]
cosmetic changes to some IPv6 related initscript files

Patch for some IPv6 related initscript files, 99% cosmetics (remov e.g. some
trailing spaces) - too cosmetic for a new bug ;-)
Comment 26 Bill Nottingham 2006-08-02 11:15:29 EDT
Added to CVS.

At this point, we are not pushing IPv6 fixes back to RHEL 3 and RHEL 4 - this
will be fixed in RHEL 5.

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