Hi,
On the plenary tonight, Lorenzo Colitti from Google mentioned a
looping problem with p2p interfaces and using non-/127 prefix length.
He said they had asked the vendors to implement an RFC fix for this
but vendors had refused (citing loss of forwarding performance). I
think this may call for more attention here.
The ICMPv6 spec (RFC4443) has the following new requirement (stemming
from draft-ietf-ipngwg-p2p-pingpong) since its predecessor:
One specific case in which a Destination Unreachable message is sent
with a code 3 is in response to a packet received by a router from a
point-to-point link, destined to an address within a subnet assigned
to that same link (other than one of the receiving router's own
addresses). In such a case, the packet MUST NOT be forwarded back
onto the arrival link.
In the last sentence seems to mean the triggering packet. If so,
making this kind of forwarding specification inside ICMP spec is
interesting, and it is also interesting because the ICMP
implementation must watch out for packets which aren't destined to the
local node.
AFAIK, this issue is not touched in any other RFC (for v4 or v6).
This is more or less well-known behaviour on IPv4 side and as such
long prefixes are not used on point-to-point links.
Based on my quick test with Juniper routers both IPv4 and IPv6 packets
happily loop back and forth (no forwarding checks, ping shows "time to
live exceeded"), and both ICMPv4 and ICMPv6 packets get originated
just fine (traceroute shows looping behaviour). (Note: Juniper claims
conformance to RFC2463, not RFC4443.)
I wonder how other _hardware-based_ implementations behave? At least
Cisco claims RFC4443 compliancy but I don't have p2p interfaces to
test this. I wonder if there are other vendors who have found
implementing RFC4443's apparent "thou shalt not forward back"
unfeasible?
If that part in the implementation has widely been seen as a problem,
given that IPv6 architecture (in paper) requires /64 addressing, and
there are other reasons why /127 is broken (RFC3627), the IETF might
need to do something.
Workarounds are at least using distinct /128 addresses and static
routes or a routing protocol or just link-local addresses.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
