From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jeroen Massar" Subject: RE: (usagi-users 02435) Re: IPv6 bugs introduced in 2.4.21 Date: Thu, 19 Jun 2003 01:03:56 +0200 Sender: netdev-bounce@oss.sgi.com Message-ID: <001501c335ed$e54dfa80$210d640a@unfix.org> References: <1055957670.7478.227.camel@slurv.ws.pasop.tomt.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit Cc: , Return-path: To: "'Andre Tomt'" , In-Reply-To: <1055957670.7478.227.camel@slurv.ws.pasop.tomt.net> Errors-to: netdev-bounce@oss.sgi.com List-Id: netdev.vger.kernel.org Andre Tomt wrote: > On ons, 2003-06-18 at 17:20, Jeroen Massar wrote: > > Notez bien that many people use :: and ::1 and ::2 etc as a unicast > > address. > > I'm getting majorly confused now, things I've taken for granted with > IPv6, and used in IOS, *BSD, Windows and Linux for ages, > suddenly stops working with Linux, and is wrong (it seems). You have quite some short ages. IPv4 isn't even around for halve an age yet... though it's coming close :) > Is there anything wrong about using $network::1/64 ? Other than not > being EUI64.. Absolutely not. Actually one can fill in the last 64 bits by himself. Though there are some bits that should be untouched because of DAD and some rules. > 2001:730:f:1:: is invalid as a unicast address? (note it > still works on ptp-interfaces as long as you set nexthop to the dev, not the > ip address - but I expected that.) > > /127's does not match two addresses (:2a :2b in this case)? > > > > > > The /127 matches both 2a and 2b, why does it end up at localhost? > > > > Routing, remove the route which goes over lo. > > There is no route that goes over lo, other than one for a different > prefix, wich is set to avoid loops on unmatched prefixes. > unreachable 2001:730:f::/48 dev lo metric 2048 error -101 > mtu 16436 advmss 16376. Setting an unreachable for a prefix routed to your destination is very good practice indeed. > Because of routing? I don't understand. the /127 route matches both 2a > and 2b, and has no conflicting routes. It _should_ end up on the > aorta-dev as far as I can see. > > 2001:730:3::1:2a/127 via :: dev aorta proto kernel metric > 256 mtu 1480 advmss 1420 > (kernel autogenerated) Via :: on device aorta.. which explains it quite well. Both IP's go to the device and over the wire to the other side. But packets coming back get dropped as they have no destination on your box. Use tcpdump and you'll see :) > I tried removing it, and add a route without the via ::, > still does not > work like before. non-routed traffic still goes to the bitbucket, but > routed traffic works as well as ever. As said we still use /127, and will keep on using /127's, at the IPng POP. My routing table entries for the tunnel currently look like: 3ffe:8114:1000::26 dev sixxs metric 1024 mtu 1280 advmss 1220 3ffe:8114:1000::26/127 via :: dev sixxs proto kernel metric 256 mtu 1280 advmss 1220 As you can see I've added a seperate route to the 'remote' side (3ffe:8114:1000::26). This way the packets go along quite cleanly. Btw this is on 2.4.21-rc1 and on that system I had to remove the routes to lo too. Unicast my :) Greets, Jeroen