Subject: implications of 6to4 for v6coex

From: james woodyatt <[email-masked]>
Date: Fri, 5 Sep 2008 19:32:10 -0700

everyone--

I've been reviewing RFC 3056, RFC 3068 and RFC 3964 with an eye toward  
composing draft guidelines for service providers deploying 6to4 relays  
for the exclusive use of their subscribers, i.e. *not* public 6to4  
relay services.  In the process, I've come to think that some  
additional recommendations from IETF are in order, specifically to  
deal with IPv6-IPv4 Coexistence (V6COEX) issues.  The intent of this  
message is to start a discussion on the topic.

I believe section 5.2 "Mixed scenario with relay to native IPv6" in  
RFC 3056 adequately describes the scenario of interest to the V6COEX  
effort.

In this scenario, the service provider has a mix of offerings,  
including 1) IPv4 service at globally routed addresses and 2) native  
or tunneled IPv6 service at globally routed addresses.  The V6COEX  
issue arises when a node in subscriber A, receiving IPv4-only service  
in its delegated 192.0.2.0/24 subnet, e.g. 192.0.2.1, elects to become  
a 6to4 site with its corresponding 6to4 prefix 2002:c000:201::/48 in  
order to communicate with native IPv6 nodes at subscriber B in the  
2001:db8:1::/48 prefix.

Here's an ASCII diagram to show how this scenario presents a V6COEX  
issue:

Subcriber                       Service Provider                Public
Networks                        Interior                        Internet

  Subscriber A
  (6to4-only)
+--------------------+                      192.88.99.1  
+-------------------+
| 2002:c000:201::/48 |=================================>|    Public  
6to4    |
|                    |                                   
|                   |
|       192.0.2.1/32 |<============++     +-------------|        
Relay       |
+--------------------+ 192.0.2.1    \\   /               
+-------------------+
                                      \\ /
  Subscriber B                         \/
  (native IPv6)                        /\\
+--------------------+ 2001:db8:1::1 /  \\               
+-------------------+
| 2001:db8:1::/48    |<-------------+    ++=============|    Public  
6to4    |
|                    |                                   
|                   |
|                    |--------------------------------->|        
Relay       |
+--------------------+                 2002:c000:201::1  
+-------------------+

              1. The common scenario today, i.e. no 6to4 relay in
                 service provider network.  Public relay of last
                 resort used.

The double-width lines show 6to4 packet flows tunneled over IPv4 and  
the single-width lines show all other IPv6 packet flows (native and  
other tunnels).

All the outbound IPv6 packets from Subscriber A are encapsulated in  
IPv4 proto 41 and sent to their corresponding IPv4 destination  
directly if they're for the 2002::/16 prefix, otherwise they are  
forwarded to some public 6to4 relay at the 192.88.99.1 anycast  
address.  Likewise, the return path from Subscriber B, along with all  
the other traffic destined to 6to4 addresses, i.e. 2002::/16, are  
forwarded to some public 6to4 relay at the 2002:c058:6301:: anycast  
address.

The two 6to4 relay routers may or may not be the same router.  They  
may or may not even be located in the same autonomous system.  In any  
case, neither relay is operated by the service provider.

The V6COEX issue related to this scenario arises from a combination of  
two very common network operation errors.  The first problem is that  
many public 6to4 relay operators do not comply with the requirement of  
section 5.2.3 in RFC 3056, which says:
> 5.2.3 Unwilling to relay
>
> It may arise that a site has a router with both 6to4 pseudo-
>    interfaces and native IPv6 interfaces, but is unwilling to act as a
>    relay router.  Such a site MUST NOT advertise any 2002:: routing
>    prefix into the native IPv6 domain and MUST NOT advertise any  
> native
>    IPv6 routing prefixes or a default IPv6 route into the 6to4 domain.
>    Within the 6to4 domain it will behave exactly as in the basic 6to4
>    scenario of Section 5.1.

Admittedly, part of the problem is that a similar statement about the  
IPv4 anycast prefix, i.e. 192.88.99.0/24 is not present in RFC 3068.
Moving on, the second problem is that many IPv4 network managers are  
not following the recommendations of section 7 in RFC 3068, which says:

> 7 Security Considerations
>
> The generic security risks of 6to4 tunneling and the appropriate  
> protections are discussed in [RFC3056]. The anycast technique  
> introduces an additional risk, that a rogue router or a rogue AS  
> would introduce a bogus route to the 6to4 anycast prefix, and thus  
> divert the traffic. IPv4 network managers have to guarantee the  
> integrity of their routing to the 6to4 anycast prefix in much the  
> same way that they guarantee the integrity of the generic v4 routing.

As a result of these two common operating errors, the scenario in the  
diagram above results in communication failure.  When public relay  
operators do not actually provide the service they are advertising,  
then neither do the Internet service providers who accept their routes  
to the 6to4 anycast prefix without guaranteeing the integrity of  
service.

It's a particularly visible issue when the communication failure is  
between two co-located subscribers.

Why should the traffic even need to flow outside the data center, much  
less across two continents and a transoceanic link?  The answer is  
that it shouldn't.  The IETF should recommend that those providers  
planning to offer both IPv4 and IPv6 service to subscribers make sure  
to deploy 6to4 relays for the exclusive use of their subscribers.

