Date: Sat, 31 Aug 2002 00:58:48 -0700 From: Nick Sayer <nsayer@quack.kfu.com> To: freebsd-net@freebsd.org Subject: IPv6 PPP - the real issues Message-ID: <3D707738.6050805@quack.kfu.com>
next in thread | raw e-mail | index | archive | help
Ok. I sort of misunderstood the problem(s). The current behavior is this: 1. When you create a tun device, it ends up getting a non-p2p link-local address. This winds up confusing things because ppp will bring up a link-local p2p address pair, and outgoing packets wind up with the wrong source address. Deleting the spurious link-local address makes link-local connectivity work with Brian Somer's latest stuff. I believe that "auto_linklocal=1" is doing this. I suspect that that behavior is inappropriate for tunnel devices. 2. I can establish link-local connectivity just fine, but attempting to set up an rtadvd on the 'server' and and an rtsol on the 'client' end doesn't seem to do anything. I can run a tcpdump and see the router solicitations head upstream and the router advertisments in reply go downstream, but nothing ever gets added. If I'm not mistaken, the kernel is responsible for processing received router / prefix solicitations, right? So why isn't it processing these ones? 3. If I manually make up a /64 and set up an anycast alias for the 0 address (all-routers) and a manual route to that subnet on the tunnel device on the server, and manually add that prefix on the client, everything works correctly. The fact that I must add the prefixed address manually to the client is, I believe, more or less the last stumbling block. My goal is to document the process of setting up an IPv6 only dialup ISP. Customers would get a dynamic 64 bit prefix, which they could share with neighbor discovery proxying if they want. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D707738.6050805>