On Feb 9, 2011, at 11:06 AM, Eric Brunner-Williams wrote:

well, i've argued new gtld registry operators in general do not benefit from a manditory v6 reachability requirement at transition to delegation, a position unpopular with v6 evangelicals and others who suppose that new gtld registry operators will exist to serve "the next billion users" rather than to offer alternate name space views to the existing {b,m}illions of v4 addressed spindles.

I disagree... I think that offering alternate name space views to the existing {b,m}illions of v4 addressed spindles requires IPv6 reachability as well since those will also be adding IPv6 capabilities in the next year or two. It's not that I think you only serve the future. It's that we think you are failing to recognize that IPv6 is now and that what is IPv4 today will be at least dual-stack tomorrow.

related, i've argue that new gtld registry operators in general do not benefit from a manditory dnssec requirement, a position unpopular with dnssec evangelicals and others who suppose that new gtld registry operators will exist to serve ecommerce with sufficient generality, persistence, and volume to make them more attractive targets for rational economic exploits than existing, unsigned zones.

for those not keeping track, icann's laundry list of mandatory to implements includes v6 reachibility, and dnssec, shortly after the date of contract, so significantly prior to the operator acquiring operational experience, and of course, cctlds, and existing gtlds, are under no obligation to sign their zones.

The latter part of that paragraph is an unfortunate artifact of a pre-existing contract without those requirements. I would expect those requirements to be added at contract renewal.

i don't think of these positions as "naysaing" either v6 or dnssec, just the it-must-be-done-now claims of urgency and universality of some of the respective advocates for "sensible stuff", who because they hold the right opinion, inform icann's ssac.

I think that the requirements are reasonable and that it is unfortunate that they cannot be added to the existing GTLD contracts. Owen

On Feb 9, 2011, at 3:08 PM, Eric Brunner-Williams wrote:

...

I disagree... I think that offering alternate name space views to the existing {b,m}illions of v4 addressed spindles requires IPv6 reachability as well since those will also be adding IPv6 capabilities in the next year or two.

so your claim is that to have a .cat, serving registrants currently using v4 provisioned hosting services, and end-users currently using v4 provisioned eyeball networks, and initially address and resources (but not names) currently extant in the com/net/org/biz/info namespaces [1], the .cat registry first has to be v6 reachable.

My claim is that about the time these zones are rolling out, the registrants currently using v4 provisioned hosting services and end users currently using v4 provisioned eyeball networks will also, at least in some cases, be using dual stack and/or v6 services.

and this claim is true because the webhosting operators, primarily in Catalonia, who have v4 now, will themselves be v6 reachable in the next year or two ... i think this requires either the existing hosting operators abandon vhosting as a service model or abandon their existing v4 allocations.

You do not have to abandon v4 to deploy v6. That's an absurd claim.

now rinse and repeat for .nyc. the claim is somehow that the market for hosting operators (ok, the hosting lines of business of godaddy, tucows, enom, netsol, ... and their downstream resellers, which is statistically likely to have 51% of all .nyc registrations), and/or (your choice) the eyeball network operators for the tri-state area, are going to either abandon vhosting as a service model or abandon their existing v4 allocations ...

Again, the need for v6 is not predicated on the abandonment of v4.

where the v6 ab initio convinces me some is the area i currently work on -- developing economies. nigeria is a good example, fewer than 10^^5 computers, a population of 15x10^^7, and cell phone penetration rate approaching 1 in 3. even so, the number of v6 prefixes in afnic's inventory of allocations is ... very small ... for all of africa as a region.

I believe AfriNIC has a /12 like any other RIR. I'm not sure what you are saying here.

...

It's not that I think you only serve the future. It's that we think you are failing to recognize that IPv6 is now and that what is IPv4 today will be at least dual-stack tomorrow.

if the window for applications opens 4 months after icann-41 (amman, jordan), in q42011, then delegations will occur as soon as q32012.

Yes.

is your claim that registry operators where v6 is _sparce_, and/or where v6 eyeball networks are _sparce_, two years from today, are properly failed for technical reasons, two years from today, for lack of v6 capability?

I'm not sure what you mean by _sparce_. My claim is that by 4q2012, I expect we will see much much wider IPv6 deployment and potentially eyeball networks that are primarily or exclusively IPv6 with at best limited or degraded IPv4 support through multiple layers of NAT. As such, I think that registries spinning up in 3q2012 should be required to have IPv6 support. yes.

if your claim is that v6 is mandatory to implement sometime soon, i'm fine with that rather flexible temporal requirement, but icann's current rules of the road are an application that isn't v6 ready at transition to delegation (roughly two years from now) fails.

If you define soon as prior to 2q2012, then, yes, I'm fine with that. However, that seems to be about a quarter earlier than you think these things will be starting up. Since you seem to be claiming they should get some period beyond that where they don't need to run IPv6 (I'm not sure where they're supposed to get their addresses to run on IPv4 by then, frankly), I think your definition of soon and mine are probably not compatible.

pessimally, the requirement is present at the date when applications are submitted, that is, a year from today.

I don't think that 1q2012 is especially out of line given a 2q2012 target date.

now there's still 24 months for icann legal staff to acquire clue, and for last week's press event to galvanize operators everywhere, so perhaps this (and its cognate, dnssec at transition to delegation) can be elided, but it is irresponsible to assert [2], independent of the purpose and position of a registry, that it must have a feature due to the universalist claims of advocates for a particular technology.

I think it is irresponsible at this point to consider deploying any major network infrastructure without requiring IPv6 capabilities at deployment. IANA is already out of IPv4. If you expect these systems to start getting deployed in 3q2012, then, you're talking about a time which is likely to be well past RIR exhaustion in most cases. I suppose they can get a /22 from APNIC, but, other than that, where do you expect these organizations to even get IPv4 to work with?

thanks for your difference, -e

Any time. Owen

On Feb 10, 2011, at 7:00 AM, Eric Brunner-Williams wrote:

On 2/9/11 10:32 PM, Owen DeLong wrote:

...

On Feb 9, 2011, at 3:08 PM, Eric Brunner-Williams wrote:

...

...

I disagree... I think that offering alternate name space views to the existing {b,m}illions of v4 addressed spindles requires IPv6 reachability as well since those will also be adding IPv6 capabilities in the next year or two.

so your claim is that to have a .cat, serving registrants currently using v4 provisioned hosting services, and end-users currently using v4 provisioned eyeball networks, and initially address and resources (but not names) currently extant in the com/net/org/biz/info namespaces [1], the .cat registry first has to be v6 reachable.

My claim is that about the time these zones are rolling out, the registrants currently using v4 provisioned hosting services and end users currently using v4 provisioned eyeball networks will also, at least in some cases, be using dual stack and/or v6 services.

"in some cases" is a poor motivation for a general mandatory-to-implement requirement. a "v6 where required (by other market actors than icann's legal staff in marina del rey)" form would be appropriate -- but you're making a universal claim, so on we go...

I said "at least in some cases". Since we know that it will be a monotonically increasing set of "some cases" which will rapidly grow to a very high fraction of "some cases", yes, it is a good motivation for a general mandatory-to-implement requirement.

inter alia, that both ends of the chain of resolution (stub resolver on an eyeball network and mapped resource in a hosting provider rack) may be using dual-stack fails to motivate why the authoritative name to address resolver must be v6 reachable.

We can agree to disagree about this.

...

...

and this claim is true because the webhosting operators, primarily in Catalonia, who have v4 now, will themselves be v6 reachable in the next year or two ... i think this requires either the existing hosting operators abandon vhosting as a service model or abandon their existing v4 allocations.

You do not have to abandon v4 to deploy v6. That's an absurd claim.

yet it is the claim you are making. the resource must be v6 reachable, and you're not offering arbitrary capriciousness of some evangelically unbalanced lawyers in a high-rise in marina del ray as a rational, so you must have a material necessity rational.

No, it is not. I am claiming that you need to have IPv6 capabilities on critical internet infrastructure because: + The internet is moving to IPv6. + We will be out of free IPv4 addresses by the time these services are being deployed. + A monotonically increasing number of clients will have no or limited/degraded IPv4 access at or soon after deployment of these new GTLDs.

...

...

now rinse and repeat for .nyc. the claim is somehow that the market for hosting operators (ok, the hosting lines of business of godaddy, tucows, enom, netsol, ... and their downstream resellers, which is statistically likely to have 51% of all .nyc registrations), and/or (your choice) the eyeball network operators for the tri-state area, are going to either abandon vhosting as a service model or abandon their existing v4 allocations ...

Again, the need for v6 is not predicated on the abandonment of v4.

you've managed to elide responding to both (a) an actual new (in 2005) registry, with existing v4 provisioning, and (b) a pending new (in 2012) registry, again with existing v4 provisioning.

i look forward to learning why .cat failed for lack of v6, and why .nyc will fail, for lack of v6, in a sentence that doesn't contain a reference to lawyers in a high-rise in marina del ray.

I never claimed that .cat failed because of lack of IPv6 as I have no first hand knowledge of the failure of .cat. I never claimed that .nyc would fail because of lack of IPv6. I don't know whether either of those claims is true. If either claim is true, then, certainly, it would be evidence that we need IPv6 for new deployments of critical infrastructure that it is a valid requirement for new GTLDs. However, even if both claims are false, it does not eliminate the need for new GTLDs to provide support for IPV6. There are no lawyers in Marina Del Rey in these statements: + The internet is moving to IPv6. + We will be out of free IPv4 addresses by the time these services are being deployed. + A monotonically increasing number of clients will have no or limited/degraded IPv4 access at or soon after deployment of these new GTLDs. + In a world where there are IPv4 only, IPv4/IPv6 dual stack and IPv6 only hosts, critical infrastructure such as GTLD services should be required to be dual-stack.

...

...

where the v6 ab initio convinces me some is the area i currently work on -- developing economies. nigeria is a good example, fewer than 10^^5 computers, a population of 15x10^^7, and cell phone penetration rate approaching 1 in 3. even so, the number of v6 prefixes in afnic's inventory of allocations is ... very small ... for all of africa as a region.

I believe AfriNIC has a /12 like any other RIR. I'm not sure what you are saying here.

try looking beyond what the iana has allocated to a rir, and look at what prefixes the rir has allocated. alternatively, something along the lines of trivial pursuits, name the data centers and/or eyeball networks in africa in which v6 was deployed in q42010.

I guess your point is that AfriNIC and Africa in general is behind the rest of the world in IPv6 deployment? I'm not sure how that is relevant to the fact that IPv6 is a valid requirement for new GTLD infrastructure other than to say that dropping this requirement might impact Africa less than other parts of the world.

...

...

...

It's not that I think you only serve the future. It's that we think you are failing to recognize that IPv6 is now and that what is IPv4 today will be at least dual-stack tomorrow.

if the window for applications opens 4 months after icann-41 (amman, jordan), in q42011, then delegations will occur as soon as q32012.

Yes.

...

is your claim that registry operators where v6 is _sparce_, and/or where v6 eyeball networks are _sparce_, two years from today, are properly failed for technical reasons, two years from today, for lack of v6 capability?

I'm not sure what you mean by _sparce_.

See africa, v6 availability, above.

Oh, you mean sparse and the_..._ is for emphasis. I thought it was offsetting some special word. Sorry for the misunderstanding. My claim is that if you are running GTLD services, then, you are dealing not with any particular region, but, with providing global infrastructure. The sparseness of IPv6 infrastructure in Africa is not particularly relevant to the question of whether or not global infrastructure needs to support IPv6 going forward.

...

My claim is that by 4q2012, I expect we will see much much wider IPv6 deployment and potentially eyeball networks that are primarily or exclusively IPv6 with at best limited or degraded IPv4 support through multiple layers of NAT.

now that is an interesting claim. suppose it is true and there is "at best limited or degraded IPv4" on eyeball networks. why is a once per session trip up and down the chain of resolution sufficient to motivate anything?

Are you serious? If it's not, then we don't really need GTLDs at all, do we?

further, why do you suppose that new gtld registries, but not existing gtld registries, have an affirmative duty to be v6 reachable from resolvers on v6-only eyeball networks?

I never said existing gtld registries don't have such an affirmative duty. I think ICANN severely erred in not including IPv6 in the provisions of earlier contracts. I have said that before this topic ever came up. The fact that ICANN made a mistake previously does not mean we should expand that mistake or continue making that mistake.

