As far as I can tell, the ping-pong behavior is a bug.
The operators do need some help from the vendors working around the bugs
until the vendors can fix them.
Separately, it appears that the operators want to use /127 for pt-to-pt
inter-router links, and I see no good reason to say that they can't. So
we probably should modify the specs to permit this.
(Whether I think this is a a great idea or a false economy is
irrelevant. This particular case does not conflict with the various
reasons for wanting /64s as a general model.)
Yours,
Joel
Egor Zimin wrote:
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]
<mailto:[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
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