Compare the following ASCII diagram to the previous one:

Subcriber                       Service Provider                Public
Networks                        Interior                        Internet

                                                              IPv4      
IPv6
+--------------------+                                          
|        |
| Subscriber A       | 
<=======================================>#        |
| (6to4-only)        |           +---------------+              
|        |
|                    |==========>|               |<------------|------- 
 >#
| 2002:c000:201::/48 |           | SP 6to4 Relay |              
|        |
| 192.0.2.1/32       |<==+    +--|               | 
<===========>#        |
+--------------------+   \\  /   +---------------+              
|        |
                           \\/    :               :              
|        |
                            /\    :               :              
|        |
+--------------------+    / \\   +---------------+              
|        |
| Subscriber B       |<--+   \+==|               | 
<===========>#        |
|(native IPv6)       |           | SP 6to4 Relay |              
|        |
|                    |<--------->|               |<------------|------- 
 >#
| 2001:db8:1::/48    |           +---------------+              
|        |
|                    |<----------------------------------------|------- 
 >#
+--------------------+                                          
|        |

              2. The proposed scenario, i.e. service provider
                 deploys 6to4 relays for exclusive use of its
                 own subscribers.  No public relays are needed.

In this diagram, subscriber A communicates directly via native IPv4  
with the public Internet to and from any address in its subnet  
192.0.2.0/24.  Likewise, subscriber B communicates directly via native  
IPv6 with non-6to4 Internet destinations through the normal forwarding  
path.  Once again, the double-width lines show 6to4 packet flows  
tunneled over IPv4 and the single-width lines show all other IPv6  
packet flows (native and other tunnels).

When subscriber A wishes to communicate with non-6to4 IPv6 sites,  
their 6to4 router at 192.0.2.1 sends its traffic encapsulated in IPv4  
to its nearest SP 6to4 relay, which decapsulates and forwards either  
to subscriber B or to some exterior IPv6 transit network.  Likewise,  
when subscriber B wishes to communicate with 6to4 IPv6 sites, the  
service provider's IGP routes all traffic destined for 2002::/16 to  
the nearest interior 6to4 relay, which encapsulates and forwards  
either to subscriber A or to some exterior IPv4 transit network.  In  
the case of subscriber A communicating with subscriber B, the paths in  
each direction never leave the service provider's networks.

Even service providers who offer *only* IPv6 service to their  
customers and do *not* offer IPv4 service should still deploy 6to4  
relays in their own networks so that the return path to 6to4  
destinations does not depend on the use of public relays whose  
reliability and availability they do not and cannot control.  This is  
the essential not of the case that 6to4 presents a V6COEX problem.

I mean to document in detail how service providers can configure and  
deploy 6to4 relays for the exclusive use of their own subscribers in a  
forthcoming Internet draft, but there are some practical issues with  
such deployments that I think would best be addressed by an update to  
the standards documents.

In particular, I think it would be helpful to ask IANA to allocate a  
block of IPv4 unicast addresses for use by service providers in  
assigning interface addresses of their non-public 6to4 relays.  These  
addresses would be like RFC 1918 addresses, in that they are  
explicitly forbidden from appearing in the IPv4 default-free zone  
routing tables, and their uniqueness property is only guaranteed to  
hold within the borders of a single autonomous system (though peering  
relationships could certainly extend their reach by mutual agreement).

The reasoning behind my idea is that service providers really do not  
want their 6to4 relays to be available outside their own networks, so  
assigning public addresses to their IPv4 interfaces as the current  
standards documents require is unnecessary, fails to conserve IPv4  
address space, and places a burden on them to do ingress filtering at  
their borders to prevent unauthorized use of their relays by exterior  
sites.  However, assigning them RFC 1918 addresses is a less than  
ideal solution, because those addresses are very likely to be reserved  
for use by carrier-grade NAT devices in providing Internet service to  
subscribers.  Allocating a new special use block reserved solely for  
service provider 6to4 relay interfaces seems to me like a good and  
proper thing to do.  These addresses do not need to appear in any of  
the 6to4 transit packets; they are only used for operations and  
management functions.

Note well: there is no need to allocate a special-use block of IPv6  
addresses for service provider 6to4 relays.  The RFC 4193 unique local  
addresses are more than adequate for this purpose.

Comments?

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 15 Sep 2008 15:49:31 +1200

James,

Long story ==> very short:

> The reasoning behind my idea is that service providers really do not want their 6to4 relays to be available outside their own networks,

That may or may not be true, and I could give you a current example where it's
definitely not true (i.e. an ISP intentionally announcing its 6to4 relay
at an exchange point). In cases where it is true, I certainly agree
that operational practice must be to ensure that the address is not
advertised - in fact I'm plagued at the moment by a 6to4 relay
that is widely advertised but that doesn't actually offer service.

However I don't really get why we'd benefit from reserving special IPv4
space to be not advertised. I do see why we'd benefit from making it
clear that the relay anycast should only be advertised within a scope
where it actually works, but that seems as much an issue for an O'Reilly
book as for an RFC.

    Brian

---

From: james woodyatt <[email-masked]>
Date: Mon, 15 Sep 2008 12:35:40 -0700

