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/
participants (4)
-
Alex Le Heux -
Marco Schmidt -
Randy Bush -
Yuli Azarch