Re: one data point regarding native IPv6 support

The situation in the UK appears similar to the US, with the exception of some really tech-friendly, passionate and clueful ISPs: either flat-out denial that IPv6 is important, in the smaller and well-off case, or else complete cluelessness, in the larger case. For larger ISPs, especially the re

Re: one data point regarding native IPv6 support

Hello all, I visited *http://www.worldipv6day.org/* which is an Internet Society website and clicked on *test* which took me to http://test-ipv6.com/# to do a test online for IPv6. When *http://test-ipv6.com/#* opened for me to run a test, part of the results says: "You appear to be able to brow

Re: one data point regarding native IPv6 support

Hello, > "You appear to be able to browse the IPv4 Internet only. You will not > be able to reach IPv6-only sites." > > Please can some one visit http://test-ipv6.com/# and give me more > explanation on the displayed result? That message is quite clear, isn't it? You use an Internet Service Provi

Re: one data point regarding native IPv6 support

Dear Stefan, Thank you for the reply. I think there should be a platform where IPv4 users and IPv6 users can interface. If this link is missing then there will be problem. Otueneh On Fri, Jun 10, 2011 at 10:09 AM, Stefan Winter wrote: > Hello, > > > "You appear to be able to browse the IPv4 Inte

Re: one data point regarding native IPv6 support

On Fri, Jun 10, 2011 at 05:55, otunte otueneh wrote: > Dear Stefan, > Thank you for the reply. > I think there should be a platform where IPv4 users and IPv6 users can > interface. If this link is missing then there will be problem. > > That kind of thing can be done - Google NAT64/DNS64 or how p

Re: one data point regarding native IPv6 support

Sadly this is more common than it should be these days. I've been begging Fairpoint for IPv6 for the past 3 years, from which people in NH/VT/ME now have been subjected to as Verizon sold off FIOS/dsl in those areas to them a while back. I have "business" service from them with static I

Re: one data point regarding native IPv6 support

I have a "Business service" from my ISP too. They told me that somewhere in 2012 they would look into IPv6. So I have threatened to move to another provider. But we do not have much choice in NL at the moment I believe. Although I have to re-checked recently. Bert On 6/10/11 3:04 PM, Thomas Na

Re: one data point regarding native IPv6 support

Michel, On 2011-06-10 15:38, Michel Py wrote: ... > On that one I agree with Keith; where's the rush? Although imperfect, > 6to4 was an obvious path and its demise would be the failure of the > IETF, following a long list of things that have been killed prematurely. Who's talking about its demise

Re: one data point regarding native IPv6 support

On Jun 10, 2011, at 9:34 AM, Brian E Carpenter wrote: > Michel, > > On 2011-06-10 15:38, Michel Py wrote: > ... >> On that one I agree with Keith; where's the rush? Although imperfect, >> 6to4 was an obvious path and its demise would be the failure of the >> IETF, following a long list of things

Re: one data point regarding native IPv6 support

--On Saturday, June 11, 2011 01:34 +1200 Brian E Carpenter wrote: >... > You're correct that some ISPs will try to get monopoly rents > out of the IPv4 shortage, and use CGN to capture customers in > walled gardens, but fortunately capitalism provides a solution > to such misbehaviour: other IS

Re: Last Call: (Conclusion of FYI RFC Sub-series) to Informational RFC

Please consider these: http://www.rfc-editor.org/pipermail/rfc-interest/2011-June/002518.html and http://www.rfc-editor.org/pipermail/rfc-interest/2011-June/002519.html as Last Call comments. Mykyta. 10.06.2011 16:18, The IESG wrote: The IESG has received a request from an individual submit

RE: one data point regarding native IPv6 support

Keith & John are hitting the crux of the issue here. The entire point of the automated tunneling technologies was to enable application development and deployment in the face of lethargic ISPs, that will refuse to move until they see a set of credible applications running in the wild. None of them

Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC

On Tue, Jun 7, 2011 at 11:20 AM, Keith Moore wrote: > Indeed, that is one of its main virtues. 6to4 decouples application > deployment of v6 from network deployment of v6, and helps reduce the > "chicken or egg" problem. > No, it does not - in fact, it is the opposite. Geoff has presented data

Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC

On Tue, Jun 7, 2011 at 3:47 PM, Keith Moore wrote: > Why are you trying to make life harder for developers of IPv6 applications? > There's no reason at all that an application developer should have to set > up a special-purpose network just to test an IPv6 application. > No, we're trying to make

Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC

On Wed, Jun 8, 2011 at 1:19 PM, Keith Moore wrote: > Again, 40-something percent of the IPv6 traffic that is observed on the net > today uses 6to4. > Please point at the data behind that assertion. In many cases in the past, such assertions have comes from networks that do not have the hardware c

Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC

On Thu, Jun 9, 2011 at 10:57 AM, Keith Moore wrote: > So the existence of 6to4 is in itself a significant barrier for IPv6 > deployment for server operators and content providers. > > non sequitur. Existing server operators and content providers can easily > provide 6to4 addresses for their serv

Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC

On Thu, Jun 9, 2011 at 11:37 AM, Keith Moore wrote: > I suppose we should just tunnel the whole IPv6 network over IPv4 + HTTP > then. > > Seriously, the argument that 6to4 should be trashed because ISPs are > blocking tunnels has the flavor of "don't solve the problem, but rather, > stamp out the

Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC

On Thu, Jun 9, 2011 at 12:01 PM, Brian E Carpenter < brian.e.carpen...@gmail.com> wrote: > > In a similar way as Geoff measured 6to4 - looking at SYNs. I suspect that > > the answer will be that much fewer users have configured tunnels than > 6to4, > > and that the failure rate is much lower. > >

RE: one data point regarding native IPv6 support

OTOH, my cable ISP provider has an "Expected IPv6 Transition Phases" chart, in which Phase 3 says, "Customer Premesis Equipment (CPE) IP addressing: IPv6 only". And they've started trials of IPv6 already. Dale ___ Ietf mailing list Ietf@ietf.org http

Re: one data point regarding native IPv6 support

At the risk of piling on, I can't resist the opportunity to try to one-up Ned's story. While in the UK this year, I had the misfortune to need to call BT for support on my broken home Internet connection. In the middle of the usual mind-numbing "we will force you to walk through every idiotic

Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC

> From: Lorenzo Colitti > Mac OS 10.6.4, which uses 6to4 by default, has a ~50x greater failure > rate when connecting to dual-stack servers than Mac OS 10.6.5 - and the > only change is to not use 6to4 by default. > ... > So the existence of 6to4 is in itself a significan

Re: one data point regarding native IPv6 support

On 2011-06-11 04:03, Tony Hain wrote: ... > There is no real problem with 6to4, despite the BS being propagated about > failure rates. That's no BS, unfortunately. Have you studied the careful reports at https://labs.ripe.net/Members/emileaben/6to4-how-bad-is-it-really and http://www.potaroo.net

RE: one data point regarding native IPv6 support

--On Friday, June 10, 2011 12:10 -0400 "Worley, Dale R (Dale)" wrote: > OTOH, my cable ISP provider has an "Expected IPv6 Transition > Phases" chart, in which Phase 3 says, "Customer Premesis > Equipment (CPE) IP addressing: IPv6 only". And they've > started trials of IPv6 already. Dale, I

Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC

On Jun 9, 2011, at 10:42 AM, Lorenzo Colitti wrote: > > We have data that clearly shows that Mac OS 10.6.4, which uses 6to4 by > default... I don't want anybody to be misled by this statement. I think what Lorenzo meant to say is that Mac OS X 10.6.4 and earlier doesn't implement the policy

Re: one data point regarding native IPv6 support

John, On 2011-06-11 05:05, John C Klensin wrote: ... > But, to the extent to which the motivation for moving 6to4 to > Historic is what Tony describes as "kill-what-we-don't-like", Unfortunately, as I know from the enormous amount of technical feedback I got from living, breathing operators whil

Re: one data point regarding native IPv6 support

> "Tony" == Tony Hain writes: Tony> There is no real problem with 6to4, despite the BS being Tony> propagated about failure rates. The fundamental problem is Tony> that those complaining have their heads firmly stuck in Tony> IPv4-think, and are refusing to add a second 6to4 p

Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC

> "Lorenzo" == Lorenzo Colitti writes: >> Why are you trying to make life harder for developers of IPv6 >> applications? There's no reason at all that an application >> developer should have to set up a special-purpose network just to >> test an IPv6 application. >>

Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC

On Jun 10, 2011, at 10:43 AM, Michael Richardson wrote: > > This all reminds of how killing the mbone killed multicast. Getting grumpy email from van because I sourced more than 128Kb/s killed the mbone, it was a toy. joel___ Ietf mailing list Ietf@

Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-pcn-cl-edge-behaviour-08 R

RE: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC

You cannot expect something to be configured correctly if it is simply turned on without a) being managed by someone or b) detection mechanisms to see if it's working. Sadly, anycasted 6to4 meets neither of these conditions. ISATAP meets both of these conditions: http://tools.ietf.org/html/draf

Re: [v6ops] Last Call:

On Jun 9, 2011, at 9:25 PM, Randy Presuhn wrote: > Your argument seems to be that the peculiar operational characteristics of > 6to4 > should give it additional immunity to being declared historic. I don't find > that > argument persuasive. That's not my argument. My argument is that declari

Re: one data point regarding native IPv6 support

On Jun 9, 2011, at 18:47 , Masataka Ohta wrote: > james woodyatt wrote: >> >> I need *native* IPv6 into my home in San Francisco for my day job, > > Really? Very very very few people have day jobs that require native IPv6 service to their home network today. I'm an exception because I have a r