what is the point of partitioning content along "legacy v4 provisioned content, and its v4 provisioned access demographic" and "new gtld mapped content and its v6 provisioned access demographic"?

What? I'm not trying to partition anything. I'm trying to make sure that any new GTLDs support access from the entire internet and not just the limited and diminishing proportion of the internet that has IPv4 going forward.

to be really convincing, it would help if you'd make the case that existing v4-reachable-only registries must be v6 reachable or fail, just as you'd fail a new gtld applicant lacking v6.

I absolutely think that existing v4-reachable-only registries must be v6 reachable or fail. They may not fail quite so immediately, but, again, I absolutely believe ICANN erred in not making this a requirement for those registries. I certainly don't see using a previous mistake as a reason that we should extend or expand that mistake to new registries.

...

As such, I think that registries spinning up in 3q2012 should be required to have IPv6 support. yes.

see above.

See answers above.

...

...

if your claim is that v6 is mandatory to implement sometime soon, i'm fine with that rather flexible temporal requirement, but icann's current rules of the road are an application that isn't v6 ready at transition to delegation (roughly two years from now) fails.

If you define soon as prior to 2q2012, then, yes, I'm fine with that. However, that seems to be about a quarter earlier than you think these things will be starting up. Since you seem to be claiming they should get some period beyond that where they don't need to run IPv6 (I'm not sure where they're supposed to get their addresses to run on IPv4 by then, frankly), I think your definition of soon and mine are probably not compatible.

first, refer to the statistical likelihood date of v4 exhaustion in the afnic region. there's a nice graph available that shows very broad shoulders, several years of availability.

We're talking about GTLD registries, not African CCTLD registries. GTLDs are GLOBAL. Look at the v4 exhaustion graphs for APNIC, ARIN, and RIPE. The fact that you can point to a single region that some prognosticators say will have space for a few years longer than everyone else really isn't a relevant argument against the need for GTLDs to support IPv6.

second, registries are critical internet infrastructure, and in the arin region prop 125, which you know about having commented on it, there exists a policy of reserve for ci requirements, and 125 provides for three (3) years of resource availability to the allocation receiving ci requester. requesting a 125-similar policy for the rir with the next most proximal statistical likelihood date of v4 exhaustion, the ripe region, is on my todo list.

Again, not seeing relevance here. I have no belief that registries don't need IPv4 support. GTLD registries should absolutely be required to support both protocols until such time as IPv4 can be deprecated in general.

note however, that few applications for registries located in the arin or ripe regions, where the statistical likelihood date of v4 exhaustion is both most proximal, and the confidence level narrowest, are likely to meet the general reading of the icann board of directors' resolution #20 (nairobi), expressing an interest in forms of cost-reduction assistance to needy applicants, e.g., from "developing countries".

I really don't see how that is relevant to whether GTLD registries should be required to have IPv6 support or not. Regardless of where the registry is based, they are providing a global service. They should be required to support the global internet.

...

...

pessimally, the requirement is present at the date when applications are submitted, that is, a year from today.

I don't think that 1q2012 is especially out of line given a 2q2012 target date.

...

now there's still 24 months for icann legal staff to acquire clue, and for last week's press event to galvanize operators everywhere, so perhaps this (and its cognate, dnssec at transition to delegation) can be elided, but it is irresponsible to assert [2], independent of the purpose and position of a registry, that it must have a feature due to the universalist claims of advocates for a particular technology.

I think it is irresponsible at this point to consider deploying any major network infrastructure without requiring IPv6 capabilities at deployment. IANA is already out of IPv4. If you expect these systems to start getting deployed in 3q2012, then, you're talking about a time which is likely to be well past RIR exhaustion in most cases. I suppose they can get a /22 from APNIC, but, other than that, where do you expect these organizations to even get IPv4 to work with?

just how many endpoint identifiers do you think a registry requires?

I don't know. I presume that they need a handful for DNS servers, some for web servers, some for miscellaneous infrastructure.

i don't think this is your best argument, as it requires a suspension of belief that there is a market, or markets, in allocations sufficient to provision anything from a half-rack to multiple racks in a standard cage, and the margin on a registry footprint is lower than the margin on most other hosting operations.

You're right. For the time being, it probably won't be hard for them to obtain IPv4 resources and that really isn't relevant to whether or not they need to provide services over IPv6. The relevant part is the number of potential people trying to use their services that may not have IPv4 access.

