Subject: RE: (ngtrans) shipworm and anycast Was: Review of draft-ietf-ngtrans-shipworm-03.txt

From: "Christian Huitema" <[email-masked]>
Date: Wed, 30 Jan 2002 14:32:16 -0800

Thomas,

I agree with you, each alternative has its drawbacks. The two impacts of
the reference solution (#1) are routing and ingress filtering. If you
think about it, none of that is terribly different from the standard
IPv4 situation today. Solution #3 makes ingress filtering simpler, at
the cost of a lost of service (no /64), larger IPv6 routing tables and a
need for explicit configuration in the client. Solution #2 preserves the
/64, has a limited impact on IPv6 routing, and has a limited but
significant ingress filtering issue.

Contrary to the reviewers, I am not horrified by the IPv6 routing issue.
Dumping the shipworm packet from IPv6 to the nearest relay is in many
ways similar to the current "hot potato" paradigm for inter-domain
routing. The path to the destination will follow the most direct route
on the IPv4 network. Arguably, if the traffic had been pure IPv4, it
would have followed precisely that path. In fact, we can argue that
solution #2 and #3 are both suboptimal in this respect.

The impact on ingress filtering is legitimate. At some level, there is a
simple answer: an ISP should only accept packets from the anycast source
from an interface that also announces a route to that anycast source.
The issue is probably more one of "transit agreement verification"
rather than a straight issue of ingress filtering. I would really like a
comment on this. Do ISP actually perform ingress filtering at peer
boundaries? At customer boundaries?

-- Christian Huitema