- ipv6-wg - mailman.ripe.net

IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT
by Francis Dupont 20 Feb '99

20 Feb '99

IAB comments addressed my main concern about the document: a too large part given to "Conservation" but I still have minor comments: - 4.1.3.1 Verification of Utilization it is not reasonable to ask that all assignments to end-sites must be registered in the public database: ISPs need some kind of confidentiality in their business (cf Ruediger Volk). - same sub^3 section ping doesn't work well with anycast destinations - 4.2.1 Assignments to End-users I'd like to see conditions of assignment for: * an address (128 bit "prefix") * a subnet (64 bit prefix) * a site (48 bit prefix) Today one of more nasty problems is for a dial-up user it is hard (or expensive) to get more than one (dynamic) address then many people install NATs for that not technical reason. Of course we don't want to see the same thing with IPv6 then this point must be clear and there will be a FAQ about the "connected dentist office" (technically easy, it is a case where RIPng is well suit!) - I can't understand second opinion requirements (a must for users and a should for ISPs). I am impatient to read the next version of the document... Francis.Dupont(a)inria.fr

1 0

Re: IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT (3rd draft)
by Bernard.Tuy＠urec.cnrs.fr 18 Feb '99

18 Feb '99

| Date: Wed, 17 Feb 1999 16:45:46 -0700 | From: David Kessens <david(a)Qwest.net> | | 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. ====BT: If I agree with David's comment above and with the IAB answer to the document, a question remains : -what will be now the procedure(s) to get an "operational" document ? Do we have -still- to wait a long time, before official allocation will start ? One could argue nothing is urgent still no networks are ready to deploy for production traffic yet. But it's again a "chicken & egg" problem ... ? Regards, +bernard Tuy.

2 1

IAB comments on IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT
by Mirjam Kuehne 18 Feb '99

18 Feb '99

Dear colleagues, Please find below comments we received from the IAB on the draft "IPv6 Assignment and Allocation Policy Document". Kind Regards, Mirjam Kuehne ------- Forwarded Message Date: Mon, 15 Feb 1999 09:51:44 +0000 From: Brian E Carpenter <brian(a)hursley.ibm.com> To: Daniel.Karrenberg(a)ripe.net, Mirjam Kuehne <mir(a)ripe.net>, kimh(a)arin.n et, Anne Lord <anne(a)apnic.net>, pwilson(a)apnic.net cc: IAB <iab(a)iab.org> Subject: Re IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT (3rd draft) 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 u sed > > 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 ------- End of Forwarded Message

1 0

Re: IPv6 Assignment and Allocation Policy Document
by Poul-Henning Kamp 17 Feb '99

17 Feb '99

[ Moderator note: changed local-ir(a)ripe.net -> ipv6-wg(a)ripe.net ] Could somebody take the time to explain how multi-homing works in this setup ? I have either not grasped it or not found the place where it is described. Lets take a small ISP who have "upstream" connections to one TLA and two sub-TLA entities. Are they required to become a sub-TLA ? if yes: What if they don't meet one of the formal requirements for that ? Would failing to become a sub-TLA prevent them from opening "general" peerings with one or more of these (sub-)TLAs ? (in other words: will these policies discourage and prevent multihoming ?) if no: Which IPv6 numbers will they use ? How will route-aggregation work in this case ? Will each host have 3 IPv6 numbers listed in DNS ? Sorry if these are stupid questions, but I'm probably not the only one being unenlightened in this area... -- Poul-Henning Kamp FreeBSD coreteam member phk(a)FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far!

3 2

Re: Policy draft
by Alain Durand 16 Feb '99

16 Feb '99

I would like to comment on the IPv6 assignment and allocation policy document 1. Terminology. ------------------- I would suggest that this document use the same terminology as the one used in the various IPv6 related RFC, e.g. site local addresses instead of private addresses Also in section 2.2.3, this document refers to 80 bits available for addressing end sites. I would suggest to say at this point that this is 16 + 64 bits. Same total, but the usage is different. 2. Sites and /48 prefixes ------------------------------ I would like this document to define precisely sites. This will make it clear who can (or not) claim a /48 prefix. The document says in section 4.2.1: Only end-user organizations with a need to create subnets in their network should be assigned a full /48. Dial-up lines are considered part of the ISP's infrastructure and should be assigned from the SLA ofthat ISP. I disagree there. The network in my house may be composed of several subnets and still be connected to my ISP via dial-up. (again, we have to define precisely sites) All end-user organization requesting to be a site should get a /48. Address conservation is good practice, but, there, it's asking too much. 3. 80% Requirements for next allocation -------------------------------------------------- in 4.1.3: 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 I would suggest the document to be more precise about this. This can not be 80% of the all address space of the sub-TLA. A sub-TLA being /35, the total address space is 103 bits long! So, there must be a limit somewhere, for example say it's 80% of the address space in between bit 36 and bit 48. This is correct if a sub-TLA is only servicing sites and not NLAs. If a sub-TLA is servicing NLAs, requesting that all NLAs must use 80% of their address space before the sub-TLA may ask for a full TLA is, IMHO, too strong a requirement. I fear that sub-TLA will then be reluctant to allocate NLA. 4. Router interfaces ------------------------ in section 3.2: 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. Interfaces are required to have a link local address. Not site local. Their use is at the discretion of sites. Some may like them, some not. For administrative reasons, as site borders are often crossed, they are valid cases where router interfaces (and point-to-point links) MUST have global addresses. If I want to ping , from my host, to a router I'm responsible for, on one particular interface and if that router in not within my site borders, I need to find a global address for that particular interface. Any global unicast address space assigned must not be used for the link-local or site-local purpose as there is reserved address space for these addresses. Again, I disagree. This is NOT because two hosts are within the same site that they MUST use site local addresses. This requirement is not acceptable. Some sites may want to implement this, some not. It requires a lot of techniques to do it, including source address selection, DNS tricks and others. 5. General comments -------------------------- This document is focusing heavily on address conservation. Learning IPv4 mistake is a reasonable goal, but IPv6 addresses are so structurally different from IPv4 ones that address conservation should not be so restrictive. Also, the document specificaly ask that all special SLA request MUST be approved by the regional registries. IMHO, those issues should be better resolved at a lower level, NLA and/or SLA. Multi-homing will be more and more frequent. The way ISP will implement multi-homing in IPv6 may have a big impact on aggregation. I would like to see a section on this particular topic in this document. - Alain Durand.

