1. Absence of ND on p2p links is logical. There is no need for ND. There are only two neighbors. We always know L2 destination address, why should we use any mechanisms to resolve it ?
2. You are right, "forward packets back to the link they are coming from" is not normal behaviour for p2p links. But only for P2P(not for Ethernet p2p "face-to-face"). Unfortunately, this behaviour is normal for a lot of vendors because of specificity of hardware forwarding. So using /127 looks like a good solution for this problem. 2010/3/31 Philip Homburg <[email protected]> > In your letter dated Wed, 31 Mar 2010 15:20:55 +0400 you wrote: > >I think the "PING-PONG issue" reason alone is sufficient to progress > >draft-kohno-ipv6-prefixlen-p2p. Using /64 and other short prefixes is very > >convenient for DDoS-attackers. With /64 prefixes they can utilize > bandwidth > >of p2p(PPP) link up to 255(HopCount) times more, than actual bandwith they > >generate... > > I don't really understand this argument. If ND is enabled then this can't > happen. So the problem is caused in the first place by disabling ND. > > Now, the only way a packet can actually ping-pong on a link is if both > routers > are prepared to forward packets back over the interface they are coming > from. > Now, on any link where a router is advertising itself as a default router > this serves a usefull purpose, but on a router-to-router link sending a > packet back to the link it was coming from is a clear indication of a > routing loop and you can just as well drop the packet. > > So you have to both disable ND and be willing to forward packets back to > the > link they are coming from to trigger this problem. > > > -- Best regards, Egor Zimin
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
