Discussion: Do we still share a common understanding of an IPv6 End Site?
Hello AP-WG, While following IPv6-related discussions over the past few years [Such as: https://mailman.ripe.net/archives/list/address-policy-wg@ripe.net/message/FB...], I have found myself wondering whether the community still shares a common understanding of what constitutes an “End Site” in practice for IPv6 deployments. What makes something a separate end-site? *Core problem statement* Many aspects of the IPv6 assignment policy and documentation of assignments in the RIPE Database are based on assignments made to "End Sites”. The definition exists but is anchored to subscriber-location, and it's not obvious if it covers operationally or topologically distinct deployments, which is what I'd value the community's view on. That ambiguity may have been tolerable when most deployments followed relatively common patterns, but the wider range of deployment models in use today makes the lack of precision more noticeable. Operational and deployment models have evolved considerably since the original definition was introduced. I am interested in understanding whether the community believes the current interpretation remains clear and consistently understood. *Some areas where differing interpretations may exist include:* • What qualifies a deployment as a distinct end-site? Physical location only, or also operational/topological separation? • Whether an End Site is primarily a legal entity, an organization, a network, a physical location, a single end-user, or an operational deployment? • How the concept applies to distributed enterprise networks spanning multiple locations? I would be interested to hear views, examples, and operational experiences from others. -- Best regards, *Yuli Azarch*
Dear Yuli,
The definition exists but is anchored to subscriber-location, and it's not obvious if it covers operationally or topologically distinct deployments, which is what I'd value the community's view on.
That ambiguity may have been tolerable when most deployments followed relatively common patterns, but the wider range of deployment models in use today makes the lack of precision more noticeable.
Operational and deployment models have evolved considerably since the original definition was introduced.
I am interested in understanding whether the community believes the current interpretation remains clear and consistently understood.
Some areas where differing interpretations may exist include:
• What qualifies a deployment as a distinct end-site? Physical location only, or also operational/topological separation? • Whether an End Site is primarily a legal entity, an organization, a network, a physical location, a single end-user, or an operational deployment? • How the concept applies to distributed enterprise networks spanning multiple locations?
I would be interested to hear views, examples, and operational experiences from others.
Can you give the list some concrete examples of these deployment models that cause tension with the current end-site definition and/or interpretation? Providing such examples would probably be useful to serve as basis for further discussion. Best regards, Alex Le Heux APWG Co-chair
Can you give the list some concrete examples of these deployment models that cause tension with the current end-site definition and/or interpretation?
PD gone wild e.g. if <broadband provider> PDs me a /56 and i split it out to neighbors randy, hatless
On Jul 2, 2026, at 20:59, Randy Bush <randy@psg.com> wrote:
Can you give the list some concrete examples of these deployment models that cause tension with the current end-site definition and/or interpretation?
PD gone wild
e.g. if <broadband provider> PDs me a /56 and i split it out to neighbors
Ok, I'll bite :) Our current end-site definition: 2.9. End Site An End Site is defined as the location of 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 location - that service provider providing transit service for the End User location to other sites - that service provider carrying the End User's location traffic - that service provider advertising an aggregate prefix route that contains the End User's location assignment Even if the deployment model that you describe happens, I think it would be pretty rare: You could be considered a service provider if we stretch the concept a little bit. And if we apply the definition to that, we get: - You could argue that you're assigning address space to your neighbors, although it would be a sub-assignment, which is problematic. - You are providing transit to your neighbors - You are carrying your neighbors' location traffic So far so good, but: - There has to be a legal or business relationship between you and your neighbors. I'm not sure if "we're all buddies here" would qualify as such. - Given that your ISP PDs you the /56 I would say there is no BGP or anything like that involved, so you would not be advertising an aggregate prefix. So I would argue that under the current definition and the scenario you describe, your neighbors would not qualify as end-sites. And they shouldn't until you get your act together and set up a proper service provider with ASN, peering, LIR account, etc :) So I don't see much tension here. Cheers, Alex Wearing his Random Internet Nerd hat
hi alex, clearly you have not been reading the 5/6/42g marketing literature :)/2 randy
Hey Alex. Fair question. My question: Would it be useful for the community to clarify the characteristics that distinguish one End Site from another? For example, is it a physical location/premises, legal relationship, routing, operational control, or a combination of these, so LIRs and the RIPE NCC have a more consistent basis for documenting IPv6 assignments? A very simple example would be an enterprise, where one organization may operate branches, campuses, datacenter presence, security-separated environments, and different routing domains. The legal entity, physical site, operational site, and routing site may not always be the same thing. Is the boundary physical premises, or can it also be a distinct routing and administrative separation? On Thu, Jul 2, 2026 at 3:10 PM Alex Le Heux <alexlh@funk.org> wrote:
On Jul 2, 2026, at 20:59, Randy Bush <randy@psg.com> wrote:
Can you give the list some concrete examples of these deployment models that cause tension with the current end-site definition and/or interpretation?
PD gone wild
e.g. if <broadband provider> PDs me a /56 and i split it out to neighbors
Ok, I'll bite :)
Our current end-site definition:
2.9. End Site An End Site is defined as the location of 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 location - that service provider providing transit service for the End User location to other sites - that service provider carrying the End User's location traffic - that service provider advertising an aggregate prefix route that contains the End User's location assignment
Even if the deployment model that you describe happens, I think it would be pretty rare:
You could be considered a service provider if we stretch the concept a little bit. And if we apply the definition to that, we get:
- You could argue that you're assigning address space to your neighbors, although it would be a sub-assignment, which is problematic. - You are providing transit to your neighbors - You are carrying your neighbors' location traffic
So far so good, but:
- There has to be a legal or business relationship between you and your neighbors. I'm not sure if "we're all buddies here" would qualify as such. - Given that your ISP PDs you the /56 I would say there is no BGP or anything like that involved, so you would not be advertising an aggregate prefix.
So I would argue that under the current definition and the scenario you describe, your neighbors would not qualify as end-sites.
And they shouldn't until you get your act together and set up a proper service provider with ASN, peering, LIR account, etc :)
So I don't see much tension here.
Cheers,
Alex Wearing his Random Internet Nerd hat ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/address-policy-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
-- Best regards, *Yuli Azarch* CEO & Co-Founder [image: RapidSeedBox] W: *www. <https://followup.cc/l/10355620/82d48c1301f2ee846cbf37acc97cebe7/http%3A%2F%2Fwww.up-nature.com%2F>RapidSeedbox.com <https://www.rapidseedbox.com>* P: (+1)3039520447 <(303)%20952-0447>
Dear Yuli, Allow me to briefly explain how the RIPE NCC currently applies the policy in practice, as I understand you are asking whether there may be different interpretations of what constitutes an end site. The example you describe of an organisation operating multiple branches, campuses or data centres is actually not unusual. Each such physically separated network may qualify as a separate end site. Furthermore, where an individual end site has different routing requirements (for example due to security-separated environments) the IPv6 policy explicitly allows multiple assignments to that same end site. Because of this, your example appears to fit within the RIPE NCC's understanding of the existing policy framework and does not immediately illustrate where the current interpretation becomes unclear. You also mention situations where "the legal entity, physical site, operational site, and routing site may not always be the same thing." While it is clear how the location of the legal entity and the physical location of a network may differ, it is less clear what is meant by a physical, operational, and routing site being different. Could you provide a concrete example of such a deployment? Having a specific example would likely help the working group determine whether this is a question of interpreting the existing policy or whether there is a policy gap that the working group may wish to discuss. Kind regards, Marco Schmidt Manager Registration Services RIPE NCC On 03/07/2026 09:59, Yuli Azarch via address-policy-wg wrote:
Hey Alex. Fair question.
My question: Would it be useful for the community to clarify the characteristics that distinguish one End Site from another? For example, is it a physical location/premises, legal relationship, routing, operational control, or a combination of these, so LIRs and the RIPE NCC have a more consistent basis for documenting IPv6 assignments?
A very simple example would be an enterprise, where one organization may operate branches, campuses, datacenter presence, security-separated environments, and different routing domains. The legal entity, physical site, operational site, and routing site may not always be the same thing. Is the boundary physical premises, or can it also be a distinct routing and administrative separation?
On Thu, Jul 2, 2026 at 3:10 PM Alex Le Heux <alexlh@funk.org> wrote:
> On Jul 2, 2026, at 20:59, Randy Bush <randy@psg.com> wrote: > >> Can you give the list some concrete examples of these deployment >> models that cause tension with the current end-site definition and/or >> interpretation? > > PD gone wild > > e.g. if <broadband provider> PDs me a /56 and i split it out to > neighbors
Ok, I'll bite :)
Our current end-site definition:
2.9. End Site An End Site is defined as the location of 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 location - that service provider providing transit service for the End User location to other sites - that service provider carrying the End User's location traffic - that service provider advertising an aggregate prefix route that contains the End User's location assignment
Even if the deployment model that you describe happens, I think it would be pretty rare:
You could be considered a service provider if we stretch the concept a little bit. And if we apply the definition to that, we get:
- You could argue that you're assigning address space to your neighbors, although it would be a sub-assignment, which is problematic. - You are providing transit to your neighbors - You are carrying your neighbors' location traffic
So far so good, but:
- There has to be a legal or business relationship between you and your neighbors. I'm not sure if "we're all buddies here" would qualify as such. - Given that your ISP PDs you the /56 I would say there is no BGP or anything like that involved, so you would not be advertising an aggregate prefix.
So I would argue that under the current definition and the scenario you describe, your neighbors would not qualify as end-sites.
And they shouldn't until you get your act together and set up a proper service provider with ASN, peering, LIR account, etc :)
So I don't see much tension here.
Cheers,
Alex Wearing his Random Internet Nerd hat ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/address-policy-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
-- Best regards, *Yuli Azarch* CEO & Co-Founder RapidSeedBox W: _www. <https://followup.cc/l/10355620/82d48c1301f2ee846cbf37acc97cebe7/http%3A%2F%2Fwww.up-nature.com%2F>RapidSeedbox.com <https://www.rapidseedbox.com>_ P: (+1)3039520447 <tel:(303)%20952-0447>
----- To unsubscribe from this mailing list or change your subscription options, please visit:https://mailman.ripe.net/mailman3/lists/address-policy-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at:https://www.ripe.net/membership/mail/mailman-3-migration/
Hello all, Thank you, Marco. On Mon, Jul 6, 2026 at 2:36 AM Marco Schmidt <mschmidt@ripe.net> wrote:
Each such physically separated network may qualify as a separate end site. Furthermore, where an individual end site has different routing requirements (for example due to security-separated environments) the IPv6 policy explicitly allows multiple assignments to that same end site.
I would like to build on those two clarifications. To provide a concrete example, we can consider a single data-centre facility operated by one infrastructure provider. Each tenant/subscriber has a direct contractual relationship with the provider, and each environment has one stable /48. Although they share the same physical premises, the networks are separately connected and administered. One of those tenants also operates twelve persistent virtual network environments inside its tenant environment. The infrastructure provider makes the assignments directly. The environments fall into exactly three groups: - Some have their own ASN and independent routing policy. - Some share common routing domain but have their own management domain and independent operational lifecycle. - Some share the routing and management systems but are isolated by a strict security boundary with no lateral connectivity. This is intended as a concrete case where the physical site, the operational site and the routing site do not coincide. Each environment is stable and retains the same /48. Depending on the test applied, the relevant End Site could be: - The whole physical facility; - Each tenant; - Only the environments with independent routing; - Or each operationally or securely separated environment Possible directions for clarification might therefore include defining the End Site by the subscriber relationship, physical premises, routing boundary, operational domain, or an explicit combination of those factors. I would be interested in how others would classify the three groups above and which underlying test they would apply. Best Regards, Yuli
Dear Yuli, Thank you for the clarification. Let me share my understanding of the example and how the RIPE NCC would currently approach it. Hopefully, this also helps the working group discussion. My understanding is that the infrastructure provider has a contractual relationship with the tenant, which operates twelve persistent virtual network environments at the same physical location, each using a /48. As these twelve /48s are provided to a single End Site, Section 5.4.2 of the IPv6 Policy requires such total assignment exceeding /48 to be justified by address usage or different routing requirements. In the first scenario, each environment has its own ASN and independent routing policy. In such a case, the RIPE NCC would likely ask for more information about why multiple routing arrangements are required at the same location. We have seen similar cases before, and once the requirements would be sufficiently explained, they would be considered policy compliant. For the other scenarios, I don't think that an independent operational lifecycle, management domain, or security boundary by itself defines a separate End Site under the current policy. If we would encounter such situation, we would therefore want to understand why these requirements could not be accommodated within a single /48. As per current best operational practices, a /48 is intended to provide (business) customers with a sufficiently large address space for their internal network designs, such as (V)LANs, services or security zones. Consequently, these factors alone would not appear to justify assignments totalling more than a /48 to a single End Site. Did I understand the example correctly, and is this the question you would like feedback on? What do others in the working group think? Kind regards, Marco Schmidt Manager Registration Services RIPE NCC On 10/08/2026 10:00, Yuli Azarch wrote:
Hello all,
Thank you, Marco.
On Mon, Jul 6, 2026 at 2:36 AM Marco Schmidt <mschmidt@ripe.net> wrote:
Each such physically separated network may qualify as a separate end site. Furthermore, where an individual end site has different routing requirements (for example due to security-separated environments) the IPv6 policy explicitly allows multiple assignments to that same end site.
I would like to build on those two clarifications.
To provide a concrete example, we can consider a single data-centre facility operated by one infrastructure provider.
Each tenant/subscriber has a direct contractual relationship with the provider, and each environment has one stable /48. Although they share the same physical premises, the networks are separately connected and administered.
One of those tenants also operates twelve persistent virtual network environments inside its tenant environment. The infrastructure provider makes the assignments directly. The environments fall into exactly three groups:
* Some have their own ASN and independent routing policy. * Some share common routing domain but have their own management domain and independent operational lifecycle. * Some share the routing and management systems but are isolated by a strict security boundary with no lateral connectivity.
This is intended as a concrete case where the physical site, the operational site and the routing site do not coincide. Each environment is stable and retains the same /48.
Depending on the test applied, the relevant End Site could be:
* The whole physical facility; * Each tenant; * Only the environments with independent routing; * Or each operationally or securely separated environment
Possible directions for clarification might therefore include defining the End Site by the subscriber relationship, physical premises, routing boundary, operational domain, or an explicit combination of those factors.
I would be interested in how others would classify the three groups above and which underlying test they would apply.
Best Regards,
Yuli
On Wed, Aug 12, 2026 at 8:39 AM Marco Schmidt <mschmidt@ripe.net> wrote:
Did I understand the example correctly, and is this the question you would like feedback on?
Hello all, Thank you, Marco. Yes, you understood the example correctly, and the three points below are exactly where I would value the working group’s feedback. I would be interested in views from other working group members on three points: 1. Does the current policy text itself determine the outcome of the twelve-environment example, or could it reasonably be read differently depending on how “End Site” is interpreted? 2. Have operators encountered cases where a single customer genuinely required more than a /48 for reasons other than different routing requirements? If so, how were those cases handled? 3. Regardless of the answer above, would it be useful for the End Site definition and Section 5.4.2 to state more explicitly which forms of physical, routing, operational, management or security separation are relevant? I would particularly value operational experiences from other members. Best regards, Yuli
participants (4)
-
Alex Le Heux -
Marco Schmidt -
Randy Bush -
Yuli Azarch