if you're going to swing for the fence, don't try to argue lack of something that can still be bought for some time to come. make the claim that registrants (other than ppc registrants, that's a separate case you may want to make, and if so, don't forget the eyeball network operator as a beneficiary from systemic synthetic return, a la verisign's sitefinder) demand that their resources be resolvable by v6 only paths because there is sufficient revenue in v6 reachability, or that v6 only registrations will, in the twelve quarters of operation, provide more revenue, or at least enough to cover costs and reduce the likelihood of registry failure, than the v4 only registrations.

As I said. I think that registries should be required to support both protocols as a simple matter of compatibility with the state of the global internet during the time of their service. It would be absurd to allow a registry with support only for IPX. A such, in the internet that will exist during the terms of these contracts, it would be absurd to allow a registry without support for both IPv4 and IPv6. However, I can see the possibility of a case where a registry is actually unable to get sufficient IPv4 resources during the contract period. In such a case, I do not believe that inability should be held against them. However, with regards to IPv6, there is no such excuse.

having made any case based upon benefit, it would be illuminating to opine why no existing registry operator is experiencing v6 uptake by its registrants supporting a registrant beneficiary theory.

The case for benefit is not there yet. However, as you pointed out, everything we're talking about is 18-24 months away from operations, so, the case will change a lot in that time. The case that is there now is the fact that we all know the internet is changing and that IPv4 addresses are becoming scarce. Deployment of critical infrastructure without dual stack (or at least IPv6) support at this point is irresponsible going forward.

...

...

thanks for your difference, -e

Any time.

less religion, more near-term numbers. t.i.a.

No problem. Owen

On Feb 14, 2011, at 7:12 AM, Eric Brunner-Williams wrote:

owen,

at several points you assert that gtlds are "global", which i suggest is an error on your part.

TLDs come in two flavors. GTLD -- Global Top Level Domain -- A domain which contains records for entities not restricted to a particular geographical area. CCTLD -- Country Code Top Level Domain -- A domain which is under the control of a particular national government represented by the corresponding 2-letter ISO country code. The G in GTLD is Global... I'm not asserting anything, it's flat out in the term.

gtlds are whatever the controlling contract (icann) requires, and that currently lacks an external to the point of service performance measurement, and whatever the registrants require, with some filtering through the marginal interests of registrars.

Your point being?

the icann contract for the .cat registry is "sponsored", and the interest of the registry, and its registrants, is marginal outside of catalonia.

Interest in .cat may or may not be marginal. Doesn't matter. The nature of any policy regarding GTLDs is that it relates to more GTLDs than just ".cat". GTLDs are, by definition, global in scope on the internet and any policy about them should be viewed in that light.

the icann contract for some municipality or region, assuming the new gtld program results in new contracts, may be "standard" or "community-based", but the intersts of the registry, and its registrants, may also be marginal outside of that municipality or region.

Your point being?

you can decide for yourself if your preference for the policy and profit margins for .nyc are controlling, or if the preferences of the city administration, the registry operator, and, using either the .cat or the .nl rates of adoption, a quarter of a million or four million new yorkers are controlling.

First, I think giving all of these random things a GTLD to begin with is an absurd process fraught with peril to satisfy ICANN's greed. However, that's not my decision. If ICANN is going to move forward with this mess, the least we can do is try to have consistent policy for all GTLDs. While I recognize that ICANN lacked the foresight to make it possible to apply updated technical requirements to existing GTLD operators until their contract comes up for renewal, that is no reason we should not have reasonable and current requirements for new GTLDs.

if there is a registry the operations for which you are familiar enough to discuss, we can discuss the necessity and utility of a v6 reachibility requirement, though the prior to delegation requirement is unique to the proposed contract for new registries.

All operators should be required to support IPv6. If ICANN had done their job properly, this requirement would be applied to existing operators too. Unfortunately, ICANN dropped the ball and the contracts don't allow that. The fact that ICANN dropped the ball on existing registries isn't a reason to drop the ball on new ones. Owen

On 2/14/11 3:30 PM, Owen DeLong wrote:

On Feb 14, 2011, at 7:12 AM, Eric Brunner-Williams wrote:

...

owen,

at several points you assert that gtlds are "global", which i suggest is an error on your part.

TLDs come in two flavors.

GTLD -- Global Top Level Domain -- A domain which contains records for entities not restricted to a particular geographical area.

CCTLD -- Country Code Top Level Domain -- A domain which is under the control of a particular national government represented by the corresponding 2-letter ISO country code.

The G in GTLD is Global... I'm not asserting anything, it's flat out in the term.

ok. we've reached the point where your subject matter expertise is obviously greater than mine. i've been working in icann policy and registry technology since ... well, since the nic contract was one floor below my office in sri's e-building. and you _know_ that "g" means "global". -e

I'd argue that all TLD registries should be reachable over IPv6 by now and all TLD should be reachable over IPv6 by now. It's not that hard nor is it any more expensive. It just requires will to turn it on. Requiring that new TLDs and the registry infrastucture be reachable over IPv6 from day one is perfectly reasonable. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

according to the vendors selling CGNAT solutions the impact to end users is (almost) unnoticeable.

And according to a used car salesman, this here pickup truck was only gently driven by a little old lady to the shop once a week. There's going to be a lot of snake oil in the next couple years as very small ISPs struggle to implement native IPv6 over those aging DSLAMs and GPON systems that don't and won't support it. Nathan

Scott Helms <khelms@ispalliance.net> writes:

IPv6 for some ISPs will be extraordinarily painful because of legacy layer 2 gear

I don't feel sorry for them. We know that IPv6 is coming for how long? 15years? 10year? 5years? Well if you only read the mainstream media you should have read something about this new Internet thing about two years ago. And still many people fear IPv6 or think the can still wait for another couple of years.

For ISPs in this circumstance the choice will be CGNAT rather than IPv6 for a number of years because the cost is much lower and according to the vendors selling CGNAT solutions the impact to end users is (almost) unnoticeable.

Cost's might be lower but service will be worse. NAT breaks a lot of applications file sharing will not work properly and running your own web server at home will not work properly. Well you always get what you pay for and people will buy any crap if it is cheap enough. Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink@guug.de | ------------------- | -------------------------------------------------------------------------

On Wed, 9 Feb 2011, Jens Link wrote:

Scott Helms <khelms@ispalliance.net> writes:

...

IPv6 for some ISPs will be extraordinarily painful because of legacy layer 2 gear

I don't feel sorry for them. We know that IPv6 is coming for how long? 15years? 10year? 5years? Well if you only read the mainstream media you

And at what point during that time did they have any vendor gear they could purchase that -would- support v6? At -best- during the last 5 years, but I'd put money on that even today they can't purchase gear with adequate v6 support. -- david raistrick http://www.netmeister.org/news/learn2quote.html drais@icantclick.org http://www.expita.com/nomime.html

On 02/09/2011 12:08 PM, Jack Bates wrote:

On 2/9/2011 2:00 PM, david raistrick wrote:

...

And at what point during that time did they have any vendor gear they could purchase that -would- support v6? At -best- during the last 5 years, but I'd put money on that even today they can't purchase gear with adequate v6 support.

Supply and demand. There was no demand (most of my vendors didn't get any requests/questions concerning IPv6 until roughly 6 months ago). J and C have had considerable support (though still a work in progress) for some time, though I'd agree that 5 years sounds about right (it takes 1 large core network to push C/J into implementing base IPv6, but it was originally around that customer's desires and not multipurpose).

Ultimately vendors only kneejerk when they're told to kneejerk. It's not like we didn't know about it 10 years ago too, but when the feature mill was prioritized... around the merry-go-round we go. So let's lay blame where everybody can agree: suits. Mike

On Feb 9, 2011, at 12:00 PM, david raistrick wrote:

On Wed, 9 Feb 2011, Jens Link wrote:

...

Scott Helms <khelms@ispalliance.net> writes:

...

IPv6 for some ISPs will be extraordinarily painful because of legacy layer 2 gear

I don't feel sorry for them. We know that IPv6 is coming for how long? 15years? 10year? 5years? Well if you only read the mainstream media you

And at what point during that time did they have any vendor gear they could purchase that -would- support v6? At -best- during the last 5 years, but I'd put money on that even today they can't purchase gear with adequate v6 support.

This is largely the result of the fact that they did not demand it from their vendors during that time. Owen

On 2/9/2011 14:55, Scott Helms wrote:

Absolutely, just as the ISPs didn't see demand, and don't today, from their users and thus the circle of blame is complete :)

And they never will. Their users demand "the internets", not a specific version of some protocol that users don't care about. ~Seth

On 2/9/2011 7:22 PM, Mark Andrews wrote:

And some of their customers have been asking for IPv6 all along.

I started asking my ISP at home in 2003. I suspect if all the ISPs here were honest they would say that they have had a trickle of IPv6 requests for the last 8 years.

Mark

Mark, I don't doubt that but request levels have to rise to a certain point. I still get a trickle of requests for UUCP service along with other very low volume features/products. Its the same thing as when you guys get a feature request for BIND or ISC DHCP that only a tiny fraction of your customers will use. Everyone has to prioritize and given that all of the tech folks who wanted to get an IPv6 connection could do so via tunneling there has been absolutely 0 pressure from residential customers and very very little from commercial customers. The federal government's requirement generated a few months of interest until everyone figured out they could satisfy their requirements by setting a tunnel with HE. -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms --------------------------------

ISPs know it takes years to move a customer base. They should have been ready years ago. They still arn't ready. I was asking for what features to look for in a new CPE so that it won't need to be replaced when they turn on IPv6 and got this as a answer. It really isn't helpful. Mark,

I certainly wasn't trying to be flip or short and for that I apologize. To answer the specific question on a CPE that depends both on what kind of access network you're connecting to as well as if its a service provider installed/supported device or one that a technical end user can support him/herself as those are very different use cases. The point I am trying to communicate is that CPE issue not simple, straightforward, or cheap because in almost all of the non-DOCSIS cases we're looking at forklift upgrades. -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms --------------------------------

On Fri, Feb 11, 2011 at 11:49 AM, Owen DeLong <owen@delong.com> wrote:

On Feb 11, 2011, at 6:38 AM, Scott Helms wrote:

...

...

ISPs know it takes years to move a customer base.  They should have been ready years ago.  They still arn't ready.  I was asking for what features to look for in a new CPE so that it won't need to be replaced when they turn on IPv6 and got this as a answer.  It really isn't helpful. Mark,

   I certainly wasn't trying to be flip or short and for that I apologize.  To answer the specific question on a CPE that depends both on what kind of access network you're connecting to as well as if its a service provider installed/supported device or one that a technical end user can support him/herself as those are very different use cases.

The point I am trying to communicate is that CPE issue not simple, straightforward, or cheap because in almost all of the non-DOCSIS cases we're looking at forklift upgrades.

Yes, but, let's look at why that is...

The Broadband Forum sat on its ass and ignored IPv6. They failed to publish IPv6 standards until November of last year.

This delayed the implementations in PON and DSL systems.

DOCSIS required forklift upgrades, too. The difference is that Cable Labs got out in front of the issue and IPv6 was one of many features that required an upgrade to DOCSIS 3.

It's not like Broadband Forum didn't have this option.

Sorry... I have little sympathy on that one.

3GPP was in front of it too, IPv6 was accounted for 10 years ago... but IPv6 3G will require new handsets for all (excluding Nokia, in some cases) due to the OEMs. For us in mobile, the issue right now is largely one of handset availability. Now that Nokia is married to Windows Phone 7, i am concerned they are taking a step backwards since Windows Phone 7 does not support cellular IPv6. Cameron ++++++++ http://groups.google.com/group/tmoipv6beta ++++++++

On Feb 9, 2011, at 3:16 PM, david raistrick wrote:

On Wed, 9 Feb 2011, Owen DeLong wrote:

...

...

...

I don't feel sorry for them. We know that IPv6 is coming for how long? 15years? 10year? 5years? Well if you only read the mainstream media you

And at what point during that time did they have any vendor gear they could purchase that -would- support v6? At -best- during the last 5 years, but I'd put money on that even today they can't purchase gear with adequate v6 support.

This is largely the result of the fact that they did not demand it from their vendors during that time.

I was purchasing for and building small SP networks during that time.

Requiring v6 of our vendors would have meant we just never got anything, so we'd have never provided service. Come to think if it, maybe it -would- have been better for everyone involved (except those of us who just got paychecks and experience out of it) to just simply not do it - but we didn't know that at the time 15 years ago!

Requiring it delivered day one, sure. Putting in a requirement for "Will support" so that they are required to provide an upgrade path, OTOH, to me seemed like it was basic good business sense. It worked out pretty well for the organizations I was working for back then. We got upgradeable hardware and the vendors got awareness of the demand. Admittedly, I wasn't working in the last mile arena. However, pressuring vendors is possible without sacrificing immediate needs.

Vendor C and J don't provide gear that fits into all network topologies (WISPs, MTU DSL, and smallish ADSL roll outs come to mind, certain during the time period in question. Sure, they eventually bought products in those markets...but even still, I had sub 6 figure budgets to build with - I certainly had no leverage).

I don't think that networks with sub-6-figure buildouts are the ones we're too worried about right now. They can probably upgrade for sub-6-figure amounts. Owen

On 02/09/2011 07:32 PM, Jack Bates wrote:

The small to middle guys are at the mercy of the large guys applying pressure to vendors.

I'm gonna just pick on this one thing. This just isn't true. I've always worked in small to middle sized shops, and I have always found that I've been able to yell and scream about IPv6 (and other features) loud enough, and long enough that I get heard by someone in a decision making position for product features (usually along the lines of a product manager or so). And every time I've made the effort to do that (admittedly, not a small effort), that product or line of product has had IPv6 available for it within about a year or so (if not sooner). Every single time. Were the big guys pushing as well? Perhaps, but I *know* that my voice gets heard when I put the effort into it. If you're not being heard by your vendor, you're not yelling loud enough. You're the customer, if your question/concern/request/demand about IPv6 gets blown off by your rep, talk to their boss, and keep demanding to talk to bosses until you get to someone that can give you a solid answer one way or the other, and if the answer is, "no, we won't support IPv6" run, don't walk, away from that vendor. It is absolutely doable, and I would argue that if you haven't reached this point in your purchasing decisions, you're being negligent. -- Jeff

On 02/09/2011 08:38 PM, George Bonser wrote:

...

If you're not being heard by your vendor, you're not yelling loud enough.

Or you aren't big enough of a customer. I was at one manufacturer within the past few months and asked about the lack of v6 support at layer 3 in one of their product lines as I had an application for that line but the lack of v6 layer 3 disqualified that solution. I was told that $HUGE_CUSTOMER had placed $HUGE_ORDER and was needing layer 2 features as their highest priority and so that is where they were focusing right now and that layer 3 ipv6 would be out later this year.

They did say that it was getting more difficult to sell the gear without the layer 3 features and that the "real soon now" excuse was having trouble getting any traction with potential customers but right now the largest dollar amount of business hinged on layer 2 features.

That's at least an honest and significant answer. At that point, its up to you whether you're willing to wait. At this point, I'm not willing to, but 2 years ago, I probably would have. My main point is that, if you're getting answers like, "We don't hear any customers asking about it." then you need to push harder. I found its very easy to ask about IPv6, get that answer, and then ask again in 6 months and still get the same answer. My response then would be, "<explitive>, I asked about it 6 months ago, you're just not paying attention, now get me a product manager on the phone so that I can bend their ear and make sure that I'm heard this time." -- Jeff

On Wed, Feb 9, 2011 at 5:49 PM, Jeff McAdams <jeffm@iglou.com> wrote:

My response then would be, "<explitive>, I asked about it 6 months ago,

...

you're just not paying attention, now get me a product manager on the phone so that I can bend their ear and make sure that I'm heard this time."

-- Jeff

What I can't believe is that not one single $VENDOR_OF_CHOICE has realized the potential windfall that is NANOG. They have a captive audience here of 1,000's of the most influential technical people here who would I'm sure encourage any Vendor who came forward and said "WE WILL" to the IPV6/IPV4 situation. The depth of technical knowledge available here that could be utilized to develop a standard home CPE Unit or variations for example is huge. Not to mention the opportunity to become the "BigBlue" of the 20Teens. I still remember when it was "safe" for any IT career to go "BigBlue" no matter what technical situation you were in (If only I'd listened back then and stayed away from this Linux/Unix stuff). :) Ah well, back to trying to get my IPV6 working inside a NATed IPV4 only ISP (They will at least give you a real IPV4 IP if you wish to do you'r own NATing, default now is NAT from them). Cheers Jeff

In message <alpine.BSF.2.00.1102091459200.15471@murf.icantclick.org>, david rai strick writes:

On Wed, 9 Feb 2011, Jens Link wrote:

...

Scott Helms <khelms@ispalliance.net> writes:

...

IPv6 for some ISPs will be extraordinarily painful because of legacy layer 2 gear

I don't feel sorry for them. We know that IPv6 is coming for how long? 15years? 10year? 5years? Well if you only read the mainstream media you

And at what point during that time did they have any vendor gear they could purchase that -would- support v6? At -best- during the last 5 years, but I'd put money on that even today they can't purchase gear with adequate v6 support.

And who's fault is that? The ISP's and the vendors. The ISP's could have been requesting IPv6 support. The ISP's could have been running trials and providing feedback to the vendors. The vendors could have asked the ISP's to trail their IPv6 products. We have been saying for years "make sure you are ready". That means buying and testing equipment. Lots of those that tested went on to production years ago. As a vendor we like feedback on our products, good or bad. It's hard to work in a vacuum. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

Jason Bertoch <jason@i6ix.com> writes:

I'm not sure about your part of the world, but the economy has been terrible in mine. Even in a good economy, DSL margins don't afford the ability to replace your network every two years.

Same thing here in Germany. DSL providers fighting for the lowest price and customers thinking that free service is still too expensive.

In fact, spending on new gear all but halted for us over the last 6 years. While everyone is still figuring out best practices for IPv6 rollout today, how difficult would it have been to plan and purchase the exact equipment that long ago?

Yeah. But they could have made plans and demanded working equipment from the vendors.

Was the right equipment even available for a production environment?

No, an in some case it is still not available today.

Not only that, but cheap CPE equipment that supports IPv6 still hardly exists today, and all of that will need replacing.

In Europe: Fritzbox from AVM. Almost all the big vendors have their own branded version of it. And the latter versions do support IPv6 quite well.

In addition, what about IP phones and the customer that just replaced their entire phone system? Are they going to want to do that all over again by the end of the year?

You don't have to replace everything at once. But you have to start somewhere.

No, IPv6 rollout is going to be extremely expensive and will likely put a number of smaller operations out of business.

I know several smaller ISPs which offer IPV6 for years. Sure the eyeball providers can hardly beat the cheap prices of the big players. But they do offer individual and good service. Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink@guug.de | ------------------- | -------------------------------------------------------------------------

Cost's might be lower but service will be worse. NAT breaks a lot of applications file sharing will not work properly and running your own web server at home will not work properly. Well you always get what you pay for and people will buy any crap if it is cheap enough.

Jens

While that is true, it is no worse than the situation right now. In the US, the vast majority of users are already behind a NAT (I would say over 90% of them are) so they are already experiencing this breakage.

"George Bonser" <gbonser@seven.com> writes:

While that is true, it is no worse than the situation right now. In the US, the vast majority of users are already behind a NAT (I would say over 90% of them are) so they are already experiencing this breakage.

I never thought it was that bad. In some 3G/wireless networks in Germany the providers use NAT and transparent HTTP-proxy. But this is only wireless. I'm not aware of any DSL or Cable provider NATing their customers. Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink@guug.de | ------------------- | -------------------------------------------------------------------------

On 2/9/2011 3:50 PM, George Bonser wrote:

Practically all broadband providers NAT their customers in the US. If you look at the largest ones which are probably Comcast, Verizon, and AT&T, you have the majority of US broadband subscribers right there.

Hmm, I am not aware of Comcast (or any other large MSO) doing any NAT on large scale. Having said that almost all of the DSL customers in the US are being NAT'ed, but on the edge device (DSL modem) rather than in the core. -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms --------------------------------

George, Comcast, like all(?) DOCSIS systems uses 10/8 or one of the other defined non-routable blocks for cable modems, which (if its a DOCSIS certified device) will be a bridge only and will not do NAT. If you we're NAT'ed on a cable modem system it must have been a proprietary system, of which there once was a ton before DOCSIS caught on, that Comcast hadn't phased out. I don't believe that any of the large MSO's (and none of the small ones I know) are doing NAT on edge devices or the core at this point, however your point is still valid since virtually all of the ADSL lines deployed are being NAT'ed at the modem level and that means that millions of people are being NAT'ed without a choice. That also means that a lot of people are already going through two NAT translations since they have plugged in a small router behind their DSL modem and both are NAT'ing their buggy little hearts out. We also have to think about the tremendous number of people on all kinds of networks that are voluntarily, like me, NAT'ing through one device of their own (usually not educated) choice.

How many instances of 10/8 did they say they were running? I was behind a NAT when I had Comcast service. I am behind a NAT currently with my AT&T service.

Note that the NAT was done on the "cable modem" in both cases and not further in to their network. That said, from my reading of some industry large scale NAT devices (the A10 AX series is one which I am familiar with), they do things such as full cone NAT so it will still work with many applications that might break with conventional overload dynamic NAT.

-- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms --------------------------------

I believe all the CM vendors make at least one cable modem that has an embedded router that does NAT (Motorola SBG901, 901, 940, 941; Arris WTM552, etc). Some MSOs may deploy more or less of those. Frank -----Original Message----- From: Scott Helms [mailto:khelms@ispalliance.net] Sent: Wednesday, February 09, 2011 3:28 PM To: George Bonser Cc: nanog@nanog.org Subject: Re: Looking for an IPv6 naysayer... George, Comcast, like all(?) DOCSIS systems uses 10/8 or one of the other defined non-routable blocks for cable modems, which (if its a DOCSIS certified device) will be a bridge only and will not do NAT. If you we're NAT'ed on a cable modem system it must have been a proprietary system, of which there once was a ton before DOCSIS caught on, that Comcast hadn't phased out. I don't believe that any of the large MSO's (and none of the small ones I know) are doing NAT on edge devices or the core at this point, however your point is still valid since virtually all of the ADSL lines deployed are being NAT'ed at the modem level and that means that millions of people are being NAT'ed without a choice. That also means that a lot of people are already going through two NAT translations since they have plugged in a small router behind their DSL modem and both are NAT'ing their buggy little hearts out. We also have to think about the tremendous number of people on all kinds of networks that are voluntarily, like me, NAT'ing through one device of their own (usually not educated) choice.

How many instances of 10/8 did they say they were running? I was behind a NAT when I had Comcast service. I am behind a NAT currently with my AT&T service.

Note that the NAT was done on the "cable modem" in both cases and not further in to their network. That said, from my reading of some industry large scale NAT devices (the A10 AX series is one which I am familiar with), they do things such as full cone NAT so it will still work with many applications that might break with conventional overload dynamic NAT.

-- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms --------------------------------

On 2/9/2011 4:36 PM, Ken A wrote:

10/8 is the management network on my cable modem. The cable modem bridges your wan 'real' ip(s) through to your PC or router. At least that's how Suddenlink does it here. The customer is normally 'locked out' of the cable modem, unlike a dsl modem. The largest NATs are presumably w/mobile carriers. I've never been behind NAT (except one I controlled) on a consumer dsl or cable link in the US. Ken

Agreed on the cable side (DOCSIS at least) but most of the DSL systems I've seen are doing NAT on virtually all of the end user gear. Bell South, SBC, Verizon, and Pac Bell are all doing or in the recent past did most/all of their DSL installs this way. Bell South tried using a brouter (only one I've seen in the wild) that did PPPoE on the WAN side and then handed out the same address it was assigned via DHCP on the LAN interface, but it was problematic (imagine that) and they stopped using it some years before the AT&T purchase/merger. The smaller telcos are almost universally doing NAT as well providers like Alltel, Centurytel, Frontier, Finepoint, as well as the smaller ILEC's simply don't do bridging on their CPE gear since they seldom had their DSLAMs set up to deal with Q-in-Q or isolation methods. That's not to say I don't know some that are the exception since I do know of a few telcos that run PPPoE clients on the client PC and a handful that did get port isolation working but they are not the norm in the US. -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms --------------------------------

