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

From: Rémi Després <[email-masked]>
Date: Fri, 01 Feb 2008 09:39:00 +0100

Pekka Savola wrote :
> 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?
IMHO, pending a firm recommendation, the anycast address as source is
the most natural choice, and is the  best candidate for an answer to the
question. (An answer which IMHO is highly desirable.)
-This choice limits somewhat risks of address spoofing (if any unicast
source address is permitted, any host can pretend being a 6to4 relay).
- RFC1546 says about IPv4: " Hosts should accept datagrams with an
anycast source address, although some transport protocols (see below)
may refuse to accept them.". There is no conflict.
- RFC 1884 says, but only about IPv6 "An anycast address must not be
used as the source address of an IPv6 packet.".  There is no conflict
either.

The answer to Kevin could then IMO be made official, in a new version of 
RFC 3068, with something like:
"6to4 relay routers (between IPv4 and IPv6 public clouds)  MUST use
192.88.99.1 as  IPv4 source addresses of IPv6 packets they encapsulate,
and check that IPv6 source addresses are not  6to4 (i.e. don't start
with 2002::/16).
6to4 routers (between IPv6 private clouds and IPv4-only public
networks)  SHOULD accept IPv6 encapsulated packets only if:
- IPv4 source addresses are not 192.88.99.1 if  IPv6 source addresses
are 6to4;
- IPv4 source addresses are 192.88.99.1 if IPv6 source addresses are
not 6to4".
>> .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
Full support.
Maybe it could be even more reader friendly if "for additional
information" would become "for its use in 6to4".

Rémi

---

From: james woodyatt <[email-masked]>
Date: Fri, 1 Feb 2008 09:46:03 -0800

On Jan 31, 2008, at 22:15, Pekka Savola wrote:
>
> Only the host-based 6to4 approach has gained measurable deployment,  
> which leads me to think that we should focus on that in the  
> specifications.

<http://www.apple.com/airportextreme/specs.html>

The 6to4 router function is turned on by default in these products  
(currently).  I'm confident in saying that deployment of these boxes  
is measurable.  I've seen the measurements.

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

---

From: Christian Huitema <[email-masked]>
Date: Fri, 1 Feb 2008 10:35:06 -0800

> is measurable.  I've seen the measurements.

OK. So, what would we changed in 6to4 if we optimized for host-based or CPE-based deployment? Do we trust that we will get enough 6to4 gateways deployed to sustain growth, or do we need to add a "gateway discovery service" similar to the Teredo spec?

-- Christian Huitema

---

From: Pekka Savola <[email-masked]>
Date: Fri, 1 Feb 2008 21:10:07 +0200 (EET)

On Fri, 1 Feb 2008, james woodyatt wrote:
>> Only the host-based 6to4 approach has gained measurable deployment, which 
>> leads me to think that we should focus on that in the specifications.
>
> (currently).  I'm confident in saying that deployment of these boxes is 
> measurable.  I've seen the measurements.

Maybe I should not have continued using that terminology, as it's 
prone to confusion.  There are two cases here:

1) 'host-based 6to4' refers to the scenario described in Section 5.1 
and Section 5.2 option 2.1 of RFC 3056.  (Regardless of whether the 
6to4 router is actually a host or router.)

2) the 'main model' advocated by Brian refers to the scenario 
described in Section 5.2 option 2.2 (also discussed in section 
5.2.2.2).  As far as I know, this has not seen any deployment.

My argument was that 2) is pretty much useless and even confusing, and 
the community would be best served if it was left out of a future 
revised specification.

-- 
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: james woodyatt <[email-masked]>
Date: Fri, 1 Feb 2008 11:37:21 -0800

On Feb 1, 2008, at 10:35, Christian Huitema wrote:
>
> OK. So, what would we changed in 6to4 if we optimized for host- 
> based or CPE-based deployment? Do we trust that we will get enough  
> 6to4 gateways deployed to sustain growth, or do we need to add a  
> "gateway discovery service" similar to the Teredo spec?

A standard method of discovering whether the 6to4 relay at the  
anycast address is functioning properly would be a fine idea.

At the moment, some very large ISP's are now hindering transition to  
IPv6 by forwarding 6to4 packets to relays that are black-holing them  
rather than forwarding them.  (This was not the case when AirPort  
Extreme shipped.)  These ISP's have no plans to deploy 6to4 relays in  
their own IPv6-capable networks, nor do they have any plan to forward  
6to4 traffic to relays that will carry it for them.  This is making  
some large content providers *remove* their AAAA records when they  
discover that customers behind 6to4 routers, e.g. AirPort Extreme,  
are unable to receive service because their applications do not fall  
back to IPv4 when IPv6 connectivity is broken.

Search the Apple discussion boards for IPv6, and you will see that a  
lot of people are turning off IPv6 entirely on their computers to  
work around the connectivity issues involved here.

---

From: Gert Doering <[email-masked]>
Date: Fri, 1 Feb 2008 20:51:18 +0100

Hi,

On Fri, Feb 01, 2008 at 11:37:21AM -0800, james woodyatt wrote:
> rather than forwarding them.  

Who is that?  Maybe we should raise a bit of stink in the more operational
IPv6 lists...

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  110584

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Antonio Querubin <[email-masked]>
Date: Fri, 1 Feb 2008 10:32:27 -1000 (HST)

> Who is that?  Maybe we should raise a bit of stink in the more operational

That too would be an excellent idea!!! :)

Antonio Querubin
whois:  AQ7-ARIN

---

From: Antonio Querubin <[email-masked]>
Date: Fri, 1 Feb 2008 10:31:41 -1000 (HST)

On Fri, 1 Feb 2008, james woodyatt wrote:

> Search the Apple discussion boards for IPv6, and you will see that a lot of 
> people are turning off IPv6 entirely on their computers to work around the 
> connectivity issues involved here.

I've already mentioned in private email but will re-iterate here.  This is 
a problem caused by the CPE (the Airport in this case) not erring on the 
side of caution.  These devices really need to leave 6to4 disabled and not 
allow autoconfiguration unless they can verify there is a reachable 6to4 
relay.

Perhaps in a revised spec it can INSIST on the pingability of the 6to4 
relay so that CPEs can perform a keepalive check in determining whether to 
keep IPv6 autoconfiguration enabled.

Antonio Querubin
whois:  AQ7-ARIN

---

From: James Woodyatt <[email-masked]>
Date: Fri, 01 Feb 2008 12:45:54 -0800

As I wrote privately, the 6to4 blackholes are responding to ICMP just  
fine.  They just don't forward IPv6 from some networks (not others).

-jhw

On Feb 1, 2008, at 12:31, Antonio Querubin <[email-masked]> wrote:

>> Search the Apple discussion boards for IPv6, and you will see that  
>> a lot of people are turning off IPv6 entirely on their computers to  
> I've already mentioned in private email but will re-iterate here.   
> This is a problem caused by the CPE (the Airport in this case) not  
> erring on the side of caution.  These devices really need to leave  
> 6to4 disabled and not allow autoconfiguration unless they can verify  
> there is a reachable 6to4 relay.
>
> Perhaps in a revised spec it can INSIST on the pingability of the  
> 6to4 relay so that CPEs can perform a keepalive check in determining  
> whether to keep IPv6 autoconfiguration enabled.
>
>
> Antonio Querubin
> whois:  AQ7-ARIN

---

From: Alain Durand <[email-masked]>
Date: Fri, 01 Feb 2008 15:46:22 -0500

Open relays are usually a bad think. Public anycast open relays are just
worse. Even if you are not concerned about security issues, there are
problems: you never know where they are, if they will be there tomorrow, if
they are on the other side of the planet, if the bandwidth is reasonable,
etc..

Essentially, expecting to get a functioning 6to4 relay is expecting a free
lunch. Who is going to pay for it?

IMHO, the entire model is broken.

   - Alain.

---

From: Christian Huitema <[email-masked]>
Date: Fri, 1 Feb 2008 13:23:31 -0800

> Essentially, expecting to get a functioning 6to4 relay is expecting a
> free lunch. Who is going to pay for it?

Alain is using some extreme language, but there really is an issue with the deployment model for 6to4 relays.

James is observing that some public relays are broken, perhaps deliberately. This point was raised during the discussion of the "anycast relay" RFC. It is actually a well known failure mode of the anycast model: your traffic is just a routing update away from a black hole. The remedy is well known: 6to4 routers ought to be configurable. If the user can somehow procure a reliable gateway, that gateway should be used.

Teredo went one step further. Public gateways can easily be abused. So Teredo introduced a discovery mechanism to find out the best gateway on a destination by destination basis. That mechanism is little more than a ping, and could easily be ported to 6to4. We could assume that 6to4 routers maintain a "routing cache" associating specific "native IPv6" destinations with the "closest 6to4 gateway". Given a new IPv6 destination, the 6to4 router will send a ping through the public server, note the IPv4 address from which the ping comes back, and send the rest of the traffic through that address.

In short, the Teredo model places the deployment onus on the IPv6 only servers. They must somehow ensure presence of a transition relay near them. They have an incentive to do so: serving the users of the transition technology. They also have an incentive to provide good quality service. This is a big contrast with the 6to4 model, which basically places the requirement on the legacy ISP.

-- Christian Huitema

---

From: james woodyatt <[email-masked]>
Date: Fri, 1 Feb 2008 13:48:40 -0800

On Feb 1, 2008, at 13:23, Christian Huitema wrote:
>
> James is observing that some public relays are broken, perhaps  
> deliberately.

I'm also observing that some ISP's are refusing to deploy 6to4 relays  
at *private* anycast addresses inside their own interior routing  
domains, preferring instead to dump the 6to4 "problem" to whatever  
the nearest public 6to4 relay is advertising service (which may or  
may not actually be available).

I think it would be helpful if routes to 192.88.99.1 shouldn't be  
advertised to peers from which protocol 41 packets will not be  
decapsulated and forwarded into an IPv6 domain.

> Teredo went one step further. Public gateways can easily be abused.  
> So Teredo introduced a discovery mechanism to find out the best  
> gateway on a destination by destination basis. That mechanism is  
> little more than a ping, and could easily be ported to 6to4. We  
> could assume that 6to4 routers maintain a "routing cache"  
> associating specific "native IPv6" destinations with the "closest  
> 6to4 gateway". Given a new IPv6 destination, the 6to4 router will  
> send a ping through the public server, note the IPv4 address from  
> which the ping comes back, and send the rest of the traffic through  
> that address.

This assumes the "ping" packets will pass through the same firewalls  
as the packets that trigger them.  If they don't produce a timely  
response, what happens?  Remember, at this point, there is a human  
being sitting at a console watching a stalled progress bar and  
waiting for a connection to go through.  The connection they're  
attempting is IPv6 because their host has a global IPv6 address  
assigned (with a 2002:aabb:ccdd:xxxx:/64 prefix) and they got an  
answer to a request for AAAA records.

Their host can connect to other hosts in 2002::/16 just fine.  It's  
only the non-2002::/16 address that are unreachable.  So, how many  
non-6to4 destinations do we have to "ping" before we decide to stop  
advertising an IPv6 default route for those 2002:aabb:ccdd:xxxx::/64  
addresses altogether?

At this point, if large IPv6-capable ISP's cannot be persuaded to  
deploy 6to4 relays in their interior IPv6/IPv4 routing domains for  
the use of their paying, retail IPv4 customers, then I have to say  
that 6to4 is a failure as a transition strategy, and we should move  
now to deprecate it.

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 01 Feb 2008 22:55:30 +0100

Christian Huitema wrote:
> James is observing that some public relays are broken, perhaps deliberately.
 > This point was raised during the discussion of the "anycast relay" RFC.

Instead of trying to "fix" 6to4, which also has this rather annoying 
issue called NAT which it can't 1,2,3 bypass, why not simply push Teredo 
forward which has all these points resolved already?

Greets,
  Jeroen

---

From: Gert Doering <[email-masked]>
Date: Fri, 1 Feb 2008 22:56:55 +0100

Hi,

> lunch. Who is going to pay for it?

If enough ISPs provide working 6to4 relays, serving their own customers
(that pay for the bandwidth, be it IPv4 or IPv4-encapsulated IPv6), the
model would work just fine.

Gert Doering
        -- NetMaster

