April 2005 - address-policy-wg

IPv6 Policy Clarification - Initial allocation criteria "c)"
by Laura Cobley 19 Jul '05

19 Jul '05

Dear Colleagues, As explained in the email sent on Mon, 14 Jun 2004: http://www.ripe.net/ripe/mail-archives/address-policy-wg/2004/msg00240.html This is the second mail request for clarification of the IPv6 Address Allocation and Assignment Policy. Below is an excerpt from the IPv6 Address Allocation and Assignment Policy: 5.1.1. Initial allocation criteria "c)" "To qualify for an initial allocation of IPv6 address space, an organisation must [...] plan to provide IPv6 connectivity to organisations to which it will assign /48s by advertising that connectivity through its single aggregated address allocation" LIRs who operate closed/private networks appear not to qualify because the address space in these networks will not be advertised. Was this the community's intention? Best Regards, Laura Cobley Registration Services RIPE NCC

9 12

Policy proposal: #gamma IPv6 Initial Allocation Criteria
by Hans Petter Holen 11 Jul '05

11 Jul '05

Dear all, Please find enclosed a policy proposal from Andy Furnell. My proposal is to enter this proposal into the Discussion Phase with a time line of 4 weeks ending on May 9the allowing the discusssion to continue over the RIPE meeting. 1. Number #gamma 2. Policy Proposal Name: IPv6 Initial Allocation Criteria 3. Author a. name: Andy Furnell b. e-mail: andy(a)linx.net c. telephone: +44 (0) 20 7645 3519 d. organisation: London Internet Exchange (LINX) 4. Proposal Version: 1 5. Submission Date: 4/4-2005 6. Suggested WG for discussion and publication: Address Policy WG 7. Proposal type: modify a. new, modify, or delete 8. Policy term: renewable a. temporary, permanent, or renewable. 9. Summary of proposal: The proposal is to change the IPv6 Initial Allocation criteria outlined in the "IPv6 Address Allocation and Assignment Policy" (http://www.ripe.net/ripe/docs/ipv6policy.html). The proposed change is to remove "have a plan for making at least 200 /48 assignments to other organisations within two years" and to remove the reference to "/48s" as the assignment size. 10. Policy text a. Current (if modify): 5.1.1. Initial allocation criteria To qualify for an initial allocation of IPv6 address space, an organisation must: a) be an LIR; b) not be an End Site; c) plan to provide IPv6 connectivity to organisations to which it will assign /48s by advertising that connectivity through its single aggregated address allocation; and d) have a plan for making at least 200 /48 assignments to other organisations within two years. b. New: 5.1.1. Initial allocation criteria To qualify for an initial allocation of IPv6 address space, an organisation must: a) be an LIR; b) not be an End Site; c) plan to provide IPv6 connectivity to organisations and customers to which it will make assignments by advertising that connectivity through its single aggregated address allocation. 11. Rationale: a. Arguments supporting the proposal Many LIRs' networks do not have 200 customers to make assignments to but still maintain autonomous network and addressing policies. These require address space that is both aggregatable and independent from that of their peers. In addition, a /48 assignment is not always appropriate; ISPs might have different plans for the size of the assignments they will make and the policy should not stand as an obstacle for them. Such a change in the policy will also make IPv6 allocations more accessible and could result in the acceleration of IPv6 development. b. Arguments opposing the proposal With such a change in the policy, every LIR operating an autonomous network would be able to receive an IPv6 allocation. The worst case scenario would be a number of allocations equal to the number of LIRs in the RIPE region. ---------------------------------------------------------------------------

23 115

Policy proposal: #alpha: TLD Anycast Allocation Policy
by Hans Petter Holen 11 Jul '05

11 Jul '05

