Quick poll: When a 6to4 relay encapsulates v6 traffic and sends it to a 6to4 host over v4, should the source address be 192.88.99.1 or the relay's v4 unicast address? RFC3056 and RFC3068 are both silent on this decision, as far as I can tell. If anything, I believe that RFC3068 is slightly hinting that 192.88.99.1 was intended, because one of the suggestions in there is to include the v4 unicast address in the BGP aggregator attribute for troubleshooting purposes. If the relay router were returning its unicast v4 address in its replies, I'm not sure why an additional way of revealing the unicast address would be necessary. My take is that it should use 192.88.99.1. It makes the flow between the relay and the client more symmetric (one flow instead of two, if you're looking purely at layer 3). Stateful firewalls are more likely to do the right thing. Network administrators are going to have a better chance of understanding why 192.88.99.1 is sending loads of traffic to systems on their network, instead of some random unicast IP. This is also how the majority of 6to4 relays that I can see from our network operate. Arguments supporting this position: http://www.ops.ietf.org/lists/v6ops/v6ops.2004/msg00253.html -- "As an anycast address, 192.88.99.1 should probably not appear as a source address, however for reasons related to both operational and software it does." draft-savola-v6ops-6to4-security-02.txt -- "Every 6to4 Relay MUST configure and use "192.88.99.1" as the source address of packets that are encapsulated towards 6to4 Routers." RFC3964 -- "This threat is caused by 6to4 deployment but can be avoided, at least in the short-term, by using 192.88.99.1 as the source address." The opposing view is that relays should use their own unicast IP as the source. This makes troubleshooting 6to4 problems easier, and may be required for some networks with stricter anti-spoofing rules. I'm not sold on either argument, but not enough to say it's wrong. Regardless of which is right, I think the current RFCs are ambiguous on this point, and that it should probably be clarified - even if the clarification is to say that both are acceptable. If any of the original RFC authors are watching, how did you see this working? Or was this intentionally left out as an implementation detail? The reason this is coming up right now... Since we've started running a 6to4 relay, we've had a few complaints show up at our abuse@ box asking what this 192.88.99.1 host is on our network, why its WHOIS doesn't make sense, and why it's sending them traffic. It occurred to me that if there was a PTR record for 1.99.88.192.in-addr.arpa that it might seem slightly less suspicious in firewall logs, or at least give network operators unfamiliar with 6to4 enough information to know what to look up. i.e. if you see 199.7.83.42 showing up talking to one of your servers, do you recognize that IP immediately? If not, does the fact that it resolves to l.root-servers.net give you enough of a starting place to know where to find out what it is? Especially think about novice network operators who need a push where to look. Currently 99.88.192.in-addr.arpa is delegated to ARINs name servers. Their servers return SERVFAIL on queries sent for that zone. From talking to a few people at ARIN, they seem a bit unsure why their nameservers were used for that zone, and were never given instructions from IANA to add any records to it at all. So, I took this to IANA who said "Good point, but our understanding is that relays shouldn't ever be using that IP to send any packets - is this really a problem?" I disagreed, and was asked if I could find a consensus on this matter here. So, does anyone feel strongly one way or another about which address a 6to4 relay should use when encapsulating packets? Additionally, is anyone strongly for or against adding a PTR record for 192.88.99.1 that might help document its use better? -- Kevin |