On Sep 14, 2008, at 20:49, Brian E Carpenter wrote:
> [I wrote:]
>> The reasoning behind my idea is that service providers really do  
>> not want their 6to4 relays to be available outside their own  
>> networks,
>
> at an exchange point).

Yes, you're right.  I over-generalized.  Some providers don't mind.   
Others certainly do.

It's been made clear to me in private conversations with  
representatives of more than one very large service provider that  
their continuing lack of 6to4 relay service offerings to their  
subscribers is directly caused by their perceived inability to limit  
the availability of the relay service to their subscribers only.  Some  
service providers clearly believe that they have no practical means of  
doing it, i.e. that ingress filtering and limited BGP advertisement  
are impractical, and so they are actively resisting deployment of any  
6to4 or Teredo relay routers.

> [...] in fact I'm plagued at the moment by a 6to4 relay that is  
> widely advertised but that doesn't actually offer service.

I know of at least two relays that plague a large number of IPv4 users  
in this way.  One of them is widely advertised throughout North  
America by the two largest retail Internet service providers to  
residential customers.  Neither relay I know about is operated by an  
organization capable of handling the load they are being delegated.   
Of course, they are unable to provide relay service for the entire  
Internet.  (One of them is operated by an organization I can't  
discover any useful information about, and I honestly wonder if it  
might be a cut-out for a signal intelligence operation.)

Inoperative public relay routers wouldn't pose as much of a problem if  
service providers were taking seriously the need to guarantee the  
integrity of the 6to4 relay service available to their IPv4  
customers.  As noted above, most are deferring it to disinterested  
third-parties without sufficient capabilities, and some are certainly  
doing it *deliberately* because of their technical objections to the  
standard.

> where it actually works, but that seems as much an issue for an  

I had an extensive discussion off-list with Nathan Ward about this,  
and he helped me refine my ideas considerably.  When I get the time to  
work on my draft, it will include a better-composed justification for  
allocating a new special-use block.

Again, my purpose is to address the technical concerns I've heard  
expressed from service providers who do not want the IPv4 interface  
addresses of their 6to4 relay routers (and, yes Teredo relays too)  
from being disclosed *at* *all* outside their networks, i.e. not just  
kept out of BGP-- because they do not feel that ingress filtering is  
practical, and that it wastes global IPv4 addresses, and finally that  
they don't want to deal with realm conflicts associated with using RFC  
1918 for both subscriber networks and relay router interfaces.

In any case, we've heard technical objections from service providers  
on the V6OPS list to deploying 6to4 and Teredo relay routers before,  
and it seems like either A) those objections will need to be addressed  
for IPv4-IPv6 coexistence to work, or B) we should deprecate those  
transition mechanisms for which we cannot satisfy the legitimate  
technical concerns of very large service providers actively resisting  
the deployment of necessary relay routers.

---

From: Brian Carpenter <[email-masked]>
Date: Tue, 16 Sep 2008 10:39:49 +1200

[resend to bypass stupid DNS blacklist]

On 2008-09-16 07:35, james woodyatt wrote:
...
> I had an extensive discussion off-list with Nathan Ward about this, and
> he helped me refine my ideas considerably.  When I get the time to work
> on my draft, it will include a better-composed justification for

OK, good, but it could be a hard battle to get the RIRs on board with
yet another special-use prefix.

...
> In any case, we've heard technical objections from service providers on
> the V6OPS list to deploying 6to4 and Teredo relay routers before, and it
> seems like either A) those objections will need to be addressed for
> IPv4-IPv6 coexistence to work, or B) we should deprecate those

Well, I can't speak for Teredo, but 6to4 was specifically conceived
as a way of bypassing recalcitrant ISPs unwilling to offer native
IPv6 service. So deprecating it would be exactly the wrong thing:
an ISP that doesn't like 6to4 packets should be incented to provide
IPv6 service.

    Brian

---

From: james woodyatt <[email-masked]>
Date: Mon, 15 Sep 2008 15:58:30 -0700

> an ISP that doesn't like 6to4 packets should be incented to provide

Transitioning to IPv6 doesn't make 6to4 and Teredo go away.

Offering IPv6-only service isn't even sufficient to relieve providers  
of the requirement to deploy relays, because the return paths to  
2002::/16 and 2001::/32 need to be made reliable for IPv6-only  
subscribers.  The requirement to provide reliable 6to4 and Teredo  
relays will be with us until the happy day that the IPv4  
specifications can be archived off in the Historic category.  I expect  
the Heat Death Of The Universe to arrive before that happens.

We need to remove the technical obstacles that service providers say  
are preventing them from deploying relays for the exclusive use of  
their subscribers.  Otherwise, we are in serious danger of splitting  
the ostensibly singular IPv6 public Internet into three separate  
functional autonomies: A) the Teredo internet, B) the 6to4 internet,  
and C) the native (and manually tunneled) internet.  Is that what we  
want?

It would be very nice if an authoritative voice at one of the very  
large service providers currently resisting the deployment of relays  
would step up now and explain what are those technical obstacles that  
we must remove for them if IPv4-IPv6 coexistence to succeed.  Perhaps,  
there are no real technical obstacles at all, and I've just been led  
to believe otherwise by mistake.  If so, then it would be good to  
understand what are the non-technical obstacles currently holding up  
deployment, so we can make appropriate choices to prevent the split I  
describe above.

