we observed certain packets goes ping-pong on p2p link.
it depends on:
- how p2p links are implemented on the stack
- how routes to p2p links are configured
(this highly is implementation dependent)
but anyway, i would like to have your second opinion.
KAME code has a special code (disabled by default) for this case, like
- suppose I am a router. if the packet comes in from interface Ix,
and goes out again to Ix, and interface Ix is a p2p link, I do not
forward the packet. instead, I'd emit ICMPv6 no route to host.
questions:
- is my scenario make sense? or do we have some implementation mistake?
- is the KAME special behavior look legal?
- are there any implementation that chokes with it? for example,
are there implementation that do not check the local address on p2p
link, and expect the packet to come back again?
- if it looks legal, what ICMPv6 type/code should be used?
timexceeded?
- how should we document?
(if you are curious about the source, see #ifdef PROHIBIT_P2PREDIRECT
in sys/netinet6/ip6_forward.c in KAME tree).
itojun
scenario:
suppose we have routers "A" and "B", and they are connected by some
p2p link (tunnel, ATM, whatever).
case 1: consider link local address (La and Lb).
A (La) --- (Lb) B
A has fe80::/10 (or fe80::/64 depending on your implementation)
route pointed to the p2p link. if A emits a packet with Lx (!= Lb) as a
destination, it will reach B. then B forwards it back to A. then A forwards
it back to B, ... until hoplimit field goes 0. also, they would emit
ICMPv6 redirect to the peer, since the packet gets forwarded back again to the
incoming interface.
case 2: consider non-link local address (Ga and Gb). Ga and Gb shares a
single /64 prefix, P::/64.
A (Ga) --- (Gb) B
A has P::/64 route pointed to the p2p link. if A emits a packet with
Gx (P::x, and Gx != Gb) as a destination, it will reach B. now, the same
story as above. note that, as P::/64 is global or sitelocal prefix,
remote node can generate the ping-pong packet and chew up the bandwidth
on the p2p link (so it may be a security issue).
NOTE: gated models p2p links differently.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
