Apropos of one of those endless arguments on the Internet (where everything is true, because it says it on the Internet), I had a discussion with Kurtis about the definition of an ipv6 "End Site", which is specified in section 2.9 of RIPE-655. This says:
2.9. End Site
An End Site is defined as an End User (subscriber) who has a business or legal relationship (same or associated entities) with a service provider that involves:
- that service provider assigning address space to the End User - that service provider providing transit service for the End User to other sites - that service provider carrying the End User's traffic - that service provider advertising an aggregate prefix route that contains the End User's assignment
Our reading of this is that each of these conditions is mandatory, i.e. logical AND, because logical OR does not make sense. Term 2.9.2 states that an ipv6 End Site is only an End Site if the service provider is providing transit service for the End User to other sites. Section 5.4 and 5.4.1 then state:
LIRs must make IPv6 assignments in accordance with the following provisions.
End Users are assigned an End Site assignment from their LIR or ISP.
So the policy appears to state that an IPv6 assignment can only be issued to an end user if the end user has a transit service to more than one site, presumably ipv4 because demanding ipv6 connectivity would create a circular requirement. In other words, ipv4 connectivity to multiple different sites appears to be a mandatory prerequisite in order to get an IPv6 assignment. Could someone in the RIPE NCC please confirm that this policy is being policed as stated? And if not, when can we expect all non-compliant assignments in the RIPE NCC service region to be revoked? Nick
Dear Nick, Thank you for raising this question. On 2016-06-22 15:37:17 CET, Nick Hilliard wrote:
2.9. End Site
An End Site is defined as an End User (subscriber) who has a business or legal relationship (same or associated entities) with a service provider that involves:
- that service provider assigning address space to the End User - that service provider providing transit service for the End User to other sites - that service provider carrying the End User's traffic - that service provider advertising an aggregate prefix route that contains the End User's assignment
Our reading of this is that each of these conditions is mandatory, i.e. logical AND, because logical OR does not make sense. Term 2.9.2 states that an ipv6 End Site is only an End Site if the service provider is providing transit service for the End User to other sites.
The RIPE NCC's current understanding is that the points in the list in section 2.9 are seen as logical OR, with the first point "assigning address space" as the mandatory one. The other requirements are considered optional. For example, it seems reasonable for an LIR to provide address space to an End User, while the End User takes care themselves for routing and traffic management. If all points were mandatory, it would be extremely difficult for service providers to make IPv6 assignments. For example, only End Users with multiple sites would be entitled to receive an IPv6 assignment. This seems to be against the spirit of the IPv6 policy, which aims to allow networks to access IPv6. If the RIPE community disagrees with this understanding or feels that the current wording of section 2.9 is ambiguous, we invite a policy proposal that provides an adjusted End Site definition. I hope this clarifies. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum
Marco Schmidt wrote:
If the RIPE community disagrees with this understanding or feels that the current wording of section 2.9 is ambiguous, we invite a policy proposal that provides an adjusted End Site definition.
I hope this clarifies.
Hi Marco, Thanks for clarifying. The alternative was awkward: http://i.imgur.com/J8vJwYR.jpg It looks like the interpretation and the wording are slightly at variance, albeit in favour of common sense, so the wording should probably be regarded as a policy bug which needs to be fixed. Nick
Hi, On Wed, Jun 22, 2016 at 08:31:52PM +0100, Nick Hilliard wrote:
It looks like the interpretation and the wording are slightly at variance, albeit in favour of common sense, so the wording should probably be regarded as a policy bug which needs to be fixed.
It's very very old text which came from the very first version of the IPv6 policy (and nobody ever dared touch the definition of "site", because there's endless ratholing). But maybe now is the time to go where no man has gone this year, and propose an IPv6 related policy proposal - any volunteers? :-) Gert Doering -- APWG chair -- 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
Gert Doering wrote:
But maybe now is the time to go where no man has gone this year, and propose an IPv6 related policy proposal - any volunteers? :-)
I'll take a look at it. Nick
let's also chip in the possibility to make /64 assignments while redefining the definition. plenty that keep coming at the RIPE Meeting with all kind of cases where they want to use IPv6 (PI) but membership is not accesible. https://ripe72.ripe.net/presentations/114-RIPE72-IPv6-PI.pdf /elvis Excuse the briefness of this mail, it was sent from a mobile device.
On Jun 22, 2016, at 23:40, Nick Hilliard <nick@foobar.org> wrote:
Gert Doering wrote:
But maybe now is the time to go where no man has gone this year, and propose an IPv6 related policy proposal - any volunteers? :-)
I'll take a look at it.
Nick
On 22 Jun 2016, at 21:49, Elvis Daniel Velea <elvis@velea.eu> wrote:
let's also chip in the possibility to make /64 assignments while redefining the definition. plenty that keep coming at the RIPE Meeting with all kind of cases where they want to use IPv6 (PI) but membership is not accesible.
https://ripe72.ripe.net/presentations/114-RIPE72-IPv6-PI.pdf
I think that is a orthogonally different problem though, and therefor are two different policy proposals. Best Regards, - kurtis -
Hi, On Wed, Jun 22, 2016 at 11:49:35PM +0300, Elvis Daniel Velea wrote:
let's also chip in the possibility to make /64 assignments while redefining the definition. plenty that keep coming at the RIPE Meeting with all kind of cases where they want to use IPv6 (PI) but membership is not accesible.
https://ripe72.ripe.net/presentations/114-RIPE72-IPv6-PI.pdf
No, IPv6 PI policy is a different topic and needs to be covered by a different proposal. 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
Hi, Excuse the briefness of this mail, it was sent from a mobile device.
On Jun 23, 2016, at 09:26, Gert Doering <gert@space.net> wrote:
Hi,
On Wed, Jun 22, 2016 at 11:49:35PM +0300, Elvis Daniel Velea wrote: let's also chip in the possibility to make /64 assignments while redefining the definition. plenty that keep coming at the RIPE Meeting with all kind of cases where they want to use IPv6 (PI) but membership is not accesible.
https://ripe72.ripe.net/presentations/114-RIPE72-IPv6-PI.pdf
No, IPv6 PI policy is a different topic and needs to be covered by a different proposal.
I only proposed this because in my mind it could have easily been solved when redefining the end site definition. /elvis
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
Hi, On Thu, Jun 23, 2016 at 12:48:22PM +0300, Elvis Daniel Velea wrote:
No, IPv6 PI policy is a different topic and needs to be covered by a different proposal.
I only proposed this because in my mind it could have easily been solved when redefining the end site definition.
No. This is a totally different part of the policy that disallows sub-assignments. 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 22 Jun 2016, at 21:40, Nick Hilliard <nick@foobar.org> wrote:
Gert Doering wrote:
But maybe now is the time to go where no man has gone this year, and propose an IPv6 related policy proposal - any volunteers? :-)
I'll take a look at it.
I’d be happy to help Nick! /Feeling slightly guilty Best Regards, - kurtis -
participants (5)
-
Elvis Daniel Velea -
Gert Doering -
Kurt Erik Lindqvist -
Marco Schmidt -
Nick Hilliard