From leo at ripe.net Mon Feb 3 17:02:41 2003 From: leo at ripe.net (leo vegoda) Date: Mon, 3 Feb 2003 17:02:41 +0100 Subject: [lir-wg] Creation of PI Policy Task Force Message-ID: Dear Colleagues, At last week's RIPE 44 meeting in Amsterdam, the LIR WG created a task force to investigate changes to the policy for PI assignments. Issues raised in the WG session included the needs of ccTLD name servers, IXPs and the routability of address assignments. You can view a recording of the LIR WG sessions on-line from: rtsp://webcast.ripe.net/Archive/lir-1.rm and rtsp://webcast.ripe.net/Archive/lir-2.rm If you would like to take part in the task force then please let me know so that I can subscribe you to the mailing list. Kind regards, -- leo vegoda RIPE NCC Registration Services From hpholen at tiscali.no Sat Feb 8 00:34:58 2003 From: hpholen at tiscali.no (Hans Petter Holen) Date: Sat, 08 Feb 2003 00:34:58 +0100 Subject: [lir-wg] ASO AC Representative to the ICANN NomCom In-Reply-To: <12966615.1042151548@213.234.102.185.adsl.oeke.tiscali.no> References: <12966615.1042151548@213.234.102.185.adsl.oeke.tiscali.no> Message-ID: <141005500.1044664498@cq> --On 9. januar 2003 22:32 +0100 Hans Petter Holen wrote: > As a consequence of the ICANN reform the AC is supposed to appoint a > representative on the ICANN nomination committee. The role of the nomcom > is to elect some of the future ICANN board members. (The AC still has a > task to elect some). FYI: ------------ Forwarded Message ------------ Date: 6. februar 2003 08:49 -0800 From: Mark McFadden - ASO Address Council To: ac-coord at aso.icann.org Cc: linda at icann.org, stuart at icann.org Subject: [AC-COORD] ASO AC Representative to the ICANN NomCom All: Yesterday, as part of the Address Council's regularly scheduled monthly teleconference, an election was held for the AC representative to the ICANN Nominations Committee. The Address Council was pleased that two strong candidates stepped forward to volunteer their time and effort on behalf of the community. On behalf of the Address Council I thank both German Valdez and Eric Decker for agreeing to stand as the AC representative. On February 4, 2003 the Address Council elected German Valdez to act as its representative to the ICANN NomCom beginning immediately and with a term ending December 31, 2003. Please join with me in congratulating German in his new role and thanking Eric for his willingness to serve on the Address Council's behalf. mark Mark McFadden North American Representative (ARIN) - Address Council Address Supporting Organization - ICANN aso.ac at mcfaddencentral.com ---------- End Forwarded Message ---------- From ncc at ripe.net Mon Feb 10 13:14:17 2003 From: ncc at ripe.net (RIPE NCC) Date: Mon, 10 Feb 2003 13:14:17 +0100 Subject: [lir-wg] Re: NCC#2003021144 Network Abuse Issues In-Reply-To: <001301c2cfd4$fe7063b0$e6107142@GrowingColorado.com>; from Tim Crawford on Sat, 8 Feb 2003 17:48:41 -0700 References: <001301c2cfd4$fe7063b0$e6107142@GrowingColorado.com> Message-ID: <200302101214.h1ACEHrY017300@x6.ripe.net> Dear Tim, Thank you for your e-mail. Have you tried to contact the administrator of this network? His contact details are: person: Jean-Francois Stenuit address: Belgacom Skynet NV/SA address: Rue Carli 2 address: B-1140 Bruxelles address: Belgium phone: +32 2 706-1311 fax-no: +32 2 706-1150 e-mail: jfs at skynet.be nic-hdl: JFS1-RIPE remarks: ---------------------------------------- remarks: Network problems to: noc at skynet.be remarks: Peering requests to: peering at skynet.be remarks: Abuse notifications to: abuse at skynet.be remarks: ---------------------------------------- mnt-by: SKYNETBE-MNT changed: jfs at skynet.be 19970707 changed: ripe at skynet.be 20021125 source: RIPE Please note that the RIPE NCC allocates IP address space to operators. They assign those addresses to their networks and customers. The allocation is registered in the RIPE Database by the RIPE NCC and the assignments by the operators themselves. The contact information referenced is placed in the RIPE Database by the network operators and can be changed by them at any time using the automatic interface made available (to everyone) by the RIPE NCC. The RIPE NCC operates according to the requirements set by the RIPE Community. Those requirements are set in the various RIPE Working Groups. Participation in RIPE and its Working Groups is open to anyone with an interest in IP networking in the RIPE NCC Service Region. There is currently no standard defined by the RIPE Community for contact information referenced by inetnum objects in the RIPE Database. There is only the technical need to complete all the mandatory attributes in a "person:" or "role:" object. If you feel a need for a change in composition of the contact data used in the RIPE Database then you should raise the issue in the RIPE Community. If a consensus for change is reached the RIPE NCC will implement the technical changes required. Network operators would then need to implement any changes required of them. The following URLs may be useful: IPv4 Address Allocation and Assignment Policies in the RIPE NCC Service Region http://www.ripe.net/ripe/docs/ipv4-policies.html#5.1.2 Updates in the RIPE Database (from the Database Reference Manual) http://www.ripe.net/ripe/docs/databaseref-manual.html#3.0 "person:" object http://www.ripe.net/perl/whois?-vperson "role:" http://www.ripe.net/perl/whois?-vrole The LIR Working Group (where policy is set) http://www.ripe.net/ripe/wg/lir/index.html The Database Working Group (where Database requirements are set) http://www.ripe.net/ripe/wg/db/index.html The Anti-Spam Working Group (fighting the problem of spam) http://www.ripe.net/ripe/wg/anti-spam/index.html The RIPE NCC Service Region http://www.ripe.net/ripencc/mem-services/general/europe.html kind regards, Yvette Vermeer RIPE NCC On Sat, 8 Feb 2003 17:48:41 -0700, wrote: * Dear Sir or Ma'am, * * We have attempted to communicate with clients who subscribe with your * network. * inetnum: 80.201.0.0 - 80.201.255.255 * netname: BE-SKYNET-ADSL1 * * Reporting abuse using their Abuse Email address resulted in an auto-reply * directing you to an internet site where the Abuse Notifications page was not * functional. We are reporting this to Internet authorities here in the * United States and registering complaints with local providers (Arin.net). * If we are not able to address Hacking activity from clients within your * networks, steps need to be taken on this end to filter out access until * measures can be put into place to prevent such activity! * * Below is a copy of the Message: * * * Sincerely, * Tim Crawford * IT, CTES * * * * * To whom it may concern, * * Clients on your system have been observed in the conduct of Port Sniffing, * then using Password guessing software to gain access to remote systems. * * We have been observing - Host Name from Peer: umberto-89z8gkv * * for a period of Time attempting to access our networks. We established * several mock systems to observe what activity they intended. * * This person was able to determine and administrative User ID and Password. * After accessing the system the individual loaded a program called: * Protocol Version - DWRCC.EXE: 3.670000-0.000000 * * Protocol Version - DWRCS.EXE: 3.670000-0.000000 * * Product Version - DWRCS.EXE: 3.69.0.7 * and began a sharing operation between 9 additional users. (See below and * attachment from event logs) * * Unfortunately this person does not reside within the United States, in which * case we could openly pursue legal action against him. However, it there are * legal avenues in your country governing such abuse, please forward the * information so that we may proceed with legal action against your client. * This action will be sent to and logged with the IFCC and shared with all * U.S. networks which may result in Filtering preventing users of your network * access. * * Sincerely, * Tim Crawford * IT, CTES * * * * Date: 02/08/03 11:25:55 * * Computer Name: UMBERTO-89Z8GKV * * User ID: Umberto * * Logon As ID: DianeS * * Domain: * * OS Product ID: 55679-641-7737495-23856 * * OS Registered Owner: Umberto * * OS Registered Organization: * * Host Name from Peer: umberto-89z8gkv * * IP Addresse(s) from Peer: 192.168.0.1,169.254.145.179,80.201.61.247 * * Host: * * IP Address: 80.201.61.247 * * Protocol Version - DWRCC.EXE: 3.670000-0.000000 * * Protocol Version - DWRCS.EXE: 3.670000-0.000000 * * Product Version - DWRCS.EXE: 3.69.0.7 * * Authentication Type: NT Challenge/Response * * Last Error Code: 0 * * Last Error Code (WSA): 0 * * Absolute timeout setting: 0 minutes * * Connect/Logon timeout setting: 90000 miliseconds * * AccessCheck: * * . * * The description for Event ID ( 0 ) in Source ( DWMRCS ) could not be found. * It contains the following insertion string(s): * * DameWare Mini Remote Control * * , The following user has connected via remote control. * * * * * * Date: 02/08/03 11:26:03 * * Computer Name: UMBERTO-89Z8GKV * * User ID: Umberto * * Logon As ID: DianeS * * Domain: * * OS Product ID: 55679-641-7737495-23856 * * OS Registered Owner: Umberto * * OS Registered Organization: * * Host Name from Peer: umberto-89z8gkv * * IP Addresse(s) from Peer: 192.168.0.1,169.254.145.179,80.201.61.247 * * Host: * * IP Address: 80.201.61.247 * * Protocol Version - DWRCC.EXE: 3.670000-0.000000 * * Protocol Version - DWRCS.EXE: 3.670000-0.000000 * * Product Version - DWRCS.EXE: 3.69.0.7 * * Authentication Type: NT Challenge/Response * * Last Error Code: 0 * * Last Error Code (WSA): 0 * * Absolute timeout setting: 0 minutes * * Connect/Logon timeout setting: 90000 miliseconds * * Access Check: Administrators * * . * * The description for Event ID ( 0 ) in Source ( DWMRCS ) could not be found. * It contains the following insertion string(s): * * DameWare Mini Remote Control * * , The following user has or has been disconnected from remote control. * * * * * * Date: 02/08/03 12:17:51 * * Computer Name: UMBERTO-89Z8GKV * * User ID: Umberto * * Logon As ID: DianeS * * Domain: * * OS Product ID: 55679-641-7737495-23856 * * OS Registered Owner: Umberto * * OS Registered Organization: * * Host Name from Peer: umberto-89z8gkv * * IP Addresse(s) from Peer: 192.168.0.1,169.254.145.179,80.201.61.247 * * Host: * * IP Address: 80.201.61.247 * * Protocol Version - DWRCC.EXE: 3.670000-0.000000 * * Protocol Version - DWRCS.EXE: 3.670000-0.000000 * * Product Version - DWRCS.EXE: 3.69.0.7 * * Authentication Type: NT Challenge/Response * * Last Error Code: 0 * * Last Error Code (WSA): 0 * * Absolute timeout setting: 0 minutes * * Connect/Logon timeout setting: 90000 miliseconds * * Access Check: Admi From kristofer at nh.is Wed Feb 12 13:46:18 2003 From: kristofer at nh.is (Kristofer Sigurdsson) Date: Wed, 12 Feb 2003 12:46:18 +0000 Subject: [lir-wg] Sub-allocations, how and when? Message-ID: <20030212124618.GD15231@pfy.rhi.hi.is> Hello, I am currently doing some work for a small ISP with a fair number of clients, that wants to get a sub-allocation (in accordance with the new sub-allocations policy). We are going to request a /20 allocation from our primary uplink. However, we may have difficulties in showing usage for a /20 assignment for ourselves and our current customers (we're not far from it, though), but we need this allocation to deal with near-future customers. We are also going to request an AS in order to be properly multi-homed, which means we need the /20 right away to avoid prefix filters. We could of course, in accordance with the RIPE community's "slow-start" mechanism, start with a smaller allocation, or even just request assignments for ourselves, our customers, and then new customers as we go along, but this would mean lots of CIDR blocks, instead of just one /20. We are also going to request an AS in order to be properly multi-homed, due to prefix filters, having many small blocks is not an option. Becoming a LIR is not an option just now, due to various financial and political reasons. Now, my question to the list is, when will the sub-allocation policy be operational, and how will one request such an allocation? Presumably, RIPE will provide a sample allocation request form, any idea when? Any ideas on how to do this without a sub-allocation? Any way for our uplink to "reserve" a /20, which would then origin from our AS, and then assign chunks of it to us as we go along, maybe? Our uplink's AW is /24, and they don't have any room within their current allocations to give us a /20, so they would have to request this specifically from RIPE. Thanks in advance for any comments and/or suggestions. -- Krist?fer Sigur?sson From jrace at attglobal.net Thu Feb 13 16:08:56 2003 From: jrace at attglobal.net (Dr. Jeffrey Race) Date: Thu, 13 Feb 2003 22:08:56 +0700 Subject: [lir-wg] Abstract of proposed Internet Draft for Best Current Practice (please comment) Message-ID: <20030213150905.A20676A00F@postboy.ripe.net> Interested parties are invited to provide comments to correct, elaborate or perfect my proposal, abstracted below. I'd also welcome suggestions for other fora in which to post requests for comments. I plan to offer as Internet Draft when comments are all in. Comments or objections to the effect "This is going to be burdensome on $spam_enabler" are superfluous because that is the precise intention of the proposed Practice: to move the burden from victims to polluters and their enablers. Thanks for all help. Jeffrey Race BEST CURRENT PRACTICE FOR DUTY OF CARE OF INTERNET RESOURCES Pre-release version 1.31 Draft date: February 13, 2003 Drafted by Jeffrey Race Current draft version (4,000 words) available at ABSTRACT This document defines a Best Current Practice to minimize pollution of the Internet by various types of abuse, using the community's own measures in the absence of effective legal, regulatory and technical measures. The Internet's design and management were predicated on voluntary cooperation, self-imposed good behavior, and the non-profit motivational structure of custodians of Internet Resources extant at its inception. Current experience of constantly rising pollution invalidates these formative assumptions and demands prompt and effective curative measures. Present anti-pollution measures fall under four generic headings: (1) self-directed good behavior; (2) legal sanctions (3) technical measures (principally filtering) and (4) self-help defensive measures (principally blocklisting). The first three have definitively failed and will continue to fail for reasons specified in the document. The fourth is generally completely effective in warding off ingress of pollution and frequently results in reforming abuse enablers, but it has two major shortcomings: limited uptake due to fear of loss of competitive market position by early adopters, and sustained transmission outages ("collateral damage"). In view of the failure of (1), (2) and (3) and the effectiveness despite shortcomings of (4), the document proposes to apply to the Internet the same rules society applies to all other resources to deter antisocial behavior viz. proper behavior requires clear published standards, standards entail accountability, accountability entails multiple modes of enforceability, and enforceability entails traceability. The document details procedures and implementing mechanisms based on this universal rule of human experience, while preserving present levels of anonymity for deserving cases. Since both legal and technical measures have failed and will continue to fail, only the behavior modification method of stopping pollution remains, and the only proven effective method of behavior modification is withdrawal of internet resources of identity and connectivity to continue pollution. Numerous tests have shown this sanction to work equally well against both the wilful and the negligent to halt pollution immediately, where prior efforts at polite persuasion to follow best practice were ignored with impunity. The proposal thus innovates in four respects to halt Internet pollution: (1) It makes explicit that every custodian of internet resources is responsible for preventing emission of pollution (2) Adopting a simultaneous universal practice of withdrawal of internet resources means that no provider will suffer competitive disadvantage (3) The burden of pollution now falls on the polluter and his enabler rather than on the victim, so conforming to the basic principle used everywhere else in society to maintain justice and good order. (4) This Practice legitimates withdrawal of internet resources as the only method proven effective in halting abuse. The Practice is intended to apply at every level of allocation, registration and usage of internet resources including but not limited to RIRs, LIRs, ISPs, webhosting firms, backbone connectivity providers, domain name registrars, and end-users. It defines internet resources, unsolicited bulk electronic messaging, and abuse, and specifies procedures progressively to sanction abuse after a period of public admonishment. In effect, the proposal implements the "user pays" paradigm in a completely new and clever way, without requiring any complicated metering technology all proposals for which have failed on issues of complexity, backward compatibility, absence of adequate hardware, and the need for universal adoption to be effective at all. The document embodies the only set of measures now on offer which will quickly end the spam menace internationally without any new legislation, and with but small and transitory disruption, by moving from the discredited "victim pays" model to the modern "polluting user pays" model, without any metering. Adoption will not only be cost-free for the Internet as a whole but will substantially reduce the current economic burden of abuse. It does this by transferring the economic burden from abuse victims to the polluters and their enablers, which is fair, easily feasible, and indeed the system used everywhere else in society. As such the anticipated vigorous objections to adoption from some parties may be seen in advance as self-serving attempts to perpetuate the discredited "victim pays" model by those now profiting from an environmental polluter business model or by their accessories and enablers. E:\WS\COMPOSE\RFCABST2.TXT ===================END FORWARDED MESSAGE=================== ===================END FORWARDED MESSAGE=================== From leo at ripe.net Fri Feb 14 10:01:46 2003 From: leo at ripe.net (leo vegoda) Date: Fri, 14 Feb 2003 10:01:46 +0100 Subject: [lir-wg] Sub-allocations, how and when? In-Reply-To: <20030212124618.GD15231@pfy.rhi.hi.is> References: <20030212124618.GD15231@pfy.rhi.hi.is> Message-ID: Hi Kristofer, Kristofer Sigurdsson writes: [...] >Now, my question to the list is, when will the sub-allocation policy be >operational, and how will one request such an allocation? Presumably, >RIPE will provide a sample allocation request form, any idea when? The policy will be implemented soon. However, we need to complete some updates to some internal software, first. We also need to introduce a new status attribute value into the database. With regards to request forms: the policy does not require LIRs to send requests to the RIPE NCC. Instead, the maximum sub-allocation size is linked to an LIR's Assignment Window. >Any ideas on how to do this without a sub-allocation? Any way for our >uplink to "reserve" a /20, which would then origin from our AS, and then >assign chunks of it to us as we go along, maybe? Our uplink's AW is >/24, and they don't have any room within their current allocations to >give us a /20, so they would have to request this specifically from >RIPE. If the upstream LIR does not have sufficient address space to make an assignment (or sub-allocation) then they can request an additional allocation. Kind regards, -- leo vegoda RIPE NCC Registration Services From john at apnic.net Fri Feb 14 06:13:09 2003 From: john at apnic.net (John Tran) Date: Fri, 14 Feb 2003 15:13:09 +1000 (EST) Subject: [lir-wg] APNIC new block of addresses Message-ID: Dear colleagues APNIC received IPv4 address blocks 222/8 and 223/8 from IANA in February 2003 and will be making allocations from these ranges in the near future. This announcement is being made for the information of the Internet community so that network configurations such as routing filters may be updated as appropriate. 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/min-alloc.html Kind regards Son ____________________________________________________________________ Resources Services Manager Asia Pacific Network Information Centre phone: +61 7 3858 3100 http://www.apnic.net fax: +61 7 3858 3199 Helpdesk phone: +61 7 3858 3188 email: helpdesk at apnic.net Please send Internet Resource Requests to _____________________________________________________________________ From kristofer at nh.is Fri Feb 14 11:39:52 2003 From: kristofer at nh.is (Kristofer Sigurdsson) Date: Fri, 14 Feb 2003 10:39:52 +0000 Subject: [lir-wg] Sub-allocations, how and when? In-Reply-To: References: <20030212124618.GD15231@pfy.rhi.hi.is> Message-ID: <20030214103952.GG27306@pfy.rhi.hi.is> Hi Leo, leo vegoda, Fri, Feb 14, 2003 at 10:01:46AM +0100 : [...] > With regards to request forms: the policy does not require LIRs to send > requests to the RIPE NCC. Instead, the maximum sub-allocation size is > linked to an LIR's Assignment Window. According to the draft, the maximum size of a sub-allocation is 400% of a LIR's AW each year. Since our request is 1600% of our upstream LIR's AW, doesn't that mean they'll have to forward our request to RIPE, just like they have to do for our conventional assignment requests? Thank you for your reply. -- Krist?fer Sigur?sson From leo at ripe.net Fri Feb 14 12:36:27 2003 From: leo at ripe.net (leo vegoda) Date: Fri, 14 Feb 2003 12:36:27 +0100 Subject: [lir-wg] APNIC new block of addresses Message-ID: FYI -------------- next part -------------- An embedded message was scrubbed... From: John Tran Subject: APNIC new block of addresses Date: 14 Feb 2003 05:15:32 GMT Size: 3610 URL: -------------- next part -------------- -- leo vegoda RIPE NCC Registration Services From webmaster at ripe.net Mon Feb 17 12:07:32 2003 From: webmaster at ripe.net (RIPE NCC Document Announcement Service) Date: Mon, 17 Feb 2003 12:07:32 +0100 Subject: [lir-wg] New Document available: RIPE-269 Message-ID: <200302171107.h1HB7XAq017258@birch.ripe.net> New RIPE Document Announcement -------------------------------------- A new document is available from the RIPE document store. Ref: ripe-269 Title: Smallest RIPE NCC Allocation / Assignment Sizes Author: Joao Luis Silva Damas, Leo Vegoda Date: 17 February 2003 Format: PS=10901 TXT=2159 Obsoletes: ripe-222, ripe-242, ripe-259. ripe-264, ripe-266 Obsoleted by: Updates: Updated by: Short content description ------------------------- This document contains the size of the minimum and default allocations made by the RIPE NCC to Local Internet Registries (LIRs) and End Users from IPv4 and IPv6 CIDR blocks allocated to the RIPE NCC by the Internet Assigned Numbers Authority (IANA). The new 2001:1400::/23 IPv6 allocation and its routing policy have been added. Accessing the RIPE document store --------------------------------- You can access the RIPE documents in HTML format via our website at the following URL:. http://www.ripe.net/docs/smallest-alloc-sizes.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-269.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-269.txt plain text version Kind Regards, Jeroen Bet RIPE NCC Web Content Manager From leo at ripe.net Tue Feb 18 08:55:40 2003 From: leo at ripe.net (leo vegoda) Date: Tue, 18 Feb 2003 08:55:40 +0100 Subject: [lir-wg] Sub-allocations, how and when? In-Reply-To: <20030214103952.GG27306@pfy.rhi.hi.is> References: <20030212124618.GD15231@pfy.rhi.hi.is> <20030214103952.GG27306@pfy.rhi.hi.is> Message-ID: Hi Kristofer, Kristofer Sigurdsson writes: >Hi Leo, > >leo vegoda, Fri, Feb 14, 2003 at 10:01:46AM +0100 : > >[...] > >> With regards to request forms: the policy does not require LIRs to send >> requests to the RIPE NCC. Instead, the maximum sub-allocation size is >> linked to an LIR's Assignment Window. > >According to the draft, the maximum size of a sub-allocation is 400% of >a LIR's AW each year. Since our request is 1600% of our upstream LIR's >AW, doesn't that mean they'll have to forward our request to RIPE, just >like they have to do for our conventional assignment requests? We won't be publishing request forms for LIRs wishing to sub-allocate more than 400% of their AW. We do not believe there is any reliable way for the RIPE NCC to evaluate such a request. This is because the request will, in most cases, be based on the predicted needs of predicted customers. Unlike assignments, no network plan justifying a request can be made. This is the main reason for delegating responsibility for sub- allocations to LIRs and basing it on their AW. Anyone needing a /20 could become an LIR and would receive it as long as they could demonstrate a need for efficient use of a /22 within the next three months. (Or existing use or a combination of the two). If you can suggest a reliable method of evaluating requests for a sub- allocation, and there is a demonstrated need for this, we would of course look at introducing a request form. Kind regards, -- leo vegoda RIPE NCC Registration Services From john at apnic.net Fri Feb 14 06:13:09 2003 From: john at apnic.net (John Tran) Date: Fri, 14 Feb 2003 15:13:09 +1000 (EST) Subject: [lir-wg] [APNIC Members][Apnic-announce] APNIC new block of addresses Message-ID: Dear colleagues APNIC received IPv4 address blocks 222/8 and 223/8 from IANA in February 2003 and will be making allocations from these ranges in the near future. This announcement is being made for the information of the Internet community so that network configurations such as routing filters may be updated as appropriate. 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/min-alloc.html Kind regards Son ____________________________________________________________________ Resources Services Manager Asia Pacific Network Information Centre phone: +61 7 3858 3100 http://www.apnic.net fax: +61 7 3858 3199 Helpdesk phone: +61 7 3858 3188 email: helpdesk at apnic.net Please send Internet Resource Requests to _____________________________________________________________________ _______________________________________________ Apnic-announce mailing list Apnic-announce at lists.apnic.net http://mailman.apnic.net/mailman/listinfo/apnic-announce * APNIC Members Mailing List * _______________________________________________ members mailing list members at lists.apnic.net http://mailman.apnic.net/mailman/listinfo/members From gert at space.net Tue Feb 18 16:31:13 2003 From: gert at space.net (Gert Doering) Date: Tue, 18 Feb 2003 16:31:13 +0100 Subject: [lir-wg] Sub-allocations, how and when? In-Reply-To: <20030212124618.GD15231@pfy.rhi.hi.is>; from kristofer@nh.is on Wed, Feb 12, 2003 at 12:46:18PM +0000 References: <20030212124618.GD15231@pfy.rhi.hi.is> Message-ID: <20030218163113.V15927@Space.Net> Hi, as the one who made the Sub-Allocation proposal, let me try to clarify a few things. On Wed, Feb 12, 2003 at 12:46:18PM +0000, Kristofer Sigurdsson wrote: > I am currently doing some work for a small ISP with a fair number of > clients, that wants to get a sub-allocation (in accordance with the new > sub-allocations policy). We are going to request a /20 allocation from > our primary uplink. However, we may have difficulties in showing usage > for a /20 assignment for ourselves and our current customers (we're not > far from it, though), but we need this allocation to deal with > near-future customers. We are also going to request an AS in order to > be properly multi-homed, which means we need the /20 right away to > avoid prefix filters. Sub-Allocation size should not be based on routing considerations. If you get a /22 (or similar), and someone "out there" is not accepting that announcement, packets will always travel over your upstream's aggregate (/16 or whatever they announce), so you can be reached. > We could of course, in accordance with the RIPE community's "slow-start" > mechanism, start with a smaller allocation, or even just request > assignments for ourselves, our customers, and then new customers as we > go along, but this would mean lots of CIDR blocks, instead of just > one /20. Depending on the layout and fragemntation of your upstream's network, it might be a good compromise to start with a smaller sub-allocation, but "keep" the remaining part of a /20 available in case you need it. If you really need the /20 quickly, it will be there. (If the address space is not there, I suggest that your upstream talks to the RIPE hostmasters how to solve that - a new allocation might be required. Maybe they can also demonstrate proper assignments of /23s and get their AW raised...) [..] > Now, my question to the list is, when will the sub-allocation policy be > operational, and how will one request such an allocation? Presumably, > RIPE will provide a sample allocation request form, any idea when? There's no official request form (yet) because the sub-allocation thing is something that's happening between you and your upstream. The NCC is /not/ involved here (normally). > Any ideas on how to do this without a sub-allocation? Any way for our > uplink to "reserve" a /20, which would then origin from our AS, and then > assign chunks of it to us as we go along, maybe? This would be the traditional way that people have been doing it before the sub-allocation policy. It's messy, cause you can't properly document what's happening. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 56285 (56029) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From leo at ripe.net Tue Feb 18 17:30:15 2003 From: leo at ripe.net (leo vegoda) Date: Tue, 18 Feb 2003 17:30:15 +0100 Subject: [lir-wg] Sub-allocations, how and when? In-Reply-To: <20030218163113.V15927@Space.Net> References: <20030212124618.GD15231@pfy.rhi.hi.is> <20030218163113.V15927@Space.Net> Message-ID: <8eLILpAX+lU+Ew2c@ripe.net> Gert Doering writes: [...] >(If the address space is not there, I suggest that your upstream talks >to the RIPE hostmasters how to solve that - a new allocation might be >required. Maybe they can also demonstrate proper assignments of /23s >and get their AW raised...) If an LIR would like us to review their AW they just need to send an e- mail to . We actively review LIRs' AWs very few requests. However, we're always happy to look again if requested. Regards, -- leo vegoda RIPE NCC Registration Services From leo at ripe.net Tue Feb 18 18:16:02 2003 From: leo at ripe.net (leo vegoda) Date: Tue, 18 Feb 2003 18:16:02 +0100 Subject: [lir-wg] Sub-allocations, how and when? In-Reply-To: <8eLILpAX+lU+Ew2c@ripe.net> References: <20030212124618.GD15231@pfy.rhi.hi.is> <20030218163113.V15927@Space.Net> <8eLILpAX+lU+Ew2c@ripe.net> Message-ID: leo vegoda writes: >Gert Doering writes: > >[...] > >>(If the address space is not there, I suggest that your upstream talks >>to the RIPE hostmasters how to solve that - a new allocation might be >>required. Maybe they can also demonstrate proper assignments of /23s >>and get their AW raised...) > >If an LIR would like us to review their AW they just need to send an e- >mail to . We actively review LIRs' AWs very few s/very/every/ Gah! the dangers of spell checkers :-) >requests. However, we're always happy to look again if requested. > >Regards, > -- leo vegoda RIPE NCC Registration Services From ncc at ripe.net Wed Feb 19 10:58:58 2003 From: ncc at ripe.net (RIPE NCC Mailing List administration) Date: Wed, 19 Feb 2003 10:58:58 +0100 Subject: [lir-wg] New Mailing List: lirportal@ripe.net Message-ID: <200302190958.h1J9wwAq001342@birch.ripe.net> Dear All, (Apologies for any duplicate mails). In response to the community's request during the Tools Working Group at RIPE 44 we are pleased to announce a new mailing list specifically for the RIPE NCC LIR Portal. This mailing list will provide an opportunity to discuss any issues related to the LIR Portal including the features offered and issues concerning the application. You can join the LIR Portal mailing list by following the instructions at: http://www.ripe.net/mailman/listinfo/lirportal For more information about the LIR Portal please refer to our previous announcement found at: http://www.ripe.net/ripencc/mem-services/lir-portal.html Regards, RIPE NCC Mailing List administration From ncc at ripe.net Wed Feb 19 11:08:46 2003 From: ncc at ripe.net (Nick Hyrka) Date: Wed, 19 Feb 2003 11:08:46 +0100 Subject: [lir-wg] RIPE 44 Meeting Report Message-ID: <5.1.1.6.0.20030219104937.02e66608@mailhost.ripe.net> (Apologies for any duplicate mails.) Dear Colleagues: The RIPE 44 Meeting was held recently at the Krasnapolsky Hotel from 27 - 31 January 2003 in Amsterdam. There were a total of 360 attendees comprised of the RIPE NCC membership, the RIPE community and government representatives. Attendees also included representatives from APNIC, ARIN, LACNIC, and ICANN. Members from the U.K. had the highest number of representatives (53), followed by Germany (50), the Netherlands (37) and the U.S.A (42). Additionally, there were more representatives from Eastern European countries than ever before. Highlights of RIPE 44 included the open discussion during the Plenary on the RIPE NCC 2002 membership survey results, the first report by LACNIC after being granted official RIR status, and the first webcasting trial of the RIPE 44 sessions held in the Grand Ballroom. Version 1.0 of the RIPE NCC LIR Portal was also showcased at RIPE 44. Portal features and benefits were noted at a presentation given at the LIR and Tools Working Groups? sessions. The RIPE NCC would like to thank SURFnet, Afilias, NIKHEF, KPN EuroRings, and AMSIX for the support they provided to the meeting. A summary of the RIPE 44 highlights follows: LIR === * Denesh Bhabuta (Aexiomus Limited) stepped down as co-chair of the LIR Working Group. Gert D?ring (SpaceNet) and Andrea Borgato (I.Net S.p.A.) were selected as new co-chairs. * A search for a new name for the LIR Working Group was started. Rob Blokzijl (RIPE Chair) will publish a proposal for a new name. * The LIR Working Group Chairs will draft a new charter for the working group. * The sub-allocation policy document was approved. No changes were made. * A task force and mailing list was formed to investigate changes to the PI policy. * The RIPE NCC was tasked to publish a draft document on status values in inetnum objects. DATABASE ========= * IPv6 support for querying the Whois Database has been implemented. * References by name have been cleaned from the database and an ?organisation:? object was proposed. * The RIPE NCC was tasked to: - document the mirroring protocol and its operational requirements. - add inverse lookups to all attributes that have integrity constraints. - propose and implement "reclaim:"-like functionality to the database. - add contact data to key-cert objects. IPv6 === * Enhanced IPv6 support for the new IPv6 Whois proxy has been implemented. * Test Traffic Measurement test-boxes now fully support IPv6. * Gert D?ring (SpaceNet) proposed discussions to enable IPv6 access to the root servers and AAAA records for TLD in the root zone. * Bernard Tuy (RENATER) was tasked to co-ordinate an IPv6 routing guideline document. * The RIPE NCC was tasked to: - enable reverse delegation for 6bone under ip6.arpa. - investigate increasing the size of RIR allocations to rationalise routing with the IANA. ROUTING ======= * Joao Silva Damas (ISC) was announced as co-chair of the Routing Working Group. A second co-chair is being sought. * The Routing Registry Consistency Check utility implemented by the RIPE NCC was finalised. The source code is available on the RIPE NCC ftp server at: ftp://ftp.ripe.net/ripe/dbase/software/RRCC-0.2.tar.gz * A list of IP address space allocated by the RIPE NCC, useful for filtering unallocated address space on routers, was published on the RIPE NCC ftp server at: ftp://ftp.ripe.net/ripe/stats/issued/ * As a part of the RIS Beacon Project the RIPE NCC was tasked to look into the behaviour of a second BGP announcement whilst the first one has not yet converged. * The RIPE NCC was tasked to analyse RIS data to approximate how much of the Internet is seen by RIS route collectors. DNS ==== * Johan Ihren (Autonomica AB) presented a proposal for experimentally signing the root-zone. The RIPE NCC was tasked to discuss the idea with the RIRs and propose technical and political recommendations. * Andrei Robachevsky (RIPE NCC) presented a report on IPv6-related DNS issues. The RIPE NCC requests feedback on freezing delegations in the ip6.int space, reverse 6to4 delegations and support of 6bone space reverse delegations under ip6.arpa. TTM & RESEARCH =============== * A new Chair is being sought for the Test Traffic Working Group. * Test Traffic Measurement test-boxes now fully support IPv6, making TTM the first measurement product on the market to do so. * CDMA is now fully supported as an alternative clock source. * Mailing list discussions have begun on upgrading TTM to the IPv6 version as well as on new business models for TTM. TECHSEC ======== * Erik Rozendaal (NLnet Labs) presented a new project at NLnet Labs called ?Donkey?. It intends to provide a general purpose distributed public key database. The presentation can be found at: http://www.ripe.net/ripe/meetings/archive/ripe-44/presentations/ripe44-techsec-donkey/donkey-talk.html ANTI-SPAM ========= * More spam problems with proxies than open relays were reported. * Assured Path Messaging was noted as a possible alternative e-mail service. PRESENTATIONS ============== * SQL Slammer Worm Attack / Rene Wilhelm (RIPE NCC) - Analysis of data collected around the time of this attack, showing clear effects but also that most of the Internet backbone infrastructure survived: http://www.ripe.net/ripe/meetings/archive/ripe-44/presentations/ripe44-tt-sql-slammer/ * Improved Secure Communication System for RIPE NCC Members / Andrei Robachevsky (RIPE NCC) - An initial proposal was presented on how to improve the current system by using a X.509-based PKI model: http://www.ripe.net/ripe/meetings/archive/ripe-44/presentations/ripe44-plenary-secure/ * The RIPE NCC LIR Portal v.1 / Leo Vegoda and Manuel Valente (RIPE NCC) - The new portal service?s features were explained in a live demonstration: http://www.ripe.net/ripe/meetings/archive/ripe-44/presentations/ripe44-lir-portal/ TUTORIALS ========= * The RIPE NCC IP Request Tutorial, given by the RIPE NCC staff, was presented. It explained address space assignment and allocation procedures in the RIPE NCC region: http://www.ripe.net/ripe/meetings/archive/ripe-44/tutorials/ * The NetFlow Services tutorial, given by Benoit Claise (Cisco Systems), on reviewing the design, configuration, tuning and troubleshooting of NetFlow versions was presented during the EOF: http://www.ripe.net/ripe/meetings/archive/ripe-44/presentations/ripe44-eof-netflow.pdf * The BGP Troubleshooting tutorial, given by Philip Smith (Cisco Systems), covering common problems ISPs face when deploying BGP within their networks was also presented during the EOF: http://www.ripe.net/ripe/meetings/archive/ripe-44/presentations/ripe44-eof-bgp.pdf FIRST RIPE MEETING WEBCASTING ============================ The first RIPE Meeting webcast was held at RIPE 44. Recordings of sessions held in the Grand Ballroom have been archived and can be accessed at: http://www.ripe.net/ripe/meetings/archive/ripe-44/multicast.html HOSTMASTER CENTRE ================== The RIPE NCC Hostmaster Centre was open during RIPE 44. The centre continues to be a useful facility for the meeting attendees and will be provided at RIPE 45. RIPE 44 REFERENCE PAGE ====================== A complete list of RIPE 44 sessions, tutorials and presentations can be found at: http://www.ripe.net/ripe/meetings/archive/ripe-44/ RIPE 45 ====== RIPE 45 will be held in Barcelona, Spain from 12 to 16 May 2003. Information on RIPE 45 will be available at: http://www.ripe.net/ripe/meetings/ripe-45/ New LIRs please note: LIRs who signed up in 2002 are entitled to two (2) free tickets to attend RIPE 45. The tickets cover registration only and do not apply to the RIPE dinner, your travel or hotel accommodations. More information on the new LIR tickets can be found at: http://www.ripe.net/ripe/meetings/ripe-45/new-lir.html Or contact . END From ripe-lists at stop.me.uk Wed Feb 19 13:23:36 2003 From: ripe-lists at stop.me.uk (Denesh Bhabuta) Date: Wed, 19 Feb 2003 12:23:36 +0000 Subject: [lir-wg] RIPE 44 Meeting Report In-Reply-To: <5.1.1.6.0.20030219104937.02e66608@mailhost.ripe.net> References: <5.1.1.6.0.20030219104937.02e66608@mailhost.ripe.net> Message-ID: <20030219122336.GA6375@cyberstrider.net> On Wed, Feb 19, 2003 at 11:08:46AM +0100, Nick Hyrka wrote: > LIR > === > * Denesh Bhabuta (Aexiomus Limited) stepped down as co-chair of the LIR > Working Group. Gert D?ring (SpaceNet) and Andrea Borgato (I.Net S.p.A.) > were selected as new co-chairs. Apologies from me for not making my posting sooner regarding the reasons I stepped down. I had many people approach me at the last meeting asking me for reasons, so I decided to post on here too. I was elected as co-Chair of the LIR-WG two years ago at the Bologna RIPE meeting, and my aim was to get heavily involved on a platform of 'bringing RIPE and the NCC up to date with the industry and newer industry requirements for the benefit of the Internet community' Many thanks for supporting me in that election and throughout my term as co-Chair. The industry has gone through immense changes in these two years and in addition to playing catch up, I believe that the NCC have made great strides in the right direction. There is still, IMHO, a long way to go, and I fully trust Hans Peter, Gert and Andrea in steering the Working Group and aiding the NCC through further changes. My own circumstances changed in the past two years and like many other organisations, my own companies started to feel the pinch of the downturn. Thus, for the latter part of last year and for the next 2-3 months I have been and will be spending time on restructuring my various businesses and as such I am unable to spend much time on other issues. To me, the priveledge of being elected as a co-Chair meant I had certain responsibilities - to the NCC and to the RIPE Community. By not being able to spend quality time on issues, I would not have been able to fulfill my role to it's full extent. I thus came to the decision back in December that I would not stand for re-election this time and also mentioned to Hans Peter during the RIPE meeting that I would not be accepting any nominations for me. I do hope to restand at some point in the future. Although I am no longer involved at the co-Chair level, I am more than happy to be contacted via email or directly at RIPE meetings (which I still plan to attend) regarding any advice/pointers. Once again, many thanks for your support and see you at the next RIPE meeting. Roll on Barcelona. Regards Denesh From schwalm at noris.net Wed Feb 26 13:52:25 2003 From: schwalm at noris.net (Gernot Schwalm) Date: Wed, 26 Feb 2003 13:52:25 +0100 Subject: [lir-wg] Assignment Procedures for multi-homed customers Message-ID: <20030226135225.A32202@noris.de> Hi, we have a customer who wants to be multihomed in the near future and therefore needs/wants his own AS. Will he get his own PA-Allocation then or do we have to request PI-Space for him? Thanks in advance, Gernot Schwalm -- noris network AG / Kilianstrasse 142 \ 90425 Nuernberg Tel. 0911-9352-0 / Fax 0911-9352-100 \ info at noris.net ~ From kurt_kayser at gmx.de Wed Feb 26 14:10:41 2003 From: kurt_kayser at gmx.de (Kurt Kayser) Date: Wed, 26 Feb 2003 14:10:41 +0100 Subject: [lir-wg] IXP networks routing In-Reply-To: <1046210539.81354.215.camel@monza.nolink.net> References: <1046184822.24049.11195.camel@w1-2-lev.fr.corp.ndsoftware.com> <20030225151157.GK3917@pasky.ji.cz> <20030225152035.GA1772@nic.fr> <1046210539.81354.215.camel@monza.nolink.net> Message-ID: <3E5CBCD1.6060600@gmx.de> Hi, as an IXP-Operator I would like to comment this in three ways: 1. Requesting an Address-space be it v4 or v6 for an IXP-Infrastructure and not making it globally reachable somehow misses the point. It should be clearly reachable - ideally through *all* connected peers of the infrastructure. (they certainly can decide on the security for these destinations) 2. Address-space differs from IXP to ISP substiantially. ISPs hand out IP-addresses to customers and IXPs assign single (or *very* few) addresses to ISPs. That means that address consumption and renewals are very rare. Even the default allocations from the IRRs for IXPs is - to my opinion - far too large. 3. Same with the members fee. Ok, I am speaking for a small IXP, but a RIPE membership cannot be afforded right now. There is in contradiction the need for 1 single AS-number and one small prefix the cost which is normally calculated for the untrained new LIR ISP, who needs training, hostmaster-help, etc. Why not add a special categoy for IXP demands. There is a small number of them (50 in Europe?) and basicall NO effort after giving them their numbers for work. Best regards, Kurt Kayser Lars Erik Gullerud wrote: > On Tue, 2003-02-25 at 16:20, Stephane Bortzmeyer wrote: > >>On Tue, Feb 25, 2003 at 04:11:57PM +0100, >> Petr Baudis wrote >> a message of 29 lines which said: >> >> >>>AFAIK they should not be globally routable and they are only for internal usage >>>of the exchange points. >> >>Very bad idea. >> >>1) When you traceroute through an exchange point, the IP addresses you >>get should be routable, for easier debugging. >> >>2) Path MTU discovery may depend on it. >> >>Having IXP addresses not globally routable is as wrong as having RFC >>1918 (or FECO::) addresses at an IXP. > > > No, very GOOD idea. > > We block all inbound route announcements of IXP prefixes we are > connected to on IPv4 for a very good reason, and I don't see what has > changed from IPv4 to IPv6 that should make our routing policy any > different for IPv6 IXP-space. > > Hint - a lot of networks don't use "next-hop-self" on their border > routers toward iBGP peers and instead carry a route for the IXP block in > their IGP so other BGP speakers have next-hop reachability. Some > networks, unfortunately, also do NOT make sure to filter said IXP blocks > properly. What do you think happens when suddenly a route for that IXP > block leaks in on some peering session (on a different router than the > one actually connected to the IXP of course), and eBGP has a lower > administrative distance (preference) than the IGP - which is usually the > default? Can you guess what happens to the traffic that should be going > to a next-hop from that IXP-block? Yes, I've seen this very effect on > several networks I've had the joy of troubleshooting, and could share > some interesting stories on that topic. > > As for your specific objections: > > 1) Why does this make for easier debugging? You get a perfectly valid > ICMP reply from a valid IP address that you should be able to resolve in > DNS without any problems as it is unique (global unicast). If you mean > you would like to use the actual IXP IP-address as a destination for a > traceroute, well - don't. You shouldn't need to anyway. And unless you > are one of the peers I am speaking to over said IXP, you have no valid > reason in my book to send any traffic to my border-router on that > IP-address, and I don't see why I should let you. Hey, services like > echo and chargen were once considered very useful debugging tools too - > that doesn't mean anyone would recommend having said services open to > the world nowadays. > > 2) How would lack of routability of this space break path MTU discovery? > Please show me where in RFC1191 or RFC1981 it says that you would need > to send any packets addressed directly to the IP who sent you a > "Datagram Too Big/Packet Too Big" ICMP message in either IPv4 or IPv6, > respectively, for pMTUd to work. > > /leg > > > -- +++ Kurt Kayser Consulting - ISP & Carrier Netzwerkdesign, Planung, Schulungen *** Heinrich-M?ller-Str. 1c, 90530 R?thenbach b.St. Wolfgang, Germany *** Tel: +49 (0) 9129 289315, Fax: +49 (0) 9129 289316, Mobil: +49 (0) 160 5810284 From kristofer at nh.is Wed Feb 26 14:15:33 2003 From: kristofer at nh.is (Kristofer Sigurdsson) Date: Wed, 26 Feb 2003 13:15:33 +0000 Subject: [lir-wg] Assignment Procedures for multi-homed customers In-Reply-To: <20030226135225.A32202@noris.de> References: <20030226135225.A32202@noris.de> Message-ID: <20030226131533.GA7901@pfy.rhi.hi.is> Hi, Gernot Schwalm, Wed, Feb 26, 2003 at 01:52:25PM +0100 : > Hi, > > we have a customer who wants to be multihomed in the near future and > therefore needs/wants his own AS. Will he get his own PA-Allocation then or > do we have to request PI-Space for him? There is nothing unusual about announcing PA address space, even if it's not yours (as long as the LIR in question permits it), so your customer should simply go ahead and request for an AS (well, only LIR's can request an AS, but there is nothing wrong with a LIR requesting one for a customer). The LIR would then make the assignment origin in the customer's AS. However, you might want to make your customer sign a legal contract to clearify this point, i.e. that the address space belongs to the LIR, not the customer, in case they want to switch to another upstream provider. -- Krist?fer Sigur?sson Neth?nnun ehf. From pim at bit.nl Wed Feb 26 14:17:30 2003 From: pim at bit.nl (Pim van Pelt) Date: Wed, 26 Feb 2003 14:17:30 +0100 Subject: [lir-wg] IXP networks routing In-Reply-To: <3E5CBCD1.6060600@gmx.de> References: <1046184822.24049.11195.camel@w1-2-lev.fr.corp.ndsoftware.com> <20030225151157.GK3917@pasky.ji.cz> <20030225152035.GA1772@nic.fr> <1046210539.81354.215.camel@monza.nolink.net> <3E5CBCD1.6060600@gmx.de> Message-ID: <20030226131730.GC6460@crow.bit.nl> On Wed, Feb 26, 2003 at 02:10:41PM +0100, Kurt Kayser wrote: | Hi, | | as an IXP-Operator I would like to comment this in three ways: Hoi Kurt, | 1. Requesting an Address-space be it v4 or v6 for an IXP-Infrastructure | and not making it globally reachable somehow misses the point. It should | be clearly reachable - ideally through *all* connected peers of the | infrastructure. | (they certainly can decide on the security for these destinations) You probably are using this /48 out of 2001:7f8::/32 with the wrong reasons. It should be used for peering meshes and not for services at your IXP, and therefor it should not have to be routable or globally visible. If you want PI space for your IXP to run services in, you can join the long list of people that would like to have PI space in IPv6, which is simply not possible at this point in time. | 2. Address-space differs from IXP to ISP substiantially. ISPs hand out | IP-addresses | to customers and IXPs assign single (or *very* few) addresses to ISPs. That | means | that address consumption and renewals are very rare. Even the default | allocations | from the IRRs for IXPs is - to my opinion - far too large. The standard allocation size as per common practice at this point is either /64 or /48. More types of sizes are being debated all the time, but to this day, no other sizes have been established. A /64 might be too small for IXPs with more than one peering mesh, so the next step up is /48. | 3. Same with the members fee. Ok, I am speaking for a small IXP, but a RIPE | membership | cannot be afforded right now. There is in contradiction the need for 1 | single AS-number | and one small prefix the cost which is normally calculated for the | untrained new LIR | ISP, who needs training, hostmaster-help, etc. Why not add a special | categoy for IXP | demands. There is a small number of them (50 in Europe?) and basicall NO | effort after | giving them their numbers for work. You cannot identify your IXP as a special pig in the race of pigs. Therefor, no exception should be made for you, or RIRs, or any other enterprise. What would happen if every enterprise started an IXP and claimed a right to their own PI space ? It would become a mess! To put it frank: go to an upstream and request a block of 'PA' from their space to run your services in, and let them aggregate your traffic. If you want independability, go to multiple upstreams. groet, Pim -- __________________ Met vriendelijke groet, /\ ___/ Pim van Pelt /- \ _/ Business Internet Trends BV PBVP1-RIPE /--- \/ __________________ From kurt_kayser at gmx.de Wed Feb 26 15:04:48 2003 From: kurt_kayser at gmx.de (Kurt Kayser) Date: Wed, 26 Feb 2003 15:04:48 +0100 Subject: [lir-wg] IXP networks routing In-Reply-To: <20030226131730.GC6460@crow.bit.nl> References: <1046184822.24049.11195.camel@w1-2-lev.fr.corp.ndsoftware.com> <20030225151157.GK3917@pasky.ji.cz> <20030225152035.GA1772@nic.fr> <1046210539.81354.215.camel@monza.nolink.net> <3E5CBCD1.6060600@gmx.de> <20030226131730.GC6460@crow.bit.nl> Message-ID: <3E5CC980.4010904@gmx.de> Hi Pim (and mailing-list observers, of course :), please see my inline comments. Pim van Pelt wrote: > On Wed, Feb 26, 2003 at 02:10:41PM +0100, Kurt Kayser wrote: > | 1. Requesting an Address-space be it v4 or v6 for an IXP-Infrastructure > | and not making it globally reachable somehow misses the point. It should > | be clearly reachable - ideally through *all* connected peers of the > | infrastructure. > | (they certainly can decide on the security for these destinations) > You probably are using this /48 out of 2001:7f8::/32 with the wrong reasons. > It should be used for peering meshes and not for services at your IXP, and > therefor it should not have to be routable or globally visible. We're currently only running v4 with PA-space, which is blocked by the LIR from whom we borrowed it. So w.r.t. v6, there are just link-local tests ongoing. > If you want PI space for your IXP to run services in, you can join the > long list of people that would like to have PI space in IPv6, which is > simply not possible at this point in time. Agreed, that would be the way to go for me as well. > | 2. Address-space differs from IXP to ISP substiantially. ISPs hand out > | IP-addresses > | to customers and IXPs assign single (or *very* few) addresses to ISPs. That > | means > | that address consumption and renewals are very rare. Even the default > | allocations > | from the IRRs for IXPs is - to my opinion - far too large. > The standard allocation size as per common practice at this point is either > /64 or /48. More types of sizes are being debated all the time, but to this > day, no other sizes have been established. A /64 might be too small for > IXPs with more than one peering mesh, so the next step up is /48. I'm again referring currently more to v4, since there are /19s or /20s default for new LIRs. > | 3. Same with the members fee. Ok, I am speaking for a small IXP, but a RIPE > | membership > | cannot be afforded right now. There is in contradiction the need for 1 > | single AS-number > | and one small prefix the cost which is normally calculated for the > | untrained new LIR > | ISP, who needs training, hostmaster-help, etc. Why not add a special > | categoy for IXP > | demands. There is a small number of them (50 in Europe?) and basicall NO > | effort after > | giving them their numbers for work. > You cannot identify your IXP as a special pig in the race of pigs. Therefor, > no exception should be made for you, or RIRs, or any other enterprise. What > would happen if every enterprise started an IXP and claimed a right to their > own PI space ? It would become a mess! I do not consider myself a pig, so please let's keep this discussion on a serious level, ok? I sincerely believe in NEW IXP-members (not for free of course!), but with special conditions (no support, just one AS and one prefix) for the IXP-setup. I also believe in the RIPE-NCC to be able to distinguish between enterprises that might request a status of an IXP. It all depends of the policy and conditions. > To put it frank: go to an upstream and request a block of 'PA' from their > space to run your services in, and let them aggregate your traffic. If you > want independability, go to multiple upstreams. First part has happened so far, but traffic for the network is a problem (basically who pays the upstream-ISP for the traffic) and connectivity is just not there. So it's a very bad hack for local connectivity, which could be greatly improved, if there are mechanisms in place that would allow this. .kurt -- +++ Kurt Kayser Consulting - ISP & Carrier Netzwerkdesign, Planung, Schulungen *** Heinrich-M?ller-Str. 1c, 90530 R?thenbach b.St. Wolfgang, Germany *** Tel: +49 (0) 9129 289315, Fax: +49 (0) 9129 289316, Mobil: +49 (0) 160 5810284 From wilson.mehringer at cablecom.ch Wed Feb 26 15:09:03 2003 From: wilson.mehringer at cablecom.ch (Wilson Mehringer) Date: Wed, 26 Feb 2003 15:09:03 +0100 Subject: [lir-wg] Assignment Procedures for multi-homed customers Message-ID: Hi Kristofer, I thought that a customer can NOT get an AS# from Ripe without first becoming a LIR!! Vise versa, he/she can become a LIR without necessarily getting an AS#. Am I missing out on something?? Wilson >>> Kristofer Sigurdsson 02/26/03 02:15pm >>> Hi, Gernot Schwalm, Wed, Feb 26, 2003 at 01:52:25PM +0100 : > Hi, > > we have a customer who wants to be multihomed in the near future and > therefore needs/wants his own AS. Will he get his own PA-Allocation then or > do we have to request PI-Space for him? There is nothing unusual about announcing PA address space, even if it's not yours (as long as the LIR in question permits it), so your customer should simply go ahead and request for an AS (well, only LIR's can request an AS, but there is nothing wrong with a LIR requesting one for a customer). The LIR would then make the assignment origin in the customer's AS. However, you might want to make your customer sign a legal contract to clearify this point, i.e. that the address space belongs to the LIR, not the customer, in case they want to switch to another upstream provider. -- Krist?fer Sigur?sson Neth?nnun ehf. From av at nethead.de Wed Feb 26 15:42:45 2003 From: av at nethead.de (Arnd Vehling) Date: Wed, 26 Feb 2003 15:42:45 +0100 Subject: [lir-wg] Assignment Procedures for multi-homed customers References: Message-ID: <3E5CD265.F4B7699F@nethead.de> HI; Wilson Mehringer wrote: > I thought that a customer can NOT get an AS# from Ripe without first becoming a LIR!! Wrong, any customer of a LIR can apply via the LIR for an ASN Number as long as he meets the requirements. > Vise versa, he/she can become a LIR without necessarily getting an AS#. Right. best regards, Arnd -- NetHead Network Design and Security Arnd Vehling av at nethead.De Gummersbacherstr. 27 Phone: +49 221 8809210 50679 K?ln Fax : +49 221 8809212 From gert at space.net Wed Feb 26 17:31:03 2003 From: gert at space.net (Gert Doering) Date: Wed, 26 Feb 2003 17:31:03 +0100 Subject: [lir-wg] Assignment Procedures for multi-homed customers In-Reply-To: ; from wilson.mehringer@cablecom.ch on Wed, Feb 26, 2003 at 03:09:03PM +0100 References: Message-ID: <20030226173103.H15927@Space.Net> Hi, On Wed, Feb 26, 2003 at 03:09:03PM +0100, Wilson Mehringer wrote: > I thought that a customer can NOT get an AS# from Ripe without first > becoming a LIR!! Wrong. Only a LIR can *request* an AS#, but the LIR can request the AS# for their customer. > Vise versa, he/she can become a LIR without necessarily getting an AS#. Yes. Being LIR doesn't necessarily require you to be multihomed, so no need to automatically assign an AS# Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 57147 (56285) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From kristofer at nh.is Wed Feb 26 18:44:50 2003 From: kristofer at nh.is (Kristofer Sigurdsson) Date: Wed, 26 Feb 2003 17:44:50 +0000 Subject: [lir-wg] Assignment Procedures for multi-homed customers In-Reply-To: References: Message-ID: <20030226174450.GB7901@pfy.rhi.hi.is> Hi, Wilson Mehringer, Wed, Feb 26, 2003 at 03:09:03PM +0100 : > > Hi Kristofer, > > I thought that a customer can NOT get an AS# from Ripe without first becoming a LIR!! > Vise versa, he/she can become a LIR without necessarily getting an AS#. > Am I missing out on something?? Only LIRs can request an AS, but they can request one for someone else. The only requirements for a new AS is that a) they have some address space to announce and b) they can specify a minimum of two existing AS's that the new one will peer with. Here's a quote from "Autonomous System (AS) Number Assignment Policies and Procedures" (http://www.ripe.net/ripe/docs/asn-assignment.html): "The RIPE NCC assigns AS Numbers for Autonomous Systems located in the RIPE NCC service region and only accepts requests for AS Numbers from LIRs. LIRs may request AS Numbers on behalf of other organisations. ". You're right about the latter part, though. A LIR does not have to have an AS. It is quite common for LIRs to have their own AS, but by no means necessery. An AS is simply a technical requirement to be able to peer with other entities, in order to exchange dynamic routing tables. On the other hand, being a LIR is a far bigger thing, a Local Internet Registry. LIR's are typically providers who can request allocations from RIPE and then furthermore assign IP numbers to their customers, and well...be an Internet Registry. :-) -- Krist?fer Sigur?sson Neth?nnun ehf. From randy at psg.com Wed Feb 26 19:38:36 2003 From: randy at psg.com (Randy Bush) Date: Thu, 27 Feb 2003 02:38:36 +0800 Subject: [lir-wg] IXP networks routing References: <1046184822.24049.11195.camel@w1-2-lev.fr.corp.ndsoftware.com> <20030225151157.GK3917@pasky.ji.cz> <20030225152035.GA1772@nic.fr> <1046210539.81354.215.camel@monza.nolink.net> <3E5CBCD1.6060600@gmx.de> Message-ID: > as an IXP-Operator I would like to comment this in three ways: > > 1. Requesting an Address-space be it v4 or v6 for an IXP-Infrastructure > and not making it globally reachable somehow misses the point. It should > be clearly reachable - ideally through *all* connected peers of the > infrastructure. (they certainly can decide on the security for these > destinations) > ... randy From kurtis at kurtis.pp.se Thu Feb 27 10:13:57 2003 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Thu, 27 Feb 2003 10:13:57 +0100 Subject: [lir-wg] IXP networks routing In-Reply-To: <20030226131730.GC6460@crow.bit.nl> Message-ID: > The standard allocation size as per common practice at this point is > either > /64 or /48. More types of sizes are being debated all the time, but to > this > day, no other sizes have been established. A /64 might be too small for > IXPs with more than one peering mesh, so the next step up is /48. Per the previous thread here a /64 would be for a very small IX.... - kurtis -