RIPE Policy vs IETF RFC
Dear colleagues, As you might know, the current IPv6 policy states very clear that assignments to customers must be a minimum of a /64. 5.4.1. Assignment address space size End Users are assigned an End Site assignment from their LIR or ISP. The size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (only one subnet is anticipated for the End Site). https://www.ripe.net/publications/docs/ripe-655 On the other hand, a while ago, RFC7608 (BCP198) was published, stating: 2. Recommendation IPv6 implementations MUST conform to the rules specified in Section 5.1 of [RFC4632]. Decision-making processes for forwarding MUST NOT restrict the length of IPv6 prefixes by design. In particular, forwarding processes MUST be designed to process prefixes of any length up to /128, by increments of 1. In practice, this means that the RFC suggests that a customer can get an IPv6 assignment of any size, while the RIPE policy says the minimum should be a /64. I’m interested to know what the community thinks about this and if alignment between this RFC and the RIPE policy is needed. Nathalie Künneke-Trenaman IPv6 Program Manager RIPE NCC
On Mon, Jun 13, 2016 at 11:53 AM, Nathalie Trenaman <nathalie@ripe.net> wrote:
Dear colleagues,
As you might know, the current IPv6 policy states very clear that assignments to customers must be a minimum of a /64.
5.4.1. Assignment address space size
End Users are assigned an End Site assignment from their LIR or ISP. The size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (only one subnet is anticipated for the End Site).
https://www.ripe.net/publications/docs/ripe-655
On the other hand, a while ago, RFC7608 (BCP198) was published, stating:
2. Recommendation IPv6 implementations MUST conform to the rules specified in Section 5.1 of [RFC4632].
Decision-making processes for forwarding MUST NOT restrict the length of IPv6 prefixes by design. In particular, forwarding processes MUST be designed to process prefixes of any length up to /128, by increments of 1.
In practice, this means that the RFC suggests that a customer can get an IPv6 assignment of any size, while the RIPE policy says the minimum should be a /64. I’m interested to know what the community thinks about this and if alignment between this RFC and the RIPE policy is needed.
I would say, please don't mix implementation with actual usage. I can run 100 000 x /128 internal while only have 2 x /48 external. -- Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no
Le 13 juin 2016 à 11:58, Roger Jørgensen <rogerj@gmail.com> a écrit :
I would say, please don't mix implementation with actual usage. I can run 100 000 x /128 internal while only have 2 x /48 external.
+1 Even if I don’t see a reason at the moment to assign a /128 to a customer, there could be one in the future, so I don’t think RIPE should try to enforce any policy as it doesn’t have any negative impact on the Internet. This is valid as long as the IPv6 address space stays aggregated, and that the maximum prefix length allowed in the global routing table is /48 (or else, as it seems there is no unanimity on this). Perhaps there should be a formal recommendation/policy about the maximum prefix length any AS should accept. David Ponzone Direction Technique email: david.ponzone@ipeva.fr <mailto:david.ponzone@ipeva.fr> tel: 01 74 03 18 97 gsm: 06 66 98 76 34 Service Client IPeva tel: 0811 46 26 26 www.ipeva.fr <blocked::http://www.ipeva.fr/> - www.ipeva-studio.com <blocked::http://www.ipeva-studio.com/> Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisée est interdite. Tout message électronique est susceptible d'altération. IPeva décline toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié. Si vous n'êtes pas destinataire de ce message, merci de le détruire immédiatement et d'avertir l'expéditeur.
Hi, On Mon, Jun 13, 2016 at 11:53:18AM +0200, Nathalie Trenaman wrote:
In practice, this means that the RFC suggests that a customer can get an IPv6 assignment of any size,
No. It says that if you happen to feel like routing a /128 out of your assignment somewhere else (like, for an anycast service bound to a single service IP), your routing gear must permit it. 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
Nathalie,
As you might know, the current IPv6 policy states very clear that assignments to customers must be a minimum of a /64.
5.4.1. Assignment address space size
End Users are assigned an End Site assignment from their LIR or ISP. The size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (only one subnet is anticipated for the End Site).
https://www.ripe.net/publications/docs/ripe-655
On the other hand, a while ago, RFC7608 (BCP198) was published, stating:
2. Recommendation IPv6 implementations MUST conform to the rules specified in Section 5.1 of [RFC4632].
Decision-making processes for forwarding MUST NOT restrict the length of IPv6 prefixes by design. In particular, forwarding processes MUST be designed to process prefixes of any length up to /128, by increments of 1.
In practice, this means that the RFC suggests that a customer can get an IPv6 assignment of any size, while the RIPE policy says the minimum should be a /64. I’m interested to know what the community thinks about this and if alignment between this RFC and the RIPE policy is needed.
That is an interpretation of RFC7608 that I hope is not common. RFC7608 is written for the purpose of ensuring that forwarding engines (and routing protocols) are built so that they can handle any prefix length. Apparently some implementations treated IPv6 as classful, and only supported forwarding of prefix lengths from 0-64 and 128. RFC7608 has absolutely nothing to do with end-site address assignment. The IETF consensus on that is in RFC6177. Best regards, Ole
Hi Ole, Gert, David and Roger,
In practice, this means that the RFC suggests that a customer can get an IPv6 assignment of any size, while the RIPE policy says the minimum should be a /64. I’m interested to know what the community thinks about this and if alignment between this RFC and the RIPE policy is needed.
That is an interpretation of RFC7608 that I hope is not common. RFC7608 is written for the purpose of ensuring that forwarding engines (and routing protocols) are built so that they can handle any prefix length. Apparently some implementations treated IPv6 as classful, and only supported forwarding of prefix lengths from 0-64 and 128. RFC7608 has absolutely nothing to do with end-site address assignment. The IETF consensus on that is in RFC6177.
Best regards, Ole
Thanks for your clarifications. The reason why I brought this up on the list, is that this RFC caused some discussion internally and externally and I wanted to verify that we’re all still on the same page. I agree that routing and end-site address assignment are two different things and I’m happy to see we are in agreement. Regards, Nathalie
On 13 Jun 2016, at 11:36, Nathalie Trenaman <nathalie@ripe.net> wrote:
Hi Ole, Gert, David and Roger,
In practice, this means that the RFC suggests that a customer can get an IPv6 assignment of any size, while the RIPE policy says the minimum should be a /64. I’m interested to know what the community thinks about this and if alignment between this RFC and the RIPE policy is needed.
That is an interpretation of RFC7608 that I hope is not common. RFC7608 is written for the purpose of ensuring that forwarding engines (and routing protocols) are built so that they can handle any prefix length. Apparently some implementations treated IPv6 as classful, and only supported forwarding of prefix lengths from 0-64 and 128. RFC7608 has absolutely nothing to do with end-site address assignment. The IETF consensus on that is in RFC6177.
Best regards, Ole
Thanks for your clarifications. The reason why I brought this up on the list, is that this RFC caused some discussion internally and externally and I wanted to verify that we’re all still on the same page. I agree that routing and end-site address assignment are two different things and I’m happy to see we are in agreement.
Please excuse me while I delurk. The following text is from RFC 4291: All Global Unicast addresses other than those that start with binary 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as described in Section 2.5.1. Global Unicast addresses that start with binary 000 have no such constraint on the size or structure of the interface ID field. That is written without MUST or SHOULD, and has been at least partly overtaken by RFC 6164 ('Using 127-Bit IPv6 Prefixes on Inter-Router Links', though 6164 is not noted as updating 4291), but it does seem a very definite statement. Has it been modified anywhere else? Sam -- Sam Wilson Communications Infrastructure Section, IT Infrastructure Information Services, The University of Edinburgh Edinburgh, Scotland, UK The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
Hi,
On 13 Jun 2016, at 11:26, Ole Troan <ot@cisco.com> wrote:
Nathalie,
As you might know, the current IPv6 policy states very clear that assignments to customers must be a minimum of a /64.
5.4.1. Assignment address space size
End Users are assigned an End Site assignment from their LIR or ISP. The size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (only one subnet is anticipated for the End Site).
https://www.ripe.net/publications/docs/ripe-655
On the other hand, a while ago, RFC7608 (BCP198) was published, stating:
2. Recommendation IPv6 implementations MUST conform to the rules specified in Section 5.1 of [RFC4632].
Decision-making processes for forwarding MUST NOT restrict the length of IPv6 prefixes by design. In particular, forwarding processes MUST be designed to process prefixes of any length up to /128, by increments of 1.
In practice, this means that the RFC suggests that a customer can get an IPv6 assignment of any size, while the RIPE policy says the minimum should be a /64. I’m interested to know what the community thinks about this and if alignment between this RFC and the RIPE policy is needed.
That is an interpretation of RFC7608 that I hope is not common. RFC7608 is written for the purpose of ensuring that forwarding engines (and routing protocols) are built so that they can handle any prefix length. Apparently some implementations treated IPv6 as classful, and only supported forwarding of prefix lengths from 0-64 and 128. RFC7608 has absolutely nothing to do with end-site address assignment. The IETF consensus on that is in RFC6177.
RFC 7421 (“Why /64?”) is also relevant here, I think. Tim
Hi Nathalie, If it helps, the survey (http://survey.consulintel.es/index.php/175122) responses indicate right now (from 703 responses, about 200 from RIPE, missing responses from Russia that has got very few), only 76 ISPs providing /64, the rest is shared almost 50/50 among /48 and /56. I will try to get responses from Russia, Brazil, Mexico, Japan, Korea, China and India, which I guess have some deployment and almost didn’t responded at the time being. Then at the end of June, I will “clean” up duplicate responses (some times several folks respond from the same ISP). Regards, Jordi -----Mensaje original----- De: ipv6-wg <ipv6-wg-bounces@ripe.net> en nombre de Nathalie Trenaman <nathalie@ripe.net> Responder a: <nathalie@ripe.net> Fecha: lunes, 13 de junio de 2016, 4:53 Para: <ipv6-wg@ripe.net> Asunto: [ipv6-wg] RIPE Policy vs IETF RFC
Dear colleagues,
As you might know, the current IPv6 policy states very clear that assignments to customers must be a minimum of a /64.
5.4.1. Assignment address space size
End Users are assigned an End Site assignment from their LIR or ISP. The size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (only one subnet is anticipated for the End Site).
https://www.ripe.net/publications/docs/ripe-655
On the other hand, a while ago, RFC7608 (BCP198) was published, stating:
2. Recommendation IPv6 implementations MUST conform to the rules specified in Section 5.1 of [RFC4632].
Decision-making processes for forwarding MUST NOT restrict the length of IPv6 prefixes by design. In particular, forwarding processes MUST be designed to process prefixes of any length up to /128, by increments of 1.
In practice, this means that the RFC suggests that a customer can get an IPv6 assignment of any size, while the RIPE policy says the minimum should be a /64. I’m interested to know what the community thinks about this and if alignment between this RFC and the RIPE policy is needed.
Nathalie Künneke-Trenaman IPv6 Program Manager RIPE NCC
********************************************** 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 all, Thank you for your work on this Jordi, and to you Nathalie for reaching out to the community to seek input and clarification. While I do not know the ins and outs of the technical side of IPv6, I care enough about its deployment worldwide and know enough about policy to understand that incongruent policy -- either in practice or on paper -- can often create a rather massive headache. Best, -Michael __________________ Michael J. Oghia Independent consultant & editor 2015 ISOC IGF Ambassador Istanbul, Turkey Skype: mikeoghia Twitter <https://www.twitter.com/MikeOghia> *|* LinkedIn <https://www.linkedin.com/in/mikeoghia> On Mon, Jun 13, 2016 at 2:33 PM, JORDI PALET MARTINEZ < jordi.palet@consulintel.es> wrote:
Hi Nathalie,
If it helps, the survey (http://survey.consulintel.es/index.php/175122) responses indicate right now (from 703 responses, about 200 from RIPE, missing responses from Russia that has got very few), only 76 ISPs providing /64, the rest is shared almost 50/50 among /48 and /56.
I will try to get responses from Russia, Brazil, Mexico, Japan, Korea, China and India, which I guess have some deployment and almost didn’t responded at the time being.
Then at the end of June, I will “clean” up duplicate responses (some times several folks respond from the same ISP).
Regards, Jordi
-----Mensaje original----- De: ipv6-wg <ipv6-wg-bounces@ripe.net> en nombre de Nathalie Trenaman < nathalie@ripe.net> Responder a: <nathalie@ripe.net> Fecha: lunes, 13 de junio de 2016, 4:53 Para: <ipv6-wg@ripe.net> Asunto: [ipv6-wg] RIPE Policy vs IETF RFC
Dear colleagues,
As you might know, the current IPv6 policy states very clear that assignments to customers must be a minimum of a /64.
5.4.1. Assignment address space size
End Users are assigned an End Site assignment from their LIR or ISP. The size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (only one subnet is anticipated for the End Site).
https://www.ripe.net/publications/docs/ripe-655
On the other hand, a while ago, RFC7608 (BCP198) was published, stating:
2. Recommendation IPv6 implementations MUST conform to the rules specified in Section 5.1 of [RFC4632].
Decision-making processes for forwarding MUST NOT restrict the length of IPv6 prefixes by design. In particular, forwarding processes MUST be designed to process prefixes of any length up to /128, by increments of 1.
In practice, this means that the RFC suggests that a customer can get an IPv6 assignment of any size, while the RIPE policy says the minimum should be a /64. I’m interested to know what the community thinks about this and if alignment between this RFC and the RIPE policy is needed.
Nathalie Künneke-Trenaman IPv6 Program Manager RIPE NCC
********************************************** 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 (9)
-
David Ponzone -
Gert Doering -
JORDI PALET MARTINEZ -
Michael Oghia -
Nathalie Trenaman -
Ole Troan -
Roger Jørgensen -
Tim Chown -
WILSON Sam