- lir-wg - mailman.ripe.net

New Mailing List: lirportal@ripe.net
by RIPE NCC Mailing List administration 19 Feb '03

19 Feb '03

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 <lirportal(a)ripe.net> 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

1 0

Sub-allocations, how and when?
by Kristofer Sigurdsson 18 Feb '03

18 Feb '03

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

3 6

New Document available: RIPE-269
by RIPE NCC Document Announcement Service 17 Feb '03

17 Feb '03

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

1 0

APNIC new block of addresses
by leo vegoda 14 Feb '03

14 Feb '03

FYI -- leo vegoda RIPE NCC Registration Services

1 0

APNIC new block of addresses
by John Tran 14 Feb '03

14 Feb '03

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 <Son(a)apnic.net> 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(a)apnic.net Please send Internet Resource Requests to <hostmaster(a)apnic.net> _____________________________________________________________________

1 0

Abstract of proposed Internet Draft for Best Current Practice (please comment)
by Dr. Jeffrey Race 13 Feb '03

13 Feb '03

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 <jrace[at]attglobal.net> Current draft version (4,000 words) available at <http://www.camblab.com/misc/univ_std.txt> 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===================

1 0

Re: NCC#2003021144 Network Abuse Issues
by RIPE NCC 10 Feb '03

10 Feb '03

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(a)skynet.be nic-hdl: JFS1-RIPE remarks: ---------------------------------------- remarks: Network problems to: noc(a)skynet.be remarks: Peering requests to: peering(a)skynet.be remarks: Abuse notifications to: abuse(a)skynet.be remarks: ---------------------------------------- mnt-by: SKYNETBE-MNT changed: jfs(a)skynet.be 19970707 changed: ripe(a)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, <Tim(a)ppronline.net> 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

1 0

Short Address Council update
by Hans Petter Holen 08 Feb '03

08 Feb '03

Dear wg, Just to give you a short update after the Address Council phone meeting last night. As last years AC chair Barbara Rosseman have now left the address council and started working for ICANN our communication channels towards ICANN should be even better than ever. (With both John Crain and Barbara among ICANN staff). Accoding to our internal procedures we had an election for AC chair and after due discussion and election Mark McFadden was elected as AC Chair and Hartmut Glaser and myself co-chairs. 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). Our long term goal is to establish an open and transparent process for this election, just as the ICANN board member elections of the past, but with the given time frames (the nomcom will start its initial work close to february 1st) the AC will elect a representative to the nomcom. Since I am on the AC to serve the RIPE NCC community and the best interest of the internet community, please feel free to give me or other AC-coord representatives input with respect to particular nominations as soon as possible. -hph

1 1

Creation of PI Policy Task Force
by leo vegoda 03 Feb '03

03 Feb '03

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

1 0

Spam on mailing list
by RIPE NCC WebMaster 30 Jan '03

30 Jan '03

Dear all, Apologies for forwarding some spam to the lir-wg mailing list. This was purely a human error on my account. Sorry for the inconvenience, Regards Jeroen Bet RIPE NCC Mailing list moderator ==================

1 0