Mike Leber | 1 Mar 21:34 2009
Picon

Re: SWIPnet relay handling most U.S. east coast 6to4 traffic?


Thor Lancelot Simon wrote:
>>From almost anywhere in the Eastern U.S. I test from, traceroutes to
> the 6to4 anycast address seem to land at SWIPnet in Amsterdam.  This
> is because SWIPnet seems to peer with several major U.S. providers in
> New York City, giving a short path from many networks in the U.S. to
> their Amsterdam relay -- notably, from the networks of the major U.S.
> residential cable providers, Time Warner and Cablevision.
 >
> It looks like most public-relay traffic from a large chunk of the U.S.
> could stop tromboning through Europe (and wasting SWIPnet's link
> bandwidth across the Atlantic) if a 6to4 relay were added to one of
> SWIPnet's NYC core routers.  Is there any chance of this?

We deployed 6to4 relays in the US, Europe, Asia to help fix exactly this 
problem, and we announce the 192.88.99.0/24 and 2002::/16 anycast 
prefixes globally at all locations to all peers and customers.

However, there's no way for any specific peer to know that any one 
network announcing 6to4 anycast prefixes does or does not have more than 
one relay, or that they have a relay thats right there next to them that 
they should be using for better performance (instead of tromboning).

I guess that's a matter of choice between the network that announces the 
prefixes being used and the network that is listening to those prefixes 
and using them.

Mike.

--

-- 
(Continue reading)

Marco d'Itri | 1 Mar 22:31 2009
Picon

Re: SWIPnet relay handling most U.S. east coast 6to4 traffic?

On Mar 01, Mike Leber <mleber <at> he.net> wrote:

> I guess that's a matter of choice between the network that announces the  
> prefixes being used and the network that is listening to those prefixes  
> and using them.
IOW, some careful application of the cluebat is needed to enlighten the
staff of networks which choose a scenic route to the relays.

--

-- 
ciao,
Marco

Hank Nussbacher | 26 Mar 06:29 2009
Picon

Biggest mistake for IPv6: It's not backwards compatible, developers admit

<http://www.networkworld.com/news/2009/032509-ipv6-mistake.html?netht=ts_032509&nladname=032509dailynewspmal>

-Hank

Steve Wilcox | 26 Mar 16:51 2009
Picon

Re: Biggest mistake for IPv6: It's not backwards compatible, developers admit

Well, it was designed 15 years ago with the intention that it would be rolled out in less than aforementioned time period, without a sudden urgency brought on by slow adoption! So to be fair, the design probably could have been better but I guess they were still living in a time period when widescale protocol changes were do-able and taken seriously...

Steve




--
Network Operations - Standards & Design
Google Inc.
E: stevewilcox <at> google.com
M: +44 7920 041930
Thomas Jacob | 26 Mar 17:55 2009
Picon

Re: Biggest mistake for IPv6: It's not backwards compatible, developers admit

On Thu, 2009-03-26 at 15:51 +0000, Steve Wilcox wrote:
> Well, it was designed 15 years ago with the intention that it would be
> rolled out in less than aforementioned time period, without a sudden
> urgency brought on by slow adoption! So to be fair, the design
> probably could have been better but I guess they were still living in
> a time period when widescale protocol changes were do-able and taken
> seriously...
> 
> Steve

I am sure some people here have already read DJBs abrasive views on the
matter but if you compare the IPv4/IPv6 switch to the introduction
MX records in the 80s, as he does, it seems already at that
time some people were aware of workable methods for making
such protocol changes be adopted quickly.

http://cr.yp.to/djbdns/ipv6mess.html

The introduction of support for CIDR routes into the BGP protocol in 94
might be considered another example of prior art.

Sure those things are less fundamental then the layer 3 protocol.

On the other hand, this last statement might equally well be used in
support for the opposite thesis.

But being wise after the fact is always easy ;)

   Thomas

Steve Wilcox | 26 Mar 18:34 2009
Picon

Re: Biggest mistake for IPv6: It's not backwards compatible, developers admit



On Thu, Mar 26, 2009 at 4:55 PM, Thomas Jacob <jacob <at> internet24.de> wrote:
On Thu, 2009-03-26 at 15:51 +0000, Steve Wilcox wrote:
> Well, it was designed 15 years ago with the intention that it would be
> rolled out in less than aforementioned time period, without a sudden
> urgency brought on by slow adoption! So to be fair, the design
> probably could have been better but I guess they were still living in
> a time period when widescale protocol changes were do-able and taken
> seriously...
>
> Steve

