RE: (usagi-users 02435) Re: IPv6 bugs introduced in 2.4.21

["Jeroen Massar" <jeroen@unfix.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)?
> 
> <snip>
> 
> > > 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 <peep> :)

Greets,
 Jeroen