Dear all, Please find enclosed a policy proposal. As per my previous message I will "beta-test" the new PDP on this proposal. The current proposal has been discussed previously and has now been re-formulated after that discussion. My proposal is to enter this proposal into the Discussion Phase with a time line of 2 weeks ending on April 4th. Best Regards, Hans Petter 1.Number (assigned by the RIPE NCC) alpha 2.Policy Proposal Name: TLD Anycast Allocation Policy 3.Author a.name: Andreas Baess b.e-mail: baess(a)denic.de c.telephone: +49 69 27235 0 d.organisation: DENIC e.G. 4.Proposal Version: 1 5.Submission Date: 6.Suggested WG for discussion and publication: Address Policy Working Group 7.Proposal type: new 8.Policy term: renewable 9.Summary of proposal To enable ccTLD and gTLD nameserver operators to provide their DNS service using shared unicast technology, RIPE NCC is able to assign one IPv4 and IPv6 prefix per operator that is not likely to be filtered by common practise for anycast-operation of their DNS services. 10. Policy text a.Current: N/A b.New: "If the nameserverset of a TLD without anycasting technology applied would not pass the IANA Administrative Procedure for Nameserver Delegation and Glue Data (http://www.iana.org/procedures/delegation-data.html) may receive dedicated network prefixes for the sole purpose of anycasting name servers, as described in RFC 3258. These shall be: one /24 IPv4 prefix and/or one /32 IPv6 prefix per operator. The prefixes shall be tagged as 'ASSIGNED ANYCAST' in the RIPE database and MUST be returned to the RIPE NCC if not in use for anycast DNS any longer." 11. Rationale: PROS A. Acceptance of DNS for special treatment Studies like http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-eof-rickard.… shows clearly that ccTLD and gTLD nameservers are a critical network infrastructure that justify special policies to guarantee operability of Internet applications. B. Policy Harmonization Three out of four RIRs (APNIC, ARIN and LACNIC) have policies allowing assignments to network critical infrastructure. All three policies classify TLDs as critical infrastructure. Extracts from these policies can be found in Appendices I through III. C. Scalability of DNS To serve the projected increase of DNS queries and to ensure sufficient network topological coverage and diversity TLD managers need to deploy an increasing number of nameservers. D. Resilience Internet has become part of the daily life and their availabilty is as important as the availability of all public services. Anycasting is currently the state-of-the-art solution to lower the impact of DDoS attacks. E. IPv6 Support As the world starts exploiting IPv6, the DNS infrastructure should support IPv6 natively. However it is not yet possible to reduce the number of nameservers in the IPv4 cloud. CONS F. Waste of Address Space Accepting a number of IPv4/24 and IPv6/32 allocations for critical network infrastructures does not align with the traditional address conservation efforts. With anycasting it is very likely that only a few addresses from the entire assignment would be used. 2. Root DNS are special, others are not RIPE document 233 dated from 24th May 2002 says: "Although it is undesirable to give special status to any IP (IPv4 or IPv6) address block, it was agreed by the community that the particular need defined in this document is the only justifiable exception to that general principle." 3. Assigning an own network prefix is just a workaround to ensure global reachability which could also be achieved by adjusting currently deployed route filter practices. Appendix I APNIC Policy (Following section is taken from http://www.apnic.net/docs/policy/add-manage-policy.html - 11.3) 11.3 Critical infrastructure The following critical infrastructure networks, if operating in the Asia Pacific region, are eligible to receive a portable assignment: * root domain name system (DNS) server; * global top level domain (gTLD) nameservers; * country code TLD (ccTLDs) nameservers; * IANA; * Regional Internet Registry (RIRs); and * National Internet Registry (NIRs). Assignments to critical infrastructure are available only to the actual operators of the network infrastructure performing such functions. Registrar organisations which do not actually host the network housing the registry infrastructure, will not be eligible for an assignment under this policy. The minimum assignment made under these terms is /24. Appendix II ARIN Policy (Following section taken from http://ww2.arin.net/policy/index.html#four4) 4.4. Micro-allocation - ARIN will make micro-allocations to critical infrastructure providers of the Internet, including public exchange points, core DNS service providers (e.g. ICANN-sanctioned root, gTLD, and ccTLD operators) as well as the RIRs and IANA. These allocations will be no longer than a /24 using IPv4 or a /48 using IPv6. Multiple allocations may be granted in certain situations. Appendix III LACNIC (Following section is taken from http://lacnic.net/policy-en.pdf) 3.3.3 Micro Allocations Micro allocation is the name given to those allocations that imply blocks smaller than /20 but always larger than or equal to /24. LACNIC can grant this type of allocation in case of projects and infrastructure for networks that are key or critical for the region, such as IXPs (Internet Exchange Points), NAPs (Network Access Points), RIRs, ccTLDs, among others. In the case of IXPs or NAPs, in order to be able to apply for this type of allocation, organizations shall meet the following requirements: 1. Duly document the following aspects: 1. 1Prove by means of their bylaws their capacity of IXP or NAP. The organization shall have at least three members and an open policy in relation to the association of new members. 1. 2Submit a company structure organizational diagram. 1. 3Document the numbering plan to be implemented. 2. Provide a usage plan for the following three and six months. The rest of the applications shall be studied based on the analysis of the documentation justifying the critical and/or key aspects of the project. Organizations receiving micro allocations are not authorized to suballocate these addresses.

8 12

Policy Proposal: #epsilon Policy text modifications to take account of,ICANN recognition of AfriNIC as a fully functioning RIR.
by Hans Petter Holen 01 Jul '05

01 Jul '05

Dear All, With the formal recognition of AfriNIC as a fully functioning RIR there is no need to still have special policy provisions for the AfriNIC region in the RIPE NCC region. http://www.nro.net/archive/news/20050411-afrinic-final-recognition.html As I do not expect much discussion on this Item I propose to end the discussion period by May 1st. 1.Number (assigned by the RIPE NCC) #epsilon 2.Policy Proposal Name: Policy text modifications to take account of ICANN recognition of AfriNIC as a fully functioning RIR. 3.Author a.name: Adiel Akplogan b.e-mail: adiel(a)afrinic.net c.telephone:+230 259 2409 d.organisation: AfriNIC 4.Proposal Version: 1.0 5.Submission Date: 6.Suggested WG for discussion and publication Address Policy Working Group 7.Proposal type: modify a.new, modify, or delete. 8.Policy term: renewable a.temporary, permanent, or renewable. 9.Summary of proposal To modify the policy document text to reflect full recognition of AfriNIC as a functioning RIR. 10. Policy text a.Current (if modify): "1.0 Introduction The RIPE NCC is an independent association and serves as one of four Regional Internet Registries (RIRs). Its service region incorporates Europe, the Middle East, Central Asia and African countries located north of the equator." b.New: "1.0 Introduction The RIPE NCC is an independent association and serves as one of /five/ Regional Internet Registries (RIRs). Its service region incorporates Europe, the Middle East, and Central Asia." a.Current (if modify): "5.1 First Allocation The RIPE NCC's minimum allocation size is /21. The minimum allocation size for countries in Africa is /22." b.New: "5.1 First Allocation The RIPE NCC's minimum allocation size is /21." 11. Rationale: a.Arguments supporting the proposal With the recognition of AfriNIC as a fully functioning and independant RIR there is a need to modify this document reflecting this change. b.Arguments opposing the proposal None.

1 1

HD ratio policy proposal
by BIDRON Alain ROSI/DAS 01 Jul '05

01 Jul '05

Dear Colleagues Referring to the minutes of the last RIPE Policy Working Group meeting and to the action list as updated during that meeting, I have to make a formal proposal on use of HD ratio for IPV4. Here is this policy proposal. In order to be consistent with the PDP Draft proposal coming from Rob Blokzijl I have used the template provided in the new PDP proposal. Best regards. Alain _________________________________________________________ 1. Policy Proposal Name: IPv4-HD-Ratio 2. Author a. name: Alain Bidron b. e-mail: alain.bidron(a)francetelecom.com c. telephone: +33 1 44 44 27 75 d. organisation: France Telecom 3. Proposal Version: V0 4. Submission Date: 02/02/2005 5. Suggested WG for discussion and publication: Address Policy WG 6. Proposal type: modify 7. Policy term: permanent 8. Summary of proposal: Internet address space is managed hierarchically: - IANA allocates space to Regional Internet Registries (RIRs). - RIRs allocate space to Local Internet Registries (LIRs). - LIRs assign space to End Users. At each level, some address space may be reserved for future expansion and/or efficient aggregation. As more hierarchical levels are introduced, the overall efficiency of the address space usage decreases. The HD ratio (Host-Density ratio) is a way to measure address space usage [RFC 3194]. The HD ratio value can relate to a percentage of usage, which decreases as the amount of address space grows. This allows for the decreasing efficiency that occurs with more hierarchical levels. The HD ratio is currently used to measure IPv6 address space usage [ipv6-address-policy]. The IPv6 Address Allocation and Assignment Policy considers a block of IPv6 address space to be ‘used’ when its HD ratio reaches 0.80. This is a manageable figure ("values of 80% or less correspond to comfortable trade-offs between pain and efficiency" [RFC 3194]). This document proposes using the HD ratio to measure IPv4 usage. The proposed value of the HD ratio for IPv4 is 0.96. 9. Policy text: a. Current: "An LIR may receive an additional allocation when about eighty percent (80%) of all the address space currently allocated to it is used in valid assignments or sub-allocations." b. New: "An LIR may receive an additional allocation when its total allocated address space usage meets the HD-Ratio value of 0.96." 10. Rationale: a. Background The current document, “IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region” [ipv4-address-policy], considers a block of IPv4 addresses to be ‘used’ when 80% of the addresses within the block have been sub-allocated or assigned. This is applied to all address blocks, regardless of size. Current policies assume a hierarchical system of address space delegation. However, they do not make any allowance for hierarchical management within allocated address space. For LIRs in particular, a hierarchical approach is often required for assignment of address space to service elements such as customer networks, individual Points of Presence (PoPs), regionalised topologies, and even distinct ISP products. Small network infrastructures may require simple hierarchies, but large infrastructures can require several levels of address space subdivision. These levels of hierarchy are not recognised by the current policy framework and are highly restricted by the "80% rule". As a result, managing large blocks is often difficult, requiring large internal routing tables and/or frequent renumbering of internal address blocks. One of the goals of the RIR system is to avoid unnecessary depletion of IPv4 address space. However, address management policies must also be practical in terms of how much management overhead they cause. When large amounts of address space are involved, the "80% rule" can result in more work for an LIR. Basing usage on the HD ratio should lead to equal levels of management overhead across the board, rather than penalising the holders of large address blocks. b.Impact To see a rough estimation of the immediate impact of this proposal, an HD Ratio value of 0.96 was applied to the average amount of address space held by an LIR in the RIPE NCC Service Region. This showed that on average, LIRs would qualify for an additional allocation block when they have assigned or sub-allocated about 59% of their allocated address space. c.Arguments supporting the proposal. This proposal fairly takes into account addressing hierarchies used in large and extra-large registries and introduces a useful level of flexibility for those registries The local Internet registries using the 80% criteria may continue to do so and will not be impacted by the new policy. The RIPE NCC will provide support to minimise complicated calculations or administrative burden to LIRs. d. Arguments opposing the proposal. This proposal will have some limited impact on IPV4 address consumption. Appendix A. The HD ratio The HD ratio is calculated as follows [RFC 3194]: HD = log(U)/log(S) Where: S is the size of the address block concerned, and U is the number of addresses used. Note: The current IPv4 policy considers addresses to be ‘used’ once they are assigned or sub-allocated by the LIR. Appendix B. Selection of HD ratio value We should decide an appropriate HD ratio value on a rational basis. To do this, we make certain assumptions about the number of "hidden" hierarchical levels involved in managing address blocks of various sizes. If we assume there is 80% usage at each level, we can easily calculate the overall usage. The following table proposes a set of hierarchical levels which we can reasonably expect within different amounts of address space. If a usage of 80% is achieved at each hierarchical level, then the overall usage will be (0.80 to the power of "n"). It is then possible to calculate HD ratio values from this value. Size range Level Utilisation HD ratio (prefix) (n) (0.80**n) (calculated) /24 to /20 1 80% .960 to .973 /20 to /16 1.5 72% .961 to .970 /16 to /12 2 64% .960 to .968 /12 to /8 2.5 57.2% .960 to .966 /8 to /4 3 51.20% .960 to .966 The levels of hierarchy listed above are based on assumptions about the likely size and structure of LIRs holding address blocks of these sizes. A reasonable HD ratio value may be 0.96 (a round figure which occurs within most of these ranges) from the table above. The following table gives the usage requirements for IPv4 address blocks from /24 to /8 for this value. IPv4 Addresses Addresses Util% prefix total used 24 256 205 80.11% 23 512 399 77.92% 22 1024 776 75.79% 21 2048 1510 73.71% 20 4096 2937 71.70% 19 8192 5713 69.74% 18 16384 11113 67.83% 17 32768 21619 65.98% 16 65536 42055 64.17% 15 131072 81811 62.42% 14 262144 159147 60.71% 13 524288 309590 59.05% 12 1048576 602249 57.43% 11 2097152 1171560 55.86% 10 4194304 2279048 54.34% 9 8388608 4433455 52.85% 8 16777216 8624444 51.41% Note: This table provides values for CIDR blocks, but the same calculations can be made for non-CIDR blocks. As an example, an LIR holding a total amount of address space equal to a /16 would be able to receive more address space when they had sub-allocated or assigned 64.17% of that space; while an LIR holding a /9 would be able to receive more space when they had sub-allocated or assigned 52.85% of their address space. Appendix C. References [RFC 3194] "The Host-Density ratio for address assignment efficiency: An update on the H ratio", A. Durand, C.Huitema, November 2001. [ipv6-address-policy] RIPE NCC document: "IPv6 Address Allocation and Assignment Policy" http://www.ripe.net/ripe/docs/ipv6policy.html [ipv4-address-policy] RIPE NCC document: "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" http://www.ripe.net/ripe/docs/ipv4-policies.html

2 2

Policy Proposal: #Zeta Adding Regional Boundaries to policy documents
by Hans Petter Holen 01 Jul '05

01 Jul '05

Dear Address Policy WG, This policy proposal is nothing more than an editorial change - but we still feel it is fair to run it trough the PDP. As I do not expect much discussion I propose the discussion phase to end by May 1st. While I am voicing this proposal the suggestion actualy comes from our excellent RIPE NCC staff. Thanks leo for pointing this out. Best Regards Hans Petter Holen Address Policy 1. Number Zeta 2. Policy Proposal Name: Adding Regional Boundaries to policy documents 3. Author a. name: Hans Petter Holen b. e-mail: hpholen(a)tiscali.no c. telephone: +47 45066054 d. organisation: Visma IT AS 4. Proposal Version: 5. Submission Date: 16/4-2005 6. Suggested WG for discussion and publication Address policy type 7. Proposal type: a. modify 8. Policy term: a. permanent 9. Summary of proposal Our AS assignment policy has the following statement in it: "The RIPE NCC assigns AS Numbers for Autonomous Systems located in the RIPE NCC service region" Neither the IPv4 nor the IPv6 policy documents have such a clear statement in them. It might be a good idea to add a similar statement to those documents when they are updated. 10. Policy text a. Current (if modify): b. New: 11. Rationale: a. Arguments supporting the proposal Clearification of the scope of the documents b. Arguments opposing the proposal n/a

1 2

New Draft Document: RIPE Whois Registration in 2005: What should be in Whois and Why?
by leo vegoda 02 May '05

02 May '05

Dear Colleagues, At RIPE 49, Eva Ericsson Rabete (TeliaSonera) made a presentation to the Address Policy Working Group in which she asked some questions about the state of the RIPE Whois Database. Following the discussion at the meeting, Eva was asked to take the discussion onto this list (Action Point 49.4). A draft document discussing the uses of the RIPE Whois Database, and detailing questions to consider, has been published in the "Latest Draft Documents" section of the RIPE Document Store. The purpose of this draft document is to encourage discussion about what elements should be in the Whois Database and why they should be there. This draft document is available at: http://www.ripe.net/ripe/draft-documents/whois2005.html Regards, -- leo vegoda Registration Services Manager RIPE NCC

2 1

Summary TLD Anycast Allocation Policy
by Patrick Arkley 28 Apr '05

28 Apr '05

Hi WG. We at MCI are requesting a /24 PI-range to use for an anycast service (DNS) but the request has been rejected in accordance to the current assignment policy. We need PI-space belonging to a separate AS so we can't use existing MCI space. The need for this range is if course routing reasons which is prohibited by the policy. I've been reading Andreas Baess e-mail on this issue and I hope this issue will be addressed on the RIPE 50 and rule in favour of changing the policy. I don't judge on the routability aspects but more on the fact that we need a change in the policy to accomodate a setup for anycast services. Myself I can't attend the WG meeting on Thursday 5/5 due to other engagements so this e-mail is my support for the proposal. Best regards Patrick Arkley Supervisor IP/DNS-team SKSC/SKRC MCI - Powered by UUNET Armégatan 38 S-171 04 Solna, Sweden Web: www.se.mci.com <http://www.se.mci.com/> Phone direct: +46 (0)8 5661 7075 Fax: +46 (0)8 5661 7236 Mobile: +46 (0)733 11 20 75 VNET: 915-7075 E-mail: patrick.arkley(a)se.mci.com <mailto:patrick.arkley@se.mci.com>

1 0

Policy proposal: #beta: IPv4-HD-Ratio
by Guido Roeskens 28 Apr '05

28 Apr '05

Hello, we from Bluewin fully support the proposal Policy proposal: #beta: IPv4-HD-Ratio LIR: ch.bluewindow Vote: YES Comment: ISP's providing access services to many customers face several problems - Usage in different PoP's changes; at one time you have many customers in one PoP, at another time in others. You need to supply enough adresses to all PoPs even though they aren't needed all the time. - Assymetric usage of pools and redundancy To provide redundancy you overallocate some IP addresses to be able to handle the failure of single devices The pool usage on the devices and device groups are not balanced - RFC 3194 is as true for IPv4 as for IPv6 - consistency between IPv4 and IPv6 policies Kind regards, Guido Roeskens Swisscom Fixnet AG Bluewin

6 8

Mega-allocations
by Iljitsch van Beijnum 25 Apr '05

25 Apr '05

Hi, It seems there is a new trend in RIR-land: mega-allocations. This year APNIC, ARIN and the RIPE NCC have made the following allocations: # whois -h whois 126.0.0.0 whois.apnic.net inetnum: 126.0.0.0 - 126.255.255.255 netname: BBTEC descr: Japan Nation-wide Network of Softbank BB Corp. country: JP status: ALLOCATED PORTABLE # whois -h whois.arin.net 73.0.0.0 NetRange: 73.0.0.0 - 73.191.255.255 CIDR: 73.0.0.0/9, 73.128.0.0/10 NetName: CABLE-1 NetType: Direct Allocation # whois -h whois.ripe.net 86.192.0.0 inetnum: 86.192.0.0 - 86.255.255.255 netname: FR-TELECOM-20050302 descr: France Telecom status: ALLOCATED PA That's a total of 33 million IP addresses in 3 allocations (and as many months). The total population for these three countries is 127 + 293 + 60 = 480 million, so that's an IP address for nearly 7% of those country's inhabitants. If I were a conspiracy theorist I would think that IPv6 proponents are trying to burn up the remaining IPv4 space as fast as they can so we'll all be running IPv6 at the end of the decade. If that's the case: good job! :-) Seriously: what's going on here?

3 3

Re: [address-policy-wg] Policy proposal: #gamma IPv6 InitialAllocation Criteria
by Cameron Gray (RIPE Address Policy WG) 24 Apr '05

24 Apr '05

Collective, This originated from a thread I started on ipv6-ops... As the archives seem to bear out shim6/mhap/multi6 or whatever the new *thing* will be is not ready. We (uk.netegral) have a /32 already (2001:4bf0::) however many of the recipients of sub-allocations will be using the resources in conjunction with their other providers. My, now somewhat aging, e-mail to lir-help asked what happens to LIRs that cannot get/justify/plan for 200 /48s their reply was simple: get it off another LIR. This now leads into a problem with routing policies: if /32s are only to be allowed in the backbone, how doe these sub-lir allocations get announced. My idea is to simply allow internetwork /48 to be announced to the backbone, or aggregates thereof (i.e. to adjacent /48s for the same ASN as a /47 and so on...). I know the first response will be that this will grow the routing table infinitely and I agree, however with 629-ish from my view there isn't much of a table to speak of. Are there any considerations I'm missing, why can't IPv6 prefixes be treated in the same way as IPv4? I'm not advocating announcing every /64 from here to timbuktu but otherwise I can't see anything to allow the "little guys" from actually benefitting therefore deploying IPv6. One of our customers has a /48 allocation and is now refusing to issue to customers as he can't announce this to the second upstream (they refuse to pass it on as it isn't a /32), they have also hit peers that refused the prefix as it hit their "this route is internal" prefix filter. I assume the end goal here is to encourage the uptake of v6 not hinder it... Can this disparity in policies not be addressed using current protocols and technologies simply by increasing the allowable boundary for the backbone? This has a neat side effect of not having to alter the issuing policy for /32s :) .

6 10

Re: [address-policy-wg] Policy proposal: #gamma IPv6 InitialAllocation Criteria
by Gert Doering 23 Apr '05

23 Apr '05

Hi, On Thu, Apr 21, 2005 at 11:33:46PM +0100, Cameron Gray wrote: > First a little background, recently in the London Webhosting world, a > big drive has occured to become multi-homed and isolated from any one > providers screwups, downtime, incompetence, etc. The problem with this > is that very few of them have any of the necessary skills to liase with > the NCC to do requests or even understand why its necessary [tangent: > the number of times I see "because ARIN gave us a /24 per box" as a > justification from the same group is silly]. I firmly believe in > leaving the important things to those who know what they are doing, > present company (I hope ;)). > > The small providers can have either IPv6 PI (currently disallowed and > frowned upon) or become a LIR and wreak havoc on the hostmasters. This is something that I really don't understand. The hostmasters are here to help educate LIRs that don't know what they are doing - and it will be for the better of everyone. If they are so clueless, then they shouldn't be allowed to do BGP, and possible "wreak havoc" on everybody else's routing tables. > I'm against dishing out /32s to Joe Blogs because I believe the subnet > recommendation/guidelines as published are a good balance. In theory a > /48 for any customer site should be several orders of magnitude to many > for most customers in two years. > > But the ongoing problem is that of what should be allowed into the > public v6 Internet. Indeed. The idea behind the proposed change is (sort of) "those who can be bothered to understand the system and become a LIR are allowed". What you are asking for ("those people are clueless but so important that they need to be visible in everyones routing table") is a different proposal. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster(a)Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234

4 3

Re: [address-policy-wg] Policy proposal: #gamma IPv6 InitialAllocation Criteria
by Cameron Gray (RIPE Address Policy WG) 22 Apr '05

22 Apr '05

Gert Doering wrote: > Hi, > > On Thu, Apr 21, 2005 at 11:27:32AM +0100, Cameron Gray (RIPE Address Policy WG) wrote: > >>Or are we lobbying for the criteria as a LIR to be relaxed...? > > > Actually there are no big hurdles for becoming a LIR. Prove your existance, > fill in paperwork, pay startup fee, done. I think my phrasing was misunderstood. What I meant was the 200 rule, not to become a de facto LIR. > This alone doesn't give you an IPv6 allocation yet, though - the biggest > hurdle there is that you have to claim a plan to supply 200 customers with > IPv6. As it is only a *plan*, it's possible to achieve for most LIRs > that actually provide addresses to customers. Well not if we're sticking to the letter of the policy, and especially as in perticular *our* customers will require multi-homing, therefore a /32 to themselves... (this is a YMMV comment, but asbestos underwear donned anyway). > OTOH, there's an ongoing policy change proposal to drop the 200-customer > rule. Please read up the specifics of the proposal in the archive, and > voice your opinion... I disagree with the policy change, I think that the policy change should be on allowed prefixed into the backbone. First a little background, recently in the London Webhosting world, a big drive has occured to become multi-homed and isolated from any one providers screwups, downtime, incompetence, etc. The problem with this is that very few of them have any of the necessary skills to liase with the NCC to do requests or even understand why its necessary [tangent: the number of times I see "because ARIN gave us a /24 per box" as a justification from the same group is silly]. I firmly believe in leaving the important things to those who know what they are doing, present company (I hope ;)). The small providers can have either IPv6 PI (currently disallowed and frowned upon) or become a LIR and wreak havoc on the hostmasters. I'm against dishing out /32s to Joe Blogs because I believe the subnet recommendation/guidelines as published are a good balance. In theory a /48 for any customer site should be several orders of magnitude to many for most customers in two years. But the ongoing problem is that of what should be allowed into the public v6 Internet. As much as I would like to attend RIPE 50 I have other commitments as well as government to select half-way through so I am unable to. Could we continue the discussion here or is this very much an in person topic? -- Best regards, Cameron Gray Director, Netegral Limited www.netegral.co.uk | cgray(a)netegral.co.uk 0871 277 NTGL (6845)

