Redhat – Configuring ppp to support IPv6

Have you actually requested a subnet, and not just the tunnel? You need another subnet routed to your tunnel endpoint, you CANNOT use the tunnel subnet directly:

https://www.sixxs.net/faq/connectivity/?faq=usingsubnet

https://www.sixxs.net/home/requestsubnet/

How do I give connectivity to other hosts on my subnet?

The easiest way to use your subnet is to assign a /64 per network and then setup a Router Advertisement server. As SixXS serves out per tunnel a /48 (a so called site-prefix) as subnets you have the possiblity of having 65535 /64's and thus subnets inside your site. A /48 is an end-site and should thus not be delegated to other administrators.

Under Linux this Router Advertisement (RA) server is called radvd, *BSD (KAME stack) calls it rtadvd. Clients can then be configured using RFC 2462 aka "IPv6 Stateless Address Autoconfiguration".

Note well that in tunnels from the /64 only ::1 (the PoP) and ::2 (your endpoint) can be used as the rest is not routed.

The 'default routed /64' is a routed subnet though and is routed to the endpoint of your tunnel and thus can be used directly for connecting hosts on a seperate link behind your tunnel. If you need to serve multiple /64s behind your endpoint you will need to request a subnet though.

A site is defined as a network with one single administration. The moment a change occurs in administration, one is in a different site. Thus if you have 1 building operated by administration group X and another building operated by admin Y then those are two sites. Of course, when group X and Y, both administratively fall under group A, they can still be taken as to be a single site where wanted.

"peer refused to authenticate" is the explanation. It's logged by your client's pppd, so the server is the peer that it's referring to.

PPP is not inherently a client-server protocol. It's symmetric. That means each end of the connection can require the other end to authenticate itself. In ISP-like configurations, authentication goes only one way. The client proves its identity to the server, but the server doesn't prove its identity to the client.

If you want to use that type of setup, you have to give the client's pppd the noauth option, which tells it not to require authentication from the server. Adding it to /etc/ppp/peers/myisp should do it.

If you want to authenticate both ways, that should be doable too.

update

Since you've posted the latest logs, the new problem is the login option. login means that the client's PAP password is expected to match the user's password in the system user database (i.e. /etc/passwd and friends). If you're trying to define the password exclusively through pap-secrets, remove the login option.