On 20/09/2008, at 10:18 AM, Christian Huitema wrote:
I do not know the history and the reason for the "MUST" in this paragraph, and I agree with Nathan's statement that this section in the RFC creates a problem if we implement a strict adherence to the RFC.The requirement came out of a desire for traceability and testability, and was pushed during the AD review of the draft.
See my comments at the end, they are basically the same as what I'd have written here.
Many experts were concerned that anycast addresses defeat ingress filtering, and would facilitate various forms of spoofing attacks. Using the "real" address of the gateway as a source address would prevent that.
Is the suggestion here that strict uRPF would cause a problem?A network with strict uRPF on multihoming links will have no doubt realised that it's broken for many other things, and turned it off.
On the other hand, if we're talking about some kind of stateful firewalling (IPv4), that doesn't really work with 6to4 anyway. Infact, stateful firewalling and this requirement would make things worse.
They were also concerned that with anycast addresses, it would be difficult to test which gateways are up or down, or that the user would have no recourse if the quality of service on the anycast path of the moment was low.
What would the user's recourse be?If you mean that the user would switch to another relay, then while this might be something that you or I would do, in a world where 6to4 is enabled by default on many platforms, the vast majority of users would not. The way I see it, is that we're at a trade off here, with 2 options:
1) Leave this as it is, less providers deploy relays, but the relays we do have are more easy to debug. IPv6 over 6to4 performance globally is not good, we cannot put services on IPv6 because of performance problems.
2) Remove the paragraph, more providers deploy relays, but we have very little relay debugging available to us. IPv6 over 6to4 performance globally is improved, we can start putting services on IPv6 without performance problems.
Continuing to allow IPv6 over 6to4 to be broken for the sake of a bit of debugging is, in my opinion, a bad thing. We now understand the things that break 6to4, and we are able to test for them without 6to4 relays being on non-RFC3068 addresses.
Because of the implementations of many vendors, (2) has already been done. Let's remove the paragraph to alleviate concerns of these providers, and get on with it.
-- Nathan Ward