/48 per end site

[apieters...@gmail.com]

Dear all,

 

there is some confusion about end sites and the qualification of this within the IPv6 allocation.

residential customers receive a /56 typically so if I would have 2 houses, I receive 2 x /56

that is pretty straight forward.

 

If I am an ISP that is doing IPv6 address allocation to business customers, the rules as described in RIPE refer to end sites in allocation rules but this term is a bit unclear to me:

should an ISP then assign a /48 to each business customer (and carve this /48 addres space further up over the different locations of offices of this customer)  or should the ISP assign a /48 each customer’s location (so just like a residential customer receives 2 /56, a customer with n location would receive n /48’s?

 

Many thanks for clarify what is meant with end sites...

 

Many thanks,

Alain

 

 

 

 

[apieters...@gmail.com]

 

Just to add to this

Here are some snippets from the RIPE documents (+references)

RIPE-738 makes reference to RIPE-690 (indented the part inside the RIPE 738 text)

 

https://www.ripe.net/publications/docs/ripe-738#initial_allocation

 

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

 

5.4. Assignment

 

LIRs must make IPv6 assignments in accordance with the following provisions.

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 value of "n" x /64.

Section 4.2 of ripe-690 provides guidelines about this.

https://www.ripe.net/publications/docs/ripe-690

     4.2. Prefix assignment options

 

To keep addressing plans usable and understandable, and to align with DNS reverse zone delegations, the size of the delegated prefix should align with a nibble boundary. Each hexadecimal character in an IPv6 prefix represents one nibble, which is 4 bits. The length of a delegated prefix should therefore always be a multiple of 4.

 

A single network at a customer site will be a /64. At present, RIR policies permit assignment of a /48 per site, so the possible options when choosing a prefix size to delegate are /48, /52, /56, /60 and /64. However, /64 is not sustainable, it doesn't allow customer subnetting, and it doesn't follow IETF recommendations of “at least” multiple /64s per customer. Moreover, future work within the IETF and recommendations from RFC 7934 (section 6) allow the assignment of a /64 to a single interface (https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-07).

 

     The following sections explain why /48 and /56 are the recommended prefix assignment sizes for end customers.

    

     4.2.1. /48 for everybody

 

This is probably the most practical way to assign IPv6 prefixes to end customer CPE devices.

      here is the confusion coming from: most practical way is to assign a /48 to end customer CPE devices (so that means a /48 to every site then).

                  but then in 5.4.2, the text is talking about an assignment to a single End site... These explanations are really contradicting and confusing me what it should be now;

                  a /48 per CPE (or customer location) or a single /48 per business customer (regardless of number of sites)  

     

In this case everyone has a /48 prefix and advanced end-users are less likely to make mistakes when addressing their networks and devices, resulting in much less call-centre time to sort out problems. It also has the advantage of sharing the same prefix size as ULAs and some transition mechanisms, so this facilitates a direct mapping of existing customer addressing plans to the delegated prefix.

 

     Example of assigned prefixes out of 2001:db8::/40 :

 

     2001:db8:aaaa::/48

     2001:db8:aaab::/48

     2001:db8:aaac::/48

     2001:db8:aaad::/48

 

For the first prefix, 2001:db8:aaaa:XXXX::/48, the XXXX is the part that the end-user can use to make their own addressing plan. This is also the structure used in most addressing plan manuals and guides.

 

 

5.4.2. Assignments shorter than a /48 to a single End Site

 

Assignments larger than a /48 (shorter prefix) or additional assignments exceeding a total of a /48 must be based on address usage or because different routing requirements exist for additional assignments.

In case of an audit or when making a request for a subsequent allocation, the LIR must be able to present documentation justifying the need for assignments shorter than a /48 to a single End-Site.

 

5.5. Registration

 

When an LIR holding an IPv6 address allocation makes IPv6 address assignments, it must register these assignments in the appropriate RIR database.

These registrations can either be made as individual assignments or by inserting an object with a status value of 'AGGREGATED-BY-LIR' where the assignment-size attribute contains the size of the individual assignments made to End Users.

When more than a /48 is assigned to an organisation, it must be registered in the database as a separate object with status 'ASSIGNED'.

In case of an audit or when making a request for a subsequent allocation, the LIR must be able to present statistics showing the number of individual assignments made in all objects with a status of 'AGGREGATED-BY-LIR' in such a way the RIR is able to calculate and verify the actual HD-ratio.

 

 

 

Any  guidelines on how to interpret things here...

Or best common practice from other operators.

 

Many thanks,

Alain Pieters

[Hans Thienpondt]

Hi Alain,

Disclaimer: Last I’ve read and fully understood the RIPE policy is more than 10+ years ago already, when I had to file a request to receive an IPv6 prefix for my employer at the time.

Assuming the rules are still the same:

I believe what qualifies as a single End Site is a physical location of a business/customer.

So If you’re an ISP, and have a customer with 16 physical locations, the addressing policy allows you to justify 16x /48 allocations to that customer (one per physical site).

Practically speaking, keeping the BCOP in mind on residential platforms, I believe it depends on which ‘platform’ you end up as a customer.

If you’re a business ordering a business ‘branded' product (which in reality is delivered through a residential platform) you’ll end up with what the network policy will give you (RADIUS/DHCPv6 assigned).

On residential platforms this is most likely to be a /56.

However, If you’re a business customer ordering an actual business product you’ll end up with a /48 per physical location.

Whether or not the ISP does some smarts to be able to aggregate multiple physical locations or not on a per-customer basis, is up to the ISP to decide, you just have to be able to provide documentation to RIPE explaining the N physical locations.

Hope this helps,

Cheers,

-Hans

-- 
You received this message because you are subscribed to the Google Groups "Belgianv6Council" group.
To unsubscribe from this group and stop receiving emails from it, send an email to Belgianv6Counc...@ipv6forum.com.
To view this discussion on the web, visit https://groups.google.com/a/ipv6forum.com/d/msgid/Belgianv6Council/002e01d81811%24a00bd3f0%24e0237bd0%24%40gmail.com.

[apieters...@gmail.com]

Hi Hans,

 

that cleared out things from the current RIPE documentation: a /48 to every site then.

 

to begin with offcourse: you never know if in 10 years from now, someone decides that instead of a /48 a business would required a /40.

Nevertheless, in order to be able to cope either these policy changes or to allow to your end customer to request a larger subnet then on a specific physical location i.e. is it also best practice used to select a different address allocation methods (using the left-to-right principle i.e) versus the old IPv4 subnet allocation method, called right-to-left allocation (192.168.0.0/24, 192.168.1.0/24, etc...).

I guess that, in contrary to a residential subscriber, businesses will be more resistance to chance in case the “standard” allocation was too small. If re-addressing would be required because the provider can not allocate a large chunk of IPv6 address space (the subsequent /48 chunk is i.e. assign already to another location), the customer would not be pleased... It would however also mean that a lot of the address space is going to be ‘reserved’ – not sure if this conflits with the HD ratio thing in subsequent requests to RIPE.

 

What is your take or experience on the address allocation principle? Stick to good old IPv4 assignments (IPAM tools etc dont have the options or so to do this) or consider a different allocation method.

 

Many thanks,

Alain

[Hans Thienpondt]

Hi Alain,

I’d say, a sparse allocation method would be recommended, but this is really something your IPAM system needs to support. 

Alternatively like you described, you can hack your way around sparse allocations: e.g. by altering the allocation process. If your end-site needs a /48 end-site allocation you could change it into a 2-step process:

a. Reserve a /40 container (random prefix length for making my point) aggregate for customer Y

b. Within this /40 aggregate, allocate (status=assigned) the first /48 to customer Y

When you run out of space, you could automate a script to replace all /40’s aggregates by a /41. (And re-iterate as you capacity manage).

In terms of HD ratio: just because you’ve marked an aggregate as reserved in a private database, does not necessarily mean you need to sync it towards the RIPE db, what I’d sync is what you’ve actually allocated towards customers…

However, a sparse allocation method is orthogonal to routing aggregation of multiple sites. If another requirement would be to aggregate those multiple sites into a single prefix, … you can’t have it all ;-)

I guess, on the practical side, a /48 allocation will be a good enough allocation for most business customers. 

Any other customers that require a bigger block and/or aggregation, I’d advise you to trigger them in providing an addressing plan for the infrastructure. Not as a hard requirement, but as a heads up to get them to think things over in terms of what their current infrastructure is and how it will scale.

It’s good practice to avoid renumbering, but in some cases you just can’t predict the future well enough so readdressing becomes unavoidable.. (Or allocating a 2nd disjoint prefix for the end site for that matter).

Hope it helps!

Cheers,

-Hans

On 2 Feb 2022, at 10:47, apieters...@gmail.com wrote:

Hi Hans,

 

that cleared out things from the current RIPE documentation: a /48 to every site then.

 

to begin with offcourse: you never know if in 10 years from now, someone decides that instead of a /48 a business would required a /40.

Nevertheless, in order to be able to cope either these policy changes or to allow to your end customer to request a larger subnet then on a specific physical location i.e. is it also best practice used to select a different address allocation methods (using the left-to-right principle i.e) versus the old IPv4 subnet allocation method, called right-to-left allocation (192.168.0.0/24, 192.168.1.0/24, etc...).

<image001.png>

[apieters...@gmail.com]

Hi Hans,

 

many thanks for the elaborated answers. The abondance of IPv6 address space is so huge that it is a bit like getting groceries in the carrefour and not being able to pick a yoghurt because there is too much choice...

but a /48 for everyone is definitely carved in my brain as final answer (for now that is – stashing away the cristal bal again). I guess in 15 years from now when retired, nobody can blame me for picking the wrong prefix range 😊

Well I still blame the industry for taking on IPv4 instead ISO CLNS... but that were different times in the ’90 – a bit like the yoghurt...

Mvg,