---

From: Kevin Day <[email-masked]>
Date: Fri, 1 Feb 2008 16:55:14 -0600

> advertising an IPv6 default route for those 2002:aabb:ccdd:xxxx::/64  

Could requiring that anycasted 6to4 relays respond to an ICMP echo on  
their v6 address, then sending a ping to 2002:c058:6301:: help? That  
would at least prove connectivity to 192.88.99.1, and that something  
there is listening.

That works for our relay, anyway:

$ ping6 2002:c058:6301::
PING6(56=40+8+8 bytes) 2002:451f:630e:1::1 --> 2002:c058:6301::
16 bytes from 2002:c058:6301::, icmp_seq=0 hlim=64 time=6.398 ms

And this proves at the very least that:

v6 6to4 address selection on my system came up with the right IP
I can reach 192.88.99.1 over v4
6to4 made it through my router/firewall
The 6to4 relay at 192.88.99.1 is decapsulating/encapsulating packets  
correctly

It doesn't prove that the 6to4 relay actually has v6 connectivity, but  
I think that's getting beyond the scope of this problem.

If that helps, maybe this gives additional ammo for an updated 6to4  
anycast RFC that includes an ICMP echo requirement.

-- Kevin

---

From: Alain Durand <[email-masked]>
Date: Fri, 01 Feb 2008 18:23:34 -0500

> model would work just fine.

Why should ISP X pay to run a 6to4 relay that would in essence offer transit
for customers of other ISPs? And let's say that ISP X offer the outband
relay for its customers only, how would the packets come back from the real
IPv6 Internet to ISP X IPv4 network? Is ISP X suppose to announce a
de-aggregate of 2002://16? That would create a huge increase in the routing
table size...

  - Alain.

---

From: Alain Durand <[email-masked]>
Date: Fri, 01 Feb 2008 18:42:11 -0500

> I think that's getting beyond the scope of this problem.

This does not give any indication about the effective bandwidth available
either. The fundamentals issue there are:
- there is no way to select which anycast relay to use for inbound
  and outbound packets
- there is no contract nor SLA between the customer and the anycast 6to4
  relays (inbound/outband), so there is little incentive to whoever operates
  those relay to fix problems

   - Alain.

---

From: Alain Durand <[email-masked]>
Date: Fri, 01 Feb 2008 18:52:33 -0500

> forward which has all these points resolved already?

The Teredo model, actually from our observation with available code from its
major source, is that both end need to have it configured to enable a
reliable connection.

We tried with an open Teredo relay, and packets went sometimes to Korea,
sometimes nowhere.

In other words, this is fine to get IPv6 working between 2 PCs in different
homes separated by NAT boxes, but this is not usable to access a regular
IPv6 server on the Internet **UNLESS** that server also deploys Teredo...

So, going that route, if an IPv6 server wants to offer reliable service to
customers, it might have to be configured with:
- a regular global IPv6 address to serve regular IPv6 native customers
- a 6to4 address to serve 6to4 customers and avoid open relays
- a Teredo address to serve PC behind NAT box that uses Teredo

IMHO, this makes the deployment model of new servers a bit complex...

   - Alain.

---

From: james woodyatt <[email-masked]>
Date: Fri, 1 Feb 2008 16:17:19 -0800

On Feb 1, 2008, at 15:23, Alain Durand wrote:
> for customers of other ISPs?

No one here is asking for ISP X to advertise its 6to4 relays at  
public anycast addresses (either IPv4 or IPv6) into the default free  
zone.

I think the question you want to ask is this one: why should ISP X  
offer 6to4 relay service to its IPv4 customers when it can force them  
to pay extra for the additional utility of native IPv6 service?   
Admittedly, I don't have an answer to that question, except to say  
that the "additional utility" of IPv6 is limited by the fact that  
2002::/16 effectively divorced from the IPv6 default free zone by  
those same network operators insisting that interior 6to4 relays are  
harmful to their insert-noun-phrase-here.

> And let's say that ISP X offer the outband
> IPv6 Internet to ISP X IPv4 network?

