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

From: Kevin Day <[email-masked]>
Date: Wed, 30 Jan 2008 18:33:23 -0600

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 31 Jan 2008 14:46:49 +1300

> over v4, should the source address be 192.88.99.1 or the relay's v4

This kind of makes my head hurt because...
> 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.
> 
> 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."
> 

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

---

From: Kevin Day <[email-masked]>
Date: Wed, 30 Jan 2008 20:06:57 -0600

> being just another router's address (i.e. very definitely not  

Sorry, I didn't mean that to sound like 3056 should have had anything  
to say about this specific issue, just that it didn't mention v4  
source address selection at all. 3068 also didn't mention it, which it  
maybe should have.

> deployments where one or the other is better.

Agreed. But if that is the general consensus, I believe it should be  
documented somehow.

My take on the situation was that the only thing that made sense was  
to use 192.88.99.1 - like just about everything else on the internet,  
if packets are sent to that IP, replies should come from that IP.  
Others believed the exact opposite. If both are right, documenting  
that somewhere makes the most sense.

> I'm not sure it will help people much.

I'm not exactly sure what, but I was thinking something along the  
lines of "anycast.6to4.relay.see.rfc3068.net" which I think would give  
people enough to find out more on their own.

-- Kevin

---

From: Antonio Querubin <[email-masked]>
Date: Wed, 30 Jan 2008 16:41:19 -1000 (HST)

On Wed, 30 Jan 2008, Kevin Day wrote:

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

A PTR record should probably be added but it's not a show-stopper.  Doing 
a whois for 192.88.99.0 or googling 192.88.99.1 should provide anyone 
curious enough with more info than a PTR RR would.

---

From: Kevin Loch <[email-masked]>
Date: Wed, 30 Jan 2008 23:21:42 -0500

> over v4, should the source address be 192.88.99.1 or the relay's v4 

Stateful firewalls would prefer that the return traffic come from
192.88.99.1 (assuming they properly handle proto 41 traffic).

- Kevin

---

From: Antonio Querubin <[email-masked]>
Date: Wed, 30 Jan 2008 20:34:59 -1000 (HST)

On Wed, 30 Jan 2008, Kevin Loch wrote:

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

The scenario is 6to4 to 6to4.  Both ends would ideally be encapsulating 
traffic directly to the other's IPv4 address.  Relay via 192.88.99.1 need 
not be involved.  In that situation you'd probably want the 6to4 host to 
use it's own IPv4 address as the source if it has to deal with a firewall.

192.88.99.1 is really required when traffic is between a 6to4 host and a 
native IPv6 host as there's really no other way to reach the latter.  The 
latter will punt to it's default gateway and the packets will eventually 
egress from a 6to4 border relay on it's way to the 6to4 host.

So the 'ideal' behaviour of the encapsulator (to deal with firewalls) 
really depends on whether the source address of the IPv6 packet is native 
or a 6to4 address.  A 6to4 host talking to 6to4 can still encap to a relay 
if it wanted to but 1) it's not as efficient, and 2) probably more likely 
to run afoul of firewalls.

Antonio Querubin
whois:  AQ7-ARIN

---

From: Pekka Savola <[email-masked]>
Date: Thu, 31 Jan 2008 08:55:41 +0200 (EET)

> v4, should the source address be 192.88.99.1 or the relay's v4 unicast 

There is no requirement either way.

Most relays use 192.88.99.1 as the source address, and..

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

>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 

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

---

From: "Erik Kline" <[email-masked]>
Date: Thu, 31 Jan 2008 17:01:03 -0800

> good idea what that should be :-).

"6to4.anycast.iana.org"?  Maybe incorporate the rfc #, maybe that
would get stale quickly.  I how it gets decided depends on who
decides?  I have no idea...

---

From: Antonio Querubin <[email-masked]>
Date: Thu, 31 Jan 2008 15:13:34 -1000 (HST)

On Fri, 1 Feb 2008, Brian E Carpenter wrote:

> Date: Fri, 01 Feb 2008 10:49:08 +1300
> From: Brian E Carpenter <[email-masked]>
> To: Antonio Querubin <[email-masked]>
> Cc: Kevin Loch <[email-masked]>, v6ops <[email-masked]>
> Subject: Re: 6to4 anycast IP as source address / PTR record
> 
> On 2008-01-31 19:34, Antonio Querubin wrote:
>> The scenario is 6to4 to 6to4.
>
> I thought that was exactly the scenario Kevin was *not*
> asking about. In that case it's obvious that each 6to4 box
> will use its own IPv4 address as source (which is why it's
> not mentioned in RFC 3056 - because it's obvious).

Doh!  You're right of course.  Sorry for adding to the confusion :)

---

From: David Conrad <[email-masked]>
Date: Thu, 31 Jan 2008 17:38:38 -0800

If someone is going to propose something along these lines, I suspect it
would be better if it were something like "6to4.anycast.arpa"... (the key
bit being the TLD).  I doubt it would reduce the abuse load at IANA, but at
least we could share the pain with the IAB... :-)

Regards,
-drc

---

From: Kevin Day <[email-masked]>
Date: Thu, 31 Jan 2008 22:13:23 -0600

> least we could share the pain with the IAB... :-)

I'd considered trying to sell the idea of a name under .arpa, but  
thought that would just add even more debate over what's acceptable to  
put under .arpa and what isn't.

I was actually going to propose something along the lines of "anycast. 
6to4.relay.see.rfc3068.net", with "www.rfc3068.net" being a very brief  
description of what it's used for. Kinda emulating what the as112.net  
folks have done. I've registered rfc3068.net just to stop any random  
idiot watching from registering it after seeing it discussed, but I'm  
happy to turn it over to whoever ends up being responsible for this if  
it goes ahead, and that domain is chosen.

Or maybe all this could be wrapped up in a rehashed RFC that replaces  
3068 which addresses some of the recent issues brought up, that also  
formally selects a domain for the PTR record.

-- Kevin

---

From: Pekka Savola <[email-masked]>
Date: Fri, 1 Feb 2008 08:15:16 +0200 (EET)

On Fri, 1 Feb 2008, Brian E Carpenter wrote:
>> 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.
>
> I don't see how. There are quite some variants of 6to4 that haven't
> been used, but that doesn't seem to be grounds for undocumenting them.
> I think it's 3068 that needs rewriting, to document what has been
> learnt about using anycast relays to support host-based 6to4.

Based on classification of draft-iab-protocol-success-01.txt, you 
could almost consider 6to4 as a "wild success".  From Section 1.3:

    A wildly successful protocol
    is so useful that it can solve more problems or address more
    scenarios or devices.  This may indicate that it is time to revise
    the protocol to better accommodate the new design space.

Only the host-based 6to4 approach has gained measurable deployment, 
which leads me to think that we should focus on that in the 
specifications.

Unused or non-deployed ideas are routinely removed when revising 
specs.  "BGP-based 6to4" is one that should be at the minimum 
rephrased, if not outright removed.