I am sure some people here have already read DJBs abrasive views on the
matter but if you compare the IPv4/IPv6 switch to the introduction
MX records in the 80s, as he does, it seems already at that
time some people were aware of workable methods for making
such protocol changes be adopted quickly.

http://cr.yp.to/djbdns/ipv6mess.html

The introduction of support for CIDR routes into the BGP protocol in 94
might be considered another example of prior art.

Sure those things are less fundamental then the layer 3 protocol.

I think thats part of it - they are less fundemental.

Also, none of them required a complete change end to end.. in v6 you need to have user apps, user OS, access layer, backbone layer, content all enabled .. its affects all components at most layers.


 


On the other hand, this last statement might equally well be used in
support for the opposite thesis.

But being wise after the fact is always easy ;)

  Thomas




--
Network Operations - Standards & Design
Google Inc.
E: stevewilcox <at> google.com
M: +44 7920 041930
Brandon Butterworth | 26 Mar 19:29 2009
Picon

Re: Biggest mistake for IPv6: It's not backwards compatible, developers admit

I don't see the point of raking over history. It's too late,
lots of things could have been different but they aren't.

The effort is best spent making good of what we do have

brandon

Doug Barton | 26 Mar 19:32 2009
Picon

Re: Biggest mistake for IPv6: It's not backwards compatible, developers admit

Brandon Butterworth wrote:
> I don't see the point of raking over history. 

The value would be in recognizing the mistakes that were made and
learning from them in order to avoid making them again. Unfortunately
I don't see any willingness to take an honest look at the mistakes
that were made, so you're right, there is no value in rehashing the
history.

Doug

Scott Beuker | 26 Mar 22:07 2009
Picon

RE: Biggest mistake for IPv6: It's not backwards compatible, developers admit

> > I don't see the point of raking over history.
> 
> The value would be in recognizing the mistakes that were made and
> learning from them in order to avoid making them again. Unfortunately
> I don't see any willingness to take an honest look at the mistakes
> that were made, so you're right, there is no value in rehashing the
> history.

Furthermore, I think it's highly debatable whether the big mistake
was technical (a lack of backwards compatibility), or business (the
industries lack of timely action). Or both.

It seems to be fashionable this month to point the finger at IPv6 for
having failed us, but dual-stack could have been a solid transition
mechanism if started earlier. But, you know, something about leading
a horse to water and then he doesn't drink.

- Scott Beuker

Fred Baker | 27 Mar 02:53 2009
Picon

Re: Biggest mistake for IPv6: It's not backwards compatible, developers admit

Also, I think it is only fair to point out that they didn't have the  
option of making it backwards compatible with IPv4; it's not that they  
didn't, it's that they couldn't. How, precisely, would you make an  
IPv4 packet that has longer addresses? IPv4 forces any change to the  
header to become a new protocol.

I could imagine making a protocol (IPv17 if you like) that was a  
different protocol than IPv4 but had a variable length address: for  
example, it might be a tuple that contained the length of the tuple,  
the length of the network part, the length of the host part, the  
network part, and the host part. If the other fields were the same as  
IPv4, one could imagine deploying the new protocol in such a way that  
a translator could go between them, and put IPv17 in the backbone. We  
would be in a position much like we are now, however; from 1995 until  
now nobody would see a business justification for deployment, and  
folks who deployed would find that they had a hard time talking with  
folks who had not. It would be essentially the same issue we face now.

On Mar 26, 2009, at 2:07 PM, Scott Beuker wrote:

>>> I don't see the point of raking over history.
>>
>> The value would be in recognizing the mistakes that were made and
>> learning from them in order to avoid making them again. Unfortunately
>> I don't see any willingness to take an honest look at the mistakes
>> that were made, so you're right, there is no value in rehashing the
>> history.
>
>
> Furthermore, I think it's highly debatable whether the big mistake
> was technical (a lack of backwards compatibility), or business (the
> industries lack of timely action). Or both.
>
> It seems to be fashionable this month to point the finger at IPv6 for
> having failed us, but dual-stack could have been a solid transition
> mechanism if started earlier. But, you know, something about leading
> a horse to water and then he doesn't drink.
>
> - Scott Beuker


Gmane