On 2/9/2011 3:50 PM, Scott Helms wrote:

On 2/9/2011 4:36 PM, Ken A wrote:

...

10/8 is the management network on my cable modem. The cable modem bridges your wan 'real' ip(s) through to your PC or router. At least that's how Suddenlink does it here. The customer is normally 'locked out' of the cable modem, unlike a dsl modem. The largest NATs are presumably w/mobile carriers. I've never been behind NAT (except one I controlled) on a consumer dsl or cable link in the US. Ken

Agreed on the cable side (DOCSIS at least) but most of the DSL systems I've seen are doing NAT on virtually all of the end user gear.

End user gear = gear I control.. so I can 'make it work', poke holes where needed, no worries, 64k ports, etc. I thought we were talking about CGNAT taking over the world due to v4 scarcity. Ken Bell

South, SBC, Verizon, and Pac Bell are all doing or in the recent past did most/all of their DSL installs this way. Bell South tried using a brouter (only one I've seen in the wild) that did PPPoE on the WAN side and then handed out the same address it was assigned via DHCP on the LAN interface, but it was problematic (imagine that) and they stopped using it some years before the AT&T purchase/merger.

The smaller telcos are almost universally doing NAT as well providers like Alltel, Centurytel, Frontier, Finepoint, as well as the smaller ILEC's simply don't do bridging on their CPE gear since they seldom had their DSLAMs set up to deal with Q-in-Q or isolation methods. That's not to say I don't know some that are the exception since I do know of a few telcos that run PPPoE clients on the client PC and a handful that did get port isolation working but they are not the norm in the US.

-- Ken Anderson Pacific Internet - http://www.pacific.net

You mean they provide CPE which does NAT? Or the CPE actually has a RFC1918 address on the WAN?

Correct, the CPE does NAT. But regardless, the user's platform (and hence all the applications running on it) are going through a dynamic NAT.

Are you sure about that - I'm a comcast subscriber and see no signs that I am being natted?

Josh, maybe it is different in different markets. When I had Comcast, I was behind a NAT.

On Feb 9, 2011, at 12:50 PM, George Bonser wrote:

...

I never thought it was that bad. In some 3G/wireless networks in Germany the providers use NAT and transparent HTTP-proxy. But this is only wireless. I'm not aware of any DSL or Cable provider NATing their customers.

Jens

Practically all broadband providers NAT their customers in the US. If you look at the largest ones which are probably Comcast, Verizon, and AT&T, you have the majority of US broadband subscribers right there.

No. Almost none of the broadband providers in the US NAT their customers. Most of them provide a single public IP address to their residential customers. Most broadband customers use their own NAT to extend that single public IP address from the provider to multiple addresses within the site. This is a very very different thing from LSN with a lot less breakage. Owen

...

Almost none of the broadband providers in the US NAT their

customers.

Well, I suppose I have been unlucky then because every single one I have had has NATed me. I had a "real" IP when I had dialup, but I got NAT when I went broadband. I have a friend that has another service and she is NATed too. Boot up in her network and you get 192.168.1.x

In other words, the broadband provider provides a single global IP to the "always up" CPE. That CPE does DHCP to user stations and hands out 1918 addresses and NATs them to the single global IP. I have had 3 broadband providers over the past 10 years, all three have done that. I have a friend on a fourth provider that also does that. I have yet to see a broadband provider that configures a network so that individual nodes in the home network get global IPs.

On 2/9/2011 4:00 PM, Jack Bates wrote:

On 2/9/2011 5:47 PM, George Bonser wrote:

...

I have yet to see a broadband provider that configures a network so that individual nodes in the home network get global IPs. Bridge only CPE's given off this node.

1043 IP addresses handed out 1024 Unique interfaces

Looks like customers aren't always big on more than 1 IP. :)

Jack

And meanwhile Comcast has announced one /64-per-household service for IPv6... guess they didn't get the memo from Owen about how every class of home appliances will need its own subnet. Matthew Kaufman

On Feb 9, 2011, at 4:27 PM, Matthew Kaufman wrote:

On 2/9/2011 4:00 PM, Jack Bates wrote:

...

On 2/9/2011 5:47 PM, George Bonser wrote:

...

I have yet to see a broadband provider that configures a network so that individual nodes in the home network get global IPs. Bridge only CPE's given off this node.

1043 IP addresses handed out 1024 Unique interfaces

Looks like customers aren't always big on more than 1 IP. :)

Jack

And meanwhile Comcast has announced one /64-per-household service for IPv6... guess they didn't get the memo from Owen about how every class of home appliances will need its own subnet.

Matthew Kaufman

Actually Comcast is willing to give out more than a /64 to a home, they're waiting for the CPE to catch up. I've had some very good discussions with John Brzozowski on the subject. While we don't see completely eye-to-eye on the matter, I think that Comcast is trying to do reasonably well by their customers in the IPv6 addressing realm. I expect that they will eventually come around to giving out /48s, but, for now they seem to feel they need to see the use case develop before they deploy it. It's not ideal in my opinion, but, it's much better than it could be. FWIW, Comcast is transporting the /48 from my home nicely, even if they don't know they're doing it. Owen

On 02/09/2011 07:27 PM, Matthew Kaufman wrote:

...

And meanwhile Comcast has announced one /64-per-household service for IPv6... guess they didn't get the memo from Owen about how every class of home appliances will need its own subnet.

Huh? I don't think Comcast has stated what their plans on household allocation is. I merely noted (in response to a bogus claim that they'd be allocating *less* than a /64, that the current allocation in their 6rd trial, as observed by me, is a /64. - Jim

On Wed, Feb 9, 2011 at 6:47 PM, George Bonser <gbonser@seven.com> wrote:

I have yet to see a broadband provider that configures a network so that individual nodes in the home network get global IPs.

One huge reason to adopt ipv6. --                       Fred

On 2/10/2011 3:19 PM, George Herbert wrote:

On Wed, Feb 9, 2011 at 6:11 PM, Fred Richards<fredr@geexology.org> wrote:

...

On Wed, Feb 9, 2011 at 6:47 PM, George Bonser<gbonser@seven.com> wrote:

...

I have yet to see a broadband provider that configures a network so that individual nodes in the home network get global IPs.

One huge reason to adopt ipv6.

Maybe Roku will add the "ipv6 tunnel endpoint channel" next? Seems like an opportunity? Ken

Any of the ones I've used at home do provide global IPv4s to the home networks.

I'm kinda selective, though.

-- Ken Anderson Pacific Internet - http://www.pacific.net

On Wed, 09 Feb 2011 18:47:34 -0500, George Bonser <gbonser@seven.com> wrote:

In other words, the broadband provider provides a single global IP to the "always up" CPE. That CPE does DHCP to user stations and hands out 1918 addresses and NATs them to the single global IP.

Correct. The distinction you seem unware of (or unwilling to accept) is that the ISP did not assign you a private address. Your CPE did. The ISP gave you a single public IPv4 address. With the notable exception of Uverse, you can put that address on any device you want. But you only have the one public address, so you'll have to resort to NAT inside your network to support more than one machine. (DSL and cable modems can be set to pure bridged mode, thus turning off their routing/NAT engine. You cannot do that with Uverse due to their authentication method.) This is *very* different from the ISP doing the NAT... one device doing NAT for thousands of customers, vs. a device in the customer's hands doing the NAT.

I have yet to see a broadband provider that configures a network so that individual nodes in the home network get global IPs.

Open your eyes. Many cable networks will sell you access to more than one address -- TW (RR) has done this for over a decade. AT&T Uverse will provide a /29 for free. --Ricky

"George Bonser" <gbonser@seven.com> writes:

In other words, the broadband provider provides a single global IP to the "always up" CPE. That CPE does DHCP to user stations and hands out 1918 addresses and NATs them to the single global IP.

Ah there is the misunderstanding. Same her in good old Europe. If you pay for it you'll get more than one public IP. I though you were talking about the CPE getting an RFC1918 address and than hand out RFC1918 addresses to the inside as well and (maybe) another instance of NAT along the way. Well yes, there are providers which are already doing this. Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink@guug.de | ------------------- | -------------------------------------------------------------------------

George Bonser wrote:

I have yet to see a broadband provider that configures a network so that individual nodes in the home network get global IPs.

When I switched to ADSL I'm pretty sure I was offered the choice of a single public IP address on the outside of my router, or a /29 public range for my home network (and presumably also a public address for the external interface of my router). I chose the former and don't regret having done so. I can do a mixture of static and dynamic NAT to allow things from the outside into particular internal hosts if I want do. This was in 2005, and I can very well believe this choice was not available some time later.

On Sat, 12 Feb 2011 09:02:32 GMT, Adam Atkinson said:

When I switched to ADSL I'm pretty sure I was offered the choice of a single public IP address on the outside of my router, or a /29 public range for my home network (and presumably also a public address for the external interface of my router). I chose the former and don't regret having done so. I can do a mixture of static and dynamic NAT to allow things from the outside into particular internal hosts if I want do.

This was in 2005, and I can very well believe this choice was not available some time later.

It's more a business question. If you're an ADSL provider, you probably want to save "multiple public IP" as a feature so you can upsell customers to "business class". There's little business case for doing it by default for Joe Sixpack (especially in a world where public IP's are getting scarce). Fortunately, in IPv6 the bit boundaries have moved, so there's no scarcity issue and "give everybody a /48 (or at least a /56)" is a no-brainer.

