Re: draft-ietf-ipngwg-p2p-pingpong-00.txt vs RFC4443

[Pekka Savola <[e-mail]>]

On Tue, 17 Aug 2010, Fernando Gont wrote:
> AFAICT, it does. It says: "....and the destination address on the packet
> seems to be on-link (in terms of Neighbor Discovery) on the
> point-to-point interface". Or am I missing something?

Yes, you're right.  I was not reading the text carefully enough. 
(Though "is on-link" vs "is of the same subnet prefix" are 
semantically two subtly different checks. Not sure if it matters in 
this case.)

> It seems that the point is not really that of reduced performance, but
> rather that complying with this requirement would require a change in
> the silicon?
>
> If that's the case (i.e., no real performance implications), then it
> looks like an appropriate fix for this issue. -- which does not
> necessarily argue against /127 prefixes, as there are other reasons for
> using them (or, put another way, let's not correlate *this* with the
> fight over /127 prefixes).

This issue was initially brought up by Google IPv6 presentation, 
proxying Juniper's statements, so it would probably best if either of 
them could clarify.

>> FWIW, "Packet may be forwarded back on the received interface" is
>> actually, AFAIK, used in certain PE routerscenarios where you ping
>> yourself over a p2p link.
>
> Is the echo request/response really forwarded back on the received
> interface? (isn't the *response* that is forwarded back on the received
> interface?)

You're probably right.  I was likely confused on how this is actually 
done, and right now I can't find any written references on the "p2p 
self ping" troubleshooting technique I seem to recall. Olivier's note 
about the different scenario may still apply.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings