Sure the internet will not die... But by the time we run out of IPv4 to allocate, the IPv6 network will not have completed to dual stack the current IPv4 network. So what will happen? ----- Original Message ----- From: "Randy Bush" <randy@psg.com> To: "Franck Martin" <franck@genius.com> Cc: nanog@nanog.org Sent: Monday, 19 April, 2010 12:17:19 PM Subject: Re: Rate of growth on IPv6 not fast enough?

And doing guess-o-matic extrapolation, it will take another 3 years before we reach 10,000 ASN advertising IPv6 networks. That will be 33% of ASN. With the impending running out of IPv4 starting next year, seems to me we are not going to make it in an orderly fashion?

hint: those asns have ipv4

* William Herrin:

On Sun, Apr 18, 2010 at 8:45 PM, Franck Martin <franck@genius.com> wrote:

...

Sure the internet will not die...

But by the time we run out of IPv4 to allocate, the IPv6 network will not have completed to dual stack the current IPv4 network. So what will happen?

Zero-sum game. Deploying a new IPv4 address will require removing one from some other function.

Not true. Many LIRs have traditionally avoided reclaiming unused address space from (ex-)customers because it was cheaper to use fresh addresses.

Franck Martin wrote:

Sure the internet will not die...

But by the time we run out of IPv4 to allocate, the IPv6 network will not have completed to dual stack the current IPv4 network. So what will happen?

Reality is that as soon as SSL web servers and SSL-capable web browsers have support for name-based virtual hosts, the number of IPv4 addresses required will drop. Right now, you need 1 IP address for 1 SSL site; SNI spec of SSL gets rid of that. --Patrick

* Patrick W. Gilmore:

...

Reality is that as soon as SSL web servers and SSL-capable web browsers have support for name-based virtual hosts, the number of IPv4 addresses required will drop. Right now, you need 1 IP address for 1 SSL site; SNI spec of SSL gets rid of that.

Agreed.

When do you expect Windows XP & earlier versions to be a small enough segment of the userbase that businesses will consider DoS'ing those customers? My guess is when the cost of additional v4 addresses is higher than the profit generated by those customers.

Put another way: Not until it is too late.

I'm not so sure. Name-based virtual hosting for plain HTTP was introduced when Windows NT 4.0 was still in wide use. It originally came with Internet Explorer 2.0, which did not send the Host: header in HTTP requests. Anyway, I think the TLS thing is a bit of a red herring. It might be a popular justification for IP space at the formal level, but real-world requirements are a bit more nuanced. FTP and SSH/SFTP do not support name-based virtual hosting, so if you're a web hoster and structured things around "one IPv4 address per customer", then there might be another obstacle to collapsing everything on a single IPv4 address. It's also difficult to attribute DoS attackers at sub-HTTP layers to a customer if everything is on a single IPv4 address, making mitigation a bit harder.

* Patrick W. Gilmore:

...

I'm not so sure. Name-based virtual hosting for plain HTTP was introduced when Windows NT 4.0 was still in wide use. It originally came with Internet Explorer 2.0, which did not send the Host: header in HTTP requests.

NT4 was never heavily adopted by users.

It was fairly popular on corporate desktops, until 2005 or so. You really don't want to know details.

Also, not nearly as many billions were being sold on e-commerce sites.

We're talking pretty much recent history here, closer to 2005 than to 2000. Here are some statistics from a popular IT web site in Germany, from mid-2006: <http://www.heise.de/newsticker/meldung/Mozilla-Firefox-gewinnt-wieder-Marktanteile-140479.html> They report a 2.5% market share. Of course, these clients weren't running Internet Explorer 2.0 anymore, and this offers a clue what will happen if SNI is a desirable feature in browsers. 8-)

Owen DeLong wrote:

I had an interesting discussion with someone from Registration Services at ARIN today.

The big requests for IP space (the 11 organizations that hold 75% of all ARIN issued space) do not come from the server side... They come from the eye-ball ISPs. The only /8 issued by ARIN to an ISP, for example, was issued to a cable ISP.

With this in mind, I don't think there's much to be gained here. Optimizing the utilization of less than 25% of the address space in the face of the consumption rate on the 75% side simply cannot yield a meaningful result. It really is akin to rearranging the deck chairs on the Titanic.

The eyeball ISPs will find it trivial to NAT should they ever need to do so however, something servers cannot do - you are looking at numbers, not operational considerations. --Patrick

On Apr 19, 2010, at 7:14 AM, Patrick Giagnocavo wrote:

Owen DeLong wrote:

...

I had an interesting discussion with someone from Registration Services at ARIN today.

The big requests for IP space (the 11 organizations that hold 75% of all ARIN issued space) do not come from the server side... They come from the eye-ball ISPs. The only /8 issued by ARIN to an ISP, for example, was issued to a cable ISP.

With this in mind, I don't think there's much to be gained here. Optimizing the utilization of less than 25% of the address space in the face of the consumption rate on the 75% side simply cannot yield a meaningful result. It really is akin to rearranging the deck chairs on the Titanic.

The eyeball ISPs will find it trivial to NAT should they ever need to do so however, something servers cannot do - you are looking at numbers, not operational considerations.

--Patrick

I'm looking at both, and, frankly, LSN (large scale NAT) is not as trivial as you think. I actually talk to and work with some of these very large providers on a regular basis. None of them is looking forward to deploying LSN with anything but dread. The support issues, user experience, CALEA problems, and other issues with LSN are huge. None of them that I am aware of are considering using lSN to free up addresses to hand over to hosting providers. Owen

On 4/19/10 9:14 AM, "Patrick Giagnocavo" <patrick@zill.net> wrote:

The eyeball ISPs will find it trivial to NAT should they ever need to do so however, something servers cannot do - you are looking at numbers, not operational considerations.

Personally, I'm just waiting to see which eyeball ISP is the first to react to looming IPv4 exhaustion by (NAT | IPv6 && 6to4)ing their client ranges and using the freed up /9 to offer colo/hosting services at very competitive (compared to desperately scrambling to find a /29 at your IPv4-exhausted ISP) pricing. -- Dave Pooser, ACSA Manager of Information Services Alford Media http://www.alfordmedia.com

Nick Hilliard wrote:

On 19/04/2010 16:14, Patrick Giagnocavo wrote:

...

The eyeball ISPs will find it trivial to NAT should they ever need to do so [...]

Patrick,

Having made this bold claim, have you ever actually tried to run a natted eyeball network? The last two natted eyeball networks I worked with could never figure out which aspect of NAT hurt more: the technical side or the business side.

Nick

I apologize for a lack of clarity, in that what I meant was: "NAT for eyeball ISPs is technically possible and feasible if needed (since IP addresses are centrally managed by one company); NAT for servers (in the sense of dedicated/colocated systems run by different people/companies) is almost technically impossible and not feasible due to customer training needed and the coordination that would be required." I meant "trivial" FSVO "possible" - sorry. --Patrick

On 2010-04-19, at 10:51, Florian Weimer wrote:

* Nick Hilliard:

...

On 19/04/2010 16:14, Patrick Giagnocavo wrote:

...

The eyeball ISPs will find it trivial to NAT should they ever need to do so [...]

...

Having made this bold claim, have you ever actually tried to run a natted eyeball network? The last two natted eyeball networks I worked with could never figure out which aspect of NAT hurt more: the technical side or the business side.

I'm pretty sure the acceptance of NAT varies regionally. I think there's a large ISP in Italy which has been doing NAT since the 90s. So it's not just the mobile domain.

I haven't been a customer of an ISP in New Zealand for a long time now, but people there tell me that there is an expectation of NAT when you sign up for DSL service. Nobody normally expects to be handed a globally-unique v4 address. Joe

On Mon, 19 Apr 2010 10:01:25 -0500 (CDT) Joe Greco <jgreco@ns.sol.net> wrote:

...

* Nick Hilliard:

...

On 19/04/2010 16:14, Patrick Giagnocavo wrote:

...

The eyeball ISPs will find it trivial to NAT should they ever need to do so [...]

...

Having made this bold claim, have you ever actually tried to run a natted eyeball network? The last two natted eyeball networks I worked with could never figure out which aspect of NAT hurt more: the technical side or the business side.

I'm pretty sure the acceptance of NAT varies regionally. I think there's a large ISP in Italy which has been doing NAT since the 90s. So it's not just the mobile domain.

It can be tricky to introduce a new NATted product and compete with established players which do not NAT, though.

It's another opportunity to monetize things. Give people the option of a "real" IP address for $5 extra a month in case they actually need it for gaming, etc., and default Grandma's average everyday connection to NAT.

That'd be easy if you were just starting up an ISP. What do you do with your existing customer base? If their current service includes a dynamic public IPv4 address, you can't gracefully take it away, without likey violating services T&Cs, government telco regulations etc. So you'll have to go through a formal process of getting agreement with customers to take them away. Or do you have a flag fall day when after that new customers get NATted, but old customers don't? Do you offer a LSN vs non-LSN product at different price points? The price difference must be large enough for people to care about, or better described, bother with it, yet the problem might be that that discount might need to be so large that it doesn't actually cover the costs of providing a service to that customer. Thinking about what sort of discount I'd find attractive enough on roughly what I spend for ADSL Internet access, and putting myself in a customers position, I'd figure it'd be at least 10%. You'd have to state up front why you're offering a cheaper product, and for people to make an informed judgement value, they'll need to understand the problem i.e. the Internet running out of IPv4 addresses and what the consequences of NAT are. Their eyes will probably glaze over at this point, because all they want is "Internet" and don't care how it works, and are probably not going to want to accept restrictions now that might bite them in the future. At a certain point, the risks of going with a cheaper limited service, when you don't understand or fully understand it's restrictions, becomes higher than the price of the full service. IOW, if it's too hard to understand why the LSN service is cheaper, people will just pay the extra 10% - it's less riskier that way. That extra 10% is insurance.

The eyeball ISP's definitely have the easier end of things.

Considering the above issues, I'd think it's the other way around.

... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.

On Mon, 19 Apr 2010 10:01:25 -0500 (CDT) Joe Greco <jgreco@ns.sol.net> wrote:

...

...

* Nick Hilliard:

...

On 19/04/2010 16:14, Patrick Giagnocavo wrote:

...

The eyeball ISPs will find it trivial to NAT should they ever need to do so [...]

...

Having made this bold claim, have you ever actually tried to run a natted eyeball network? The last two natted eyeball networks I worked with could never figure out which aspect of NAT hurt more: the technical side or the business side.

I'm pretty sure the acceptance of NAT varies regionally. I think there's a large ISP in Italy which has been doing NAT since the 90s. So it's not just the mobile domain.

It can be tricky to introduce a new NATted product and compete with established players which do not NAT, though.

It's another opportunity to monetize things. Give people the option of a "real" IP address for $5 extra a month in case they actually need it for gaming, etc., and default Grandma's average everyday connection to NAT.

That'd be easy if you were just starting up an ISP. What do you do with your existing customer base? If their current service includes a dynamic public IPv4 address, you can't gracefully take it away, without likey violating services T&Cs, government telco regulations etc. So you'll have to go through a formal process of getting agreement with customers to take them away.

I haven't seen any such documents or regulations.

Or do you have a flag fall day when after that new customers get NATted, but old customers don't? Do you offer a LSN vs non-LSN product at different price points? The price difference must be large enough for people to care about, or better described, bother with it, yet the problem might be that that discount might need to be so large that it doesn't actually cover the costs of providing a service to that customer.

Maybe the price difference for existing customers is $0. You put them on NAT, and if they squawk, put them back. Since you don't need to do your whole customer base at once, you can even learn along the way.

Thinking about what sort of discount I'd find attractive enough on roughly what I spend for ADSL Internet access, and putting myself in a customers position, I'd figure it'd be at least 10%. You'd have to state up front why you're offering a cheaper product, and for people to make an informed judgement value, they'll need to understand the problem i.e. the Internet running out of IPv4 addresses and what the consequences of NAT are. Their eyes will probably glaze over at this point, because all they want is "Internet" and don't care how it works, and are probably not going to want to accept restrictions now that might bite them in the future. At a certain point, the risks of going with a cheaper limited service, when you don't understand or fully understand it's restrictions, becomes higher than the price of the full service. IOW, if it's too hard to understand why the LSN service is cheaper, people will just pay the extra 10% - it's less riskier that way. That extra 10% is insurance.

Many/most people are _already_ behind a NAT gateway. The guy who wrote "The Internet for Dummies" went for a good while behind a carrier NAT without realizing he was. And he's no dummy. Practical experience by network operators who have deployed NAT suggests that it's not ideal, but it's not horrible or impossible. A vast number of people just want to do their stuff and don't really care too much as long as things don't break. So what you need to do is consider what it is most people do, and how much of that would break. For an average household that's browsing the web and checking mail, NAT == not noticeable. And there will be other things, too, that work just fine. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.

Mark Andrews wrote:

In message <201004200022.o3K0M2Ba007459@aurora.sol.net>, Joe Greco writes:

...

...

That'd be easy if you were just starting up an ISP. What do you do with your existing customer base? If their current service includes a dynamic public IPv4 address, you can't gracefully take it away, without likey violating services T&Cs, government telco regulations etc. So you'll have to go through a formal process of getting agreement with customers to take them away. I haven't seen any such documents or regulations.

People purchaced the service on the understanding that they would get a Internet address. A address behind a NAT is not a Internet address, it's a *shared* Internet address which is a very different thing.

Given that many ISPs put their sign-up documents, including contracts, on-line, you can no doubt supply a link to such a document that has legal terms that would preclude NATed service, yes? My recollection is only that I would be provided with "Internet service" or "access to the Internet" . No mention of RFC1918 space or other distinguishing information was given. Note in the below blurb no mention of publicly routable addresses... Comcast's contract states: "Comcast will provide you with dynamic Internet protocol ("IP") address(es) as a component of HSI, and these IP address(es) can and do change over time. You will not alter, modify, or tamper with dynamic IP address(es) assigned to you or any other customer. You agree not to use a dynamic domain name server or DNS to associate a host name with the dynamic IP address(es) for any commercial purpose. You also agree not to use any software that provides for static IP address(es) on or in conjunction with any computer(s) or network device connected to HSI. If applicable, Comcast will release and/or recover the dynamic IP address(es) when the Service or this Agreement is disconnected, discontinued, or terminated." --Patrick

Mark Andrews wrote:

In message <4BCD14EF.8090204@zill.net>, Patrick Giagnocavo writes:

...

Mark Andrews wrote:

...

...

I haven't seen any such documents or regulations. People purchaced the service on the understanding that they would get a Internet address. A address behind a NAT is not a Internet address, it's a *shared* Internet address which is a very different

In message <201004200022.o3K0M2Ba007459@aurora.sol.net>, Joe Greco writes: thing. Given that many ISPs put their sign-up documents, including contracts, on-line, you can no doubt supply a link to such a document that has legal terms that would preclude NATed service, yes?

My recollection is only that I would be provided with "Internet service" or "access to the Internet" . No mention of RFC1918 space or other distinguishing information was given.

Note in the below blurb no mention of publicly routable addresses...

It doesn't have to as the normal definition of a Internet address is a publically routable internet address. A address behind a NAT is not a Internet address (Big I Internet).

(hope the attribution is not screwed up) *ANY* valid Internet Protocol address is an "IP address" as mentioned in the contract I quoted. Including 192.168.99.2 .

If you supply something less than a full blown Internet access you need to point out the restriction otherwise I would expect you to be subject to "Bait and Switch" and other consumer protection laws.

You are charmingly naive about how "the law" actually works in the USA - that is IMHO. In any case, I left the large amount of quotes in to show that I (and possibly Joe) are asking you for specific examples to support your argument - and all you are offering is more of your personal opinion, which is not an objective source of support for your position. If I want that, I can go to any of *.livejournal.com, *.blogger.com , etc. --Patrick

On Tue, Apr 20, 2010 at 01:58:13PM +1000, Mark Andrews wrote:

...

You are charmingly naive about how "the law" actually works in the USA - that is IMHO.

Yes, things vary around the world. You failed to state "In the USA". There is plenty of case law in Australia about companies attempting to arbitarially change terms and conditions to the detriment of the consumer and being made to reverse the changes.

this is the North American Network Operators Group. Not the Australian Network Operators Group.

Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia

--bill

On Tue, Apr 20, 2010 at 10:45:02PM +1000, Mark Andrews wrote:

In message <20100420121646.GE15321@vacation.karoshi.com.>, bmanning@vacation.ka roshi.com writes:

...

On Tue, Apr 20, 2010 at 01:58:13PM +1000, Mark Andrews wrote:

...

...

You are charmingly naive about how "the law" actually works in the USA - that is IMHO.

Yes, things vary around the world. You failed to state "In the USA". There is plenty of case law in Australia about companies attempting to arbitarially change terms and conditions to the detriment of the consumer and being made to reverse the changes.

this is the North American Network Operators Group. Not the Australian Network Operators Group.

And last I heard NA != USA. So have you decided to annex the rest of NA and bring it under US law. :-)

nope - but we'll be glad to tell your PM that Australia is prepared to join the Union as the next five states and enjoy all the benefits of our enlighted government and laws. or would you prefer to be part of Canada? --bill

On Tue, 20 Apr 2010 23:02:26 +0930, Mark Smith said:

access like you used to. You guys sue over hot coffee (of both kinds)!

Well.. yeah. When it causes 3rd degree burns, you start thinking about suing. http://www.lectlaw.com/files/cur78.htm "McDonalds also argued that consumers know coffee is hot and that its customers want it that way. The company admitted its customers were unaware that they could suffer thirddegree burns from the coffee...." Read that and tell me if you *still* think it's a totally frivolous lawsuit. (Hot water is *dangerous* - in many cases even more so than an open flame. If you stick your hand/arm in a flame, you can *usually* pull it out before your shirt sleeve catches fire, and you only take damage the time your arm is actually in the flame. You get a hot water spill on you, that sleeve will hold the hot water against your skin, and the burn becomes a gift that keeps on giving...)

In message <67D28817-D47B-468F-9212-186C60531140@internode.com.au>, Mark Newton writes:

On 20/04/2010, at 1:28 PM, Mark Andrews wrote:

...

Changing from a public IP address to a private IP address is a big change in the conditions of the contract. People do select ISP's on the basis of whether they will get a public IP address or a private IP address.

Seems to me your objection is based on whether or not the customer gets a public address vs a private address.

There's no need for NAT pools to be RFC1918. Pretty sure everyone is going to get a public address of some form... it just won't necessarily be globally unique to them.

RFC1918 addresses are not the only source of private addresses. If you are giving out addresses behind a NAT then they are private address.

As for jurisdictional issues: This particular Australian ISP amended its T&C document to give us the discretion of providing LSN addresses about two years ago. Will we need to? Perhaps not. But if we do, the T&C's are already worked out. Looking ahead in time and forecasting future risks is one of the things businesses are supposed to do, right?

Which is a good thing to do. If you are offering a (potentially) degraded service then the customer needs to be informed before they agree to the service. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

In message <201004200022.o3K0M2Ba007459@aurora.sol.net>, Joe Greco writes:

...

...

That'd be easy if you were just starting up an ISP. What do you do with your existing customer base? If their current service includes a dynamic public IPv4 address, you can't gracefully take it away, without likey violating services T&Cs, government telco regulations etc. So you'll have to go through a formal process of getting agreement with customers to take them away.

I haven't seen any such documents or regulations.

People purchaced the service on the understanding that they would get a Internet address. A address behind a NAT is not a Internet address, it's a *shared* Internet address which is a very different thing.

People purchase mobile Internet service and get placed behind carrier NAT. People get free Internet at hotels and are almost always behind a NAT. The terminology war is lost.

...

Many/most people are _already_ behind a NAT gateway.

They are behind NAT44 which they deployed themselves and control the configuration of themselves. They can direct incoming traffic as they see fit. They are NOT restricted to UDP and TCP.

NAT444 is a different kettle of fish. There are lots of things that you do with a NAT44 that you can't do with a NAT444.

If all you do is browse the web and read email then you won't see the much of a difference. If you do anything more complicated than making outgoing queries you will see the difference.

You *might* see the difference. You might not, too. And hey, just so we're clear here, I would *agree* that Internet access ought to mean an actual IP address with as little filtering, etc., as reasonable... but we're exploring what happens at exhaustion here. So I'm not interested in arguing this point; the fact of the matter is that we WILL hit exhaustion, and it's going to be a hell of an operational issue the day your subscribers cannot get an IP from the DHCP server because they're all allocated and in use. I'm as offended as anyone by what is often passed off as "Internet" access, but it's completely devoid of value to argue what you seem to be saying: the fact that it is so _today_ does not mean that it /has/ to be so _tomorrow._ All that's down that path is exhaustion with no solutions. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.

In message <201004201240.o3KCeHl4074118@aurora.sol.net>, Joe Greco writes:

...

In message <201004200022.o3K0M2Ba007459@aurora.sol.net>, Joe Greco writes:

...

...

That'd be easy if you were just starting up an ISP. What do you do with your existing customer base? If their current service includes a dynamic public IPv4 address, you can't gracefully take it away, without likey violating services T&Cs, government telco regulations etc. So you'll have to go through a formal process of getting agreement with customers to take them away.

I haven't seen any such documents or regulations.

People purchaced the service on the understanding that they would get a Internet address. A address behind a NAT is not a Internet address, it's a *shared* Internet address which is a very different thing.

People purchase mobile Internet service and get placed behind carrier NAT. People get free Internet at hotels and are almost always behind a NAT. The terminology war is lost.

But regardless of what it is called people usually know what they signed up for and when what has worked for the 5-6 years suddenly breaks ...

...

...

Many/most people are _already_ behind a NAT gateway.

They are behind NAT44 which they deployed themselves and control the configuration of themselves. They can direct incoming traffic as they see fit. They are NOT restricted to UDP and TCP.

NAT444 is a different kettle of fish. There are lots of things that you do with a NAT44 that you can't do with a NAT444.

If all you do is browse the web and read email then you won't see the much of a difference. If you do anything more complicated than making outgoing queries you will see the difference.

You *might* see the difference. You might not, too.

And hey, just so we're clear here, I would *agree* that Internet access ought to mean an actual IP address with as little filtering, etc., as reasonable... but we're exploring what happens at exhaustion here. So I'm not interested in arguing this point; the fact of the matter is that we WILL hit exhaustion, and it's going to be a hell of an operational issue the day your subscribers cannot get an IP from the DHCP server because they're all allocated and in use.

I'm as offended as anyone by what is often passed off as "Internet" access, but it's completely devoid of value to argue what you seem to be saying: the fact that it is so _today_ does not mean that it /has/ to be so _tomorrow._ All that's down that path is exhaustion with no solutions.

Hopefully being on the Internet, for the home user, will mean you have IPv6 connectivity and public address space handed out using PD in 3-5 years time. That Google, Yahoo etc. have turned on IPv6 to everyone. DS-lite or some other distributed NAT44 technology is being used to for those machines that don't support IPv6 or to reach content providers that have not yet enabled IPv6. If the ISP decides to go with NAT444 then the will be control pages that get you a real IPv4 address the same as many hotels have today as there will be customers that need the functionality. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

John Levine wrote:

Other than the .01% of consumer customers who are mega multiplayer game weenies, what's not going to work? Actual experience as opposed to hypothetical hand waving would be preferable.

.01%? heh. NAT can break xbox, ps3, certain pc games, screw with various programs that dislike multiple connections from a single IP, and the crap load of vpn clients that appear on the network and do not support nat traversal (either doesn't support it, or big corp A refuses to enable it). When we were in our infancy, we had areas doing NAT. It was a support nightmare from hell, and in some cases, it just didn't work period. That doesn't even get into the load issues. Jack

On Apr 20, 2010, at 7:53 AM, John Levine wrote:

...

But regardless of what it is called people usually know what they signed up for and when what has worked for the 5-6 years suddenly breaks ...

If a consumer ISP moved its customers from separate IPs to NAT, what do you think would break? I'm the guy who was behind a double NAT for several months without realizing it, and I can report that the only symptom I noticed was incoming call flakiness on one of my VoIP phones, and even that was easy to fix by decreasing the registration interval. The other VoIP phone worked fine in its default config.

Did you use Yahoo IM, AIM, or Skype? Did you use any of those for Video Chat and/or to transfer files? Did you do any peer to peer filesharing? Did you play any MMOs? Did you run any services?

Other than the .01% of consumer customers who are mega multiplayer game weenies, what's not going to work? Actual experience as opposed to hypothetical hand waving would be preferable.

I hate to break it to you, but they are not 0.1%, they are more like 15%. When you add in the other things that break which I have outlined above, you start to approach 75%. I would argue that 75% is a significant and meaningful fraction of an ISPs customer base.

I'm not saying that NAT is wonderful, but my experience, in which day to day stuff all works fine, is utterly different from the doom and disaster routinely predicted here.

Perhaps your day to day is different from others. Perhaps people here generally think in terms of servicing all of their customers. Perhaps in many cases if just 1% of our customers are on the phone with our technical support department, we are losing money. YMMV. Owen

On Tue, 20 Apr 2010, John R. Levine wrote:

Skype video chat, all the time, works fine. Don't remember about file transfer.

Whenever I am behind NAT and talk to someone else who is behind NAT skype seems to lower the quality, my guess it's because it now bounces traffic via another non-NATed node. These kind of applications work best if there is at least one non-NATed party involved, especially for video etc. -- Mikael Abrahamsson email: swmike@swm.pp.se

On Tue, 20 Apr 2010 18:38:33 +0200 (CEST) Mikael Abrahamsson <swmike@swm.pp.se> wrote:

On Tue, 20 Apr 2010, John R. Levine wrote:

...

Skype video chat, all the time, works fine. Don't remember about file transfer.

Whenever I am behind NAT and talk to someone else who is behind NAT skype seems to lower the quality, my guess it's because it now bounces traffic via another non-NATed node.

I think that means skype will be ported to IPv6 pretty quickly. CGN/LSN is going to dramatically reduce the number of 'super nodes' with public IPv4 addresses to relay calls through. That'll be particularly unfair to people in Australia, because here we have a per-month quota system e.g. 20GB of downloads and/or uploads a month. I wouldn't want my quota being chewed up by lots of other people's phone calls.

These kind of applications work best if there is at least one non-NATed party involved, especially for video etc.

-- Mikael Abrahamsson email: swmike@swm.pp.se

Regards, Mark.

"John R. Levine" <johnl@iecc.com> writes:

...

...

Did you run any services?

Of course not, it's consumer DSL. I run services on my server which is somewhere else and tunnel in via ssh which, of course, works fine through NAT.

Take a look at all those small SOHO storage boxes. They all offer web and FTP services and they all support something like dyndns. Customers want these features and are using these features.

For any such feature on such devices, it would be more honest for the purposes of debate to state that as "Some customers want these features [...]" which is completely true. There are a lot of features in a lot of devices that are never used by (a few, some, most, etc) end users, and even where they are used, the existence of web or ftp services on a storage appliance may merely mean that a user finds it more convenient to access the device locally that way... rather than setting up SMB etc. It certainly does not imply that all customers who buy the SuperStorageDeviceWithFTPCapability are running public FTP archives and that NAT becomes a problem for the owners of all those devices. It may be a problem for a percentage of them, though. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.

Andy Davidson wrote:

On Tue, Apr 20, 2010 at 11:29:59AM -0400, John R. Levine wrote:

...

...

Did you use Yahoo IM, AIM, or Skype?

Yes, yes, and yes. Works fine.

What about every other service/protocol that users use today, and might be invented tomorrow ? Do & will they all work with NAT ?

Anyone inventing a new service/protocol that doesn't work with NAT isn't planning on success.

Do many others work as well or act reliably through NAT ?

Yes.

Will it stop or hamper the innovation of new services on the internet ?

Hasn't so far.

The answer to these questions isn't a good one for users, so as the community that are best placed to defend service quality and innovation by preserving the end to end principal, it is our responsibility to defend it to the best of our ability.

Firewalls will always break the end-to-end principle, whether or not addresses are identical between the inside and outside or not.

So get busy - v6 awareness, availability and abundancy are overdue for our end users.

Maybe. Most of them are perfectly happy. Matthew Kaufman

On Tue, 27 Apr 2010 10:48:54 PDT, Matthew Kaufman said:

Anyone inventing a new service/protocol that doesn't work with NAT isn't planning on success.

Only true in the IPv4 world. IPv6 will hopefully be different.

...

The answer to these questions isn't a good one for users, so as the community that are best placed to defend service quality and innovation by preserving the end to end principal, it is our responsibility to defend it to the best of our ability.

Firewalls will always break the end-to-end principle, whether or not addresses are identical between the inside and outside or not.

The difference is that if a protocol wants to be end-to-end, I can fix a firewall to not break it. You don't have that option with a NAT.

...

So get busy - v6 awareness, availability and abundancy are overdue for our end users.

Maybe. Most of them are perfectly happy.

Most of the US population was perfectly happy just before the recent financial crisis hit. Ignorance is bliss - but only for a little while.

On Tue, 27 Apr 2010 14:37:08 EDT, Jon Lewis said:

Maybe we want end-to-end to break.

Firewalls can trivially be misconfigured such that they're little more than routers, fully exposing all the hosts behind them to everything bad the internet has to offer (hackers, malware looking to spread itself, etc.).

At least with NAT, if someone really screws up the config, the "inside" stuff is all typically on non-publicly-routed IPs, so the worst likely to happen is they lose internet, but at least the internet can't directly reach them.

You *do* realize that the skill level needed to misconfigure a firewall into that state, and the skill level needed to do the exact same thing to a firewall-NAT box, are *both* less than the skill level needed to remember to also deploy traffic monitors so you know you screwed up, and host-based firewalls to guard against chuckleheads screwing up the border box? In other words, if your security scheme relies on that supposed feature of NAT, you have *other* things you need to be working on.

On Tue, 27 Apr 2010 14:54:07 EDT, Jon Lewis said:

I think you forget where most networking is done. Monitoring? You mean something beyond walking down the hall to the network closet and seeing all the blinking lights are flashing really fast?

That site will manage to chucklehead their config whether or not it's NAT'ed.

How about the typical home DSL/Cable modem user?

And they won't manage to chucklehead their config, even if it's not NAT'ed.

Do you think they even know what SNMP is? Do you think they have host based firewalls on all their PCs?

Hmm... Linux has a firewall. MacOS has a firewall. Windows XP SP2 or later has a perfectly functional firewall out of the box, and earlier Windows had a firewall but it didn't do 'default deny inbound' out of the box. Those people with XBoxes and Playstations and so on can take it up with their vendors - they were certainly *marketed* as "plug it in and network", and at least my PS/2 and PS/3 didn't come with a "Warning: Do Not Use Without a NAT" sticker on them. So who doesn't have a host-based firewall in 2010? The idea is old enough that it's *really* time to play name-and-blame.

Do you want mom and dad's PCs exposed on the internet, or neatly hidden behind a NAT device they don't even realize is built into their cable/DSL router?

Be careful here - I know that at least in my neck of Comcast cable, you can go to Best Buy, get a cablemodem, plug the cable in one side, plug an ethernet and one machine in the other side, and be handed a live on-the-network DHCP address that works just fine except for outbound port 25 being blocked. For the past month or so, my laptop has gotten 71.63.92.124 every night when I get home, which certainly doesn't look very NAT'ed. Are you *really* trying to suggest that a PC is not fit-for-purpose for that usage, and *requires* a NAT and other hand-holding? And for the record - I don't worry about my mother's PC being exposed on the Internet, because she's running Vista, which has a sane firewall by default. What *does* worry me is that she's discovered Facebook, and anything she clicks on there will not have the *slightest* bit of trouble whomping her machine through a NAT. Let's be realistic - what was the last time we had a *real* threat that a NAT would have stopped but the XP SP2 firewall would not have stopped? And how many current threats do we have that are totally NAT-agnostic?

On Apr 27, 2010, at 2:25 PM, Jon Lewis wrote:

On Tue, 27 Apr 2010 Valdis.Kletnieks@vt.edu wrote:

...

That site will manage to chucklehead their config whether or not it's NAT'ed.

True...but when they do it and all their important stuff is in 192.168.0/24, you still can't reach it...and if they break NAT, at least their internet breaks. i.e. they'll know its broken. When they change the default policy on the firewall to Accept/Allow all, everything will still work...until all their machines are infected with enough stuff to break them.

Nah... They'll chucklehead forward something to 135-139/TCP on the box with all the important stuff just fine. NAT won't save them from this.

...

Hmm... Linux has a firewall. MacOS has a firewall. Windows XP SP2 or later has a perfectly functional firewall out of the box, and earlier Windows had a firewall but it didn't do 'default deny inbound' out of the box.

Linux can have a firewall. Not all distros default to having any rules. XP can (if you want to call it that). I don't have any experience with MacOS. Both my kids run Win2k (to support old software that doesn't run well/at all post-2k). I doubt that's all that unusual.

And the rest of the world should pay for your kid's legacy requirements why?

...

Are you *really* trying to suggest that a PC is not fit-for-purpose for that usage, and *requires* a NAT and other hand-holding?

Here's an exercise. Wipe a PC. Put it on that cable modem with no firewall. Install XP on it. See if you can get any service packs installed before the box is infected.

1. Yes, I can. I simply didn't put an IPv4 address on it. ;-) 2. I wouldn't hold XP up as the gold standard of hosts here. Owen

On Thu, 29 Apr 2010 08:22:47 -0700 Bill Stewart <nonobvious@gmail.com> wrote:

On Tue, Apr 27, 2010 at 3:24 PM, Owen DeLong <owen@delong.com> wrote:

...

...

Here's an exercise.  Wipe a PC.  Put it on that cable modem with no firewall.  Install XP on it.  See if you can get any service packs installed before the box is infected.

One of my coworkers was IPv6ing his home network. He had to turn off the Windows firewall on the machine with the IPv6 tunnel for a couple of minutes to install some stubborn software. Then he had to reimage the box because it was pwned, and he's pretty sure that the infection came in over the IPv6 tunnel, not the hardware-firewalled IPv4.

Your friend should learn about causation verses correlation http://en.wikipedia.org/wiki/Correlation_does_not_imply_causation Every noticed how people who have car accidents got out of bed that morning?

-- ---- Thanks; Bill

Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.

James Hess wrote:

Fortunately, the IPv6 address space is so large and sparse, that scanning it would be quite a feat, even if a random outside attacker already knew for a fact that a certain /64 probably contains a vulnerable host.

All I need to do is run a popular web site on the IPv6 Internet, and I get all the addresses of connected hosts I want. That address-space-scanning is hard is nearly irrelevant. Matthew Kaufman

In message <Pine.LNX.4.61.1004271718210.5148@soloth.lewis.org>, Jon Lewis writes:

Both my kids run Win2k (to support old software that doesn't run well/at all post-2k). I doubt that's all that unusual.

Then they won't have IPv6 and hence are irrelevent to the discussion about IPv6 NAT. As for built in firewalls, even my brother printer as a firewall built into it and it supports IPv6. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

Owen DeLong wrote:

On Apr 27, 2010, at 10:48 AM, Matthew Kaufman wrote:

...

Andy Davidson wrote:

...

On Tue, Apr 20, 2010 at 11:29:59AM -0400, John R. Levine wrote:

...

...

Did you use Yahoo IM, AIM, or Skype?

Yes, yes, and yes. Works fine.

What about every other service/protocol that users use today, and might be invented tomorrow ? Do & will they all work with NAT ?

Anyone inventing a new service/protocol that doesn't work with NAT isn't planning on success.

Respectfully, I disagree. There are many possible innovations that are available in a NAT-less world and it is desirable to get to that point rather than hamper future innovation with this obsolete baggage.

I would argue that every one of those innovations, if even passably useful, can also be implemented in a NAT-full world.

...

...

Do many others work as well or act reliably through NAT ?

Yes.

In reality, it's more like some yes, some not so much.

== Some designed to work properly in the face of NAT, some ignored reality at their peril.

...

...

Will it stop or hamper the innovation of new services on the internet ?

Hasn't so far.

Here I have to call BS... I know of a number of cases where it has.

Ok, you called it... so where's the list of such services that haven't materialized as a result of NAT? Matthew Kaufman

Owen DeLong wrote:

On Apr 27, 2010, at 11:49 AM, Matthew Kaufman wrote:

...

Owen DeLong wrote:

...

On Apr 27, 2010, at 10:48 AM, Matthew Kaufman wrote:

...

Andy Davidson wrote:

...

On Tue, Apr 20, 2010 at 11:29:59AM -0400, John R. Levine wrote:

...

> Did you use Yahoo IM, AIM, or Skype? > > Yes, yes, and yes. Works fine.

What about every other service/protocol that users use today, and might be invented tomorrow ? Do & will they all work with NAT ?

Anyone inventing a new service/protocol that doesn't work with NAT isn't planning on success.

Respectfully, I disagree. There are many possible innovations that are available in a NAT-less world and it is desirable to get to that point rather than hamper future innovation with this obsolete baggage.

I would argue that every one of those innovations, if even passably useful, can also be implemented in a NAT-full world.

Perhaps, but, often at significant additional code, development time, QA resources and other costs. Also, often at a degraded level requiring a non-NAT'd third-party broker to intermediate between any two NAT'd parties attempting to trade information.

Yes, there's additional development, but if NAT was more standardized (which it has a chance of being for IPv6, if we'd just stop arguing about whether or not it is going to happen... it'll happen, the question is whether or not there'll be a standard to follow) that development cost could be nearly a one-time library cost vs. custom code to deal with every situation and changing situations.

...

...

...

...

Do many others work as well or act reliably through NAT ?

Yes.

In reality, it's more like some yes, some not so much.

== Some designed to work properly in the face of NAT, some ignored reality at their peril.

We can agree to disagree about this. The reality is that there are cool things you can do with peer to peer networking that simply aren't possible in an enforced client-server model.

Agreed.

NAT enforces a client-server model and permanently and irrevocably relegates some administrative domains to the client role. This is an unfair disadvantage to the users within those domains when it is not by the choice of the administrator (and NAT in IPv4 so far, often is not).

No. Most NAT *doesn't* enforce a client-server model, it enforces a deliberate signaling model for establishing peer-to-peer communication, and allows open client-server communication (and most communication is, and will forever be, client-server). Assuming, again, that the NATs behave reasonably when trying to do peer-to-peer communication through them, which most (over 90% of what's deployed for IPv4) do. And *all* could, if there were standards people could code to. Which, again, for IPv6 there could be, if we'd stop claiming that NAT will never happen / is a bad idea and so shouldn't be standardized / etc.

...

...

...

...

Will it stop or hamper the innovation of new services on the internet ?

Hasn't so far.

Here I have to call BS... I know of a number of cases where it has.

Ok, you called it... so where's the list of such services that haven't materialized as a result of NAT?

Haven't materialized, for one, is an attempt to redefine the question. Note that the original question included "hamper". I would argue that the cost of maintaining a NAT compatibility lab and the QA staff to use it is a sufficient burden to call it "hamper".

Again, such a lab would not be needed if NAT operation were codified in standards. Which could happen, if not for the vocal set who keeps arguing against them, even when there's 5+ good reasons for them, even in IPv6.

For the ones that did not materialize, however, I am at an unfortunate disadvantage in the argument. I can tell you that I know of at least 5 such cases. However, I cannot reveal the details because I am under NDA to the companies that were developing these products. I can tell you that in 3 of the 5 cases, adapting them to cope with a NAT world would have required the company to run an external service in perpetuity (or at least so long as the application would function, no server, no function) in order to do the match-making between clients that could not directly reach each-other.

I guess a good analogy is this:

In a NAT world, you have only matchmaking services and all of your ability to meet potential mates is strictly controlled through these matchmaking services. There are many services available independent of each other, and, each has its own limitations, biases, and quirks. However, you cannot meet potential mates without involving at least one matchmaker.

True, but that's essentially true for all software, and certainly true for all "web-based" software.

In a NAT-Free world, you have the ability to use a matchmaking service if you like, but, you also have the ability to meet potential mates at bars, in the grocery store, on the street, in restaurants, through chance meetings, introductions by a friend, or even at work.

Really? There's still the name/service to address lookup problem. If the controlling entity goes away, you're again dead in the water. We're just lucky that some of those services (e.g., DNS) have a group who's agreed to run them in perpetuity as far as we can tell. If every root nameserver moved to a new IP address on a random whim tomorrow, most of these apps you talk about would stop working. No different than losing access to the aforementioned matchmaking service.

It is possible that if you never knew it was possible to meet potential mates in all of these other ways, you would happily deal with a vast number of matchmaking services hoping to find a useful result. On the other hand, if you were to ask the average person who has experienced the latter scenario if they would be willing to limit their choices to only using a dating service, my guess would be that most people would reject the idea outright.

Some people want the matchmaking controlled by an entity other than the de facto one, actually. Lots of benefits to trying to register your highly-mobile computer in a peer-to-peer introduction system designed for that instead of in a DNS that isn't. Matthew Kaufman ps. In the spirit of disclosure, I should point out that I've shipped a peer-to-peer networking protocol that works through most NATs and which is almost certainly already installed on the computer you are using now.

On 4/27/2010 1:36 PM, Andy Davidson wrote:

On Tue, Apr 20, 2010 at 11:29:59AM -0400, John R. Levine wrote:

...

...

Did you use Yahoo IM, AIM, or Skype?

Yes, yes, and yes. Works fine.

What about every other service/protocol that users use today, and might be invented tomorrow ? Do & will they all work with NAT ?

Sure, I can invent a service/protocol that doesn't work with NAT. While I am at it, I'll make it not work with IPv4, IPv6, Ethernet, an architectures using less than 256 bits of memory addressing. I bet it'll be popular!

Do many others work as well or act reliably through NAT ?

Yes, nearly everything that end users use works great through NAT, because end users are often behind NAT and for a service to be popular, it has to be NAT-friendly. Protocols that are not NAT friendly and yet survive are generally LAN applications that are resting on their NAT-unferiendliness and calling it security.

Will it stop or hamper the innovation of new services on the internet ?

Nope.

The answer to these questions isn't a good one for users, so as the community that are best placed to defend service quality and innovation by preserving the end to end principal, it is our responsibility to defend it to the best of our ability.

The end to end principle only helps service quality and innovation when the services are built on an end to end model. In a client-server world where addresses only identify groups of endpoints and individual identification is done at higher layers (which is what the ipv4+NAT Internet is looking like), end to endness is an anomaly, not the norm.

So get busy - v6 awareness, availability and abundancy are overdue for our end users.

Nearly all of the end users don't give a rat's hindquarters about ipv6. It gives them nothing they know that they want. Meanwhile, those who do know they want it are getting used to working around it, using PAT tricks and STUN services. Should people *have* to use those services? No. But there's so many other things that we shouldn't have to do, but we do anyway because that's how it works, that these NAT-circumvention tricks are not a dealbreaker. Meanwhile, the NATification of the Internet continuously increases the contrast between services (with real addresses) and clients (with shared addresses). Over time, this differentiation will increase and become more and more a standard (a de facto one if not an actual codified one.) Clients will have shared, ephemeral addresses, and services will have stable ones. This helps ensure that clients cannot generally communicate without a facilitating service, and every transaction will then have a middleman, somebody you have to pay somehow to get your services. You may pay in cash, by watching commercials, by sacrificing personal information, or by submitting your communciations to analysis by others, but somehow, you will pay. The vast majority of users won't care; they communicate that way now, and it does not bother them much. It's only those few who want to communicate without paying, in time, money, or privacy, or to communicate in ways other than the standard protocols, who will really suffer. And their complaints will have to fight against the voice of those who will say, well, if you make it end to end, then businesses lose money, and people will be able to share files again and violate copyrights, and all these things will cost jobs and tax dollars, etc, etc. If you want to avoid that future, I strongly suggest you deploy ipv6 and pressure others to do the same. But you're going to need to use valid arguments, about privacy and protection from the deprecations of unscrupulous middlemen, instead of insisting that the Internet will break down and die and locusts will descend from the heavens and eat our first born if we don't. -Dave

Mark Smith wrote:

On Tue, 27 Apr 2010 14:29:50 -0400 Dave Israel <davei@otd.com> wrote:

...

On 4/27/2010 1:36 PM, Andy Davidson wrote:

...

On Tue, Apr 20, 2010 at 11:29:59AM -0400, John R. Levine wrote:

...

...

Did you use Yahoo IM, AIM, or Skype?

Yes, yes, and yes. Works fine.

What about every other service/protocol that users use today, and might be invented tomorrow ? Do & will they all work with NAT ?

Sure, I can invent a service/protocol that doesn't work with NAT. While I am at it, I'll make it not work with IPv4, IPv6, Ethernet, an architectures using less than 256 bits of memory addressing. I bet it'll be popular!

One already exists. It's called DCCP, or Datagram Congestion Control Protocol - it's like UDP with congestion management. It'd be great to use for Video and Voip, which could then vary the codec parameters to suit congestion should it occur. Shame NAT has stopped it being widely deployed.

SCTP could be used to perform peer to peer IM and file transfers, where the file transfer takes place within the existing SCTP connection, rather than having to establish a separate connection. Shame NAT has stopped it being widely deployed.

Mark, I think you made Dave's point perfectly. Sure, history will be littered with protocols developed after NAT was widespread but whose designers willfully ignored reality (often committees filled with a bunch of people who wanted to acknowledge reality and a few strong voices who want to pretend there's a world without NAT both now and in the IPv6 future). Many of these won't see wide deployment as a result. You can add SIP and SDP to the list, as those were designed with an FTP-like belief that you can know your local address and send it around in the payload and expect the right thing to happen. (FTP at least had the excuse that it predated NAT deployment)... though SIP, for some inexplicable reason, has survived to make it to wide deployment anyway. Or you can run things like DCCP and SCTP encapsulated in UDP (works just fine), or design a new protocol that combines the best of DCCP and SCTP and DTLS and mix in some IP mobility and other features and deploy it to almost every Internet host (what I did... the protocol is RTMFP and it is in every copy of Flash Player since version 10.0), or design a new protocol for your application which does what DCCP and DTLS do only for your own widely deployed application (as the Skype folks did). All of these are excellent approaches for having something which *actually works*, though impefectly as the backlash against NATs in groups such as the IETF has lead to a big lack of standards around how they should work. Either applications learn to deal with NAT, in which case they thrive on both the heavily-NATed still-mostly-IPv4 Internet of the future *or* the has-NAT mostly-IPv6 Internet of the future (a great way to hedge your bets if you're writing protocols and applications)... or they don't learn to deal with NAT, in which case they don't work on todays IPv4 Internet *and* they won't work on the heavily-NATed still-mostly-IPv4 Internet of one possible future *or* the has-NAT mostly-IPv6 Internet of the future. Those won't be nearly as popular. And in case you don't have handy a short list of why the IPv6 Internet will be filled with NAT, I'll give you three items to start with: 1. SOX, HIPPA, and other audit checklist compliance currently requires NAT for (theoretical) fail-closed and topology hiding. If IPv6 NAT exists, this requirement may not go away. 2. There will be a requirement for client hosts which have IPv6 SLAAC implementations that expose their MAC address in the low address bits to have those bits hidden from the outside Internet. 3. Organizations not large enough to qualify for (or who don't wish to bother with) PI space will deploy NAT so as to avoid internal renumbering of things which must have static addresses (Intranet servers, DNS resolvers, etc.). This is because the IPv6 future where every LAN is carrying multiple PA addresses to every host wasn't sufficiently well designed for it to actually work for either the multihoming case or the interior-network/outside-Internet case. The good news is that it might be sufficient to do pure NAT and not NAPT, and it might be possible still to get some good standards around how these devices should behave... both of which aren't happening for the IPv4 Internet, unfortunately. Matthew Kaufman

I'm not normally one to respond to NANOG messages with opinions.... but... Yeah, NAT broke the internet. Yes you can engineer around it. There is NO reason to hold onto NAT as a standard. With v6 we have the opportunity to do it right (or at least semi-right) from the beginning, lets not choose to break it all from the beginning. Don't worry, if you understand basic routing these concepts shouldn't be hard for you. And don't worry, there is still plenty of market for residential "firewalls" and all but yeah maybe they'll actually have to be a firewall/router as opposed to just a NAT box. So there is my opinion; I don't understand why anyone thinks NAT should be a fundamental part of the v6 internet even after reading almost every message in this thread. It is just a stop-gap v4 measure and yeah, before people understood real security it was a security thing. Lets just move ahead with the good stuff! There'll be plenty of legacy/nostalgia around for years for those who still want to work with it. Just an opinion, Carl

On Wed, Apr 28, 2010 at 6:54 PM, David Conrad <drc@virtualized.org> wrote:

...

I don't understand why anyone thinks NAT should be a fundamental part of

On Apr 28, 2010, at 2:38 PM, Carl Rosevear wrote: the v6 internet

Perhaps the ability to change service providers without having to renumber?

Couldn't we use link scope (or other local) addresses to local networks, and have gateways that do 1:1 translation between those addresses and PA space ? Call it NATv6, whatever. Nobody is going to remember addresses by hand, name servers (DNS or local scope as avahi) will be the rule. And DHCPv6 (or router advertisement) is how you provide your hosts access. Maybe internal servers, such as smbfs or NFS, could be only at link scope addresses? No need to renumerate, and full protection from outsiders.

Regards, -drc

Seriously, Felipe

In message <01F57362-8092-48CB-8336-15B9CC1713C2@virtualized.org>, David Conrad writes:

On Apr 28, 2010, at 2:38 PM, Carl Rosevear wrote:

...

I don't understand why anyone thinks NAT should be a fundamental part = of the v6 internet=20

Perhaps the ability to change service providers without having to = renumber?

We have that ability already. Doesn't require NAT.

Regards, -drc -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

In message <A3F2FF6F-AFE3-4ED1-AD33-5B627724930B@virtualized.org>, David Conrad writes:

Mark,

On Apr 28, 2010, at 3:07 PM, Mark Andrews wrote:

...

...

Perhaps the ability to change service providers without having to = renumber? =20 We have that ability already. Doesn't require NAT.

Cool! You've figured out, e.g., how to renumber authoritative name = servers that you don't have direct control over!

Don't do that. It was a deliberate design decision to use names rather than IP addesses in NS records. This allows the operators of the nameservers to change their addresses when they need to. B.T.W. we have the technology to automatically update delegations if we need to and have for the last 10 years. People just need to stop being scared about doing it.

And modify filter = lists on a firewalls across an enterprise network! And remotely update = provisioning systems and license managers without interrupting services! = Etc., etc.

http://www.rfc-editor.org/internet-drafts/draft-carpenter-renum-needs-work= -05.txt

A tiny home office network managed by a highly technical individual with = full control over all aspects of the network is not a good model on = which to base the definition of "we".

Regards, -drc

Well if you insist on using IP addresses rather than real crypto for access control. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

On Wed, 28 Apr 2010 14:54:04 PDT, David Conrad said:

On Apr 28, 2010, at 2:38 PM, Carl Rosevear wrote:

...

I don't understand why anyone thinks NAT should be a fundamental part of the v6 internet

Perhaps the ability to change service providers without having to renumber?

RFC4193 or PI address space, depending what problem you're trying to solve by not renumbering.

Paul, On Apr 29, 2010, at 8:29 AM, Paul Timmins wrote:

If you change ISPs, send out an RA with the new addresses, wait a bit, then send out an RA with lifetime 0 on the old address.

Even if this works (and I know a lot of applications that use the socket() API that effectively cache the address returned by DNS for the lifetime of the application), how does this help situations where IPv6 address literals are specified in configuration files, e.g., resolv.conf, glue for authoritative DNS servers, firewalls/filters, network management systems, etc.? See sections 5 and 7 of http://www.rfc-editor.org/internet-drafts/draft-carpenter-renum-needs-work-0... The point here is that if there is a non-zero cost associated with renumbering, there will be non-zero incentive to deploy technologies such as NATv6 to reduce that cost. Some folks have made the argument that for sites large enough for the cost of renumbering to be significant, they should be able to justify provider independent space and be willing to accept the administrative and financial cost. While this may be the case (I have some doubts that many of the folks using PA space now will be all that interested in dealing with the RIR system, but I may be biased), it does raise concerns about routing system growth and forces ISPs to be willing to accept long IPv6 prefixes from end users (which some ISPs have already said they won't do). Regards, -drc

Owen, On Apr 30, 2010, at 7:04 PM, Owen DeLong wrote:

Ideally, in the vast majority of cases, resolv.conf is populated by dhcpv6 or it's successor.

:-). I haven't been following the religious war against DHCPv6 -- is it now acceptable to get DNS information via DHCPv6? I note that MacOSX still doesn't appear to support DHCPv6. Does Win7?

IPv6 also has the convenient concept of preferred and valid lifetimes on addresses facilitating a convenient overlap period while both prefixes still work, but, new flows should be universally originated from the specified prefix.

I'm aware of this. It would be interesting to see how many applications actually take advantage of this (rant about the socket API model deleted).

There is a non-zero cost associated with renumbering. However, it is much closer to zero than in IPv4.

I agree that it can or at least has the promise to be.

There is also a non-zero cost to NAT.

Yes.

Unfortunately, the costs of NAT are more on the toxic polluter basis, where you must pay your own tab for renumbering.

End users must pay the cost of renumbering in both cases. With NAT, renumbering is done on the NAT box. Without NAT, renumbering must be done within the entire network. NAT can have an additional initial capital cost (although most CPE support NATv4 at no additional cost) and can have a potentially non-obvious additional opex cost associated with debugging network problems, application support, etc. In the end, it would be nice if it was a simple business decision. In reality, I suspect most folks getting IPv6 prefixes from their ISP will follow the same model they use with IPv4 because that's what they know and it works for them. Hopefully, we'll see. Regards, -drc

IPv6's fundamental goal is to restore end-to-end.

For some. For many, IPv6's fundamental goal is to keep doing what we've been doing without running out of addresses. The fact that the two camps have orthogonal goals is probably part of the reason the rate of growth on IPv6 is so slow. -- Dave Pooser, ACSA Manager of Information Services Alford Media http://www.alfordmedia.com

--- On Wed, 4/28/10, Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote:

I'm not people are understanding or know the true reality. NAT broke the Internet's architecture, by turning IP from being a peer-to-peer protocol into a master/slave one (think mainframes and dumb terminals). Read RFC1958 if you don't understand what that means, specifically the 'end-to-end' principle part. IPv6's fundamental goal is to restore end-to-end.

And this, in a few short sentences, is why IPv6 adoption has been so incredibly slow and frustrating. For some of us, IPv6's primary benefit is solving the "32 bits aren't enough" problem. For others, the commercial Internet architecture which evolved is aesthetically offensive, and they see IPv6 as the corrective mechanism. Only one of those two has any sort of time constraint (read: necessity), and it isn't the latter. The end-to-end principle is grand, I agree - but there are lots of commercial considerations which I find have a higher priority for my customers. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com

And when ISPs start using NAT for their customers, there will be more problems leading to more support calls.

You say this as though they don't do it now. R's, John

On 19/04/2010 16:51, Florian Weimer wrote:

...

I'm pretty sure the acceptance of NAT varies regionally. I think there's a large ISP in Italy which has been doing NAT since the 90s.

to my knowledge, if we're talking about the same organisation, this large ISP is moving away from NAT, or already has done so.

Sure, you can NAT eyeballs, but it hurts like hell.

Which hurts more ... NATting eyeballs, or blinding them entirely? Eventually we'll run out. Then we get to pick. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.

On Apr 19, 2010, at 8:23 AM, Joe Greco wrote:

...

...

On 19/04/2010 16:51, Florian Weimer wrote:

...

I'm pretty sure the acceptance of NAT varies regionally. I think there's a large ISP in Italy which has been doing NAT since the 90s.

to my knowledge, if we're talking about the same organisation, this large ISP is moving away from NAT, or already has done so.

Sure, you can NAT eyeballs, but it hurts like hell.

Which hurts more ... NATting eyeballs, or blinding them entirely?

Eventually we'll run out. Then we get to pick.

IPv6 is not blinding them entirely.

No, IPv6 is clear vision. My _point_ was that NAT'ing eyeballs was better than providing no IPv4 gameplan (i.e. blind). ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.

On 4/19/2010 10:14, Patrick Giagnocavo wrote:

The eyeball ISPs will find it trivial to NAT should they ever need to do so however, something servers cannot do - you are looking at numbers, not operational considerations.

LSN is not trivial. Here is some unverified calculations I did on the problem of scaling nat. Right now I'm using 42 translation entries in my nat table. Each entry takes up 312 bytes of FIB memory, which is ~12.7 Kib of data in the FIB. Mutiply this by 250k users and we have 3,124,237 KiB of FIB entries, or 3.1 GiB. This is not running any PtP programs or really hitting the network, I'm just browsing the web and typing this email to you. If we look a the total number of translations for 250k users we see 10.5M entries. As TCP/UDP only has 65,536 ports and about 1025 of them are unusable, this leaves 64,511 ports to work with per IP. Divided out we need 163 public IP's min just to nat the number of users on a single PDSN pool, assuming we have a 1/2 loading thats 326 public IP's for one pool. Now things get fun when I turn on my torrent program, average number of translations is at 3500 per person (during a virus outbreak or other network event), we'll need a pool of 27k public IP's and 254 GiB of ram to store the NAT tables. This would be a /17 of IP space just to NAT 250k private users! This is why nat does not scale. NAT breaks other IP protocols which don't use TCP or UDP, and even breaks common protocols like TCP based FTP unless the NAT device has special support for FTP to do deep packet inspection and track the FTP sessions. Now suppose some one finds out that 250k people are behind a LSN box. All they have to do is write a virus that opens up tons of connections and it will DDOS the entire providers nat device. Jjust think, a single user could get the entire user base blocked from 4chan! -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

Bryan, On Apr 19, 2010, at 10:22 AM, Bryan Fields wrote:

Here is some unverified calculations I did on the problem of scaling nat.

Right now I'm using 42 translation entries in my nat table. Each entry takes up 312 bytes of FIB memory, which is ~12.7 Kib of data in the FIB. Mutiply this by 250k users and we have 3,124,237 KiB of FIB entries, or 3.1 GiB. This is not running any PtP programs or really hitting the network, I'm just browsing the web and typing this email to you.

This is really interesting data. What hardware is this on? Thanks, -drc

On 4/19/2010 10:40 AM, David Conrad wrote:

Bryan,

On Apr 19, 2010, at 10:22 AM, Bryan Fields wrote:

...

Here is some unverified calculations I did on the problem of scaling nat.

Right now I'm using 42 translation entries in my nat table. Each entry takes up 312 bytes of FIB memory, which is ~12.7 Kib of data in the FIB. Mutiply this by 250k users and we have 3,124,237 KiB of FIB entries, or 3.1 GiB. This is not running any PtP programs or really hitting the network, I'm just browsing the web and typing this email to you.

This is really interesting data. What hardware is this on?

most firewall vendors can give you this information for their products. it tends to manifest itself in documented connection table size limits. For devices using A PF derivative for example it's right around a kilobyte per entry.... platforms based on 32 bit memory architecture have a hard 4GB limit for that size of those datastructures.

Thanks, -drc

In a message written on Mon, Apr 19, 2010 at 01:22:31PM -0400, Bryan Fields wrote:

Right now I'm using 42 translation entries in my nat table. Each entry takes up 312 bytes of FIB memory, which is ~12.7 Kib of data in the FIB. Mutiply this by 250k users and we have 3,124,237 KiB of FIB entries, or 3.1 GiB. This is not running any PtP programs or really hitting the network, I'm just browsing the web and typing this email to you. [snip] Now things get fun when I turn on my torrent program, average number of translations is at 3500 per person (during a virus outbreak or other network event), we'll need a pool of 27k public IP's and 254 GiB of ram to store the NAT tables. This would be a /17 of IP space just to NAT 250k private users!

There are a few problems with your data.... I know of no platform that does hardware NAT. Rather, NAT is a CPU function. While this is another interesting scaling issue, it means this data is not going in the FIB (hardware forwarding database), but rather is stored in a CPU accessible database. It's not that you need 3.1G/254G of memory in the FIB (which would be expensive) but rather that you need it in relatively cheap DRAM. Even if use your larger memory number of 254G that's only $10-15k of RAM cost these days, hardly a deal breaker. The FIB would hold only one entry for the /17 (or similar) pointing it to the CPU. Secondly, you're playing to both extremes. Yes, the point to point user will use 3500 entries and grandma checking e-mail may use 42 entries. Not everyone will run a point to point client, and not everyone will be grandma. Using an average is a much better first start. I suspect though the percentage of users using a point to point client is small though, and thus drives the average number even lower. So, 3500 + 42 / 2 = 1751 entries on average per person. 250,000 users * 1751 entries * 312 bytes/entry = ~136G of data. 250,000 users * 1751 entries / 64000 ports/IP = 6939 IP's. So a /19 provides headroom. 10 servers, each with 16G of RAM (160G total) could do the job with headroom. Not all users will be active at the same time, so 100k per user probably translates into a 1Mbps/sec rate, given the old 10:1 rule on end users. 250,000 users * 100,000 bytes/sec = ~186Gigabits/sec. Humm, 10 servers won't do that (18Gbps/sec per server of NAT, no way!). 40 servers though would be 4.65Gbps per box, which with 10GE seems reasonable. But that also means each one only needs 1/4th the RAM from above. In summary, to NAT 250,000 users: 40 servers, each with: CPU capable of NATing 4.65Gbps 4-8Gb of memory 2x10GE interfaces A /19 of address space. I think a server like that could be had for $10k each, easy. So 400k of servers, depreciated over 3 years, divided by 250,000 users: $0.53 per user per YEAR. Or, $0.04 per month per user. Even selling $20 packages ISP's should be able to absorb four cents per user. NAT scales just fine. I find that quite unfortunate, personally, but I don't think there's a problem with the technology or economics. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/

On 4/19/2010 14:07, Leo Bicknell wrote:

e a few problems with your data....

I know of no platform that does hardware NAT. Rather, NAT is a CPU function. While this is another interesting scaling issue, it means this data is not going in the FIB (hardware forwarding database), but rather is stored in a CPU accessible database.

It's not that you need 3.1G/254G of memory in the FIB (which would be expensive) but rather that you need it in relatively cheap DRAM. Even if use your larger memory number of 254G that's only $10-15k of RAM cost these days, hardly a deal breaker. The FIB would hold only one entry for the /17 (or similar) pointing it to the CPU.

Well thats true of some implementations now, but some others put it in hardware. I'd say to scale you need to have it in hardware.

Secondly, you're playing to both extremes. Yes, the point to point user will use 3500 entries and grandma checking e-mail may use 42 entries. Not everyone will run a point to point client, and not everyone will be grandma. Using an average is a much better first start. I suspect though the percentage of users using a point to point client is small though, and thus drives the average number even lower.

Yes, but I was showing what a great DDOS attack method it would be too ;) The numbers were slightly better than something I pulled from my backside to demonstrate why we can't nat an entire PDSN worth of customers.

So, 3500 + 42 / 2 = 1751 entries on average per person.

250,000 users * 1751 entries * 312 bytes/entry = ~136G of data.

250,000 users * 1751 entries / 64000 ports/IP = 6939 IP's.

So a /19 provides headroom. 10 servers, each with 16G of RAM (160G total) could do the job with headroom.

Yea, but this is more along the lines of a science experiment at this point. I can't expect a carrier to deploy this, even if it's the best solution. The average carrier is _dumb_ and stupidity takes care of stupidity at these places. They are not going to deploy something unless it's Blue or Green (or purple).

Not all users will be active at the same time, so 100k per user probably translates into a 1Mbps/sec rate, given the old 10:1 rule on end users.

250,000 users * 100,000 bytes/sec = ~186Gigabits/sec. Humm, 10 servers won't do that (18Gbps/sec per server of NAT, no way!). 40 servers though would be 4.65Gbps per box, which with 10GE seems reasonable. But that also means each one only needs 1/4th the RAM from above.

In summary, to NAT 250,000 users:

40 servers, each with: CPU capable of NATing 4.65Gbps 4-8Gb of memory 2x10GE interfaces A /19 of address space.

I think a server like that could be had for $10k each, easy. So 400k of servers, depreciated over 3 years, divided by 250,000 users: $0.53 per user per YEAR. Or, $0.04 per month per user. Even selling $20 packages ISP's should be able to absorb four cents per user.

This is a good example, but I really would like to do some work on testing how much a given nat solution can scale.

NAT scales just fine. I find that quite unfortunate, personally, but I don't think there's a problem with the technology or economics.

It's a damn shame is what it is :( -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

* Leo Bicknell:

I know of no platform that does hardware NAT. Rather, NAT is a CPU function. While this is another interesting scaling issue, it means this data is not going in the FIB (hardware forwarding database), but rather is stored in a CPU accessible database.

If you NAT all traffic, the NAT database needs the same level of efficiency as the FIB. You could probably even join the two (you should check that the corresponding RIB entry is still current, but that can probably be forced to be cheap).

On Mon, 19 Apr 2010 19:57:04 -0700 Owen DeLong <owen@delong.com> wrote:

On Apr 19, 2010, at 3:10 PM, Florian Weimer wrote:

...

* Leo Bicknell:

...

I know of no platform that does hardware NAT. Rather, NAT is a CPU function. While this is another interesting scaling issue, it means this data is not going in the FIB (hardware forwarding database), but rather is stored in a CPU accessible database.

If you NAT all traffic, the NAT database needs the same level of efficiency as the FIB.

You could probably even join the two (you should check that the corresponding RIB entry is still current, but that can probably be forced to be cheap).

More likely, if you're going to do this (and I would not wish it on my worst competitors), you would want to push smaller NATs out towards the customer aggregation point where you can get away with cheaper commodity hardware that can later be repurposed. Yes, more boxes, but, much less expensive and keeps the router doing what routers do best rather than NATing everything on the router.

Pushing functions as closer to the edge of the network usually makes them easier to scale and more robust and resilient to failure. There might be more chance of failure, but there is less consequence. Specific to CGN/LSN, I think the best idea is that if we can't have a 1 to 1 relationship between subscriber and global IPv4 address (in the ISP network that is), the next best thing is to try to keep as close to that as possible e.g. if you share a single IPv4 address between two customers, you've halved your IPv4 addressing requirements / doubled your growth opportunity, and allowed for e.g. 32K TCP or UDP ports for each of those customers. Regards, Mark.

On Mon, Apr 19, 2010 at 1:22 PM, Bryan Fields <Bryan@bryanfields.net> wrote:

On 4/19/2010 10:14, Patrick Giagnocavo wrote:

...

The eyeball ISPs will find it trivial to NAT should they ever need to do so however, something servers cannot do - you are looking at numbers, not operational considerations.

LSN is not trivial.

Here is some unverified calculations I did on the problem of scaling nat.

Right now I'm using 42 translation entries in my nat table.  Each entry takes up 312 bytes of FIB memory, which is ~12.7 Kib of data in the FIB.  Mutiply this by 250k users and we have 3,124,237 KiB of FIB entries, or 3.1 GiB.  This is not running any PtP programs or really hitting the network, I'm just browsing the web and typing this email to you.

Bryan, Is there some reason we believe we need to scale individual NAT systems beyond about 1000 users each in order to have the desired impact on address recapture/reuse? Growing towards 7B people in the world with, let's say, 4 connected client devices each, grouped 1000 per NAT box requires 7B * 4 / 1K = 28M or 1.7 /8's for the eyeball networks before structural overhead. Pushing a carrier NAT process shallow has its own set of complications (and certainly isn't trivial) but raw scalability doesn't look like one of the problems. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004

LSN is not trivial.

Here is some unverified calculations I did on the problem of scaling nat.

One of my colleagues here (Shane Alcock) did some research into "Service Provider NAT" based off passive traces from a New Zealand Residential ISP[1]. By passively looking at connections he investigated how you could dimension a NAT box for an ISP. His research is available here http://www.wand.net.nz/~salcock/spnat/tech_report.pdf . If walls of text scare you (why are you reading this mailing list then?) skip through and look at the graphs (page 3 onwards) [1]: Contrary to Joe Abley's belief, I'm not aware of any major DSL provider in NZ that is doing NAT inside their network -- although almost all of the CPE's in New Zealand do NAT you, so as an end user you usually do end up behind NAT, but it is one under your own control, and can be eliminated with a careful choice of CPE. There are some wifi providers, and some 3G APN's that will provide you with ISP NAT.

On Mon, Apr 19, 2010 at 11:47 PM, Adrian Chadd <adrian@creative.net.au> wrote: > On Tue, Apr 20, 2010, Perry Lorier wrote:

...

could dimension a NAT box for an ISP.  His research is available here http://www.wand.net.nz/~salcock/spnat/tech_report.pdf .  If walls of text scare you (why are you reading this mailing list then?) skip through and look at the graphs (page 3 onwards) Interesting. Only a few days, and not really any analysis for worst case scenarios and how to possibly gracefully recover from those. (eg, I've done some NAT hacks to detect idle HTTP pconns and toss those before tossing the others.)

I found some of the premises lacking, at least, in an initial reading; session expiration is a problem for SP NAT, and for that reason, the dimensioning that makes it even worse is questionable, in that the shown er solution to UDP packets creating many sessions was by establishing extra short expiration durations; it attempts to address one problem, while creating an even bigger one..., NAPT with short expiration in a SP environment indicates a point of more breakage to network connectivity than the negative impact of current NAPT practice in enterprise environments. At least table sizings can be met by expanding capacity. Expiring good/still-active "short lived" sessions cannot be fixed, except by not expiring them. A good example of an application this "short lived sessions" treatment may break is DNS, if for example, a domain's authoritative responses are taking >10 seconds to arrive, and the DNS cache on a subscriber's PC submits a query to each of the authoritative servers for that domain, the session will expire, before 1/3rd of the normal DNS timeout has passed -- since only one packet is sent to submit each DNS query, they all get considered "short-lived sessions". Now instead of DNS being slow (response after 10 seconds due to congestion of an overseas link or something), the domain being resolved is completely unreachable ---- the response arrives but was discarded because the session expired, so never seen, unless one of the servers can get a response in within that 10s window.... That's an ungraceful failure result. Expiring sessions early is likely to create a similar problem for P2P client applications -- they were waiting for a response, but will never get it. That "one packet session" concept is just a prediction; in reality, the client likely hopes for a response from many of those requests within a few minutes... If expiring these"short lived sessions" is undesired by the application and if adopted by SPs could probably result in significant changes by the developers to the client software applications observed. Changes to the applications (in reaction to SP NAT) could be expected to effect that peak result of SP NAT, negating portions of state table reductions obtained temporarily through shortening expiration periods. Means that new apps designed for use with such services would probably have to re-transmit much earlier, or flood no-op UDP, TCP packets in order to keep sessions open, in order to provide the user a reasonable experience.. sending additional packets to 'keep sessions alive' on the NAT device consumes more time on the wire (bandwidth), negates and might eventually exceed part of the SP's advantage of early expiration, if the expire is short enough -- -J

Patrick Giagnocavo wrote:

...

The eyeball ISPs will find it trivial to NAT should they ever need to do so however, something servers cannot do - you are looking at numbers, not operational considerations.

I'll recommend this for competitors.

And what'll you do for your customers when you have no more IPv4 addresses? ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.

On 4/18/10 8:28 PM, "Patrick Giagnocavo" <patrick@zill.net> wrote:

Reality is that as soon as SSL web servers and SSL-capable web browsers have support for name-based virtual hosts, the number of IPv4 addresses required will drop.

And if Internet history teaches us one thing, it's that end users replace outdated browsers at the drop of a hat, right? -- Dave Pooser, ACSA Manager of Information Services Alford Media http://www.alfordmedia.com

On 4/18/2010 6:28 PM, Patrick Giagnocavo wrote:

Franck Martin wrote:

...

Sure the internet will not die...

But by the time we run out of IPv4 to allocate, the IPv6 network will not have completed to dual stack the current IPv4 network. So what will happen?

Reality is that as soon as SSL web servers and SSL-capable web browsers have support for name-based virtual hosts, the number of IPv4 addresses required will drop. Right now, you need 1 IP address for 1 SSL site; SNI spec of SSL gets rid of that.

my load balancer needs 16 ips for every million simultaneous connections, so does yours.

--Patrick

joel jaeggli wrote:

On 4/18/2010 6:28 PM, Patrick Giagnocavo wrote:

...

Reality is that as soon as SSL web servers and SSL-capable web browsers have support for name-based virtual hosts, the number of IPv4 addresses required will drop. Right now, you need 1 IP address for 1 SSL site; SNI spec of SSL gets rid of that.

my load balancer needs 16 ips for every million simultaneous connections, so does yours.

That is an accurate statement but sort of a side issue. I would hazard a guess that ~95% of publicly reachable (i.e. non-SSL-VPN) SSL certificate using servers would never see that amount of traffic. I am talking about the 5 or 10 IPv4 IPs you get with a $99/month dedicated server, so that you can setup 5 or 10 different clients with a shopping cart - Amazon and other large e-tailers have the ability to buy/work around any shortage or bottleneck. Cordially --Patrick

On Apr 19, 2010, at 3:16 AM, Chris Campbell wrote:

On 19 Apr 2010, at 03:52, joel jaeggli wrote:

...

On 4/18/2010 6:28 PM, Patrick Giagnocavo wrote:

...

Franck Martin wrote:

...

Sure the internet will not die...

But by the time we run out of IPv4 to allocate, the IPv6 network will not have completed to dual stack the current IPv4 network. So what will happen?

Reality is that as soon as SSL web servers and SSL-capable web browsers have support for name-based virtual hosts, the number of IPv4 addresses required will drop. Right now, you need 1 IP address for 1 SSL site; SNI spec of SSL gets rid of that.

my load balancer needs 16 ips for every million simultaneous connections, so does yours.

I'm pretty sure that's not the case for inbound connections...

http://vegan.net/pipermail/lb-l/2008-June/000871.html

Depends on which side of the loadbalancer you're talking about and how it is configured. Owen

On Apr 18, 2010, at 5:17 PM, Randy Bush wrote:

...

And doing guess-o-matic extrapolation, it will take another 3 years before we reach 10,000 ASN advertising IPv6 networks. That will be 33% of ASN. With the impending running out of IPv4 starting next year, seems to me we are not going to make it in an orderly fashion?

hint: those asns have ipv4

And... contrary to Chicken Little, the sky is not falling.

On 4/18/2010 9:56 PM, Mikael Abrahamsson wrote:

On Mon, 19 Apr 2010, Franck Martin wrote:

...

Anybody has better projections? What's the plan?

My guess is that end user access will be more and more NAT444:ed (CGN) while at the same time end users will get more and more IPv6 access (of all types), and over a period of time more and more of the p2p traffic (VoIP, file transfers etc) will move to IPv6 because it'll stop working over IPv4. When enough users have IPv6 access the server-based content will be made reachable over v6 as well.

The transition will take at least 5 years, I guess in 2015 we'll be perhaps halfway there.

Just because the curve doesn't look steep enough now doesn't mean it won't in two years. Human behavior is hard to model and panic hasn't set in yet. The nutjobs are for example not headed for the hills yet. http://www.time.com/time/magazine/article/0,9171,990020-1,00.html

In a message written on Sun, Apr 18, 2010 at 10:22:25PM -0700, joel jaeggli wrote:

Just because the curve doesn't look steep enough now doesn't mean it won't in two years. Human behavior is hard to model and panic hasn't set in yet.

There is also an aspect of this transition I don't think we've seen before (in networking). A large percentage of end users are on technologies (cable modem, dsl, even dial up) who's configuration is entirely driven out of a provisioning database. Once the backbone is rolled out, the nameservers, dhcp, and configuration servers dual-stacked many ISP's could enable IPv6 for all of their customers overnight with only a few keystrokes. Now they won't literally do it that way to save their support folks, but if the need arises they will be able to push the button quite quickly. I suspect the middle part of this S curve is going to be much, much steeper than anyone is predicting right now. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/

sthaug@nethelp.no wrote:

*If* the whole IPv6 config can be driven from the same database. For the time being, DHCPv6 cannot deliver a default gateway to customers (and there is a religious faction within the IPv6 community which seem to want to prevent this at all costs).

s/IPv6/IETF/ I don't know of anyone outside of the IETF promoting the insanity of a DHCP server not having the option of giving out a gateway address. - Kevin

On Mon, 19 Apr 2010 17:19:23 +0200 (CEST) sthaug@nethelp.no wrote:

...

There is also an aspect of this transition I don't think we've seen before (in networking). A large percentage of end users are on technologies (cable modem, dsl, even dial up) who's configuration is entirely driven out of a provisioning database.

Once the backbone is rolled out, the nameservers, dhcp, and configuration servers dual-stacked many ISP's could enable IPv6 for all of their customers overnight with only a few keystrokes.

*If* the whole IPv6 config can be driven from the same database. For the time being, DHCPv6 cannot deliver a default gateway to customers (and there is a religious faction within the IPv6 community which seem to want to prevent this at all costs).

I'm not religious about it, however I don't understand why it's such a problem. My fundamental objection is that if you've got two ways of achieving something, you've got twice as many things that can go wrong. Duplicate functionality drives up capex and opex. I'd have been happy with IPv6 only using DHCPv6. I'd have been happy with IPv6 only using RA type mechanisms (i.e. like IPX and Appletalk). Now that we've got both (because there are valid arguments for each method), at least lets try to keep them as simple as possible, by avoiding duplicating functionality across each of them. Currently the only pure duplication the RDNSS option in RAs. Although I think DNS information can be considered bootstrap information, I do have a fear that the RDNSS option in RAs will become the thin edge of the wedge.

As long as we have the dependency on RA for default gateways, what you suggest is considerably more difficult.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no

On Mon, Apr 19, 2010 at 12:10 PM, Frank Bulk - iName.com <frnkblk@iname.com> wrote:

Don't forget the home gateway aspect -- it's a huge gaping hole in the IPv6 deployment strategy for ISPs.  And don't talk to me about Apple's Airport Extreme.  ISPs want (once the volume of IETF IPv6-related drafts has settled down) for every router at Wal-mart to include IPv6 support.  If they start right now and presume that home gateways/routers are replaced every 3 to 5 years, it will be several years before they've covered even 50% of the homes.

Alternatively, they could commission the vendors to release firmware upgrades with IPv6 support for the most common older devices. Given that many of them are Linux based and the code already exists, this isn't likely to be technically difficult. The customer support costs, however, of convincing people to actually install the new firmware is another story. A consortium of ISPs could collectively work with the biggest OEMs/vendors to get this done if they wanted to do so. Start by commissioning IPv6 support into all new hardware. I would think that given the razor thin margins in home gateways/routers extra money coming in for simply turning on code which already exists would be attractive to at least some of them. Come up with some kind of logo for the program "IPv6 READY!". Make it a bandwagon thing so that vendors who aren't part of the program look behind the times. Offer some kind of cheap to implement network service to customers which can only be accessed via IPv6 to create user demand. Many people have said that the reason that no one is doing IPv6 is that there is nothing in it for the end users, so change that. Bill Bogstad

On Mon, Apr 19, 2010 at 1:14 PM, Mohacsi Janos <mohacsi@niif.hu> wrote:

On Mon, 19 Apr 2010, Bill Bogstad wrote:

...

On Mon, Apr 19, 2010 at 12:10 PM, Frank Bulk - iName.com <frnkblk@iname.com> wrote:

...

Don't forget the home gateway aspect -- it's a huge gaping hole in the IPv6 deployment strategy for ISPs.  And don't talk to me about Apple's Airport Extreme.  ISPs want (once the volume of IETF IPv6-related drafts has settled down) for every router at Wal-mart to include IPv6 support.  If they start right now and presume that home gateways/routers are replaced every 3 to 5 years, it will be several years before they've covered even 50% of the homes.

Alternatively, they could commission the vendors to release firmware upgrades with IPv6 support for the most common older devices.   Given that many of them are Linux based and the code already exists, this isn't likely to be technically difficult.

Yes it is. Most of the home gateways are are manufactured : develop, produce and forget life-cycle. The development codebase, is not existing anymore. The developers are moved to another company.... You barely have support for low-end home gateways after a year of first shipment. In the first year some bugfixing....

That's because they aren't getting paid for maintaining old firmware (razor thin margins). At least in the case of Linux based units, GPL enforcement has for the most part required them to keep better track of their codebase. As a result, I think this is more feasible then you do. Still it WOULD be easier to just work on getting all new equipment IPv6 capable. Both cable and cellphone companies already commission custom firmware for their settop boxes and cell phones, I see no reason that ISPs couldn't do the same.

...

Start by commissioning IPv6 support into all new hardware.   I would think that given the razor thin margins in home gateways/routers extra money coming in for simply turning on code which already exists would be attractive to at least some of them.  Come up with some kind of logo for the program "IPv6 READY!".

Don't count much on "IPv6 READY!" logo. IPv6 READY usually means, there are some IPv6 support in the device, but it might not work on your particular environment....: no IPv6 on PPPoE, no DHCPv6 support, no IPv6 setting are possible on webinterface....

That's why you make it a trademarked logo and you have licensing requirements that specify what must be included in order for them to use the logo on their marketing materials. The consortium decides what is needed to make IPv6 work for them and enforces it via logo licensing. Frankly if the protocols out of the IETF for things like DHCP/default routes don't make sense, the consortium can simply specify something else. I'm pretty sure that if the spec comes with a sufficiently large check attached the OEMs will implement whatever you want in the firmware. Bill Bogstad

On Mon, 19 Apr 2010, Leen Besselink wrote:

...

I actually think the razor thin margins make it less likely.

If I'm not mistaken, one of the reasons firmware updates are not available from a number of vendors/products, is because the small boxes don't have enough ROM and/or RAM.

The ROM is to small to hold an extra stack (or other features) and/or the RAM is to small to handle the connection tracking for the larger addresses. Because people want a stateful firewall, right ?

In a very low end devices maybe. Mid range devices there is enough flash and RAM. I have been using openwrt on various devices (asus, dlink, lynksys) with ipv6 for more than 3 years. Best Regards, Janos Mohacsi

On Mon, 19 Apr 2010 18:42:06 EDT, Joe Provo said:

On Mon, Apr 19, 2010 at 12:58:43PM -0400, Bill Bogstad wrote: [snip]

...

be attractive to at least some of them. Come up with some kind of logo for the program "IPv6 READY!". Make it a bandwagon thing so that vendors who aren't part of the program look behind the times.

Wheels, they get re-invented: http://www.ipv6ready.org/

How sad. I have IPv6, they don't (at the moment anyhow)... % wget http://www.ipv6ready.org --2010-04-19 20:53:53-- http://www.ipv6ready.org/ Resolving www.ipv6ready.org... 2001:468:603:c001::5, 132.177.125.100 Connecting to www.ipv6ready.org|2001:468:603:c001::5|:80... failed: Connection timed out. Connecting to www.ipv6ready.org|132.177.125.100|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 6381 (6.2K) [text/html] Saving to: “index.html” 100%[======================================>] 6,381 --.-K/s in 0.05s 2010-04-19 20:54:14 (122 KB/s) - “index.html” saved [6381/6381] % traceroute6 2001:468:603:c001::5 traceroute to 2001:468:603:c001::5 (2001:468:603:c001::5), 30 hops max, 80 byte packets 1 fe80::260:3eff:fe8c:bc99%ppp0 (fe80::260:3eff:fe8c:bc99%ppp0) 56.953 ms 65.618 ms 65.497 ms 2 isb-7301-1.gi0-1.110.cns.ipv6.vt.edu (2001:468:c80:210a::1) 64.179 ms 65.069 ms 65.086 ms 3 isb-6509-2.gi4-15.cns.ipv6.vt.edu (2001:468:c80:f220::1) 196.036 ms 198.903 ms 198.779 ms 4 isb-7606-1.ge1-1.cns.ipv6.vt.edu (2001:468:c80:f221::2) 64.558 ms 64.438 ms 64.315 ms 5 2001:468:cfe:1002::1 (2001:468:cfe:1002::1) 70.066 ms 69.948 ms 69.706 ms 6 2001:468:c00:ffff::1 (2001:468:c00:ffff::1) 69.574 ms 65.763 ms 55.573 ms 7 2001:468:c00:ffee::2 (2001:468:c00:ffee::2) 71.210 ms 71.056 ms 70.934 ms 8 2001:468:ff:906::1 (2001:468:ff:906::1) 75.973 ms 75.855 ms 75.677 ms 9 2001:468:ff:646::1 (2001:468:ff:646::1) 86.494 ms 86.363 ms 86.199 ms 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * *

On Mon, Apr 19, 2010 at 06:56:43AM +0200, Mikael Abrahamsson wrote:

On Mon, 19 Apr 2010, Franck Martin wrote:

...

Anybody has better projections? What's the plan?

My guess is that end user access will be more and more NAT444:ed (CGN) while at the same time end users will get more and more IPv6 access (of all types), and over a period of time more and more of the p2p traffic (VoIP, file transfers etc) will move to IPv6 because it'll stop working over IPv4. When enough users have IPv6 access the server-based content will be made reachable over v6 as well.

The transition will take at least 5 years, I guess in 2015 we'll be perhaps halfway there.

I suppose we will be here before 2015. We have at least one segment where IPv6 CPE is mandated by network access providers - that's cellular networks. So, adding "Verizon mandates IPv6 for LTE phones"[1] and "Verizon expects to commercially launch its LTE 4G network in up to 30 markets in 2010"[2] I can suggest that there will be significant increase of IPv6-enabled users in 2010-2011. May be this increase will be even significant enough to push content providers to dual-stack too... [1]: http://www.circleid.com/posts/20090609_verizon_mandates_ipv6_support_for_nex... [2]: http://www.wirelessweek.com/News-Verizon-LTE-Data-Calls-081709.aspx