On Feb 9, 2011, at 6:21 PM, Owen DeLong wrote:

On Feb 9, 2011, at 12:50 PM, George Bonser wrote:

...

...

I never thought it was that bad. In some 3G/wireless networks in Germany the providers use NAT and transparent HTTP-proxy. But this is only wireless. I'm not aware of any DSL or Cable provider NATing their customers.

Jens

Practically all broadband providers NAT their customers in the US. If you look at the largest ones which are probably Comcast, Verizon, and AT&T, you have the majority of US broadband subscribers right there.

No.

Almost none of the broadband providers in the US NAT their customers.

Most of them provide a single public IP address to their residential customers.

Most broadband customers use their own NAT to extend that single public IP address from the provider to multiple addresses within the site.

This is a very very different thing from LSN with a lot less breakage.

Owen This maybe true of all the big boys but I can tell you that rural telcos providing internet connectivity (personal experience in Northern MN) do and heavily. They may run fiber to the house but they do LSN big time. Tom

In message <5A6D953473350C4B9995546AFE9939EE0BC1397D@RWC-EX1.corp.seven.com>, " George Bonser" writes:

...

Cost's might be lower but service will be worse. NAT breaks a lot of applications file sharing will not work properly and running your own web server at home will not work properly. Well you always get what you pay for and people will buy any crap if it is cheap enough. =20 Jens

While that is true, it is no worse than the situation right now. In the US, the vast majority of users are already behind a NAT (I would say over 90% of them are) so they are already experiencing this breakage. =20

But for the most part they can work around breakages with a single NAT. Double NAT prevents most of the work arounds working. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

Daniel Roesen <dr@cluenet.de> writes:

And quite important for residential ISPs of some size: have fun teaching your call centers diagnosing double-NAT failure modes.

NAT444 is a hell I don't want to visit really.

No it's great! It's secure! It's easy to implement! It's the only way to do it right! Till the end of the month I'm working for a rather large enterprise customer and they use NAT, NAT NAT, NAT NAT NAT, and even even NAT NAT NAT NAT connections for their VPN. They claim that it's easy. I think it isn't and I relay need to get drunk after troubleshooting such a problem. So I must be stupid, because NAT is so *easy*. On the other hand, when you tell them about IPv6 they say it's to complicated and that they don't need it. Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink@guug.de | ------------------- | -------------------------------------------------------------------------

On Wed, 9 Feb 2011, Scott Helms wrote:

For ISPs in this circumstance the choice will be CGNAT rather than IPv6 for a number of years because the cost is much lower and according to the vendors selling CGNAT solutions the impact to end users is (almost) unnoticeable.

Anyone care to define CGNAT? Google results for this are either unrelated or "CGNAT will save us" or "CGNAT doesnt count" - no rfcs, no explainations, nothing.... -- david raistrick http://www.netmeister.org/news/learn2quote.html drais@icantclick.org http://www.expita.com/nomime.html

Try looking for the expanded terms: Large Scale NAT Carrier Grade NAT NAT444 Owen On Feb 9, 2011, at 11:58 AM, david raistrick wrote:

On Wed, 9 Feb 2011, Scott Helms wrote:

...

For ISPs in this circumstance the choice will be CGNAT rather than IPv6 for a number of years because the cost is much lower and according to the vendors selling CGNAT solutions the impact to end users is (almost) unnoticeable.

Anyone care to define CGNAT? Google results for this are either unrelated or "CGNAT will save us" or "CGNAT doesnt count" - no rfcs, no explainations, nothing....

-- david raistrick http://www.netmeister.org/news/learn2quote.html drais@icantclick.org http://www.expita.com/nomime.html

On 2/9/2011 2:17 PM, Iljitsch van Beijnum wrote:

But just CGNAT with no IPv6 is going to be very bad. Maybe 95% of your users won't notice, but do you really want the other 5% to tie up your support lines?

Yes, as that will cause them to produce an IPv6 product for those customers (even if it's a specialized CPE they ship to those 5% that does a tunnel back to an ISP server which connects to native IPv6). You must have demand and pressure to push companies to spend money. Helpdesk calls count. Let the phones ring. The suits will listen then. Jack

On 2/9/2011 5:56 PM, Robert E. Seastrom wrote:

Or 6rd and go native on their permanent prefix as the forklift upgrade schedule allows. Oh well, it's better than nothing or Crummier Grade NAT.

ds-lite tends to be friendlier LSN from various tests, and is native v6. Jack

Mark Andrews <marka@isc.org> writes:

DS-Lite over 6rd using RFC 1918 / multi-use ISP assigned block (I'd love to be able to say class E here) provides a single NAT translation for IPv4 and public IPv6.

Okay, it's 10:15 in the morning and I really want a drink know. ;-) Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink@guug.de | ------------------- | -------------------------------------------------------------------------

On Feb 9, 2011, at 6:01 PM, Jack Bates wrote:

On 2/9/2011 5:56 PM, Robert E. Seastrom wrote:

...

Or 6rd and go native on their permanent prefix as the forklift upgrade schedule allows. Oh well, it's better than nothing or Crummier Grade NAT.

ds-lite tends to be friendlier LSN from various tests, and is native v6.

DS-lite is still CGN. You may be thinking of the comparison versus NAT444 described in draft-donley-nat444-impacts (https://datatracker.ietf.org/doc/draft-donley-nat444-impacts/). But you should read the criticisms of that draft on the BEHAVE mailing list, http://www.ietf.org/mail-archive/web/behave/current/msg09027.html and http://www.ietf.org/mail-archive/web/behave/current/msg09030.html. Cheers, -Benson

On Feb 10, 2011, at 9:53 AM, Jack Bates wrote:

On 2/10/2011 8:36 AM, Benson Schliesser wrote:

...

DS-lite is still CGN.

It is still LSN, but it is not NAT444, and the failure rate reduces because of that. Also, DS-Lite guarantees that you have IPv6 connectivity. NAT444 makes no such assertion.

DS-lite *uses* IPv6 connectivity, it doesn't provide it. That's like saying 6rd or 6to4 "guarantees you have IPv4 connectivity". As for NAT444 (or double-NAT): One could just as easily deploy DS-lite with a NAT444 configuration. Or deploy CGN without NAT444 (e.g. CGN44, by managing subnets delegated to each subscriber). The two topics are related but separate. In terms of CGN44 versus NAT444, I'd like to see evidence of something that breaks in NAT444 but not CGN44. People seem to have a gut expectation that this is the case, and I'm open to the possibility. But testing aimed at demonstrating that breakage hasn't been very scientific, as discussed in the URLs I posted with my previous message. Cheers, -Benson

On Feb 10, 2011, at 8:05 AM, Benson Schliesser wrote:

On Feb 10, 2011, at 9:53 AM, Jack Bates wrote:

...

On 2/10/2011 8:36 AM, Benson Schliesser wrote:

...

DS-lite is still CGN.

It is still LSN, but it is not NAT444, and the failure rate reduces because of that. Also, DS-Lite guarantees that you have IPv6 connectivity. NAT444 makes no such assertion.

DS-lite *uses* IPv6 connectivity, it doesn't provide it. That's like saying 6rd or 6to4 "guarantees you have IPv4 connectivity".

As for NAT444 (or double-NAT): One could just as easily deploy DS-lite with a NAT444 configuration. Or deploy CGN without NAT444 (e.g. CGN44, by managing subnets delegated to each subscriber). The two topics are related but separate.

I think that at the point where you go to NAT444 instead of tunneling the IPv4, it's Dual-Stack, but, not Dual-Stack-Lite.

In terms of CGN44 versus NAT444, I'd like to see evidence of something that breaks in NAT444 but not CGN44. People seem to have a gut expectation that this is the case, and I'm open to the possibility. But testing aimed at demonstrating that breakage hasn't been very scientific, as discussed in the URLs I posted with my previous message.

Technologies which depend on a rendezvous host that can know about both sides of both NATs in a private->public->private scenario will break in a private->private2->public->private2->private scenario. There are technologies and applications which depend on this. (I believe, among others, that's how many of the p2p systems work, no?) Owen

On Thu, Feb 10, 2011 at 14:17, Benson Schliesser <bensons@queuefull.net> wrote:

If you have more experience (not including rumors) that suggests otherwise, I'd very much like to hear about it.  I'm open to the possibility that NAT444 breaks stuff - that feels right in my gut - but I haven't found any valid evidence of this.

In case you have not already found this: http://tools.ietf.org/html/draft-donley-nat444-impacts-01 Cheers, ~Chris

Regardless, I think we can agree that IPv6 is the way to avoid NAT-related growing pains.  We've known this for a long time.

Cheers, -Benson

_______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info@arin.net if you experience any issues.

-- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org

On Feb 21, 2011, at 12:37 PM, Dan Wing wrote:

...

-----Original Message----- From: arin-ppml-bounces@arin.net [mailto:arin-ppml-bounces@arin.net] On Behalf Of Chris Grundemann Sent: Thursday, February 17, 2011 5:55 PM To: Benson Schliesser Cc: NANOG list; ARIN-PPML List Subject: Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)

On Thu, Feb 10, 2011 at 14:17, Benson Schliesser <bensons@queuefull.net> wrote:

...

If you have more experience (not including rumors) that suggests otherwise, I'd very much like to hear about it. I'm open to the possibility that NAT444 breaks stuff - that feels right in my gut - but I haven't found any valid evidence of this.

In case you have not already found this: http://tools.ietf.org/html/draft-donley-nat444-impacts-01

That document conflates problems of NAT444 with problems of NAT44 with problems of bandwidth starvation with problems of CGN.

For details, see my comments at http://www.ietf.org/mail-archive/web/behave/current/msg09027.html and see Reinaldo Penno's comments at http://www.ietf.org/mail-archive/web/behave/current/msg09030.html

-d

The document describes problems that will exist in NAT444 environments. It does not state that these problems would be specific to NAT444, but, NAT444 will cause or exacerbate each of the problems described. Yes, the problems may have other underlying root causes, but, they will all be present in a NAT444 environment, even if they were not present in the same environment prior to deployment of NAT444. Let me put it this way... IPv4 has a TITANIC lack of numeric addresses and has been stretched beyond its limits for some time now. IPv6 is a life boat. NAT is a seat cushion used for floatation. NAT444 (and other NAT-based extensions) are deck chairs. Attempting to improve them beyond their current states is an effort to rearrange the deck chairs. Owen

On Mon, Feb 21, 2011 at 19:08, Dan Wing <dwing@cisco.com> wrote:

Its title, filename, abstract, and introduction all say the problems are specific to NAT444.  Which is untrue.

I just re-read the filename, abstract and introduction, and I disagree that any of those say that the problems are specific to NAT444. They all do state that these problems are present in NAT444, but not that it's the only technology/scenario/configuration where you might find them. More importantly, I am unsure the point of this argument. Are you trying to say that the items listed as broken in the draft are not actually broken? Because in my experience they are. IMHO, the fact that they are also broken in other (similar) scenarios is not evidence that they are not broken in this one. On the contrary, this scenario seems to be evidence to the brokenness in the others (until we get a chance to test and document them all - are you volunteering? ;). Cheers, ~Chris

-d

-- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org

[ arin cesspool removed from cc: as i can not post there anyway ]

There seems to be a position, taken by others on these lists, that IPv6 is the only address family that matters. Interestingly, this position seems to be most pronounced from people not involved in operating production networks.

excuse me! randy

Benson Schliesser wrote:

On Feb 22, 2011, at 3:14 AM, Randy Bush wrote:

...

...

There seems to be a position, taken by others on these lists, that IPv6 is the only address family that matters. Interestingly, this position seems to be most pronounced from people not involved in operating production networks.

excuse me!

Hi, Randy. I didn't mean to deny you exist; you apparently do. ;) But in my sampling, operators with the opinion that 'IPv4 doesn't matter' represent the minority. Of course, it also depends on how you define "doesn't matter". I think that ongoing operation matters, especially when "ongoing" means a continued expectation of both existing and new customers. It's easy to say, "burn the IPv4 bridge" so we're forced to migrate to IPv6. But it's another thing to actually do it, when you're competing for customers that want IPv4 connectivity.

That said, we're not forced to choose only one: IPv4 vs. IPv6. We should migrate to IPv6 because it makes sense - IPv4 is going to become more expensive and painful (to use and support). That doesn't preclude us from patching IPv4 together long enough to cross the bridge first.

Thoughts?

The patching started in 1994 with RFC 1627.... how much time is needed??? Seriously, some people will not move until the path they are on is already burning, which is why they did nothing over the last 5 years despite knowing that the IANA pool was exhausting much faster than they had wanted to believe. It took getting within months of exhausting the IANA pool before the crowd woke up and noticed the path was on fire. Now you want 'just a little more'... after which it will be 'just a little more'. Fortunately Randy and a few others took action and demonstrated that 'this is not hard', it just takes some effort. Pouring more effort into hack upon hack is not making progress, it is stalling for the sake of stalling. Consumers don't want IPv4, they want connectivity to their favorite content. Hacks in the network to make that content appear to be available will be expensive to maintain, and irrelevant as soon as the content has realized the mess that has been made between them and their customers. More energy into moving content and apps will result in less energy wasted in deploying short lived hacks. Tony

Cheers, -Benson

On Feb 22, 2011, at 1:36 PM, Benson Schliesser wrote:

On Feb 22, 2011, at 3:14 AM, Randy Bush wrote:

...

...

There seems to be a position, taken by others on these lists, that IPv6 is the only address family that matters. Interestingly, this position seems to be most pronounced from people not involved in operating production networks.

excuse me!

Hi, Randy. I didn't mean to deny you exist; you apparently do. ;) But in my sampling, operators with the opinion that 'IPv4 doesn't matter' represent the minority. Of course, it also depends on how you define "doesn't matter". I think that ongoing operation matters, especially when "ongoing" means a continued expectation of both existing and new customers. It's easy to say, "burn the IPv4 bridge" so we're forced to migrate to IPv6. But it's another thing to actually do it, when you're competing for customers that want IPv4 connectivity.

We may be the minority, but, we have a lot more address space and no shortage of IP addresses. How many IPv4 providers can say that?

That said, we're not forced to choose only one: IPv4 vs. IPv6. We should migrate to IPv6 because it makes sense - IPv4 is going to become more expensive and painful (to use and support). That doesn't preclude us from patching IPv4 together long enough to cross the bridge first.

Thoughts?

Patching the deck chairs does not change the fact that the boat is sinking. I suggest focusing on getting in a life boat. Deck chairs don't float very well. IPv6 is a life boat. NAT444 and other IPv4 preservation hacks are deck chairs. You can rearrange them all you want. Owen

On Feb 22, 2011, at 6:29 PM, Randy Bush wrote:

...

...

...

There seems to be a position, taken by others on these lists, that IPv6 is the only address family that matters. Interestingly, this position seems to be most pronounced from people not involved in operating production networks.

excuse me!

Hi, Randy. I didn't mean to deny you exist; you apparently do. ;) But in my sampling, operators

benson,

vendors saying what operators want went *seriously* out of fashion a couple of years back. we can speak for ourselves, tyvm.

I agree completely. I'm responding to what I've heard from operators. Cheers, -Benson

On Feb 22, 2011, at 3:40 AM, Owen DeLong wrote:

...

There seems to be a position, taken by others on these lists, that IPv6 is the only address family that matters. Interestingly, this position seems to be most pronounced from people not involved in operating production networks. But, regardless, if I were to accept this position then I might also agree that it doesn't matter whether or not draft-donley-nat444-impacts is misleading.

I don't think anyone has said that IPv6 is the only address family that matters. What I think people, myself included, have been saying is that IPv6 is the only way forward that does not involve many of these problems. (See my earlier Titanic post).

I agree completely: IPv6 is the only way forward that avoids these problems. In fact, an understanding of CGN impacts should be enough motivation for operators and users to start deploying IPv6 immediately.

As to whether or not it matters that people misinterpred draft-donly..., I'm not sure whether it actually does or not. There is no flavor of NAT that is particularly desirable. It's a matter of choosing the one that is least damaging to your environment where least damage may boil down to a choice between 5% and 3% remaining functionality.

I agree with your sentiment, that we should choose the least damaging solutions. Call it the "lesser evil" if you'd like. However, I think your estimates (5% vs 3%) are backwards. CGN-based solutions work for the vast majority of network traffic today - it's the stuff in the margin that breaks, according to all test reports I've seen.

I don't think anyone is saying IPv4 no longer matters. I think we are saying that effort spent attempting to make the deteriorating IPv4 situation deteriorate less is both futile and better spent on making the IPv6 deployment situation better.

It's not an exclusive situation - we can roll out IPv6 while continuing to maintain our existing IPv4 connectivity, support new customers with IPv4 needs, etc. As I mentioned before, we have to support the bridge we're crossing (crumbling IPv4 infrastructure) until we're on the other side (fertile IPv6 farmland).

...

Of course, we can also rely on an IPv4 address market to avoid NAT in the more sensitive situations (i.e. situations with more sensitive users). But that's a different conversation.

Only if you expect that you can rely on a supply side in such a market. I am unconvinced that such will be reliable, especially after about 6 months of trading. This also presumes that more sensitive users can be defined in terms of what those users are willing (or able) to pay.

This is an interesting discussion, because the timeframe is central to everything I've commented above. Considering RIR exhaustion (4-12 months) plus ISP exhaustion (TBD, but let's say anywhere from 1 month to 5+ years after RIR exhaustion), I expect some network providers to struggle with IPv4 address exhaustion before the 3rd quarter of 2011. On the other hand, other network providers will have enough resources to last for years - let's call that "excess supply". By all realistic estimates, any network provider that hasn't deployed IPv6 support into their infrastructure will need anywhere from 3 months to 3 years or more - let's generously say around 18 months to the point where 60% - 80% of hosts have reached IPv6 connectivity. Just considering these facts, I think we can see why some ISPs might be interested in acquiring more addresses through 2012. And those with excess supply might be motivated (financially) by a marketplace to share their resources, to meet this need. Further, let's consider that some network services (such as content / hosting) will need IPv4 connectivity longer than others, in order to reach the long-tail. For this category, I can see why some networks might be interested in acquiring more addresses through 2013 - 2016. Fortunately, on the other side of 2012 prices should decrease because supply goes up (as some people give up IPv4). Thus the market value of an address probably can be represented by a curve peaking in a couple years and then declining to zero a few years after that. Feedback on this would be appreciated - but my current belief is that it's realistic to plan for a couple years of trading rather than "about 6 months". (Side note: If we really wanted people to move to IPv6 before now, we should have instituted increasing prices for RIR-provided addresses. I posit that we just didn't have the collective balls to do this.) Cheers, -Benson

On Feb 22, 2011, at 3:54 PM, Valdis.Kletnieks@vt.edu wrote:

On Tue, 22 Feb 2011 02:29:23 CST, Benson Schliesser said:

...

There seems to be a position, taken by others on these lists, that IPv6 is the only address family that matters. Interestingly, this position seems to be most pronounced from people not involved in operating production networks.

"most pronounced from people not involved in operating production networks that are way behind the planning curve for IPv6 deployment".

There, fixed that for you.

My original text remains true, because I tend to hear IPv6-only advocacy from vendors and policy folks more than operators - even more so versus operators of commercial ISP networks. But I take your point, that operators ahead of the IPv6 deployment curve are most likely to stand up with that opinion. Of course, the "network effect" being what it is... Your network being 100% IPv6 doesn't solve the overall problem of reachability. I think your example of 4% traffic from VT is applicable - you will have to worry about IPv4 connectivity, in one form or another, until it diminishes significantly. It's a bit like a tragedy of the commons. Cheers, -Benson

...

http://tools.ietf.org/html/draft-donley-nat444-impacts-01 That document conflates problems of NAT444 with problems of NAT44 with problems of bandwidth starvation with problems of CGN.

it may require a delicate palate to differentiate the different flavors of <bleep> randy

On Wed, Feb 09, 2011 at 06:01:46PM -0600, Jack Bates wrote:

ds-lite tends to be friendlier LSN from various tests,

Any pointers to study reports etc. heartly welcome. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

On 9 feb 2011, at 20:53, William Herrin wrote:

* Carrier NAT buys us enough years to build an IPv4 successor

You're kidding, right? How long did it take exactly to get where we are now with IPv6? 18, 19 years? And yet there's still all kinds of stuff that isn't really ready for prime time yet.

* Next protocol should really be designed to support interoperability with the old one from the bottom up. IPv6 does not

That's because it's not the headers that aren't incompatible (the protocol translation is ok even though it could have been a bit better) but the addresses. A system that knows about 32-bit addresses will just not talk to a system with a 128-bit address. Once we're at 128-bit addresses then we can migrate to IPvA (7 - 9 are already taken) without much trouble. But then, 32-bit ASes interoperate with 16-bit ones with no trouble and still after a decade the support for that is not nearly good enough, either.

On 9 feb 2011, at 21:17, George Herbert wrote:

...

Once we're at 128-bit addresses then we can migrate to IPvA (7 - 9 are already taken) without much trouble.

I know about IPv8 (sigh), and the Chinese abortive IPv9 claim, but when did 7 happen?

RFC 1475, apparently: http://www.iana.org/assignments/version-numbers/version-numbers.xhtml

On 9 feb 2011, at 21:26, William Herrin wrote:

...

You're kidding, right? How long did it take exactly to get where we are now with IPv6? 18, 19 years?

Tech like carrier NAT theoretically yeilds address reclamation in excess of 80%.

Most IPv4 space is unused anyway, but it's not being reclaimed much despite that. (How many IP addresses does the US federal government need? Few people would think ~ 10 /8s. Especially since many of them aren't even lit up.)

...

...

* Next protocol should really be designed to support interoperability with the old one from the bottom up. IPv6 does not

...

That's because it's not the headers that aren't incompatible (the protocol translation is ok even though it could have been a bit better) but the addresses.

No, it's because decisions were made to try to abandon the old DFZ table along with IPv4 and institute /64 as a standard subnet mask. But for those choices, you could directly translate the IPv4 and IPv6 headers back and forth, at least until one of the addresses topped 32 bits. The transition to IPv6 could be little different than the transition to 32-bit AS numbers -- a nuisance, not a crisis. You recompile your software with the new IN_ADDR size and add IP header translation to the routers, but there's no configuration change, no new commands to learn, etc.

It's not that simple. But I agree on one thing: it could have been better. What needs to be done to move from IPv4 to IPv6 is three things: 1. the headers 2. the addresses 3. the applications Today, only IPv6 applications can use IPv6 addresses and only when IPv6 applications use IPv6 addresses will there be IPv6 headers. It would have been better to roll out the headers first. That would have meant changes to routers, because routers touch the headers. But if translating between IPv6 with 32-bit addresses and IPv4 can be done with low overhead (which is more or less the case today, BTW) then it would have been possible to upgrade from IPv4 to IPv6 subnet by subnet. This way, there wouldn't have had to be any dual stack, and once people had deployed IPv6 they would have kept using it. Today, and especially some years ago, IPv6 would/will often atrophy after having been deployed initially because of lack of use. Apps could have been upgraded the same way they have now, with the only difference that using an IPv4-mapped IPv6 address meant generating an IPv6 packet, not an IPv4 packet as is done today. Once 128-bit addresses are being used going from an IPv6 subnet to an IPv4 subnet becomes problematic, but this can be solved with stateful translation so most stuff keeps working anyway. And remember, servers and apps that can't work through a stateful translator can still get 32-bit addresses so everything keeps working without trouble. However, it's easy to come up with all of this in 2011. In 1993 the world was very different, and many things we take for granted today were still open questions then. It's very illuminating to read up on the mailinglist discussions from back then. People complained about IPv6 a decade or half a decade ago, too. Back then there may have been a chance to come up with a different protocol as a successor for IPv4, but it's way too late for that now. Anyway, most non-legacy applications support 128-bit addresses now and we have a pretty decent NAT64 spec sitting in the RFC editor queue (even if I do say so myself) so it's just a matter of sitting tight until we're through the painful part of the transition.

On 2/9/11 1:42 PM, Nathan Eisenberg wrote:

...

Most IPv4 space is unused anyway, but it's not being reclaimed much despite that. (How many IP addresses does the US federal government need? Few people would think ~ 10 /8s. Especially since many of them aren't even lit up.)

What do you mean, lit up? You mean they're not in the routing tables that you get from your carriers? I'd argue that's no indication of whether they're in use or not.

Especially given that they're know to be in use. e.g. it's not a secret, they just don't appear in your internet.

In my recent probe of route servers, I found 22 legacy /8's that were partly or completely unused. I'm a little surprised ARIN/ICANN thinks it's a waste of time to even try to reclaim them.

How long would that be tied up in legal issues before they were freed?

On 10/02/2011, at 4:39 PM, Mark Andrews wrote:

In message <alpine.BSF.2.00.1102092156050.16359@goat.gigo.com>, Jason Fesler wri tes:

...

...

In my recent probe of route servers, I found 22 legacy /8's that were partly

...

or completely unused. I'm a little surprised ARIN/ICANN thinks it's a waste

...

of time to even try to reclaim them.

Because it is a waste of time and money.

That's an assertion I've heard, but has anyone quantified it? How much time and money would it take? Has anyone just asked the 22 /8 holders mentioned above nicely if they might just like to give them back for some good publicity? You know, US DoD migrates to IPv6 and returns X /8s for the good of the American people (assume ARIN) so that broadband might continue to grow and thrive in the land of the free? MMC

On Feb 9, 2011, at 10:35 PM, Matthew Moyle-Croft wrote:

On 10/02/2011, at 4:39 PM, Mark Andrews wrote:

...

In message <alpine.BSF.2.00.1102092156050.16359@goat.gigo.com>, Jason Fesler wri tes:

...

...

In my recent probe of route servers, I found 22 legacy /8's that were partly

...

or completely unused. I'm a little surprised ARIN/ICANN thinks it's a waste

...

of time to even try to reclaim them.

Because it is a waste of time and money.

That's an assertion I've heard, but has anyone quantified it? How much time and money would it take? Has anyone just asked the 22 /8 holders mentioned above nicely if they might just like to give them back for some good publicity? You know, US DoD migrates to IPv6 and returns X /8s for the good of the American people (assume ARIN) so that broadband might continue to grow and thrive in the land of the free?

MMC

Multiple times. The most optimistic estimates are on the order of 4 years. The most optimistic estimates of the return rate are on the order of 6-8 /8s (not the 100% of 22 /8s you are postulating). The legal expenses would be extreme. So, for $ALOT and 4 years of effort, you might get back as much as 4 months of address space. Next? Owen

On Feb 10, 2011, at 11:46 AM, Ricky Beam wrote:

Had they started the process a deacde ago instead of complaining that it's too much work, not worth it, etc., etc., then some of it might have been reclaimed by now.

How about 15 years ago: http://tools.ietf.org/html/rfc1917 Regards, -drc

On Feb 10, 2011, at 12:15 AM, Ricky Beam wrote:

On Wed, 09 Feb 2011 16:42:14 -0500, Nathan Eisenberg <nathan@atlasnetworks.us> wrote:

...

What do you mean, lit up? You mean they're not in the routing tables that you get from your carriers? I'd argue that's no indication of whether they're in use or not.

That's pretty much the definition of "in use". If they don't appear in the global routing table, then they aren't being used. I cannot send traffic to them; they cannot send traffic to me.

In my recent probe of route servers, I found 22 legacy /8's that were partly or completely unused. I'm a little surprised ARIN/ICANN thinks it's a waste of time to even try to reclaim them.

--Ricky

This dead horse keep coming back for another beating. The purpose of a global registry of numbers is to provide a common source for unique numbers. The definition of "in use" by internet registries does not require appearance in your routing tables or even in the route servers. Not only that, the "users" may not even want or need to exchange traffic with you. As a survivor of many network consolidations due to corporate acquisitions, I have many scars from trying to get separate RFC 1918 islands to interwork properly. That is the reason that even so-called private networks need unique IP addressing. And now, since IPv6 is actually being deployed and used, there is absolutely no economic incentive to continue to fight the "IPv4 addresses not in my routing table are not 'in use'" battle any more. It is a waste of time and money. James R. Cutler james.cutler@consultant.com

On 2/9/2011 9:15 PM, Ricky Beam wrote:

On Wed, 09 Feb 2011 16:42:14 -0500, Nathan Eisenberg <nathan@atlasnetworks.us> wrote:

...

What do you mean, lit up? You mean they're not in the routing tables that you get from your carriers? I'd argue that's no indication of whether they're in use or not.

That's pretty much the definition of "in use". If they don't appear in the global routing table, then they aren't being used.

There is no one universal "global routing table". They probably appear in someone's routing table, somewhere... just not yours. If Cogent stops peering with you (I picked them, because that's not out of the question) and you stop seeing all their downstream routes, did those addresses suddenly become available for reassignment?

I cannot send traffic to them; they cannot send traffic to me.

That's true of almost all addresses these days, what with firewalls and all.

In my recent probe of route servers, I found 22 legacy /8's that were partly or completely unused. I'm a little surprised ARIN/ICANN thinks it's a waste of time to even try to reclaim them.

How many days do you think a single /8 lasts at current assignment rates? How would ARIN/ICANN go about reclaiming addresses that someone believes they are using but that you don't think are in use? Matthew Kaufman

On 2/10/2011 9:46 PM, Ricky Beam wrote:

On Thu, 10 Feb 2011 11:43:50 -0500, Matthew Kaufman <matthew@matthew.at> wrote:

...

There is no one universal "global routing table". They probably appear in someone's routing table, somewhere... just not yours.

Using public address space for private networking is a gross misuse of the resource. Go to any registry and ask for address space for your private networking that you do not intend to announce to the internet. They will laugh at you, and point you to RFC1918. (and likely flag you as someone to whom address space should never be assigned.) The only reason legacy holders get away with such crap is because there's no clear contract governing their assignment.

https://www.arin.net/policy/nrpm.html#four35 Encourages use of RFC1918, but does not require it, especially when private peering with other networks is involved.

...

How many days do you think a single /8 lasts at current assignment rates?

APNIC says the last 2 /8's they were assigned (triggering the dead-man clause) would last ~6mo. With responsible use, 22 /8's would last several years. (3-5 best guess. Of course, there could be a land-rush and all of it disappear next week -- see also: responsible use)

If all 22 /8's were free to use, yes, 3-5 years. However, it violates existing RIR policies if those addresses are in use, even if not routed publicly.

First off, someone will have to do a lot more than 5 minutes of poking router-servers to see just how sparsely used ("announced") the space really is. That includes digging through BGP histories to see if it's ever been announced. Then research who should be in control of the space (announced or not.) Then send out nasty sounding letters informing whomever that X address space has not been announced to the public internet in Y years; on Z date, the space will reenter the IANA/ICANN free pool for reassignment. (cue lawyers :-)) They'd also be highly motivated to return unused space if they were being billing for it.

All of this would have to be accomplished in less than 6-9 months, but no one is going to wait in the hopes it might be accomplished, as failure would mean ruin. So the networks will deploy counter measures before the 6-9 month mark. They are already in the process.

As for this "not fixing the problem", IPv4 is going to be a problem for MANY years to come. IPv6 deployment is glacially slow. IPv4 being "out of space" is getting news attention now, but will fade from the spotlight shortly. The people who have space will continue to have it and generally not notice the lack of availablity. The likes of Facebook, etc., have jumped on IPv6 because they have a reason to... they have volumes of IPv6 connected eyeballs. Yet the likes of Amazon and Akamai, aren't supporting IPv6 (and have no published plans to.) Almost all of the major ISPs in the country still don't fully support IPv6 -- the few that do embrace v6 make it a pain in the ass to get it setup. I don't support IPv6 (since elink killed their experiment); I can get everywhere I care to go, and everyone who cares to get to me does. I, like many/most others, will fix that problem when it *is* a problem.

IPv4 will not be a problem for MANY years to come. If it survives 5 years in the DFZ, I'll be shocked. Errr, wasn't it this list that Akamai said they were testing and working on IPv6 deployments less than a week ago? Also, just because I have space (currently a /19 free), only means I have until that space runs out (assigning a /22 to a telco tomorrow morning as they just hit 98% utilization tonight, technically 100%, but I managed to free up a few). After that, IPv4 requires CGN or IPv6 with NAT64/DNS64. Neither option is pretty. Jack

I don't know about that. Yes, v4 will be around for a long time but considering the oligopolies we have in both eyeball and content networks, ones a dozen or so very large networks switch, there is the vast majority of Internet traffic right there. It will be around for a very long time handling a tiny bit of traffic.

Facebook alone accounts for 25% of internet traffic in the US. Netflix is estimated to be over 20% and YouTube at 10%. So that's 55% of Internet traffic right there. At the other end of the transaction you have AT&T with 15.7 million, Comcast at 15.9 million, Verizon at 9.2 million and Time Warner at 8.9 million (early 2010 numbers). That's 50 million of the estimated 83 million US broadband subscribers. So once three content providers and four subscriber nets switch, that is over 25% of US internet traffic on v6 (more than half the users and more than half the content they look at). Comcast, nor the other large MSOs, are not as monolithic as they may appear from the outside. In most cases the large MSOs are divided into regions that are more or less autonomous and that doesn't count the outlier properties that haven't been brought into the fold of the region

Agreed, V4 traffic levels are likely to drop and stay at low levels for decades. they are in for various, usually cost related, reasons so don't expect a large block of any of those guys to suddenly be at 60% of their users can get IPv6 addresses. While Facebook working over IPv6 will be a big deal you won't get all of their traffic since a significant fraction of that traffic is from mobile devices which are going to take much longer than PCs to get to using IPv6 in large numbers. Also, Netflix is even more problematic since the bulk of their traffic, and the fastest growing segment as well, is coming from Xboxes, Tivos, other gaming consoles, and TVs with enough embedded brains to talk directly. Those devices will also seriously lag behind PCs in IPv6 support.

I don't think the growth of v6 traffic is going to be gradual, I think it will increase in steps. You will wake up one morning to find your v6 traffic doubled and some other morning it will double again.

They'll be jumps, but they will be fairly smallish jumps since both the content maker, the ISP, and the device consuming the content all have to be ready. Since I don't imagine we will see any pure IPv6 deployments any time soon many/most of the IPv6 deploys will be dual stack and so we are still at the mercy of the AAAA record returning before the A record does.

-- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms --------------------------------

On Fri, Feb 11, 2011 at 10:00 AM, Scott Helms <khelms@ispalliance.net> wrote:

Agreed, V4 traffic levels are likely to drop and stay at low levels for decades.

I seriously doubt v4 traffic is going to fall off a cliff. That would require IPv6 adoption on a large scale over a relatively short period. To date, nothing in the v6 verse has happened *quickly*. Replacement or software upgrades to millions of CPEs in hundreds of network is not something that will happen overnight. Even then, that will not instantly switch everyone and every device to IPv6. How many "connected" devices do you think there are in the average home? TV? DVR (stb)? Game console(s)? Netflix streaming thing? If you're using Windows 7, you're already "IPv6 connected"... IPv6 is installed by default (and in fact cannot be uninstalled) and configured with Teredo. So a lot of people could be using v6 already and not even know it.

...

Facebook ... So that's 55% of Internet traffic right there.

and making a dent in it means residential transition. 50mil (or 83mil) devices is a lot of shit to replace or reprogram. Not to forget the thousands of devices that feed them.

... mobile devices

i.e. cellphones... the two largest groups there (iPhone and Android) support IPv6 already. (in certain versions) I was saying the same thing about netflix. PC based streaming can already be done via IPv6. (ipv6.netflix.com?) I'm not sure any of my media devices (tv, consoles, tivo) can do IPv6. I'd be disappointed if SONY didn't have the PS3 doing v6. Tivo doesn't do v6 -- unless the premier does. DTV receiver doesn't. DISH doesn't. (Wii, don't care. :-)) --Ricky

On Fri, 11 Feb 2011 12:20:59 -0500, George Bonser <gbonser@seven.com> wrote:

The thing is that a very few networks account for a very large amount of traffic.

Traffic has to have two end points. Just because the content source supports IPv6 does not mean the content request will be. That's the "millions of eyeballs" (aka sheep.) You don't seem to grasp the full picture... There are 4 parts to the equation: 1. Content Source 2. Transit network(s) 3. CPE 4. Content Consumer Fixing the source (be it Facebook, Youtube, or netflix) is rather simple in concept -- it's just one network, and doesn't require touching millions of devices. Transit networks are hit-n-miss, but is becoming less of a burden. The CPE on the other hand is a whole other mess... there are thousands (into millions) that will need firmware upgrades or complete replacement to support IPv6. (That's the cablemodems, dsl modem, Uverse RGs, FiOS ONTs, and linksys's and netgears of the world.) And *then* the device that actually wants the content has to have support. (that'd be you roku, blu-ray player, console, laptop, cellphone, picture frame, etc.)

What is the natural "churn" rate for CPE for one of the large MSOs?

How often MSO's replace CPE gear? "When it breaks" and "when it's no longer compat" I don't know about your cable company, but TW doesn't replace anything unless it's broken. I've had the same SB5100 for nearly a decade. (they did replace the SB3100/4100's a few years back, but they were no longer compatible with the network.) AT&T DSL also doesn't replace CPE's unless they break. (or you buy a new one.) In bridge mode, any modem will do. It's when the modem is also the router (which is most cases today) that it will need attention to support IPv6. (in bridge mode, you'll have to fix whatever it's plugged into, but that's the customer's problem... off to Best Buy for an IPv6 capable D-Link.)

What portion of the MSOs have v6 capable CPE in place right now...

Unknown. I've not known any MSO to publish those numbers. Any sane MSO is handing out D3 modems even if they are still running a D2 network, so new connections (or replacements) should be D3.

you only need about five

If you're thinking of five major cable operators, they aren't each "one network" but are a group of franchises/markets running more or less independent of each other.

Yes, and I mentioned that. So once you have >50% of the potential content sources v6 capable and >50% of the potential eyeballs v6 capable, you have potentially 25% of internet traffic on v6. And that can be done with the migration of enough networks to count on your fingers.

Heh. No it can't. You grossly underestimate the work necessary to get the eyeballs v6 capable. If Comcast has to replace as little as 10% of their modems, that'd be over 1mil. That's not going to happen overnight. (or even a month.) --Ricky

Fine approach as long as the DSLAMs and CPE allow ether type 0x86DD to pass. Frank -----Original Message----- From: Jack Bates [mailto:jbates@brightok.net] Sent: Friday, February 11, 2011 4:01 PM To: Ricky Beam Cc: nanog@nanog.org Subject: Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... On 2/11/2011 3:41 PM, Ricky Beam wrote:

In bridge mode, any modem will do. It's when the modem is also the router (which is most cases today) that it will need attention to support IPv6. (in bridge mode, you'll have to fix whatever it's plugged into, but that's the customer's problem... off to Best Buy for an IPv6 capable D-Link.)

I just finished discussing with the one telco in my network that deployed PPPoE. All customers will bring their modem into the office, where the front desk ladies will flash the config to bridge mode. It was that or replace thousands of CPE that never will support IPv6 in routed mode. Have a nice day. Jack

Fixing the source (be it Facebook, Youtube, or netflix) is rather simple in concept -- it's just one network, and doesn't require touching millions of devices. Transit networks are hit-n-miss, but is becoming less of

a

burden. The CPE on the other hand is a whole other mess... there are thousands (into millions) that will need firmware upgrades or complete replacement to support IPv6.

I would venture to say that it is likely that most of the CPE deployed over the past couple of years is capable of supporting v6 even if v6 is not currently deployed on that CPE. (That's the cablemodems, dsl modem, Uverse

RGs, FiOS ONTs, and linksys's and netgears of the world.) And *then* the device that actually wants the content has to have support. (that'd be you roku, blu-ray player, console, laptop, cellphone, picture frame, etc.)

You are "frame dragging" what I said into something I didn't say. What I said was that it will take v6 deployment in only a tiny portion of the number of networks to account for a large amount of the traffic. There is a lot of v6 capability that is just sitting there at the moment. I never said v4 support would go away, in fact, I said it would be around for decades.

...

What is the natural "churn" rate for CPE for one of the large MSOs?

How often MSO's replace CPE gear?

That is a different question. People are always moving, for example, turning in their old CPE and getting new. Old ones break and need to be replaced with a new one. Let's say the gear they have been handing out over the past couple of years has had v6 capability. So not only have all new deployments had the capability for v6 once the provider turns it up, a good number of legacy installations have been gaining v6 capability as old gear is changed out for new. How many CPE units does Comcast go through in a month? That would be about the rate of v6 capability being deployed out there even if v6 isn't turned up on it.

"When it breaks" and "when it's no longer compat" I don't know about your cable company, but TW doesn't replace anything unless it's broken.

Correct, and a certain number of those break every month. With every passing month the amount of CPE out there that isn't v6 capable declines.

I've had the same SB5100 for nearly a decade.

This isn't about you or me. It is about "the net" in aggregate. V4 will continue to work, and those with older stuff will get v4. But at some point there are going to be people who decide to deploy a site that is v6 only. It will be "cool" and only "certain" people will be able to get to the content. Probably college kids and aging hipsters. Then other people will start hearing about it and want access to it ... and will demand their ISP get them on v6 pronto ;)

Heh. No it can't. You grossly underestimate the work necessary to get the eyeballs v6 capable. If Comcast has to replace as little as 10% of their modems, that'd be over 1mil. That's not going to happen overnight. (or even a month.)

--Ricky

They are constantly replacing them, all the time. Every day they replace a few more. Someone moves, turns in their old cable box, gets a new one at the new place. Kid spills milk in it, it gets dropped, whatever. Old CPE attritions out of the installed base every day, I just don't know what the annual churn rate is. But I do believe that if IPv6 were enabled in a market today on some carrier, there would be an installed base of gear right now that could handle it on day one that would represent an amount of traffic that is not insignificant.

So riddle me this - what CPE stuff were they giving out in 2009 that was already v6-able? (and actually *tested* as being v6-able, rather than "It's supposed to work but since we don't do v6 on the live net, nobody's ever actually *tried* it...")

I would venture to say the same as today's CPE if they are issuing today the same CPE to new customers that they were issuing in 2009. I do know that in my area it has changed since 2007. But I don't know when they started issuing the current CPE.

On 02/12/2011 09:26 AM, Lamar Owen wrote:

While I have a few WRT54G's lying around, I've never tried IPv6 on them, and would find it interesting if anyone has.

http://www.tunnelbroker.net/forums/index.php?topic=106.0 -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/

On 02/12/2011 02:32 PM, Scott Howard wrote:

On Sat, Feb 12, 2011 at 9:26 AM, Lamar Owen<lowen@pari.edu> wrote:

...

While I have a few WRT54G's lying around, I've never tried IPv6 on them, and would find it interesting if anyone has.

I used a WRT54G running DD-WRT for some time with a HE IPv6 tunnel (now replaced with a Cisco 877, but not due to any failing of the Linksys/DD-WRT)

IPv6 support is actually broken in the latest version of DD-WRT, and it's been that way for some time (measured in years), however with some hacking you can get it to work. It's not at all user friendly, and definitely not consumer ready, but once it's working it's pretty much rock solid.

All up I'd say I probably spent less time getting IPv6 working on DD-WRT than on my Cisco 877W (Hint: IOS 12.x doesn't support IPv6 on the bridge interface, the IOS 15.x Advanced Security feature set doesn't support IPv6 at all, and the flash requirements listed for 15.1 Advanced IP are wrong. Go Cisco!)

Keep in mind that not all WRT54G's support DD-WRT. Linksys moved from Linux to Vxworks but kept the model number the same (the version did change). The WRT54GL along with various other devices do support it - details are on the DD-WRT website.

OpenWRT will run IPv6 fine; Comcast posted patches some months back to enable some 6rd configuration mods needed for Comcast's IPv6 trial. From the Comcast beta forum, it's clear that some people have succeeded at merging those 6rd patches into OpenWRT, though there may be some rough edges. I haven't had time to take them for a spin. - Jim

On 2/11/2011 5:34 PM, Owen DeLong wrote:

No, you grossly underestimate the motivation that will exist to get the eyeball networks v6 capable.

eyeball networks... we hack and patch them together. Silly putty is very useful. IPv6 rollouts are no different. Just more silly putty. IPv4 support for all the applications and appliances that don't support IPv6 is what will suck. So, don't worry about the ISP. Core networks are gearing up super fast (they've actually been at it for years, just not rolled it out), eyeballs will hack and patch easy enough (CPEs aren't that large a deal, and 6rd even gets us around internal v4 only problems in those isolated areas), many standard services on the net are v6 capable. Those which aren't, that's their own fault. They've had decades. :) Jack

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 My Milestone (android 2.1) uses IPv6 when connecting to a WLAN with stateless auto configuration enabled... (well at least basic connectivity when browsing web pages... Not sure about the rest...) Am 12.02.2011 16:49, schrieb Thomas Habets:

On Fri, Feb 11, 2011 at 16:02, Ricky Beam <jfbeam@gmail.com> wrote:

...

i.e. cellphones... the two largest groups there (iPhone and Android) support IPv6 already.

No they don't. Only Symbian and Maemo (MeeGo?) supports IPv6 *on the mobile side*.

Not android, not iphone.

Unless this has changed in the last month, it's still the case.

Neither of the two have any public plans to support IPv6 either.

Really.

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1WtpcACgkQHTGv6cAMp2iYGQCgmY7LZLOCyaj0SloiyObyBHx+ Ts8AnAvnyRurC9a3eZgwV0BRJ2oiAvJe =+mZr -----END PGP SIGNATURE-----

On Sat, 12 Feb 2011, Thomas Habets wrote:

Really.

Exactly. Can we PLEASE kill the myth that Android and iPhone has IPv6 support for mobile side. PLEASE. None do, and there are no publically available roadmaps when this might happen on either OSes. There are exactly two types of devices (afaik) that support IPv6 for mobile, and that's Nokia phones using Symbian and Maemo (afaik only N900). No other vendor has any IPv6 mobile side support, and even though Microsoft did the right thing for IPv6 on Vista and Win7, they've dropped the ball on Windows Phone 7 and have no IPv6 support there. I was very disappointed when I learnt that fact. I've been told it's to some extent a Qualcomm baseband issue. There are also no USB dongles with IPv6 support that I am aware of. This means that the incentive for mobile operators to support IPv6 is very close to zero even though a lot of them could do it fairly easily. I have native IPv6 in my Nokia N900, it works just fine within "my" own network, ie without roaming. -- Mikael Abrahamsson email: swmike@swm.pp.se

On Sat, 2011-02-12 at 09:37 -0800, Cameron Byrne wrote:

Mikael and I both have 3G networks with demonstrated IPv6 capabilities, perhaps people should request Google drive Android IPv6 support. Please point your IPv6 interest here http://code.google.com/p/android/issues/detail?id=3389 and comment and try and drive the IPv6 support for mobile into Android.

Looks like cyanogenmod supports ipv6: http://forum.cyanogenmod.com/topic/1286-ipv6-on-cm-508-ds/ Laurent

On Feb 11, 2011, at 7:00 AM, Scott Helms wrote:

...

I don't know about that. Yes, v4 will be around for a long time but considering the oligopolies we have in both eyeball and content networks, ones a dozen or so very large networks switch, there is the vast majority of Internet traffic right there. It will be around for a very long time handling a tiny bit of traffic.

Agreed, V4 traffic levels are likely to drop and stay at low levels for decades.