- address-policy-wg - mailman.ripe.net

RIPE 52 Report available
by Paul Rendek 31 May '06

31 May '06

[Apologies for duplicate e-mails] Dear Colleagues, The RIPE 52 Meeting Report is now online at: http://www.ripe.net/ripe/meetings/ripe-52/report.html Regards, Paul Rendek Head of Member Services & Communications RIPE NCC

1 0

2005-01 Policy Proposal Withdrawn (HD-ratio Proposal)
by Filiz Yilmaz 30 May '06

30 May '06

PDP Number: 2005-01 HD-ratio Proposal Dear Colleagues The proposal 2005-01 has been withdrawn. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/archive/ Regards Filiz Yilmaz RIPE NCC Policy Development Officer

1 0

Mike Simkins is out of the office.
by Mike.Simkins＠sungard.com 29 May '06

29 May '06

I will be out of the office starting 26/05/2006 and will not return until 30/05/2006. I will respond to your message when I return. If you have an urgent issue - please call the IOC at 1-800-41-1181 where someone will be able to help you immediately

1 0

Contact e-mail Address Requirements at RIPE et al.
by Jeff Scribner 27 May '06

27 May '06

BlankGentlemen: >From time to time our security department has had to expend considerable effort to find working e-mail addresses for organizations responsible for IP addresses controlled by RIPE. In some instances, no working address could be found or a time consuming visit to a web site form was required for contact. Every organization controlling an IP address with a listing at RIPE should be required to list at least one working contact e-mail address where notifications of abuse emanating from that IP address can be sent. RIPE should be allocated money and personnel to enforce this rule. In addition, all persons and organizations assigned an IP address should be required to take vigorous action to prevent abusive messages from originating at that IP address. RIPE should be allocated money and personnel to enforce this rule and, if necessary, to shut down any IP address or group of addresses having excessive instances of abuse. This policy should also be followed by ARIN, APNIC, AFRNIC, LACNIC, etc. and would result in less spam and abuse and more rapid correction thereof. Regards, Jeffrey L. Scribner ASI Enterprises, Inc. 9660 Falls of the Neuse Road Suite 138-123 Raleigh, North Carolina 27615-2473 Telephone 919-844-6404 Cell 919-264-6404 Fax Server 501-643-9064 jscribner(a)asienterprises.com http://www.asienterprises.com

1 0

Draft Minutes: RIPE 52 Address Policy WG session
by Catherine Carr 25 May '06

25 May '06

Dear Colleagues Draft Minutes from the Address Policy Working Group session at RIPE 52 can be found at: http://www.ripe.net/ripe/wg/address-policy/r52-minutes.html Please check the minutes for errors or omissions. Comments and corrections can be sent directly to this list or to one of the WG chairs personally. Additionally, archives of the webcast can be found at: mms://webcast.ripe.net/ripe-52/ap.wmv http://www.ripe.net/ripe/meetings/ripe-52/webcast-files/ap.wmv http://www.ripe.net/ripe/meetings/ripe-52/podcasts/ap.mp3 There is also a copy of the Jabber/IRC session available at: http://www.ripe.net/ripe/meetings/ripe-52/transcripts/ap.txt Kind regards, -- Catherine Carr RIPE NCC IP Resource Analyst

1 0

41/8 announcement
by Ernest B. M 22 May '06

22 May '06

Apologies for duplicates] Dear Colleagues, Please note that AfriNIC received the IPv4 address range 41.0.0.0/8 from the IANA in April 2005. You may wish to adjust any filters you have in place accordingly. Reachability tests can be conducted with 41.223.252.1 as a target IP address. Kind Regards, Ernest, AfriNIC.

2 1

Proposal 2005-2 comment
by John L Crain 13 May '06

13 May '06

Just one brief comment in that section A.2. needs to be updated. There are currently five RIR's since the addition of AfriNIC. Here is the section: A.2. Policy Harmonisation Three out of four RIRs (APNIC, ARIN and LACNIC) have policies allowing assignments to network critical infrastructure. All three policies classify TLD name servers as critical infrastructure. Extracts from these policies can be found in Appendices I through III. John

1 0

Just say *NO* to PI space -- or how to make it less destructive
by Pekka Savola 12 May '06

12 May '06

Hi, I don't support PI space to end-sites. We have to get rid of the notion that a random end-site has any business whatsoever in mucking with the global routing tables, either by making it much larger than need be or by polluting it with needless dynamicity. Example of the latter: deploying inbound traffic engineering adjustment solutions which result in thousands of daily flaps in the advertisements, as shown by Huston's analysis. We have way too much trouble with clueless ISPs to also add (or continue to add) end-sites to the mix... .... Now, from practical point of view, it seems there is strong "need" for PI, and it might be a PI policy of some kind might actually get through. If so, the policy should be such that it minimizes the bad effects of PI and encourages people to use other solutions if those are viable for them (unfortunately, the only way to achieve that appears to be $$$$), in particular (in the rough order of importance): 1. Each assignment must be accompanied by a recurring fee (at least 1000-2000 USD/EUR a year, preferably 5000+). This is peanuts (compared to other costs) to anyone who actually needs this multihoming solution. However, this ensures at least some minimum usage barrier ("those who don't really need this can use different multihoming solutions"), and recovery of the resources back to RIR after the company has gone bankrupt or no longer needs the addresses. If you don't know where to put the extra money, donate it to ISOC or something. 2. one-size-fits-all assignments, period. You get a /48 or /32 (I don't have much preference here), but you must not be able to justify for larger space. This is to avoid the organization from getting a larger block and chopping it into smaller pieces and polluting the global routing table with more specifics which would get past prefix length filters. 3. assignments from a separate address block, set aside for PI. To ease strict "assignment-size only" filtering of these blocks. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

38 110

The flexibility of IPv4 routing
by Florian Weimer 11 May '06

11 May '06

According to this article: <http://www.renesys.com/blog/2006/04/tracking_plane_flight_on_inter.shtml> Connexion uses BGP and the Internet routing table to implement IP mobility: | So how did they solve it? They assigned a /24 (256 globally visible IP | addresses) to each plane. They announce that network from the origin | site (in my case, Europe since I took off from Germany). When the | plane is between the two satellites and in view of each, it is | programmed to re-connect to the North American satellite. So traffic | is always getting to the ground the fastest it can, minimizing | latency. Certainly a cool hack, although I'm not sure if the leak of the /24s to the global routing table is intended. It's not necessary to minimize latency. Perhaps Connexion does not operate an intercontinental AS, though -- which would mean that two planes using different head stations could not communicate with each other at the IP layer. Anyway, I wish you guys could bring this kind of flexibility to the IPv6 world. 8-)

2 2

2005-12 New Draft Document Published (4-Byte AS Number Policy)
by Filiz Yilmaz 10 May '06

10 May '06

PDP Number: 2005-12 4-Byte AS Number Policy Dear Colleagues We have published a draft document for the proposal described in 2005-12. You can find the full proposal at: http://ripe.net/ripe/policies/proposals/2005-12.html and the draft document at: http://ripe.net/ripe/draft-documents/2005-12-draft.html We encourage you to read the draft document text and send any comments to address-policy-wg(a)ripe.net before 7 June 2006. Regards Filiz Yilmaz RIPE NCC Policy Development Officer

1 0