By an asymmetric IPv4 path, of course.  The 6to4 relay is only a  
transition mechanism.  It doesn't have to work as well as native  
IPv6.  It just has to work.  If it doesn't work *at all*, then we  
should deprecate it.

> Is ISP X suppose to announce a

That's clearly not a good idea.

---

From: Alain Durand <[email-masked]>
Date: Fri, 01 Feb 2008 21:44:11 -0500

> That's clearly not a good idea.

Now, please help me reconcile how can a return relay for ISP X *only*
advertize 2002::/16 (and nothing smaller) and not offer free return transit
for people that are not its customers?

  - Alain.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 02 Feb 2008 17:33:18 +1300

> At this point, if large IPv6-capable ISP's cannot be persuaded to deploy
> 6to4 relays in their interior IPv6/IPv4 routing domains for the use of
> their paying, retail IPv4 customers, then I have to say that 6to4 is a
> failure as a transition strategy, and we should move now to deprecate it.
>

It wasn't designed as a transition strategy (actually, nothing I've
worked on was designed as a transition strategy) but rather as a
coexistence tool. In fact 6to4 was specifically designed as a way
for cooperating sites and ISPs to get past IPv4-only ISPs. But I agree
that it's unfortunate if an IPv6-enabled ISP doesn't either offer
a 6to4 relay or offer IPv4 transit to an ISP that does offer a
6to4 relay.

I don't think that we can get this toothpaste back in the tube,
though.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 02 Feb 2008 17:37:32 +1300

> for people that are not its customers?

Indeed. RFC 3056 explicitly says that the scope of such an advertisement
has to be limited by policy.

   3. A relay router MUST advertise a route to 2002::/16 into the native
   IPv6 exterior routing domain.  It is a matter of routing policy how
   far this routing advertisement of 2002::/16 is propagated in the
   native IPv6 routing system.  Since there will in general be multiple
   relay routers advertising it, network operators will require to
   filter it in a managed way.  Incorrect policy in this area will lead
   to potential unreachability or to perverse traffic patterns.

      Brian

---

From: Kevin Day <[email-masked]>
Date: Sat, 2 Feb 2008 02:32:42 -0600

> public anycast addresses (either IPv4 or IPv6) into the default free  

While there may not be demands placed on any ISP to do so, there are a  
bunch of us who are doing it anyway. Which either is or isn't allowed  
under RFC3068, depending on who you ask.

Judging by the huge range of emails we've received since announcing  
192.88.99.0/24 and 2002::/16 to the world, most ISP's and end user's  
knowledge of what 6to4 is ranges from "non-existent" to "misinformed".  
So, it's a pretty safe bet to say that there's a pretty large  
percentage of ISPs out there that have no current plans to either  
start their own relay, or make arrangements with someone who does.

So, I don't mind giving up a pretty trivial amount of bandwidth to  
help v6 adoption along - or at the very least do our part to make sure  
6to4 works for who we can.

-- Kevin

---

From: Gert Doering <[email-masked]>
Date: Sat, 2 Feb 2008 10:08:01 +0100

Hi,

> for customers of other ISPs? 

Why should it, indeed.  If he does not want to do that, nobody forces
him to announce the IPv4 anycast address / 2002::/16 to this other ISP.

> de-aggregate of 2002://16? That would create a huge increase in the routing

The response is likely to take a different path - independent of "anycast"
or not.  So the response is likely to take a relay that's run by the
ISP (or upstream ISP) of the other end.

If there are enough relays, those are well-maintained and monitored, 
and people stop playing political bullshit games, 6to4 could work nicely.

