April 2005 - address-policy-wg

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