1 0

New IPv6 Address Block Allocated to the RIPE NCC
by Filiz Yilmaz 20 Apr '05

20 Apr '05

Dear Colleagues, The RIPE NCC received the IPv6 address range 2A00::/21 from the IANA in April 2005. You may wish to adjust any filters you have in place accordingly. More information on the IP space administered by the RIPE NCC can be found on our web site at: <https://www.ripe.net/ripe/docs/smallest-alloc-sizes.html> Regards, -- Filiz Yilmaz RIPE NCC

1 0

New Document available: RIPE-344
by RIPE NCC Document Announcement Service 19 Apr '05

19 Apr '05

New RIPE Document Announcement -------------------------------------- A new document is available from the RIPE document store. Ref: ripe-344 Title: Internet Assigned Numbers Authority (IANA) Policies for Allocation of IPv4 Blocks to Regional Internet Registries Author: APNIC, ARIN, LACNIC, RIPE NCC Date: 19 April 2005 Format: PDF=74310 TXT=4719 Short content description ------------------------- On 8 April 2005, during the ICANN Board meeting in Mar del Plata, Argentina, the ICANN Board formally approved the adoption of a global policy on IANA Allocation of IPv4 address space to the Regional Internet Registries developed by the Address Supporting Organisation (ASO) and the Number Resource Organisation (NRO). The ICANN Board resolution is available from the ICANN website at: http://www.icann.org/minutes/resolutions-08apr05.htm The document "Internet Assigned Numbers Authority (IANA) Policies for Allocation of IPv4 Blocks to Regional Internet Registries" describes the policy governing the allocation of IPv4 address space from the IANA to the Regional Internet Registries (RIRs). Accessing the RIPE document store --------------------------------- You can access this new RIPE document in HTML format via our website at the following URL: http://www.ripe.net/ripe/docs/iana-rir-allocation-policies.html The RIPE Document Store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-344.pdf PDF version ftp://ftp.ripe.net/ripe/docs/ripe-344.txt plain text version

