January 2000 - ipv6-wg - mailman.ripe.net

FYI - Re: IPv6 Policy Document Review
by Mirjam Kuehne 31 Jan '00

31 Jan '00

Dear colleagues, Please see below comments the Co-Chairs of the IETF IPng Working Group and the NGTrans Working Group sent concerning the IPv6 Policy Document. Maybe this can be useful as input for the discussion at the RIPE Meeting. Kind Regards, Mirjam Kuehne RIPE NCC ---------- Forwarded message ---------- Date: Tue, 25 Jan 2000 16:26:24 -0800 To: Anne Lord <anne(a)apnic.net>, ipv6-registry(a)apnic.net From: Steve Deering <deering(a)cisco.com> Subject: Re: IPv6 Policy Document Review - Call for comments Cc: ipng(a)sunroof.eng.sun.com, ngtrans(a)sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Anne et al, Here are some comments on the Provisional IPv6 Assignment and Allocation Policy Document from the co-chairs of the IPng and NGTrans Working Groups. We very much appreciate your invitation for us to review the document. Let us first note that we are delighted that the IPv6 address allocation and assignment process has begun and seems to be functioning smoothly. The establishment of such a process was a critical requirement for production deployment of IPv6, and we would like to say thanks to you and your colleagues in the RIRs for all the work you have done to get the process up and running. Let us also point out that these comments are not based on us being customers of the allocation process -- we hope that those ISPs who have been allocated IPv6 address space under the existing process will separately comment on any difficulties they may have encountered or any suggestions for improvement they might have. Rather, these comments are based on our knowledge of the design goals and technical requirements of IPv6 addressing and our concerns about some potential negative consequences of the current allocation policy. Our primary concern with the current document is that it stresses unnecessary address conservation in a number of places, and in ways that are contrary to the intent of the protocol design. Specifically: (1) The third paragraph of section 4.3.1, regarding dial-up lines, is apparently motivated by a desire to conserve address space. Unfortunately, it is ambiguous and contradictory, and depending on how it is interpreted, it could impose an unnecessary and potentially harmful constraint on IPv6 address allocation to customer sites. o It is ambiguous because it seems to equate dial-up access with single-user access, while clearly those properties are distinct: a single dial-up line may well serve multiple users. And why is the number of users relevant to IP address allocation? A single user with multiple IP devices requires more IP addresses than multiple users sharing a single device. o It is contradictory because a dial-up customer (e.g., a residential or small-office customer) who has a need to create subnets is intended to receive a /48, according to the first paragraph of that section, and a longer prefix than /48, according to the third paragraph. o It is unnecessary because the size of the public topology part of the IPv6 address was explicitly chosen to be far more than enough to hierarchically assign a unique TLA+NLA (i.e., a unique /48) to every enterprise and every household in the world, for the foreseeable future and beyond, regardless of their type of access technology. We took into consideration the possibility that all dial-up users would one day migrate to always- on access, and we sized the public topology part of the IPv6 address accordingly. Thus there is no need to share a /48 among multiple customers, whether they use dial-up access or not. o It is potentially harmful because if ISPs interpret the policy to mean they should assign only a single /64 to each dial-up customer, given that at least some and possibly many dial-up customers will have a need to create subnets, we will almost certainly see one or both of the following harmful developments: - subdivision of the customer's 64-bit interface ID field into a subnet ID field and a smaller interface ID field, which would defeat the IPv6 goals of stateless address autoconfiguration and topologically-independent, globally-unique node identification that are achieved through the use of EUI-64-based interface IDs. - deployment of IPv6 NAT devices to allow the customer to have multiple /64 subnets behind a single /64 allocation, which would defeat the IPv6 goal of having a single, global address space for all IPv6 devices. Therefore, we recommend that the third paragraph of section 4.3.1 be deleted from the document, and that it be made clear to the RIRs and ISPs that it is perfectly legitimate and desirable that every end-user customer, including dial-up and residential customers, be assigned a static, unique /48 IPv6 address prefix. (2) The last paragraph of section 3.2, regarding address assignment to point-to-point links, also seems to be motivated by the desire to conserve address space. The recommendation against ISPs assigning global, public addresses to routers' point-to-point interfaces is both unnecessary and inappropriate. o It is unnecessary because it would have negligible impact on address space consumption if each ISP were to set aside one of its allocated NLA values (i.e., one /48), from which to assign global /64 prefixes to each of its point- to-point links. The IPv6 address space is, by design, big enough to allow all Internet device interfaces, including those of ISPs' routers, to have globally-unique, publicly visible addresses. o It is inappropriate because it is beyond the RIRs' mandate to determine that ISPs' router interfaces "do not require public address space". An ISP might well choose to assign global addresses to its point-to-point interfaces, for example to permit inter-ISP traceroute to work properly, and the RIRs have no business interfering in that operational decision. Therefore, we recommend that the last paragraph of section 3.2 be deleted. (However, the parenthetical comment at the end of that paragraph, concerning the validity of all 1s and all 0s field values, should be retained somewhere, or be promoted to being a paragraph of its own). (3) Though the document does not explicitly say so, a number of readers have interpreted the description of the slow-start mechanism in section 4.2.4 to mean that an ISP will normally start with a /35 allocation and then, as its IPv6 customer base grows, be required to come back to its RIR for each additional bit of address space, i.e., first for the enclosing /34, then for the enclosing /33, and so on, up to the sub-TLA allocation of /29. While that might be a reasonable approach if we were trying to force the ISPs to achieve maximal density of address usage, such aggressive address conservation is explicitly not a goal of the IPv6 allocation policy, and if it were in fact to be implemented that way, it would impose an unnecessary and undesirable burden on ISPs. For example, while an ISP might reasonably do flat routing for its first 6500 NLAs (80% of the NLAs in the initial /35), if it expected to enjoy any significant further growth, the next sensible step would be for it to establish an internal hierarchy for its subsequent NLA assignments. However, obtaining only a single bit of additional address space would not allow for any sort of long-term hierarchy to be established. Instead, we suggest that a reasonable expectation for any ISP that appears at all likely to grow into a full sub-TLA, and eventually a TLA, should be that they go from a /35 initial allocation to a /29 full sub-TLA allocation in one step. We do not believe this would be inconsistent with the purposes of slow start for IPv6 address allocation, which we understand to be: o prevention of flagrant wastage or stockpiling of IPv6 address space, o arranging that ISPs with significantly fewer customers have longer prefixes than others, and o forcing occasions for ISPs to receive guidance from their RIRs on acceptable address usage practices. Now perhaps our suggested approach is in fact what you have in mind -- we note that the document gives considerable (and sensible) flexibility for the RIRs to exercise their best judgement regarding how much additional space to grant. If that is the intent (and we hope it is), we would prefer that that be made much more explicit in the policy document, so that any legitimate ISP with serious plans for a large IPv6 deployment can know that it will not be subjected to many small "baby-step" allocations that would complicate its planning and possibly force it to impose otherwise unnecessary renumbering events on its earlier customers. We also suggest that you consider changing the criteria so that existing top-level IPv4 ISPs who already have a large installed infrastructure and IPv4 customer base, and who presumably require less guidance on prudent address allocation practices, be able to obtain a full /29 sub-TLA to start, rather than being required to slow start from a /35. Yes, that creates the risk of such an ISP obtaining a lot of IPv6 space and then never using it, but (a) the requirement that ISPs report their NLA allocations in a public database provides a separate mechanism for monitoring usage, and that could be used as input to a reclamation decision, should that become necessary, and (b) if existing large IPv4 ISPs fail to eventually acquire a significant number of IPv6 customers, that will almost certainly indicate an overall lack of demand for IPv6 service, in which case the issue of IPv6 address stockpiling will have become moot. (4) The very few words in the document regarding allocation of TLAs ("If no further growth is possible within that sub-TLA range, the Regional IR may allocate a full TLA.", in section 4.2.5.1), when read in the context of the other, unnecessary address conservation requirements above, give the impression that the RIRs will be very reluctant to allocate actual TLAs. In particular: o Why does it say "...*may* allocate a full TLA", rather than "...*will* allocate a full TLA" (or "...*will normally* allocate a full TLA", to allow for exceptions)? o What is the criterion for determining that "no further growth is possible" with a sub-TLA? The only reference to determining when a piece of address space is "full" is in the section on sub-TLA allocation, section 4.2.5, in which there is an "at least 80% used" requirement. That is a reasonable threshold for determining when a flat address space, or a single field of a hierarchical address (such as the 13-bit NLA field in an initial /35 allocation, handled as a flat space), is near capacity, but it is unreasonable and unachievable in practice in a hierarchically-structured address space (such as the 19-bit NLA space in a full sub-TLA). We recommend that the criteria for obtaining a TLA be made more explicit, and we suggest that you consider a metric such as the "H ratio" defined in RFC 1715, which takes into account the significantly reduced density achievable in a hierarchical address space. For example, specifying an H ratio of 0.26, which that RFC describes as "optimistic" based on past experience with other, similar address spaces, would yield a recommendation that an ISP be granted a TLA at the point that it has allocated about 87,000 NLA values to end-user customers and/or downstream ISPs. Perhaps you could round that number down to 75,000 or up to 100,000 to come up with a simple rule for when an ISP could expect to acquire a TLA. Our remaining comments, both substantive and editorial, are given below, following quotations of the relevant text: > ABSTRACT > > This document describes the registry system for distributing > globally unique unicast IPv6 address space. Append to the end of that sentence: "under format prefix 001, as defined in RFC 2374", to make it clear that this policy does not necessarily apply to any future global unicast space that might be created under other format prefixes. > IPv6 address > space is distributed in a hierarchical manner (as is IPv4 > address space), managed by the IANA and further delegated by > the Regional Internet Registries (Regional IRs) as described > in RFC 1881. In the case of IPv6, the Regional IRs allocate > Top-Level Aggregation Identifiers (TLAs) to organizations, > which, as TLA Registries, in turn allocate or assign address > space to other Internet Service Providers (ISPs) and end > users. ISPs then serve as Next Level Aggregation (NLA) > Registries for their customers. The use of the terms "TLA Registry" and "NLA Registry" above, and throughout the document, are inconsistent and often counter-intuitive. For example, the above paragraph uses: - "TLA Registry" to refer to an organization to whom a TLA value has been assigned, but - "NLA Registry" to refer to an organization that assigns NLA values to others. We suggest that you consistently use: - TLA Registry only to refer to those organization that assign TLA and sub-TLA values, i.e., IANA, the RIRs, and subordinate registries (like JPNIC), if any. - NLA Registry only to refer to those organizations that assign NLA values, i.e., ISPs and Exchanges, and their subordinate ISPs, if any. - SLA Registry only to refer to those organizations that assign SLA values, i.e., end-user customers (and ISPs, for their own infrastructure). > 2 IPv6 ADDRESS SPACE AND THE INTERNET REGISTRY SYSTEM > > IPv6 unicast addresses are aggregatable with contiguous > bit-wise masks used to define routable prefixes,... The reference to "contiguous bit-wise masks" is obsolete and inapplicable to IPv6. In IPv6, prefixes are always specified by length (number of bits), never by mask. >...using a method similar to that used for IPv4 addresses under CIDR. The method of aggregation is not just "similar" to that used for IPv4 under CIDR, it is the same. > Internet. The Internet Registry system exists to ensure that > IPv6 address space is managed in a globally consistent, > fair, and responsible manner that minimizes wastage, and > maximizes aggregation within the routing structure. The goal is not to *minimize* wastage, nor is it to *maximize* aggregation. Rather, the goal is to *limit* wastage, and to achieve *adequate* aggregation to meet the demands of stable, global routing. > 2.1 The Internet Registry System Hierarchy > > The hierarchical Internet Registry system exists to enable > the goals described in this document to be met. In the case > of IPv6, this hierarchy consists of the following levels, as > seen from the top down: IANA, Regional Internet Registries, > TLA, NLA Registries, and end-sites. Following our suggestion above for consistent usage of terms, remove "TLA," from the last sentence above. (IANA and the RIRs are the TLA registries.) And if you disagree with that, then at least add the word "Registries" after "TLA", for grammatical consistency. > 2.1.3 TLA Registries > > TLA Registries are established under the authority of the > appropriate Regional IR to enable "custodianship" of a TLA > or sub-TLA block of IPv6 addresses. Following our terminology suggestion, this section would refer to NLA registries having custodianship over blocks of NLAs (that fall under specific TLA or sub-TLA values assigned by the RIRs), and the subsequent (currently empty) section 2.1.4 would be deleted. We would also like to see this same language about custodianship applied to the RIRs themselves, so that it is made clear the RIRs are also custodians, not owners, of the address space (blocks of TLAs and sub-TLAs) allocated to them by IANA. > 2.1.5 End-sites > > [to be written] We assume the points to be made here are that: - end-site customers are not granted "ownership" of the address space they are assigned. - end-site customers are responsible for assigning SLA IDs (subnet numbers) and interface IDs to their own links and nodes. > 2.2.1 Uniqueness > > Each IPv6 unicast address must be globally unique. After "unicast address", add the phrase "under format prefix 001", because the statement above is not true of *all* IPv6 unicast addresses (particularly site-local, link-local, and loopback unicast addresses). > This is an absolute requirement for guaranteeing that every host >on the Internet can be uniquely identified. Change "host" to "node". (In IPv6, the term "host" does not include routers, whereas "node" includes all IPv6 devices, both hosts and routers.) > 2.2.2 Aggregation > > IPv6 addresses must be distributed in a hierarchical manner, In several places in the document, the term "distribution" is used, rather than "allocation" or "assignment". If "distribution" has a distinct meaning, or is meant to refer to the union of allocation and assignment, please include it in the glossary at the end, with an explanation of its meaning. > permitting the aggregation of routing information and > limiting the number of routing entries advertised into the > Internet. This is necessary to ensure proper operation of > Internet routing and to maximize the routing system's > ability to meet the demands of both likely and unforeseeable > future increases in both size and topological complexity. In > IPv6, aggregation of external routes is the primary goal. In that last sentence, change "the primary goal" to "a primary goal". IPv6 has other primary goals, such as increasing the available address space. > This goal is motivated by the problems which arose in IPv4 > network addressing. IPv4 address allocations have not been > sufficiently hierarchical to ensure efficient routing across > the Internet. Inefficient use of classful allocations led to > an excess of routing entries appearing in the default-free > routing table. Change "Inefficient use of classful allocations" to "Allocations of non-hierarchical (classful) prefixes". It was not the inefficiency of classful allocation that led to large routing tables, but rather their lack of sufficient hierarchy. > Furthermore, increased complexity of network > topologies led to IPv4 prefixes being announced many times > via different routes. The presence of this sentence, in the context of the paragraph in which it appears, would seem to imply that a goal is to reduce the complexity of network topologies, which is certainly not a goal of IPv6 addressing or the allocation policy. > 2.2.4 Registration > > Every assignment and allocation of IPv6 Internet address > space must be registered in a publicly accessible database. > This is necessary to ensure uniqueness and to provide > information for Internet trouble shooting at all levels. Add a hyphen to "trouble shooting". > 3.2 Initial IPv6 Addressing Hierarchy > > ... > > All router interfaces are required to have at least one > link-local unicast address or site-local address. As we explained in our earlier comments, we recommend that the paragraph containing this sentence be deleted. However, in case you decline to accept that recommendation, you should know that the above sentence is not exactly right. All router (and host) interfaces are required to have at least one link-local unicast address. *In addition*, they may be assigned site-local and/or global unicast addresses. > 4.1 IPv6 Addresses not to be considered property > > All allocations and assignments of IPv6 address space are > made on the basis that the holder of the address space is > not to be considered the "owner" of the address space, and > that all such allocations and assignments always remain > subject to the current policies and guidelines described in > this document. Change "all such allocations and assignments" to "all allocations and assignments of addresses under format prefix 001". Perhaps change "in this document" to "in the most recent version of this document". > Holders of address space may potentially be > required, at some time in the future, to return their > address space and renumber their networks in accordance with > the consensus of the Internet community in ensuring that the > goals of aggregation and efficiency continue to be met. Perhaps change "that the goals of aggregation and efficiency be met" to "that the technically and operationally necessary levels of aggregation and efficiency be met". > 4.2.1 General Criteria for Initial Sub-TLA Allocation > > Subject to sections 4.2.2, and 4.2.3, Regional IRs will only > make an initial allocation of sub-TLA address space to > organizations that meet criterion (a) AND at least one part > of criterion (b), as follows: > > a. The requesting organization's IPv6 network must > have exterior routing protocol peering > relationships with the IPv6 networks of at least > three other organizations that have a sub-TLA > allocated to them. In criterion (a), change "sub-TLA" to "sub-TLA or TLA". > > AND either > > b(i). The requesting organization must have > reassigned IPv6 addresses received from its > upstream provider or providers to 40 SLA customer > sites with routed networks connected by permanent > or semi-permanent links. What's a semi-permanent link? > > OR > > b(ii). The requesting organization must > demonstrate a clear intent to provide IPv6 service > within 12 months after receiving allocated address > space. This must be substantiated by such > documents as an engineering plan or deployment > plan. So, what sort of organization would satisfy (a) AND b(ii)? Any ISP who could satisfy (a) would presumably already be providing IPv6 service, not just planning to do it. > > 4.2.2 Criteria for sub-TLA Allocations in Transitional > "Bootstrap" Phase > > ... > > a. The requesting organization's network must have > exterior routing protocol peering relationships > with at least three other public Autonomous > Systems in the default-free zone. Make it clearer that you are talking about *IPv4* peering arrangements, in this case. > > AND > > b. The requesting organization must show that it > plans to provide production IPv6 service within 12 > months after receiving allocated address space. > This must be substantiated by such documents as an > engineering plan or a deployment plan. > > AND either > > c. The requesting organization must be an IPv4 > transit provider and must show that it already has > issued IPv4 address space to 40 customer sites > that can meet the criteria for a /48 IPv6 > assignment. In this case, the organization must > have an up-to-date routing policy registered in > one of the databases of the Internet Routing > Registry, which the Regional IR may verify by > checking the routing table information on one of > the public looking glass sites). > > OR > > d. The requesting organization must demonstrate > that it has experience with IPv6 through active > participation in the 6bone project for at least > six months, during which time it operated a > pseudo-TLA (pTLA) for at least three months. The > Regional IRs may require documentation of > acceptable 6Bone routing policies and practice > from the requesting organization. We understood that the 6bone pre-qualification process was to be independent of the other bootstrap criteria, i.e. sufficient on it own. It seems unlikely that many ISPs meeting criteria (a) would need to rely on criterion (d), rather than (c). The 6bone pre-qual was supposed to allow bootstrapping of IPv6 providers who are *not* established IPv4 providers, i.e., do not satisfy (a). > 4.2.3.2 Multihomed Sites > > [to be written] What needs to be said here is that end-user sites connected to multiple ISPs are expected to receive an NLA assignment (i.e., a /48) from each of those ISPs, and therefore, each of such an end-user's nodes may have multiple, globally-unique addresses. However, it should also be explicitly said that nothing in this policy is intended to prevent or discourage a multi-homed end-user site from negotiating with any number of ISPs for the service of advertising and routing a /48 prefix obtained from another ISP. > 4.2.4 Size for Initial Allocation: "Slow-Start" Mechanism > > Regional IRs will adopt a "slow start" mechanism when making > initial allocations of sub-TLA space to eligible > organizations. By this mechanism, the initial allocation > will allow 13 bits worth of NLA IDs to be used by the > organization unless the requesting organization submits > documentation to the Regional IR to justify an exception > based on topological grounds. 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, an organization > may receive 8,192 SLAs (a /48 each). In that last sentence, change "8,192 SLAs" to "8,192 NLAs". > 4.2.6 Registering and Verifying Usage > > Each TLA Registry is responsible for the usage of the > sub-TLA address space it receives... Change "sub-TLA" to "sub-TLA or TLA". (And we would prefer that these be called NLA registries, because they register NLAs, not TLAs, as discussed above.) > Registered end-sites must be connected and reachable. This is inconsistent with our recommendation that dial-up customers be able to obtain a /48, just like any other customers, so if our recommendation is accepted, this section will have to be reconsidered. > ...Filtering holes should be negotiated > by the Regional IR and the organization holding the > addresses in question. Explain what is meant by a "filtering hole". >...If an end-site requests an additional SLA, the TLA Registry must >send the request to the Regional IR for a second opinion. That should be "If an end-site requests an additional *NLA*, the *NLA* Registry must...". > 4.2.7 Renumbering > > It is possible that circumstances could arise whereby > sub-TLA address space becomes scarce. This could occur, for > example, due to inefficient use of assigned address space, > or to an increase in the number of organizations holding > both TLA and sub-TLA space. Change "inefficient" to "very inefficient". > Regional IRs requiring a TLA Registry to renumber will allow > that Registry at least 12 months to return the sub-TLA > space. [Note that the granted renumbering time may depend on > the prefix length returned. The draft document > http://search.ietf.org/internet-drafts/draft-ietf-ipngwg-router-renum-08.txt > describes the issues involved in and methods used for > renumbering IPv6 networks.] Just for your information, the IPng working group has an effort underway to produce a new document describing the renumbering process for a site, which will be more appropriate to cite here, once it has been published. > 4.4 Reclamation Methods/Conditions > > ... > > However, if the limit is reached and routing technology at > that time is not able to support additional routing entries, > Regional IRs will review all allocations made up to that > point. In the course of this review, the Regional IRs may > seek consensus of the Internet registry and engineering > communities to set minimum acceptable usage rates or new > criteria determining eligibility to hold sub-TLA space. > Dependent upon such a consensus, the Regional IRs may revoke > the sub-TLA allocations of any Registry not complying with > those rates or criteria. We wonder if you want to say "sub-TLA or TLA" in the two places above where you refer only to "sub-TLA". > 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. Change "are reached" to "is reached". > 6.1 Allocation and Reverse Address Mapping > > ... > > For each IPv6 address block allocated by a Regional IR to a > member or customer, the Regional IR must set up NS records > in the appropriate sub-domain within the "ip6.int" domain. Just for your information, it is very likely that the "ip6.int" domain will be moved out of ".int" and into ".arpa". We expect this to be decided fairly soon, probably by Adelaide. > 7. GLOSSARY > > Allocation - The provision of IP address space to ISPs that > reassign their address space to customers. Change "ISPs" to "ISPs or exchanges". > End-user - An organization receiving reassignments of IPv6 > addresses exclusively for use in operational networks. Why "reassignments" instead of "assignments"? What is the point of using the phrase "operational networks"? Is this in contrast to experimental networks or non-operational networks? If this is actually intended to mean "not for offering public transit service to other organizations" or something like that, please say that. > Public Topology - The collection of providers and exchanges > who provide public Internet transit service. Change "who" to "that". > 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. Insert the word "geographic" before "scope"? > 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. IPv4 and IPv6 are *not* different in the way that this confusing text seems to suggest. In both protocols, addresses identify interfaces, not hosts, and in both kinds of addresses, the lowest-order field identifies an interface within a net or subnet (even though it is less precisely called the "host field" in IPv4). Finally, in the Call for Comments for the policy document, you said: >* Definition of 'transit provider' > >A definition for the above term was not included in the current document. >Comments and suggestions for an appropriate definition are encouraged. We suggest that you *not* try to define that term, knowing what a slippery slope that is. We believe the criteria for allocation specified by the policy document (however it turns out after this review cycle) is, or ought to be, sufficient to indicate who is eligible to be assigned a sub-TLA or TLA value and who is not. Thanks again for requesting our feedback, and we apologize for the lateness and lengthiness of our response. We would be happy to set up a meeting to discuss any of these issues with you in person, if that would be helpful. Steve Deering & Bob Hinden, Co-Chairs, IPng Working Group Alain Durand, Bob Fink & Tony Hain, Co-Chairs, NGTrans Working Group

1 0

Re: minutes
by Wilfried Woeber, UniVie/ACOnet 24 Jan '00

24 Jan '00

According to Hamid Alipour: >The thing that I would like you consider is that we have enough address >space availble trough IPv6. I have two remarks here: >1- why should IPv6 address space alocation follow the same procedure as > IPv4 Well, it's not the same procedure ;-) There is a different (if administratively similar!) set of guidelines and procedures in place for obtaining an sTLA to enable an Internet Service Provider to design and build an IPv6-based service. It has taken of lot of effort and discussion to propose, refine, review and finally agree, on the current set of guidelines. There is a lot of documents out there (RFCs, drafts, allocation guidelines) documenting the current lines of thinking. Of course, as the Internet evolves, there's going to be a constant need for review, refinement and - probably - changes. > while we had address space limitation there and we do not have > address space limitation in IPv6 then we must ease address space > allocation in IPv6. I think you should consider the fact that an IP-Address in *itself* (be that v4 or v6) is only of limited use. In most cases, it only becomes a valuable resource as soon as a set of addresses (a "prefix") gets configured in a real network and announced on the routing layer. > currently I have to run a procedure for each end > user who whishes to get address space Having gone through the procedure with RIPE to acquire an sTLA, I'm not able to remember that requirement?! > and I have ensure RIPE that the > address space is really needed.end users do not have this permistion to > reserve address space. Let's assume for a minute that there is no feedback loop in place which requires "you", or anyone else, to document your need - how much of the "vast" IPv6 address space would you want to reserve for your <"insert your organisation here">? One quarter? Only 20%? What would be a "fair" percentage for your <"organisation">? > that's ok while we are dealing with IPv4 , but > what about IPv6? all of us know that designing a network with larger > address space is easier and we can consider further developments too, > address space is not fragmented and the network can run with higher > performance. routers will have smaller routing tables and we can save > RAM and CPU resources.due to limited address space in IPv4 it was not > possible. optimizations was based on minimizing required address space > , with IPv6 we can optimize the network design based on less resource > usage and higher performance. > >2- make address space allocation in IPv6 Localized. > we can allocate some prefixes for countries , say put aside 2 bytes of > address space. no? put aside 3 bytes, more or less put some space for > countries. in 2 byte version we would have 65536 country codes while > we do not have such amount of countries.RIRs can assign some prefix > to companies which act international.let say a company whishes to act > nation wide after a while he decides to have an office in an other country. > he must register his office in that country and get some permission for > his activities there, let they get an address space assignment from LIR in > that country besides other permissions they have to get.they can do this > or negotiate with a IR to get a multi-national or international prefix. > how much effort is needed for this? and compare it with this procedure > that I have to negotiate and get approval from RIPE whenever an ISP > in my country needs address space. I think we have been through that one more than once, and I do not see any reason why the answer for IPv6 could be fundamentally different from the answer for IPv4. Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Vienna University : Fax: +43 1 4277 - 9 140 Universitaetsstrasse 7 : RIPE-DB Handle: WW144 A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 __________________________________________________________________________

1 0

Re: minutes
by Simon Leinen 24 Jan '00

24 Jan '00

>>>>> "dk" == David Kessens <david(a)qip.Qwest.net> writes: > F. IPv6 forum creation (David Kessens) > there has been a mailinglist created ~2-3 months ago with subject > deployment of IPv6. It contains technical questions & answers > There's a website too, http://www.ipv6.org/ The IPv6 Forum Web site is http://www.ipv6forum.com/ . IPv6.org is an effort to disseminate information about IPv6. It has neither formal membership nor fees. To my knowledge it isn't related to the IPv6 Forum (other that some people may be active in both). > It is meant to be a formal organisation to promote IPv6 > It currently has 55 members, the membership fee is ~$2500 a year) > The IPv6 forum sponsors meetings to spread information about IPv6 > It has two main goals: inform and help in deployment by collecting > useful information > next meeting will be in October near Paris named "Global IPv6 summit" > on the 8/9 dec there will be a meeting in Berlin to be help in German > language, but translations will be offered too > a meeting in Japan is planned, but there's no date yet -- Simon Leinen simon(a)babar.switch.ch SWITCH http://www.switch.ch/misc/leinen/ Who is General Failure & why's he reading my disk?