---

From: Christian Huitema <[email-masked]>
Date: Mon, 15 Sep 2008 17:44:34 -0700

> the Heat Death Of The Universe to arrive before that happens.

Teredo has a very different deployment strategy than 6to4.

Teredo relays are typically deployed only after an ISP has already deployed a V6 service. The relays will be used by remote V4 users connecting to the native IPv6 customers of that ISP. Teredo relays are not advertised on the V4 Internet. If the ISP ensures that the advertisements for 2001::/32 are not sent to third parties, then the relays can only be used by that ISP's customer.

Dual-stack IPv6 users can deploy their own Teredo relays. For example, the provider of a big service over IPv6 could deploy a Teredo relay as part of the service, for exclusive use by that service.

-- Christian Huitema

---

From: james woodyatt <[email-masked]>
Date: Tue, 16 Sep 2008 14:54:00 -0700

On Sep 15, 2008, at 17:44, Christian Huitema wrote:

> If the ISP ensures that the advertisements for 2001::/32 are not  
> sent to third parties, then the relays can only be used by that  
> ISP's customer.

The complaint I have heard is that simply not advertising the routes  
to third parties is not enough to prevent them from using static  
routes to steal relay service.

This can be mitigated by using ULA's for the IPv6 interface addresses,  
but the corresponding use of RFC 1918 addresses for the IPv4  
interfaces is more perilous, it seems, from an O&M perspective— or so  
I've gathered.  Perhaps, I'm mistaken, and there really are no  
technical objections to the deployment of relay routers, and the  
resistance is entirely motivated by perverse incentives that lead to  
the degradation of the public IPv6 internet as their tragic side- 
effect.  I'm trying not to be demoralized by that possibility.

> Dual-stack IPv6 users can deploy their own Teredo relays. For  
> example, the provider of a big service over IPv6 could deploy a  
> Teredo relay as part of the service, for exclusive use by that  
> service.

Isn't this impossible without filtering the return path to the unicast  
IPv4 addresses on their Teredo relay so that exterior sites are unable  
to obtain relay service to other exterior sites by the application of  
a static route?  I gather that this filtering requirement is the only  
reason service providers are offering any technical objection to the  
deployment of 6to4 and Teredo relays.  My idea is to allocate a new  
special-use block of IPv4 addresses so that such static routes are  
only possible by explicit, mutual agreement between autonomous systems.

On a related note: should we move this discussion onto the <[email-masked] 
 > list?

---

From: Christian Huitema <[email-masked]>
Date: Tue, 16 Sep 2008 15:43:39 -0700

Teredo relays should only originate packets to an IPv4 address if the communication was initiated from the IPv6 side. That's enough to build a stateful address filter in the relay, so it only accepts IPv4 packets if there was prior initiation from the IPv6 side. I don't know whether commercial implementations of Teredo actually implement this stateful filtering, but if they did that would go a long way towards alleviating the ISP's fear.

Failing that, it is also possible to run the Teredo relay at an arbitrary port number, or even one that changes periodically.  That, too, would make it very hard for "leeches" to steal the relay service by pointing to the IPv4 address of the relay.

The remaining possibility for the "leeches" would be to set up a static IPv6 route for 2001::/32 towards the relay that they want to target. If ISP are concerned with that, they can simply black-hole traffic to 2001::/32 at their border router. It will not hurt, since the internal hosts are supposed to use the internal relay.

Having special IPv4 addresses for the relay does not appear particularly beneficial. By definition, the Teredo relay is meant to accept traffic from various remote IPv4 addresses, and thus should be reachable from these addresses.

From: [email-masked] [mailto:[email-masked]] On Behalf Of james woodyatt
Sent: Tuesday, September 16, 2008 2:54 PM
To: IPv6 Operations
Subject: Re: implications of 6to4 for v6coex

If the ISP ensures that the advertisements for 2001::/32 are not sent to third parties, then the relays can only be used by that ISP's customer.

The complaint I have heard is that simply not advertising the routes to third parties is not enough to prevent them from using static routes to steal relay service.

This can be mitigated by using ULA's for the IPv6 interface addresses, but the corresponding use of RFC 1918 addresses for the IPv4 interfaces is more perilous, it seems, from an O&M perspective- or so I've gathered.  Perhaps, I'm mistaken, and there really are no technical objections to the deployment of relay routers, and the resistance is entirely motivated by perverse incentives that lead to the degradation of the public IPv6 internet as their tragic side-effect.  I'm trying not to be demoralized by that possibility.

Isn't this impossible without filtering the return path to the unicast IPv4 addresses on their Teredo relay so that exterior sites are unable to obtain relay service to other exterior sites by the application of a static route?  I gather that this filtering requirement is the only reason service providers are offering any technical objection to the deployment of 6to4 and Teredo relays.  My idea is to allocate a new special-use block of IPv4 addresses so that such static routes are only possible by explicit, mutual agreement between autonomous systems.

On a related note: should we move this discussion onto the <[email-masked]<mailto:[email-masked]>> list?