1 0

NRO Response to WGIG Paper on IP Numbers
by Axel Pawlik 19 Apr '05

19 Apr '05

Dear Colleagues, The Number Resource Organization (NRO), on behalf of the Regional Internet Registries including the RIPE NCC, published a document consisting of comments to the Working Group on Internet Governance (WGIG) on the draft working paper on IP Numbers (April 2005). The NRO document submitted to the WGIG can be found on the NRO website at: http://www.nro.net/documents/nro23.html The original draft WGIG paper can be found at: http://wgig.org/docs/WGIGPaperCluster1IPnumbers-Final.pdf Regards, Axel Pawlik Managing Director RIPE NCC

1 0

Policy proposal for changes in RIPE policy Do cuments.
by Erics 19 Apr '05

19 Apr '05

... that meets the point. I agree and support this proposal. - Eric

1 0

Policy proposal for changes in RIPE policy Documents.
by Adiel AKPLOGAN 18 Apr '05

18 Apr '05

Hello, This is a policy proposal to modify RIPE NCC policy documents to take in account the full recognition of AfriNIC. === 1.Number (assigned by the RIPE NCC) 2.Policy Proposal Name: Policy text modifications to take account of ICANN recognition of AfriNIC as a fully functioning RIR. 3.Author a.name: Adiel Akplogan b.e-mail: adiel(a)afrinic.net c.telephone:+230 259 2409 d.organisation: AfriNIC 4.Proposal Version: 1.0 5.Submission Date: 6.Suggested WG for discussion and publication Address Policy Working Group 7.Proposal type: modify a.new, modify, or delete. 8.Policy term: renewable a.temporary, permanent, or renewable. 9.Summary of proposal To modify the policy document text to reflect full recognition of AfriNIC as a functioning RIR. 10. Policy text a.Current (if modify): "1.0 Introduction The RIPE NCC is an independent association and serves as one of four Regional Internet Registries (RIRs). Its service region incorporates Europe, the Middle East, Central Asia and African countries located north of the equator." b.New: "1.0 Introduction The RIPE NCC is an independent association and serves as one of /five/ Regional Internet Registries (RIRs). Its service region incorporates Europe, the Middle East, and Central Asia." a.Current (if modify): "5.1 First Allocation The RIPE NCC's minimum allocation size is /21. The minimum allocation size for countries in Africa is /22." b.New: "5.1 First Allocation The RIPE NCC's minimum allocation size is /21." 11. Rationale: a.Arguments supporting the proposal With the recognition of AfriNIC as a fully functioning and independant RIR there is a need to modify this document reflecting this change. b.Arguments opposing the proposal None. == Kind regards.