1 0

minutes
by David Kessens 22 Jan '00

22 Jan '00

Hi, Please see below for the minutes of our last session. I would like to thank Petra Zeidler for taking and preparing the minutes. I would like to declare them the final version if I don't receive any major comments until January 31. Thanks, David K. PS I will not be very responsive for the next weeks due to a vacation --- Slides available from http://whois.6bone.net/~david/presentations/ Minutes of the IPv6 WG meeting at RIPE 34 Agenda: A. Administrative Stuff Scribe is Petra Zeidler Agenda got reshuffled, beside that no changes B. Status of 6BONE (David Kessens) see slides for the contents of the presentation no Questions C. Experience from the RIPE NCC with IPv6 allocations (Mirjam Kuehne) http://www.ripe.net/meetings/ripe/ripe-34/pres/ipv6-alloc-experience/index.… Questions: - Does RIPE NCC look at IPv4 allocations when deciding about IPv6 alloc.? - no, one can start out with IPv6 address space - How long does getting an allocation take? - about as long as a large IPv4 assignement now, but in the beginning it took longer due to necessary shakedown of procedures - What about the "exchange points distribute address space" point? - Neither the exchanges nor the registries are particularily keen to see that, maybe clear that up in the documentation - is the problem of how to handle different address spaces at the client site, their upstream and the exchange point worked out? - no. Input from the Exchange people needed, the IX wg is in parallel to this meeting - how does one find IPv6 database objects in the database? - by using whois, the object types are inet6num and ipv6site D. Experience from APNIC with IPv6 allocations (Fabrina Hossain) http://www.ripe.net/meetings/ripe/ripe-34/pres/apnic-ipv6/index.html Questions: - what is a NIR, and what's the IPv6 problem with them? - a national internet registry, an intermediary between RIR and LIR; assigning a block of STLAs is not planned in the current regulations, but would be sensible. This point needs to be cleared up yet. - are there political problems with or for NIRs? - none up to date - what type of IPv6 usage happens in the APNIC region? - tunneled over IPv4 E. Experience from customers of the RIPE NCC with IPv6 allocations (audience) Stephen Burley, UUnet UK: requested at 3 registries due to their international character, got /35. Issues are Aggregation and looking at a whole continent /29 is reserved for them so they can expand contiguously UUnet is still staring up IPv6 operations, they have renumbered from their 6bone addresses and had questions from customers about IPv6, but did no assignments yet. general point: what about company mergers and splits? - renumbering is easy in theory Wilfried Woeber for Vienna Uni, RIPE IPv6 allocation #6: IPv6 requires quite different architecture considerations regarding wether to assign a /64 or a /48 actually using IPv6 found surprising, non-obvious traps (eg DNS) working with RIPE to get the allocation was nice planning for IPv6 is hard to do due to lack of experience on all sides the role of IXes is unclear. Are they to move from being a switch to being a router? How does one build infrastructure for a routed IX? What about the IPv6 multihoming issue? For an IXes own routing infrastructure there are no address issues F. IPv6 forum creation (David Kessens) there has been a mailinglist created ~2-3 months ago with subject deployment of IPv6. It contains technical questions & answers There's a website too, http://www.ipv6.org/ It is meant to be a formal organisation to promote IPv6 It currently has 55 members, the membership fee is ~$2500 a year) The IPv6 forum sponsors meetings to spread information about IPv6 It has two main goals: inform and help in deployment by collecting useful information next meeting will be in October near Paris named "Global IPv6 summit" on the 8/9 dec there will be a meeting in Berlin to be help in German language, but translations will be offered too a meeting in Japan is planned, but there's no date yet H. IPv6 test project done by TF-TANT (Simon Nybroe, http://www.tbit.dk/quantum/slides/ripe34qtpv6/index.htm) Questions/comments: DNS still needs IPv4 connectivity to be able to do its "tree walk" There are more applications needed that work with IPv6 A IPv6 routing registry needs to be considered G. European developments/initiatives regarding IPv6 - there's a project to link 6TAP and AMS-IX using a native IPv6 link AMS-IX has IPv6 on the Ethernet and at 6TAP it's available over the peering router. Question: is it an experiment or are there plans to offer "ordinary" transit? - no transit yet, currently it will run in a ~3month test period X. Any Other Business - there's IPv6 in the RIPE terminal room, with www.ipv6.surfnet.nl as tunnel router - IPv6 policies are to be dicussed in the LIR WG, only implementation matters at IPv6 WG, as IPv6 is now in assignment production. Anyone may take part in the LIR WG (only the LIRs really ought to :-) --

