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.