From join at uni-muenster.de Fri Nov 22 10:54:51 1996 From: join at uni-muenster.de (JOIN Project Team) Date: Fri, 22 Nov 1996 10:54:51 +0100 (MET) Subject: proposal for RIPE's IPv6-address space structure Message-ID: 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 at 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 at 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 at dfn.de From roque at di.fc.ul.pt Fri Nov 22 11:58:04 1996 From: roque at di.fc.ul.pt (Pedro Roque) Date: Fri, 22 Nov 1996 10:58:04 GMT Subject: proposal for RIPE's IPv6-address space structure In-Reply-To: References: Message-ID: <199611221058.KAA20879@oberon.di.fc.ul.pt> >>>>> "JOIN" == JOIN Project Team 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. From Daniel.Karrenberg at ripe.net Fri Nov 22 12:05:29 1996 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 22 Nov 1996 12:05:29 +0100 Subject: proposal for RIPE's IPv6-address space structure In-Reply-To: Your message of Fri, 22 Nov 1996 10:54:51 +0100. References: Message-ID: <9611221105.AA17554@ncc.ripe.net> 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 From Daniel.Karrenberg at ripe.net Fri Nov 22 12:07:37 1996 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 22 Nov 1996 12:07:37 +0100 Subject: proposal for RIPE's IPv6-address space structure In-Reply-To: Your message of Fri, 22 Nov 1996 10:54:51 +0100. References: Message-ID: <9611221107.AA17604@ncc.ripe.net> Also interesting is the Mike O'Dells latest draft: draft-odell-8+8-00.txt From pete at sms.fi Fri Nov 22 13:10:37 1996 From: pete at sms.fi (Petri Helenius) Date: Fri, 22 Nov 1996 14:10:37 +0200 (EET) Subject: proposal for RIPE's IPv6-address space structure In-Reply-To: <9611221105.AA17554@ncc.ripe.net> References: <9611221105.AA17554@ncc.ripe.net> Message-ID: <199611221210.OAA26512@silver.sms.fi> 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 From join at uni-muenster.de Fri Nov 22 14:16:39 1996 From: join at uni-muenster.de (JOIN Project Team) Date: Fri, 22 Nov 1996 14:16:39 +0100 (MET) Subject: proposal for RIPE's IPv6-address space structure In-Reply-To: <199611221058.KAA20879@oberon.di.fc.ul.pt> Message-ID: Hi Pedro, > >>>>> "JOIN" == JOIN Project Team 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 From join at uni-muenster.de Fri Nov 22 14:50:28 1996 From: join at uni-muenster.de (JOIN Project Team) Date: Fri, 22 Nov 1996 14:50:28 +0100 (MET) Subject: proposal for RIPE's IPv6-address space structure In-Reply-To: <9611221105.AA17554@ncc.ripe.net> Message-ID: 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 > From join at uni-muenster.de Fri Nov 22 14:54:47 1996 From: join at uni-muenster.de (JOIN Project Team) Date: Fri, 22 Nov 1996 14:54:47 +0100 (MET) Subject: proposal for RIPE's IPv6-address space structure In-Reply-To: <9611221107.AA17604@ncc.ripe.net> Message-ID: 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 From Daniel.Karrenberg at ripe.net Fri Nov 22 16:01:56 1996 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 22 Nov 1996 16:01:56 +0100 Subject: proposal for RIPE's IPv6-address space structure In-Reply-To: Your message of Fri, 22 Nov 1996 14:50:28 +0100. References: Message-ID: <9611221501.AA24691@ncc.ripe.net> > JOIN Project Team 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 From Daniel.Karrenberg at ripe.net Fri Nov 22 16:25:25 1996 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 22 Nov 1996 16:25:25 +0100 Subject: proposal for RIPE's IPv6-address space structure In-Reply-To: Your message of Fri, 22 Nov 1996 14:10:37 +0200. <199611221210.OAA26512@silver.sms.fi> References: <199611221210.OAA26512@silver.sms.fi> Message-ID: <9611221525.AA25544@ncc.ripe.net> > Petri Helenius 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 From Daniel.Karrenberg at ripe.net Fri Nov 22 16:56:54 1996 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 22 Nov 1996 16:56:54 +0100 Subject: proposal for RIPE's IPv6-address space structure In-Reply-To: Your message of Fri, 22 Nov 1996 14:54:47 +0100. References: Message-ID: <9611221556.AA26627@ncc.ripe.net> > JOIN Project Team 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 From pete at sms.fi Fri Nov 22 17:16:15 1996 From: pete at sms.fi (Petri Helenius) Date: Fri, 22 Nov 1996 18:16:15 +0200 (EET) Subject: proposal for RIPE's IPv6-address space structure In-Reply-To: <9611221525.AA25544@ncc.ripe.net> References: <199611221210.OAA26512@silver.sms.fi> <9611221525.AA25544@ncc.ripe.net> Message-ID: <199611221616.SAA01991@silver.sms.fi> Daniel Karrenberg writes: > > > Petri Helenius 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 From neil at easynet.net Fri Nov 22 18:31:01 1996 From: neil at easynet.net (Neil J. McRae) Date: Fri, 22 Nov 1996 17:31:01 +0000 Subject: proposal for RIPE's IPv6-address space structure In-Reply-To: Your message of "Fri, 22 Nov 1996 14:10:37 +0200." <199611221210.OAA26512@silver.sms.fi> Message-ID: <199611221731.RAA08383@NetBSD.noc.EASYNET.NET> On Fri, 22 Nov 1996 14:10:37 +0200 (EET) Petri Helenius 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 at EASYNET.NET NetBSD/sparc: 100% SpF (Solaris protection Factor) Free the daemon in your computer! From neil at nharris.demon.co.uk Sat Nov 23 16:33:57 1996 From: neil at nharris.demon.co.uk (Neil Harris) Date: Sat, 23 Nov 1996 15:33:57 +0000 Subject: proposal for RIPE's IPv6-address space structure Message-ID: >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 Not to mention ESI and 1-byte selector, as is usual for ATM NSAP addressing, if we want to mix-and-match NSAP and IPv6 addresses. At Sohonet we are currently working out our NSAP addressing scheme. We have 4.5 bytes of prefix under the UK DCC scheme, and we add another nibble to define an 'escape hatch' version number for our numbering scheme, and bring it to byte alignment. We also have 6 bytes of ESI, and 1 byte of SEL, from common ATM practice. So, we now have only 20 - (4.5 + 0.5 + 6 + 1) = 8 bytes of NSAP address space left for our own internal purposes. We would very much like to have an addressing scheme where IPv6 and NSAP addresses can, at the very least, be derived algorithmically from one another. Our design criteria for our NSAP addressing scheme: > >The proposed addressing proposal should allow: > > Easy interpretation by human beings (eg byte aligned or nibble-aligned >fields) > A version field, to allow changing the numbering scheme later. > Compatibility with IPv6, if possible. > Easy NSAP filtering by _organisation_ and class of service, bearing in > mind that some filtering may only be possible by strict prefix. > Efficient routing > Support of multiple providers, multi-homing and diverse routing. > Some customer-specified numbering for internal use (???) -- Neil Harris Sohonet Limited http://www.sohonet.co.uk/ From join at uni-muenster.de Mon Nov 25 15:33:23 1996 From: join at uni-muenster.de (JOIN Project Team) Date: Mon, 25 Nov 1996 15:33:23 +0100 (MET) Subject: proposal for RIPE's IPv6-address space structure In-Reply-To: <9611221501.AA24691@ncc.ripe.net> Message-ID: 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 From Daniel.Karrenberg at ripe.net Mon Nov 25 17:30:45 1996 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 25 Nov 1996 17:30:45 +0100 Subject: proposal for RIPE's IPv6-address space structure In-Reply-To: Your message of Mon, 25 Nov 1996 15:33:23 +0100. References: Message-ID: <9611251630.AA12970@ncc.ripe.net> > JOIN Project Team 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 From Frank.Hoffmeister at Germany.EU.net Mon Nov 25 20:36:50 1996 From: Frank.Hoffmeister at Germany.EU.net (Frank Hoffmeister) Date: Mon, 25 Nov 1996 20:36:50 +0100 Subject: proposal for RIPE's IPv6-address space structure In-Reply-To: Your message of "Mon, 25 Nov 1996 17:30:45 +0100." <9611251630.AA12970@ncc.ripe.net> Message-ID: <199611251936.UAA16810@mail.Germany.EU.net> > > 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 From Daniel.Karrenberg at ripe.net Tue Nov 26 10:20:35 1996 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 26 Nov 1996 10:20:35 +0100 Subject: proposal for RIPE's IPv6-address space structure In-Reply-To: Your message of Mon, 25 Nov 1996 20:36:50 +0100. <199611251936.UAA16810@mail.Germany.EU.net> References: <199611251936.UAA16810@mail.Germany.EU.net> Message-ID: <9611260920.AA27179@ncc.ripe.net> > Frank Hoffmeister 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 From bilse at EU.net Tue Nov 26 15:26:59 1996 From: bilse at EU.net (Per Gregers Bilse) Date: Tue, 26 Nov 1996 15:26:59 +0100 Subject: proposal for RIPE's IPv6-address space structure In-Reply-To: <9611260920.AA27179@ncc.ripe.net> Message-ID: <199611261426.AA09025@jotun.EU.net> On Nov 26, 10:20, Daniel Karrenberg 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 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 at EU.net From mnorris at hea.ie Wed Nov 27 10:38:39 1996 From: mnorris at hea.ie (Mike Norris) Date: Wed, 27 Nov 96 09:38:39 +0000 Subject: (Fwd) ISPACs Message-ID: <199611270938.JAA00232@dalkey.hea.ie> Apologies for multiple postings. Mike ------- Forwarded Message Return-Path: owner-nanog at merit.edu Date: Tue, 26 Nov 1996 12:49:12 -0800 (PST) Message-Id: <199611262049.MAA05750 at chimp.jnx.com> From: Tony Li To: nanog at merit.edu, cidrd at iepg.org, metro at nlanr.net Subject: ISPACs Sender: owner-nanog at merit.edu Status: RO Folks, I'd like to point your attention to the following ID. I would appreciate any comments. For the lack of a better place, I'd ask that discussion be on the cidrd mailing list. Thanks, Tony A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Internet Service Provider Address Coalitions (ISPACs) Author(s) : T. Li Filename : draft-li-ispac-00.txt Pages : 5 Date : 11/25/1996 ------- End of Forwarded Message From GeertJan.deGroot at ripe.net Wed Nov 27 14:23:30 1996 From: GeertJan.deGroot at ripe.net (Geert Jan de Groot) Date: Wed, 27 Nov 1996 14:23:30 +0100 Subject: (Fwd) ISPACs In-Reply-To: Your message of "Wed, 27 Nov 1996 09:38:39 GMT." <199611270938.JAA00232@dalkey.hea.ie> Message-ID: <9611271323.AA00787@ncc.ripe.net> On Wed, 27 Nov 96 09:38:39 +0000 "Mike Norris" wrote: > Title : Internet Service Provider Address Coalitions (ISPACs) > Author(s) : T. Li > Filename : draft-li-ispac-00.txt > Pages : 5 > Date : 11/25/1996 I don't think this will fly. The major cost of ISP's is their lines; changing between ISPACs means that the same infrastructure is used, and thus that performance level and price will be very similar amongst 'competitors' in the same ISPAC. I don't think it makes sense for a customer to change ISP between those in the ISPAC. Also, this would mean that the ISP's in the ISPAC give each other transit over their main international lines. That just doesn't make sense to me. I must be missing something? Geert Jan From bonito at nis.garr.it Thu Nov 28 11:14:20 1996 From: bonito at nis.garr.it (Antonio_Blasco Bonito) Date: Thu, 28 Nov 1996 11:14:20 +0100 (MET) Subject: (Fwd) ISPACs In-Reply-To: <9611271323.AA00787@ncc.ripe.net> from "Geert Jan de Groot" at Nov 27, 96 02:23:30 pm Message-ID: <199611281014.LAA18786@cuori.nis.garr.it> Quoting from Geert Jan de Groot's message: > > On Wed, 27 Nov 96 09:38:39 +0000 "Mike Norris" wrote: > > Title : Internet Service Provider Address Coalitions (ISPACs) > > Author(s) : T. Li > > Filename : draft-li-ispac-00.txt > > Pages : 5 > > Date : 11/25/1996 > > I don't think this will fly. The major cost of ISP's is their lines; > changing between ISPACs means that the same infrastructure is used, > and thus that performance level and price will be very similar > amongst 'competitors' in the same ISPAC. You are right, but the proposal still makes sense in my view > I don't think it makes sense for a customer to change ISP between > those in the ISPAC. ISPs in the ISPAC could differentiate among themselves for other characteristics than the transport infrastrucure: i.e. type of customers, local scope, type of customer support, etc > > Also, this would mean that the ISP's in the ISPAC give each other > transit over their main international lines. That just doesn't make > sense to me. This is exactly what happens in Italy where a large number of small ISPs use a small set of upstream big ISPs. Hence a sort of ISPAC is already in place... > > I must be missing something? Are you still missing something? > > Geert Jan > ---------- ---------- Antonio-Blasco Bonito E-Mail: bonito at nis.garr.it GARR - Network Information Service c=it;a=garr;p=garr;o=nis;s=bonito c/o CNUCE - Istituto del CNR Tel: +39 50 593246 Via S. Maria, 36 Fax: +39 50 904052 I-56126 PISA Telex: 500371 CNUCE I Italy Url: http://www.nis.garr.it/nis/staff/bonito.html ---------- ----------