3 2

filtering against IPv& in IPv4
by Thomas Trede 21 Jan '00

21 Jan '00

Hello, FYI: The mentioned problem in the following message of the IPNG-Mailinglist might be interesting and an issue for the IPv6-WG at RIPE... I will not forward the whole thread of the IPNG-Mailing to this list; it has been suggested to take the issue to the IPv6-Forum. I suggest we should spend some time at the upcoming RIPE-Meeting for this issue (even, if we only check whether it is an issue for the IPv6-activities in RIPE-community). Regards, Thomas Date: Wed, 19 Jan 2000 20:04:56 +0900 (JST) Message-Id: <20000119.200456.23033996.kazu(a)iijlab.net> To: ngtrans(a)sunroof.eng.sun.com, ipng(a)sunroof.eng.sun.com Subject: filtering against IPv6 in IPv4 From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <kazu(a)iijlab.net> X-Mailer: Mew version 1.95b17 on Emacs 20.5 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng(a)sunroof.eng.sun.com Precedence: bulk Hi all, Some ISPs configure IP filters NOT to forward "IPv6 in IPv4" packets. This is obstacles for transition from IPv4 to IPv6. Are there any activities in IETF to recommend ISPs not to filter "IPv6 in IPv4" packets? (e.g. IAB recommendation) --Kazu -------------------------------------------------------------------- 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: LIR 34.11 Discuss moving IPv6 policy matters to lir-wg
by Wilfried Woeber, UniVie/ACOnet 12 Jan '00