3 2

Policy proposal: #gamma IPv6 Initial Allocation Criteria
by Mike Hughes 14 Apr '05

14 Apr '05

The 200 /48s rule does fail the job, in the present environment. We should abolish it for the arbitrary, plucked from the air number, that it is. Why? Because there are networks which are not end sites, who do make assignments to customers (just not 200 of them right now - or within 2 years), which cannot wait for the i*tf to get off the pot with whatever multi6/shim6 thing they are doing, which cannot wait the N years it will take for vendors to implement whatever comes out of the i*tf. They need fully-functioning IPv6 connectivity which is not dependant on (the address space, services, operational stability, etc., of) an upstream carrier, right now, for whom large scale renumbering whenever they have to change upstream is not a realistic option. This can be achieved through an IPv6 address allocation which is functionally similar to the IPv4 PA allocation they are currently entitled to. Currently, the RIRs issue these in /32 chunks. Sure, routing tables will grow. A bit. That's because the Internet is (still) growing. IPv6 is part of that growth, yet I don't really think we've had a substantial sunrise period yet. The sun seems to be very low on the horizon from where I'm sat. I don't think we're talking about floodgates here. The majority seem to think there are enough safeguards to prevent "casual" users from successfully receiving an IPv6 allocation. I agree. Right now, the only strong objections I'm seeing appear to be somewhat Canutist, despite being otherwise well-informed. In case my opinion isn't clear, I support the proposal as it stands. If there is a genuine and well-founded concern about pulling the "200 number" without some other form of safeguard, maybe we go with the proposal as it stands, but add a commitment (by the Chairs? group as a whole? NCC?) to table a review of the situation once the i*tf do come up with something, and there is vendor support for it? Would that help to allay fears of wet feet? Regards, Mike -- Mike Hughes Chief Technical Officer London Internet Exchange mike(a)linx.net http://www.linx.net/ "Only one thing in life is certain: init is Process #1"

