DRAFT: RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6
Hello Address Policy Working Group, IPv6 Working Group, as announced yesterday on the APWG list, here's the first draft of the "we are going to tell the world what the RIPE community recommends regarding the end of IPv4 / advent of IPv6". The text has been drafted by the RIPE NCC, but the actual recommendation needs to come from "the community", so change whatever you think needs changing. Face-to-face discussion will take place in the APWG and IPv6 WG meeting on Thursday, October 25th. (Short discussion in APWG early morning, time to think about it during the day, final decision in the IPv6 WG meeting on Thursday afternoon). ----------------------- snip ----------------------- DRAFT - RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6 RIPE 55: 22 - 26 October 2007 The RIPE community resolves as follows: 1) At current allocation rates, the remaining pool of unallocated IPv4 address space is likely to be allocated within the next two to four years. Although the Internet will continue to function as normal after this point this event will have a significant influence on future network operations as well as IP address management and allocation policies. Therefore we recognise that the widespread deployment of IPv6 will be essential to sustain future growth of the Internet. 2) We urge network operators and Internet Service Providers (ISPs) to deploy IPv6 across their networks as soon as possible. This deployment must include providing IPv6 access to End Users and ensuring services are accessible by IPv6. 3) We recognise that the responsibility for creating policies related to the management of critical Internet resources in the RIPE NCC service region rests with the RIPE community and the proven success of the RIPE Policy Development Process (PDP). In recognition of this responsibility, we commit to continue development of effective policies for the responsible management of IPv4 and IPv6 address space. 4) We agree that this situation requires a committed effort from network operators, ISPs and the RIPE community. We urge that the widespread deployment of IPv6 be made a high priority. ----- End forwarded message ----- Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 122119 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
Hi, what about also urging the vendors to fully support IPv6 (like forwarding in hardware, increase functionality, you name it...)? Cheers, Florian -----Ursprüngliche Nachricht----- Von: ipv6-wg-admin@ripe.net [mailto:ipv6-wg-admin@ripe.net] Im Auftrag von Gert Doering Gesendet: Mittwoch, 17. Oktober 2007 17:29 An: address-policy-wg@ripe.net; ipv6-wg@ripe.net Betreff: [ipv6-wg] DRAFT: RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6 Hello Address Policy Working Group, IPv6 Working Group, as announced yesterday on the APWG list, here's the first draft of the "we are going to tell the world what the RIPE community recommends regarding the end of IPv4 / advent of IPv6". The text has been drafted by the RIPE NCC, but the actual recommendation needs to come from "the community", so change whatever you think needs changing. Face-to-face discussion will take place in the APWG and IPv6 WG meeting on Thursday, October 25th. (Short discussion in APWG early morning, time to think about it during the day, final decision in the IPv6 WG meeting on Thursday afternoon). ----------------------- snip ----------------------- DRAFT - RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6 RIPE 55: 22 - 26 October 2007 The RIPE community resolves as follows: 1) At current allocation rates, the remaining pool of unallocated IPv4 address space is likely to be allocated within the next two to four years. Although the Internet will continue to function as normal after this point this event will have a significant influence on future network operations as well as IP address management and allocation policies. Therefore we recognise that the widespread deployment of IPv6 will be essential to sustain future growth of the Internet. 2) We urge network operators and Internet Service Providers (ISPs) to deploy IPv6 across their networks as soon as possible. This deployment must include providing IPv6 access to End Users and ensuring services are accessible by IPv6. 3) We recognise that the responsibility for creating policies related to the management of critical Internet resources in the RIPE NCC service region rests with the RIPE community and the proven success of the RIPE Policy Development Process (PDP). In recognition of this responsibility, we commit to continue development of effective policies for the responsible management of IPv4 and IPv6 address space. 4) We agree that this situation requires a committed effort from network operators, ISPs and the RIPE community. We urge that the widespread deployment of IPv6 be made a high priority. ----- End forwarded message ----- Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 122119 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
I believe vendors will go where-ever their users show them the money. Create the demand, the offer will show up. Joao On 17 Oct 2007, at 17:39, Florian Frotzler wrote:
Hi,
what about also urging the vendors to fully support IPv6 (like forwarding in hardware, increase functionality, you name it...)?
Cheers, Florian
-----Ursprüngliche Nachricht----- Von: ipv6-wg-admin@ripe.net [mailto:ipv6-wg-admin@ripe.net] Im Auftrag von Gert Doering Gesendet: Mittwoch, 17. Oktober 2007 17:29 An: address-policy-wg@ripe.net; ipv6-wg@ripe.net Betreff: [ipv6-wg] DRAFT: RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6
Hello Address Policy Working Group, IPv6 Working Group,
as announced yesterday on the APWG list, here's the first draft of the "we are going to tell the world what the RIPE community recommends regarding the end of IPv4 / advent of IPv6".
The text has been drafted by the RIPE NCC, but the actual recommendation needs to come from "the community", so change whatever you think needs changing.
Face-to-face discussion will take place in the APWG and IPv6 WG meeting on Thursday, October 25th. (Short discussion in APWG early morning, time to think about it during the day, final decision in the IPv6 WG meeting on Thursday afternoon).
----------------------- snip -----------------------
DRAFT - RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6 RIPE 55: 22 - 26 October 2007
The RIPE community resolves as follows:
1) At current allocation rates, the remaining pool of unallocated IPv4 address space is likely to be allocated within the next two to four years. Although the Internet will continue to function as normal after this point this event will have a significant influence on future network operations as well as IP address management and allocation policies. Therefore we recognise that the widespread deployment of IPv6 will be essential to sustain future growth of the Internet.
2) We urge network operators and Internet Service Providers (ISPs) to deploy IPv6 across their networks as soon as possible. This deployment must include providing IPv6 access to End Users and ensuring services are accessible by IPv6.
3) We recognise that the responsibility for creating policies related to the management of critical Internet resources in the RIPE NCC service region rests with the RIPE community and the proven success of the RIPE Policy Development Process (PDP). In recognition of this responsibility, we commit to continue development of effective policies for the responsible management of IPv4 and IPv6 address space.
4) We agree that this situation requires a committed effort from network operators, ISPs and the RIPE community. We urge that the widespread deployment of IPv6 be made a high priority.
----- End forwarded message -----
Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 122119
SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner- Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
On 18-okt-2007, at 12:49, Joao Damas wrote:
I believe vendors will go where-ever their users show them the money. Create the demand, the offer will show up.
Same thing for the ISPs. And the content networks. All three of those are in the end paid by the end-user. But the end-user has no idea what IPv6 is and is certainly not going to spend extra money to get it. There is plenty of work to do elsewhere too, but the CPE issue is quickly becoming a significant hurdle. The reason for that is that those tend to run IPv4 NAT which makes easy IPv6 tunneling hard. We really need those boxes to support IPv6 in the near future. However, in order for that to work there must be a clear provisioning model between ISPs and end-users. A good way to do this with IPv6 is with DHCPv6 prefix delegation, but until pretty much everyone agrees it's hard to build a CPE that will do something reasonable with IPv6 out of the box.
Iljitsch van Beijnum wrote:
There is plenty of work to do elsewhere too, but the CPE issue is quickly becoming a significant hurdle.
On the contrary, the CPE issue has been a major problem for many years. It's simply one which has been ignored for far too long.
The reason for that is that those tend to run IPv4 NAT which makes easy IPv6 tunneling hard. We really need those boxes to support IPv6 in the near future.
This all comes down to economics. Adding IPv6 capabilities to CPE access devices costs money, and CPE devices are often chosen purely on the basis of cost alone. Ergo, IPv6 capability is bad for business, if you manufacture CPE boxen. The real problem here is the lifetime of CPE devices. I'm going to estimate a rough half-life of 3 years. This is going to mean an awful lot of CPE access device swapouts to move to teh ipv6 intarweb. Which brings things back to the access ISPs: all access ISPs should be encouraged in the strongest possible terms to deploy devices now which are ipv6 capable, or which can be upgraded to be ipv6 capable. This will put pressure on the manufacturers to introduce v6 boxes to the marketplace because there are almost no low-end units which will do ipv6 out of the box right now. For a laugh, or maybe a cry, check out: http://www.google.com/search?q=ipv6+%2Bsite%3Ahttp%3A%2F%2Fwww.netopia.com http://www.google.com/search?q=ipv6+%2Bsite%3Ahttp%3A%2F%2Fwww.belkin.com http://www.google.com/search?q=ipv6+%2Bsite%3Ahttp%3A%2F%2Fwww.netgear.com http://www.google.com/search?q=ipv6+%2Bsite%3Ahttp%3A%2F%2Fwww.2wire.com http://www.google.com/search?q=ipv6+%2Bsite%3Ahttp%3A%2F%2Fwww.draytek.com http://www.google.com/search?q=ipv6+%2Bsite%3Ahttp%3A%2F%2Fwww.linksys.com http://www.google.com/search?q=ipv6+%2Bsite%3Ahttp%3A%2F%2Fwww.zyxel.com read: "heuston, we have a problem" Nick -- Network Ability Ltd. | Head of Operations | Tel: +353 1 6169698 3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 Dublin 2, Ireland | Exchange Association | Email: nick@inex.ie
This all comes down to economics. Adding IPv6 capabilities to CPE access devices costs money, and CPE devices are often chosen purely on the basis of cost alone. Ergo, IPv6 capability is bad for business, if you manufacture CPE boxen.
IPv6 is a software upgrade. Most of these boxes can be flashed in the field and many of them are based on Linux or BSD, so in most cases it is only a matter of including and testing the IPv6 code that already exists.
The real problem here is the lifetime of CPE devices. I'm going to estimate a rough half-life of 3 years. This is going to mean an awful lot of CPE access device swapouts to move to teh ipv6 intarweb.
This means that if we can get manufacturers to include IPv6 during the next 12 months, then in 4 years, half the CPE will support IPv6 through pure attrition. That's not too bad. Once the kit is on the market, this schedule can be speeded up if required. Also, remember that IPv4 doesn't suddenly stop working. You could reasonably expect to leave most existing customers alone and only deal with CPE upgrades for the few that want to upgrade. The CPE manufacturers can move pretty quickly if they see a demand for IPv6. --Michael Dillon
michael.dillon@bt.com wrote:
IPv6 is a software upgrade.
Michael, you've got quite the talent for coming up with vacuous sound-bites like this. It is true that if: - you have an CPE device which is designed to be upgraded (lots of early CPE devices weren't) - the CPE device has enough flash and RAM to run ipv6 - there is actually an ipv6 capable image for your CPE device, which assumes that your CPE device is still supported by its manufacturer - this ipv6 upgrade image is stable enough for production use - you are clued in enough to be able to upgrade your CPE device - your ISP can afford the time to support the reconfiguration of your device via its support mechanism, ... then IPv6 is a software upgrade. If any of these is not true, you're way off into uncharted territory. Obviously, it's always going to be possible to buy your way out of this sort of problem, but how are you going to explain this to Joe and Jane Knucklehead who want teh intarweb for their kids' school projects, Jane's IM with her sister in OZ and Joe's late night pr0n sessions, and who have no knowledge whatever in any meaningful sense about what ipv6 is and how it could make their life any better, and that now they have to fork out €60 for another ADSL modem when their current one works just fine, thank you very much. Nick -- Network Ability Ltd. | Head of Operations | Tel: +353 1 6169698 3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 Dublin 2, Ireland | Exchange Association | Email: nick@inex.ie
It is true that if:
- you have an CPE device which is designed to be upgraded (lots of early CPE devices weren't) - the CPE device has enough flash and RAM to run ipv6 - there is actually an ipv6 capable image for your CPE device, which assumes that your CPE device is still supported by its manufacturer - this ipv6 upgrade image is stable enough for production use - you are clued in enough to be able to upgrade your CPE device - your ISP can afford the time to support the reconfiguration of your device via its support mechanism,
... then IPv6 is a software upgrade.
If any of these is not true, you're way off into uncharted territory.
Uncharted territory? How does "you continue to use IPv4 as before" become uncharted territory. If a customer's network does not support IPv6 for any reason, including CPE, then they just keep on using IPv4 as they always have done. They can still get to IPv6 resources that have installed appropriate adapters such as 6to4 relays or ALGs on the content providers network. When the IPv6 Internet is required to sustain business growth because there are no unused IPv4 addresses available, all the IPv4 network infrastructure will continue to work as it had before.
how are you going to explain this to Joe and Jane Knucklehead ... what ipv6 is and how it could make their life any better, and that now they have to fork out EUR60 for another ADSL modem when their current one works just fine, thank you very much.
It's easier than most engineers think. Ordinary people spend EUR60 every day for things that they find useful, such as a meal in a restaurant, new clothes. Experience has shown that they are not unhappy to pay that much money to replace an Internet gateway as long as it is old and there is some perceived benefit in the new one. Since a new one will support IPv6, is likely to have field-upgradeable software, and probably includes a better firewall and management interface, it will be easy to get them to pay for it. --Michael Dillon
* michael dillon:
This all comes down to economics. Adding IPv6 capabilities to CPE access devices costs money, and CPE devices are often chosen purely on the basis of cost alone. Ergo, IPv6 capability is bad for business, if you manufacture CPE boxen.
IPv6 is a software upgrade.
Including IPsec? Doubt it, some of the CPUs barely manage to run PPPoE.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Florian Weimer wrote:
* michael dillon:
This all comes down to economics. Adding IPv6 capabilities to CPE access devices costs money, and CPE devices are often chosen purely on the basis of cost alone. Ergo, IPv6 capability is bad for business, if you manufacture CPE boxen. IPv6 is a software upgrade.
Including IPsec? Doubt it, some of the CPUs barely manage to run PPPoE.
IPv6 can use without IPsec. Also, you can use IPsec without IPv6. I blame IPv6-advocates for adding "security" to the "feature list" for IPv6, in an attempt to make it more attractive. The only real feature IPv6 adds is more addresses. There are a few simplifications that you can make when you don't have to worry about running out of addresses, and these are part of IPv6. But security (and quality of service) is just as easy in IPv4 as in IPv6. - -- Shane -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHGGPtMsfZxBO4kbQRAp0UAKClQGfgNnZgRm3gCkeicErb9idnRwCgkI62 PXBXY5BC8BXBT8mGY/KCT2g= =QUMA -----END PGP SIGNATURE-----
On 18-okt-2007, at 21:26, Florian Weimer wrote:
IPv6 is a software upgrade.
Including IPsec? Doubt it, some of the CPUs barely manage to run PPPoE.
Since when are IPv6 routers required to do IPsec processing?
Iljitsch van Beijnum wrote:
Since when are IPv6 routers required to do IPsec processing?
December 1995 - please see rfc1883 and rfc2640, section 4:
A full implementation of IPv6 includes implementation of the following extension headers: [...] Authentication Encapsulating Security Payload
The first four are specified in this document; the last two are specified in [RFC-2402] and [RFC-2406], respectively.
Nick -- Network Ability Ltd. | Head of Operations | Tel: +353 1 6169698 3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 Dublin 2, Ireland | Exchange Association | Email: nick@inex.ie
On 19-okt-2007, at 11:04, Nick Hilliard wrote:
Since when are IPv6 routers required to do IPsec processing?
December 1995 - please see rfc1883 and rfc2640, section 4:
A full implementation of IPv6 includes implementation of the following extension headers:
Two can play the RFC quoting game (2460): With one exception, extension headers are not examined or processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header.
Hi, On Fri, Oct 19, 2007 at 03:30:38PM +0200, Iljitsch van Beijnum wrote:
Two can play the RFC quoting game (2460):
There's a certain fun value to watch your "I can quote more interesting things from the RFC" game - but: ** can we please try to focus on "do we want to issue this resolution, ** and if yes, which words need changing"? Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 122119 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
Hi, Gert Doering schrieb:
Hi,
On Fri, Oct 19, 2007 at 03:30:38PM +0200, Iljitsch van Beijnum wrote:
Two can play the RFC quoting game (2460):
There's a certain fun value to watch your "I can quote more interesting things from the RFC" game - but:
** can we please try to focus on "do we want to issue this resolution, ** and if yes, which words need changing"?
a) seconded, or this tends to get a "ignored by the sane people" thread like this 240/4 thingy on the NANOG-list... Please discuss that stuff in private or ask RIPE to open an "Advocacy WG" + list.. thanks. b) there aren't that many change-requeensts (nono, no ITIL...) for the wording, are they? Did i miss something in the mess? -- ======================================================================== = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ========================================================================
Hi, On Fri, Oct 19, 2007 at 08:14:18PM +0200, Sascha Lenz wrote:
b) there aren't that many change-requeensts (nono, no ITIL...) for the wording, are they? Did i miss something in the mess?
As far as I can see, so far, the main point was: - address the vendors anything major I have missed? Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 122119 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
* Gert Doering:
Hi,
On Fri, Oct 19, 2007 at 08:14:18PM +0200, Sascha Lenz wrote:
b) there aren't that many change-requeensts (nono, no ITIL...) for the wording, are they? Did i miss something in the mess?
As far as I can see, so far, the main point was:
- address the vendors
Or only address RIPE members, which would make more sense IMHO.
* Iljitsch van Beijnum:
On 18-okt-2007, at 21:26, Florian Weimer wrote:
IPv6 is a software upgrade.
Including IPsec? Doubt it, some of the CPUs barely manage to run PPPoE.
Since when are IPv6 routers required to do IPsec processing?
RFC 4294, Section 8.1.
On 18 Oct 2007, at 13:11, Iljitsch van Beijnum wrote:
On 18-okt-2007, at 12:49, Joao Damas wrote:
I believe vendors will go where-ever their users show them the money. Create the demand, the offer will show up.
Same thing for the ISPs.
Nope. If ISPs want to continue getting new customers and there are no new IPv4 addresses available then either trade them with some other party who has them, or they use IPv6. The last option might be more expensive at first but it will go down in price, whereas the cost of the first option is only likely to increase. This will create demand from the ISPs for IPv6 enabled products, though perhaps more in the area of application level gateways than in others. Customers won't care if their ISP gives them v6 or v4 as long as they get the service.
And the content networks. All three of those are in the end paid by the end-user. But the end-user has no idea what IPv6 is and is certainly not going to spend extra money to get it.
There is plenty of work to do elsewhere too, but the CPE issue is quickly becoming a significant hurdle. The reason for that is that those tend to run IPv4 NAT which makes easy IPv6 tunneling hard. We really need those boxes to support IPv6 in the near future.
However, in order for that to work there must be a clear provisioning model between ISPs and end-users. A good way to do this with IPv6 is with DHCPv6 prefix delegation, but until pretty much everyone agrees it's hard to build a CPE that will do something reasonable with IPv6 out of the box.
Joao Damas wrote:
Nope. If ISPs want to continue getting new customers and there are no new IPv4 addresses available then either trade them with some other party who has them, or they use IPv6. ... or use RFC1918 space and NAT their entire SOHO customer base. I am told some ISPs do it already.
-- Patrick Vande Walle
Hi Gert, Some inputs below in-line. Regards, Jordi
De: Gert Doering <gert@space.net> Responder a: <address-policy-wg-admin@ripe.net> Fecha: Wed, 17 Oct 2007 17:28:54 +0200 Para: <address-policy-wg@ripe.net>, <ipv6-wg@ripe.net> Asunto: [address-policy-wg] DRAFT: RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6
Hello Address Policy Working Group, IPv6 Working Group,
as announced yesterday on the APWG list, here's the first draft of the "we are going to tell the world what the RIPE community recommends regarding the end of IPv4 / advent of IPv6".
The text has been drafted by the RIPE NCC, but the actual recommendation needs to come from "the community", so change whatever you think needs changing.
Face-to-face discussion will take place in the APWG and IPv6 WG meeting on Thursday, October 25th. (Short discussion in APWG early morning, time to think about it during the day, final decision in the IPv6 WG meeting on Thursday afternoon).
----------------------- snip -----------------------
DRAFT - RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6 RIPE 55: 22 - 26 October 2007
The RIPE community resolves as follows:
1) At current allocation rates, the remaining pool of unallocated IPv4 address space is likely to be allocated within the next two to four years. Although the Internet will continue to function as normal after this point this event will have a significant
... as normal after this point, for those that already have been allocated/assigned IPv4 addresses, ...
influence on future network operations as well as IP address management and allocation policies. Therefore we recognise that the widespread deployment of IPv6 will be essential to sustain future growth of the Internet.
2) We urge network operators and Internet Service Providers (ISPs) to deploy IPv6 across their networks as soon as possible.
... possible, typically by means of incremental steps (depending on each network case, from the core to the access), ...
This deployment must include providing IPv6 access to End Users and ensuring services are accessible by IPv6.
3) We recognise that the responsibility for creating policies related to the management of critical Internet resources in the RIPE NCC service region rests with the RIPE community and the proven success of the RIPE Policy Development Process (PDP). In recognition of this responsibility, we commit to continue development of effective policies for the responsible management of IPv4 and IPv6 address space.
4) We agree that this situation requires a committed effort from network operators, ISPs and the RIPE community. We urge that the widespread deployment of IPv6 be made a high priority.
----- End forwarded message -----
Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 122119
SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
* Gert Doering:
2) We urge network operators and Internet Service Providers (ISPs) to deploy IPv6 across their networks as soon as possible. This deployment must include providing IPv6 access to End Users and ensuring services are accessible by IPv6.
Shouldn't this paragraph target RIPE members specifically? Or, put differently, why are end users and software vendors excluded?
Florian Weimer wrote:
* Gert Doering:
2) We urge network operators and Internet Service Providers (ISPs) to deploy IPv6 across their networks as soon as possible. This deployment must include providing IPv6 access to End Users and ensuring services are accessible by IPv6.
Shouldn't this paragraph target RIPE members specifically? Or, put differently, why are end users and software vendors excluded?
Speaking as an end user, which probably does not qualify me as being part of the "RIPE Community": Agree with Florian's comments, and I would add hardware vendors to the list. As long as there are no commodity CPEs supporting IPv6, there is no incentive for ISPs to deploy IPv6 to their end users, especially those targetting the home users. -- Patrick Vande Walle
Hi, Patrick Vande Walle schrieb:
Florian Weimer wrote:
* Gert Doering:
2) We urge network operators and Internet Service Providers (ISPs) to deploy IPv6 across their networks as soon as possible. This deployment must include providing IPv6 access to End Users and ensuring services are accessible by IPv6.
Shouldn't this paragraph target RIPE members specifically? Or, put differently, why are end users and software vendors excluded?
Speaking as an end user, which probably does not qualify me as being part of the "RIPE Community":
Agree with Florian's comments, and I would add hardware vendors to the list. As long as there are no commodity CPEs supporting IPv6, there is no incentive for ISPs to deploy IPv6 to their end users, especially those targetting the home users.
even though the statement cannot be more than political "blah-blah" without any real outcome :-), i want to join in that the wording SHOULD include at least vendors end end-suer, since they are the biggest problem (point of view: a Consultant). Probably "network operators" is meant to include end-users, but that's not clear enough. And i also see vendors as part of "the community" here, but probably they don't think they are addressed without explicitely mentioning it :-) ISPs won't start deploying IPv6 more widely without end-users requiring it and vendors have a full (as in COMPLETE, WORKING) set of IPv6 capable devices, including SOHO CPEs. ...heck, i already have one upstream explicitely SHUTTING DOWN its IPv6 (testbed) service (Allocation returned) without any production replacement since noone wants to have IPv6 connectivity...yes, big german business/resale ISP ... scary. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== BayCIX GmbH * 84034 Landshut * Wagnergasse 8 Tel: +49 871 925360 * Fax: +49 871 9253629 eMail: technik@baycix.de GF: Thomas Zajac * HR B 4878 (Landshut)
At 10:49 18/10/2007, Sascha Lenz wrote:
Hi,
Patrick Vande Walle schrieb:
Florian Weimer wrote:
* Gert Doering:
2) We urge network operators and Internet Service Providers (ISPs) to deploy IPv6 across their networks as soon as possible. This deployment must include providing IPv6 access to End Users and ensuring services are accessible by IPv6.
Shouldn't this paragraph target RIPE members specifically? Or, put differently, why are end users and software vendors excluded?
Speaking as an end user, which probably does not qualify me as being part of the "RIPE Community": Agree with Florian's comments, and I would add hardware vendors to the list. As long as there are no commodity CPEs supporting IPv6, there is no incentive for ISPs to deploy IPv6 to their end users, especially those targetting the home users.
even though the statement cannot be more than political "blah-blah" without any real outcome :-), i want to join in that the wording SHOULD include at least vendors end end-suer, since they are the biggest problem (point of view: a Consultant). Probably "network operators" is meant to include end-users, but that's not clear enough. And i also see vendors as part of "the community" here, but probably they don't think they are addressed without explicitely mentioning it :-)
ISPs won't start deploying IPv6 more widely without end-users requiring it and vendors have a full (as in COMPLETE, WORKING) set of IPv6 capable devices, including SOHO CPEs.
End users won't require it; they know little about v4 and v6 and only care about their applications working and being able to reach the hosts/sites they want to reach. When some parts of the Internet are only reachable via v6 *that* is when users will want to know why and will kick their ISPs, who will hasten to get their act together and will then kick their upstreams. We have a fully v6-compliant network already - and little traffic.
...heck, i already have one upstream explicitely SHUTTING DOWN its IPv6 (testbed) service (Allocation returned) without any production replacement since noone wants to have IPv6 connectivity...yes, big german business/resale ISP ... scary.
-- Tim
* Tim Streater:
End users won't require it; they know little about v4 and v6 and only care about their applications working and being able to reach the hosts/sites they want to reach.
Does this reflect your experience with the academic community? (Just curious.)
When some parts of the Internet are only reachable via v6 *that* is when users will want to know why and will kick their ISPs, who will hasten to get their act together and will then kick their upstreams.
Uh-oh, this reminds me of the Internet2 Detective. 8-/
At 14:39 18/10/2007, Florian Weimer wrote:
* Tim Streater:
End users won't require it; they know little about v4 and v6 and only care about their applications working and being able to reach the hosts/sites they want to reach.
Does this reflect your experience with the academic community? (Just curious.)
End users doing v6 testing or testing apps for v6, will obviously know. We must have a number of those in some NRENs that we serve. We have several NREN customers who consistently generate orders of magnitude more v6 traffic than others. Then you have the generality of network engineers, who should know :-) But end-users in general (academic or not) are unlikely to know, seems to me. -- Tim
End users are every day smarter. They realize that some peer to peer applications, on-lime-gaming, etc., works better some times or in some ISPs, and they end-up guessing that it is because they are able to use IPv6 end-to-end, doing *real* peer-to-peer. And it happens that some ISPs offer transition services that improve that, others not, so end-users end up replacing their ISPs and this is going to be more and more frequent, because this is already happening as more and more people uses Vista. Regarding the comment on the IPv6 traffic. There is a big misconception here, and I can prove it. We developed a tool to measure *REAL* IPv6 traffic, not just *NATIVE*. Because today, it is clear that a very very very low % is native, because almost none of the ISPs offer native IPv6 to the last mile, it is quite obvious. However, the increase on transition (encapsulated) IPv6 traffic is something happening in *ALL* the networks, despite those networks don't have *ANY* IPv6 support. GEANT may offer dual stack, but if the universities don't offer IPv6 to the desktop, then the OSs are using transition mechanisms, without users noticing it ! Regards, Jordi
De: Tim Streater <tim.streater@dante.org.uk> Responder a: <address-policy-wg-admin@ripe.net> Fecha: Thu, 18 Oct 2007 11:31:10 +0100 Para: Sascha Lenz <slz@baycix.de>, Address Policy WG <address-policy-wg@ripe.net> CC: <ipv6-wg@ripe.net> Asunto: Re: [address-policy-wg] DRAFT: RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6
At 10:49 18/10/2007, Sascha Lenz wrote:
Hi,
Patrick Vande Walle schrieb:
Florian Weimer wrote:
* Gert Doering:
2) We urge network operators and Internet Service Providers (ISPs) to deploy IPv6 across their networks as soon as possible. This deployment must include providing IPv6 access to End Users and ensuring services are accessible by IPv6.
Shouldn't this paragraph target RIPE members specifically? Or, put differently, why are end users and software vendors excluded?
Speaking as an end user, which probably does not qualify me as being part of the "RIPE Community": Agree with Florian's comments, and I would add hardware vendors to the list. As long as there are no commodity CPEs supporting IPv6, there is no incentive for ISPs to deploy IPv6 to their end users, especially those targetting the home users.
even though the statement cannot be more than political "blah-blah" without any real outcome :-), i want to join in that the wording SHOULD include at least vendors end end-suer, since they are the biggest problem (point of view: a Consultant). Probably "network operators" is meant to include end-users, but that's not clear enough. And i also see vendors as part of "the community" here, but probably they don't think they are addressed without explicitely mentioning it :-)
ISPs won't start deploying IPv6 more widely without end-users requiring it and vendors have a full (as in COMPLETE, WORKING) set of IPv6 capable devices, including SOHO CPEs.
End users won't require it; they know little about v4 and v6 and only care about their applications working and being able to reach the hosts/sites they want to reach. When some parts of the Internet are only reachable via v6 *that* is when users will want to know why and will kick their ISPs, who will hasten to get their act together and will then kick their upstreams.
We have a fully v6-compliant network already - and little traffic.
...heck, i already have one upstream explicitely SHUTTING DOWN its IPv6 (testbed) service (Allocation returned) without any production replacement since noone wants to have IPv6 connectivity...yes, big german business/resale ISP ... scary.
-- Tim
********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Well, I don't agree you're not part of the community. Being subscriber and poster to the mailing is a qualifier for being a member :-) Agree with Florian and you. It is needed to say something to remind vendors that market is already asking for IPv6 support. I don't think they should just wait for the demand to come, because then it will be late. So a warning to them is a good thing. Same for software developers, they should realize that they can take advantage of IPv6 NOW, because even if there are no native access providers yet, transition is available in end-hosts. There is no immediate need for low costs CPEs, of course is good to have, but transition tools in end-hosts already deliver the same, until access providers provide dual stack, then of course, CPEs with allow dual stack on the WAN link are needed. Regards, Jordi
De: Patrick Vande Walle <patrick@vande-walle.eu> Responder a: <patrick@vande-walle.eu> Fecha: Thu, 18 Oct 2007 11:26:09 +0200 Para: <address-policy-wg@ripe.net> CC: <ipv6-wg@ripe.net> Asunto: Re: [address-policy-wg] DRAFT: RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6
Florian Weimer wrote:
* Gert Doering:
2) We urge network operators and Internet Service Providers (ISPs) to deploy IPv6 across their networks as soon as possible. This deployment must include providing IPv6 access to End Users and ensuring services are accessible by IPv6.
Shouldn't this paragraph target RIPE members specifically? Or, put differently, why are end users and software vendors excluded?
Speaking as an end user, which probably does not qualify me as being part of the "RIPE Community":
Agree with Florian's comments, and I would add hardware vendors to the list. As long as there are no commodity CPEs supporting IPv6, there is no incentive for ISPs to deploy IPv6 to their end users, especially those targetting the home users.
-- Patrick Vande Walle
********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
On Thu, 18 Oct 2007, JORDI PALET MARTINEZ wrote:
Well, I don't agree you're not part of the community. Being subscriber and poster to the mailing is a qualifier for being a member :-)
Agree with Florian and you. It is needed to say something to remind vendors that market is already asking for IPv6 support. I don't think they should just wait for the demand to come, because then it will be late. So a warning to them is a good thing. Same for software developers, they should realize that they can take advantage of IPv6 NOW, because even if there are no native access providers yet, transition is available in end-hosts.
there are NOT ENOUGH native (commercial) access providers ...but we should make a small note that some already exist. :-)
There is no immediate need for low costs CPEs, of course is good to have, but transition tools in end-hosts already deliver the same, until access
//transition tools in end-hosts// ...and what happens to performance??? imho, low-cost CPEs are key if one wants to seriously see IPv6 deployed significantly. it would be a significant contribution to break chicken/egg-type problems...
providers provide dual stack, then of course, CPEs with allow dual stack on the WAN link are needed.
Regards, Jordi
Best Regards, ------------------------------------------------------------------------- Carlos Friac,as See: Wide Area Network Working Group (WAN) www.gigapix.pt FCCN - Fundacao para a Computacao Cientifica Nacional www.ipv6.eu Av. do Brasil, n.101 www.6diss.org 1700-066 Lisboa, Portugal, Europe www.geant2.net Tel: +351 218440100 Fax: +351 218472167 www.fccn.pt ------------------------------------------------------------------------- The end is near........ see http://ipv4.potaroo.net "Internet is just routes (217118/774), naming (billions) and... people!" Aviso de Confidencialidade Esta mensagem e' exclusivamente destinada ao seu destinatario, podendo conter informacao CONFIDENCIAL, cuja divulgacao esta' expressamente vedada nos termos da lei. Caso tenha recepcionado indevidamente esta mensagem, solicitamos-lhe que nos comunique esse mesmo facto por esta via ou para o telefone +351 218440100 devendo apagar o seu conteudo de imediato. Warning This message is intended exclusively for its addressee. It may contain CONFIDENTIAL information protected by law. If this message has been received by error, please notify us via e-mail or by telephone +351 218440100 and delete it immediately.
Performance is not an issue when doing peer to peer with the same transition mechanism (example Teredo to Teredo or 6to4 to 6to4), actually the performance is better than doing it with IPv4 and using intermediate hosts, such as MSN or Skype do. Performance impacts when both hosts doing peer-to-peer (or client-to-server) are using different types of IPv6 connectivity (example, native vs. 6to4 or Teredo, or Teredo vs. 6to4). This is solved by deploying 6to4 and Teredo relays in the ISPs, and is actually something inexpensive that ISPs should do while they can't provide native access. Regards, Jordi
De: Carlos Friacas <cfriacas@fccn.pt> Responder a: <ipv6-wg-admin@ripe.net> Fecha: Fri, 19 Oct 2007 09:22:44 +0100 (WEST) Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es> CC: <ipv6-wg@ripe.net> Asunto: [ipv6-wg] Re: [address-policy-wg] DRAFT: RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6
On Thu, 18 Oct 2007, JORDI PALET MARTINEZ wrote:
Well, I don't agree you're not part of the community. Being subscriber and poster to the mailing is a qualifier for being a member :-)
Agree with Florian and you. It is needed to say something to remind vendors that market is already asking for IPv6 support. I don't think they should just wait for the demand to come, because then it will be late. So a warning to them is a good thing. Same for software developers, they should realize that they can take advantage of IPv6 NOW, because even if there are no native access providers yet, transition is available in end-hosts.
there are NOT ENOUGH native (commercial) access providers ...but we should make a small note that some already exist. :-)
There is no immediate need for low costs CPEs, of course is good to have, but transition tools in end-hosts already deliver the same, until access
//transition tools in end-hosts//
...and what happens to performance???
imho, low-cost CPEs are key if one wants to seriously see IPv6 deployed significantly. it would be a significant contribution to break chicken/egg-type problems...
providers provide dual stack, then of course, CPEs with allow dual stack on the WAN link are needed.
Regards, Jordi
Best Regards,
------------------------------------------------------------------------- Carlos Friac,as See: Wide Area Network Working Group (WAN) www.gigapix.pt FCCN - Fundacao para a Computacao Cientifica Nacional www.ipv6.eu Av. do Brasil, n.101 www.6diss.org 1700-066 Lisboa, Portugal, Europe www.geant2.net Tel: +351 218440100 Fax: +351 218472167 www.fccn.pt ------------------------------------------------------------------------- The end is near........ see http://ipv4.potaroo.net "Internet is just routes (217118/774), naming (billions) and... people!"
Aviso de Confidencialidade Esta mensagem e' exclusivamente destinada ao seu destinatario, podendo conter informacao CONFIDENCIAL, cuja divulgacao esta' expressamente vedada nos termos da lei. Caso tenha recepcionado indevidamente esta mensagem, solicitamos-lhe que nos comunique esse mesmo facto por esta via ou para o telefone +351 218440100 devendo apagar o seu conteudo de imediato.
Warning This message is intended exclusively for its addressee. It may contain CONFIDENTIAL information protected by law. If this message has been received by error, please notify us via e-mail or by telephone +351 218440100 and delete it immediately.
********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Performance impacts when both hosts doing peer-to-peer (or client-to-server) are using different types of IPv6 connectivity (example, native vs. 6to4 or Teredo, or Teredo vs. 6to4). This is solved by deploying 6to4 and Teredo relays in the ISPs, and is actually something inexpensive that ISPs should do while they can't provide native access.
This is something that is described in more detail on ARIN's IPv6 wiki targetted at ISPs: http://www.getipv6.info/index.php/First_Steps_for_ISPs --Michael Dillon
I think the information that we host for long time ago in The IPv6 Portal is much more complete: http://www.ipv6tf.org/index.php?page=using/connectivity/6to4 Same for Teredo: http://www.ipv6tf.org/index.php?page=using/connectivity/teredo I'm going to post those links in the Wiki also. Regards, Jordi
De: <michael.dillon@bt.com> Responder a: <ipv6-wg-admin@ripe.net> Fecha: Sat, 20 Oct 2007 06:29:04 +0100 Para: <ipv6-wg@ripe.net> Conversación: [ipv6-wg] Re: [address-policy-wg] DRAFT: RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6 Asunto: RE: [ipv6-wg] Re: [address-policy-wg] DRAFT: RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6
Performance impacts when both hosts doing peer-to-peer (or client-to-server) are using different types of IPv6 connectivity (example, native vs. 6to4 or Teredo, or Teredo vs. 6to4). This is solved by deploying 6to4 and Teredo relays in the ISPs, and is actually something inexpensive that ISPs should do while they can't provide native access.
This is something that is described in more detail on ARIN's IPv6 wiki targetted at ISPs: http://www.getipv6.info/index.php/First_Steps_for_ISPs
--Michael Dillon
********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
I think the information that we host for long time ago in The IPv6 Portal is much more complete:
http://www.ipv6tf.org/index.php?page=using/connectivity/6to4
We!? If you have any influence over the design of those pages, please get them to fix the silly scrolling system. The scrollbar is too small, and it doesn't behave like a normal scrollbar does (clicking in the scrollbar makes a big jump. PgUp/PgDn don't work). It is simply an inappropriate design for delivering technical information. Alternatively, provide PDF versions of those pages so people can download them and read them without suffering from that silly page design. --Michael Dillon
I will check with the web designer and fix it immediately, but it is working for me ... What platform/OS/browser you have the problem to check if is only that one ? Regards, Jordi
De: <michael.dillon@bt.com> Responder a: <ipv6-wg-admin@ripe.net> Fecha: Wed, 24 Oct 2007 13:45:13 +0100 Para: <ipv6-wg@ripe.net> Conversación: [ipv6-wg] Re: [address-policy-wg] DRAFT: RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6 Asunto: RE: [ipv6-wg] Re: [address-policy-wg] DRAFT: RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6
I think the information that we host for long time ago in The IPv6 Portal is much more complete:
http://www.ipv6tf.org/index.php?page=using/connectivity/6to4
We!?
If you have any influence over the design of those pages, please get them to fix the silly scrolling system. The scrollbar is too small, and it doesn't behave like a normal scrollbar does (clicking in the scrollbar makes a big jump. PgUp/PgDn don't work). It is simply an inappropriate design for delivering technical information.
Alternatively, provide PDF versions of those pages so people can download them and read them without suffering from that silly page design.
--Michael Dillon
********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Jordi, Michael, I would like to remind you that this list is not intended to get into contests on who has a better website (unless of course it is not reachable over ipv6 ;-)). David Kessens --- On Wed, Oct 24, 2007 at 01:45:13PM +0100, ipv6-wg-admin@ripe.net wrote:
I think the information that we host for long time ago in The IPv6 Portal is much more complete:
http://www.ipv6tf.org/index.php?page=using/connectivity/6to4
We!?
If you have any influence over the design of those pages, please get them to fix the silly scrolling system. The scrollbar is too small, and it doesn't behave like a normal scrollbar does (clicking in the scrollbar makes a big jump. PgUp/PgDn don't work). It is simply an inappropriate design for delivering technical information.
Alternatively, provide PDF versions of those pages so people can download them and read them without suffering from that silly page design.
--Michael Dillon
David Kessens ---
I would like to remind you that this list is not intended to get into contests on who has a better website (unless of course it is not reachable over ipv6 ;-)).
This is not a contest. This is about improving the availability of educational resources to help ISPs implement IPv6. There is far too much information about IPv6 scattered over too many sites and books. A lot of that information is old and out of date, or it is of dubious quality because somebody has an axe to grind such as the people who want to assign their customers /120 blocks to "conserve addresses". We need some editorial review of the existing material so that people know what sites/books/people they can trust. Jordi and I are communicating privately to get the IPv6 Task Force website fixed so that people can actually access the information on that site. And we will include links to some of that material on the ARIN IPv6 educational wiki http://www.getipv6.info I believe that this is all worthy of discussion on this list since it helps prepare for the coming IPv6 implementation crunch. --Michael Dillon P.S. IPv6 is *NOT* IPv4 with more bits. It is a different protocol from IPv4 with a different addressing architecture and numerous different approaches to networking problems. You have to make some serious effort to learn and understand it.
I think it may be better one additional paragraph asking the end users to *request* IPv6 transition or native services to their ISPs and look for an alternative ISP when their actual one is not willing to offer the service. Which this, I'm not asking the ISPs to do native overnight, I know this is not reasonable, but deploying 6to4 and Teredo relays for their users is simple and inexpensive solution and a very good think for both reducing the unnecessary upstream traffic and lowering the RTT when using those transition mechanisms. There is no excuse for an ISP not doing so already and I'm happy to offer my time if somebody don't have the knowledge about how to do so. Regards, Jordi
De: Florian Weimer <fw@deneb.enyo.de> Responder a: <ipv6-wg-admin@ripe.net> Fecha: Thu, 18 Oct 2007 10:57:34 +0200 Para: Gert Doering <gert@space.net> CC: <address-policy-wg@ripe.net>, <ipv6-wg@ripe.net> Asunto: [ipv6-wg] Re: [address-policy-wg] DRAFT: RIPE Community Resolution on IPv4 Depletion and Deployment of IPv6
* Gert Doering:
2) We urge network operators and Internet Service Providers (ISPs) to deploy IPv6 across their networks as soon as possible. This deployment must include providing IPv6 access to End Users and ensuring services are accessible by IPv6.
Shouldn't this paragraph target RIPE members specifically? Or, put differently, why are end users and software vendors excluded?
********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
participants (14)
-
Carlos Friacas -
David Kessens -
Florian Frotzler -
Florian Weimer -
Gert Doering -
Iljitsch van Beijnum -
Joao Damas -
JORDI PALET MARTINEZ -
michael.dillon＠bt.com -
Nick Hilliard -
Patrick Vande Walle -
Sascha Lenz -
Shane Kerr -
Tim Streater