12 Jan '00

Hi Hans Petter! >I would like to ask the lir-wg and the ipv6-wg to give its opinions on this >matter, and if possible to conclude. > >Conclusions could be: >1) Keep it as is >2) Move all policy discussions to lir-wg >3) Keep it as is for next n meetings My feeling is that the time has come to move IPv6 addressing policy and address distribution items to the LIR-WG, thus I'm proposing "option 2". I think it was indeed appropriate to take care of IPv6-specific issues in the framework of the IPv6-WG, in particular as long as we are/were living in a test-bed kind of environment. (Btw, 6Bone issues, as well as technical issues should still remain with the IPv6 WG) However, as LIRs now can request IPv6 address space *for production use* in much the same way as IPv4 addresses, there's not too much "special handling" requirements left, I suppose. Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Vienna University : Fax: +43 1 4277 - 9 140 Universitaetsstrasse 7 : RIPE-DB Handle: WW144 A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 __________________________________________________________________________

1 0

LIR 34.11 Discuss moving IPv6 policy matters to lir-wg
by hph＠infostream.no 11 Jan '00

11 Jan '00

At the two last lir-wg meetings ar RIPE meetings the question of wether IPv6 policy matters should be discussed in a separate working group or in the lir-wg where all other policy matters are discussed has been brough up. Two meetings ago I rejected this suggestions for two reasons: - I did'n feel qualified to chair the rather detailed technical discussions going on related to the v6 policies - The lir-wg agenda was filled with other matters The reasons for suggesting moving the discussions to the policy forum is to keep policy discussions in one place, thus making schedulig simpler for policy interested meeting attendants. I would like to ask the lir-wg and the ipv6-wg to give its opinions on this matter, and if possible to conclude. Conclusions could be: 1) Keep it as is 2) Move all policy discussions to lir-wg 3) Keep it as is for next n meetings Yours, the lir-wg chair.

