<p dir="ltr"></p>
<p dir="ltr">Sent from ipv6-only Android<br>
On Feb 28, 2013 4:30 AM, "Christopher Palmer" <<a href="mailto:Christopher.Palmer@microsoft.com">Christopher.Palmer@microsoft.com</a>> wrote:<br>
><br>
> Catching up to the thread... sorry if this is randomizing<br>
><br>
> <br>
><br>
> Dropping some info.<br>
><br>
> <br>
><br>
> 1. Window’s prefix policy, in Win8 and Win7, means that IPv4->IPv4 is generally preferred over 6to4->NativeIPv6. <br>
><br>
> 2. The majority of home users don’t have routers that support UPnP management of NAT/FW openings, at least from our telemetry.<br>
><br>
> <br>
><br>
> Separate from the IPv6 question, I’m not as enthusiastic on the ability of an everyday user to get IPv6 access. ISPs are often regional monopolies, and if your local market doesn’t have IPv6, you’re hosed. Tunnel brokers notwithstanding.<br>
><br>
> <br>
><br>
> Not to oversimplify the issue too much – but I’d bet that the easiest and most geographically available way to get IPv6 in the United States is to go to Verizon and get a new LTE hotspot for your house. A frustrating reality…<br>
><br>
> <br></p>
<p dir="ltr">Watch this space. <br></p>
<p dir="ltr">CB</p>
<p dir="ltr">><br>
> <br>
><br>
> From: ipv6-ops-bounces+christopher.palmer=<a href="mailto:microsoft.com@lists.cluenet.de">microsoft.com@lists.cluenet.de</a> [mailto:<a href="mailto:ipv6-ops-bounces%2Bchristopher.palmer">ipv6-ops-bounces+christopher.palmer</a>=<a href="mailto:microsoft.com@lists.cluenet.de">microsoft.com@lists.cluenet.de</a>] On Behalf Of Keith Moore<br>
> Sent: Tuesday, February 26, 2013 6:05 AM<br>
> To: Lorenzo Colitti<br>
> Cc: IPv6 Ops list; Kevin Day; Jared Mauch<br>
><br>
> Subject: Re: 6to4 status (again)<br>
><br>
> <br>
><br>
> On 02/26/2013 01:23 AM, Lorenzo Colitti wrote:<br>
>><br>
>> On Tue, Feb 26, 2013 at 3:07 PM, Keith Moore <<a href="mailto:moore@network-heretics.com">moore@network-heretics.com</a>> wrote:<br>
>>><br>
>>> The problem is that the advice is based on a false premise. Native access is NOT yet widely available in many parts of the world. If it were, there wouldn't be much 6to4 traffic, and turning off 6to4 relays wouldn't cause problems.<br>
>>><br>
>>><br>
>>> So a recommendation to drop 6to4 relays would, at the present time, be a very harmful recommendation.<br>
>><br>
>> <br>
>><br>
>> Sure, but as far as I can see, the only alternatives are:<br>
>><br>
>> Upgrade the box with 10G interfaces, incurring substantial cost.<br>
>> Drop the packets, degrading service quality.<br>
>><br>
>> Suppose operators take the position that they don't want to upgrade the relays because most of the traffic on them comes from third party networks, and thus #1 is infeasible. What then?<br>
><br>
><br>
> What I find myself thinking is that if you're not willing to spend more money on faster interfaces to the relays (which I see as a purely business decision, similar to whether to procure faster links to a peer), then one alternative to shutting down the relay entirely might be to advertise the route to that relay less favorably, so that it doesn't look like a good route to as many peers, thus reducing the load that way.<br>
><br>
> Hopefully more access providers will take up the slack so as to provide better 6to4 service for their customers, at least until those providers provide native v6 access to their customers. But I do see 6to4 relay as a service that probably has to migrate closer to the edge over time until there's no longer a need for it.<br>
><br>
> Keith<br>
><br>
> p.s. At my great distance, it does seem a bit odd for an operator to say, in effect, "too many people are wanting to send traffic to this prefix, therefore we need to shut down our link to it." Is that the way operators think about prefixes in general? But I also realize that there's nobody who speaks for 2002::/16 so there's no way to go to them and say "you need to pay us for more bandwidth". And I don't think that just because an operator is willing to run a relay, that this implies that they have to spend arbitrary amounts of money to keep it from dropping packets.</p>