Re: 6to4 anycast IP as source address / PTR record

[Brian E Carpenter <brian.e.carpenter@gmail.com>]

On 2008-01-31 13:33, Kevin Day wrote:
> 
> 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?

This kind of makes my head hurt because...
> 
> RFC3056 and RFC3068 are both silent on this decision, as far as I can
> tell. 

Naturally, 3056 is silent because the notions of host-based 6to4 and
of an anycast address for the relay were both absent at that time.
The idea was router-based 6to4 with the relay's IPv4 address
being just another router's address (i.e. very definitely not anycast).

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

Well, that has no authority; it's preempted by 3964.
> 
> 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."

Which, being Informational, can only be advisory...
> 
> 
> 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. 

I think that's the only viable choice, because there will be
deployments where one or the other is better.

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

See above - I don't think there's an answer.

> Additionally, is
> anyone strongly for or against adding a PTR record for 192.88.99.1 that
> might help document its use better?

Well, yes, but unless it can point to rfc3964.tools.ietf.org
I'm not sure it will help people much.

   Brian