On Thu, Oct 10, 2002 at 01:54:32AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@?(B
> In article <20021009170018.H29133@xxxxxxxxxxxxxxxxxxx> (at Wed, 9 Oct 2002
> 17:00:18 +0100), Derek Fawcus <dfawcus@xxxxxxxxx> says:
> > 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