I do have some doubts about the "bullshit" part :(

Gert Doering
        -- NetMaster

---

From: Rémi Després <[email-masked]>
Date: Sat, 02 Feb 2008 10:22:08 +0100

> lunch. Who is going to pay for it?

Agreed.
6to4 was not designed as a general IPv6 deployment tool.
It was, and remains, an effective solution for two IPv6 clouds to 
communicate across a v4-only infrastructure, without involving ISPs.

The new approach I have been working on, and deployed by the French ISP 
Free, can combines advantages of 6to4 (simplicity and processing 
efficiency) with the fact that ISPs that operate relays do it for 
themselves.

An I-D 00 which describes it should be available in a few days (still 
under individual revisions).

Rémi

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 03 Feb 2008 15:35:14 +1300

below...

On 2008-02-02 21:32, Kevin Day wrote:
>> No one here is asking for ISP X to advertise its 6to4 relays at public
>> anycast addresses (either IPv4 or IPv6) into the default free zone.
>>
> 
> So, it's a pretty safe bet to say that there's a pretty large percentage
> of ISPs out there that have no current plans to either start their own
> relay, or make arrangements with someone who does.
> 
> So, I don't mind giving up a pretty trivial amount of bandwidth to help
> v6 adoption along - or at the very least do our part to make sure 6to4
> works for who we can.

Applause and kudos. Obviously, anyone who wants to filter those
announcements will do so.

     Brian

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 04 Feb 2008 10:10:39 +1300

Roll back the clock and I'm sure you'll find email 20 years old saying
things like
"the blackholes are responding to ICMP just
fine.  They just don't forward IPv4 from some networks (not others)."

As Gert hinted, this is the tedious part of deploying a new
protocol, i.e. chasing down the connectivity gaps one
at a time. I doubt it's specific to 6to4, though maybe we need
an FAQ on running a 6to4 relay.

   Brian

On 2008-02-02 09:45, James Woodyatt wrote:
>> relay so that CPEs can perform a keepalive check in determining

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 04 Feb 2008 10:03:52 +1300

> measurable.  I've seen the measurements.

Yes. And in fact other CPE vendors could reach the conclusion that this
is the easy way for them to offer some kind of v6 support. I agree
with Pekka that the BGP mode of deployment has been a bust so far,
but I don't see it as being actively harmful, so I don't really
see why we'd spend cycles on it. At least we do document that
2002:: prefixes longer than /16 must not be advertised, and that
seems to be useful text.

    Brian

---

From: Nathan Ward <[email-masked]>
Date: Tue, 5 Feb 2008 03:13:14 +1300

On 2/02/2008, at 8:37 AM, james woodyatt wrote:

> Extreme shipped.)  These ISP's have no plans to deploy 6to4 relays  
> in their own IPv6-capable networks, nor do they have any plan to  
> forward 6to4 traffic to relays that will carry it for them.  This is  
> making some large content providers *remove* their AAAA records when  
> they discover that customers behind 6to4 routers, e.g. AirPort  
> Extreme, are unable to receive service because their applications do  
> not fall back to IPv4 when IPv6 connectivity is broken.
>

Yup, I wrote an email here some time ago about this: "6to4 and  
'campus' networks".
My comments were more in relation to end hosts turning on 6to4 when  
they had non-RFC1918 addresses, but it still applies in the case of  
CPE turning on 6to4 in a similar situation (perhaps the CPE is behind  
NAT, or a firewall of some kind, or has a broken relay, etc.).

Applications /do/ fall back in my experience, however they take a long  
time to do so - I think my Mac did it in around 90 seconds or so when  
I last looked. Obviously, way past the user getting impatient, and  
declaring it 'broken'.

I'd be happy to follow it up, I've had a few thoughts about how this  
could work since then, and some thoughts about how it's painful. I'll  
write more when it's not 3am, however.

Some things to leave you with for now;
- 6to4 relays for the forward and reverse path between two hosts are  
likely to be different
- Teredo gets around problems by testing the relay bidirectionally  
when talking to any new host (no asymmetric relaying in Teredo of  
course)
- Any initial test needs to make sure that the following are both  
reachable bidirectionally, so we are sure we are not behind a stateful  
firewall, or NAT, etc.:
   o Host reachable through the magic (192.88.99.1) relay
   o 6to4 host that is not in 2002:c058:6301::/48 (192.88.99.1)
- If we are amending some parts of 6to4, should we consider optionally  
doing Teredo-like tricks for discovering relays closer to the non-6to4  
host? (ie. look at the IPv4 src addr in incoming packet, and use that  
for reaching that host in the future). Can we trigger that by doing an  
ICMPv6 echo request (as Teredo does), which would also verify that the  
selected relay is working.

Cheers,

--
Nathan Ward

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 05 Feb 2008 14:25:57 +1300

> de-aggregate of 2002://16? That would create a huge increase in the routing

