IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT (3rd draft)
Hi, Included below are the comments from the IAB on the 'IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT (3rd draft)'. I personnally think that the IAB's comments are pretty close to the suggestions that the wg decided on during the RIPE IPv6 wg session in Amsterdam. I welcome your input, including endorsements of the changes suggested by the IAB. David K. --- Forwarded message:
From brian@hursley.ibm.com Mon Feb 15 04:57:10 1999 Message-ID: <36C7EE30.3A84DFB3@hursley.ibm.com> Date: Mon, 15 Feb 1999 09:51:44 +0000 From: Brian E Carpenter <brian@hursley.ibm.com> Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Daniel.Karrenberg@ripe.net, Mirjam Kuehne <mir@ripe.net>, kimh@arin.net, Anne Lord <anne@apnic.net>, pwilson@apnic.net CC: IAB <iab@iab.org> Subject: Re IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT (3rd draft) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit
Dear colleagues,
Re IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT (3rd draft)
The IAB has been looking at this draft and here are our comments (which are not confidential in any way).
It's very good to see the registries working actively on this important topic. However there are two points of concern about the current version, one political and one technical.
The political one is easy to fix. Referring to ICANN is contentious in this context, and referring to IANA is not contentious. So please replace all reference to ICANN by IANA. It doesn't change anything but it will reduce argument.
The technical one is more tricky. Basically the draft errs too much on the side of address conservation. While it is important to be prudent and to avoid creating an IPv6 toxic waste dump, we do have a lot more freedom than with IPv4. The draft doesn't take full advantage of this, with the paradoxical effect that aggregation is harmed and unnecessary renumbering is forced. We can afford to be more generous with subTLA space and less restrictive with slow start. The detailed comments below almost all relate to this point.
IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT (3rd draft) ...
ABSTRACT
This document describes the registry system for the distribution of globally unique IPv6 address space, which follows a hierarchical distribution as it does with IPv4. The distribution of IPv6 address space is managed by the IANA (formerly IANA) and further delegated by
...space is managed by the IANA and...
(it is managed by IANA and only by IANA.)
...
This document does not describe private IPv6 address space, or anycast
There is no such thing as private IPv6 address space. There are site-local and link-local IPv6 addresses defined architecturally.
...
2.1.1 IANA
The Internet Corporation for Assigned Names and Numbers (IANA) has
Remove all mention of ICANN which is a red rag to many bulls. The Authority lies with IANA.
authority over all number spaces used in the Internet, including IPv6 address space. IANA allocates parts of the IPv6 address space to Regional Internet Registries (IRs) according to their established needs. ... 2.2 Goals of the Internet Registry System
The remainder of this document is primarily concerned with the management of public IPv6 address space. Every assignment of IPv6 addresses should be made with the following goals in mind for it is in the interest of the Internet community as a whole that these goals be pursued. It is worth noting that "conservation" and "aggregation" are often conflicting goals, and therefore each assignment must be evaluated carefully.
This is IPv4 thinking. Aggregation is what matters for IPv6. Conservation is not a major goal; avoidance of profligacy is the goal, which is much weaker. Suggested rewrite of the last sentence:
Each assignment must be evaluated carefully to ensure good aggregation without being profligate with address usage.
Moreover, these goals may occasionally be in conflict with the interests of individual end users or ISPs.
They will be in conflict. Suggested rewrite:
In the case of IPv4, the necessary heavy emphasis on address conservation, and the attempt to retrofit aggregation, have combined to cause frequent conflict betwen the interests of end users and smaller ISPs with those of the network as a whole. It has also favoured the use of private address space with its unfortunate architectural side effects. IPv6 allows this conflict to be avoided in future.
In such cases, careful analysis and judgement are necessary to find an appropriate compromise.
Delete this sentence; this compromise is not needed for v6.
...
2.2.3 Conservation
The word "Conservation" should be replaced by "Avoidance of profligacy" in the title and everywhere else. Don't misunderstand this as being against conservation: but this draft goes overboard.
...
For purposes of a slow start of a sub-TLA, however, a first sub-TLA allocation would actually always be a /35 block (13 bits instead of 19).
There is no need to slow-start sub-TLAs; in fact it makes no sense. A sub-TLA is always going to be allocated to a single operator; backbone ISPs will certainly not want to see /35 announcements - We expect they will filter anything longer than /29.
Sub-TLAs should be fully allocated. (To put it another way, Sub-TLAs *are* the slow-start mechanism.)
...
4.1.1 Requirements for Allocating a Sub-TLA
In order to meet the conservation and aggregation goals discussed above, only requesting organizations that meet certain requirements will be allocated sub-TLA space. The requirements for an initial allocation to an organization are different from the requirements that have to be met once the initial allocation has been used and additional address space is requested.
Whereas the requirements for an initial allocation are based on technical considerations, all additional address space is purely based on the utilization of the initial allocation. In order to meet the aggregation goal, requests for an initial allocation of a sub-TLA have to be carefully evaluated. It is not necessary for every requesting organization to obtain sub-TLA space. The following requirements must be met in order to obtain an initial allocation of sub-TLA address space:
The requesting organization's IPv6 network must be interconnected with the IPv6 networks of at least three other organizations that have a sub-TLA allocated to them, and either:
-- The requesting organization must have reassigned IPv6 addresses received from its upstream provider or providers to 100 SLA customer sites with routed networks. Dial-in customers do not count toward the 100 IPv6 customer sites.
This is far too high a bar for at least three reasons
1. nobody can meet it during the early stages of IPv6 deployment 2. there are many examples of non-profit networks, and certainly some for-profit networks, that do not achieve this scale, but must have at least a sub-TLA to avoid horrendous aggregation problems due to multihoming. This guideline definitely hurts aggregation. 3. this criterion also makes it very unlikely that metropolitan internet exchanges would qualify, yet metro exchanges are prime candidates for TLA or sub-TLA allocation (again to enable multihoming).
We suggest reducing the 100 to 10.
Customers currently using IPv4 host addresses for dial-up should not be assigned an NLA or an SLA, or
This seems redundant and gratuitous.
-- The requesting organization must demonstrate a clear intent to provide IPv6 service within 3 months after receiving allocated address space. This must be substantiated by such documents as an engineering plan or deployment plan.
We think 3 months is too short, even in our business. Change to 6 months.
The above criterion that requires interconnection with at least three other sub-TLAs creates a bootstrapping problem which can be resolved by the following requirements that have been defined for a bootstrapping period:
This seems to say that it's impossible to try to bootstrap an IPv6-only ISP. That's restraint of trade. Anyway, given your second option above (intent to provide service) why do we need the bootstrapping mechanism at all? Intent to supply service allows bootstrapping.
The requesting organization's network must have BGP peering relationships with at least three other public Autonomous Systems in default-free zones,
The requesting organization must show that it already has issued IPv4 address space to 100 customer sites that can meet the criteria for a /48 IPv6 reassignment, and
100 is too high as noted above.
The requesting organization must demonstrate a clear intent to provide IPv6 service within 3 months after receiving allocated address space. This must be substantiated by such documents as an engineering plan or deployment plan.
3 months is too short as noted above.
The first 50 requesting organizations who obtain a sub-TLA must fulfill either the criteria for the bootstrapping or the general criteria. Only 30 out of these 50 networks/organizations can be located in one region. After 50 sub-TLAs have been allocated, the bootstrap criteria will no longer apply.
We suggest 100 instead of 50, and lose the regional restriction and the next paragraph. We don't need this level of prudence.
...
4.1.2 Size for Initial Allocation/Slow-Start Mechanism
The initial allocation of sub-TLA space will allow 13 bits worth of NLA IDs to be utilized by the organization receiving the /35 reserved from the sub-TLA unless the requesting organization submits documentation to the Regional IR to justify an exception.
As noted above this is a totally inappropriate restriction. We do not need to conserve addresses to this extent. Sub-TLA assignees should get the full /29. All of the following text and the notion of extending sub-TLA allocations should be simplified and reworked to remove this whole notion.
...This initial allocation allows the organization to create a hierarchy within the allocation depending on their customer type (ISP or end-site) and the topology of their own network. For example: this allows the organization to receive 8,192 NLAs (a /48 each). The making of assignments (to ISPs or end-sites) is covered in section 4.2 in more detail.
The size of the initial allocation has been set to 13 bits because this allows the TLA Registry some freedom in creating an addressing hierarchy. If it has other Service Providers as customers (who in turn have their own end-user customers), this allows the TLA Registry to sub-allocate smaller blocks to each of them.
There is no need to do this and it hurts aggregation. This is IPv4-centric thinking.
4.1.3 Requirements for Next Allocation
Once an organization has used 80% of the sub-TLA address space, the organization may contact the Regional IR in its region to request that another range of addresses be allocated. The size of the next range depends on the utilization rate of the previous allocation.
The only reasonable step is from a complete sub-TLA (/29) to a shorter prefix. Here there are two models that the IETF probably needs to look at - the next step is a complete TLA (/16), or it is new form of sub-TLA somewhere betwen /16 and /29. However this is far-future and should be left for further study.
Simplify all this: allocate complete sub-TLAs and leave everything beyond this for further study. Just delete most of 4.1.3 for now.
...
4.1.3.2 Renumbering
This section is useful, unlike the rest of 4.1.3.
However, we will not be short of subTLAs or TLAs for many years. While it is good to make all allocations temporary, there is no need to recover subTLAs within 3 months of allocating a TLA to the same operator. Some would say this recovery should not be done at all in the early years; if it is to be done, the overlap period should be much longer, say 24 months. A minimum of 12 months should be guaranteed in perpetuity.
...
4.2 Assignments
4.2.1 Assignments to End-users
Every end-user organization receives a /48 worth of address space (80 bits). Out of this, 16 bits are an SLA block used for subnetting and another 64 bits are used per interface. All requests for additional address space from the same TLA Registry must be submitted to the Regional IR for evaluation (a second opinion). In this case the full utilization of the initial SLA must be documented. The need for additional address space must be presented in the form of an engineering plan. Since the SLA part of the end-user's assignment allows for creating 65,536 subnets, the organization must show in what way this was not sufficient for their network, and must present a plan showing where each of the 65,536 subnets is used and why new subnets are necessary.
This is plain wrong. The reason we went for 16 bits was not to allow for 65k subnets. It was to allow complex corporate networks to use the SLA space as an aggregatable address space. The last sentence should be something like
Since the SLA part of the end-user's assignment allows for a 16-bit aggregatable subnet addressing scheme, the organization must show why their network topology cannot be accommodated within a 16-bit addressing scheme.
...
4.2.2 Assignments and Allocations to Other ISPs
If the TLA Registry has ISP customers (who in turn have end-users), the TLA Registry could use the 13 bits of NLA address space to create
This should be 19 bits as noted above.
an addressing hierarchy for them.
Each of the TLA Registry's own end-users would receive a /48 as specified above, however, the ISP customers (NLAs) could be "allocated" additional bits in order to aggregate the ISP's customers internally. A slow-start mechanism will be used for these NLA allocations.
We agree with slow-start in this context. ...
4.3 Reclamation Methods/Conditions
Allocations are valid only as long as the original criteria are still met. The criteria for allocating TLA address space may change over time depending on routing technology. The current target is to limit the global routing space to roughly 8,000 entries. If 50% of this limit is reached, routing technology and allocation criteria will be reviewed. If routing technology allows additional route entries, the number of possible TLAs and sub-TLAs may be increased.
8000 is very modest. Who set this goal? It is also wrong; we can have about 8k TLAs and 8k sub-TLAs, so 16k is the correct value (and extremely conservative in terms of router technology).
Also this section should actually say that if the 50% limit (of 16k) is reached, the routing issues will be referred to the IETF.
If it turns out that routing technology at that time does not allow additional routing entries,
This won't happen, and in any case why worry about it today? Leave it all TBD.
...
5. ORGANIZATIONS OPERATING IN MORE THAN ONE REGION
If an organization requesting sub-TLA space operates in more than one region, and needs separate sub-TLA blocks for routing purposes, it should request the address space for its entire network from only one of the Regional IRs. It can apply for an initial allocation that is larger than 13 bits if it can show that its network is divided into several components with each needing its own sub-TLA route (each component individually needs to fulfill the criteria for being a TLA Registry). The size of the allocation would depend on how many top-level routes are needed.
For example, if a multinational transit provider can show that it needs three top-level routes, it would initially receive 15 bits of NLA space (a /33). It could then allocate a /35 to each of the top-level parts of the network and route each one separately. Each of these sub-allocations would need to be entered in the database of the Regional IR individually.
This doesn't compute. We don't expect to see /35 or even /33 announcements at the default-free level. The goal is aggregation at TLA and subTLA level, with nothing smaller being advertised. We'd even expect such a provider to be multihomed with several /29s. Again, we just don't have to conserve to this degree.
Regards
Brian Carpenter IAB Chair
David K. ---
Hi David, Any possibility that the minutes, or a summary, from the IPv6 WG session can be forwarded to the list for the benefit of those of us who weren't able to be present? Thanks! philip -- At 16:45 17/02/99 -0700, David Kessens wrote:
Hi,
Included below are the comments from the IAB on the 'IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT (3rd draft)'.
I personnally think that the IAB's comments are pretty close to the suggestions that the wg decided on during the RIPE IPv6 wg session in Amsterdam.
I welcome your input, including endorsements of the changes suggested by the IAB.
David K. ---
Forwarded message:
From brian@hursley.ibm.com Mon Feb 15 04:57:10 1999 Message-ID: <36C7EE30.3A84DFB3@hursley.ibm.com> Date: Mon, 15 Feb 1999 09:51:44 +0000 From: Brian E Carpenter <brian@hursley.ibm.com> Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Daniel.Karrenberg@ripe.net, Mirjam Kuehne <mir@ripe.net>, kimh@arin.net, Anne Lord <anne@apnic.net>, pwilson@apnic.net CC: IAB <iab@iab.org> Subject: Re IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT (3rd draft) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit
Dear colleagues,
Re IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT (3rd draft)
The IAB has been looking at this draft and here are our comments (which are not confidential in any way).
It's very good to see the registries working actively on this important topic. However there are two points of concern about the current version, one political and one technical.
The political one is easy to fix. Referring to ICANN is contentious in this context, and referring to IANA is not contentious. So please replace all reference to ICANN by IANA. It doesn't change anything but it will reduce argument.
The technical one is more tricky. Basically the draft errs too much on the side of address conservation. While it is important to be prudent and to avoid creating an IPv6 toxic waste dump, we do have a lot more freedom than with IPv4. The draft doesn't take full advantage of this, with the paradoxical effect that aggregation is harmed and unnecessary renumbering is forced. We can afford to be more generous with subTLA space and less restrictive with slow start. The detailed comments below almost all relate to this point.
IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT (3rd draft) ...
ABSTRACT
This document describes the registry system for the distribution of globally unique IPv6 address space, which follows a hierarchical distribution as it does with IPv4. The distribution of IPv6 address space is managed by the IANA (formerly IANA) and further delegated by
...space is managed by the IANA and...
(it is managed by IANA and only by IANA.)
...
This document does not describe private IPv6 address space, or anycast
There is no such thing as private IPv6 address space. There are site-local and link-local IPv6 addresses defined architecturally.
...
2.1.1 IANA
The Internet Corporation for Assigned Names and Numbers (IANA) has
Remove all mention of ICANN which is a red rag to many bulls. The Authority lies with IANA.
authority over all number spaces used in the Internet, including IPv6 address space. IANA allocates parts of the IPv6 address space to Regional Internet Registries (IRs) according to their established needs. ... 2.2 Goals of the Internet Registry System
The remainder of this document is primarily concerned with the management of public IPv6 address space. Every assignment of IPv6 addresses should be made with the following goals in mind for it is in the interest of the Internet community as a whole that these goals be pursued. It is worth noting that "conservation" and "aggregation" are often conflicting goals, and therefore each assignment must be evaluated carefully.
This is IPv4 thinking. Aggregation is what matters for IPv6. Conservation is not a major goal; avoidance of profligacy is the goal, which is much weaker. Suggested rewrite of the last sentence:
Each assignment must be evaluated carefully to ensure good aggregation without being profligate with address usage.
Moreover, these goals may occasionally be in conflict with the interests of individual end users or ISPs.
They will be in conflict. Suggested rewrite:
In the case of IPv4, the necessary heavy emphasis on address conservation, and the attempt to retrofit aggregation, have combined to cause frequent conflict betwen the interests of end users and smaller ISPs with those of the network as a whole. It has also favoured the use of private address space with its unfortunate architectural side effects. IPv6 allows this conflict to be avoided in future.
In such cases, careful analysis and judgement are necessary to find an appropriate compromise.
Delete this sentence; this compromise is not needed for v6.
...
2.2.3 Conservation
The word "Conservation" should be replaced by "Avoidance of profligacy" in the title and everywhere else. Don't misunderstand this as being against conservation: but this draft goes overboard.
...
For purposes of a slow start of a sub-TLA, however, a first sub-TLA allocation would actually always be a /35 block (13 bits instead of 19).
There is no need to slow-start sub-TLAs; in fact it makes no sense. A sub-TLA is always going to be allocated to a single operator; backbone ISPs will certainly not want to see /35 announcements - We expect they will filter anything longer than /29.
Sub-TLAs should be fully allocated. (To put it another way, Sub-TLAs *are* the slow-start mechanism.)
...
4.1.1 Requirements for Allocating a Sub-TLA
In order to meet the conservation and aggregation goals discussed above, only requesting organizations that meet certain requirements will be allocated sub-TLA space. The requirements for an initial allocation to an organization are different from the requirements that have to be met once the initial allocation has been used and additional address space is requested.
Whereas the requirements for an initial allocation are based on technical considerations, all additional address space is purely based on the utilization of the initial allocation. In order to meet the aggregation goal, requests for an initial allocation of a sub-TLA have to be carefully evaluated. It is not necessary for every requesting organization to obtain sub-TLA space. The following requirements must be met in order to obtain an initial allocation of sub-TLA address space:
The requesting organization's IPv6 network must be interconnected with the IPv6 networks of at least three other organizations that have a sub-TLA allocated to them, and either:
-- The requesting organization must have reassigned IPv6 addresses received from its upstream provider or providers to 100 SLA customer sites with routed networks. Dial-in customers do not count toward the 100 IPv6 customer sites.
This is far too high a bar for at least three reasons
1. nobody can meet it during the early stages of IPv6 deployment 2. there are many examples of non-profit networks, and certainly some for-profit networks, that do not achieve this scale, but must have at least a sub-TLA to avoid horrendous aggregation problems due to multihoming. This guideline definitely hurts aggregation. 3. this criterion also makes it very unlikely that metropolitan internet exchanges would qualify, yet metro exchanges are prime candidates for TLA or sub-TLA allocation (again to enable multihoming).
We suggest reducing the 100 to 10.
Customers currently using IPv4 host addresses for dial-up should not be assigned an NLA or an SLA, or
This seems redundant and gratuitous.
-- The requesting organization must demonstrate a clear intent to provide IPv6 service within 3 months after receiving allocated address space. This must be substantiated by such documents as an engineering plan or deployment plan.
We think 3 months is too short, even in our business. Change to 6 months.
The above criterion that requires interconnection with at least three other sub-TLAs creates a bootstrapping problem which can be resolved by the following requirements that have been defined for a bootstrapping period:
This seems to say that it's impossible to try to bootstrap an IPv6-only ISP. That's restraint of trade. Anyway, given your second option above (intent to provide service) why do we need the bootstrapping mechanism at all? Intent to supply service allows bootstrapping.
The requesting organization's network must have BGP peering relationships with at least three other public Autonomous Systems in default-free zones,
The requesting organization must show that it already has issued IPv4 address space to 100 customer sites that can meet the criteria for a /48 IPv6 reassignment, and
100 is too high as noted above.
The requesting organization must demonstrate a clear intent to provide IPv6 service within 3 months after receiving allocated address space. This must be substantiated by such documents as an engineering plan or deployment plan.
3 months is too short as noted above.
The first 50 requesting organizations who obtain a sub-TLA must fulfill either the criteria for the bootstrapping or the general criteria. Only 30 out of these 50 networks/organizations can be located in one region. After 50 sub-TLAs have been allocated, the bootstrap criteria will no longer apply.
We suggest 100 instead of 50, and lose the regional restriction and the next paragraph. We don't need this level of prudence.
...
4.1.2 Size for Initial Allocation/Slow-Start Mechanism
The initial allocation of sub-TLA space will allow 13 bits worth of NLA IDs to be utilized by the organization receiving the /35 reserved from the sub-TLA unless the requesting organization submits documentation to the Regional IR to justify an exception.
As noted above this is a totally inappropriate restriction. We do not need to conserve addresses to this extent. Sub-TLA assignees should get the full /29. All of the following text and the notion of extending sub-TLA allocations should be simplified and reworked to remove this whole notion.
...This initial allocation allows the organization to create a hierarchy within the allocation depending on their customer type (ISP or end-site) and the topology of their own network. For example: this allows the organization to receive 8,192 NLAs (a /48 each). The making of assignments (to ISPs or end-sites) is covered in section 4.2 in more detail.
The size of the initial allocation has been set to 13 bits because this allows the TLA Registry some freedom in creating an addressing hierarchy. If it has other Service Providers as customers (who in turn have their own end-user customers), this allows the TLA Registry to sub-allocate smaller blocks to each of them.
There is no need to do this and it hurts aggregation. This is IPv4-centric thinking.
4.1.3 Requirements for Next Allocation
Once an organization has used 80% of the sub-TLA address space, the organization may contact the Regional IR in its region to request that another range of addresses be allocated. The size of the next range depends on the utilization rate of the previous allocation.
The only reasonable step is from a complete sub-TLA (/29) to a shorter prefix. Here there are two models that the IETF probably needs to look at - the next step is a complete TLA (/16), or it is new form of sub-TLA somewhere betwen /16 and /29. However this is far-future and should be left for further study.
Simplify all this: allocate complete sub-TLAs and leave everything beyond this for further study. Just delete most of 4.1.3 for now.
...
4.1.3.2 Renumbering
This section is useful, unlike the rest of 4.1.3.
However, we will not be short of subTLAs or TLAs for many years. While it is good to make all allocations temporary, there is no need to recover subTLAs within 3 months of allocating a TLA to the same operator. Some would say this recovery should not be done at all in the early years; if it is to be done, the overlap period should be much longer, say 24 months. A minimum of 12 months should be guaranteed in perpetuity.
...
4.2 Assignments
4.2.1 Assignments to End-users
Every end-user organization receives a /48 worth of address space (80 bits). Out of this, 16 bits are an SLA block used for subnetting and another 64 bits are used per interface. All requests for additional address space from the same TLA Registry must be submitted to the Regional IR for evaluation (a second opinion). In this case the full utilization of the initial SLA must be documented. The need for additional address space must be presented in the form of an engineering plan. Since the SLA part of the end-user's assignment allows for creating 65,536 subnets, the organization must show in what way this was not sufficient for their network, and must present a plan showing where each of the 65,536 subnets is used and why new subnets are necessary.
This is plain wrong. The reason we went for 16 bits was not to allow for 65k subnets. It was to allow complex corporate networks to use the SLA space as an aggregatable address space. The last sentence should be something like
Since the SLA part of the end-user's assignment allows for a 16-bit aggregatable subnet addressing scheme, the organization must show why their network topology cannot be accommodated within a 16-bit addressing scheme.
...
4.2.2 Assignments and Allocations to Other ISPs
If the TLA Registry has ISP customers (who in turn have end-users), the TLA Registry could use the 13 bits of NLA address space to create
This should be 19 bits as noted above.
an addressing hierarchy for them.
Each of the TLA Registry's own end-users would receive a /48 as specified above, however, the ISP customers (NLAs) could be "allocated" additional bits in order to aggregate the ISP's customers internally. A slow-start mechanism will be used for these NLA allocations.
We agree with slow-start in this context. ...
4.3 Reclamation Methods/Conditions
Allocations are valid only as long as the original criteria are still met. The criteria for allocating TLA address space may change over time depending on routing technology. The current target is to limit the global routing space to roughly 8,000 entries. If 50% of this limit is reached, routing technology and allocation criteria will be reviewed. If routing technology allows additional route entries, the number of possible TLAs and sub-TLAs may be increased.
8000 is very modest. Who set this goal? It is also wrong; we can have about 8k TLAs and 8k sub-TLAs, so 16k is the correct value (and extremely conservative in terms of router technology).
Also this section should actually say that if the 50% limit (of 16k) is reached, the routing issues will be referred to the IETF.
If it turns out that routing technology at that time does not allow additional routing entries,
This won't happen, and in any case why worry about it today? Leave it all TBD.
...
5. ORGANIZATIONS OPERATING IN MORE THAN ONE REGION
If an organization requesting sub-TLA space operates in more than one region, and needs separate sub-TLA blocks for routing purposes, it should request the address space for its entire network from only one of the Regional IRs. It can apply for an initial allocation that is larger than 13 bits if it can show that its network is divided into several components with each needing its own sub-TLA route (each component individually needs to fulfill the criteria for being a TLA Registry). The size of the allocation would depend on how many top-level routes are needed.
For example, if a multinational transit provider can show that it needs three top-level routes, it would initially receive 15 bits of NLA space (a /33). It could then allocate a /35 to each of the top-level parts of the network and route each one separately. Each of these sub-allocations would need to be entered in the database of the Regional IR individually.
This doesn't compute. We don't expect to see /35 or even /33 announcements at the default-free level. The goal is aggregation at TLA and subTLA level, with nothing smaller being advertised. We'd even expect such a provider to be multihomed with several /29s. Again, we just don't have to conserve to this degree.
Regards
Brian Carpenter IAB Chair
David K. ---
Philip, On Fri, Feb 19, 1999 at 09:58:59AM +1000, Philip Smith wrote:
Any possibility that the minutes, or a summary, from the IPv6 WG session can be forwarded to the list for the benefit of those of us who weren't able to be present?
I just got the unedited version of the minutes from the RIPE NCC. I haven't had a chance to do any editing and I will not have such a chance in the next week since I will be travelling. I will post a more complete version when I am back. I hope this helps, David K. --- ----------------------- Minutes of the IPv6 WG Attendees -------> xx Previous chair --> Thomas Trede (TT3-RIPE) New chair -------> David Kessens (DK13-RIPE) Scribe ----------> Sabrina Waschke (SAWA1-RIPE) Co-scribe -------> Bernard Tuy (BT261-RIPE) AGENDA A. Administrative stuff (David Kessens, chair, 5min) - appointment of scribe - agenda bashing B. Selection of new chair C. Review of action points: 31.1 RIPE NCC will start allocating IPv6 addresses by the next RIPE meeting in January 1999. 31.2 send out to 1) experienced people draft documents about address registration and allocation 2) concerned WGs more finalized papers to stress the discussion and have working papers ready by the end of '98. D. Status of 6bone (David Kessens) E. 6REN - first IPv6 production network (David Kessens, presentation originally from Bob Fink) F. inet6num object in the RIPE Database G. IPv6 allocation progress (Paula Caslav) - discussion of 'IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT (3rd draft)' H. Experience from ISPs with IPv6 (input from audience requested) I. Future directions of the WG Z. AOB B. Selection of new chair - - - David Kessens approved as new chair - - - Jan Czmok mwentioned in e-mail that he is interested, but was not present at the meeting --> possibility to be the co-chair in future C. Review of action points: 31.1 RIPE NCC will start allocating IPv6 addresses by the next RIPE meeting in January 1999. - - - postponed : RIPE NCC will start allocating IPv6 addresses in the first quarter of 1999. C. Review of action points: 31.2 send out to 1) experienced people draft documents about address registration and allocation 2) concerned WGs more finalized papers to stress the discussion and have working papers ready by the end of '98. - - - 1) DONE - - - 2) DONE D. Status of 6bone (David Kessens) - - - URL of presentation : - - - experimental 6bone network is growing fast (exponential) - - - 39 countries registered - - - ca. 1700 queries and 8 updates per day - - - 245 ipv6 ojects - - - registry will be moved from ISI to Quest where David Kessens works yet E. 6REN - first IPv6 production network (David Kessens, presentation originally from Bob Fink) - - - URL of presentation : - - - 6REN is an experimental testbed initiated by Bob Fink from ESnet - - - ESnet, CAIRN, I2/vBNS, CAnet3 and WIDE want to interconnect in IPv6/ATM to promote and coordinate production quality IPv6 network - - - a registry will be available by Qwest as for 6bone F. inet6num object in the RIPE Database - - - slight changes were proposed : status field & maintain-lower functionality to be added --> general aggreement that this is ok G. IPv6 allocation progress (Paula Caslav) - discussion of 'IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT (3rd draft)' - - - URL of presentation : http://www.ripe.net/meetings/ripe/ripe-32/pres/ - - - short SUMMARY : - draft is joined work of all 3 Regional IR (want of globally consistent procedures & guidelines) - bootstrap criteria: - must have 3 peers and at least 100 IPv4 customers or plans to offer IPv6 service in next 3 months - regular criteria : - must interconnected with 3 subTLAs carriers and have at least 100 IPv6 customers or have plans to extend IPv6 service in the next 3 months - - - COMMENTS from audience : - 3 months are not realistic, vendors won't be ready yet in 3 months - what includes "IPv6 service" ? --> WG should not interfere in business - discussion about the number 100 ["100 IPv4 (->IPv6) customers"], some felt this is too restrictive - don't impose more than 2 steps in going to a TLA prefix (don't add additionnal subdivisions, in NLAs ...) - - - timeline : - need comments from the RIPE community (--> within 2 weeks !) - discussion of changes within the Regional IR's - get a block from the IANA/ICANN - start IPv6 assignments - - - discussion about IPv6 ASSIGNMENT AND ALLOCATION POLICY on IPv6 RIPE mailing list : <ipv6-wg@ripe.net> - - - there will probably be an extra document for the reverse delegation - - - no RIPE NCC billing charge changes in 1999 - - - Quote from the draft: "All router interfaces are required to have at least one link-local unicast address or site-local address. Site-local will be used for all point-to-point links, loopback addresses, and so forth. As these are not required to be visible outside the site's network, they do not require public address space." --> suggestion to change "will be used" to another wording, e.g. "it is recommended" because of possible problems with traceroute - - - have the aggregation criterion as the first goal and conservation as a secondary goal ! - - - "utilization" what does this mean ? --> 80 % of SLA space given out - - - geographical aggregation ? --> depends, might happen with exchange points - - - URL for more info : http://www.ripe.net/lir/registries/ipv6.html H. Experience from ISPs with IPv6 (input from audience requested) - - - Dante and Terena will perform tests with IPv6 to interconnect European NRENs - - - UUnet UK will be becoming part of the 6REN project I. Future directions of the WG - - - growing number of interested people - - - set a tutorial up for the next RIPE meeting (Vienna) - - - provide IPv6 connectivity at the next RIPE meeting (Vienna) Z. AOB - - - IETF IPng & NGtrans interim meeting at IMAG in Grenoble Feb. 2 - Feb. 4, 1999 http://www.ipv6.imag.fr/ietf1999.html ---- end of minutes ----
participants (2)
-
David Kessens -
Philip Smith