> | do you think it okay even if outsiders (bad guys) can chew your
> | bandwidth? i think not.
>
>No, nor do I.
>
>But you are proposing to fix this by special case code. I'd prefer to
>fix it by correctly configuring my routing table.
>
>That is, if the only thing out the P2P link in a specific address range
>is 1 address, I should have a /128 in the routing table, not a /64.
>
>If for some reason I have chosen to install a /64 for the link, then I
>must want all those packets to get sent down the P2P link.
again, this really depends on how an implementor model p2p interface
on their implementation. it seems to me that there's no common
consensus, at all, on how p2p interfaces gets implemented, and
how these routes to p2p gets advertised to neighbors by routing
protocols. cisco and gateway are the popular interpretation, i guess.
i guess it hard to standardize the interpretation/model of p2p
interface.
if i know the peer's address, i can install blackhole route for /64,
and specific route for /128 (for my interface address and the peer's).
however, it is not always possible to know peer's address beforehand:
- we don't always know peer's address (think about linklocal address
- fe80::/10), and
- we don't run NS/NA on L2 without hardware address, so
- we don't know the peer's address.
i would like to solve the problem for this case.
>On the other hand, if the /128 is all that exists, then regular forwarding
>decisions (with no special cases) will arrange that packets that shouldn't
>get forwarded down the link don't get sent that way.
actually, "use the default route" can be dangerous here. on 6bone, we
see a lot of bogus unicast NS/NA toward global address (probably due to
NUD) sent to offlink destination over wrongly-configured default
route. we are seeing them as the following kernel printf() messages.
since they have TTL=255, they go all the way to the final destionation
(like www.kame.net). i hope to help people configure the boxes right,
but if there are millions people (i guess there will be) i can't
keep up.
May 1 13:26:29 apple /netbsd: nd6_ns_input: invalid hlim 249
May 1 13:26:48 apple last message repeated 8 times
May 1 13:45:06 apple /netbsd: nd6_ns_input: invalid hlim 249
May 1 13:45:34 apple last message repeated 11 times
itojun
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
