October 2001 - lir-wg - mailman.ripe.net

RE: Multihoming - Resilience or Independence
by Lu, Ping 23 Oct '01

23 Oct '01

> > > Even for PI and swamp space, if the organization divides > their space among > > different ISPs for > > multi-homed links. You still got a problem. > > That is what I thought this thread was about? > > > > That is not the suggestion. See above. The assignments per > > > block and RIR > > > is well known. > > > > Well known and lots of holes in it. That's the problem. > > Uhm, say again? You mean that there are people that take address > assignments with them when they change provider? I think that > is a much > larger problem than that of multihoming then... > I mean when a customer get a second link from a backup ISP using the same block from the primary ISP. Then it became a hole in the primary ISP's CIDR block. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net

1 0

FreeIPdb to be released
by David R Huberman 23 Oct '01

23 Oct '01

Hello, As discussed last month on this list, Global Crossing uses a powerful suite of tools, called IPdb, to manage its address space, address space assignments, and RIR requirements for both IPv4 and IPv6. Version 1.0 of FreeIPdb will be released next week as open source. I will post all the pertinent details in the coming days. /david *--------------------------------* | Global Crossing API | | Manager, Global IP Addressing | | (703) 627-5800 | | huberman(a)gblx.net | *--------------------------------*

1 0

LIR-PARTITIONED - Final version
by Nurani Nimpuno 23 Oct '01

23 Oct '01

