Hi, As far as I understand it without seeing a complete "life cycle" of a multihoming failover, this proposal only works because of a three-way collaboration between both ISPs concerned and the site. Unless I've misunderstood something, that is almost the same as is required to make the draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat solution work too. In both cases, something is needed to avoid packets with ISP A's prefix being discarded by ISP B's ingress filters. The fact that their internal prefix has been translated in one case is beside the point.
If that is correct, this common aspect should be in its own draft. Then we can see a straight comparison between the two approaches. I'd also like to see a detailed goal-by-goal comparison with the goals defined in RFC 3582. Back in the MULTI6 WG, that was the approach we took in comparing proposed solutions. The multihoming-without-ipv6nat draft notes that e2e address transparency wasn't listed as a goal in RFC 3582. Having been co-chair of that WG, I'm pretty sure that's because we never imagined anyone proposing anything else for IPv6. That was obviously a failure of the imagination. But apart from that, I don't think it's reasonable to sweep it (and the referral problem that derives from it) under the carpet. It's a problem faced by essentially every distributed app. So I think all proposals for multihoming that affect e2e address transparency need to analyse their impact on referrals. Regards Brian _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
