IPv6 prefix delegation BCOP document available for comments and suggestions
Dear RIPE IPv6 WG, As promised at last RIPE meeting in Madrid, we produced a first draft of "Best Current Operational Practice for operators: IPv6 prefix assignment for end-users - static (stable) or dynamic (non-stable) and what size to choose." The aim of this document is to document the best current operational practice on what size of IPv6 prefix ISPs should assign/delegate to their customers and should they delegate it in a stable, static way or should it change over time. Please find the PDF attached and also accessible at: https://www.sinog.si/docs/draft-IPv6pd-BCOP-v1.pdf We are submitting this document to RIPE IPv6 WG (here) to check the technical validity of the document and also get consensus on it. We are also submitting it to RIPE BCOP TF to check if this is a real best operational practice and get consensus on it there. Please, read the document and send back comments to this mailing list. All feedback is more than welcome. On behalf of co-authors, Jan Žorž P.S: This document is not intended to document what practices may be in future and what they might look like, but to reflect the best methods of implementing IPv6 at the time of publication. Updates to this document will be published to reflect changes in best current practices where there are developments in standards and implementations.
Hi Jan, It's not clear to me why in Section 3.1.5, a global /64 prefix is recommended for PPPoE connections. Sections 3.1.2 and 3.1.3 talk about directly connecting hosts without any kind of CPE. As far I know, the last time that was in fashion for PPP links was with dial-up. So I think that for PPPoE we can safely assume that a CPE can request a prefix using DHCPv6 PD. As indirectly mentioned in Section 3.1.2, assigning a global /64 to a point-to-point link may open certain kinds of attacks. All links with a global /64 risk a ND exhaustion attack. However, point-to-points also risk a ping-pong attack. For a PPPoE link these issues are trivially solved to leaving the link unnumbered.
On 28/03/2017 13:28, Philip Homburg wrote:
Hi Jan,
It's not clear to me why in Section 3.1.5, a global /64 prefix is recommended for PPPoE connections.
Sections 3.1.2 and 3.1.3 talk about directly connecting hosts without any kind of CPE. As far I know, the last time that was in fashion for PPP links was with dial-up.
Hey, Thank you for reading the document and commenting, I hope you find it useful. You would be surprised how many residential customers still have CPE in bridge mode and are connecting to PPPoE service using Windows (or any other OS) PC using a PPPoE dialer, some of them even using multiple parallel PPPoE sessions from multiple computers sitting on the same network. In this case, even static /64 for WAN link would not work as in this case the assignments would not work for both of them and you need to setup a dynamic WAN numbering to accommodate multiple PPPoE sessions. People still does strange things and since this is all about documenting the current operational practice, we need to take this into account.
So I think that for PPPoE we can safely assume that a CPE can request a prefix using DHCPv6 PD.
Yes.
As indirectly mentioned in Section 3.1.2, assigning a global /64 to a point-to-point link may open certain kinds of attacks. All links with a global /64 risk a ND exhaustion attack. However, point-to-points also risk a ping-pong attack.
Indeed. I believe we covered that with recommending /127 or similar.
For a PPPoE link these issues are trivially solved to leaving the link unnumbered.
Again, for those, using a PPPoE dialer that would not work. If you are 100% sure that nobody in your network is connecting using a PPPoE dialer, then yes, go ahead with unnumbered. Cheers, Jan
Hi, On Wed, Mar 29, 2017 at 08:14:59AM +0200, Jan Zorz - Go6 wrote:
For a PPPoE link these issues are trivially solved to leaving the link unnumbered.
Again, for those, using a PPPoE dialer that would not work. If you are 100% sure that nobody in your network is connecting using a PPPoE dialer,
... and your CPEs can cope with having no GUA on the WAN link (like, for doing DNS lookups, or such). They *should*, but ...
then yes, go ahead with unnumbered.
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On 29/03/2017 09:02, Gert Doering wrote:
Hi,
On Wed, Mar 29, 2017 at 08:14:59AM +0200, Jan Zorz - Go6 wrote:
For a PPPoE link these issues are trivially solved to leaving the link unnumbered.
Again, for those, using a PPPoE dialer that would not work. If you are 100% sure that nobody in your network is connecting using a PPPoE dialer,
... and your CPEs can cope with having no GUA on the WAN link (like, for doing DNS lookups, or such). They *should*, but ...
Hey, I'm absolutely not a fan of unnumbered links, to make it clear. However, CPE with unnumbered WAN link will receive a prefix delegation and from this point on, there are many different implementations on different CPEs - some will take first /64 and number the loopback, some will not and just start numbering L3 ports and so on - but as soon as one interface is numbered from PD - CPE uses that to doe DNS and other stuff. Cheers, Jan
then yes, go ahead with unnumbered.
Gert Doering -- NetMaster
Hi Jan, In your letter dated Wed, 29 Mar 2017 08:14:59 +0200 you wrote:
You would be surprised how many residential customers still have CPE in bridge mode and are connecting to PPPoE service using Windows (or any other OS) PC using a PPPoE dialer, some of them even using multiple parallel PPPoE sessions from multiple computers sitting on the same network.
I literally do not know of a single case where somebody around me was running ppp on Windows 7 (or later) or on a recent version of MacOS. That just doesn't seem to happen around here (in .nl). Many people here connect a Linux box using PPPoE, but in that case the Linux box is configured as a router. Note that the ISP I'm using hands out FritzBox CPEs which officially do not even support bridging a VDSL connection. So I'm very curious. Do ISPs officially support this? Are there ISPs that describe how to put a DSL model in bridge mode and the configure Windows 10 to connect? How does that work with iphones, android, etc. Do people bridge PPPoE to wifi and then run PPPoE on a phone or tablet? How did multiple sessions work with IPv4. Did every session get its own public IPv4 address using PPP IPCP? How does that work with the /64. Are multiple static /64s assigned to a particular customer? In the case of multiple /64s, do hosts have sufficiently stable PPPoE IDs that you can assign the right one to each host?
As sad I am to write this, here's the real-life story...
You would be surprised how many residential customers still have CPE in
bridge mode and are connecting to PPPoE service using Windows (or any other OS) PC using a PPPoE dialer, some of them even using multiple parallel PPPoE sessions from multiple computers sitting on the same network.
I literally do not know of a single case where somebody around me was running ppp on Windows 7 (or later) or on a recent version of MacOS. That just doesn't seem to happen around here (in .nl).
Do ISPs officially support this? Are there ISPs that describe how to put a DSL model in bridge mode and the configure Windows 10 to connect?
Yes, Telekom Slovenije still runs PPPoE over their fiber network. I was making fun of that 9 years ago ( http://blog.ipspace.net/2008/10/internet-access-russian-dolls.html) and not much changed in the meantime. Unfortunately, some people (including my father) believe that using PPPoE from Windows is more secure than running it from the edge router (aka *modem *because some people never saw a real modem in their life), so he's running PPPoE from every Windows laptop he has in his house. How does that work with iphones, android, etc. Do people bridge PPPoE to
wifi and then run PPPoE on a phone or tablet?
Not sure about tablets etc., but that's exactly what he's doing (I think that was the default setup his *modem *was shipped with anyway... years ago). How did multiple sessions work with IPv4. Did every session get its own
public IPv4 address using PPP IPCP?
Yes.
How does that work with the /64. Are multiple static /64s assigned to a particular customer? In the case of multiple /64s, do hosts have sufficiently stable PPPoE IDs that you can assign the right one to each host?
No idea. I don't want to talk about that setup (because it's breaking down for him occasionally with Windows 10), let alone touch it. Maybe Jan knows more ;)) Hope this doesn't make you depressed... Ivan
In your letter dated Wed, 29 Mar 2017 15:37:45 +0200 you wrote:
Yes, Telekom Slovenije still runs PPPoE over their fiber network. I was making fun of that 9 years ago ( http://blog.ipspace.net/2008/10/internet-access-russian-dolls.html) and not much changed in the meantime.
Hooking up CPEs to an ethernet-like link without actually running a routing protocol has its own set of issues. PPPoE framing is also simple enough that it should not cost a lot of CPU time.
Unfortunately, some people (including my father) believe that using PPPoE from Windows is more secure than running it from the edge router (aka *modem *because some people never saw a real modem in their life), so he's running PPPoE from every Windows laptop he has in his house.
Fascinating. There are people who insist that every CPE has to come with an IPv6 firewall that has to be enabled by default. And then, connecting a Windows system directly to an internet connection because it is believed to be more secure than a CPE. Worlds apart. But yes, for those markets, assigning a /64 seems to be required.
On Wed, 29 Mar 2017, Philip Homburg wrote:
Hooking up CPEs to an ethernet-like link without actually running a routing protocol has its own set of issues. PPPoE framing is also simple enough that it should not cost a lot of CPU time.
Encap/decap is always costly unless mitigated by special hardware (which of course costs money, but in volume can be low). ISPs are doing PPPoE because of other reasons, not because it's easy on the forwarding plane. Most of the motivation I've been seeing revolves around the same reasons enterprise want DHCPv6 IA_NA "that's what we've 'always' been doing and we have the systems to support it". I prefer IPoE, but that seems to be common here in the nordics, but the rest of the world seems to have converged around PPPoE. -- Mikael Abrahamsson email: swmike@swm.pp.se
On 04/04/2017 10:59, Mikael Abrahamsson wrote:
On Wed, 29 Mar 2017, Philip Homburg wrote:
Hooking up CPEs to an ethernet-like link without actually running a routing protocol has its own set of issues. PPPoE framing is also simple enough that it should not cost a lot of CPU time.
Encap/decap is always costly unless mitigated by special hardware (which of course costs money, but in volume can be low). ISPs are doing PPPoE because of other reasons, not because it's easy on the forwarding plane. Most of the motivation I've been seeing revolves around the same reasons enterprise want DHCPv6 IA_NA "that's what we've 'always' been doing and we have the systems to support it".
I prefer IPoE, but that seems to be common here in the nordics, but the rest of the world seems to have converged around PPPoE.
Hey, Operators who offered ADSL built a PPPoE provisioning and all the billing infrastructure behind and even if doing PPPoE on FTTH does not make *any* technical sense, I heard that re-doing and changing the whole provisioning system would cost them too much, so they went the easy way - PPPoE over anything/everything. It is what it is and I guess we'll have to live with it ;) Cheers, Jan
Il 05/04/2017 13:26, Jan Zorz - Go6 ha scritto:
Operators who offered ADSL built a PPPoE provisioning and all the billing infrastructure behind and even if doing PPPoE on FTTH does not make *any* technical sense, I heard that re-doing and changing the whole provisioning system would cost them too much, so they went the easy way - PPPoE over anything/everything. It is what it is and I guess we'll have to live with it ;)
Having a PPPoE interface to every customer also simplify network monitoring (get interface traffic via SNMP, for example) and ethernet VLAN to seperate customers L2 traffic could not be a viable solution, maybe because CPE needs manual configuration to set VID. So, even new operators can find PPPoE better than DHCP or IPoE. Regards Claudio
On Wed, 5 Apr 2017, Claudio Ferronato wrote:
(get interface traffic via SNMP, for example) and ethernet VLAN to seperate customers L2 traffic could not be a viable solution, maybe because CPE needs manual configuration to set VID.
Why would the CPE need to send tagged frames? The access switch can do the tagging/detagging, the CPE can send untagged frames. -- Mikael Abrahamsson email: swmike@swm.pp.se
Il 05/04/2017 17:20, Mikael Abrahamsson ha scritto:
On Wed, 5 Apr 2017, Claudio Ferronato wrote:
(get interface traffic via SNMP, for example) and ethernet VLAN to seperate customers L2 traffic could not be a viable solution, maybe because CPE needs manual configuration to set VID.
Why would the CPE need to send tagged frames? The access switch can do the tagging/detagging, the CPE can send untagged frames.
Because I'm talking from a WISP perspective, where there isn't a "real" access switch. Claudio
On Wed, 5 Apr 2017, Claudio Ferronato wrote:
Because I'm talking from a WISP perspective, where there isn't a "real" access switch.
There can be. Slide 10. https://meetings.ripe.net/see5/files/SEE5_20160419_IPv6_Community_Wifi_Final... -- Mikael Abrahamsson email: swmike@swm.pp.se
Il 06/04/2017 07:04, Mikael Abrahamsson ha scritto:
On Wed, 5 Apr 2017, Claudio Ferronato wrote:
Because I'm talking from a WISP perspective, where there isn't a "real" access switch.
There can be. Slide 10.
https://meetings.ripe.net/see5/files/SEE5_20160419_IPv6_Community_Wifi_Final...
Ok, thank you. But, this is a kind of configuration that not so many WISP could accept easily. If the CPE (and not UE) does captive portal login (maybe via MAC auth), to give global IPv6 addresses, it can be reachable from the Internet and this widen the surface attack (http://tinyurl.com/z2dvvfl). Yes, firewall rules are a good solution, but another way is to simply bridge ethernet to radio interface. There are some drawbacks of the last way, as PPPoE encapsulation removes the capacity to do QoS for VoIP traffic on the CPE device. But the main point is: pppoe is not dead (yet). Regards Claudio
On 29/03/2017 14:44, Philip Homburg wrote:
Hi Jan,
In your letter dated Wed, 29 Mar 2017 08:14:59 +0200 you wrote:
You would be surprised how many residential customers still have CPE in bridge mode and are connecting to PPPoE service using Windows (or any other OS) PC using a PPPoE dialer, some of them even using multiple parallel PPPoE sessions from multiple computers sitting on the same network.
I literally do not know of a single case where somebody around me was running ppp on Windows 7 (or later) or on a recent version of MacOS. That just doesn't seem to happen around here (in .nl).
You live in .nl ;) Other areas are different. There are other continents, too ;)
Many people here connect a Linux box using PPPoE, but in that case the Linux box is configured as a router.
Note that the ISP I'm using hands out FritzBox CPEs which officially do not even support bridging a VDSL connection.
So I'm very curious.
Do ISPs officially support this? Are there ISPs that describe how to put a DSL model in bridge mode and the configure Windows 10 to connect?
Sure :)
How does that work with iphones, android, etc. Do people bridge PPPoE to wifi and then run PPPoE on a phone or tablet?
it doesn't. Some people just want to have few computers at home connected and they run multiple PPPoE sessions. Remember, we are documenting a current reality here, not what we want to do in the future.
How did multiple sessions work with IPv4. Did every session get its own public IPv4 address using PPP IPCP?
Yes ;)
How does that work with the /64. Are multiple static /64s assigned to a particular customer? In the case of multiple /64s, do hosts have sufficiently stable PPPoE IDs that you can assign the right one to each host?
In this case you need to delegate /64 for WAN dynamically. If host with PPPoE is in question, you don't have to do static. Most bullet-proof today for network behind the CPE is static. Cheers, Jan
Dear Philip, Philip Homburg wrote at 29.03.2017 14:44:
Hi Jan,
In your letter dated Wed, 29 Mar 2017 08:14:59 +0200 you wrote:
You would be surprised how many residential customers still have CPE in bridge mode and are connecting to PPPoE service using Windows (or any other OS) PC using a PPPoE dialer, some of them even using multiple parallel PPPoE sessions from multiple computers sitting on the same network.
I literally do not know of a single case where somebody around me was running ppp on Windows 7 (or later) or on a recent version of MacOS. That just doesn't seem to happen around here (in .nl).
I 've seen them here (.de) in the field as i have had a projekt to replace old BRAS with newer BNG about two years ago. All of them have been ADSL customers using PPPoE. So it turned out that it would absolutly neccessary to build the config on the BNG with SLAAC using a /64 per customer as their WAN Prefix.
Note that the ISP I'm using hands out FritzBox CPEs which officially do not even support bridging a VDSL connection.
That's absolutly correct for VDSL customer, but if you still have to support ADSL you most likely run into trouble without supporting SLAAC and a /64.
Do ISPs officially support this?
Yes, we do so.
Are there ISPs that describe how to put a DSL model in bridge mode and the configure Windows 10 to connect?
Can't tell about this Windows 10 thingie and to be honnest i have not researched all versions from all OS out in the field. But i have seen Windows, Linux and MacOS at the time of migration.
How does that work with iphones, android, etc. Do people bridge PPPoE to wifi and then run PPPoE on a phone or tablet?
Most likely they do not do that on a phone or a tablet. Using a router and WiFi on the LAN seems to be more common in that case.
How did multiple sessions work with IPv4. Did every session get its own public IPv4 address using PPP IPCP?
Only speaking for my employe: Multiple Sessions are not supported on residential PPPoE access. Only one PPPoE Session per customer is supported. Best Regards. Matthias Kluth Senior Network Consultant HeLi NET Telekommunikation GmbH & Co. KG Hafenstr. 80-82 D-59067 Hamm Tel.: +49 (0)2381 / 874-4502 Fax: +49 (0)2381 / 874-4551 Mobil: +49 (0)173 / 5411102 Email: mk@helinet.de Web: http://www.helinet.de -- HeLi NET Telekommunikation GmbH & Co. KG Sitz der Gesellschaft: Hamm - Amtsgericht Hamm HRA 1881 Komplementaerin: HeLi NET Verwaltung GmbH Sitz der Gesellschaft: Hamm - Amtsgericht Hamm HRB 2781 Geschaeftsfuehrung: Dipl.-Kfm. Ralf Schuette
On 30/03/2017 10:28, Matthias Kluth wrote:
Dear Philip,
Philip Homburg wrote at 29.03.2017 14:44:
Hi Jan,
In your letter dated Wed, 29 Mar 2017 08:14:59 +0200 you wrote:
You would be surprised how many residential customers still have CPE in bridge mode and are connecting to PPPoE service using Windows (or any other OS) PC using a PPPoE dialer, some of them even using multiple parallel PPPoE sessions from multiple computers sitting on the same network.
I literally do not know of a single case where somebody around me was running ppp on Windows 7 (or later) or on a recent version of MacOS. That just doesn't seem to happen around here (in .nl).
I 've seen them here (.de) in the field as i have had a projekt to replace old BRAS with newer BNG about two years ago. All of them have been ADSL customers using PPPoE.
So it turned out that it would absolutly neccessary to build the config on the BNG with SLAAC using a /64 per customer as their WAN Prefix.
Thnx for your comment. Yes, it pragmatically make sense to do it this way unless you are 100% sure you don't have any PPPoE non-router-end-host clients connecting to your network. We got quite a number of suggestions, ideas and feedback on the document, so I would like that we conclude this first round of feedback at the end of this week, so we (authors) can do the next edit cycle next week and come back with draft v.2. Thnx again to everyone for your time and energy to read this document and all your feedback. Cheers, Jan Zorz
Dne 29.3.2017 v 14:44 Philip Homburg napsal(a):
Do ISPs officially support this? Are there ISPs that describe how to put a DSL model in bridge mode and the configure Windows 10 to connect?
Funny story: between 2007 and 2008 O2 Czech Republic offered a new ADSL plan called Internet ADSL Start. On contrary to other plans this one didn't have a data limit but instead was charged per number of minutes on-line. Marketing department probably wanted to reuse old billing systems from the era of dial-up. For the purpose of measuring online time, modems were shipped in bridge mode and PPPoE connection was established from the connected computer whenever customer wanted to "connect to the internet". By that time, there were no smartphones nor tablets, even laptops were not that common. I guess there was only one PPPoE session supported per line. BTW, I wish somebody from O2 CZ reads this BCOP document, especially section 3.2.3. about problems with assigning less then /56. They are running a big deployment of IPv6 on xDSL broadband lines offering only /64 via PD with no option to get more addresses (not even for an extra payment). Their reaction on any complaints always is that their setup is sufficient for 99 % of customers and they don't see it worthy to support the 1 % of trouble-making customers (which is kind of same argumentation others use for not deploying IPv6 at all). Cheers, Ondřej Caletka
Ondřej Caletka wrote:
Funny story: between 2007 and 2008 O2 Czech Republic offered a new ADSL plan called Internet ADSL Start. On contrary to other plans this one didn't have a data limit but instead was charged per number of minutes on-line. Marketing department probably wanted to reuse old billing systems from the era of dial-up.
yeah, KPN did this in NL at around the same time. I know of one case where someone only noticed after their bank account had been drained of all its cash as a result of background windows chatter traffic. Fortunately, the service was discontinued in short order after KPN realised what a completely bone-headed idea it was. Nick
On 30/03/2017 17:36, Ondřej Caletka wrote:
BTW, I wish somebody from O2 CZ reads this BCOP document, especially section 3.2.3. about problems with assigning less then /56. They are running a big deployment of IPv6 on xDSL broadband lines offering only /64 via PD with no option to get more addresses (not even for an extra payment). Their reaction on any complaints always is that their setup is sufficient for 99 % of customers and they don't see it worthy to support the 1 % of trouble-making customers (which is kind of same argumentation others use for not deploying IPv6 at all).
That's exactly the aim of this document, thnx for pointing it out, Ondřej Cheers from Abidjan, Jan
Hello, a few (late) comments: 3.1.1: When exactly is this a good idea and why reference an old draft?(We have 6164) 3.1.4 ULA: Since numerous problems may be caused by this approach, I believe that more than one should be mentioned 3.2.1: users not being able to use all 4 hex digits can lead to erroneous allocations outside of /56? This sounds a bit stretched 3.2.1: which mechanisms use a default /48 prefix size? Could you please elaborate a bit? 3.2.2: /48 for all is most practical & most pragmatic? How many /32 we need to burn for our end users? We have ~1.6M residential users and our /29 is definitely not enough. Is RIPE onboard with that? 4.2. even though I generally agree that dynamic assignments have more disadvantages (than benefits), the need to have a logging system is usually not one of them, as most (if not all) ISPs have that covered long before IPv6 (e.g. RADIUS accounting) As more general final comment, I believe that such a document would definitely benefit operators just starting out cheers, Yannis On 03/27/2017 04:32 PM, Jan Zorz - Go6 wrote:
Dear RIPE IPv6 WG,
As promised at last RIPE meeting in Madrid, we produced a first draft of "Best Current Operational Practice for operators: IPv6 prefix assignment for end-users - static (stable) or dynamic (non-stable) and what size to choose."
The aim of this document is to document the best current operational practice on what size of IPv6 prefix ISPs should assign/delegate to their customers and should they delegate it in a stable, static way or should it change over time.
Please find the PDF attached and also accessible at:
https://www.sinog.si/docs/draft-IPv6pd-BCOP-v1.pdf
We are submitting this document to RIPE IPv6 WG (here) to check the technical validity of the document and also get consensus on it. We are also submitting it to RIPE BCOP TF to check if this is a real best operational practice and get consensus on it there.
Please, read the document and send back comments to this mailing list. All feedback is more than welcome.
On behalf of co-authors, Jan Ε½orΕΎ
P.S: This document is not intended to document what practices may be in future and what they might look like, but to reflect the best methods of implementing IPv6 at the time of publication. Updates to this document will be published to reflect changes in best current practices where there are developments in standards and implementations.
On 11/04/2017 10:40, Yannis Nikolopoulos wrote:
Hello,
Hey, Thnx for your time and effort to read the draft, much appreciated!
a few (late) comments:
3.1.1: When exactly is this a good idea and why reference an old draft?(We have 6164) 3.1.4 ULA: Since numerous problems may be caused by this approach, I believe that more than one should be mentioned
Any suggestion what to add (and not to make it too long)?
3.2.1: users not being able to use all 4 hex digits can lead to erroneous allocations outside of /56? This sounds a bit stretched
People does strange things ;)
3.2.1: which mechanisms use a default /48 prefix size? Could you please elaborate a bit?
That was some tunneling mechanisms, Jordi can explore more. I would just remove that section, but Jordi wants to elaborate on this ;)
3.2.2: /48 for all is most practical & most pragmatic? How many /32 we need to burn for our end users? We have ~1.6M residential users and our /29 is definitely not enough. Is RIPE onboard with that?
Why not ;) If you burn your IPv6 space, you get new allocation. This should not be a problem, specially because RIPE NCC default mathematics is based on /48-per-customer, at least that's what I remember.
4.2. even though I generally agree that dynamic assignments have more disadvantages (than benefits), the need to have a logging system is usually not one of them, as most (if not all) ISPs have that covered long before IPv6 (e.g. RADIUS accounting)
ack.
As more general final comment, I believe that such a document would definitely benefit operators just starting out
Thnx!!! Cheers, Jan
cheers, Yannis
On 03/27/2017 04:32 PM, Jan Zorz - Go6 wrote:
Dear RIPE IPv6 WG,
As promised at last RIPE meeting in Madrid, we produced a first draft of "Best Current Operational Practice for operators: IPv6 prefix assignment for end-users - static (stable) or dynamic (non-stable) and what size to choose."
The aim of this document is to document the best current operational practice on what size of IPv6 prefix ISPs should assign/delegate to their customers and should they delegate it in a stable, static way or should it change over time.
Please find the PDF attached and also accessible at:
https://www.sinog.si/docs/draft-IPv6pd-BCOP-v1.pdf
We are submitting this document to RIPE IPv6 WG (here) to check the technical validity of the document and also get consensus on it. We are also submitting it to RIPE BCOP TF to check if this is a real best operational practice and get consensus on it there.
Please, read the document and send back comments to this mailing list. All feedback is more than welcome.
On behalf of co-authors, Jan Ε½orΕΎ
P.S: This document is not intended to document what practices may be in future and what they might look like, but to reflect the best methods of implementing IPv6 at the time of publication. Updates to this document will be published to reflect changes in best current practices where there are developments in standards and implementations.
I guess some of those questions have already been improved in the latest edits last week. Maybe we should publish them so people is commenting from the last version? Saludos, Jordi -----Mensaje original----- De: ipv6-wg <ipv6-wg-bounces@ripe.net> en nombre de Jan Zorz - Go6 <jan@go6.si> Responder a: <jan@go6.si> Fecha: martes, 11 de abril de 2017, 10:53 Para: <ipv6-wg@ripe.net> Asunto: Re: [ipv6-wg] IPv6 prefix delegation BCOP document available for comments and suggestions On 11/04/2017 10:40, Yannis Nikolopoulos wrote: > Hello, Hey, Thnx for your time and effort to read the draft, much appreciated! > > a few (late) comments: > > 3.1.1: When exactly is this a good idea and why reference an old > draft?(We have 6164) > 3.1.4 ULA: Since numerous problems may be caused by this approach, I > believe that more than one should be mentioned Any suggestion what to add (and not to make it too long)? > 3.2.1: users not being able to use all 4 hex digits can lead to > erroneous allocations outside of /56? This sounds a bit stretched People does strange things ;) > 3.2.1: which mechanisms use a default /48 prefix size? Could you please > elaborate a bit? That was some tunneling mechanisms, Jordi can explore more. I would just remove that section, but Jordi wants to elaborate on this ;) > 3.2.2: /48 for all is most practical & most pragmatic? How many /32 we > need to burn for our end users? We have ~1.6M residential users and our > /29 is definitely not enough. Is RIPE onboard with that? Why not ;) If you burn your IPv6 space, you get new allocation. This should not be a problem, specially because RIPE NCC default mathematics is based on /48-per-customer, at least that's what I remember. > 4.2. even though I generally agree that dynamic assignments have more > disadvantages (than benefits), the need to have a logging system is > usually not one of them, as most (if not all) ISPs have that covered > long before IPv6 (e.g. RADIUS accounting) ack. > > As more general final comment, I believe that such a document would > definitely benefit operators just starting out Thnx!!! Cheers, Jan > > cheers, > Yannis > > On 03/27/2017 04:32 PM, Jan Zorz - Go6 wrote: >> Dear RIPE IPv6 WG, >> >> As promised at last RIPE meeting in Madrid, we produced a first draft of >> "Best Current Operational Practice for operators: IPv6 prefix assignment >> for end-users - static (stable) or dynamic (non-stable) and what size to >> choose." >> >> The aim of this document is to document the best current operational >> practice on what size of IPv6 prefix ISPs should assign/delegate to >> their customers and should they delegate it in a stable, static way or >> should it change over time. >> >> Please find the PDF attached and also accessible at: >> >> https://www.sinog.si/docs/draft-IPv6pd-BCOP-v1.pdf >> >> We are submitting this document to RIPE IPv6 WG (here) to check the >> technical validity of the document and also get consensus on it. We are >> also submitting it to RIPE BCOP TF to check if this is a >> real best operational practice and get consensus on it there. >> >> Please, read the document and send back comments to this mailing list. >> All feedback is more than welcome. >> >> On behalf of co-authors, Jan Ε½orΕΎ >> >> P.S: This document is not intended to document what practices may >> be in future and what they might look like, but to reflect the best >> methods of implementing IPv6 at the time of publication. Updates to this >> document will be published to reflect changes in best current practices >> where there are developments in standards and implementations. > > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company 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 11/04/2017 10:56, JORDI PALET MARTINEZ wrote:
I guess some of those questions have already been improved in the latest edits last week. Maybe we should publish them so people is commenting from the last version?
Hey, Jordi Yes, I'm aware of that, but I would not like to create confusion. Let's collect the feedback, do the edit cycle and publish the second version of the draft that people can go and read again and comment. Having a semi-baked intermediate versions between full edit-cycle versions would just create confusion. Cheers, Jan
Saludos, Jordi
-----Mensaje original----- De: ipv6-wg <ipv6-wg-bounces@ripe.net> en nombre de Jan Zorz - Go6 <jan@go6.si> Responder a: <jan@go6.si> Fecha: martes, 11 de abril de 2017, 10:53 Para: <ipv6-wg@ripe.net> Asunto: Re: [ipv6-wg] IPv6 prefix delegation BCOP document available for comments and suggestions
On 11/04/2017 10:40, Yannis Nikolopoulos wrote:
Hello,
Hey,
Thnx for your time and effort to read the draft, much appreciated!
a few (late) comments:
3.1.1: When exactly is this a good idea and why reference an old draft?(We have 6164) 3.1.4 ULA: Since numerous problems may be caused by this approach, I believe that more than one should be mentioned
Any suggestion what to add (and not to make it too long)?
3.2.1: users not being able to use all 4 hex digits can lead to erroneous allocations outside of /56? This sounds a bit stretched
People does strange things ;)
3.2.1: which mechanisms use a default /48 prefix size? Could you please elaborate a bit?
That was some tunneling mechanisms, Jordi can explore more. I would just remove that section, but Jordi wants to elaborate on this ;)
3.2.2: /48 for all is most practical & most pragmatic? How many /32 we need to burn for our end users? We have ~1.6M residential users and our /29 is definitely not enough. Is RIPE onboard with that?
Why not ;) If you burn your IPv6 space, you get new allocation. This should not be a problem, specially because RIPE NCC default mathematics is based on /48-per-customer, at least that's what I remember.
4.2. even though I generally agree that dynamic assignments have more disadvantages (than benefits), the need to have a logging system is usually not one of them, as most (if not all) ISPs have that covered long before IPv6 (e.g. RADIUS accounting)
ack.
As more general final comment, I believe that such a document would definitely benefit operators just starting out
Thnx!!!
Cheers, Jan
cheers, Yannis
On 03/27/2017 04:32 PM, Jan Zorz - Go6 wrote:
Dear RIPE IPv6 WG,
As promised at last RIPE meeting in Madrid, we produced a first draft of "Best Current Operational Practice for operators: IPv6 prefix assignment for end-users - static (stable) or dynamic (non-stable) and what size to choose."
The aim of this document is to document the best current operational practice on what size of IPv6 prefix ISPs should assign/delegate to their customers and should they delegate it in a stable, static way or should it change over time.
Please find the PDF attached and also accessible at:
https://www.sinog.si/docs/draft-IPv6pd-BCOP-v1.pdf
We are submitting this document to RIPE IPv6 WG (here) to check the technical validity of the document and also get consensus on it. We are also submitting it to RIPE BCOP TF to check if this is a real best operational practice and get consensus on it there.
Please, read the document and send back comments to this mailing list. All feedback is more than welcome.
On behalf of co-authors, Jan Ε½orΕΎ
P.S: This document is not intended to document what practices may be in future and what they might look like, but to reflect the best methods of implementing IPv6 at the time of publication. Updates to this document will be published to reflect changes in best current practices where there are developments in standards and implementations.
********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company
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 Tue, Apr 11, 2017, at 10:53, Jan Zorz - Go6 wrote:
3.2.1: which mechanisms use a default /48 prefix size? Could you please elaborate a bit?
That was some tunneling mechanisms, Jordi can explore more. I would just remove that section, but Jordi wants to elaborate on this ;)
Years ago I had to deal a little bit with Microsoft DirectAccess which was expecting /48, no more, no less. Not sure about the status today. -- Radu-Adrian FEURDEAN
On Tue, 11 Apr 2017, Yannis Nikolopoulos wrote:
3.2.2: /48 for all is most practical & most pragmatic? How many /32 we need to burn for our end users? We have ~1.6M residential users and our /29 is definitely not enough. Is RIPE onboard with that?
Yes. /48 per site is ok as per all IETF and RIPE documents I am aware of. So if your /29 is too small for your customer base, go get another one. I know ISPs who returned their /29 before they even started serious deployment, and received larger space. I encourage people to do just this. -- Mikael Abrahamsson email: swmike@swm.pp.se
On 04/11/2017 11:57 AM, Mikael Abrahamsson wrote:
On Tue, 11 Apr 2017, Yannis Nikolopoulos wrote:
3.2.2: /48 for all is most practical & most pragmatic? How many /32 we need to burn for our end users? We have ~1.6M residential users and our /29 is definitely not enough. Is RIPE onboard with that?
Yes. /48 per site is ok as per all IETF and RIPE documents I am aware of.
So if your /29 is too small for your customer base, go get another one. I know ISPs who returned their /29 before they even started serious deployment, and received larger space. I encourage people to do just this.
That's great to hear but when we upgraded our /32 to a /29 (~2011), this was not the case unfortunately (meaning that RIPE would not accept our long term addressing plan as a reason enough to get multiple /29s
Hi Yanis, That sounds surprising, but in any case, a few weeks ago, a new policy proposal to facilitate this has been approved. I think is already implemented or it will a matter of a few days, so you should not have any problem at all to justify an allocation for 1.6 millions of customers or even much more, with a /48. Regards, Jordi -----Mensaje original----- De: ipv6-wg <ipv6-wg-bounces@ripe.net> en nombre de Yannis Nikolopoulos <dez@otenet.gr> Responder a: <dez@otenet.gr> Fecha: martes, 11 de abril de 2017, 11:24 Para: Mikael Abrahamsson <swmike@swm.pp.se> CC: Jan Zorz - Go6 <jan@go6.si>, "ipv6-wg@ripe.net" <ipv6-wg@ripe.net> Asunto: Re: [ipv6-wg] IPv6 prefix delegation BCOP document available for comments and suggestions On 04/11/2017 11:57 AM, Mikael Abrahamsson wrote: > On Tue, 11 Apr 2017, Yannis Nikolopoulos wrote: > >> 3.2.2: /48 for all is most practical & most pragmatic? How many /32 we >> need to burn for our end users? We have ~1.6M residential users and >> our /29 is definitely not enough. Is RIPE onboard with that? > > Yes. /48 per site is ok as per all IETF and RIPE documents I am aware of. > > So if your /29 is too small for your customer base, go get another one. > I know ISPs who returned their /29 before they even started serious > deployment, and received larger space. I encourage people to do just this. > That's great to hear but when we upgraded our /32 to a /29 (~2011), this was not the case unfortunately (meaning that RIPE would not accept our long term addressing plan as a reason enough to get multiple /29s ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company 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.
Hi Yanis, All, On Tue, 11 Apr 2017, JORDI PALET MARTINEZ wrote:
Hi Yanis,
That sounds surprising, but in any case, a few weeks ago, a new policy proposal to facilitate this has been approved. I think is already implemented or it will a matter of a few days, so you should not have any problem at all to justify an allocation for 1.6 millions of customers or even much more, with a /48.
i.e. this message....... (if the estimation was correct, the announcement will happen very soon!) =========================== Date: Thu, 30 Mar 2017 15:04:06 From: Marco Schmidt <mschmidt@ripe.net> To: address-policy-wg@ripe.net Subject: [address-policy-wg] 2016-05 Proposal Accepted (Synchronising the Initial and Subsequent IPv6 Allocation Policies) Dear colleagues, Consensus has been reached on 2016-05, "Synchronising the Initial and Subsequent IPv6 Allocation Policies". This policy change matches the subsequent IPv6 allocation requirements with the initial allocation requirements. In addition to the existing justification based on past utilisation, it is now also possible to document new needs, including the number of users, the extent of the organisation's infrastructure, the hierarchical and geographical structuring of the organisation, the segmentation of infrastructure for security and the planned longevity of the allocation. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2016-05 The new RIPE Document is ripe-684 and is available at: https://www.ripe.net/publications/docs/ripe-684 We estimate that this proposal will take around two weeks to fully implement. We will send another announcement once the implementation is complete and the new procedures are in place. Thank you to everyone who provided input. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC =========================== Cheers, Carlos
Regards, Jordi
-----Mensaje original----- De: ipv6-wg <ipv6-wg-bounces@ripe.net> en nombre de Yannis Nikolopoulos <dez@otenet.gr> Responder a: <dez@otenet.gr> Fecha: martes, 11 de abril de 2017, 11:24 Para: Mikael Abrahamsson <swmike@swm.pp.se> CC: Jan Zorz - Go6 <jan@go6.si>, "ipv6-wg@ripe.net" <ipv6-wg@ripe.net> Asunto: Re: [ipv6-wg] IPv6 prefix delegation BCOP document available for comments and suggestions
On 04/11/2017 11:57 AM, Mikael Abrahamsson wrote:
On Tue, 11 Apr 2017, Yannis Nikolopoulos wrote:
3.2.2: /48 for all is most practical & most pragmatic? How many /32 we need to burn for our end users? We have ~1.6M residential users and our /29 is definitely not enough. Is RIPE onboard with that?
Yes. /48 per site is ok as per all IETF and RIPE documents I am aware of.
So if your /29 is too small for your customer base, go get another one. I know ISPs who returned their /29 before they even started serious deployment, and received larger space. I encourage people to do just this.
That's great to hear but when we upgraded our /32 to a /29 (~2011), this was not the case unfortunately (meaning that RIPE would not accept our long term addressing plan as a reason enough to get multiple /29s
********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company
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.
Carlos, Jordi, thank you both for the heads up (I'm a little behind on the policy mailing list) On 04/12/2017 01:28 AM, Carlos Friacas wrote:
Hi Yanis, All,
On Tue, 11 Apr 2017, JORDI PALET MARTINEZ wrote:
Hi Yanis,
That sounds surprising, but in any case, a few weeks ago, a new policy proposal to facilitate this has been approved. I think is already implemented or it will a matter of a few days, so you should not have any problem at all to justify an allocation for 1.6 millions of customers or even much more, with a /48.
i.e. this message....... (if the estimation was correct, the announcement will happen very soon!)
=========================== Date: Thu, 30 Mar 2017 15:04:06 From: Marco Schmidt <mschmidt@ripe.net> To: address-policy-wg@ripe.net Subject: [address-policy-wg] 2016-05 Proposal Accepted (Synchronising the Initial and Subsequent IPv6 Allocation Policies)
Dear colleagues,
Consensus has been reached on 2016-05, "Synchronising the Initial and Subsequent IPv6 Allocation Policies".
This policy change matches the subsequent IPv6 allocation requirements with the initial allocation requirements. In addition to the existing justification based on past utilisation, it is now also possible to document new needs, including the number of users, the extent of the organisation's infrastructure, the hierarchical and geographical structuring of the organisation, the segmentation of infrastructure for security and the planned longevity of the allocation.
You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2016-05
The new RIPE Document is ripe-684 and is available at: https://www.ripe.net/publications/docs/ripe-684
We estimate that this proposal will take around two weeks to fully implement.
We will send another announcement once the implementation is complete and the new procedures are in place.
Thank you to everyone who provided input.
Kind regards,
Marco Schmidt Policy Development Officer RIPE NCC ===========================
Cheers, Carlos
Regards, Jordi
-----Mensaje original----- De: ipv6-wg <ipv6-wg-bounces@ripe.net> en nombre de Yannis Nikolopoulos <dez@otenet.gr> Responder a: <dez@otenet.gr> Fecha: martes, 11 de abril de 2017, 11:24 Para: Mikael Abrahamsson <swmike@swm.pp.se> CC: Jan Zorz - Go6 <jan@go6.si>, "ipv6-wg@ripe.net" <ipv6-wg@ripe.net> Asunto: Re: [ipv6-wg] IPv6 prefix delegation BCOP document available for comments and suggestions
On 04/11/2017 11:57 AM, Mikael Abrahamsson wrote:
On Tue, 11 Apr 2017, Yannis Nikolopoulos wrote:
3.2.2: /48 for all is most practical & most pragmatic? How many /32 we need to burn for our end users? We have ~1.6M residential users and our /29 is definitely not enough. Is RIPE onboard with that?
Yes. /48 per site is ok as per all IETF and RIPE documents I am aware of.
So if your /29 is too small for your customer base, go get another one. I know ISPs who returned their /29 before they even started serious deployment, and received larger space. I encourage people to do just this.
That's great to hear but when we upgraded our /32 to a /29 (~2011), this was not the case unfortunately (meaning that RIPE would not accept our long term addressing plan as a reason enough to get multiple /29s
********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company
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 (13)
-
Carlos Friacas -
Claudio Ferronato -
Gert Doering -
Ivan Pepelnjak -
Jan Zorz - Go6 -
JORDI PALET MARTINEZ -
Matthias Kluth -
Mikael Abrahamsson -
Nick Hilliard -
Ondřej Caletka -
Philip Homburg -
Radu-Adrian FEURDEAN -
Yannis Nikolopoulos