--
james woodyatt <[email-masked]<mailto:[email-masked]>>
member of technical staff, communications engineering

---

From: Antonio Querubin <[email-masked]>
Date: Tue, 16 Sep 2008 13:05:41 -1000 (HST)

On Tue, 16 Sep 2008, james woodyatt wrote:

>> If the ISP ensures that the advertisements for 2001::/32 are not sent to 
>> third parties, then the relays can only be used by that ISP's customer.
>
> The complaint I have heard is that simply not advertising the routes to third 
> parties is not enough to prevent them from using static routes to steal relay 
> service.

If they're afraid of that, why can't they just block access to the relay 
address via ACLs at their borders?  Most ISPs probably do some kind of 
filtering at their border anyway.  Adding one more deny rule isn't gonna 
make a big impact on performance.

-- 
Antonio Querubin
whois:  AQ7-ARIN

---

From: james woodyatt <[email-masked]>
Date: Tue, 16 Sep 2008 17:43:27 -0700

On Sep 16, 2008, at 16:05, Antonio Querubin wrote:
>> The complaint I have heard is that simply not advertising the  
>> routes to third parties is not enough to prevent them from using  
>> static routes to steal relay service.
>
> If they're afraid of that, why can't they just block access to the  
> relay address via ACLs at their borders?  Most ISPs probably do some  
> kind of filtering at their border anyway.  Adding one more deny rule  
> isn't gonna make a big impact on performance.

Yes, the existing RFCs recommend filtering at the border gateway and  
limited routing advertisements to trusted peers.  So, why do service  
providers think they can't secure their 6to4 relay service that way?   
They must have a legitimate reason, don't you think?  Surely, they  
aren't trying to sabotage the IPv4-IPv6 transition by splitting the  
public IPv6 internet into three parts (one for native, one for 6to4  
and one for Teredo), right?

Again, it would be better if an authoritative voice recommending  
*against* the deployment of 6to4 and Teredo relays in service provider  
networks, because of concerns about limiting access to relay services  
to their subscribers only, would step in here and speak to the issue  
directly.  I've only gathered from talking with people that the  
problem with ACLs at the border routers is that a real deployment plan  
would require too many ACL entries, i.e. one for each relay, because  
relays would have to be in lots of different places around the  
interiors of their networks, and addressed accordingly.

Won't somebody from a service provider *please* step up and explain  
why they cannot and/or will not deploy 6to4 relay routers for the use  
of their subscribers as the standards track documents currently  
describe them?  The continuing silence from the operations community  
on this topic is very troubling, but I suppose it's possible everyone  
is still enjoying their copious allotment of holiday time.

It *is* September, though, isn't it?

---

From: Joe Abley <[email-masked]>
Date: Tue, 16 Sep 2008 21:39:20 -0400

On 16 Sep 2008, at 20:43, james woodyatt wrote:

> why they cannot and/or will not deploy 6to4 relay routers for the  
> use of their subscribers as the standards track documents currently  
> on this topic is very troubling, but I suppose it's possible  
> everyone is still enjoying their copious allotment of holiday time.

Perhaps you're asking the wrong question. Perhaps there's no reason  
for any operator not to deploy a 6to4 relay for use of their  
customers; perhaps the problem instead is that there is no clear  
reason in the eyes of those operators to bother.

Does it make the helpdesk phone ring less? Will it cause an average  
ISP to win more customers this month? I suspect the pragmatic answer  
to both is no.

Joe

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 16 Sep 2008 23:32:24 -0400

James,

Unless a problem is of a Show Stopper nature, do we have to continue
this discussion?  I don't see any problem in your emails of a Show
Stopper nature.  It would be helpful if you could articulate a Show
Stopper problem in a sentence or two. That way, maybe the Montreal
interim meeting on ipv4 and ipv6 coexistence can discuss such issues. 

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Joe Abley
Sent: Tuesday, September 16, 2008 9:39 PM
To: james woodyatt
Cc: IPv6 Operations
Subject: Re: implications of 6to4 for v6coex

> is still enjoying their copious allotment of holiday time.

Perhaps you're asking the wrong question. Perhaps there's no reason for
any operator not to deploy a 6to4 relay for use of their customers;
perhaps the problem instead is that there is no clear reason in the eyes
of those operators to bother.

Does it make the helpdesk phone ring less? Will it cause an average ISP
to win more customers this month? I suspect the pragmatic answer to both
is no.

Joe

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 17 Sep 2008 09:57:38 +0200

On Tue, 16 Sep 2008 15:43:39 -0700, Christian Huitema

<[email-masked]> wrote:

> Teredo relays should only originate packets to an IPv4 address if the

> communication was initiated from the IPv6 side. That's enough to build a

> stateful address filter in the relay, so it only accepts IPv4 packets if

> there was prior initiation from the IPv6 side. I don't know whether

> commercial implementations of Teredo actually implement this stateful

> filtering, but if they did that would go a long way towards alleviating

the

> ISP's fear.

At least those Teredo relay deployments I know of _do_ discard traffic from

IPv4 to IPv6 unless solicited by one native IPv6 node. That's the most

basic protection against blind spoofing Teredo clients.

However, if I understand James right, his concern is with the IPv6 to IPv4