Not allowed by RFC 3056. As stated there, the scope of advertisements
for 2002::/16 needs to be *managed*, because you're going to have to
encapsulate anything that arrives, on the assumption that there will
be a 6to4 router at the specified V4ADDR. So you'd better make sure
that only the IPv6 locations you want to serve can see your particular
2002::/16 advertisement, because you have no choice about the
V4ADDR destination.

Similarly, the scope of IPv4 advertisements for your relay (whether
it's 192.88.99.0/24 or anything else) needs to be limited to
IPv4 locations that you're willing to serve for 6to4. You have no
choice about the IPv6 destination.

In neither case do those locations have to be your own customers,
however. And there's no reason to expect symmetric paths.

I always expected 6to4 relay deployments to be altruistic,
not related to revenue.

    Brian

---

From: Nathan Ward <[email-masked]>
Date: Wed, 6 Feb 2008 16:35:41 +1300

> IMHO, this makes the deployment model of new servers a bit complex...

I'm unclear as to why a server would need three different addresses,  
as opposed to one address, and two relays. Rather, I'm unclear as to  
why that would be an improvement.

Deploying relays and a single address looks like:
- 6to4 paths:
-- client -> server - could be bad
-- server -> client - goes through our relay, and over v4 for the long  
portion of the path
- Teredo paths:
-- client -> server - goes through our relay, and over v4 for the long  
portion of the path
-- server -> client - goes through our relay, and over v4 for the long  
portion of the path

We can improve that by encouraging ISPs to deploy 6to4 relays today  
even (especially!) if they don't want to do a full v6 roll out to end  
users.

Like or or not, anyone doing v6 today should be deploying Teredo and  
6to4 relays, if they desire their paths to perform well to/from 6to4  
and Teredo end users. There are /lots and lots/ of them. My data would  
even suggest that there are more 6to4 and Teredo users than there are  
native v6 users, by several orders of magnitude.

--
Nathan Ward

--
Nathan Ward

---

From: Remi Denis-Courmont <[email-masked]>
Date: Wed, 6 Feb 2008 13:05:30 +0100

>>> issue called NAT which it can't 1,2,3 bypass, why not simply push

>>> Teredo forward which has all these points resolved already?

On the other hand, Teredo has some limitations that 6to4 does not have.

For a start, it can only provide one address per end-point. As such, while

it can address the "lame automatic 6to4 tunneling" PC problem (e.g. Vista),

it won't fix the "lame automatic 6to4 tunneling" access point/router

problem (e.g. Airport), as the router would have no prefix to advertise.

Then, Teredo requires state, not only on the gateway side, but also on the

relay side. Of course, fixing 6to4 to detect firewalls would unavoidably

require this too, so this is a lesser issue.

>> The Teredo model, actually from our observation with available code

>> from its major source, is that both end need to have it configured

>> to enable a reliable connection.

Yep, that is, both end sites. You can share a single Teredo relay from a

native V6CPE for an entire house, or for a whole server farm.

>> We tried with an open Teredo relay, and packets went sometimes to

>> Korea, sometimes nowhere.

There are very few public/global Teredo relays. Indeed, if you don't have

your own relay, your path may be very suboptimal.

>> In other words, this is fine to get IPv6 working between 2 PCs in

>> different

>> homes separated by NAT boxes, but this is not usable to access a

>> regular

>> IPv6 server on the Internet **UNLESS** that server also deploys

>> Teredo...

The server site would preferably have to have a relay. Not necessarily the

server itself. Of course, this is only useful if the server does not have

IPv4 at all. If it does have IPv4, then source address selection will go

for IPv4 instead of Teredo.

>> So, going that route, if an IPv6 server wants to offer reliable

>> service to

>> - a 6to4 address to serve 6to4 customers and avoid open relays

Even that won't solve most of the problems with 6to4.

> why that would be an improvement.

It would yield different result with source address selection, especially

if IPv4 is also available. However, there are practical problems, such as

how to put multiple IPv6 addresses with different source address selection

labels in the DNS... without breaking down every second IPv6 capable DNS

resolver on the client side.

-- 

Rémi Denis-Courmont

http://www.remlab.net