Bug 143452

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.

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.

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

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.

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

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

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?

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.

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

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.

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

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.

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.

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?

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

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?

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.

@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??

(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 :(

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.

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.

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.

Created attachment 133462 [details]
patch for /etc/ppp/ipv6-up

as requested, new radvd trigger mechanism is currently left out in this patch

Created attachment 133463 [details]
patch for /etc/ppp/ipv6-down

as requested, new radvd trigger mechanism is currently left out in this patch

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 ;-)

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.