proposal for RIPE's IPv6-address space structure
Hello, we want to present a proposal concerning the allocation of IPv6-address space within the RIPE-region on the basis of the Internet Draft "An IPv6 Provider-Based Unicast Address Format" [1], which itself is consistent with RFC 1884 [2] and RFC 1887 [3]. The proposal is based on the following assumptions. A1. There will likely be a mixture of providers of different sizes. A2. Small providers will grow to become large providers. A3. Large providers will lose customers and become small providers. A4. Organizations which need to be multi-homed to more than one provider will request a Provider ID assignment. These four assumptions are essentially taken from [1] (see section 3.3). We add one further assumption: A5. Internet Service Providers will mainly offer their service within one country. Our proposal tries to achieve the following goals: D1. The hierarchical address structure is to simplify routing or rather to offset the growth of routing tables. (Aggregation) D2. Address space should be sufficient for a long time - in principle for ever. This leads to a conservative approach. (Conservation) D3. It should accommodate ISPs and their customers (avoid reassignments, if possible; long-term address space planning for providers). D2 and D3 are contrary in a way. We propose the following address allocation scheme: |FP+RegID| Provider ID | Subscriber ID | Intra-Sub | | | PRID | RPID | | | +--------+-------+------+---------------+-----------+ | 8 bit | 7 bit | n bit| (49 - n) | 64 bit | +--------+-------+------+---------------+-----------+ with n = 17 ! PRID (Provider Region ID) 7 bit corresponds to 128 IDs. These are mainly reserved for the countries of the 'natural', ie. European, RIPE-Region (A5). Non-European domains supported by RIPE get their own prefix (FP+RegID) in order to support a dedicated authority for these regions in the future. We should mention that we have discussed the possibility to subdivide the RIPE address space in such a way that the length of the Country-ID depends on the size (population) of that country. In such a scheme big countries could get a 5 or 6 bit long Country-ID (instead of 7 bit), resulting in a larger address space for those countries. RPID (Rest of Provider ID): In principle 56 bit are available to address providers and their customers. With n=17 there is room for 2^17 (= 131072) providers per provider region (=country). The remaining 32 bits are available to identify a customer. Hence, each provider has as many customer networks available as there are host addresses available with IPv4. If this turns out not to be enough to satisfy the needs of a very LARGE provider then, there should be the option to double the assigned address space by adjoining the neighboring address block. In order to do so RPIDs should be assigned in multiples of 16 initially, leaving the option to half the 'reserved' address space but still keeping the option to double. Given a reasonable size for an ISP within an open market this compromise should address D2 as well as D3 still leaving the option for some degenerated cases with just a single prefix. Different assumptions about the future growth and dynamics of national Internet markets might result in a different choice for n. We hope that this proposal will serve at least as input for discussion. References: [1] Rekhter, Y., Lothberg, P., Hinden, R., Deering, S., Postel, J., "An IPv6 Provider-Based Unicast Address Format", Internet Draft, March 1996. [2] Hinden, R., "IP Version6 Addressing Architecture", RFC 1884, December 1995. [3] Rekhter, Y., Li, T., "An Architecture for IPv6 Unicast Address Allocation", RFC 1887, December 1995. Best regards Frank Hoffmeister Guido Loeffler Juergen Rauschenbach Author's Addresses: Frank Hoffmeister EUnet Deutschland GmbH Phone: +49 231 972 00 Emil-Figge-Str. 80 Fax: +49 231 972 1188 D-44227 Dortmund E-Mail: Frank.Hoffmeister@Germany.EU.net Guido Loeffler JOIN project University of Muenster Phone: +49 251 83 8458 Einsteinstr. 60 Fax: +49 251 83 2678 D-48149 Muenster E-Mail: join@uni-muenster.de Juergen Rauschenbach DFN-Verein Phone: +49 30 884299 46 Pariser Str.44 Fax: +49 30 884299 70 D-10707 Berlin E-Mail: jrau@dfn.de
"JOIN" == JOIN Project Team <join@uni-muenster.de> writes:
JOIN> PRID (Provider Region ID) 7 bit corresponds to 128 JOIN> IDs. These are mainly reserved for the countries of the JOIN> 'natural', ie. European, RIPE-Region (A5). Non-European JOIN> domains supported by RIPE get their own prefix (FP+RegID) in JOIN> order to support a dedicated authority for these regions in JOIN> the future. JOIN> We should mention that we have discussed the possibility to JOIN> subdivide the RIPE address space in such a way that the JOIN> length of the Country-ID depends on the size (population) of JOIN> that country. In such a scheme big countries could get a 5 JOIN> or 6 bit long Country-ID (instead of 7 bit), resulting in a JOIN> larger address space for those countries. Could you clarify a bit the Region ID field ... i.e. is there supposed to be a region id per country ? what about pan-european organizations (E-bone, EUnet, Dante and so on) ? Do they get the region of the country where their head-quarters is or a special "all-europe region" ? Do you intend to have address assignment made "provider based" or "geographically based" ? i.e. where would EUnet PT get his prefix, for instance ? from the "europe-wide" or "Holland" region or from "portuguese" region ? Note that this is not criticism to the idea... i just think these points could/should be addresses more clearly in the document. regards, Pedro.
Hi Pedro,
"JOIN" == JOIN Project Team <join@uni-muenster.de> writes:
JOIN> PRID (Provider Region ID) 7 bit corresponds to 128 JOIN> IDs. These are mainly reserved for the countries of the JOIN> 'natural', ie. European, RIPE-Region (A5). Non-European JOIN> domains supported by RIPE get their own prefix (FP+RegID) in JOIN> order to support a dedicated authority for these regions in JOIN> the future.
JOIN> We should mention that we have discussed the possibility to JOIN> subdivide the RIPE address space in such a way that the JOIN> length of the Country-ID depends on the size (population) of JOIN> that country. In such a scheme big countries could get a 5 JOIN> or 6 bit long Country-ID (instead of 7 bit), resulting in a JOIN> larger address space for those countries.
Could you clarify a bit the Region ID field ... i.e. is there supposed to be a region id per country ?
Yes, so it is. But with less than 60 countries within the European RIPE region many PRIDs will remain which may be used for pan-european organizations and other things.
what about pan-european organizations (E-bone, EUnet, Dante and so on) ? Do they get the region of the country where their head-quarters is or a special "all-europe region" ?
See above.
Do you intend to have address assignment made "provider based" or "geographically based" ?
We intend to have address assignment "provider based".
i.e. where would EUnet PT get his prefix, for instance ? from the "europe-wide" or "Holland" region or from "portuguese" region ?
This depends on whether EUnet PT regards itself as part of a pan-european EUnet provider or as independent Portuguese service provider.
Note that this is not criticism to the idea... i just think these points could/should be addresses more clearly in the document.
I hope, our points got clear.
regards, Pedro.
Regards, Guido
Hi, some quick comments:
|FP+RegID| Provider ID | Subscriber ID | Intra-Sub | | | PRID | RPID | | | +--------+-------+------+---------------+-----------+ | 8 bit | 7 bit | n bit| (49 - n) | 64 bit | +--------+-------+------+---------------+-----------+
with n = 17 !
PRID (Provider Region ID) 7 bit corresponds to 128 IDs. These are mainly reserved for the countries of the 'natural', ie. European, RIPE-Region (A5).
Can you provide a rationale for grouping providers by country. It strikes me as contrary to both aggregation and conservation goals.
Non-European domains supported by RIPE get their own prefix (FP+RegID) in order to support a dedicated authority for these regions in the future.
This is very difficult to do since it is by no means clear where regional boundaries will be.
If this turns out not to be enough to satisfy the needs of a very LARGE provider then, there should be the option to double the assigned address space by adjoining the neighboring address block. In order to do so RPIDs should be assigned in multiples of 16 initially, leaving the option to half the 'reserved' address space but still keeping the option to double.
For this to work, the additional space needed must be exactly the reserved size. Usually it is either less or more. Strategies like that have been shown to be less than optimal for conservation while the additional aggregation effect is not very big. How about just using the 56 bits for local-IR+subscriber? The boundary does not need to be fixed at all. Then use a similar scheme than the present IPv4 one to determine the size of allocations to local IRs (provider): Fixed size for new local IRs and further allocations based on established usage rate.
We hope that this proposal will serve at least as input for discussion.
Certainly. Daniel
Daniel Karrenberg writes:
How about just using the 56 bits for local-IR+subscriber? The boundary does not need to be fixed at all. Then use a similar scheme than the present IPv4 one to determine the size of allocations to local IRs (provider): Fixed size for new local IRs and further allocations based on established usage rate.
Using only 56 bits for the IR would effectively defeat the possiblity of using MAC / ESI addresses as the low 48 bits of an IP address. Pete
Petri Helenius <pete@sms.fi> writes: Using only 56 bits for the IR would effectively defeat the possiblity of using MAC / ESI addresses as the low 48 bits of an IP address.
Sorry I don't get you. The subscriber has 64 bits to play with. That gives 16 bits to select the physical subnet if you choose to use 48 bits for MAC. Do we have a misunderstanding? Here is the lenghts from msb in my proposal: 3 - Provider-Based Unicast Address prefix (010) 5 - regional IR ID (32 is plenty) r - local IR ID (r=56-s) s - subscriber ID (s=56-r) 64 - subscriber local addressing (maybe 16+48 for Petri) --- 128 === The values for r would be determined similarly as with current policies: 1) new local IRs get a fixed size allocation 2) furhter allocations will be determined according to usage rate. Detailed policies such as ranges for r subject to further discussion. Daniel
Daniel Karrenberg writes:
Petri Helenius <pete@sms.fi> writes: Using only 56 bits for the IR would effectively defeat the possiblity of using MAC / ESI addresses as the low 48 bits of an IP address.
Sorry I don't get you. The subscriber has 64 bits to play with. That gives 16 bits to select the physical subnet if you choose to use 48 bits for MAC. Do we have a misunderstanding?
OK, I understood you would hand out 56 bits to the IR (having 72 bit prefix for an IR). Which would practically lead for an IR delegating 48 bits or less at a time. If 56 is the prefix length, we're in agreement.(as you below describe) Sorry for the confusion. I hope you make quick progress since we really need to get this allocation stuff up and running. Pete
Here is the lenghts from msb in my proposal:
3 - Provider-Based Unicast Address prefix (010) 5 - regional IR ID (32 is plenty) r - local IR ID (r=56-s) s - subscriber ID (s=56-r) 64 - subscriber local addressing (maybe 16+48 for Petri) --- 128 ===
The values for r would be determined similarly as with current policies:
1) new local IRs get a fixed size allocation 2) furhter allocations will be determined according to usage rate.
Detailed policies such as ranges for r subject to further discussion.
Daniel
On Fri, 22 Nov 1996 14:10:37 +0200 (EET) Petri Helenius <pete@sms.fi> alleged:
Using only 56 bits for the IR would effectively defeat the possiblity of using MAC / ESI addresses as the low 48 bits of an IP address.
There are pluses to this though. Neil -- Neil J. McRae. Alive and Kicking. E A S Y N E T G R O U P P L C neil@EASYNET.NET NetBSD/sparc: 100% SpF (Solaris protection Factor) Free the daemon in your <A HREF="http://www.NetBSD.ORG/">computer!</A>
Hi Daniel,
Hi,
some quick comments:
|FP+RegID| Provider ID | Subscriber ID | Intra-Sub | | | PRID | RPID | | | +--------+-------+------+---------------+-----------+ | 8 bit | 7 bit | n bit| (49 - n) | 64 bit | +--------+-------+------+---------------+-----------+
with n = 17 !
PRID (Provider Region ID) 7 bit corresponds to 128 IDs. These are mainly reserved for the countries of the 'natural', ie. European, RIPE-Region (A5).
Can you provide a rationale for grouping providers by country. It strikes me as contrary to both aggregation and conservation goals.
We assume that ISPs will mainly offer their service within one country.
Non-European domains supported by RIPE get their own prefix (FP+RegID) in order to support a dedicated authority for these regions in the future.
This is very difficult to do since it is by no means clear where regional boundaries will be.
Is it much more difficult to draw a border between the African RIPE region and the European RIPE region than between the RIPE region and the INTERNIC region?
If this turns out not to be enough to satisfy the needs of a very LARGE provider then, there should be the option to double the assigned address space by adjoining the neighboring address block. In order to do so RPIDs should be assigned in multiples of 16 initially, leaving the option to half the 'reserved' address space but still keeping the option to double.
For this to work, the additional space needed must be exactly the reserved size. Usually it is either less or more. Strategies like that have been shown to be less than optimal for conservation while the additional aggregation effect is not very big.
Do you prefer a scheme in which the address space of a provider is more precisely adapted for its needs? More conservation, less aggregation?
How about just using the 56 bits for local-IR+subscriber? The boundary does not need to be fixed at all. Then use a similar scheme than the present IPv4 one to determine the size of allocations to local IRs (provider): Fixed size for new local IRs and further allocations based on established usage rate.
I think this scheme could result in a too conservative allocation policy with regard to the large address space we have at our disposal. It might be negative for aggregation and/or IPSs.
We hope that this proposal will serve at least as input for discussion.
Certainly.
Daniel
JOIN Project Team <join@uni-muenster.de> writes:
Can you provide a rationale for grouping providers by country. It strikes me as contrary to both aggregation and conservation goals.
We assume that ISPs will mainly offer their service within one country.
This is not necessarily a valid assumption. You might want to test it against the current local IR list. More importantly the number of ISPs per country is not easy to predict. So there will be fragmentation which is bad for conservation. Also topology may suggest ways aggregation that do not follow county boundaries. So far I see only arguments against grouping by country and not a single one in favour.
This is very difficult to do since it is by no means clear where regional boundaries will be.
Is it much more difficult to draw a border between the African RIPE region and the European RIPE region than between the RIPE region and the INTERNIC region?
While one may expect that regions will be delineated by geography it is by no means clear that it will turn out that way. A region will be defined by large groups of ISPs agreeing to be served by a regional registry. Maybe Northern Africa will be a different region from Southern Africa again different from the Middle East. Maybe they will all be one region. It is by no means clear. As grouping picked today not may make sense once this process starts and worse it may be counterproductive. I propose to use region IDs per regional registry. Once a new regional registry starts it gets a new region ID.
For this to work, the additional space needed must be exactly the reserved size. Usually it is either less or more. Strategies like that have been shown to be less than optimal for conservation while the additional aggregation effect is not very big.
Do you prefer a scheme in which the address space of a provider is more precisely adapted for its needs?
Yes.
More conservation, less aggregation?
That is not necessarily a consequence of the above. The real challenge of assignment and allocation policies is to get consensus about the right balance between the two.
How about just using the 56 bits for local-IR+subscriber? The boundary does not need to be fixed at all. Then use a similar scheme than the present IPv4 one to determine the size of allocations to local IRs (provider): Fixed size for new local IRs and further allocations based on established usage rate.
I think this scheme could result in a too conservative allocation policy with regard to the large address space we have at our disposal. It might be negative for aggregation and/or IPSs.
It could result in a too conservative allocation policy just as well as any other scheme proposed; it does not have to. We still have to have the discussion about appropriate allocation sizes. I only know that the allocation sizes should not be fixed should not be fixed, i.e. every ISP gets the same size because that will be far less than optimal. My question was rather: Is there anything wrong with my proposal of using the 56 bits for just two fields local IR and subscriber with a varying boundary. Do we need other groupings? If yes, for what specific purpose? Daniel
Hi Daniel, On Fri, 22 Nov 1996, Daniel Karrenberg wrote:
This is very difficult to do since it is by no means clear where regional boundaries will be.
Is it much more difficult to draw a border between the African RIPE region and the European RIPE region than between the RIPE region and the INTERNIC region?
While one may expect that regions will be delineated by geography it is by no means clear that it will turn out that way. A region will be defined by large groups of ISPs agreeing to be served by a regional registry.
Does this imply that one geographical region may be covered by more than one regional registry? In this case 5 bit Reg IR ID would not be really 'plenty'.
Maybe Northern Africa will be a different region from Southern Africa again different from the Middle East. Maybe they will all be one region. It is by no means clear. As grouping picked today not may make sense once this process starts and worse it may be counterproductive.
Why?
I propose to use region IDs per regional registry. Once a new regional registry starts it gets a new region ID.
Section 3.2 in ID [1] says that a Regional Registry may have more than one block of addresses allocated to it.
For this to work, the additional space needed must be exactly the reserved size. Usually it is either less or more. Strategies like that have been shown to be less than optimal for conservation while the additional aggregation effect is not very big.
Do you prefer a scheme in which the address space of a provider is more precisely adapted for its needs?
Yes.
More conservation, less aggregation?
That is not necessarily a consequence of the above. The real challenge of assignment and allocation policies is to get consensus about the right balance between the two.
I agree. We are sceptical about aggregation on the regional/country level. So it gets more important to achieve almost optimal aggregation on the provider level, i.e. one prefix per provider. But even with this claim: Before running in problems with conservation (i.e. insufficient conservation), we would probably get problems with aggregation (i.e. insufficient aggregation). Consider, in our proposal a single country has room for 2^17 providers.
How about just using the 56 bits for local-IR+subscriber? The boundary does not need to be fixed at all. Then use a similar scheme than the present IPv4 one to determine the size of allocations to local IRs (provider): Fixed size for new local IRs and further allocations based on established usage rate.
I think this scheme could result in a too conservative allocation policy with regard to the large address space we have at our disposal. It might be negative for aggregation and/or IPSs.
It could result in a too conservative allocation policy just as well as any other scheme proposed; it does not have to. We still have to have the discussion about appropriate allocation sizes. I only know that the allocation sizes should not be fixed should not be fixed, i.e. every ISP gets the same size because that will be far less than optimal.
My question was rather: Is there anything wrong with my proposal of using the 56 bits for just two fields local IR and subscriber with a varying boundary. Do we need other groupings? If yes, for what specific purpose?
I don't think that there is anything wrong with your proposal. But for really estimating it, it is not concrete enough. It would be helpful to start the 'further discussion' on detailed policies such as ranges for r.
Daniel
Guido
JOIN Project Team <join@uni-muenster.de> writes: Does this imply that one geographical region may be covered by more than one regional registry? In this case 5 bit Reg IR ID would not be really 'plenty'.
No. It means that the regions covered by regional registries cannot be predicted.
Maybe Northern Africa will be a different region from Southern Africa again different from the Middle East. Maybe they will all be one region. It is by no means clear. As grouping picked today not may make sense once this process starts and worse it may be counterproductive.
Why?
Because wars have started over less than a bit field assignment. Setting unnecessary precedences is never a good idea, it is certainly a very bad idea if it is done without consensus of those affected. So do not do it. The establishment of regional registries will be driven by need, willingness and ability of groups of ISPs to achieve consensus. This depends on many factors is not predictable. So let's not second guess it.
I propose to use region IDs per regional registry. Once a new regional registry starts it gets a new region ID.
Section 3.2 in ID [1] says that a Regional Registry may have more than one block of addresses allocated to it.
Yes, so what?
I don't think that there is anything wrong with your proposal. But for really estimating it, it is not concrete enough. It would be helpful to start the 'further discussion' on detailed policies such as ranges for r.
I have not thought about that really. Quite frankly there is a lot of missing information before one can get that concrete. The most important piece missing is information on interdomain (exterior) routing schemes to be used. That's why I pointed out Mike O'Dell's 8+8 draft. Before routing becomes more clear any address allocation/assignment scheme needs to be very conservative in order not to preclude too many options in the high order bits. It also has to have the label "preliminary, provisional" because it may otherwise become useless. In the light of this and the fact tht we are not exactly overwhelmed by ISPs asking for IPv6 address space I doubt whether we need to discuss concrete schemes at this point. However we should keep this item on the agenda and have a discussion at the January RIPE meeting. We should also watch developments at the upcoming IETF. Daniel
I don't think that there is anything wrong with your proposal. But for really estimating it, it is not concrete enough. It would be helpful to start the 'further discussion' on detailed policies such as ranges for r.
I have not thought about that really. Quite frankly there is a lot of missing information before one can get that concrete. The most important piece missing is information on interdomain (exterior) routing schemes to be used. That's why I pointed out Mike O'Dell's 8+8 draft. Before routing becomes more clear any address allocation/assignment scheme needs to be very conservative in order not to preclude too many options in the high order bits. It also has to have the label "preliminary, provisional" because it may otherwise become useless.
That's a good point. In fact, we are looking for a scalable and efficient (exterior) routing scheme. Given that in the future there will be MANY ISPs worldwide the vast amount of associations of provider-based prefixes to ASes might impose a problem to the size of the routing tables. So, there is some need to aggregate routes to providers. Having regional prefixes is one option.
In the light of this and the fact tht we are not exactly overwhelmed by ISPs asking for IPv6 address space I doubt whether we need to discuss concrete schemes at this point. However we should keep this item on the agenda and have a discussion at the January RIPE meeting. We should also watch developments at the upcoming IETF.
Yes, be prepared :-) Frank
Frank Hoffmeister <Frank.Hoffmeister@Germany.EU.net> writes:
In fact, we are looking for a scalable and efficient (exterior) routing scheme.
Right.
Given that in the future there will be MANY ISPs worldwide the vast amount of associations of provider-based prefixes to ASes might impose a problem to the size of the routing tables.
Yes it might. On the other hand I am not totally pessimistic. Router vendors are getting things right by doing away with forwarding table caching, allowing reasonable sizes of forwarding tables in backbone type routers and fully separating routing computations form forwarding. The probnlem is that we are still engineering very much to a moving target. If anyone can forecast the development curve of - number and size of ISPs - interconnectivity model of ISPs - number and size of customers - connectiviy trends of customers (multi/single homed etc) - router capabilities - exterior routing technology it is easy to engineer address space allocation and assignment procedures that produce good or even optimal results. Unfortunately there is no consensus about these developments and the more wise people do not even try to speculate. Therefore I would like to keep options open as long as possible and also use a scheme with lots of flexibility. It is more tractable to devise procedures that work for the immediate future but they need to be flexible to be adapted to a changing environment. The Internet community and especially the providers and the registries have had great successes with that. Consider the registration schemes in place 4 years ago. Consider the time frame it took to devise and effectively deploy CIDR. We are good at this.
So, there is some need to aggregate routes to providers. Having regional prefixes is one option.
I would like to hear what you mean by 'regional prefix'. How is it defined? How does it relate to netowrk topology? How does aggregation to it work? Daniel
On Nov 26, 10:20, Daniel Karrenberg <Daniel.Karrenberg@ripe.net> wrote:
If anyone can forecast the development curve of
- number and size of ISPs - interconnectivity model of ISPs - number and size of customers - connectiviy trends of customers (multi/single homed etc) - router capabilities - exterior routing technology
it is easy to engineer address space allocation and assignment procedures that produce good or even optimal results. Unfortunately there is no consensus about these developments and the more wise people do not even try to speculate. Therefore I would like to keep options open as long as possible and also use a scheme with lots of flexibility.
Amen. People sometimes naively and innocently ask "When will the next version of <insert any interesting protocol> be deployed?", believing things are actually planned and orchestrated in great detail in advance. I always reply "Just before it's too late.". That's the track record so far, and nothing suggests this will change. Currently that "too late" is in the next century, so anything devised here and now can only be experimental, for educational use. Cast it in stone and it will float like a rock. -- ------ ___ --- Per G. Bilse, Mgr Network Operations ----- / / / __ ___ _/_ ---- EUnet Communications Services B.V. ---- /--- / / / / /__/ / ----- Singel 540, 1017 AZ Amsterdam, NL --- /___ /__/ / / /__ / ------ tel: +31 20 5305333, fax: +31 20 6224657 --- ------- 24hr emergency number: +31 20 421 0865 --- Connecting Europe since AS286 --- http://www.EU.net e-mail: bilse@EU.net
Also interesting is the Mike O'Dells latest draft: draft-odell-8+8-00.txt
Hi Daniel,
Also interesting is the Mike O'Dells latest draft:
draft-odell-8+8-00.txt
I know this draft, but still don't know what to think about it :-). Regards, Guido
JOIN Project Team <join@uni-muenster.de> writes:
draft-odell-8+8-00.txt
I know this draft, but still don't know what to think about it :-).
It proposes to split the IPv6 adress space in two equal size parts. One part is the "end system designator" which basically identifies an interface. Besides being globally unique it needs no other properties. The other part is called "routing goop" and contains topology information on how the end system is connected to the global internet. The consequence is that the functions of routing and uniquely identifying are fully separated. This provides quite some freedom to get the routing information right and make full use of it. Very interesting idea. Daniel
participants (7)
-
Daniel Karrenberg -
Frank Hoffmeister -
JOIN Project Team -
Neil J. McRae -
Pedro Roque -
Per Gregers Bilse -
Petri Helenius