direction, whereby a IPv6 ISP could steal the relaying capacity of another

IPv6 ISP. To address that, one must (simply?) discard packets toward

2001:0::/32 and coming from unauthorized IPv6 nodes (although this will

obviously cause a split Internet).

> Failing that, it is also possible to run the Teredo relay at an arbitrary

> port number, or even one that changes periodically.  That, too, would

make

> it very hard for "leeches" to steal the relay service by pointing to the

> IPv4 address of the relay.

It is my understanding that a Teredo relay must server traffic to/from the

*whole* IPv4 Internet. So I do not get this.

A Teredo relay can restrict which chunk of the native IPv6 Internet it

relays from/to, not which chunk of the IPv4 Internet.

> The remaining possibility for the "leeches" would be to set up a static

> IPv6 route for 2001::/32 towards the relay that they want to target. If

ISP

> are concerned with that, they can simply black-hole traffic to 2001::/32

at

> their border router. It will not hurt, since the internal hosts are

> supposed to use the internal relay.

Yes. Or at the relay itself - checking that the non-Teredo IPv6 address

belongs to the ISP.

-- 

Rémi Denis-Courmont

---

From: james woodyatt <[email-masked]>
Date: Wed, 17 Sep 2008 10:07:17 -0700

> ISP to win more customers this month? I suspect the pragmatic answer  

Sigh.  Again, here are the incentives providers have today for  
deploying 6to4 and Teredo relays:

+ To prevent P2P traffic between their customers using 6to4 at  
2002::/16 and Teredo at 2001::/32 from having to be forwarded out of  
their networks for disinterested 3rd parties to relay on their behalf.  
Even for *IPv4-only* service providers, this either A) costs money for  
traffic across their borders that would otherwise not need to be  
carried (when the 3rd party relays are working), or B) prevents their  
IPv4 customers electing to use different IPv6-transition mechanisms on  
their own from communicating with one another (when the 3rd party  
relays are refusing to serve) and drives customers away to other  
providers where the relay service is reliable.

+ To wrest the control over the quality of service for their native- 
IPv6 customers communicating with 2002::/16 and 2001::/32 destinations  
on the public Internet away from the disinterested (and potentially  
hostile) 3rd parties who operate the relays advertised to them.

Despite these incentives, service providers are balking at deploying  
relays, and not merely for financial and practical reasons.  Some have  
privately told me their technical objections to the standards  
themselves, which I have tried to relate here.  (Sadly, the V6OPS  
minutes from the Philadelphia and Dublin meetings don't seem to be  
posted where I can find them, otherwise I would link to where I  
remember Alain Durand's remarks in the V6OPS session about how private  
6to4 and Teredo relays cannot be deployed in a practical fashion.)

No, I don't imagine that 6to4 and Teredo traffic *currently* costs  
many providers enough money, or lost business, or help desk calls to  
justify the expense of deploying the relays (though, with the recent  
release of uTorrent 1.8, I suspect that may change).  However, some  
providers certainly *do* have technical objections.

---

From: Nathan Ward <[email-masked]>
Date: Fri, 19 Sep 2008 15:25:36 +1200

On 17/09/2008, at 1:39 PM, Joe Abley wrote:

>> describe them?  The continuing silence from the operations  
>> community on this topic is very troubling, but I suppose it's  
>> possible everyone is still enjoying their copious allotment of  
>> holiday time.
>

Oh! This is my cue.

Does it cause less traffic to go off-net and then back on, when it's  
going between two users on your network? Yes.
Ie. the provider is paying for traffic to leave, and then paying for  
it to come back - paying twice when they should only be paying 0 times.

Bit torrent is using 6to4 now, and it's growing. uTorrent 1.8 supports  
Teredo as of a month ago.

This stuff is all in here, note that the numbers are a bit misleading  
because I didn't have a full understanding of how DHT and stuff  
worked, but they are still formidable:
http://www.apnic.net/meetings/26/program/ipv6/ward-ipv6-stats.pdf

Here is a graph of the CSC/FUNET Teredo and 6to4 relay. The bottom of  
that slope mid August is when uTorrent 1.8 came out.
http://www.braintrust.co.nz/temp/csc-funet-teredo-6to4.png

Yep, that's 10 x growth since a month ago. About 70x growth since a  
year ago.

Not that currently, uTorrent only gets IPv6 peer addresses using peer  
exchange. It does not get them with DHT, and very few trackers support  
the BPE0007 Bittorrent extension for IPv6 support.
Based on that, that 6to4/Teredo/IPv6 traffic is going to increase,  
lots, as soon as uTorrent gets DHT with IPv6, and trackers start to  
support it.

--
Nathan Ward

---

From: Nathan Ward <[email-masked]>
Date: Fri, 19 Sep 2008 15:37:33 +1200

On 16/09/2008, at 7:35 AM, james woodyatt wrote:

> and he helped me refine my ideas considerably.  When I get the time  
> to work on my draft, it will include a better-composed justification  
> for allocating a new special-use block.
>
> from being disclosed *at* *all* outside their networks, i.e. not  
> just kept out of BGP-- because they do not feel that ingress  
> filtering is practical, and that it wastes global IPv4 addresses,  
> and finally that they don't want to deal with realm conflicts  
> associated with using RFC 1918 for both subscriber networks and  
> relay router interfaces.
>
> and it seems like either A) those objections will need to be  
> addressed for IPv4-IPv6 coexistence to work, or B) we should  
> deprecate those transition mechanisms for which we cannot satisfy  
> the legitimate technical concerns of very large service providers  
> actively resisting the deployment of necessary relay routers.