10 12

RE: [address-policy-wg] Policies interact
by Wilfried Woeber, UniVie/ACOnet 08 Apr '05

08 Apr '05

>>> For a routing decision you don't need 32 bits for an IPv4 prefix, >>> and you do not need 128 bits for an IPv6 prefix. >> Exact. >> A international routing decision can be limited to the first 64 Bits. >> The remaining 64 Bits are some sort of ARP-replacement. > >nope. folk are using /126s internally, and have igp or ibgp carrying >those prefixes. of course, they also have the classic loopbacks for >bgp, which can be /128s. real hardware vendors know this and don't >make the same mistakes as were made in the old a/b/c days. > >randy I thought we were talking about the routing table size and memory requirements for the DFZ. Are you implying that we will see those more specific /126s or /128s in the global routing table? Wilfried.

1 0

ICANN Calls for Comments on the Proposed Review Procedure for ASO Policy Proposal
by Axel Pawlik 08 Apr '05

08 Apr '05

Dear Colleagues, The RIPE NCC invites all members of the community to comment on ICANN's proposed Review Procedure for Address Supporting Organization (ASO) policy proposals. On April 6, 2005, ICANN called for public comments on this proposed Review Procedure. Further information and a link for submitting comments are available on the ICANN website at: http://www.icann.org/announcements/announcement-06apr05.htm Regards, Axel Pawlik Managing Director RIPE NCC

1 0

RE: [address-policy-wg] Policies interact
by Wilfried Woeber, UniVie/ACOnet 07 Apr '05

07 Apr '05

Sidetracking #2: >Savings in IPv4 space, do not carry over into IPv6. That is why >we lose these savings. But the size of the routing table increases >by 4 times therefore requiring 4 times as much RAM and 4 times as >much time to send/receive full routes. If this is the case we are looking at a poor implementation (memory-consumption-wise), imho. For a routing decision you don't need 32 bits for an IPv4 prefix, and you do not need 128 bits for an IPv6 prefix. My wild guess would be that the ratio is rather on the order of 1:1.5 than 1:4. [ Anyone having statistics about the average length of an IPv4 prefix? Probably in the range of (20..)21..22(..23) ] Wilfried.

4 4

Re: how 200 /48's fails the job
by Valtteri Vuorikoski 07 Apr '05

07 Apr '05