1 0

Fw: I-D ACTION:draft-ietf-ipngwg-mld-mib-02.txt
by Thomas Trede 11 Jan '00

11 Jan '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: <Internet-Drafts(a)ietf.org> To: <IETF-Announce: ;> Cc: <ipng(a)sunroof.eng.sun.com> Sent: Tuesday, January 11, 2000 12:39 PM Subject: I-D ACTION:draft-ietf-ipngwg-mld-mib-02.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IPNG Working Group of the IETF. > > Title : IP Version 6 Management Information Base for The > Multicast Listener Discovery Protocol > Author(s) : B. Haberman, R. Worzella > Filename : draft-ietf-ipngwg-mld-mib-02.txt > Pages : 12 > Date : 10-Jan-00 > > This document defines an experimental portion of the Management > Information Base (MIB) for use with network management protocols in > Internet Protocol Version 6 internets. Specifically, this document > is the MIB module which defines managed objects for implementations > of the Multicast Listener Discovery Protocol [MLD]. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-mld-mib-02.txt > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-ipngwg-mld-mib-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv(a)ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ipngwg-mld-mib-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >

1 0

Fw: I-D ACTION:draft-ietf-ipngwg-iana-tla-02.txt
by Thomas Trede 10 Jan '00

10 Jan '00

FYI. Regards, Thomas Trede ----- Original Message ----- From: <Internet-Drafts(a)ietf.org> To: <IETF-Announce: ;> Cc: <ipng(a)sunroof.eng.sun.com> Sent: Thursday, December 30, 1999 12:49 PM Subject: I-D ACTION:draft-ietf-ipngwg-iana-tla-02.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IPNG Working Group of the IETF. > > Title : Initial IPv6 Sub-TLA ID Assignments > Author(s) : B. Hinden, S. Deering, B. Fink, T. Hain > Filename : draft-ietf-ipngwg-iana-tla-02.txt > Pages : 6 > Date : 29-Dec-99 > > This document defines initial assignments of IPv6 Sub-TLA Aggregation > Identifiers (Sub-TLA ID) to the Address Registries and continued > management of the IP6.INT domain. It is intended as technical input > to the IANA from the IETF IP Next Generation (IPNG) and Next > Generation Transition (NGTRANS) working groups, as an input to the > process of developing guidelines for the allocation of IPv6 > addresses. > The IAB and IESG have authorized the Internet Assigned Numbers > Authority (IANA) as the appropriate entity to have the responsibility > for the management of the IPv6 address space as defined in [ALLOC]. > The proposed initial assignment described in the document is > consistent with: > - RFC 2373,'IP Version 6 Addressing Architecture' [ARCH] > - RFC 2374 'An Aggregatable Global Unicast Address Format' [AGGR] > - RFC 2450 'Proposed TLA and NLA Assignment Rules' [TLA-RULES]. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-iana-tla-02.txt > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-ipngwg-iana-tla-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv(a)ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ipngwg-iana-tla-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >

1 0