So, James' point here about the IPv4 interface being visible outside  
the provider seems strange at first - as we all assume that that  
address will be 192.88.99.1, so anyone trying to steal bandwidth using  
6to4 would be sent to the nearest 192.88.99.0/24 instance, and if the  
provider in question does not advertise it outside their AS it will be  
no problem.

However, RFC3068 says:
<snip>
   Each 6to4 relay router that advertise the 6to4 anycast prefix MUST
   also provide an equivalent IPv4 unicast address.  Packets sent to
   that unicast address will follow the same processing path as packets
   sent to the anycast address, i.e., be relayed to the IPv6 Internet.
</snip>

Cisco's 6to4 implementation does not allow this. Neither does FreeBSD's.
(Though, myself and colleagues have been able to do things to make it  
work on both platforms, but none of that is in the config examples you  
can find around the web)
I can't recall what Linux's implementation does.

I don't see a need for that paragraph in the RFC, and unless there's a  
reason for it, I think we should remove it, which in my understanding  
removes this whole problem.

For more fine grained control of who uses your relay, there is no  
reason you couldn't create a '6to4' MPLS VPN, and leak the  
192.88.99.0/24 prefix to their customers who you wanted to receive  
service from their relay.
Result is, transit customers get to some public relay, but end users  
on your network (say dsl or cable or whatever) get your 6to4 relay.

Also, as per Christian's followup comments, Teredo is far different to  
6to4 - the IPv4 address must be exposed for it to work.
If you don't want people to 'trombone' through your Teredo relay, put  
an ACL on there that permits traffic coming from the relay to be only  
from 2001::/32, and to only your IPv6 networks. That's much easier  
than attempting to keep state and things, and it's something that you  
can do right now.

--
Nathan Ward

---

From: Truman Boyes <[email-masked]>
Date: Fri, 19 Sep 2008 11:25:19 -0400

On 18/09/2008, at 11:37 PM, Nathan Ward wrote:
> address will be 192.88.99.1, so anyone trying to steal bandwidth  
> using 6to4 would be sent to the nearest 192.88.99.0/24 instance, and  
> if the provider in question does not advertise it outside their AS  
> it will be no problem.
>
> However, RFC3068 says:
> <snip>
> (Though, myself and colleagues have been able to do things to make  
> it work on both platforms, but none of that is in the config  
> examples you can find around the web)
> I don't see a need for that paragraph in the RFC, and unless there's  
> a reason for it, I think we should remove it, which in my  
> understanding removes this whole problem.
>
>
> Also, as per Christian's followup comments, Teredo is far different  
> to 6to4 - the IPv4 address must be exposed for it to work.
> If you don't want people to 'trombone' through your Teredo relay,  
> put an ACL on there that permits traffic coming from the relay to be  
> only from 2001::/32, and to only your IPv6 networks. That's much  
> easier than attempting to keep state and things, and it's something  
> that you can do right now.
>
> --
> Nathan Ward

The implications of the "MUST also provide an equivalent IPv4 unicast  
address" are the issue. If some providers wish to open up their  
relay's they MAY, but we should hardly expect providers to accept the  
role of relaying anyone and then dealing with the repercussions of  
anonymous attacks. I see a benefit to users in having the unicast  
addresses of 6to4 relays (ie. switching to better, but farther  
relays), however this behaviour should be up to the providers.

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.

Truman Boyes

---

From: james woodyatt <[email-masked]>
Date: Fri, 19 Sep 2008 09:49:46 -0700

On Sep 19, 2008, at 08:25, Truman Boyes wrote:
>
> The implications of the "MUST also provide an equivalent IPv4  
> unicast address" are the issue.

Yes.  One of those implications is that relays forwarding IPv6 packets  
encapsulated in IPv4 toward the public Internet are required to use  
their IPv4 interface address as the source address.  This discloses  
the global IPv4 unicast address of the relay to the public, and forces  
providers into managing a special addressing plan for their relays  
that facilitates filtering at their borders.  It's the extra  
addressing management that, I think, is the blocking factor.

Removing the requirement for using a global IPv4 unicast address on  
the relay interface only goes so far, though.  Whatever addresses  
providers choose to use must be legitimate as IPv4 source addresses on  
the public Internet, and RFC 1918 addresses are not.  So, what do they  
use?  Assuming they are willing to go with an addressing plan that  
puts all their 6to4 relays into a single prefix, which I note above is  
a problem by itself, they could use part of the allocation from the  
RIRs and just not advertise it.  The reason this is an issue is that  
it seems like a waste of IPv4 space for something that isn't supposed  
to be reachable, and the waste is replicated for each and every  
provider that deploys relays.  A special-use block would address that  
problem as well.

---

From: Christian Huitema <[email-masked]>
Date: Fri, 19 Sep 2008 15:18:54 -0700

> the RFC creates a problem if we implement a strict adherence to the

