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

Andre Tomt wrote:

On ons, 2003-06-18 at 17:20, Jeroen Massar wrote:

quoted

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>

quoted

quoted

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