European ISP enables IPv6 for all?
In a recent Slashdot article (http://slashdot.org/articles/07/12/17/1451230.shtml) discussing IPv6, someone left a comment the read, in part "One of the largest IPSs (sic) in Europe turned on IPv6 to all 8 million users this week. They've done the right thing and made it opt-in for now, their customers have to go to their control panel web page and turn it on, but almost 50,000 people did in the first 24 hours." Does anyone know which ISP the poster is talking about? Is there any truth to this at all? Any feedback appreciated. Sean Siler IPv6 Program Manager Microsoft
On 2007/12/17 10:01, Sean Siler wrote:
Does anyone know which ISP the poster is talking about? Is there any truth to this at all?
Thanks to all for your private replies - I have the answer now. (It appears to be Free.fr, if you are interested.) http://www.iliad.fr/en/presse/2007/CP_IPv6_121207_eng.pdf Sean Sean Siler|IPv6 Program Manager -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Sean Siler Sent: Monday, December 17, 2007 1:02 PM To: nanog@merit.edu Subject: European ISP enables IPv6 for all? In a recent Slashdot article (http://slashdot.org/articles/07/12/17/1451230.shtml) discussing IPv6, someone left a comment the read, in part "One of the largest IPSs (sic) in Europe turned on IPv6 to all 8 million users this week. They've done the right thing and made it opt-in for now, their customers have to go to their control panel web page and turn it on, but almost 50,000 people did in the first 24 hours." Does anyone know which ISP the poster is talking about? Is there any truth to this at all? Any feedback appreciated. Sean Siler IPv6 Program Manager Microsoft
On Dec 17, 2007 10:29 AM, Sean Siler <Sean.Siler@microsoft.com> wrote:
Thanks to all for your private replies - I have the answer now.
(It appears to be Free.fr, if you are interested.)
I'm glad they managed to get in all the hype for v6 with little in the way of reality though... nothing like making it simple for people to get confused example: "This connection system is backward compatible with the current fixed IPv4." --or--- " Furthermore, IPv6 simplifies the configuration of devices when connected to the Internet. It improves data security and supports quality of services." how does it improve data security exactly? -Chris hurrah!
" Furthermore, IPv6 simplifies the configuration of devices when connected to the Internet. It improves data security and supports quality of services." how does it improve data security exactly?
attackers are daunted by the smoke and mirrors? <sigh> this stuff is hard enough to roll without the hype. randy
On Mon, 17 Dec 2007 15:29:21 -0800 "Christopher Morrow" <morrowc.lists@gmail.com> wrote:
how does it improve data security exactly?
Back in 1994, it was expected to be true because v6 would mandate IPsec, and v6 would be deployed long before the installed base of v4 machines would be upgraded to IPsec. Obviously, that's not what happened; while IPsec was indeed late in coming, v6 was even later, so the original belief has been OBE. The mythos, however, hasn't caught up. Similar statements can be made about stateless autoconfig vs. v4 DHCP. In a slightly more realistic vein, a huge address space makes life harder for scanning worms. As Angelos Keromytis, Bill Cheswick, and I have pointed out, "harder" is by no means equivalent to "impossible", but the myth, new as it is, still propagates. --Steve Bellovin, http://www.cs.columbia.edu/~smb
On Dec 17, 2007, at 10:37 PM, Steven M. Bellovin wrote:
On Mon, 17 Dec 2007 15:29:21 -0800 "Christopher Morrow" <morrowc.lists@gmail.com> wrote:
how does it improve data security exactly?
Back in 1994, it was expected to be true because v6 would mandate IPsec, and v6 would be deployed long before the installed base of v4 machines would be upgraded to IPsec. Obviously, that's not what happened; while IPsec was indeed late in coming, v6 was even later, so the original belief has been OBE. The mythos, however, hasn't caught up. Similar statements can be made about stateless autoconfig vs. v4 DHCP.
Perhaps the concept also holds true because there's a smaller target market for the moment, and attackers are all about ROI. We've certainly seen this at other layers of the stack. However, not sure I'd posit as such.
In a slightly more realistic vein, a huge address space makes life harder for scanning worms. As Angelos Keromytis, Bill Cheswick, and I have pointed out, "harder" is by no means equivalent to "impossible", but the myth, new as it is, still propagates.
As will the worms and malware, I suppose, though perhaps with more thought-out propagation vectors that employ not only local prefix scanning, but nifty things like walking ip6.arpa or the like for presumable denser host existence. Then again, who needs self propagation, when client-side attacks seem to be more than sufficient. -danny
On Dec 17, 2007, at 9:58 PM, Danny McPherson wrote:
when client-side attacks seem to be more than sufficient.
A self-selected group of victims really helps lower the reconnaissance opex, heh. ;> ----------------------------------------------------------------------- Roland Dobbins <rdobbins@cisco.com> // 408.527.6376 voice Culture eats strategy for breakfast. -- Ford Motor Company
On 18 dec 2007, at 6:37, Steven M. Bellovin wrote:
In a slightly more realistic vein, a huge address space makes life harder for scanning worms. As Angelos Keromytis, Bill Cheswick, and I have pointed out, "harder" is by no means equivalent to "impossible", but the myth, new as it is, still propagates.
I'd say that the huge address space makes life impossible for scanning worms. That doesn't mean that there can be no successful scanning at all with IPv6, but it needs to be highly targeted if you want results the same year, so just pumping random numbers in the destination address field like SQL slammer did so successfully doesn't cut it in IPv6.
On Tue, Dec 18, 2007, Iljitsch van Beijnum wrote:
I'd say that the huge address space makes life impossible for scanning worms.
The advent of P2P has made "Valid node discovery" easier than just scanning. Damned technology and its incremental improvements. :)
That doesn't mean that there can be no successful scanning at all with IPv6, but it needs to be highly targeted if you want results the same year, so just pumping random numbers in the destination address field like SQL slammer did so successfully doesn't cut it in IPv6.
So maybe said scanning won't take down LANs anymore. Adrian
On Tue, 18 Dec 2007 12:14:52 +0100 Iljitsch van Beijnum <iljitsch@muada.com> wrote:
On 18 dec 2007, at 6:37, Steven M. Bellovin wrote:
In a slightly more realistic vein, a huge address space makes life harder for scanning worms. As Angelos Keromytis, Bill Cheswick, and I have pointed out, "harder" is by no means equivalent to "impossible", but the myth, new as it is, still propagates.
I'd say that the huge address space makes life impossible for scanning worms.
Right, by simple arithmetic.
That doesn't mean that there can be no successful scanning at all with IPv6, but it needs to be highly targeted if you want results the same year, so just pumping random numbers in the destination address field like SQL slammer did so successfully doesn't cut it in IPv6.
See http://www.cs.columbia.edu/~smb/papers/v6worms.pdf --Steve Bellovin, http://www.cs.columbia.edu/~smb
On Tue, 18 Dec 2007 12:14:52 +0100 Iljitsch van Beijnum <iljitsch@muada.com> wrote:
I'd say that the huge address space makes life impossible for scanning worms.
Perhaps for random address scanning, but certainly not for scanning worms generally. In addition to the paper Steve Bellovin provided a link to, consider how many vulnerabilities are in the app compared to the stack and raw listeners these days. Miscreants know how to progamatically feed a list of search terms to the search engines and parse the results. There are a lot of vulnerable web apps out there and they are actively being scanned, tested and exploited. Plugging the words 'rfi' and 'scanner' into a search engine for further detail. John
Apparently, from what I have gathered from other french people, Free has rolled out a variation of 6to4 using their own prefix instead of the well known 2002::/16. As they control their home gateway, this was fairly easy for them to do and did not require much core infrastructure change. The apparent benefit is that they control the routing of the return packets and thus do not need to worry about packets going through Palo Alto, Switzerland or Korea (well known 6to4 relays) on their way back from the 'native' IPv6 Internet... - Alain. On 12/17/07 1:01 PM, "Sean Siler" <Sean.Siler@microsoft.com> wrote:
In a recent Slashdot article (http://slashdot.org/articles/07/12/17/1451230.shtml) discussing IPv6, someone left a comment the read, in part "One of the largest IPSs (sic) in Europe turned on IPv6 to all 8 million users this week. They've done the right thing and made it opt-in for now, their customers have to go to their control panel web page and turn it on, but almost 50,000 people did in the first 24 hours."
Does anyone know which ISP the poster is talking about? Is there any truth to this at all?
Any feedback appreciated.
Sean Siler IPv6 Program Manager Microsoft
On 17/12/2007, Alain Durand <alain_durand@cable.comcast.com> wrote:
Apparently, from what I have gathered from other french people, Free has rolled out a variation of 6to4 using their own prefix instead of the well known 2002::/16. As they control their home gateway, this was fairly easy for them to do and did not require much core infrastructure change.
There is an French ISP named Nerim who provides native IPv6 connexions on xDSL links and dial-up (not much used) since 2002-2003. Mostly everything from servers and core network is dual stack, and while the ISP is not as large as today's Free.fr, it was the third DSL operator in France by then. XS4All (Netherlands) is providing the same service if I correctly remember. -- Vassili Tchersky vasily@chersky.ru
Vassili Tchersky wrote: [..]
XS4All (Netherlands) is providing the same service if I correctly remember.
They used to have a product called "PowerDSL", which did IPv6 over PPPv6, but apparently due to changes in the infra they had to drop this. XS4all does still, since about 2001 or so, provide a tunnelbroker to their own users. Every user can simply go to the service.xs4all.nl site, and view/modify their tunnel + subnet configuration there. Only static tunnels are supported though (at least this is afaik). Greets, Jeroen
On Tue, Dec 18, 2007 at 10:09:16AM +0100, Jeroen Massar wrote:
Vassili Tchersky wrote: [..]
XS4All (Netherlands) is providing the same service if I correctly remember.
They used to have a product called "PowerDSL", which did IPv6 over PPPv6, but apparently due to changes in the infra they had to drop this. XS4all does still, since about 2001 or so, provide a tunnelbroker to their own users. Every user can simply go to the service.xs4all.nl site, and view/modify their tunnel + subnet configuration there. Only static tunnels are supported though (at least this is afaik).
It's kind of interesting that from 2001ish to current day and there is still only a handful of service providers worldwide that seem to offer *any* kind of support for IPv6. After all the propaganda, is there actually any other major deployments in the IPv6 space?
From the ipv6.org web site, I see "Most of today's internet uses IPv4, which is now nearly twenty years old." - read as it works well!
" IPv4 has been remarkably resilient in spite of its age, but it is beginning to have problems." - Really? Every network I know using IPv4 still works as designed. "Most importantly, there is a growing shortage of IPv4 addresses, which are needed by all new machines added to the Internet." - I'm sure there's a lot more ways around this - and I'm sure the NANOG archives have a lot of thought food there. "It also adds many improvements to IPv4 in areas such as routing and network autoconfiguration." - I would really love to know what these are that DHCP etc doesn't already do. I tried to check out the FAQ at http://faq.v6.wide.ad.jp/ but it wasn't reachable - maybe it needs IPv6 connectivity? As for routing 'improvements', doesn't more address space just give us more routes to handle? "IPv6 is expected to gradually replace IPv4, with the two coexisting for a number of years during a transition period." - so this 'transition period' has been, what, 7 years so far? I'm still predicting that it'll be at least another 10 years before IPv6 amounts to much... On a side note, does anyone currently have issues getting new address space where it's operationally required? I don't know anyone first hand who has yet to come across this issue... -- Steven Haigh Email: netwiz@crc.id.au Web: http://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897 C:\WINDOWS C:\WINDOWS\GO C:\PC\CRAWL
Steven Haigh wrote:
On Tue, Dec 18, 2007 at 10:09:16AM +0100, Jeroen Massar wrote:
Vassili Tchersky wrote: [..]
XS4All (Netherlands) is providing the same service if I correctly remember. They used to have a product called "PowerDSL", which did IPv6 over PPPv6, but apparently due to changes in the infra they had to drop this. XS4all does still, since about 2001 or so, provide a tunnelbroker to their own users. Every user can simply go to the service.xs4all.nl site, and view/modify their tunnel + subnet configuration there. Only static tunnels are supported though (at least this is afaik).
It's kind of interesting that from 2001ish to current day and there is still only a handful of service providers worldwide that seem to offer *any* kind of support for IPv6.
After all the propaganda, is there actually any other major deployments in the IPv6 space?
I wonder how your Martian hands look like, they must have many many fingers. For a list of ISP's doing IPv6 check: http://www.sixxs.net/faq/connectivity/?faq=native For a long long list of Japanese providers see: http://www.ipv6style.jp/en/statistics/services/index.shtml As for all the ISP's who have received and are at least routing, check GRH (http://www.sixxs.net/tools/grh/)
From the ipv6.org web site, I see "Most of today's internet uses IPv4, which is now nearly twenty years old." - read as it works well!
That site is IMHO always quite out of date unfortunately. Greets, Jeroen
* Jeroen Massar:
For a list of ISP's doing IPv6 check: http://www.sixxs.net/faq/connectivity/?faq=native
Does PPPv6 still work on the T-DSL platform? 8-/ The list would be more convincing if it contained links to product pages. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
* Sebastian Abt:
* Florian Weimer wrote:
Does PPPv6 still work on the T-DSL platform? 8-/
Yes, it does.
Oh. What happened to the C10K PPPoE length field bug (CSCsd13298, if I'm not mistaken)? -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
* Florian Weimer wrote:
Oh. What happened to the C10K PPPoE length field bug (CSCsd13298, if I'm not mistaken)?
I got told that DT has updated most (if not all, dunno) of their C10k's to newer IOS versions having this bug fixed. This actually does match with our experience as we haven't had complaints about IPv6 issues for quite some time now. sebastian -- SABT-RIPE PGPKEY-D008DA9C
Sebastian Abt schrieb:
* Florian Weimer wrote:
Does PPPv6 still work on the T-DSL platform? 8-/
Yes, it does.
"sometimes, and sometimes not" would be more correct :-) -- ======================================================================== = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ========================================================================
Florian Weimer wrote:
* Jeroen Massar:
For a list of ISP's doing IPv6 check: http://www.sixxs.net/faq/connectivity/?faq=native
Does PPPv6 still work on the T-DSL platform? 8-/
From what I understand it depends on the router/dslam/whateverthingy one gets connected to. Some do, some don't is what I gathered.
The list would be more convincing if it contained links to product pages.
Unfortunately not available for all of them. If folks have references/updates/addons etc of course don't hesitate to submit them, I'll be more than happy to list them. Greets, Jeroen
On Tue, Dec 18, 2007 at 12:06:48PM +0100, Florian Weimer wrote:
* Jeroen Massar:
For a list of ISP's doing IPv6 check: http://www.sixxs.net/faq/connectivity/?faq=native
Does PPPv6 still work on the T-DSL platform? 8-/
The list would be more convincing if it contained links to product pages.
You likely want to look at this page: http://www.sixxs.net/faq/connectivity/?faq=ipv6transit This is the page that has those that are doing native that are reasonably major service providers. -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Date: Tue, 18 Dec 2007 11:30:55 -0500 From: Jared Mauch <jared@puck.nether.net> Sender: owner-nanog@merit.edu
On Tue, Dec 18, 2007 at 12:06:48PM +0100, Florian Weimer wrote:
* Jeroen Massar:
For a list of ISP's doing IPv6 check: http://www.sixxs.net/faq/connectivity/?faq=native
Does PPPv6 still work on the T-DSL platform? 8-/
The list would be more convincing if it contained links to product pages.
You likely want to look at this page:
http://www.sixxs.net/faq/connectivity/?faq=ipv6transit
This is the page that has those that are doing native that are reasonably major service providers.
Note that sixxs only deals with commercial providers. Many (most?) of the major research and education networks around the globe have done IPv6 in production for years. That includes ESnet, DREN, NREN and Internet2 in the US, CAnet in Canada, Geant/Dante in Europe and a number of national networks in Asia. At least ESnet has offered IPv6 as a production service for several years including DNS service. If you check the headers, you should see that this message started out via IPv6 and, if your mail host is IPv6 reachable, took IPv6 for the entire path. That said, while we provide IPv6 services, we see minimal traffic and have found that IPv6 is, at best, poorly supported by most vendors (excluding host OS vendors). Most hosts support IPv6 fairly well, but switching and routing equipment lacks many features for IPv6 that are present for IPv4 and system management and security products tend to be even worse. E.g. try SNMP access to your routers by IPv6 and you might find a few problems, depending on the vendor...and don't expect much help from the vendor. If you see IPv6 as a solution to the exhaustion of IPv4 space, take a look at http://www.civil-tongue.net/clusterf/. It may help at some point, but many of us see no clear way to get from here to there without massive growth in both the RIB and the FIB in the process. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
On Tue, 18 Dec 2007, Kevin Oberman wrote:
If you see IPv6 as a solution to the exhaustion of IPv4 space, take a look at http://www.civil-tongue.net/clusterf/. It may help at some point, but many of us see no clear way to get from here to there without massive growth in both the RIB and the FIB in the process.
I am actually more concerned with the CPE problem and how to make autoconfiguration work for end users. For instance, should we assign /64 to end users and have them do whatever they need (subnet to /80 if they need more than one network)? We need to provision routes in whatever routers connect to customers, which I guess is the FIB/RIB-problem mentioned above? Is there general agreement that IPv6 requires a router at the customer prem to scale (ISP doesn't want to know what the end user devices are)? Also, is it ok to statically assign /64 to end user or should end user be able to switch addresses (some like dynamic IPs because it's not persistant over time and like the "privacy" you get by changing IP all the time). I haven't been able to find a BCP regarding the end user equipment and how to configure it, does anyone have any pointers? -- Mikael Abrahamsson email: swmike@swm.pp.se
On Wed, 19 Dec 2007, Mikael Abrahamsson wrote:
On Tue, 18 Dec 2007, Kevin Oberman wrote:
If you see IPv6 as a solution to the exhaustion of IPv4 space, take a look at http://www.civil-tongue.net/clusterf/. It may help at some point, but many of us see no clear way to get from here to there without massive growth in both the RIB and the FIB in the process.
I am actually more concerned with the CPE problem and how to make autoconfiguration work for end users.
For instance, should we assign /64 to end users and have them do whatever they need (subnet to /80 if they need more than one network)? We need to provision routes in whatever routers connect to customers, which I guess is the FIB/RIB-problem mentioned above?
Is there general agreement that IPv6 requires a router at the customer prem to scale (ISP doesn't want to know what the end user devices are)? Also, is it ok to statically assign /64 to end user or should end user be able to switch addresses (some like dynamic IPs because it's not persistant over time and like the "privacy" you get by changing IP all the time).
In my opinion there is two type of users as usually ISP services are marketed: 1. Home user - not really interested in configuration of their devices - they just want Internet (now IPv4, soon IPv4 and IPv6) connectivity: They generaly don't use more than one LAN internally. All their devices are connected either directly to ISP device or to the home-gateway purchased at the cornet. In this case the /64 with autoconfiguration is the best option. User don't have to configure anything (may be enabling IPv6 on their computers). 2. Power users/business users - they can configure their devices, and they want measured and reported SLAs. If they want IPv6 they can articulate their needs: /64, /60, /56, or /48 with prioritisation, filtering and other business needs. In this case DHCPv6 prefix delegation seems to be the most flexible solution. Since they can configure basic things on their device. The ISP can help them and negotiate accordingly... In my opinion 99% of the users belongs to the home user category. However I think 80% the IPv6 traffic volume will be generated by power/business users.
I haven't been able to find a BCP regarding the end user equipment and how to configure it, does anyone have any pointers?
There is a draft that starts addressing the CPE problem available at: http://tools.ietf.org/html/draft-ietf-v6ops-cpe-simple-security-00 If you think you can contribute, IETF v6ops welcomes you. Best Regards, Janos Mohacsi
Mohacsi Janos wrote: [..]
In my opinion there is two type of users as usually ISP services are marketed:
1. Home user - not really interested in configuration of their devices - they just want Internet (now IPv4, soon IPv4 and IPv6) connectivity: They generaly don't use more than one LAN internally. All their devices are connected either directly to ISP device or to the home-gateway purchased at the cornet. In this case the /64 with autoconfiguration is the best option. User don't have to configure anything (may be enabling IPv6 on their computers).
This would force these places to: a) use bridging to get that single /64 onto their network thus making firewalling really difficult. b) get a 'power users' abo, which would thus make people have to PAY for getting more IP addresses. ISP's are paying their transits by paying for the *BANDWIDTH* usage. So why don't ISP's have a couple of classes (to keep it simple) which are like eg: 10Gb account 50Gb account 100Gb account This would also solve the "Those stupid users are torrenting" problem, as they are PAYING for the traffic and other costs that you actually have. Don't charge for IP addresses, charge for *BANDWIDTH* usage. If I have 200 devices on the network which don't do a thing (maybe they are light bulbs or it is my fridge) I will do much less traffic than one single user who is trying to complete his nature movie collection.
2. Power users/business users - they can configure their devices, and they want measured and reported SLAs. If they want IPv6 they can articulate their needs: /64, /60, /56, or /48 with prioritisation, filtering and other business needs. In this case DHCPv6 prefix delegation seems to be the most flexible solution. Since they can configure basic things on their device. The ISP can help them and negotiate accordingly...
Scratching the 'power users' concept, as they belong in the above home user part, I agree. Greets, Jeroen
On Wed, 19 Dec 2007, Jeroen Massar wrote:
Mohacsi Janos wrote: [..]
In my opinion there is two type of users as usually ISP services are marketed:
1. Home user - not really interested in configuration of their devices - they just want Internet (now IPv4, soon IPv4 and IPv6) connectivity: They generaly don't use more than one LAN internally. All their devices are connected either directly to ISP device or to the home-gateway purchased at the cornet. In this case the /64 with autoconfiguration is the best option. User don't have to configure anything (may be enabling IPv6 on their computers).
This would force these places to: a) use bridging to get that single /64 onto their network thus making firewalling really difficult.
I am not quite sure. My colleague tested NetScreen box with /64 advertised from LNS. It seems to be working.
b) get a 'power users' abo, which would thus make people have to PAY for getting more IP addresses.
They aready do it. In Hungary, if you are home user you can have 1 single IPv4 address. If you are a business customer, then your can have an address space allocated from your provider. You pay more if you need bigger address block.... Best Regards,
On Dec 19, 2007 6:19 AM, Mohacsi Janos <mohacsi@niif.hu> wrote:
b) get a 'power users' abo, which would thus make people have to PAY for getting more IP addresses.
They aready do it. In Hungary, if you are home user you can have 1 single IPv4 address. If you are a business customer, then your can have an address space allocated from your provider. You pay more if you need bigger address block....
also for Comcast and Cox (I believe) in the US and Verizon (I know) you aren't paying for 'ip addresses' but for 'management of/change-request-for ip addresses'... which is a scam since in any of these cases they update their 'radius' server (dhcp/radius/blah) once and everything's done. hurah!
Mohacsi Janos wrote:
This would force these places to: a) use bridging to get that single /64 onto their network thus making firewalling really difficult.
I am not quite sure. My colleague tested NetScreen box with /64 advertised from LNS. It seems to be working.
If you are routing the /64, thus that it exists entirely on the clien-side, then it should work, but if you are allocating 1 single /64 to the customer, and eg keeping ::1 as the ISP side, then you have to do weird magic to make that work.
b) get a 'power users' abo, which would thus make people have to PAY for getting more IP addresses.
They aready do it. In Hungary, if you are home user you can have 1 single IPv4 address. If you are a business customer, then your can have an address space allocated from your provider. You pay more if you need bigger address block....
That is IPv4 and seems to be the case in general for IPv4. That mentality needs to be stopped for IPv6. When an ISP is not going to provide /48's to endusers then RIPE NCC should revoke the IPv6 prefix they received as they are not following the reasons why they received the prefix for. Greets, Jeroen
They aready do it. In Hungary, if you are home user you can have 1 single IPv4 address. If you are a business customer, then your can have an address space allocated from your provider. You pay more if you need bigger address block....
That is IPv4 and seems to be the case in general for IPv4. That mentality needs to be stopped for IPv6.
When an ISP is not going to provide /48's to endusers then RIPE NCC should revoke the IPv6 prefix they received as they are not following the reasons why they received the prefix for.
Agreed. But you have to explain old telco chaps who like charging for phone number blocks.... Regards, Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882
On 19 Dec 2007, at 21:31, Jeroen Massar wrote: [...]
When an ISP is not going to provide /48's to endusers then RIPE NCC should revoke the IPv6 prefix they received as they are not following the reasons why they received the prefix for.
They received the prefix because they had a plan. That's all, a plan. Not a promise. Robert Burns words ring very true to me and probably others, too: The best laid schemes o' mice an' men gang aft a-gley Regards, Leo
Leo Vegoda wrote:
On 19 Dec 2007, at 21:31, Jeroen Massar wrote:
[...]
When an ISP is not going to provide /48's to endusers then RIPE NCC should revoke the IPv6 prefix they received as they are not following the reasons why they received the prefix for.
They received the prefix because they had a plan. That's all, a plan. Not a promise.
It is not a plan, it is justification. The 200-rule has been taken out of the allocation already. And based on the x customers times /48, they justified that they will need a /20 or something else. As such when they are going to give out /56's, they suddenly need 256 times as many customers and unless they are going to grow insanely (for a /32 from ~60k to 15m customers) they won't be able to justify their address space anymore. As such, keep it simple folks, just pass out /48's. Greets, Jeroen
On 23 Dec 2007, at 20:34, Jeroen Massar wrote: [...]
When an ISP is not going to provide /48's to endusers then RIPE NCC should revoke the IPv6 prefix they received as they are not following the reasons why they received the prefix for.
They received the prefix because they had a plan. That's all, a plan. Not a promise.
It is not a plan, it is justification. The 200-rule has been taken out of the allocation already.
Right. But circumstances change.
And based on the x customers times /48, they justified that they will need a /20 or something else. As such when they are going to give out /56's, they suddenly need 256 times as many customers and unless they are going to grow insanely (for a /32 from ~60k to 15m customers) they won't be able to justify their address space anymore.
One issue ISPs with very large IPv6 allocations may be thinking about is that additional allocations are always based on the policies in place when they make their request, not the policies in place when they received their initial allocation. If the policy has become more conservative since the allocation was made there is a chance that the plan that justified the initial allocation will need to be modified to take account of the changed policy. In other words, an allocation that was made based on an ISPs needs for just the next few years might have to last considerably longer. The alternative could be the ISP finding its efficiency is too low to justify the extra block it has requested. So I won't be too surprised if I see some ISPs assigning some /56s when their original plans were only for /48 assignments. Regards, Leo
On 19 dec 2007, at 10:16, Mikael Abrahamsson wrote:
I am actually more concerned with the CPE problem and how to make autoconfiguration work for end users.
For instance, should we assign /64 to end users and have them do whatever they need (subnet to /80 if they need more than one network)?
Subnets that aren't /64 don't support autonegotiation so you can't really subnet a /64 in practice. This means that you should probably give your customers something bigger, like a /64, a /56 or even a /48. (Yes, we have enough address space for a /48 per customer.) The tricky part is provisioning a subnet to a customer. There is a good protocol for that: DHCPv6 prefix delegation. But there aren't any CPEs on the market that support this. (If it wasn't for Apple's Airport Extreme base station and a few somewhat expensive and hard to configure Cisco boxes you could argue that there aren't any IPv6- capable CPEs commercially available in the first place.)
We need to provision routes in whatever routers connect to customers, which I guess is the FIB/RIB-problem mentioned above?
Don't think so. As long as you don't let your customers take their address space with them when they move you can aggregate customer space in your network (you can even waste some address space for that without complaints from ARIN) so in practice your IPv6 routing tables will probably be smaller than their IPv4 counterparts.
Is there general agreement that IPv6 requires a router at the customer prem to scale (ISP doesn't want to know what the end user devices are)?
The alternative is having your device act as the default gateway in your customer's LAN, which more or less means you need to have a separate subnet/VLAN per customer, which is usually not the best way to go in larger setups. Don't expect to be doing much with DHCP for IPv6, though, most stuff that's out there today doesn't support it and you still need router advertisements because DHCPv6 doesn't tell you your default gateway.
Also, is it ok to statically assign /64 to end user or should end user be able to switch addresses (some like dynamic IPs because it's not persistant over time and like the "privacy" you get by changing IP all the time).
Customers can already randomize the lower 64 bits of their address so there is some level of privacy. In a prefix delegation system I would probably make things such that customers get the same addresses for some time (a few months) but I get to change their prefix if/when I want to.
I haven't been able to find a BCP regarding the end user equipment and how to configure it, does anyone have any pointers?
Unfortunately, there is no industry-wide consensus on how CPEs and ISP equipment should interact for IPv6, so it's probably not possible at this point in time to make a CPE that will completely autoconfigure unless you stick to 6to4 tunneling which gets the job done but is less than optimal because it needs public gateways.
On Wed, 19 Dec 2007, Iljitsch van Beijnum wrote:
customers something bigger, like a /64, a /56 or even a /48. (Yes, we have enough address space for a /48 per customer.)
The good part about using /48 is that it gives customers an even : boundry for their space. Apart from that, I think /56 is a better idea (or perhaps even a /60). Good point there about autoconfiguration, subnetting using less than /64 is probably a bad idea. So, out of our /32, if we assign each customer a /48 we can only support 65k customers. So in order to support millions of customers, we need a new allocation and I would really like for each new subnet allocated to be very much larger so we in the forseeable future don't need to get a newer one. So for larger ISPs with millions of customers, next step after /32 should be /20 (or in that neighborhood). Does RIPE/ARIN policy conform to this, so we don't end up with ISPs themselves having tens of aggregates (we don't need to drive the default free FIB more than what's really needed). Other option is to have more restrictive assignments to end users and therefore save on the /32, but that might be bad as well (long term). -- Mikael Abrahamsson email: swmike@swm.pp.se
On 19 Dec 2007, at 11:58, Mikael Abrahamsson wrote:
So, out of our /32, if we assign each customer a /48 we can only support 65k customers. So in order to support millions of customers, we need a new allocation and I would really like for each new subnet allocated to be very much larger so we in the forseeable future don't need to get a newer one. So for larger ISPs with millions of customers, next step after /32 should be /20 (or in that neighborhood). Does RIPE/ARIN policy conform to this, so we don't end up with ISPs themselves having tens of aggregates (we don't need to drive the default free FIB more than what's really needed).
From the RIPE perspective, there are seven "empty" /32s between my / 32 and the next allocation. I imagine this is fully intentional, and allows the NCC to grow my v6 address pool, without growing my footprint in the v6 routing table. Andy
Changing subject for these replies which will definitely be a bit on the quite mean side... no offense but start reading for once. Next to that there are also LIR courses which cover all of this. (see other mail for /56 for end-user-sites, /48 for end-business-sites) Mikael Abrahamsson wrote: [..]> So, out of our /32, if we assign each customer a /48 we can only
support 65k customers.
Can I read from this that you never actually read any of the $RIR policy documentation about getting IPv6 address space even though you did request a /32 before, clearly without thinking about it?
So in order to support millions of customers, we need a new allocation
"new" as in "We already have one, but we actually didn't really know what we where requesting, now we need more" and I would really like for each new subnet allocated to
be very much larger so we in the forseeable future don't need to get a newer one. So for larger ISPs with millions of customers, next step after /32 should be /20 (or in that neighborhood). Does RIPE/ARIN policy conform to this, so we don't end up with ISPs themselves having tens of aggregates (we don't need to drive the default free FIB more than what's really needed).
This explains quite a bit why people are looking so weird when certain other organizations get a /20 and upward from $RIR. My suggestion: start reading.
Other option is to have more restrictive assignments to end users and therefore save on the /32, but that might be bad as well (long term).
That would be stupid and totally against the idea of IPv6. Andy Davidson wrote: [..]
From the RIPE perspective, there are seven "empty" /32s between my /32 and the next allocation.
I imagine this is fully intentional, and allows the NCC to grow my v6 address pool, without growing my footprint in the v6 routing table.
That is exactly what it is for. Then again, if you actually had *PLANNED* your address space like you are supposed to when you make a request you could have already calculated how much address space you really needed and then justify it to the $RIR. In case you have to go back to ask the $RIR for more you already made a mistake while doing the initial request... Greets, Jeroen
On 19 Dec 2007, at 12:24, Jeroen Massar wrote:
Andy Davidson wrote: [..]
From the RIPE perspective, there are seven "empty" /32s between my /32 and the next allocation. I imagine this is fully intentional, and allows the NCC to grow my v6 address pool, without growing my footprint in the v6 routing table. That is exactly what it is for. Then again, if you actually had *PLANNED* your address space like you are supposed to when you make a request you could have already calculated how much address space you really needed and then justify it to the $RIR. In case you have to go back to ask the $RIR for more you already made a mistake while doing the initial request...
With respect, Jeroen, because I did *PLAN* (your emphasis) our organisational requirements, this is precisely the reason why I think it's significant that a lot of space was left unallocated following my allocation. My RIR only asked me to *PLAN* two years in advance (see ripe-414 [footnote 0]), though prudent organisations may plan for longer. I thought it was significant (and good) to note that they are allow me room to grow sometime after that period. If you offer the sweeping statement that anyone who ever needs to go back to the RIR for more space has made a 'mistake' with their requirement planning shows you're only thinking in an incredibly short term manner. Unless, of course, you are only used to working in companies which do not grow. :-) --- [0] #[IPv6 ALLOCATION USAGE PLAN]# % % When will you use this address space? % % Subnet Within Within Within % size (/nn) 3 months 1 year 2 years Purpose subnet: subnet:
On Wed, 19 Dec 2007, Jeroen Massar wrote:
Can I read from this that you never actually read any of the $RIR policy documentation about getting IPv6 address space even though you did request a /32 before, clearly without thinking about it?
I never requested IPv6 space personally. I work with routing, not with LIR administration. I also know that RIR people don't work with routing, and it shows.
"new" as in "We already have one, but we actually didn't really know what we where requesting, now we need more"
We got our current block in 2000 (or earlier, I don't know for sure, but 2000 at the latest). So yes, we didn't know what we were doing back then. Then again, I'd say nobody knew back then.
That is exactly what it is for. Then again, if you actually had *PLANNED* your address space like you are supposed to when you make a request you could have already calculated how much address space you really needed and then justify it to the $RIR. In case you have to go back to ask the $RIR for more you already made a mistake while doing the initial request...
The world tends to change in 7 years. You seem to like bashing people for not knowing future policy and changes 7 year ahead of time, which I think it quite sad. -- Mikael Abrahamsson email: swmike@swm.pp.se
On Dec 19, 2007 5:03 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
On Wed, 19 Dec 2007, Jeroen Massar wrote:
"new" as in "We already have one, but we actually didn't really know what we where requesting, now we need more"
We got our current block in 2000 (or earlier, I don't know for sure, but 2000 at the latest). So yes, we didn't know what we were doing back then. Then again, I'd say nobody knew back then.
I'd say it's fair to bet that quite a few folks in all regions pursued ipv6 allocations more than 3-5 years ago when the policy was essentially '/32 per provider, simply show a business plan for providing services to 200+ customers in the next N years' (without much in the way of planning or proof-of-planning).
That is exactly what it is for. Then again, if you actually had *PLANNED* your address space like you are supposed to when you make a request you could have already calculated how much address space you really needed and then justify it to the $RIR. In case you have to go back to ask the $RIR for more you already made a mistake while doing the initial request...
The world tends to change in 7 years. You seem to like bashing people for not knowing future policy and changes 7 year ahead of time, which I think it quite sad.
in the case of allocation policy for ipv6 things have changed significantly in the last 2-3 years certainly. It's probably also important to look further in the future than the current RIR policy decision process requires. ARIN/RIPE (atleast) have a 2 year planning horizon for LIR allocations, this isn't sufficient for ipv6 which is supposed to last significantly longer and be as limited in prefix/entity as possible. Some large providers are attempting to plan 5-10 years out for address policy if possible, not everyone has that luxury, but in the end we (internet routing community) want limited prefixes/org that means planning horizons have to be adjusted up from 2yrs to <something else>. -Chris
Christopher Morrow wrote:
On Dec 19, 2007 5:03 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
On Wed, 19 Dec 2007, Jeroen Massar wrote:
"new" as in "We already have one, but we actually didn't really know what we where requesting, now we need more" We got our current block in 2000 (or earlier, I don't know for sure, but 2000 at the latest). So yes, we didn't know what we were doing back then. Then again, I'd say nobody knew back then.
I'd say it's fair to bet that quite a few folks in all regions pursued ipv6 allocations more than 3-5 years ago when the policy was essentially '/32 per provider, simply show a business plan for providing services to 200+ customers in the next N years' (without much in the way of planning or proof-of-planning).
HD ratio and all related documentations have existed for quite some time already. If they would have read the docs they would have understood what it meant and also gotten the reason why they asked for the 200+ rule in the first place.
[..] Some large providers are attempting to plan 5-10 years out for address policy if possible, not everyone has that luxury, but in the end we (internet routing community) want limited prefixes/org that means planning horizons have to be adjusted up from 2yrs to <something else>.
I can fully agree with this and it is definitely something that one might want to push into the RIRs. I actually hope that most ISP's do realize that they might become a bit larger in a few years, fortunately there is the 7 adjacent /32's that can be used for sizing up quite a bit. The only thing then is to hope that only the aggregate ends up in BGP. Greets, Jeroen
Mikael Abrahamsson wrote: [..]
The world tends to change in 7 years. You seem to like bashing people for not knowing future policy and changes 7 year ahead of time, which I think it quite sad.
Not intended that way. What I was really surprised, and critical, of though is you mentioning that you say "So, out of our /32, if we assign each customer a /48 we can only support 65k customers. So in order to support millions of customers, we need a new allocation", which I read as "We got a /32 recently, but never thought that we should give /48's to endsites". Changes the interpretation quite a bit. But even in 2000 the policy was and still is: /128 for really a single device /64 if you know for sure that only one single subnet will ever be allocated. /48 for every other case (smart bet, should be used per default) As such, if you have near 60k customers then you should already have realized that you needed more than a /32, especially as you can then also guess that in a couple of years it will be quite a bit more. For the longer term, I guess 7 years might fall into that by now, thus if you got a /32 in 2000 and you had 10k customers then you should be fine. If you already had 200k customers or so and then only requested a /32 though I think one can definitely state you made a big booboo. Andy Davidson wrote: [..]
With respect, Jeroen, because I did *PLAN* (your emphasis) our organisational requirements, this is precisely the reason why I think it's significant that a lot of space was left unallocated following my allocation.
Correct, that is a good thing.
My RIR only asked me to *PLAN* two years in advance (see ripe-414 [footnote 0]), though prudent organisations may plan for longer. I thought it was significant (and good) to note that they are allow me room to grow sometime after that period.
Nothing wrong there indeed and you should indeed at least plan for two years and probably more, when adding HD ratio and some prospects one should easily come up with a pretty good ballpark figure of clients that you will be having. Unless you will suddenly in a year grow by 60k clients (might happen) or really insanely with other large amounts your initial planning should hold up for quite some while
If you offer the sweeping statement that anyone who ever needs to go back to the RIR for more space has made a 'mistake' with their requirement planning shows you're only thinking in an incredibly short term manner. Unless, of course, you are only used to working in companies which do not grow. :-)
As mentioned above, not the way I intended it to mean. Greets, Jeroen
On Wed, 19 Dec 2007, Jeroen Massar wrote:
you got a /32 in 2000 and you had 10k customers then you should be fine. If you already had 200k customers or so and then only requested a /32 though I think one can definitely state you made a big booboo.
From what I have been told by my colleagues, we actually received a /35 back then and the requirement was to have 200 end users, otherwise you basically couldn't receive a "PA" at all. This was then converted into a /32 at a later date, I guess due to a change in policy.
So my wondering is basically, if we say we have millions of end users right now and we want to give them a /56 each, and this is no problem, then the policy is correct. We might not have them all IPv6 activated in 2 years which is the RIR planning horizon. I do concur with other posters here that the planning horizon for IPv6 should be longer than three years so we get fewer prefixes in the DFZ as a whole. Then again, *RIR people don't care about routing so I am still sceptical about that being taken into account.
you will be having. Unless you will suddenly in a year grow by 60k clients (might happen) or really insanely with other large amounts your initial planning should hold up for quite some while
We grow by much more than 60k a year, it's just hard to plan for it. If we project for the highest amount of growth then we're most likely wasteful (in the case of IPv4 space anyway), if we project for lowest amount of growth then we get DFZ glut. We would also like to do regional IPv6 address planning since we're too often in the habit of (without much notice for the operational people) selling off part of the business. Then again, with a /32 we can support ~16 million residential end-users with /56 each, which I guess will be enough for a while. -- Mikael Abrahamsson email: swmike@swm.pp.se
So my wondering is basically, if we say we have millions of end users right now and we want to give them a /56 each, and this is no problem, then the policy is correct. We might not have them all IPv6 activated in 2 years which is the RIR planning horizon. I do concur with other posters here that the planning horizon for IPv6 should be longer than three years so we get fewer prefixes in the DFZ as a whole. Then again, *RIR people don't care about routing so I am still sceptical about that being taken into account.
So... I need to ask for some clarification here. What, exactly, do you mean by "RIR people"? Do you mean the staff at the RIR? In that case, you're right, sort of. They care about following the policies set by their respective constituent communities. In the case of ARIN, this would be essentially anyone who cares to participate. However, if people who care about routing choose to participate (which they seem to vigorously in ARIN), then, their views will be reflected in policy as a result (they certainly are, at least to some extent in the ARIN policies). Do you mean the RIR Boards, Advisory Councils, or other representative governing bodies? In that case, you're also partially right. They care about representing their community of users and the best fiduciary interests of the RIR. I don't know about the structure of the other RIRs, but, at least in the case of ARIN, the Advisory Council is definitely primarily concerned with shaping policy according to the consensus of the constituent community and the board is concerned with insuring that the AC is following the correct processes in policy adoption and the fiduciary best interests of ARIN as an organization. Do you mean the RIR end users and customers who receive address resources from the RIRs? In that case, I think, actually that most of them care a great deal about routing. Note, in these statements, I am speaking only as an individual, and, not as someone who was recently elected to a future term on the ARIN AC or on behalf of the AC in any way.
you will be having. Unless you will suddenly in a year grow by 60k clients (might happen) or really insanely with other large amounts your initial planning should hold up for quite some while
We grow by much more than 60k a year, it's just hard to plan for it. If we project for the highest amount of growth then we're most likely wasteful (in the case of IPv4 space anyway), if we project for lowest amount of growth then we get DFZ glut.
IPv6 needs a much longer time horizon than IPv4 in my opinion. If nothing else, I would say that you should be able to project your addressing needs for the next two years at least in the ball-park of continuing your previous growth trends. If you added 100k customers last year and 80k customers the year before, then, I think it's reasonable, especially in IPv6, to plan for 125k customer adds next year and 150k customer adds the following year. If you're figures turn out to be excessive, then, in two years when you'd normally have to apply for more space (I'd like to see this move to more like 5 for IPv6), you can skip that application until you catch up. No real problem for anyone in that case.
We would also like to do regional IPv6 address planning since we're too often in the habit of (without much notice for the operational people) selling off part of the business.
Heh... Then you should force the new owners to renumber.
Then again, with a /32 we can support ~16 million residential end- users with /56 each, which I guess will be enough for a while.
So split the difference and ask for a /28. Personally, I think /56s are plenty for most residential users. I'm a pretty serious residential end-user, and, I can't imagine I'd need more than a /56 in terms of address planning. However, I have a /48 because that's the smallest direct assignment available for my multihomed end-site. Owen
On Wed, 19 Dec 2007, Owen DeLong wrote:
Do you mean the staff at the RIR?
Do you mean the RIR Boards, Advisory Councils, or other representative governing bodies?
Both these. The few times I have ventured to start emailing on a policy wg emailing list, I have gotten the notion that people who habit these have no idea about operational reality of running an ISP. They also expect suggestions in a form that is quite academic and one that most likely nobody actually working operationally at an ISP will be able to produce (I found the email reply to me from Jeroen Massar to be right on the money what I expect in this context). Yes, I understand that if your life is to run an RIR, it's frustrating to have to interact with people that don't even use the correct terms and separate between allocations, delegations and assignments.
IPv6 needs a much longer time horizon than IPv4 in my opinion. If nothing else, I would say that you should be able to project your addressing needs for the next two years at least in the ball-park of continuing your previous growth trends. If you added 100k customers last year and 80k customers the year before, then, I think it's reasonable, especially in IPv6, to plan for 125k customer adds next year and 150k customer adds the following year.
Yes, so why does the RIRs still ask for a 2 year planning horizon for IPv6? Why isn't this 5 or 10 years? If we have plenty of addresses and hand out a /28 for each AS number present on the internet right now, that would be equivalent to each AS supporting 270M /56 customers but we would still only have used up /15 of the IPv6 address space. We would though have fairly well have made sure that more than 99% of ISPs will only ever need a single IPv6 PA block, hopefully making DFZ glut less in 10-15 years.
If you're figures turn out to be excessive, then, in two years when you'd normally have to apply for more space (I'd like to see this move to more like 5 for IPv6), you can skip that application until you catch up. No real problem for anyone in that case.
I don't want anyone to apply for more space later as this would normally mean a second route. If everybody needs to do this, then we'll add 40k routes to DFZ without any good reason.
So split the difference and ask for a /28. Personally, I think /56s are plenty for most residential users. I'm a pretty serious residential end-user, and, I can't imagine I'd need more than a /56 in terms of address planning. However, I have a /48 because that's the smallest direct assignment available for my multihomed end-site.
I agree, but with current policy, asking for a /28 means (afaik) that I have to claim to have 270M /56 customers in 2-5 years. That's a pretty bold statement. But I guess that we can just keep only telling lies to the RIRs to get our addresses, which has been the standard workaround. -- Mikael Abrahamsson email: swmike@swm.pp.se
But even in 2000 the policy was and still is: /128 for really a single device /64 if you know for sure that only one single subnet will ever be allocated. /48 for every other case (smart bet, should be used per default)
I believe this policy is changing. The new text is: "End Users are assigned an End Site assignment from their LIR or ISP. The size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (only one subnet is anticipated for the End Site)." RIPE Policy Proposal 2005-08 was accepted in November. http://www.ripe.net/ripe/policies/proposals/2005-08.html Andras
On 19 dec 2007, at 13:09, Andy Davidson wrote:
On 19 Dec 2007, at 11:58, Mikael Abrahamsson wrote:
So, out of our /32, if we assign each customer a /48 we can only support 65k customers. So in order to support millions of customers, we need a new allocation and I would really like for each new subnet allocated to be very much larger so we in the forseeable future don't need to get a newer one. So for larger ISPs with millions of customers, next step after /32 should be /20 (or in that neighborhood). Does RIPE/ARIN policy conform to this, so we don't end up with ISPs themselves having tens of aggregates (we don't need to drive the default free FIB more than what's really needed).
RIPE has been giving out _extremely_ large IPv6 blocks on occasion. I'm sure that the other RIRs will also give you a bigger block than / 32 if you expect to need more than that, so please don't limit what you give to your customers.
From the RIPE perspective, there are seven "empty" /32s between my / 32 and the next allocation.
I imagine this is fully intentional, and allows the NCC to grow my v6 address pool, without growing my footprint in the v6 routing table.
Unfortunately, they do this without there being a community-supported policy in place. IPv4 experience also shows that people rarely merge the adjoining space with the existing block when they get the extra space. So all this does is fragment the address space and make prefix length filters harder. This is really a very bad policy.
Kevin Oberman wrote: [..]
Note that sixxs only deals with commercial providers. Many (most?) of the major research and education networks around the globe have done IPv6 in production for years. That includes ESnet, DREN, NREN and Internet2 in the US, CAnet in Canada, Geant/Dante in Europe and a number of national networks in Asia.
Which is a well know fact and who have quite a limited set of end-sites who can actually connect to them, that is why these are not listed. Similarly it doesn't list hosting providers either, enabling a colo to do IPv6 should be childs play, getting it to the enduser though... ;)
That said, while we provide IPv6 services
You provide services and access, but which places are actually enabled to use it? That the network is there is one thing, this is the easy part, linking up the end-sites is the hard one. Greets, Jeroen
Date: Wed, 19 Dec 2007 13:28:35 +0100 From: Jeroen Massar <jeroen@unfix.org> Sender: owner-nanog@merit.edu
Kevin Oberman wrote: [..]
Note that sixxs only deals with commercial providers. Many (most?) of the major research and education networks around the globe have done IPv6 in production for years. That includes ESnet, DREN, NREN and Internet2 in the US, CAnet in Canada, Geant/Dante in Europe and a number of national networks in Asia.
Which is a well know fact and who have quite a limited set of end-sites who can actually connect to them, that is why these are not listed. Similarly it doesn't list hosting providers either, enabling a colo to do IPv6 should be childs play, getting it to the enduser though... ;)
I was not complaining. I just wanted to be sure that people were aware that thee are a LOT of users (including large numbers of researchers, educators, and especially students connected to IPv6 capable nets.
That said, while we provide IPv6 services
You provide services and access, but which places are actually enabled to use it? That the network is there is one thing, this is the easy part, linking up the end-sites is the hard one.
Actually, for ESnet, due to an government mandate, most end sites carry or very soon will carry IPv6. This still does not mean the end users are likely to use it or that there will be much traffic. The end sites tend to NOT talk to each other. the only exception is a couple of research facilities that use IPv6, but that still amounts to an immeasurably small amount of traffic over 10G links. Perhaps the single biggest issue with making web service IPv6 enabled is that doing so almost invariably leads to a drop in total access due to brokenness in the IPv6 Internet as well as applications that don't do the right thing way too often. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
doesn't more address space just give us more routes to handle?
No. It only makes more possible prefixes. Migrating to IPv6 while keeping the current (IPv4) routing and current business relations, there would be somewhat less routes: bigger address space -> bigger chunks -> less need to incrementally add prefixes to the same place -> less prefixes Andras
On Tue, Dec 18, 2007, JAKO Andras wrote:
doesn't more address space just give us more routes to handle?
No. It only makes more possible prefixes. Migrating to IPv6 while keeping the current (IPv4) routing and current business relations, there would be somewhat less routes:
bigger address space -> bigger chunks -> less need to incrementally add prefixes to the same place -> less prefixes
You mean "more address space" -> "individual businesses want to multihome and are willing to pay for their own space" -> more prefixes. Adrian
doesn't more address space just give us more routes to handle?
No. It only makes more possible prefixes. Migrating to IPv6 while keeping the current (IPv4) routing and current business relations, there would be somewhat less routes:
bigger address space -> bigger chunks -> less need to incrementally add prefixes to the same place -> less prefixes
You mean "more address space" -> "individual businesses want to multihome and are willing to pay for their own space" -> more prefixes.
These are different business relations. I know for sure that IPv6 allows us to keep the number of prefixes lower, assuming the current business relations. IPv6 may of course modify the business relations as you described, but I'm not smart enough to know for sure in advance whether that will happen or not. Andras
doesn't more address space just give us more routes to handle?
No. It only makes more possible prefixes. Migrating to IPv6 while keeping the current (IPv4) routing and current business relations, there would be somewhat less routes:
bigger address space -> bigger chunks -> less need to incrementally add prefixes to the same place -> less prefixes
You mean "more address space" -> "individual businesses want to multihome and are willing to pay for their own space" -> more prefixes. Every business that wants to multihome and can afford it already does. v6 isn't going to change that. v6 will allow more aggregation and a routing
table closer in size to the number of AS's, which is a significant reduction. It should also reduce the problem of route churn and non-convergence. Whether everyone will play nicely and make it work is a different story. -Don
participants (27)
-
Adrian Chadd -
Alain Durand -
Andy Davidson -
Christopher Morrow -
Christopher Morrow -
Danny McPherson -
Donald Stahl -
Florian Weimer -
Iljitsch van Beijnum -
JAKO Andras -
Jared Mauch -
Jeroen Massar -
John Kristoff -
Kevin Oberman -
Leo Vegoda -
Mikael Abrahamsson -
Mohacsi Janos -
Owen DeLong -
Randy Bush -
Roland Dobbins -
Sascha Lenz -
Sean Siler -
Sebastian Abt -
Steven Haigh -
Steven M. Bellovin -
Stuart Henderson -
Vassili Tchersky