The requirement came out of a desire for traceability and testability, and was pushed during the AD review of the draft.

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.

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.

-- Christian Huitema

---

From: james woodyatt <[email-masked]>
Date: Fri, 19 Sep 2008 17:15:40 -0700

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

---

From: Nathan Ward <[email-masked]>
Date: Sat, 20 Sep 2008 12:18:06 +1200

On 20/09/2008, at 4:49 AM, james woodyatt wrote:

> Yes.  One of those implications is that relays forwarding IPv6  
> packets encapsulated in IPv4 toward the public Internet are required  
> to use their IPv4 interface address as the source address.  This  
> discloses the global IPv4 unicast address of the relay to the  
> public, and forces providers into managing a special addressing plan  
> for their relays that facilitates filtering at their borders.  It's  
> the extra addressing management that, I think, is the blocking factor.

Yep, but as I've said before, no one actually does this in their  
implementations.

> providers choose to use must be legitimate as IPv4 source addresses  
> on the public Internet, and RFC 1918 addresses are not.  So, what do  
> they use?  Assuming they are willing to go with an addressing plan  
> that puts all their 6to4 relays into a single prefix, which I note  
> above is a problem by itself, they could use part of the allocation  
> from the RIRs and just not advertise it.  The reason this is an  
> issue is that it seems like a waste of IPv4 space for something that  
> isn't supposed to be reachable, and the waste is replicated for each  
> and every provider that deploys relays.  A special-use block would  
> address that problem as well.

Hold on, if we remove the paragraph I mentioned from the RFC, why must  
there be anything other than 192.88.99.1 on the interface?

--
Nathan Ward

---

From: Nathan Ward <[email-masked]>
Date: Sat, 20 Sep 2008 12:44:07 +1200

> testability, and was pushed during the AD review of the draft.

See my comments at the end, they are basically the same as what I'd  
have written here.

> Using the "real" address of the gateway as a source address would  

Is the suggestion here that strict uRPF would cause a problem?
A network with strict uRPF on multihoming links will have no doubt  
realised that it's broken for many other things, and turned it off.

On the other hand, if we're talking about some kind of stateful  
firewalling (IPv4), that doesn't really work with 6to4 anyway. Infact,  
stateful firewalling and this requirement would make things worse.

> would have no recourse if the quality of service on the anycast path  

What would the user's recourse be?
If you mean that the user would switch to another relay, then while  
this might be something that you or I would do, in a world where 6to4  
is enabled by default on many platforms, the vast majority of users  
would not. The way I see it, is that we're at a trade off here, with 2  
options:

1) Leave this as it is, less providers deploy relays, but the relays  
we do have are more easy to debug. IPv6 over 6to4 performance globally  
is not good, we cannot put services on IPv6 because of performance  
problems.

2) Remove the paragraph, more providers deploy relays, but we have  
very little relay debugging available to us. IPv6 over 6to4  
performance globally is improved, we can start putting services on  
IPv6 without performance problems.

Continuing to allow IPv6 over 6to4 to be broken for the sake of a bit  
of debugging is, in my opinion, a bad thing. We now understand the  
things that break 6to4, and we are able to test for them without 6to4  
relays being on non-RFC3068 addresses.

Because of the implementations of many vendors, (2) has already been  
done. Let's remove the paragraph to alleviate concerns of these  
providers, and get on with it.

--
Nathan Ward

---

From: Nathan Ward <[email-masked]>
Date: Sat, 20 Sep 2008 12:54:13 +1200

On 20/09/2008, at 12:15 PM, james woodyatt wrote:
> There is clearly something broken about 6to4, and I'm not sure how  
> to fix it.  Can it be saved as a standard?

It works just fine, and with vendors' current implementations (ie.  
ignoring that paragraph), the concerns that these providers have  
raised are not a problem.

So, yes, I would say that it's very easy to save, provided that we  
don't attempt to make this mechanism (which is intended for use only  
in a transition period) be all things to everybody. I don't think  
anyone is suggesting that 6to4 is going to be perfect, so let's accept  
that it's not, and instead try to make it practical.

I note that the things we're trading away are problems that any IPv4  
anycast system has, and it works just fine for many fairly important  
things.

--
Nathan Ward

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 22 Sep 2008 11:12:01 +1200

On 2008-09-20 12:54, Nathan Ward wrote:
>> There is clearly something broken about 6to4, and I'm not sure how to
>> fix it.  Can it be saved as a standard?

Just to be clear, the issue is not with basic 6to4, which was intended
to be implemented only in routers. It's with the "obvious" extension
to allow host-based 6to4, which led fairly quickly to the notion
of anycast relays and the resulting lack of both configuration and of
a discovery protocol.

> ignoring that paragraph), the concerns that these providers have raised
> are not a problem.
> 
> So, yes, I would say that it's very easy to save, provided that we don't
> attempt to make this mechanism (which is intended for use only in a
> transition period) be all things to everybody. I don't think anyone is
> suggesting that 6to4 is going to be perfect, so let's accept that it's
> not, and instead try to make it practical.

Exactly. It was intended more or less as a work-around for regions
where IPv6 isn't forwarded, and we shouldn't attempt to promote it
beyond that role.

   Brian