Re: [PATCH] IPv6: Fix Prefix Length of Link-local Addresses

On Thu, Oct 10, 2002 at 01:54:32AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@?(B wrote:

In article [ref] (at Wed, 9 Oct 2002 17:00:18 +0100), Derek Fawcus [off-list ref] says:

quoted

All link local's are currently supposed to have those top bits
('tween 10 and 64) zero'd,  however any address within the link local
prefix _is_ on link / connected and should go to the interface.

i.e. it's perfectly valid for me to assign a link local of fe80:1910::10
     to an interface and expect it to be work,  likewise for a packet
     destined to any link local address to trigger ND.

First of all, please don't use such addresses.

Why not,  they are perfectly legal?

By spec, auto-configured link-local address is fe80::/64
and connected route should be /64.

Yes auto-configured have fe80:0:0:0: in their upper 64 bits,  but that
is just for autoconfigured addessses.  That is a seperate issue to which
prefix desinates link local.

Connected routes don't have to be /64,  things work correctly even if
one picks any other value.  

If you do really want to use such addresses (like fe80:1920::10),
you can put another route by yourself, at your own risk.

No - what I'm saying is that all link locals should go to the link.

There is no risk inherent in using such an address or link local prefix.

If a mechanism is required such that autoconfig generates the correct
type of address,  then add it.  But that doesn't _require_ that
the connected route be /64.

I happen to use link locals like the quite often,  since it makes
testing and reading packet traces a hell of a lot easier.

We should not configure in such way by default.
and, we should even have to add "discard" route for them 
by default for safe.

Why.  In what way is it not 'safe' to have any link local address
sent onto the link?  They'll either reach a destination or not,
but given that they'll never leave the link,  they can't be inherently
unsafe.

DF