Pekka Savola <pekkas(a)netcore.fi> writes: > On Tue, 5 Apr 2005 Michael.Dillon(a)radianz.com wrote: > ... > > The 200 new customer limit was meant to be a measure of largeness and > > seriousness. I think that in today's world, that measure fails to do > > the job. > > Could you clarify, why do you think "200 customers" fails as a meter for largeness ? > > There are some odder cases like transit only ISPs (which technically could only have very few direct > organizational customers -- let's assume that those would get the IP space using some other provisions or > as a matter of interpretation), but apart from that, why exactly is requiring 200 customers unreasonable? I think Mr. Bartels already made some of these points, but I'll still add my two (euro)cents to this discussion. I would think that the concept of lumping all "customers" into a single class is flawed. I work for a managed hosting provider, and we currently have POPs in three countries with multiple transit providers and peerings. Obviously we have our own IPv4 allocation. However, our focus is on medium-size and large customers, which are quite unlike residential end-user customers where 200 would be next to nothing. I doubt we'll have 200 such customers (without creative accounting, that is) in a while yet, but we are still doing active business. The current rule effectively prevents us from deploying IPv6 to our customers. In the long run, I believe that as long as the current policy prevents hosting companies who serve content to end-users from deploying IPv6, it removes motivation from the end-user ISPs (who would have no problem getting the allocation) to actually deploy it to their users. While routing table growth is a concern, not having (v6) routing table growth is in my opinion an even larger concern. Therefore my view is that the arbitrary fixed criterion of having to be "large" (for whatever value of large) for a v6 allocation should be dispensed with. -- Valtteri Vuorikoski <vuori(a)magenta.net> MagentaSites Oy

5 5

Fw: how 200 /48's fails the job [Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria]
by Michael.Dillon＠radianz.com 07 Apr '05

07 Apr '05

> There is one point I don't understand in the whole discussion: > If every RIPE member get's an IPv6 prefix, which is true for IPv4, > we are talking about plus 10K prefixes in the table. If RIPE really and truly believes that IPv6 will become the future core protocol of the public Internet, then RIPE should allocate an IPv6 /32 to every RIPE member who has PI addresses. But that is seperate from the question of new entrants who may, or may not, be following an ISP business model. > Do people *really* think this approach works and do they > really think that such an anti-competitive 200 customer policy > - does neither hit IPv6 and the idea behind it > - does not hit community > - will not be forced down by EU commission authorities ?!? If you want to discuss anti-competitive rules, then how about the 80% threshold which fails to recognize the technical realities of IPv4 subnetting which means that large networks can never be as efficient as smaller ones. But that is being addressed by the HD-Ratio proposal. --Michael Dillon

3 2

Re: how 200 /48's fails the job [Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria]
by Wilfried Woeber, UniVie/ACOnet 06 Apr '05

06 Apr '05

>If you remove "to other organisations" from d) and also reword c) so that >it refers to something other than organisations (sites?) then I think >the policy will be much fairer. Now we are getting closer to the real stuff: nobody in RIPE-Land has ever been able to agree on the definition of "ISP", much less on a definition of "customer" or "organisation" or "site". >However, I still think that the plan for 200 sites within 2 years is >not necessary at this point in time. It is not even useful or helpful, because the entities which should count up to the magical number 200, eventually, are of different make and model and lifespan. If you look at the "traditional mass-market ISP", having 200 customers is zilch. Private homes, SOHO stuff, and so on. Looking at e.g. a research network, a "customer" or "site" is something like Vienna University. Till recently (before the medical faculty was split off, I don't have the curent figures at hand) this site was serving some 60K+ students plus 6..7K facutly on the campus. The whole LAN serving that community on-site can live comfortably within a *single* /48 (yes we do have an addressing plan and our backbone is dual-stack :-). But, there are "slightly" less than 200 universities in our country... Looking at the regional school districts (9 of them, aligned with the federal states), they _could_ be run as a single site within a /48 each, and from our point of view, as a single "customer" (again 9 << 200) - or they can be treated as separate schools (=sites) leaving us with a couple of thousands to add to the tally :-). It all depends on the *operational model*, the connection technology, and the contractual relationships. Bottom line: 200 is just as good or useless as a "measure" for size of an operator, or its importance, determination to introduce IPv6, or the size of a user community served - as is 0, 5, 10, 100 or 20K. And, btw, I was involved in trying to align the evolving regional IPv6 policies across the regions: the magical mistery number "200" is merely a result of social engineering, and not a result of technical or scaling deliberations. The proposals we had on the table at that time were between "0" and a couple of "thousands". > If only we had a clearer definition >of a network How about: Some transmission equipment and physiacal channel, with more than 1 attachment point, serving some functional gadet, which require a unique identification and agreeing on the use of a common set of communication rules. those ruleswhich include using those unique identifiers on more than 1 of the attachment points. > and an internetwork. More than 1 operational domain with a "network", interconnected on at least 1, probably more, points using an "interconnection network" to provide and operate the exchange of information. > I would probably say something like: >"Any organization planning to operate an IPv6 internetwork connecting >two or more physically discontiguous locations...". You might have fun coming up with a definiton of "physically discontiguous locations...", but that's a diferent exercise :-) >--Michael Dillon Wilfried.

1 0

Re: [address-policy-wg] HD ratio policy proposal
by Erics 06 Apr '05

06 Apr '05

Dear colleagues, we think the IPv4-HD-Ratio is a good instrument for LIRs to manage the demand of address space. Especially in view of their internal topologies. Even though it may have some limited impact to address space consumption we support this proposal. Kind regards Eric - for de.telekom

1 0

RE: [address-policy-wg] Summary TLD Anycast Allocation Policy
by Wilfried Woeber, UniVie/ACOnet 05 Apr '05

05 Apr '05

>2. /32 vs. /48 V6 prefix - routability aspect > >From a routing table perspective there is no difference if the prefix is >longer or shorter. Well, for those so keen on preserving the last bit of memory, a _shorter_ prefix would actually be more efficient ;-) > When asking around which prefix length would have a good chance to >ensure the goal of not beeing filtered I have felt consensus that a /32 >has by far the best chances. However I'm considering if it wouldn't be >best to declare a /32 microallocation block from which RIPE will assign >/48 blocks. Other than the goal of conservation (which we have beaten to death already) what is the benefit of doing that? Administrative ease to collate them from the database? I would be be more worried abut the potential of taking the whole block down in one big sweep by misconfiguration and/or leaking announcements. But maybe this isn't an issue in the world of anycast for "critical" DNS services. Otoh, for those who don't like the concept, it would make it easier to cut off connectivty to those segments by entering just 1 filter... Wilfried.

1 0

Summary TLD Anycast Allocation Policy
by Andreas Bäß/Denic 05 Apr '05

05 Apr '05

Dear WG! I have followed the discussion about the TLD Anycast Allocation Policy and decided not to quote from the previous posting but to pick up the arguments - as I have understood them - and pointing to the places where I have tried to address them in my policy draft. 1. Is there a need for anycasting at all ? I was surprised to see this question on the list. I think that anycasted nameservers are an accepted standard and there is no need to discuss pros and cons anymore. 2. /32 vs. /48 V6 prefix - routability aspect >From a routing table perspective there is no difference if the prefix is longer or shorter. When asking around which prefix length would have a good chance to ensure the goal of not beeing filtered I have felt consensus that a /32 has by far the best chances. However I'm considering if it wouldn't be best to declare a /32 microallocation block from which RIPE will assign /48 blocks. 3. /32 vs. /48 V6 prefix - address conservation aspect There is no question that a /32 is quite a big block and that this sacrifice to "ensure" reachability from most network places is worth it. This question should be raised at regular intervals which is covered by renewing/adjusting/withdrawing the policy if circumstances have changed. I felt that there has been consensus within the folks I have talked to that a /32 is currently a good thing to keep the komplexity of anycast deployment at a bearable level. However the last disccusion showed me that a lot of people would prefer to assign /48 from a /32 TLD Anycast Allocation Block. 4. Are the number of assignments under this policy limited? The policy in its current form implies a limit of one V4 and one V6 block assignment because as soon as one assigment is made there is no chance to pass the referenced IANA test to get another assignment. 5. Who gets the address assignment? The assignment is bound to a TLD nameservice. Therefore the applicant would be a TLD administrator. The TLD administrator can use this assignment either by himself or hand it to an anycast provider that will operate the anycast nameservers for him. I don't think that sharing an assignment between multiple TLDs if they outsource their operation to an anycasting DNS provider should be a must to separate TLD operations from each other and that the extra address space spent is a good thing keeping in mind the limited number of TLDs where talking about. Summary: I hope with my explanation it explains that most of the concerns have been addressed already. Allocating a /32 prefix to all RIPE TLD anycast assignments should help to address concerns about address space usage and make setting up routing filters easier. Any comments or suggestions? Andreas -- DENIC e.G. Phone :+49 69 27235 120 Wiesenhuettenplatz 26 Fax :+49 69 27235 235 D-60329 Frankfurt Mail : baess(a)denic.de -- DENIC e.G. Phone :+49 69 27235 120 Wiesenhuettenplatz 26 Fax :+49 69 27235 235 D-60329 Frankfurt Mail : baess(a)denic.de

5 4

Re: [Ticket #1032183] Autoreply: viadomains <bleep>
by Randy Bush 05 Apr '05

05 Apr '05

i have plonked all mail from vianetworks.co.uk. if they ever get a clue and have something useful to say, someone please tell me. randy > From: via-domains <domains(a)vianetworks.co.uk> > RT-Ticket: Ticket #1032183 > Managed-by: RT 3.2.3 (http://www.bestpractical.com/rt/) > RT-Originator: randy(a)psg.com > To: randy(a)psg.com > > Thank you for your enquiry concerning "Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria", a summary > of which appears below. It has been logged with our automated ticketing > system and will be forwarded on to the appropriate department. > > You have been allocated a unique reference number - [Ticket > #1032183] - for this query that should be used in all further > correspondence relating to this matter. If replying by email, please > make sure that the ticket number is in the subject header. > > Thank you for your query, > > VIA Networks UK Support Administration > domains(a)vianetworks.co.uk > ------------------------------------------------------------------------- > Spam detection software, running on the system "he401war", has > identified this incoming email as possible spam. The original message > has been attached to this so you can view it (if it isn't spam) or block > similar future email. If you have any questions, see > sysadmin(a)vianetworks.co.uk for details. > > Content preview: >> and we once thought 32 bits of address should be > enough for ever > *I* wasn't part of that "we" - and the math is a > *little* bit different > here. > *I* wasn't part of that "we" one of > the few benefits of age is perspective [...] > > Content analysis details: (6.1 points, 5.0 required) > > pts rule name description > ---- ---------------------- -------------------------------------------------- > 1.0 RCVD_FROM_SECONDARY Went through secondary MX record > 0.1 TW_VT BODY: Odd Letter Triples with VT > 5.4 BAYES_99 BODY: Bayesian spam probability is 99 to 100% > [score: 1.0000] > -0.4 AWL AWL: Auto-whitelist adjustment > > >

3 2

Draft Agenda for Address Policy WG @ RIPE 50 Thursday 5th May
by Hans Petter Holen 05 Apr '05

05 Apr '05

Dear all, Please find enclosed a first Draft Agenda for the upcoming Address Policy meeting. -hph A. Administrative Matters - Welcome - Select a scribe - Distribute participants list - Finalise agenda - Approve minutes from RIPE 49: http://www.ripe.net/ripe/wg/address-policy/r49-minutes.html B. Policy overview - Regional policy overview -- presentation of the status of the current regional proposals under the "beta test of the PDP" -- status of the PDP and transition to the PDP - Gloobal policy overview C. Policy proposal: #alpha: TLD Anycast Allocation Policy D. Policy proposal: #beta: IPv4-HD-Ratio E. Policy proposal: #gamma: IPv6 remove 200 customer requirement F. Other v6 issues ? G. Status of the IPv4 Global Policy H. Status of the IPv6 Global Policy I. Any other Business

1 0

Re: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy
by Wilfried Woeber, UniVie/ACOnet 04 Apr '05

04 Apr '05

>>> Well, this can be argued the otherway around as well. We know that >>> ISPs >>> filter out previously unused space, and that they are not very active >>> in updating those filters when IANA starts allocating out of new >>> blocks. Having all in well-known block would limit that. >> >> ...wouldn't we/you/they/all have to do some filtering the "other way >> 'round" if all of those prefixes are contained in _one_ superblock to >> guard against someone/something announcing (and potentially black- >> holeing(sp?)) a route for that /32? > >Eh, I would assume there is no /32 to announce and that more specifics >will always win. > >- - kurtis - In a perfect world - yes. But "per default" when you announce something in v6-world, you are "supposed" to announce a /32 (or maybe a /35) _and_ filter anything that is longer than that. I really don't see any benefit from adding complexity again, other than clinging to the well-worn conservatiopn goal from IPv4. Wilfried.

16 39

HD ratio policy proposal
by Kelaidis Christine 04 Apr '05

04 Apr '05

My company believes that the proposal for the calculation of the HD ratio to measure IPv4 usage is a an improvement to the existing one and we would like to support this new policy proposal. Christine Kelaidis

1 0