- lir-wg - mailman.ripe.net

Re: FW: more specific routes in today reality
by Sabrina Waschke 08 Nov '01

08 Nov '01

The role of the RIPE NCC in this matter is to simply point out the different options, so that network operators can take them into account when requesting address space. It is the ISPs that decide what gets routed. The RIPE NCC has no influence on this. We will continue to assign PI address space unless the RIPE community revises this policy. However, if there are clear recommendations from the community, the RIPE NCC will certainly make these recommendations known to its members. Kind regards, Sabrina Waschke -- o------------------------------------------o | Sabrina Waschke sabrina(a)ripe.net | | Registration Services Operations Manager | | | | RIPE NCC tel +31 20 535 4444 | | www.ripe.net fax +31 20 535 4445 | o------------------------------------------o "Koepp, Karsten" <Karsten.Koepp(a)lambdanet.net> writes: * Nurani, * * I was missing a RIPE NCC hostmaster statement to this e-mail. * Sascha quoted a hostmaster. * * > -----Original Message----- * > From: Sascha E. Pollok [mailto:sp@iphh.net] * > Sent: Tuesday, October 09, 2001 12:33 PM * > To: Gert Doering; Vladimir A. Jakovenko * > Cc: lir-wg(a)ripe.net; routing-wg(a)ripe.net * > Subject: Re: more specific routes in today reality * * <SNIP> * > * > "- If PI is requested for multi-homing please explain why * > the second * > provider cannot route PA space as a more specific * > route (with the * > PA block holder adding a more specific route too)." * > * > This was suggested from a RIPE NCC Hostmaster when sending a * > PI-space req. This looks a little contrary to your opinion doesn't * > it? * > * > Sascha * > * * Has this been a mistake, or is this the default answer to PI requests * sent to the NCC nowadays? Is the NCC seriously going to recommend this * to the members? * I don't recommend the use of PI to customers either, and I don't want * to roll up the multi-homing discussion. But PI should remain provider- * independent and PA should remain provider-aggregatable. * * Regards Karsten * * Sorry for the late posting in this thread... *

1 0

RE: FW: more specific routes in today reality
by Koepp, Karsten 07 Nov '01

07 Nov '01

Vladimir, > -----Original Message----- > From: Vladimir A. Jakovenko [mailto:vovik@lucky.net] > Sent: Wednesday, November 07, 2001 2:34 PM > To: Koepp, Karsten > Cc: 'nurani(a)ripe.net'; 'lir-wg(a)ripe.net' > Subject: Re: FW: more specific routes in today reality > > > On Wed, Nov 07, 2001 at 01:55:01PM +0100, Koepp, Karsten wrote: > >Nurani, > > > >I was missing a RIPE NCC hostmaster statement to this e-mail. > >Sascha quoted a hostmaster. > [..skipped..] > ><SNIP> > >> > >> "- If PI is requested for multi-homing please explain why > >> the second > >> provider cannot route PA space as a more specific > >> route (with the > >> PA block holder adding a more specific route too)." > >> > >> This was suggested from a RIPE NCC Hostmaster when sending a > >> PI-space req. This looks a little contrary to your opinion doesn't > >> it? > >> > >> Sascha > >> > > > >Has this been a mistake, or is this the default answer to PI requests > >sent to the NCC nowadays? Is the NCC seriously going to > recommend this > >to the members? > >I don't recommend the use of PI to customers either, and I don't want > >to roll up the multi-homing discussion. But PI should remain > provider- > >independent and PA should remain provider-aggregatable. > > Quote from RFC1930, "Guidelines for creation, selection, and > registration > of an Autonomous System (AS)", page 7: > > "With the introduction of aggregation it should be noted that > a prefix may > be represented as residing in more than one AS, however, this > is very much > the exception rather than the rule". > RFC1930 does not know PA or PI address categories, just routes. > Quote from RFC2725, "Routing Policy System Security", page 9: > > "Route objects may exist for the same prefix with multiple > origin AS values > due to common multihoming practice that does not require a > unique origin AS". RFC2725 does mention PI, but not the case where PA addresses are being multi-homed. All I am saying is, regardless of whether we want this type of multi-homing or not, networks originating from different AS should use PI space. It does neither save a route nor address space to make pieces of a PA block multi-homed. It only binds the network to the provider assigning the PAs. That's why I was up-set. Still waiting for the NCC to answer... Karsten

2 1

FW: more specific routes in today reality
by Koepp, Karsten 07 Nov '01

07 Nov '01

Nurani, I was missing a RIPE NCC hostmaster statement to this e-mail. Sascha quoted a hostmaster. > -----Original Message----- > From: Sascha E. Pollok [mailto:sp@iphh.net] > Sent: Tuesday, October 09, 2001 12:33 PM > To: Gert Doering; Vladimir A. Jakovenko > Cc: lir-wg(a)ripe.net; routing-wg(a)ripe.net > Subject: Re: more specific routes in today reality <SNIP> > > "- If PI is requested for multi-homing please explain why > the second > provider cannot route PA space as a more specific > route (with the > PA block holder adding a more specific route too)." > > This was suggested from a RIPE NCC Hostmaster when sending a > PI-space req. This looks a little contrary to your opinion doesn't > it? > > Sascha > Has this been a mistake, or is this the default answer to PI requests sent to the NCC nowadays? Is the NCC seriously going to recommend this to the members? I don't recommend the use of PI to customers either, and I don't want to roll up the multi-homing discussion. But PI should remain provider- independent and PA should remain provider-aggregatable. Regards Karsten Sorry for the late posting in this thread...

3 2

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