Re: [v6ops] Last Call: (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC

On Jun 10, 2011, at 1:15 PM, james woodyatt wrote: > On Jun 9, 2011, at 10:42 AM, Lorenzo Colitti wrote: >> >> We have data that clearly shows that Mac OS 10.6.4, which uses 6to4 by >> default... > > I don't want anybody to be misled by this statement. I think what Lorenzo > meant to say is t

Re: [v6ops] Last Call:

On Jun 10, 2011, at 11:20 , Keith Moore wrote: > > Declaring 6to4 Historic certainly won't prevent people from implementing it. > But the proposed action is clearly intended to discourage implementation of > 6to4. It says so explicitly. Of course some vendors will ignore it, but > some vendo

RFP for Secretariat Services

The IETF Administrative Oversight Committee (IAOC) on behalf of the IETF announces this Request for Proposal for Secretariat Services. The Internet Society (ISOC) is the contractor. The Secretariat performs the following three types of services in support of the IETF: 1. Meeting Services 2. Cle

Re: one data point regarding native IPv6 support

--On Saturday, June 11, 2011 05:28 +1200 Brian E Carpenter wrote: > John, > > On 2011-06-11 05:05, John C Klensin wrote: > > ... >> But, to the extent to which the motivation for moving 6to4 to >> Historic is what Tony describes as "kill-what-we-don't-like", > > Unfortunately, as I know from

Re: one data point regarding native IPv6 support

On Fri Jun 10 17:15:55 2011, Nathaniel Borenstein wrote: At the risk of piling on, I can't resist the opportunity to try to one-up Ned's story. While in the UK this year, I had the misfortune to need to call BT for support on my broken home Internet connection. In the middle of the usual

Re: one data point regarding native IPv6 support

John, On one specific point: >> So my personal preference, in a more perfect world, would be to >> fold these two drafts together, I specifically pushed for the -advisory draft to be kept separate and Informational in order to get it out ASAP (in my dreams, before IPv6 Day, but that didn't prov

Re: one data point regarding native IPv6 support

james woodyatt wrote: > Very very very few people have day jobs that require native IPv6 > service to their home network today. > > I'm an exception because I have a requirement that IPv6 and IPv4 > provide more or less *equivalent* performance characteristics. Use 4 over 4 in addition to 6 over

Re: Liaison and request for review of ITU-T document

Ralph, As far as I can tell this seems to describe some sort of a Layer 2 stateful per-flow QoS mechanism using new Ethertype headers. As such I don't see why the IETF would care. The point of it escapes me, since we have plenty of reason to believe that such solutions are impractical and do not s

Re: one data point regarding native IPv6 support

On Jun 10, 2011, at 10:28 AM, Brian E Carpenter wrote: > John, > > On 2011-06-11 05:05, John C Klensin wrote: > > ... >> But, to the extent to which the motivation for moving 6to4 to >> Historic is what Tony describes as "kill-what-we-don't-like", > > Unfortunately, as I know from the enormous

Re: one data point regarding native IPv6 support

On Jun 10, 2011, at 15:10 , Joel Jaeggli wrote: > > I think the two documents at present encourage: > > * vendors an implementors to consider not using or a least disabling by > default 6to4 auto-tunneling in existing and future implementations. > > * the deployment of additional 6to4 anycast

Re: one data point regarding native IPv6 support

--On Friday, June 10, 2011 15:10 -0700 Joel Jaeggli wrote: > I'm a content provider. I'm am prepared to turn on more ipv6 > services that are visible to consumers. 6to4 is a visible and > measurable source of collateral damage. If consenting adults > want to use it that's fine, I would greatly

Re: one data point regarding native IPv6 support

As for Geoff figures. No one as far as I know has done measurements of 6to4 failure of explictly enabled 6to4. Yes Geoff figures seem scary but if vendors were to make 6to4 users do something to turn it on I truly think the failure rate would be in the noise. Lots of the perceived issues with b

Re: one data point regarding native IPv6 support

In message <92f90cdd-6da4-4b7f-bbcc-5da43a43a...@bogus.com>, Joel Jaeggli write s: > > On Jun 10, 2011, at 10:28 AM, Brian E Carpenter wrote: > > > John, > > > > On 2011-06-11 05:05, John C Klensin wrote: > > > > ... > >> But, to the extent to which the motivation for moving 6to4 to > >> Histo

Re: one data point regarding native IPv6 support

Mark Andrews wrote: > Lots of the perceived issues with broken 6to4 go away with reasonable > application support for multi-homed servers. True. A major design flaw of IPv6 is half hearted support for multihoming with multiple addresses by broken address selection architecture, which causes a lo

Re: one data point regarding native IPv6 support

In message <4df2ba67.9080...@necom830.hpcl.titech.ac.jp>, Masataka Ohta writes: > Mark Andrews wrote: > > > Lots of the perceived issues with broken 6to4 go away with reasonable > > application support for multi-homed servers. > > True. > > A major design flaw of IPv6 is half hearted support fo

Itojun Service Award Announcement

Dear IETFers, Please note below regarding the Itojun Service Award. The deadline is July 15. Thanks in advance, Jun Murai === ANNOUNCING: CALL FOR CANDIDATES FOR ITOJUN SERVICE AWARD The Itojun Service Award is presented every year to an individual or a group who has made outstanding contributions

Re: one data point regarding native IPv6 support

>I would say it's about time reality finally settles in. The reality is that for now and for the next several years, anyone who wants to communicate with "the Internet" had better figure out how to get their packets back and forth to the IPv4 Internet. This is totally unfair to new entrants who d

RE: one data point regarding native IPv6 support

Brian, >> Michel Py wrote: >> On that one I agree with Keith; where's the rush? Although >> imperfect, 6to4 was an obvious path and its demise would be >> the failure of the IETF, following a long list of things >> that have been killed prematurely. > Brian E Carpenter wrote: > Who's talking abou

Re: Last Call: (Reducing the Standards Track to Two Maturity Levels) to BCP

08.06.2011 10:58, Dave Cridland wrote: On Wed Jun 8 05:57:15 2011, Pete Resnick wrote: On 6/7/11 11:00 PM, Peter Saint-Andre wrote: And, more to the point I think, to greatly decrease the quality of RFCs published. Perhaps that's OK, but we need pretty strong consensus that it's the right thin