Dear all, Following the announcement 28 Sep 2001 on these lists, please find below the final details of the LIR-PARTITIONED PROPOSAL. This proposal will be implemented by the RIPE NCC in the coming period and presented at the RIPE 41 meeting in January 2002. Comments and suggestions made on this list have been incorporated in the proposal below. +-----------------+ | LIR-PARTITIONED | +-----------------+ Background ----------- This proposal (initially named "LIR-ALLOCATED") was originally discussed at September 1999. James Aldridge later sent out a first proposal to the LIR-WG mailing list, 14 Jan 2000. (See: http://www.ripe.net/ripe/mail-archives/lir-wg/20000101-20000401/msg00007.ht…) The full final proposal (15 Jan 2001) by Aldridge can be found at: http://www.ripe.net/ripe/mail-archives/lir-wg/20010101-20010401/msg00003.ht… At the RIPE 38 meeting,(22-26 Jan 2001), the RIPE NCC accepted the action to implement this proposal. Motivation (as expressed by James Aldridge) -------------------------------------------- "For various reasons large registries often need to distribute their allocated address space between various parts of their organisation (for example we have separate national operations in 20 or so countries obtaining address space through the eu.eunet registry). In these situations it makes sense to document this redistribution in the RIPE database but there is currently no way to do this without throwing up errors in the RIPE NCC's auditing procedures or by removing flexibility and adding more work to the already busy NCC hostmasters by having each local operation treated as having their own allocation. Previously the RIPE database software allowed anyone to register an object with a status value of "ALLOCATED" but this was abused by people who didn't know what they were doing and so this is no longer possible and all non-NCC registered inetnum objects must now have the status of "ASSIGNED". However, having multiple levels of assignments in the RIPE database causes error reports from the NCC's auditing processes which now see anything under the higher lever sub-allocation as being a duplicate (or overlapping) assignment which makes finding "real" problem assignments difficult or impossible. By allowing a local IR to register an inetnum object with a new status value of "LIR-ALLOCATED" it becomes possible to differentiate between a higher level sub-allocation ("status: LIR-ALLOCATED") and a final assignment by a LIR ("status: ASSIGNED"). By allowing this registration of intermediate objects it would also be possible to restrict changes to lower-level objects differently in different blocks of addresses within the LIR's allocation by setting different "mnt-lower" values without having to open the whole allocated block up for changes by anyone who might have a valid reason for updating a particular (range of) inetnum object(s)." Database Objects affected ------------------------- Only inetnum objects may have the "LIR-PARTITIONED" status value. Usage ----- The "LIR-PARTITIONED" feature allows LIRs to delegate maintenance of lower-level objects representing assignments within the address space specified by the inetnum object with the status "LIR-PARTITIONED PA" OR "LIR-PARTITIONED PI". Functionality ------------- When creating or modifying the inetnum object the database will check the value of the "status:" attribute according to the following rules: - The value of "ALLOCATED PA" or "ALLOCATED PI" is allowed if the object is maintained by the RIPE-NCC-HM-MNT mntner (this name is specified in ALLOCMNT variable of the configuration file) - The value of "LIR-PARTITIONED PA" is allowed if one level less specific inetnum object contains a "status:" attribute with the value of "ALLOCATED PA" or "LIR-PARTITIONED PA". - The value of "LIR-PARTITIONED PI" is allowed if one level less specific inetnum object contains a "status:" attribute with the value of "ALLOCATED PI" or "LIR-PARTITIONED PI". Additional clarification ------------------------ This proposal addresses the added inetnum status value as proposed by James Aldridge. This is strictly a database feature, allowing LIRs to delegate maintenance within their allocations in the RIPE Database. The implementation of this proposal will not affect IP address allocation policy. This means that it will not affect the responsibility LIRs have for allocations and assignments held by them. Furthermore, it will not change the manner in which the RIPE NCC verifies allocation utilisation. There is an on-going policy discussion addressing this specific issue. Kind regards, Nurani Nimpuno *-----------------------------------* | Nurani Nimpuno <nurani(a)ripe.net> | | Internet Address Policy Manager | | RIPE Network Co-ordination Centre | | http://www.ripe.net | *-----------------------------------*

1 0

RE: Multihoming - Resilience or Independence
by Lu, Ping 23 Oct '01

23 Oct '01

> > That's why filtering /20 only without re-aligning the holes > in the block > > won't > > work. In the end /20 make the routing table looks pretty > but they are > > black-holing > > lots of traffic. > > Well, it won't. The proposal for filtering is to filter on assigment > boundary, and for swamp space filter on /24. Now, what will break is > people punching holes in their PA space for multihomed users. Funny > enough, this has never been discussed (to my knowledge) as a > problem in > PTOMAIN WG of the IETF. There the argument was for traffic > engineering and > commercial relationships... > Even for PI and swamp space, if the organization divides their space among different ISPs for multi-homed links. You still got a problem. > > As we all agree that re-assign address is NOT practical at > all thus just > > filtering > > /20 block is not a good solution. > > That is not the suggestion. See above. The assignments per > block and RIR > is well known. Well known and lots of holes in it. That's the problem. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net

2 1

Revised Document available: RIPE-229
by RIPE NCC Document Announcement Service 22 Oct '01

22 Oct '01

Revised RIPE Document Announcement -------------------------------------- A revised document is available from the RIPE document store. Short content description ------------------------- This document recommends a set of route-flap damping parameters that should be applied by all ISPs in the Internet and should be deployed as default values by BGP router vendors. This document obsoletes ripe-210 and ripe-178. The document is available in HTML format at: http://www.ripe.net/ripe/docs/ripe-229.html Accessing the RIPE document store --------------------------------- The RIPE document store is 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-229.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-229.txt plain text version

1 0

219/8 allocated to APNIC
by Mirjam Kuehne 18 Oct '01

18 Oct '01

Dear Colleagues, Please see the announcement below. Mirjam Kuhne RIPE NCC ------- Forwarded Message Date: Wed, 17 Oct 2001 13:58:50 +1000 From: George Michaelson <ggm(a)apnic.net> Sender: owner-apnic-announce(a)lists.apnic.net To: apnic-announce(a)lists.apnic.net Subject: [apnic-announce] Additional IPv4 address range allocated to APNIC [Note "reply-to:" field] - --------------------------- Dear colleagues APNIC received the IPv4 address range 219/8 from IANA on 12 October 2001 and will now begin making allocations from this range. Please configure your routing filters accordingly. For more information on the resources administered by APNIC, see: http://www.apnic.net/db/ranges.html For information on the minimum allocation sizes within address ranges administered by APNIC, see: http://www.apnic.net/db/ranges.html For information on the minimum allocation sizes within address ranges administered by APNIC, see: http://www.apnic.net/db/min-alloc.html Kind regards Son APNIC Member Services Department - ------------------------------------------------------------- * APNIC-ANNOUNCE: Announcements concerning APNIC * * To unsubscribe, send "unsubscribe" to apnic-announce-request(a)apnic.net * ------- End of Forwarded Message

1 0

NEW mailing lists for global IPv6 address policy
by Mirjam Kuehne 18 Oct '01

18 Oct '01

Dear Colleagues, Please find below information about a new mailing list set up to discuss IPv6 address policy on a global level. Kind Regards, Mirjam Kuhne RIPE NCC -------------------------------------------------- * GLOBAL DEVELOPMENT OF REVISED IPv6 ADDRESS POLICY A new mailing list has been established to co-ordinate global policy discussions on the development of a revised IPv6 addressing policy to replace the "Provisional IPv6 assignment and allocation policy document". The list name is <global-v6(a)lists.apnic.net>. Although this list is hosted by APNIC, it is open to all members of the global Internet community with an interest in IPv6 address policy. Subscription information is available at: http://www.apnic.net/net_comm/lists/ Archives of discussions are available at: http://www.apnic.net/mailing-lists/global-v6 --------------- The RIRs encourage all interested parties to subscribe to this list and contribute to the development of important global address policy.

1 0

IPv6 Network Plans (Forcasting)
by Dave Pratt 18 Oct '01

18 Oct '01

Hiya Folks, I would like to elaborate on a comment made at the end of the LIR/IPv6 session in Prague about the ability of IPv6 address space requesters to forecast their address requirements. These suggestions probably might not make it into the provisional policy, but should be considered for later policy. A large ISP, probably global, and certainly national, could build its entire infrastructure with a single /48 network block. For example this would allow 256 "locations", each with 256 networks, each with more hosts than ants on this planet.... With the popular /127 for point-point connections even customer lines can be accomodated. Accordingly, the only driver for longer prefixes would seem to be the /48 customer networks. How will applicants for IPv6 address allocations quantify these networks ? The only way I can see is from very early marketing forcasts. In the past RIPE have viewed marketing forecasts with a lot of suspicion (quite rightly). However, unless RIPE issue a "one size fits all" prefix they may have to base allocations on these marketing forecasts. One thing however can be relatively easily determined, and that is "whether an applicant has ANY customers". For those LIR WITHOUT any customers, we could allocate a /48 and even large multinational corporations would have plenty of addresses (see second paragraph above again). For those LIR WITH customers, we should be much more generous because we cannot accurately judge needs from marketing forecasts. Assuming a HD ratio of 0.8, then a moderately successful city carrier LIR with 100,000 DSL or Cable customers (each requiring a /48) will qualify for more than a /28 allocation. Do we want such LIRs to come back and ask for a second route (in the global routing table) ? Conclusion: 1. We should consider allocating a /48 to LIR without any customers as this is plenty. 2. Even a /28 would result in considerable numbers of followup requests if cable/DSL customers (mass users) get /48. Opinions, Comments, Concensus ? Cheers Dave

4 5

RE: Multihoming - Resilience or Independence
by Tony Barber 16 Oct '01

16 Oct '01

At 01:18 PM 10/10/01 +0200, BLOCKI,JACEK \(HP-Poland,ex1\) wrote: >like route flaps do we?. In my opinion OSPF + 2 access links to 2 POPs of >single ISP would do the you much better. I wonder why virtually nobody >offers such a service? Because extending your IGP to customer sites is a bit silly, bloating your IGP and inducing a potential for misinformation from an external domain. You really don't want to do this. It may work well in small networks but certainly not in large players. Tony

3 2

RE: Multihoming - Resilience or Independence
by Lu, Ping 16 Oct '01

16 Oct '01

> > > The point is we will aggregate other ISP's prefixes if they > are CIDR able. > > Most of the case > > are there are holes in the range so CIDR is out-of-question. > > > > While the other camp insist to filter out any routes more > specific than /20. > > They are doing nothing to re-allocate their PA assigned to > multi-homed > > customers so CW can CIDR them into /20. > > > > The funny thing is the solution are controlled by the other > camp but they > > are all talk but > > no action. (Or trying to tell you multi-homed is a bad idea > because they > > can't deal with the > > routing table ). > > I am not sure I am following you here. Are you saying that we should > re-adress customers so that we get larger blocks of PA space > to give to > mulithomed customers? > > I think that re-addressing is pretty hard to do in any larger scale, > although that would certanly help some other issues. > That's why filtering /20 only without re-aligning the holes in the block won't work. In the end /20 make the routing table looks pretty but they are black-holing lots of traffic. As we all agree that re-assign address is NOT practical at all thus just filtering /20 block is not a good solution. > another good start would be to start reclaiming space that > has been handed > out from various ISPs old B-space and later taken with the customer. I > know a few operators that have done that (including us to > some extent), > and it's a rather demanding task but will help the operators > and reudce > the routing table as well. > > - kurtis - > I am with you here. Starting from the beginning is much better than asking them to change later. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net

2 1