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 <[email protected]> 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
-----
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/
