IPv6 Address Space Allocation for ISP

IPv6 understanding articles are written enough for all categories: from users to providers and if a user with a “correct” dual-stack provider just needs to turn on a device that supports IPv6, then what to do with the provider with its IPv6 block is not clear. Let's try to figure it out. The article assumes that the reader can read IPv6 masks, no more is required.

If even with the account of the problem, the picture should help a little

So, the typically allocated IPv6 block is / 32. These are 79228162514264337593543950336 unique IP addresses, which "should be enough for everyone." It would seem that with such an amount even an average ISP can not particularly care about the exhaustion of the address space, but network engineers know that the problem of proper address planning is not only in saving addresses, but also in that it affects equipment performance and, consequently, performance the whole network.

There are some recommendations that regional registrars and RFC6177 give :

1. ISP allocated on / 32 block
2. Each node where addresses are aggregated should receive / 48 network (65536 networks / 64 sizes)
3. There should be no subnets longer than / 64, which means that a 64 / subnet (18446744073709551616 IP addresses) is allocated to each VLAN
4. All loopbacks must be on the same / 64 subnet, interface mask - / 128

')
Obviously, with this approach, the meaning of VLAN per user, VLAN per access-switch or vlan per building, adjusted for different types of clients, is not entirely reasonable and contradicts the recommendations of RIPE. In my opinion, 2-4 VLANs to the site will suffice: corporate clients, individuals and, possibly, telephony and TV, if there is a need to distribute them (eg for ACL, netflow, etc.) where at the access level to make the corresponding bindings, eg DHCPv6 opt37

Visualization:


Take a spherical ISP, which is present in five cities, each of which has / is planned 100 sites, each will be corporate clients, physical. Face and SIP with IPTV. The provider we have is right, corporate clients are offered a wide variety of tariffs (unlimited and on traffic), physicists, it seems to me, no one already provides for traffic, and also on their SIP server / SoftSwitch only allows access from certain subnets in which they are located. voice gateways (the subscriber receives the telephony as an FXS port). And now it receives 2001: DB8 :: / 32 (the address recommended for documentation, RFC3849). Next, simple math level 5 class: in each city we need to / 38 network, but more "beautiful" will be divided into / 36 network per city, networks with such a breakdown will be enough for 11 cities. Let's call this the first level of address space.


Further we distribute addresses in the city. Second level. Let it be Samara with her 2001: db8: 2 :: / 48. Remember that the site should have / 64. At once I will make a reservation that I omit the intermediate stage of summing up blocks of several aggregations into some kind of intermediate between / 64 and / 48, since I think that this cannot be described as a typical scheme, it depends on the physical and logical construction of the network (for example, you can combine all / 64 networks of one ospf area into one shorter prefix). So we get no more than 5 VLANs on the aggregation (+ managment), not counting VPN, saving device resources, easy configuration of STP, QoS, etc., as well as access switches (the config will differ only in managing IP). Corporate clients wishing nr / 56 also fit well into this picture.
In some cases, it may be the meaning of converting a typical three-tier network building model (core-aggregation-access) to core-access, putting something L2-level on the aggregation level to make the network cheaper.

The article was not a big one, I did not give examples of IPv6 configurations, since this is beyond the scope of the article, if there is a desire from the readers - I can paint typical things on the basis of this article. I tried to collect all the recommendations on IPv6 and paint them in human language. Any changes, comments, suggestions and additions are welcome!