[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 6to4 anycast IP as source address / PTR record
On Wed, 30 Jan 2008, Kevin Day wrote:
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?
There is no requirement either way.
Most relays use 192.88.99.1 as the source address, and..
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.
.. as you write, I've received numerous complaints about weird 6to4
relay or connectivity problems which were caused by one of the
following assumptions:
a) all relay routers use 192.88.99.1 as the source address,
b) there is no need to accept all proto=41 traffic (forgetting
6to4-6to4 traffic), or
c) stateful proto=41 filtering is sufficient (on client-only system
this most prominently breaks with non-anycast sourcing relays, but
also on some other scenarios).
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?
I completely agree that this needs to be stated more clearly when/if
RFC 3056 is rewritten.
It would make a great sense to do that, IMHO, but I'm not sure if
we're quite far enough yet to have gained sufficient understanding
what needs to be clarified. When 3056 is rewritten, it can probably
be compressed to 10-15 pages at the same time. If there is strong
interest on this, I'd be interested in working on the rewrite (but it
probably doesn't belong to v6ops WG)
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.
Why doesn't WHOIS make sense? How should this be improved? Maybe it
could say "special anycast" instead of just "special", but it does
provide a pointer..
NetRange: 192.88.99.0 - 192.88.99.255
CIDR: 192.88.99.0/24
NetName: IANA-192
NetHandle: NET-192-88-99-0-1
Parent: NET-192-0-0-0-0
NetType: IANA Special Use
Comment: This block is reserved for special purposes.
Comment: Please see RFC 3068 for additional information.
Comment:
RegDate:
Updated: 2002-09-16
RIPE DB and RADB whois provide even better information.
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?
I have no problem getting a PTR record added as long as someone has a
good idea what that should be :-).
I would encourage the relays to use 192.88.99.1 but I have hard time
seeing how we could mandating it especially on receive-side
implementations.
When Teredo specification was first submitted, the IESG review came
back with pushback about the use of the anycast address (as source).
But that's a different scenario because Teredo is stateful (and
clients creating stateful state to the anycast address wasn't
considered a good idea, and the design was substantially changed) and
6to4 is stateless.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings