Re: Microsoft's participation in World IPv6 day
On Jun 5, 2011 6:15 PM, "Mark Andrews" <marka@isc.org> wrote:
In message <BANLkTimGkuL7ycrYG6kTC1U7OWis9dOA+YaV-YHwr+5C8=
0Pxw@mail.gmail.com>
, =?UTF-8?B?SsOpcsO0bWUgTmljb2xsZQ==?= writes:
2011/6/6 Mark Andrews <marka@isc.org>:
There is no reason that they can't do a similar thing to move customers who are doing things that break with LSN out from behind the LSN.
Oh, you're right, they'll surelly do that. But not in time, and not for fre= e.
Well here in Australia I would be calling the ACCC is a ISP tried to charge extra for a address that is not behind a LSN. As for in time it should be in place before they turn on LSN. If you can adjust port 25 filters whenever a customer gets a new address you can also ensure that they get address from the correct pool when they connect to the network. This really isn't rocket science. It's updating the provisioning database from a web form and generating new configs based on that database. Yes there is some work required to ensure that this gets done properly and there needs to be checks that address pools are appropriately sized.
Can you cite an example of an isp doing this? My assumption is that people will get LSN by default for standard residential broad band and business class will get public ip's. Without any commitments to cite, plan for the worst and hope for the best. Cb
If I were doing it I would also have checkboxes for some of the more common reasons and include IPv6 connectivity as one then have a 6 month grace period once the ISP offers IPv6 connectivity before removing that as a valid reason for needing a address that is not behind the LSN.
LSN is beeing actively implemented in the core network of several ISPs, and most didn't yet consider it as optional. Nor are ready for v6 connectivity to residential customers, though.
For users behind a forced NAT (no way to disable it on the CPE) or LSN, the only way out is still tunneling. Talking about bandwidth and infrastructure waste... -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
In message <BANLkTiniAKw+GPPcmJFs8QFBdRM7QEk30w@mail.gmail.com>, Cameron Byrne writes:
On Jun 5, 2011 6:15 PM, "Mark Andrews" <marka@isc.org> wrote:
In message <BANLkTimGkuL7ycrYG6kTC1U7OWis9dOA+YaV-YHwr+5C8=
0Pxw@mail.gmail.com>
, =?UTF-8?B?SsOpcsO0bWUgTmljb2xsZQ==?= writes:
2011/6/6 Mark Andrews <marka@isc.org>:
There is no reason that they can't do a similar thing to move customers who are doing things that break with LSN out from behind the LSN.
Oh, you're right, they'll surelly do that. But not in time, and not for fre= e.
Well here in Australia I would be calling the ACCC is a ISP tried to charge extra for a address that is not behind a LSN. As for in time it should be in place before they turn on LSN. If you can adjust port 25 filters whenever a customer gets a new address you can also ensure that they get address from the correct pool when they connect to the network. This really isn't rocket science. It's updating the provisioning database from a web form and generating new configs based on that database. Yes there is some work required to ensure that this gets done properly and there needs to be checks that address pools are appropriately sized.
Can you cite an example of an isp doing this? My assumption is that people will get LSN by default for standard residential broad band and business class will get public ip's.
It's how you handle the exceptions. Home users have port 25 off by default but can still get it turned on. Most home users don't need a public IP address as they are not running stuff that requires it however some do so planning to handle the exceptions as efficiently as possible is a good thing to do. I've got two applications that won't work behind a LSN. A sip phone and a 6in4 tunnel however I'm not typical. Looking at 6to4 and auto tunnels they really are a small percentage of customers that could be auto detected by the ISP and be put into the exception pool prior to enabling LSN. Most CPE routers today don't enable 6to4 (they either don't support IPv6 let alone 6to4 or its not turned on by default). As for directly connected machines many of then still require 6to4 to be turned on by hand (XP, Mac OS). What's easier for the ISP, detecting the customers that use protocol 41 today and automatically adding them to a exception pool or fielding the support calls? Mark
Without any commitments to cite, plan for the worst and hope for the best.
Cb
If I were doing it I would also have checkboxes for some of the more common reasons and include IPv6 connectivity as one then have a 6 month grace period once the ISP offers IPv6 connectivity before removing that as a valid reason for needing a address that is not behind the LSN.
LSN is beeing actively implemented in the core network of several ISPs, and most didn't yet consider it as optional. Nor are ready for v6 connectivity to residential customers, though.
For users behind a forced NAT (no way to disable it on the CPE) or LSN, the only way out is still tunneling. Talking about bandwidth and infrastructure waste... -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Jun 5, 2011 7:15 PM, "Mark Andrews" <marka@isc.org> wrote:
In message <BANLkTiniAKw+GPPcmJFs8QFBdRM7QEk30w@mail.gmail.com>, Cameron
writes:
On Jun 5, 2011 6:15 PM, "Mark Andrews" <marka@isc.org> wrote:
In message <BANLkTimGkuL7ycrYG6kTC1U7OWis9dOA+YaV-YHwr+5C8=
0Pxw@mail.gmail.com>
, =?UTF-8?B?SsOpcsO0bWUgTmljb2xsZQ==?= writes:
2011/6/6 Mark Andrews <marka@isc.org>:
There is no reason that they can't do a similar thing to move customers who are doing things that break with LSN out from behind the LSN.
Oh, you're right, they'll surelly do that. But not in time, and not for fre= e.
Well here in Australia I would be calling the ACCC is a ISP tried to charge extra for a address that is not behind a LSN. As for in time it should be in place before they turn on LSN. If you can adjust port 25 filters whenever a customer gets a new address you can also ensure that they get address from the correct pool when they connect to the network. This really isn't rocket science. It's updating the provisioning database from a web form and generating new configs based on that database. Yes there is some work required to ensure that this gets done properly and there needs to be checks that address pools are appropriately sized.
Can you cite an example of an isp doing this? My assumption is that
Byrne people
will get LSN by default for standard residential broad band and business class will get public ip's.
It's how you handle the exceptions. Home users have port 25 off by default but can still get it turned on. Most home users don't need a public IP address as they are not running stuff that requires it however some do so planning to handle the exceptions as efficiently as possible is a good thing to do.
I've got two applications that won't work behind a LSN. A sip phone and a 6in4 tunnel however I'm not typical.
Looking at 6to4 and auto tunnels they really are a small percentage of customers that could be auto detected by the ISP and be put into the exception pool prior to enabling LSN. Most CPE routers today don't enable 6to4 (they either don't support IPv6 let alone 6to4 or its not turned on by default). As for directly connected machines many of then still require 6to4 to be turned on by hand (XP, Mac OS).
What's easier for the ISP, detecting the customers that use protocol 41 today and automatically adding them to a exception pool or fielding the support calls?
I understand your scenario and logic clearly. I assume you understood my question about an example isp that also follows your logic... so we are left to assume that none exists. If ISPs were going to follow your plan they would not be cooking up 6to4-pmt and charging extra for static ip's today. Cb
Mark
Without any commitments to cite, plan for the worst and hope for the best.
Cb
If I were doing it I would also have checkboxes for some of the more common reasons and include IPv6 connectivity as one then have a 6 month grace period once the ISP offers IPv6 connectivity before removing that as a valid reason for needing a address that is not behind the LSN.
LSN is beeing actively implemented in the core network of several ISPs, and most didn't yet consider it as optional. Nor are ready for v6 connectivity to residential customers, though.
For users behind a forced NAT (no way to disable it on the CPE) or LSN, the only way out is still tunneling. Talking about bandwidth and infrastructure waste... -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
It's how you handle the exceptions. Home users have port 25 off by default but can still get it turned on. Most home users don't need a public IP address as they are not running stuff that requires it however some do so planning to handle the exceptions as efficiently as possible is a good thing to do.
I disagree. I look forward to a day when all home users by default have a public IPv6 address for each of their machines and hopefully enough to support multiple subnets within the home. Until then, IPv4 service without at least one public IP is degraded at best compared to what most people consider normal residential internet access today (which, frankly, is degraded at best compared to what I consider normal internet access).
I've got two applications that won't work behind a LSN. A sip phone and a 6in4 tunnel however I'm not typical.
You're not that atypical either, at least compared to US users. The following very common applications are known to have problems with LSN: Playstation Network X-Box Live AIM/iChat/FaceTime SIP/Vonage/other VoIP services The HTTPs Server on TiVO boxes Peer to Peer (torrent, etc.) Other less common applications also have problems: HTTP servers SMTP servers Back to my Mac VNC Tunnels
Looking at 6to4 and auto tunnels they really are a small percentage of customers that could be auto detected by the ISP and be put into the exception pool prior to enabling LSN. Most CPE routers today don't enable 6to4 (they either don't support IPv6 let alone 6to4 or its not turned on by default). As for directly connected machines many of then still require 6to4 to be turned on by hand (XP, Mac OS).
While this is true, I'm not sure it's all that relevant. Most ISPs I have talked to in the US are dreading the deployment of LSN and not planning to deploy it by default except to the extent absolutely necessary to meet customer demand.
What's easier for the ISP, detecting the customers that use protocol 41 today and automatically adding them to a exception pool or fielding the support calls?
Moving them to IPv6 and hoping that enough of the content providers move forward fast enough to minimize the extent of the LSN deployment required. Owen
Mark
Without any commitments to cite, plan for the worst and hope for the best.
Cb
If I were doing it I would also have checkboxes for some of the more common reasons and include IPv6 connectivity as one then have a 6 month grace period once the ISP offers IPv6 connectivity before removing that as a valid reason for needing a address that is not behind the LSN.
LSN is beeing actively implemented in the core network of several ISPs, and most didn't yet consider it as optional. Nor are ready for v6 connectivity to residential customers, though.
For users behind a forced NAT (no way to disable it on the CPE) or LSN, the only way out is still tunneling. Talking about bandwidth and infrastructure waste... -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
In message <DFE74319-378F-4134-B521-452328B179F0@delong.com>, Owen DeLong writes:
It's how you handle the exceptions. Home users have port 25 off by default but can still get it turned on. Most home users don't need a public IP address as they are not running stuff that requires it however some do so planning to handle the exceptions as efficiently as possible is a good thing to do.
I disagree. I look forward to a day when all home users by default have a public IPv6 address for each of their machines and hopefully enough to support multiple subnets within the home.
need == something they currently do will break without it when LSN is deployed for IPv4 and there is not a suitable workaround. I'm all for customers getting public IPv6 addresses. Keeping IPv4 running until IPv6 is ubiquitous with minimal breakage is the challenge.
Until then, IPv4 service without at least one public IP is degraded at best compared to what most people consider normal residential internet access today (which, frankly, is degraded at best compared to what I consider normal internet access).
I've got two applications that won't work behind a LSN. A sip phone and a 6in4 tunnel however I'm not typical.
You're not that atypical either, at least compared to US users. The following very common applications are known to have problems with LSN: Playstation Network X-Box Live AIM/iChat/FaceTime SIP/Vonage/other VoIP services The HTTPs Server on TiVO boxes Peer to Peer (torrent, etc.)
Other less common applications also have problems: HTTP servers SMTP servers Back to my Mac VNC Tunnels
So you take these things that are known to break as exceptions to being behind a LSN and when there is a workable alternative you remove it from the exception list with a desription of the work around. e.g. SMTP servers don't require a public IPv4 address. STARTTLS with authenticated TURN to a external MX will work. Similarly a external dual stack MX + IPv6 support will work. The ISP could supply that external MX.
Looking at 6to4 and auto tunnels they really are a small percentage of customers that could be auto detected by the ISP and be put into the exception pool prior to enabling LSN. Most CPE routers today don't enable 6to4 (they either don't support IPv6 let alone 6to4 or its not turned on by default). As for directly connected machines many of then still require 6to4 to be turned on by hand (XP, Mac OS).
While this is true, I'm not sure it's all that relevant.
Most ISPs I have talked to in the US are dreading the deployment of LSN and not planning to deploy it by default except to the extent absolutely necessary to meet customer demand.
What's easier for the ISP, detecting the customers that use protocol 41 today and automatically adding them to a exception pool or fielding the support calls?
Moving them to IPv6 and hoping that enough of the content providers move forward fast enough to minimize the extent of the LSN deployment required.
Owen
Mark
Without any commitments to cite, plan for the worst and hope for the best.
Cb
If I were doing it I would also have checkboxes for some of the more common reasons and include IPv6 connectivity as one then have a 6 month grace period once the ISP offers IPv6 connectivity before removing that as a valid reason for needing a address that is not behind the LSN.
LSN is beeing actively implemented in the core network of several ISPs, and most didn't yet consider it as optional. Nor are ready for v6 connectivity to residential customers, though.
For users behind a forced NAT (no way to disable it on the CPE) or LSN, the only way out is still tunneling. Talking about bandwidth and infrastructure waste... -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Jun 6, 2011, at 12:20 AM, Mark Andrews wrote:
In message <DFE74319-378F-4134-B521-452328B179F0@delong.com>, Owen DeLong writes:
It's how you handle the exceptions. Home users have port 25 off by default but can still get it turned on. Most home users don't need a public IP address as they are not running stuff that requires it however some do so planning to handle the exceptions as efficiently as possible is a good thing to do.
I disagree. I look forward to a day when all home users by default have a public IPv6 address for each of their machines and hopefully enough to support multiple subnets within the home.
need == something they currently do will break without it when LSN is deployed for IPv4 and there is not a suitable workaround.
We have different definitions of need. I would argue that someone needs their sight. I don't know of any blind people who, given the opportunity, would consider sight unnecessary. I don't know of any sighted people who would consider the loss of their sight an acceptable outcome given any choice in the matter. The fact that most of the internet is currently disabled (behind NAT) does not mean that they do not need complete internet access. The fact that most people do not realize they are disabled is an unfortunate consequence of the nature of their disability, not a status quo that we should seek to preserve.
I'm all for customers getting public IPv6 addresses. Keeping IPv4 running until IPv6 is ubiquitous with minimal breakage is the challenge.
Yep... And a challenge of questionable and dubious benefit and success as well. I would argue that it is better to put that amount of resources behind making IPv6 more ubiquitous rather than diverting them to hackery aimed at preserving the status quo.
Until then, IPv4 service without at least one public IP is degraded at best compared to what most people consider normal residential internet access today (which, frankly, is degraded at best compared to what I consider normal internet access).
I've got two applications that won't work behind a LSN. A sip phone and a 6in4 tunnel however I'm not typical.
You're not that atypical either, at least compared to US users. The following very common applications are known to have problems with LSN: Playstation Network X-Box Live AIM/iChat/FaceTime SIP/Vonage/other VoIP services The HTTPs Server on TiVO boxes Peer to Peer (torrent, etc.)
Other less common applications also have problems: HTTP servers SMTP servers Back to my Mac VNC Tunnels
So you take these things that are known to break as exceptions to being behind a LSN and when there is a workable alternative you remove it from the exception list with a desription of the work around.
My point is that I don't know very many US internet users that don't use at least one of the above on a regular basis, so, you've now said that everyone should get an exception until there is a workable alternative. Most of these things will likely never have workable alternatives without significant development efforts and it's questionable how effective said alternatives can be even then.
e.g. SMTP servers don't require a public IPv4 address. STARTTLS with authenticated TURN to a external MX will work. Similarly a external dual stack MX + IPv6 support will work. The ISP could supply that external MX.
That implies an unacceptable trust model for users that don't have their own external TURN host. If everyone has a TURN host, then, you have only increased the required number of public addresses. One reason I run my own SMTP server is because I don't want to trust my ISP with access to cleartext versions of all of my email. Owen
Once upon a time, Owen DeLong <owen@delong.com> said:
You're not that atypical either, at least compared to US users. The following very common applications are known to have problems with LSN: The HTTPs Server on TiVO boxes
I'm curious: how does this have any problem with any particular NAT implementation? The TiVo HTTPS server is only intended to be accessed from the local LAN, so what happens outside your house (e.g. LSN) shouldn't matter. -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
On Jun 6, 2011, at 5:55 AM, Chris Adams wrote:
Once upon a time, Owen DeLong <owen@delong.com> said:
You're not that atypical either, at least compared to US users. The following very common applications are known to have problems with LSN: The HTTPs Server on TiVO boxes
I'm curious: how does this have any problem with any particular NAT implementation? The TiVo HTTPS server is only intended to be accessed from the local LAN, so what happens outside your house (e.g. LSN) shouldn't matter.
I disagree. It is allowed to be accessed anywhere from within your household. A household is defined as the members who live there regardless of where in the world they are at any particular time. Since I spend a great deal of time traveling, I routinely download shows from my TiVO over the internet using the https server on the TiVO box. Fortunately, my TiVO boxes have public IPv4 addresses and this is not an issue. I have confirmed with legal counsel and with TiVO that my interpretation of the term household is valid within the meaning of their license agreement. Owen
On Sun, Jun 5, 2011 at 11:24 PM, Owen DeLong <owen@delong.com> wrote:
Moving them to IPv6 and hoping that enough of the content providers move forward fast enough to minimize the extent of the LSN deployment required.
The problem here is not content, it's access. Look at World IPv6 day. What percentage of web content is represented? Probably order of 10%. How about access? Our public stats still say 0.3%
On 6/7/2011 9:01 PM, Lorenzo Colitti wrote:
On Sun, Jun 5, 2011 at 11:24 PM, Owen DeLong<owen@delong.com> wrote:
Moving them to IPv6 and hoping that enough of the content providers move forward fast enough to minimize the extent of the LSN deployment required.
The problem here is not content, it's access. Look at World IPv6 day. What percentage of web content is represented? Probably order of 10%. How about access? Our public stats still say 0.3% 0.3% of access is fine, so long as the margin of broken stacks and deployments is low enough. If they find that keeping the content dual stacked has acceptable problems, then it's just a matter of access gearing up to match. The largest fear for content is to dual stack and have service levels go down. The only data we really get from this day is a better understanding of the service levels when dual stacked at major content sites. Some access providers may also determine mistakes in their networks, or isolation or MTU issues through transit providers.
Jack
As long % IPv6 content > % IPv6 eyeballs, I think the eyeball counts will naturally go up over time. As we're seeing today, content providers can add IPv6 access to a greater percentage of their content in a few months than what ISPs can do with a percentage of their customer base. Frank -----Original Message----- From: Jack Bates [mailto:jbates@brightok.net] Sent: Tuesday, June 07, 2011 10:28 PM To: nanog@nanog.org Subject: Re: Microsoft's participation in World IPv6 day On 6/7/2011 9:01 PM, Lorenzo Colitti wrote:
On Sun, Jun 5, 2011 at 11:24 PM, Owen DeLong<owen@delong.com> wrote:
Moving them to IPv6 and hoping that enough of the content providers move forward fast enough to minimize the extent of the LSN deployment required.
The problem here is not content, it's access. Look at World IPv6 day. What percentage of web content is represented? Probably order of 10%. How about access? Our public stats still say 0.3% 0.3% of access is fine, so long as the margin of broken stacks and deployments is low enough. If they find that keeping the content dual stacked has acceptable problems, then it's just a matter of access gearing up to match. The largest fear for content is to dual stack and have service levels go down. The only data we really get from this day is a better understanding of the service levels when dual stacked at major content sites. Some access providers may also determine mistakes in their networks, or isolation or MTU issues through transit providers.
Jack
On Jun 7, 2011, at 7:01 PM, Lorenzo Colitti wrote:
On Sun, Jun 5, 2011 at 11:24 PM, Owen DeLong <owen@delong.com> wrote: Moving them to IPv6 and hoping that enough of the content providers move forward fast enough to minimize the extent of the LSN deployment required.
The problem here is not content, it's access. Look at World IPv6 day. What percentage of web content is represented? Probably order of 10%. How about access? Our public stats still say 0.3%
LSN won't be required by failure of access providers to migrate. LSN will be required by failure of content providers to turn on AAAA. LSN is required when access providers come across the following two combined constraints: 1. No more IPv4 addresses to give to customers. 2. No ability to deploy those customers on IPv6. For all but the most inept of access providers, they will have some ability to put customers on IPv6 prior to the day they would have to deploy LSN. Owen
Owen, On Tue, Jun 7, 2011 at 11:47 PM, Owen DeLong <owen@delong.com> wrote:
LSN is required when access providers come across the following two combined constraints:
1. No more IPv4 addresses to give to customers. 2. No ability to deploy those customers on IPv6.
2 has little bearing on need of LSN to access v4. Insufficient amount of IPv4 addresses => LSN required. Regards, Martin
On Jun 7, 2011, at 9:59 PM, Martin Millnert wrote:
Owen,
On Tue, Jun 7, 2011 at 11:47 PM, Owen DeLong <owen@delong.com> wrote:
LSN is required when access providers come across the following two combined constraints:
1. No more IPv4 addresses to give to customers. 2. No ability to deploy those customers on IPv6.
2 has little bearing on need of LSN to access v4. Insufficient amount of IPv4 addresses => LSN required.
Regards, Martin
No, if you have the option of deploying the customers on IPv6, you don't need LSN. The problem is that until the vast majority of content is dual-stack, you can't deploy customers on IPv6 without IPv4. Owen
On Wed, Jun 8, 2011 at 12:09 AM, Owen DeLong <owen@delong.com> wrote:
On Jun 7, 2011, at 9:59 PM, Martin Millnert wrote:
Owen,
On Tue, Jun 7, 2011 at 11:47 PM, Owen DeLong <owen@delong.com> wrote:
LSN is required when access providers come across the following two combined constraints:
1. No more IPv4 addresses to give to customers. 2. No ability to deploy those customers on IPv6.
2 has little bearing on need of LSN to access v4. Insufficient amount of IPv4 addresses => LSN required.
Regards, Martin
No, if you have the option of deploying the customers on IPv6, you don't need LSN.
The problem is that until the vast majority of content is dual-stack, you can't deploy customers on IPv6 without IPv4.
cough cough NAT64/DNS64 ... Cameron
Owen
On Wed, Jun 8, 2011 at 5:47 AM, Cameron Byrne <cb.list6@gmail.com> wrote:
On Wed, Jun 8, 2011 at 12:09 AM, Owen DeLong <owen@delong.com> wrote:
On Jun 7, 2011, at 9:59 PM, Martin Millnert wrote:
Owen,
On Tue, Jun 7, 2011 at 11:47 PM, Owen DeLong <owen@delong.com> wrote:
LSN is required when access providers come across the following two combined constraints:
1. No more IPv4 addresses to give to customers. 2. No ability to deploy those customers on IPv6.
2 has little bearing on need of LSN to access v4. Insufficient amount of IPv4 addresses => LSN required.
Regards, Martin
No, if you have the option of deploying the customers on IPv6, you don't need LSN.
The problem is that until the vast majority of content is dual-stack, you can't deploy customers on IPv6 without IPv4.
cough cough NAT64/DNS64 ...
cough DS-lite. Cameron
Cameron
Owen
Cameron, On Wed, Jun 8, 2011 at 8:48 AM, Cameron Byrne <cb.list6@gmail.com> wrote:
On Wed, Jun 8, 2011 at 5:47 AM, Cameron Byrne <cb.list6@gmail.com> wrote:
On Wed, Jun 8, 2011 at 12:09 AM, Owen DeLong <owen@delong.com> wrote:
On Jun 7, 2011, at 9:59 PM, Martin Millnert wrote:
Owen,
On Tue, Jun 7, 2011 at 11:47 PM, Owen DeLong <owen@delong.com> wrote:
LSN is required when access providers come across the following two combined constraints:
1. No more IPv4 addresses to give to customers. 2. No ability to deploy those customers on IPv6.
2 has little bearing on need of LSN to access v4. Insufficient amount of IPv4 addresses => LSN required.
Regards, Martin
No, if you have the option of deploying the customers on IPv6, you don't need LSN.
The problem is that until the vast majority of content is dual-stack, you can't deploy customers on IPv6 without IPv4.
cough cough NAT64/DNS64 ...
cough DS-lite.
Cameron
AF translators are in the same class of technology as LSN -- to me they are the same (_NAT_64). Someone who thinks you will be successful in selling an Internet with pure ipv6 only access today to consumers must be living on a different planet. Cheers, Martin
On Jun 8, 2011, at 5:48 AM, Cameron Byrne wrote:
On Wed, Jun 8, 2011 at 5:47 AM, Cameron Byrne <cb.list6@gmail.com> wrote:
On Wed, Jun 8, 2011 at 12:09 AM, Owen DeLong <owen@delong.com> wrote:
On Jun 7, 2011, at 9:59 PM, Martin Millnert wrote:
Owen,
On Tue, Jun 7, 2011 at 11:47 PM, Owen DeLong <owen@delong.com> wrote:
LSN is required when access providers come across the following two combined constraints:
1. No more IPv4 addresses to give to customers. 2. No ability to deploy those customers on IPv6.
2 has little bearing on need of LSN to access v4. Insufficient amount of IPv4 addresses => LSN required.
Regards, Martin
No, if you have the option of deploying the customers on IPv6, you don't need LSN.
The problem is that until the vast majority of content is dual-stack, you can't deploy customers on IPv6 without IPv4.
cough cough NAT64/DNS64 ...
cough DS-lite.
DS-lite is a slightly less pathological form of LSN. It's still LSN, it just removes the second NAT at the CPE. Owen
On Jun 8, 2011, at 5:47 AM, Cameron Byrne wrote:
On Wed, Jun 8, 2011 at 12:09 AM, Owen DeLong <owen@delong.com> wrote:
On Jun 7, 2011, at 9:59 PM, Martin Millnert wrote:
Owen,
On Tue, Jun 7, 2011 at 11:47 PM, Owen DeLong <owen@delong.com> wrote:
LSN is required when access providers come across the following two combined constraints:
1. No more IPv4 addresses to give to customers. 2. No ability to deploy those customers on IPv6.
2 has little bearing on need of LSN to access v4. Insufficient amount of IPv4 addresses => LSN required.
Regards, Martin
No, if you have the option of deploying the customers on IPv6, you don't need LSN.
The problem is that until the vast majority of content is dual-stack, you can't deploy customers on IPv6 without IPv4.
cough cough NAT64/DNS64 ...
Doesn't solve the problem unless your users are all on cell-phone browsers that don't do a lot of the things most users do with real internet connections. Owen
On Wed, Jun 8, 2011 at 6:04 AM, Owen DeLong <owen@delong.com> wrote:
On Jun 8, 2011, at 5:47 AM, Cameron Byrne wrote:
On Wed, Jun 8, 2011 at 12:09 AM, Owen DeLong <owen@delong.com> wrote:
On Jun 7, 2011, at 9:59 PM, Martin Millnert wrote:
Owen,
On Tue, Jun 7, 2011 at 11:47 PM, Owen DeLong <owen@delong.com> wrote:
LSN is required when access providers come across the following two combined constraints:
1. No more IPv4 addresses to give to customers. 2. No ability to deploy those customers on IPv6.
2 has little bearing on need of LSN to access v4. Insufficient amount of IPv4 addresses => LSN required.
Regards, Martin
No, if you have the option of deploying the customers on IPv6, you don't need LSN.
The problem is that until the vast majority of content is dual-stack, you can't deploy customers on IPv6 without IPv4.
cough cough NAT64/DNS64 ...
Doesn't solve the problem unless your users are all on cell-phone browsers that don't do a lot of the things most users do with real internet connections.
Most of my users are on cell phone browsers :) Furthermore, i can choose which ones get ipv4-only NAT44 and which get ipv6-only + NAT64 Now, only if there was major cell phone OEM support .... Also, i would like to extend the idea that as IPv6 becomes dominant in the next few years (pending access networks), the need for IPv4 access will wane and LSN for the IPv4 will become more acceptable as IPv4 is just the long tail. Cameron
On Jun 8, 2011, at 6:09 AM, Cameron Byrne wrote:
On Wed, Jun 8, 2011 at 6:04 AM, Owen DeLong <owen@delong.com> wrote:
On Jun 8, 2011, at 5:47 AM, Cameron Byrne wrote:
On Wed, Jun 8, 2011 at 12:09 AM, Owen DeLong <owen@delong.com> wrote:
On Jun 7, 2011, at 9:59 PM, Martin Millnert wrote:
Owen,
On Tue, Jun 7, 2011 at 11:47 PM, Owen DeLong <owen@delong.com> wrote:
LSN is required when access providers come across the following two combined constraints:
1. No more IPv4 addresses to give to customers. 2. No ability to deploy those customers on IPv6.
2 has little bearing on need of LSN to access v4. Insufficient amount of IPv4 addresses => LSN required.
Regards, Martin
No, if you have the option of deploying the customers on IPv6, you don't need LSN.
The problem is that until the vast majority of content is dual-stack, you can't deploy customers on IPv6 without IPv4.
cough cough NAT64/DNS64 ...
Doesn't solve the problem unless your users are all on cell-phone browsers that don't do a lot of the things most users do with real internet connections.
Most of my users are on cell phone browsers :)
Furthermore, i can choose which ones get ipv4-only NAT44 and which get ipv6-only + NAT64
Now, only if there was major cell phone OEM support ....
Also, i would like to extend the idea that as IPv6 becomes dominant in the next few years (pending access networks), the need for IPv4 access will wane and LSN for the IPv4 will become more acceptable as IPv4 is just the long tail.
Agreed... However, where I differ is that I believe it is content and services which will drive the ability for IPv4 to be considered long tail. If all of the content and services were IPv6-capable today, the need for LSN would be very near zero (limited to the consumer devices that need to be upgraded/replaced to understand IPv6.) However, as it stands currently, a consumer would not consider an IPv6 connection with NAT64 or other LSN to be equivalent to what they expect today (unless they're on a cell-phone where they already expect the internet experience to be completely degraded). Owen
The title of this ongoing thread is giving me heart palpitations. Content access over IPv6 may help "justify" ISPs investing in IPv6, but it in no means is a prerequisite technically. LSNs are "fine" when deployed in parallel with IPv6 IMHO. There has to be a pathway to "good" networking. To Lorenzo's point - I really think the next big hurdle in the transition is getting access numbers to something respectable. World IPv6 Day has only be going for a few hours, but things seem to be going fine, and it's our hope (currently) to keep www.xbox.com available over IPv6 indefinitely. I expect other participants will keep IPv6 enabled for some or all of their respective portfolios. This leads me to worry that in 6-18 months we'll be in a position where a lot of major content has permanently transitioned, and we're still at <1% access range. That will be awkward. I'm not an ISP - but I absolutely expect that IPv6 roll-outs have long time-horizons and are fairly complex. So I hope folks are looking at IPv6 NOW, and not simply waiting for Google/Bing/Yahoo/Interwebz to enable permanent content access and organizational justification. Christopher.Palmer@microsoft.com IPv6 @ Microsoft -----Original Message----- From: Owen DeLong [mailto:owen@delong.com] Sent: Tuesday, June 07, 2011 8:48 PM To: Lorenzo Colitti Cc: nanog@nanog.org Subject: Re: Microsoft's participation in World IPv6 day On Jun 7, 2011, at 7:01 PM, Lorenzo Colitti wrote:
On Sun, Jun 5, 2011 at 11:24 PM, Owen DeLong <owen@delong.com> wrote: Moving them to IPv6 and hoping that enough of the content providers move forward fast enough to minimize the extent of the LSN deployment required.
The problem here is not content, it's access. Look at World IPv6 day. What percentage of web content is represented? Probably order of 10%. How about access? Our public stats still say 0.3%
LSN won't be required by failure of access providers to migrate. LSN will be required by failure of content providers to turn on AAAA. LSN is required when access providers come across the following two combined constraints: 1. No more IPv4 addresses to give to customers. 2. No ability to deploy those customers on IPv6. For all but the most inept of access providers, they will have some ability to put customers on IPv6 prior to the day they would have to deploy LSN. Owen
On 8 jun 2011, at 7:42, Christopher Palmer wrote:
I'm not an ISP - but I absolutely expect that IPv6 roll-outs have long time-horizons and are fairly complex. So I hope folks are looking at IPv6 NOW, and not simply waiting for Google/Bing/Yahoo/Interwebz to enable permanent content access and organizational justification.
You have to remember that the content guys need few addresses and once they have them they rarely need more, and IPv6 or not is pretty much a binary thing: yes for everyone, no for everyone. It's the opposite for consumer ISPs: they need tons of addresses on an ongoing basis but they can (for instance) give IPv6 to new users while not changing anything for existing users. So once some hurdles such as the limited availability of IPv6-capable CPEs and a plan on how to provision IPv6 are taken the ISPs have a lot of incentive to roll out IPv6 while the content guys can conceivably stay on IPv4 for a long time. The fact that IPv6 client to IPv4 server is an easy problem but the other way around a very hard one also points in this direction. BTW, how are you guys dealing with path MTU discovery for IPv6? I've seen a few sites that have problems with this, such as www.nist.gov, but you guys seem ok.
On Jun 7, 2011, at 10:42 PM, Christopher Palmer wrote:
The title of this ongoing thread is giving me heart palpitations.
Content access over IPv6 may help "justify" ISPs investing in IPv6, but it in no means is a prerequisite technically.
LSNs are "fine" when deployed in parallel with IPv6 IMHO. There has to be a pathway to "good" networking.
How many of them are you planning on maintaining? May I quote you on this after you've been doing so for a year and received 2 or three lovely FISA subpoenas for your LSN logs?
To Lorenzo's point - I really think the next big hurdle in the transition is getting access numbers to something respectable. World IPv6 Day has only be going for a few hours, but things seem to be going fine, and it's our hope (currently) to keep www.xbox.com available over IPv6 indefinitely. I expect other participants will keep IPv6 enabled for some or all of their respective portfolios.
I agree with Lorenzo to a point, but... Access will happen in due time by virtue of IPv4 runout. If content is available dual-stack ahead of that, it dramatically reduces the need for (and load on) LSN. If it is not, then, LSN is going to be a much much uglier situation to an extent that it might even have a catch-22 effect on IPv6 deployment in the eyeball networks.
This leads me to worry that in 6-18 months we'll be in a position where a lot of major content has permanently transitioned, and we're still at <1% access range. That will be awkward.
Not really.
I'm not an ISP - but I absolutely expect that IPv6 roll-outs have long time-horizons and are fairly complex. So I hope folks are looking at IPv6 NOW, and not simply waiting for Google/Bing/Yahoo/Interwebz to enable permanent content access and organizational justification.
I don't think any of them are really waiting for that. However, I do think getting to that point is actually more critical at this juncture than getting the eyeball networks fully deployed. Owen
Christopher.Palmer@microsoft.com IPv6 @ Microsoft
-----Original Message----- From: Owen DeLong [mailto:owen@delong.com] Sent: Tuesday, June 07, 2011 8:48 PM To: Lorenzo Colitti Cc: nanog@nanog.org Subject: Re: Microsoft's participation in World IPv6 day
On Jun 7, 2011, at 7:01 PM, Lorenzo Colitti wrote:
On Sun, Jun 5, 2011 at 11:24 PM, Owen DeLong <owen@delong.com> wrote: Moving them to IPv6 and hoping that enough of the content providers move forward fast enough to minimize the extent of the LSN deployment required.
The problem here is not content, it's access. Look at World IPv6 day. What percentage of web content is represented? Probably order of 10%. How about access? Our public stats still say 0.3%
LSN won't be required by failure of access providers to migrate.
LSN will be required by failure of content providers to turn on AAAA.
LSN is required when access providers come across the following two combined constraints:
1. No more IPv4 addresses to give to customers. 2. No ability to deploy those customers on IPv6.
For all but the most inept of access providers, they will have some ability to put customers on IPv6 prior to the day they would have to deploy LSN.
Owen
On 6/8/2011 12:42 AM, Christopher Palmer wrote:
I'm not an ISP - but I absolutely expect that IPv6 roll-outs have long time-horizons and are fairly complex. So I hope folks are looking at IPv6 NOW, and not simply waiting for Google/Bing/Yahoo/Interwebz to enable permanent content access and organizational justification.
To be fair, I think any ISP worth it's salt is working on IPv6 access roll-outs, but there are a lot of considerations. A content provider generally doesn't want to hurt their own connectivity and service quality, which is why using IPv6 on the main sites has generally been frowned upon. An ISP has to deal with customers when these problems arise and actually absorbs the costs of dealing with them. As such, it's not unreasonable for many ISPs to delay rollouts to all customers. It's my honest belief that we have natural progression. The peering arrangements are getting sorted out, IPv6 pathing is slowly reaching par with IPv4 pathing in the largest networks. Content providers are testing and verifying service levels with dual stack. Access networks are deploying IPv6 up to the edge and in some cases releasing it to the customers. ARIN is fixing their policies. It could be better, but I think everyone is on the right track. Jack
On Tue, 07 Jun 2011 20:47:43 PDT, Owen DeLong said:
For all but the most inept of access providers, they will have some ability to put customers on IPv6 prior to the day they would have to deploy LSN.
The cynic in me says that guarantees widespread deployment of LSN. :)
participants (11)
-
Cameron Byrne -
Chris Adams -
Christopher Palmer -
Frank Bulk -
Iljitsch van Beijnum -
Jack Bates -
Lorenzo Colitti -
Mark Andrews -
Martin Millnert -
Owen DeLong -
Valdis.Kletnieks＠vt.edu