Re: implications of 6to4 for v6coex

[james woodyatt <jhw@apple.com>]

On Sep 19, 2008, at 15:18, Christian Huitema wrote:
> [Nathan Ward 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.

I surmised correctly what motivated the requirement.

> 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.

Clearly, ingress filtering of 6to4 packets should be looking at the  
embedded IPv6 source address, rather than the outer IPv4 source  
address, right?  A new special-use block could be reserved for making  
IPv4-only ingress filtering exceptions apply to transit from 6to4  
relays.

> 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.

A new special-use block would retain this testing and tracing  
function, though it might be confusing for tracers to be receiving  
6to4 packets with source addresses that originate at relays in  
different addressing realms.  Other protocols, e.g. ICMP, would be  
guaranteed to come from relays in the local addressing realm.

I'm beginning to see where the complications here spin out.  There is  
clearly something broken about 6to4, and I'm not sure how to fix it.   
Can it be saved as a standard?


--
james woodyatt <jhw@apple.com>
member of technical staff, communications engineering