1 0

Re: IPv6 Assignment and Allocation Policy Document
by Bernard.Tuy＠urec.cnrs.fr 16 Feb '99

16 Feb '99

Hi Paula et al, In response to your email for discussing the draft you sent out before the Ripe meeting, please find enclosed my comments (to the draft itself and to Simon's comments for he's been the first one to give us an input. Others will be more than welcome ... Regards, +Bernard T. P.S.: my comments are flagged : "====BT:" | | - --------------------begin included draft---------------------------- | | | IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT (3rd draft) | | TABLE OF CONTENTS | | Abstract | 1. Scope (...) | | 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 | the Regional Internet Registries (IRs) as described in RFC 1881. The | Regional IRs assign Top-Level Aggregation Identifiers (TLAs) to | organizations, which in turn assign address space to other Internet | Service Providers (ISPs) and end users. This document describes the | policies and procedures associated with IPv6 address space management | that must be followed by the organizations that hold Top-Level | Aggregate IDs. Since ISPs essentially will be serving as NLA | Registries for their customers, creating additional "layers" to the | Registry system, it is crucial that responsibilities, procedures, and | policies are well understood and consistently applied. | | 1. SCOPE | | This document first describes the global Internet Registry system for | the distribution of globally unique unicast IPv6 address space, as | defined in RFC 2374, and its operation, then describes the rules and | guidelines governing the distribution of this address space. The rules | set forth in this document are binding for all organizations that have | IPv6 address space allocated and assigned via a Regional IR. | | This document does not describe private IPv6 address space, or anycast | and multicast address space distribution. | | | Simon: Why not write what this document does describe instead of writing | wehat it does not do? This document describe aggregatable Global Unicast | Address distribution. ====BT: As I can see, it's just written few lignes above ... "This document first describes ..." seems clear and good like this to me. | | I really don't like the use of the term "private IPv6 address space", | you do not find the term private address space used in any of the IPng | working group documents. RFC2373 uses the term "local use addresses" to | destingrise between aggregatable Global Unicast Addresses and | {link/site}-local addresses. | :nomis ====BT: agree with this. One should stick RFC taxonomy. But I guess confusion is coming from IPv4 useage ... | | It also does not describe | regional and local refinements of the global rules and | guidelines. This document serves as the base set of operational | guidelines in use by all Regional IRs. Additional guidelines may be | imposed by a particular Regional IR as appropriate. As experience is | gained in allocating IPv6 addresses, these rules and guidelines may | change. | | The remaining sections of this document are presented as follows: | (...) | | | 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. Moreover, these goals may occasionally be in | conflict with the interests of individual end users or ISPs. In such | cases, careful analysis and judgement are necessary to find an | appropriate compromise. The rules and guidelines in this document are | intended to help Regional IRs, ISPs, and end-users in their search for | effective solutions. ====BT: for multi-homed {sites, ISPs ...} none of this applied ("conservation" nor "aggregation"). Will a special procedure be designed later to handle this feature that'll be widespread as I can guess it in a near future ? | | | 2.2.3 Conservation | | Although IPv6 network address resources appear to be endless, care | must be taken to avoid repetition of the IPv4 problems and instead | focus on demonstrated need. These precautions will help manage and | conserve IPv6 network addresses for future use. | | In order to mitigate this problem in use of IPv6, conservation is one | of the main goals. It should be noted however, that the IPv6 | addressing architecture allows end-sites a great amount of | flexibility. Eighty bits out of a total of 128 bits available in an | IPv6 address are used for addressing an end-site. Address space can be | conserved only by carefully evaluating the requirements from TLAs and | NLAs and allocating address space on the basis of demonstrated need. | | Experience has shown that the growth and the consequences of growth | were never anticipated with IPv4. The Regional IRs will apply the | lessons from the IPv4 experience to ensure that conservative policies | are implemented from the beginning. ====BT: even if one can clearly understand and agree this conservation constraint and goal, it's important to have a quite soft behaviour applying this rule keeping in mind the most important thing is to allocate -simply, quickly, and efficiently- address resources one needs to run its own network. | | 2.2.4 Registration | | In response to the rapid growth of Internet activity, a public | registry system was established to document address space allocation | and assignment. This was necessary to ensure uniqueness of Internet | addresses and to provide information for Internet trouble-shooting at | all levels. As with IPv4 addresses, each of the Regional IRs maintains | a public database where all IPv6 assignments and reassignments are | entered so that network operators can identify other network | organizations. ====BT: I don't remind if somewhere else in this document one considers to set a IRR as well ? this has been discussed in the 2 last Routing WG meetings and seems to me at least as useful as IR DB in terms of trouble-shooting ... ? At least we experienced so with IPv4 IRRs. | | 3. IPv6 TECHNICAL FRAMEWORK | | 3.1 IPv6 Addressing Hierarchy | | RFC 2373 specifies that aggregatable addresses are organized into a | topological hierarchy which consists of a public topology, a site | topology, and interface identifiers. These in turn map into the | following: | | Simon: No, this is in RFC2374. | | | | 3| 13 | 8 | 24 | 16 | 64 bits | | +--+-----+---+--------+--------+--------------------------------+ | |FP| TLA |RES| NLA | SLA | Interface ID | | | | ID | | ID | ID | | | +--+-----+---+--------+--------+--------------------------------+ | |-- public topology---| site | Interface | | | |topology| | | +---------------------+--------+--------------------------------+ | | | | | |-------- network portion----->+<-------host portion------------| | | /64 | | |---------------------------------------------------------------| | | The site topology is represented by a /48. ====BT: I'm not sure for the wording : I'd prefer "The site prefix is represented by a /48" | Each site has a potential | for 65,535 subnets as specified in RFC 2374. The network portion is | represented by the first 64 bits. ====BT: again I don't know what a "portion" is ... but I clearly can understand what a "network prefix" is. (The notation /xx, introduced with CIDR refers to prefixes. The same idea -and taxonomy- has been kept for IPv6) | The host portion is represented by | the last 64 bits of the address. A /64 is the minimum network prefix | that can be assigned within a site. Additional subnets would require | additional prefixes of the same size or shorter to be assigned. Note | that the boundaries are "hard" between the network and host portions | and that the ID address space cannot be further sub-divided as all | interface ID's are required to be in the EUI-64 format as per RFC | 2373/4. The boundaries are also hard between the public topology and | the site topology division at the /48. The technical motivation for | this is given in RFC 2374 in order to facilitate multi-homing. | | In IPv6, the following prefix boundaries are suggested: | | | number of the number of the ID | left-most right-most longest length | bit boundary bit boundary prefix (in bits) | ************ ************ ******* ******** | TLA ID 4 16 /16 13 | Reserved 17 24 N/A 8 | NLA ID 25 48 /48 24 | SLA ID 49 64 /64 16 | | 3.2 Initial IPv6 Addressing Hierarchy | | A slightly modified version of the above (a special case of TLA | 0x0001) derives a sub-TLA portion from principally the reserved | address space. This has been described in RFC 2450. | | This has the following format and prefix boundaries: | | | 3| 13 | 13 | 19 | 16 | 64 bits | | +--+----------+---------+---------+--------+--------------------+ | |FP| TLA | sub-TLA | NLA | SLA | Interface ID | | | | ID | | ID | ID | | | +--+----------+---------+---------+--------+--------------------+ | | For this TLA, this means that there are the following prefix boundaries: | | number of the number of the ID | left-most right-most longest length | bit boundary bit boundary prefix (in bits) | ************ ************ ******* ******** | TLA ID 4 16 /16 13 | sub-TLA ID 17 29 /29 13 | NLA ID 30 48 /48 19 | SLA ID 49 64 /64 16 | | 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). ====BT: I guess one will mean : "a first sub-TLA allocation would actually be a /35 prefix (19 bits sub-TLA instead of 13 as shown is the previous table)". The slow start allocation scheme is shown in the table below : | 3| 13 | 19 | 13 | 16 | 64 bits | +--+----------+---------+---------+--------+--------------------+ |FP| TLA | sub-TLA | NLA | SLA | Interface ID | | | ID | | ID | ID | | +--+----------+---------+---------+--------+--------------------+ Since it'll be the scheme IRs will use at the beginning of the allocation process it's seems to me not so stupid to add this table in the document to let everyone undestand not only what the specs say but how it's implemented with the IRs ... ? | | All router interfaces are required to have at least one link-local | unicast address or site-local address. ====BT: BTW, every node must have at least one link-local address, not only routers ! | | Site-local will be used for all point-to-point links, loopback addresses, and so forth. ====BT: we suggested at the last RIPE meeting to rephrase as : "Site-local MAY be used ..." | | As these are | not required to be visible outside the site's network, they do not | require public address space. Any global unicast address space | assigned must not be used for the link-local or site-local purpose as | there is reserved address space for these addresses. (Note that all | 1's and all 0's are valid unless specifically excluded through | reservation. See list of reserved addresses in RFC 2373.) ====BT: I do remind Francis D. and Guy D. had comments on this, I hope they have been taken into account ... or would it be a good idea to formulate them again yet ? | | 4. ADDRESSING POLICIES | | | 4.1.1 Requirements for Allocating a Sub-TLA | (...) | | 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. | Customers currently using IPv4 host addresses for dial-up | should not be assigned an NLA or an SLA, or ====BT: just want to underline the last -small- word of the sentence above : "OR" and keep track of the WG discussion ... | | -- 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. | | 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: | | The requesting organization's network must have BGP peering | relationships with at least three other public Autonomous Systems in | default-free zones, ====BT: I'd suggest to rephrase this as : "The requesting organization's network must have IPv6 BGP peering relationships ... " the motivation is that until an org has got an experience with IPv6 routing it doesn't seem reasonnable to involved it in an important topology place of the Internet (this org is supposed then to aggregate ISPs prefixes it has allocated to ) ... I guess it's better the org gets first experience using a NLA from someone else or a pTL/A from 6bone or something like ... Then this org will request for a sub-TLA. | | 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. 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. ====BT: again, in all of these descriptions, I think -IMHO- concepts will get clearer if one speaks in term of prefixes (/35 prefixes for sub-TLAs and /48 prefixes for NLAs. This way it becomes obvious NLAs addressing space is 13 bits : 48 - 35) ... ?? | | 4.1.3 Requirements for Next Allocation | | 4.1.3.1 Verification of Utilization | | All assignments to end-sites must be registered in the database of the | Regional IR in the region the sub-TLA holder operates. The TLA | Registry is responsible for the utilization of the sub-TLA and the | registration of the end-site assignments and ISP allocations in the | database. The Regional IR will verify whether all assignments are | registered in the database. In addition to the database entries, the | Regional IR may ask for periodic reports describing the utilization of | the addresses to be sent. | | It is required that the end-sites be connected and reachable. The | Regional IR has the right to ping end-sites' /48s. Filtering holes | should be negotiated by the Regional IR and the organization with the | addresses. Therefore, it is suggested that end-sites use anycast | cluster addresses on their border routers to enable this. It is | expected that one /48 SLA block is enough address space per | end-site. If an end-site requests an additional SLA, the sub-TLA | holder must send the request to the Regional IR for a second opinion. | The information provided below shows address boundaries and their | corresponding amount of address space. | ====BT: | a TLA = /16 of address space | an NLA = /48 of address space | an SLA = /64 of address space | | TLA block = 13 bits of address space | NLA block = 19 bits of address space | SLA block = 16 bits of address space ====BT: that's already described above (see 3.2 and the additional table I've suggested to include there). Not sure one has to repeat this again ... ? Moreover it's confusing with the slow start mechanism where "boundaries" have been set up another way. | | 4.1.3.2 Renumbering | | Once it has been decided to allocate additional TLA space to a sub-TLA | holder, the previously allocated sub-TLA must be returned to the | Regional IR. The sub-TLA holder must then renumber its own | network. This of course has an impact on all of its customers and | customers' networks. Therefore, it is recommended that the sub-TLA | holder and its ISP customers make contractual arrangements with their | customers at the time of the first assignment. These arrangements | should clarify that the address space will have to be returned in the | event the sub-TLA holder requests a full TLA, in which case, all | end-sites must be renumbered. The sub-TLA holder should inform its | customers early on regarding the upcoming need to renumber. The | sub-TLA will have 3 months to return the sub-TLA space after the next | TLA has been allocated. ====BT: Not sure this faces the operational constraints of ISPs ... As I can understand the reasons to give a wider address space with the guarantee of gathering the old one (conservation principle) It seems to introduce complex procedures between ISPs and their customers I'm not sure are ... let's say, reasonnable. | | 4.2 Assignments | | 4.2.1 Assignments to End-users | | Every end-user organization receives a /48 worth of address space (80 | bits). ====BT: "Every end-user organization receives a /48 prefix (80 bits address space)..." | Out of this, 16 bits are an SLA block used for subnetting and | another 64 bits are used per interface. ====BT: "... the left-most 16 bits are a SLA block (/64 prefix) used ... the 64 remaining bits are used as an interface identifier" | 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. | | | 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 | 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. | | The NLA block would be an allocation to the ISP and not an assignment. | Therefore, if the ISP does not fully utilize it in a certain period of | time, the range will have to be returned. Also, the sub-TLA | organization should be careful about making these sub-allocations | because they will get a new sub-TLA only when 80% of their entire | sub-TLA block is assigned, not just allocated. Therefore, if they have | many sub-allocations that are not fully used, they might ask the ISPs | to give back some of the address space to use for other customers. | | Once an NLA ISP has used up its allocation, it may request an | additional block from the TLA Registry. This block can be any size, | depending on how quickly it took the ISP to use up its first | block. Any additional requests for NLA allocations should be submitted | to the Regional IR for a second opinion. | | Each NLA allocation must be registered in the Regional IR | database. All end-user assignments must also be registered in the | Regional IR database. ====BT: General comment here : I'm not sure it's efficient and at least acceptable to ask everyone willing a xLA to be registered in IR DB. A DNS a-la-mode mechanism should be far better for instance ... | The same procedures for these end-user | assignments apply for the end-user assignments made by the TLA | Registry to their customers directly. In the end, the TLA Registry is | responsible for how the address space is handled and should have an | overview of all the assignments being made by the NLA Service | Providers. TLA Registries will not be permitted to assign static IPv6 | addresses to dial-up customers. The Regional IR can at any time ask | for additional information about the allocations and assignments being | made (see /draft-ietf-dhc-dhcpv6-13.txt). | | 4.3 Reclamation Methods/Conditions | | If it turns out that routing technology at that time does not allow | additional routing entries, the allocations made up to that point will | be reviewed. Sub-TLA holders with a very low usage rate (to be defined | before publication) or sub-TLA holders that do not meet the new | criteria may have their sub-TLA space revoked. These organizations | will have to renumber and return the sub-TLA within a maximum of 3 | months. During the period that routing technology is being | investigated, the Regional IRs will continue allocating address space | even if the number of "possible" routes are reached. ====BT: if one wants to describe catastrophe scenarii, one must at least tell who has the authority to revoke a sub-TLA ... and on which criterion ? | | | 6. DNS AND REVERSE ADDRESS MAPPING | | TBD | ====BT: any new inputs there ? since it's an important part of IRs role to delegate reverse zones. Need some additional text or at least -to avoid to delay the beginning of allocation process- refer to another document IRs will discuss and issue later. And I'm done ... ! ____ EoM.

1 0

Fw: (ngtrans) Last Call "Categorizing Translators between IPv4 and IPv6"
by Thomas Trede 15 Feb '99

15 Feb '99

FYI. Regards, Thomas Trede -----Urspr|ngliche Nachricht----- Von: Bob Fink <fink(a)es.net> An: NGtrans List <ngtrans(a)sunroof.Eng.Sun.COM> Cc: Tony Hain <tonyhain(a)microsoft.com>; Harald Tveit Alvestrand <Harald.Alvestrand(a)maxware.no>; Bert Wijnen <WIJNEN(a)VNET.IBM.COM>; Kazu Yamamoto <kazu(a)iijlab.net>; sumikawa(a)ebina.hitachi.co.jp <sumikawa(a)ebina.hitachi.co.jp> Datum: Montag, 15. Februar 1999 17:54 Betreff: (ngtrans) Last Call "Categorizing Translators between IPv4 and IPv6" >NGtrans folk, > >I delayed this "last call" until after the Grenoble meeting as time was too >tight, and then was sick much of last week. > >So, a bit delayed, this is a "last call" on Categorizing Translators >between IPv4 and IPv6 for forwarding as Informational (this is definitely >informational as it is not a mechanism, rather a categorizing). > >Please reply to the authors or the list before March 1, 1999. > > >Thanks, > >Bob > >--- >Categorizing Translators between IPv4 and IPv6 > ><draft-ietf-ngtrans-translator-01.txt> > > >K. Yamamoto IIJ Research Laboratory >M. Sumikawa Hitachi, Ltd. > >January, 1999 >--- >

1 0

Fw: (IPng 7180) Last Call: Transmission of IPv6 Packets over Frame Relay Networks Specification to Proposed Standard
by Thomas Trede 12 Feb '99

12 Feb '99

FYI. Regards, Thomas Trede -----Urspr|ngliche Nachricht----- Von: The IESG (by way of Bob Hinden <hinden(a)iprg.nokia.com>) <iesg-secretary(a)ietf.org> An: ipng(a)sunroof.Eng.Sun.COM <ipng(a)sunroof.Eng.Sun.COM> Datum: Freitag, 12. Februar 1999 23:35 Betreff: (IPng 7180) Last Call: Transmission of IPv6 Packets over Frame Relay Networks Specification to Proposed Standard > >The IESG has received a request from the Internetworking Over NBMA >Working Group to consider Transmission of IPv6 Packets over Frame Relay >Networks Specification <draft-ietf-ion-ipv6-fr-02.txt> as a Proposed >Standard. > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send any comments to the >iesg(a)ietf.org or ietf(a)ietf.org mailing lists by February 26, 1999. > >Files can be obtained via >http://www.ietf.org/internet-drafts/draft-ietf-ion-ipv6-fr-02.txt > > > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo(a)sunroof.eng.sun.com >-------------------------------------------------------------------- >

1 0

Re: IPv6 Assignment and Allocation Policy Document
by Simon Nybroe 12 Feb '99

12 Feb '99

>Hello all, > >This is a draft version of the IPv6 assignment guidelines that we have >been working on with the other Regional Registries. We would like your >feedback on this at the RIPE meeting, and on this mailing list. Please find my comments below, comments are marked with "Simon: <comment> :nomis" > The >other Registries are now also discussing this with their communities. > >Please note that when refering to the global adressing authority, we >use the name IANA in this draft for now, but we will update this as >soon as the ICANN developments progress. > >Kind regards, > >Paula Caslav >RIPE NCC Regards, Simon - --------------------begin included draft---------------------------- IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT (3rd draft) TABLE OF CONTENTS Abstract 1. Scope 2. IPv6 Address Space and the Internet Registry System 2.1 The Internet Registry System Hierarchy 2.2 Goals of the Internet Registry System 3. IPv6 Technical Framework 3.1 IPv6 Addressing Hierarchy 3.2 Initial IPv6 Addressing Hierarchy 4. Addressing Policies 4.1 Allocations 4.2 Assignments 4.3 Reclamation Methods/Conditions 5. Organizations Operating in More than One Region 6. DNS and Reverse Address Mapping 7. Glossary 8. List of References 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 the Regional Internet Registries (IRs) as described in RFC 1881. The Regional IRs assign Top-Level Aggregation Identifiers (TLAs) to organizations, which in turn assign address space to other Internet Service Providers (ISPs) and end users. This document describes the policies and procedures associated with IPv6 address space management that must be followed by the organizations that hold Top-Level Aggregate IDs. Since ISPs essentially will be serving as NLA Registries for their customers, creating additional "layers" to the Registry system, it is crucial that responsibilities, procedures, and policies are well understood and consistently applied. 1. SCOPE This document first describes the global Internet Registry system for the distribution of globally unique unicast IPv6 address space, as defined in RFC 2374, and its operation, then describes the rules and guidelines governing the distribution of this address space. The rules set forth in this document are binding for all organizations that have IPv6 address space allocated and assigned via a Regional IR. This document does not describe private IPv6 address space, or anycast and multicast address space distribution. Simon: Why not write what this document does describe instead of writing wehat it does not do? This document describe aggregatable Global Unicast Address distribution. I really don't like the use of the term "private IPv6 address space", you do not find the term private address space used in any of the IPng working group documents. RFC2373 uses the term "local use addresses" to destingrise between aggregatable Global Unicast Addresses and {link/site}-local addresses. :nomis It also does not describe regional and local refinements of the global rules and guidelines. This document serves as the base set of operational guidelines in use by all Regional IRs. Additional guidelines may be imposed by a particular Regional IR as appropriate. As experience is gained in allocating IPv6 addresses, these rules and guidelines may change. The remaining sections of this document are presented as follows: Section 2, IPv6 Address Space and the Internet Registry System, explains the goals used in assigning IPv6 addresses and outlines the hierarchical structure of the responsible Internet Registry system organizations used to achieve those goals. Section 3, IPv6 Technical Framework, explains the IPv6 addressing format and outlines the difference between a TLA, NLA, and SLA block. Section 4, Addressing Policies, describes the requirements for applying for a TLA allocation and the policies that apply to such allocations. It discusses how TLA registries can allocate space to other ISPs (NLA blocks) and end-users (SLAs). Section 5, Organizations Operating in More than One Region, describes the process for requesting address space for organizations operating in more than one IR region. Section 6, DNS and Reverse Address Mapping, describes the role of the Regional IRs in providing reverse delegation and explains how the Regional IRs can manage subsidiary reverse delegation of allocated/assigned address space. Section 7, Glossary, provides a listing of terms used in this document along with their definitions. Section 8, List of References, provides a list of documents referenced in this document. 2 IPv6 ADDRESS SPACE AND THE INTERNET REGISTRY SYSTEM IPv6 unicast addresses are aggregatable with contiguous bit-wise masks similar to IPv4 addresses under CIDR. With IPv6, scarcity of address space is assumed to no longer exist for the end-user. However, routing table explosion and the efficient assignment of address space are still of great concern. Thus, aggregation and efficiency (conservation) of prefix allocations are explicit goals of the Internet registry system. 2.1 The Internet Registry System Hierarchy In order to achieve the goals of the Internet Registry system, a hierarchy was established which consists of the following levels as seen from the top down: IANA, Regional Internet Registries, and TLA Registries. 2.1.1 IANA The Internet Corporation for Assigned Names and Numbers (IANA) has 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.1.2 Regional Internet Registries Regional IRs operate in large geographical regions such as continents. Currently, three Regional IRs are established: ARIN serving North and South America, the Caribbean, and sub-Saharan Africa; RIPE NCC serving Europe, the Middle East, and parts of Asia and Africa; and APNIC serving Asia and Pacific regions. These regional IRs also serve areas beyond their core service areas to ensure that all regions around the globe are covered. Additional Regional IRs may be established in the future, but it is expected that the number of Regional IRs will remain relatively small. Service areas will be of continental dimensions. Regional IRs are established under the authority of the IANA. This requires consensus within the Internet community of the region and may require consensus of ISPs in that region. 2.1.3 TLA Registries TLA Registries are established under the authority of the Regional IR. These Registries have the same roles and responsibilities as a Regional IR within their designated service areas. 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. Moreover, these goals may occasionally be in conflict with the interests of individual end users or ISPs. In such cases, careful analysis and judgement are necessary to find an appropriate compromise. The rules and guidelines in this document are intended to help Regional IRs, ISPs, and end-users in their search for effective solutions. 2.2.1 Uniqueness Each public IPv6 address worldwide must be unique. This is an absolute requirement which guarantees that every host on the Internet can be uniquely identified. 2.2.2 Aggregation Public IPv6 addresses are distributed in a hierarchical manner, permitting the aggregation of routing information. This is necessary to ensure proper operation of Internet routing. IPv4 addresses were not as hierarchical as needed for efficient routing across the Internet. Problems arose in IPv4 network addresses with classful allocations and inefficient use of them. This led to too many routing entries appearing in the default-free core of the Internet. To overcome this problem, the number of global routes must be limited according to technical restrictions. These technical constraints will have to be reevaluated as router technology changes. Until new paramaters are defined, however, the policies described in this document will remain valid. 2.2.3 Conservation Although IPv6 network address resources appear to be endless, care must be taken to avoid repetition of the IPv4 problems and instead focus on demonstrated need. These precautions will help manage and conserve IPv6 network addresses for future use. In order to mitigate this problem in use of IPv6, conservation is one of the main goals. It should be noted however, that the IPv6 addressing architecture allows end-sites a great amount of flexibility. Eighty bits out of a total of 128 bits available in an IPv6 address are used for addressing an end-site. Address space can be conserved only by carefully evaluating the requirements from TLAs and NLAs and allocating address space on the basis of demonstrated need. Experience has shown that the growth and the consequences of growth were never anticipated with IPv4. The Regional IRs will apply the lessons from the IPv4 experience to ensure that conservative policies are implemented from the beginning. 2.2.4 Registration In response to the rapid growth of Internet activity, a public registry system was established to document address space allocation and assignment. This was necessary to ensure uniqueness of Internet addresses and to provide information for Internet trouble-shooting at all levels. As with IPv4 addresses, each of the Regional IRs maintains a public database where all IPv6 assignments and reassignments are entered so that network operators can identify other network organizations. 3. IPv6 TECHNICAL FRAMEWORK 3.1 IPv6 Addressing Hierarchy RFC 2373 specifies that aggregatable addresses are organized into a topological hierarchy which consists of a public topology, a site topology, and interface identifiers. These in turn map into the following: Simon: No, this is in RFC2374. | 3| 13 | 8 | 24 | 16 | 64 bits | +--+-----+---+--------+--------+--------------------------------+ |FP| TLA |RES| NLA | SLA | Interface ID | | | ID | | ID | ID | | +--+-----+---+--------+--------+--------------------------------+ |-- public topology---| site | Interface | | |topology| | +---------------------+--------+--------------------------------+ | | | |-------- network portion----->+<-------host portion------------| | /64 | |---------------------------------------------------------------| The site topology is represented by a /48. Each site has a potential for 65,535 subnets as specified in RFC 2374. The network portion is represented by the first 64 bits. The host portion is represented by the last 64 bits of the address. A /64 is the minimum network prefix that can be assigned within a site. Additional subnets would require additional prefixes of the same size or shorter to be assigned. Note that the boundaries are "hard" between the network and host portions and that the ID address space cannot be further sub-divided as all interface ID's are required to be in the EUI-64 format as per RFC 2373/4. The boundaries are also hard between the public topology and the site topology division at the /48. The technical motivation for this is given in RFC 2374 in order to facilitate multi-homing. In IPv6, the following prefix boundaries are suggested: number of the number of the ID left-most right-most longest length bit boundary bit boundary prefix (in bits) ************ ************ ******* ******** TLA ID 4 16 /16 13 Reserved 17 24 N/A 8 NLA ID 25 48 /48 24 SLA ID 49 64 /64 16 3.2 Initial IPv6 Addressing Hierarchy A slightly modified version of the above (a special case of TLA 0x0001) derives a sub-TLA portion from principally the reserved address space. This has been described in RFC 2450. This has the following format and prefix boundaries: | 3| 13 | 13 | 19 | 16 | 64 bits | +--+----------+---------+---------+--------+--------------------+ |FP| TLA | sub-TLA | NLA | SLA | Interface ID | | | ID | | ID | ID | | +--+----------+---------+---------+--------+--------------------+ For this TLA, this means that there are the following prefix boundaries: number of the number of the ID left-most right-most longest length bit boundary bit boundary prefix (in bits) ************ ************ ******* ******** TLA ID 4 16 /16 13 sub-TLA ID 17 29 /29 13 NLA ID 30 48 /48 19 SLA ID 49 64 /64 16 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). All router interfaces are required to have at least one link-local unicast address or site-local address. Simon: It is not obvious how a router with only a site-local address could do anything useful, how do on-link routers/hosts communicate with the router? Routers are required to have a link-local address. :nomis Site-local will be used for all point-to-point links, loopback addresses, and so forth. Simon: Why should point-to-point links and loopback interfaces use site-local? Interfaces with only Site-local addresses assigned are useless. For point-to-point RFC 2461 (Neighbor Discovery) says: point-to-point - a link that connects exactly two interfaces. a point-to-point link is assumed to have multicast capability and have a link-local address. point-to-point - Neighbor Discovery handles such links just like multicast links. (Multicast can be trivially provided on point to point links, and interfaces can be assigned link-local addresses.) Neighbor Discovery should be implemented as described in this document. Loopback interfaces should use 0:0:0:0:0:0:0:1 (RFC2373), this address does not have a binary prefix of 1111 1110 11 and are not a site-local address. :nomis As these are not required to be visible outside the site's network, they do not require public address space. Any global unicast address space assigned must not be used for the link-local or site-local purpose as there is reserved address space for these addresses. (Note that all 1's and all 0's are valid unless specifically excluded through reservation. See list of reserved addresses in RFC 2373.) 4. ADDRESSING POLICIES 4.1 Allocations Regional IRs make allocations to requesting organizations that qualify for a sub-TLA. Those organizations further allocate NLA space to ISP customers who in turn assign SLA space to end-sites. Sub-TLA holders can also assign SLA space directly to end-users, and sub-TLA and NLA holders will use SLA space to address their own networks. This hierarchical allocation structure allows aggregation of routing information. 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. Customers currently using IPv4 host addresses for dial-up should not be assigned an NLA or an SLA, or -- 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. 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: 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 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. 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. Once 30 organizations have been allocated sub-TLAs within one region, additional applications from that region must satisfy the general criteria, while applications from other regions may only have to satisfy the bootstrap criteria. This is because the first group of registries would not be able to fulfill the first criteria of being connected to three other sub-TLA networks, since there would be few sub-TLA networks at the start. After 50 sub-TLA registries are formed, there will be enough choices for new prospective sub-TLAs to find others to connect to and the bootstrapping phase can end. It has been decided to further limit the amount per region (an area covered by one Regional IR), so that one region will not have an unfair advantage over another. NOTE - Those who qualify for TLA or sub-TLA (whether during bootstrap or later) and who then fail to demonstrate ongoing utilization, will have their allocation revoked (defined further in section 4.3). 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. 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. 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. It must be stressed that it is not enough to have allocated 80% of the sub-TLA address space. The addresses must also be assigned and in use by end-sites. This means that sub-TLA holders must be careful and conservative in their allocations to their ISP customers. Address space must be allocated and assigned based on actual need. Administrative convenience or internal routing table size can not be a reason to allocate or assign additional address space. It is expected that sub-TLA holders also apply a slow-start mechanism as described in section 4.2.2 to their ISP customers. The next allocation may be another range of sub-TLA space with a shorter prefix than the previous one. If growth is no longer possible in the sub-TLA space, it is expected that a full TLA will be allocated. In order to justify a new range of sub-TLA or TLA space, the utilization of the previous allocation must be demonstrated. This is described below. 4.1.3.1 Verification of Utilization All assignments to end-sites must be registered in the database of the Regional IR in the region the sub-TLA holder operates. The TLA Registry is responsible for the utilization of the sub-TLA and the registration of the end-site assignments and ISP allocations in the database. The Regional IR will verify whether all assignments are registered in the database. In addition to the database entries, the Regional IR may ask for periodic reports describing the utilization of the addresses to be sent. It is required that the end-sites be connected and reachable. The Regional IR has the right to ping end-sites' /48s. Filtering holes should be negotiated by the Regional IR and the organization with the addresses. Therefore, it is suggested that end-sites use anycast cluster addresses on their border routers to enable this. It is expected that one /48 SLA block is enough address space per end-site. If an end-site requests an additional SLA, the sub-TLA holder must send the request to the Regional IR for a second opinion. The information provided below shows address boundaries and their corresponding amount of address space. a TLA = /16 of address space an NLA = /48 of address space an SLA = /64 of address space TLA block = 13 bits of address space NLA block = 19 bits of address space SLA block = 16 bits of address space 4.1.3.2 Renumbering Once it has been decided to allocate additional TLA space to a sub-TLA holder, the previously allocated sub-TLA must be returned to the Regional IR. The sub-TLA holder must then renumber its own network. This of course has an impact on all of its customers and customers' networks. Therefore, it is recommended that the sub-TLA holder and its ISP customers make contractual arrangements with their customers at the time of the first assignment. These arrangements should clarify that the address space will have to be returned in the event the sub-TLA holder requests a full TLA, in which case, all end-sites must be renumbered. The sub-TLA holder should inform its customers early on regarding the upcoming need to renumber. The sub-TLA will have 3 months to return the sub-TLA space after the next TLA has been allocated. Renumbering in IPv6 is considerably easier than in IPv4. Once the provider has informed its customer about the address range to be used in the future, the customer's network (end-site) will have two sets of addresses for a certain period of time. Hosts learn prefixes from router advertisements. With each prefix, there is a "valid lifetime" and a "preferred lifetime" designation. New sessions should be initiated with the preferred address, but existing ones can continue with the old (valid but not preferred) address. A mechanism called Router Renumbering (RR) allows address prefixes on routers to be configured and reconfigured almost as easily as the combination of Neighbor Discovery and Address Autoconfiguration works for hosts. It provides a means for a network manager to make updates to the prefixes used and advertised by IPv6 routers throughout a site. (M. Crawford, work in progress) Note that site-local addresses are not affected by renumbering the global unicast IPv6 addresses. 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. Only end-user organizations with a need to create subnets in their network should be assigned a full /48. Dial-up lines are considered part of the ISP's infrastructure and should be assigned from the SLA of that ISP. 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 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. The NLA block would be an allocation to the ISP and not an assignment. Therefore, if the ISP does not fully utilize it in a certain period of time, the range will have to be returned. Also, the sub-TLA organization should be careful about making these sub-allocations because they will get a new sub-TLA only when 80% of their entire sub-TLA block is assigned, not just allocated. Therefore, if they have many sub-allocations that are not fully used, they might ask the ISPs to give back some of the address space to use for other customers. Once an NLA ISP has used up its allocation, it may request an additional block from the TLA Registry. This block can be any size, depending on how quickly it took the ISP to use up its first block. Any additional requests for NLA allocations should be submitted to the Regional IR for a second opinion. Each NLA allocation must be registered in the Regional IR database. All end-user assignments must also be registered in the Regional IR database. The same procedures for these end-user assignments apply for the end-user assignments made by the TLA Registry to their customers directly. In the end, the TLA Registry is responsible for how the address space is handled and should have an overview of all the assignments being made by the NLA Service Providers. TLA Registries will not be permitted to assign static IPv6 addresses to dial-up customers. The Regional IR can at any time ask for additional information about the allocations and assignments being made (see /draft-ietf-dhc-dhcpv6-13.txt). 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. If it turns out that routing technology at that time does not allow additional routing entries, the allocations made up to that point will be reviewed. Sub-TLA holders with a very low usage rate (to be defined before publication) or sub-TLA holders that do not meet the new criteria may have their sub-TLA space revoked. These organizations will have to renumber and return the sub-TLA within a maximum of 3 months. During the period that routing technology is being investigated, the Regional IRs will continue allocating address space even if the number of "possible" routes are reached. 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. 6. DNS AND REVERSE ADDRESS MAPPING TBD 7. GLOSSARY Allocation - The provision of IP address space to ISPs that reassign their address space to customers. Assignment - The provision of IP address space to end-user organizations. End-user - An organization receiving reassignments of IPv6 addresses exclusively for use in operational networks. Interface Identifiers - A 64-bit IPv6 unicast address identifier that identifies an interface on a link. NLA ID - Next-Level Aggregation Identifier. NLA ISP - Internet Service Providers receiving IPv6 address allocations from a TLA Registry. Public Topology - The collection of providers and exchanges who provide public Internet transit service. Regional Internet Registries - Organizations operating in large geographical regions such as continents which are responsible for fair distribution of globally unique Internet address space and for documenting address space allocation and assignment. Site - A location, physical or virtual, with a network backbone connecting various network equipment and systems together. There is no limit to the physical size or scope of a site. Site Topology - A local, specific site or organization which does not provide public transit service to nodes outside the site. SLA ID - Site-Level Aggregation Identifier. Slow Start - The efficient means by which addresses are allocated to TLA Registries and to NLA ISPs. This method involves issuing small address blocks until the provider can show an immediate requirement for larger blocks. TLA ID - Top-Level Aggregation Identifier. TLA Registry - Organizations receiving TLA/sub-TLA ID from Regional IRs to reassign to customers. Unicast - An identifier for a single interface. A packet sent to a unicast address is delivered to the interface identified by that address. Note that the definition of an IPv4 host is different from an IPv6 identifier. One physical host may have many interfaces, and therefore many IPv6 identifiers. 8. LIST OF REFERENCES - --------------------end included draft---------------------------- ------- End of Forwarded Message -- Simon Nybroe System Developer, M. Sc. Telebit Communications A/S tel: +45 86 28 81 77 - 58 Fabrikvej 11 fax: +45 86 28 81 86 DK-8260 Viby J e-mail: sin(a)tbit.dk

1 0

Policy draft
by Paula Caslav 04 Feb '99

04 Feb '99

Hi all, This is just to let you know that we decided at the ipv6 working group session at RIPE 32 that people would be given 2 weeks on the mailing list to send their comments about the draft IPv6 Assignment guidelines. If you already made comments at the working group itself, we have noted them down and will consider them. A copy of the draft is in the mailing list archives: http://www.ripe.net/mail-archives/ipv6-wg/current/msg00019.html Kind regards, Paula Caslav RIPE NCC

1 0