- lir-wg - mailman.ripe.net

ANNOUNCEMENT: Tools BOF at RIPE 38
by RIPE NCC Staff 17 Jan '01

17 Jan '01

Dear Colleagues, The RIPE NCC is pleased to announce a 'Tools' BOF to be held at the RIPE 38 meeting in Amsterdam - please see: http://www.ripe.net/ripe/meetings/current/ripe-38/index.html This BOF session has been organised in order to discuss the tools we currently provide for our members, tools we plan to provide in the future and tools our members would like us to provide. 'Tools' refers to both software that the RIPE NCC makes available to its members to run themselves ( such as asused ) and software the RIPE NCC hosts that is used by the membership ( such as the Web page for checking European IP Address Space Request ( ripe-141 ) Forms and the Hostmaster mail robot ). Here is the Draft Agenda for this session: Proposed Agenda for the Tools BOF, RIPE 38 ------------------------------------------ Date: Tuesday 23rd January, 2001 Time: 14:00-15:30 Chair: Maldwyn Morris, Software Manager, RIPE NCC Location: St John I 0. Introduction 1. Existing tools 2. Tools in development 3. Proposals for tools I look forward to welcoming you to this BOF at the upcoming RIPE meeting. Cheers, Maldwyn Morris Software Manager RIPE NCC <swcontact(a)ripe.net>

1 0

None
by Adam Obszynski 16 Jan '01

16 Jan '01

Hello , I want to ask about PI assigned address space. The best example is my own one which good show us bad idea of assigning exactly size than user require.. Today we got very bad organisation in world BGP table.. a lot of bad aggregated prefixes etc.. so carrier providers from day to day 8-) move filter mask to right... now ie. Sprint: http://www.sprint.net/policy/bgp_filters.html: [...] Customers may announce routes as small as /26 for IP address blocks obtained through Sprint. Announcements for blocks obtained from other providers are limited to a /24 or smaller mask (/23, /22 etc.). This applies only to Sprint customers; peers are bound by a much stricter prefix policy. [...] so if RIPE will assing PI requests addresses exactly as written in ripe-141 from we give our clients big chance that they will be filtered. The of course aware about it .. but.. when we have /24 we got 70% chance to filtered with.... ie. /26 we got 40% and less.. so it can effect in one bad situation.. ripe forms written for PI assign policy and requests of /24 or smaller for route security and out customers become unhappy... IMHO one way is change our LAW to be good for mass not for goverment only 8-) so i please you to made some updates and assign PI depend on actually known filtered size in carrier networks... in europe and whole world PS: sorry for my bad english and grammar 8-| here is some sentences from ripe-127 8-) thank you! [bof] [...] Document: ripe-127 Assignment Policies [...] ments etc.. This also implies that assigning PI space prefixes longer than 24 bits is perfectly acceptable if the request does not merit 8 bits of address space to be assigned. [...] Detailed Recommendations [...] Assignment of this address space is valid as long as the criteria for the original assignment are still met. However, assignment of address space does NOT imply that this address space will be ROUTABLE ON ANY PART OF THE INTERNET. It is ____________________________________________________ ripe-127.txt Page 7 [eof] -- Regards, Adam Obszyński ATM Inc. +48-22-5156418

1 0

LIR-ALLOCATED revisited
by James Aldridge 15 Jan '01

15 Jan '01

LIR and DB Working Groups (with apologies for duplicate email), Discussed at RIPE-34 but with little subsequent action, I would like to repropose the addition of LIR-ALLOCATED as a valid status value for inetnum objects in the RIPE database. Attached is a slightly revised version of the document ("troff -ms" source version available on request) I last posted a year ago as a result of LIR-WG Action LIR-34.8. The suggestion then was that this could be massaged into a RIPE document (I think dfk volunteered!) to update ripe-185 (European Internet Registry Policies and Procedures) and that support for the new value be added to the database (and NCC tools as necessary). Regards, James -- Senior Network Engineer, IP Archictecture Group, KPNQwest Singel 540, 1017 AZ Amsterdam, NL ----------cut here---------- "Status: LIR-ALLOCATED" Considered Useful James Aldridge ----- -------- This document proposes a new value for the status field of the inetnum object in the RIPE database in addition to those listed in sections 3.4.2 (PA vs PI space) and 4.4 (Allocation Registration) of the "European Internet Registry Policies and Procedures" document ripe-185. For various reasons large registries often need to distribute their allocated address space between various parts of their organisation (for example we have separate national operations in 20 or so countries obtaining address space through the eu.eunet registry). In these situations it makes sense to document this redistribution in the RIPE database but there is currently no way to do this without throwing up errors in the RIPE NCC's auditing procedures or by removing flexibility and adding more work to the already busy NCC hostmasters by having each local operation treated as having their own allocation. Previously the RIPE database software allowed anyone to register an object with a status value of "ALLOCATED" but this was abused by people who didn't know what they were doing and so this is no longer possible and all non-NCC registered inetnum objects must now have the status of "ASSIGNED". However, having multiple levels of assignments in the RIPE database causes error reports from the NCC's auditing processes which now see anything under the higher- lever sub-allocation as being a duplicate (or overlapping) assignment which makes finding "real" problem assignments difficult or impossible. By allowing a local IR to register an inetnum object with a new status value of "LIR-ALLOCATED" it becomes possible to differentiate between a higher level sub-allocation ("status: LIR-ALLOCATED") and a final assignment by a LIR ("status: ASSIGNED"). By allowing this registration of intermediate objects it would also be possible to restrict changes to lower-level objects differently in different blocks of addresses within the LIR's allocation by setting different "mnt-lower" values without having to open the whole allocated block up for changes by anyone who might have a valid reason for updating a particular (range of) inetnum object(s). -2- An example may help to explain things at this point: inetnum: 10.1.0.0 - 10.1.255.255 netname: ZZ-REGY-19990916 descr: REGY Allocation country: EU ... status: ALLOCATED PA mnt-by: RIPE-NCC-HM-MNT ... source: RIPE inetnum: 10.1.0.0 - 10.1.31.255 netname: ZZZ-REGY-ALLOC descr: REGY - Local assignments in ZZZ country: ZZ ... status: LIR-ALLOCATED PA mnt-by: REGY-MNT mnt-lower: REGYZZ-MNT ... source: RIPE inetnum: 10.1.0.0 - 10.1.0.63 netname: CUSTOMER-XYZ-NET descr: Customer XYZ in ZZZ country: ZZ ... status: ASSIGNED PA mnt-by: REGYZZ-MNT ... source: RIPE Here the first inetnum object refers to the top-level allocation made to a local IR by the RIPE NCC and has the normal RIPE-NCC-HM-MNT maintainer field which restricts changes to the RIPE NCC Hostmasters only. The second inetnum object is registered by the central administrator of the local IR and the normal maintainer object for that administrator - REGY-MNT in this case. There is also a mnt- lower field permitting the national administrator to whom this sub-block is "allocated" to register end-user assignments. The final inetnum object here is a final assignment from the national organisation to a customer.

1 0

final version of the IPv6 joint policy meeting minutes
by David Kessens 11 Jan '01

11 Jan '01

Hi, Please see below for the final version of the minutes of the joint session of the ipv6 wg and lir wg regarding ipv6 allocation policies at RIPE37. The only changes made to the draft are typographical. I would like to thank Vesna for taking the minutes. Thanks, David K. --- IPv6 joint policy meeting RIPE ipv6-wg & lir-wg Wednesday, 13 September 2000 RIPE 37 Chair: David Kessens Agenda i Statement of current policy draft ii IAB/IESG recommendations iii Panel discussion iv AOB =i= Statement of current policy draft -- Joao Damas, RIPE NCC One year ago 3 Regional Internet Registries produced document that outlines allocation of IPv6 address space. * size of end user assignments * multihoming considerations * what is the meaning of 80% usage in ipv6? We need the clear picture of these issues to move forward. [chair: Bob Hinden tries to present the opinion of the IAB/IESG as closely as possible, but he is not the official spokesman of those bodies] = ii = IAB/IESG Recommendations on IPv6 Address Allocation - Bob Hinden URL: http://www/ripe/meetings/archive/ripe-37/presentations/ripe-ipv6-hinden/ We do not have real issue on service provider allocations size. Our recommendation is: /48 fixed boundary for all subscribers. This is consistent with responsible stewardship of the IPv6 Address space. Reasoning: - allocation policies influence the deployment; policies should make deployment easy, not slow - renumbering is (still) not painless or automatic Exceptions: - very large subscribers should get multiple /48:s, or /47 - transient nodes (roaming, dial-up) (/64) - explicitly no interest in subnetting Justifications for fixed boundary: - easy to change ISP:s (does not require restructuring of subnets) - straightforward renumbering - compatible with current multihoming proposals - allows easy growth of subscribers - reduces burden of ISP:s and RIR:s to judge customers' needs - no need for details of customers' networks - no need to judge rates of consumption - no scarcity of subscriber's space: no need for NAT - allows single reverse DNS zone (for all prefixes) Conservation: - does this waste IPv6 address space? No. - this distribution had better H ratio (RFC1715) then many others today - still, only one of the Format Prefixes (001) is going to be used; it leaves 85% of total IPv6 space for future usage and possible stricter policy Multihoming: IETF is still looking for input on this issue. = iii= Panel discussion: 1. Stephen Burley (UUNET) 2. Steve Deering (ipng) 3. Joao Damas (RIPE NCC) 4. Bob Hinden (ipng) 5. Randy Bush (ngtrans) 6. Juergen Rauschenbach (ipv6 forum) Q: What is criteria for ISP allocation? How much IPv6 address space does an ISP get? A: (Randy) This proposal is not changing other parts of policy. All will still get a /35. Normal slow start. Q: (Dave Pratt) Could you clarify what is meant by the 80% rule? A: (Bob) 80% of number of customers (ISP needs to allocate 80%, not the subscribers) Q: (Dave) I guess what I really mean is to do with ISP/LIR addressing hierarchy. It's difficult to build in hierarchy if aiming for 80% utilisation before more addresses will become available. Steve: H-ratio may be more appropriate rather than a percentage. A: I would suggest 20%. For example with 20% you can reserve addresses for 8 regions, and not worry if 6 of the 8 sites have small take up rates. A: (Steve) "you can start without hierarchy, and then add it later when the need arises". A: We could add hierarchy later, but maybe not really (same problems later as at start). We should be designing our networks correctly from the beginning. A: Discussion of possibility of H ratio's also being applied also to the LIR/ISP address range. Randy points out that with allocating /48s in a /35, the H ratio might be different, but the principle still holds, and there is a believe that there are enough addresses in IPv6 (also mentions in passing that the same believe existed in the early days of IPv4) Q: (Wilfried Woeber) Thank you for the clear document and clarification. Remaining issue: number of bits available for infrastructure. There should be a recommendation to start with the least significant bits. A: (Steve) We need an analysis regarding building an efficient hierarchy in the top 8 bits. If the community agrees on the /48 boundary, we may have to review the size of the initial allocation (/35 subTLA size). Joao explains why the /35 has been chosen. One gets 8192 NLA ranges, which can each by itself be structured and managed. This means it is actually more than if one gets a /19 in IPv4. Randy wonders why WW thinks one has a different problem in v6 than today in v4. The ISP he works for aggregates per pop, very strict and successful about it, but announce a /19 or shorter per pop. /35 feels as comfortable. Tries to understand if people don't feel comfortable with that and why. A: 13 bits (/35) is fine, it allows for aggregation per pop, the problem is the 80% usage rate. Randy: isn't the problem the percent, not matter how much it is? A: Problem is if the pops grow at different speed. A: Gert Doering, space net, Germany: We started with /19. By now, we have /16 and few /19:s, and they are not aggregated. We have resellers, and they have theirs. It fragments awfully. I am in favour of /56; or, I do not mind /48 if we can get bigger prefix (more bits) in the front. I do not need more space, but more possibility to build the hierarchy and aggregate. Joao: You have /29 contiguous block reserved to grow into. Gert: I don't see the need for slow start. There are so many /29s that the routing tables would explode before the /29s were exhausted. Bob suggests that might be solvable by rethinking the 80% usage rate (so that ISPs are not penalised for taking a long-term view from the start). Randy: He is in Frankfurt and Bon, and peers with Jurgen at both places, and announces same /35 at both places and Jurgen does not know to which one to send traffic. Chair: Want to refocus back on the recommendations of the draft. People seem to be OK with the /48. Let's move on. Need to come up with something to put in the multihoming section. For now, IPv4 method of multihoming should be used, as a short term recommendation. There is also the option to use multiple prefixes. The philosophy should be that addresses are cheap, so if someone wants to experiment with the multi address multihoming, let them and give them the addresses. Q: (Dave Pratt) Present PI space is authorised by RIPE and does NOT come from provider assigned space. I think this is a good rule (until better multihoming techniques are developed) that should be continued for IPv6. Alain Durand: Wants to emphasise that it's early in deployment and we need lots of feedback regarding whether multihoming techniques etc work. Be generous with /48s. Randy: From the proposal "if they need more address space, they get multiple /48:s". I would suggest /47. Steve: Looking to create a team to investigate how to measure usage. Maybe find a H ratio measure to apply instead of the 80% rule. Joao: the conservation is not the only issue here. WW: We want to keep the routing table small. (...) Randy: Small number of providers having TLA does not look good from the market point of view and it would create the small club who owns the Internet. A: The requirement is not only to aggregate well (shrinks the table), but also to find neutral mechanism of allocation; how to get into that club. Chair: Do you have enough info on /48 proposal? (yes) Chair: OK recommendation of this group is that /48 assignments should go ahead. This will be taken to ARIN and APNIC.

1 0

lir-wg open actions
by Hans Petter Holen 07 Jan '01

07 Jan '01

35.1 Chair Publish policy document 35 pres 35.2 Chair publish election procedure 35 pres 35.4 NCC PGP Key exchange procedure RIPE38 35.5 NCC Implement PGP for hm RIPE38 36.5 Chair Assignment window applied on infrastructure 36.6 AP Collect arbitrators Started 36.7 NCC Keep lir-wg updated on pre RIR address space changes Ntr ? 38.1 WG Further discuss restoring the transparency 38.2 NCC Incorporate IESG/IAB proposal into IPv6 policy 38.2 M17 Work with the RIPE NCC to implement suggestions 38.3 WG Nominate candidates for AC election 38.4 Rob Perform election of AC candidate at RIPE 38 Plenary

1 1

Fw: RFC 3021 on 31-Bit Prefixes on IPv4 Links
by Hans Petter Holen 03 Jan '01

03 Jan '01

FYI. ----- Original Message ----- From: "RFC Editor" <rfc-ed(a)ISI.EDU> To: <IETF-Announce: ;> Cc: <rfc-ed(a)ISI.EDU> Sent: Monday, December 18, 2000 7:31 PM Subject: RFC 3021 on 31-Bit Prefixes on IPv4 Links > > A new Request for Comments is now available in online RFC libraries. > > > RFC 3021 > > Title: Using 31-Bit Prefixes on IPv4 Point-to-Point Links > Author(s): A. Retana, R. White, V. Fuller, D. McPherson > Status: Standards Track > Date: December 2000 > Mailbox: aretana(a)cisco.com, riw(a)cisco.com, > vaf(a)valinor.barrnet.net, danny(a)ambernetworks.com > Pages: 10 > Characters: 19771 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-retana-31bits-03.txt > > URL: ftp://ftp.isi.edu/in-notes/rfc3021.txt > > > With ever-increasing pressure to conserve IP address space on the > Internet, it makes sense to consider where relatively minor changes > can be made to fielded practice to improve numbering efficiency. One > such change, proposed by this document, is to halve the amount of > address space assigned to point-to-point links (common throughout the > Internet infrastructure) by allowing the use of 31-bit subnet masks > in a very limited way. > > This is now a Proposed Standard Protocol. > > This document specifies an Internet standards track protocol for > the Internet community, and requests discussion and suggestions > for improvements. Please refer to the current edition of the > "Internet Official Protocol Standards" (STD 1) for the > standardization state and status of this protocol. Distribution > of this memo is unlimited. > > This announcement is sent to the IETF list and the RFC-DIST list. > Requests to be added to or deleted from the IETF distribution list > should be sent to IETF-REQUEST(a)IETF.ORG. Requests to be > added to or deleted from the RFC-DIST distribution list should > be sent to RFC-DIST-REQUEST(a)RFC-EDITOR.ORG. > > Details on obtaining RFCs via FTP or EMAIL may be obtained by sending > an EMAIL message to rfc-info(a)RFC-EDITOR.ORG with the message body > help: ways_to_get_rfcs. For example: > > To: rfc-info(a)RFC-EDITOR.ORG > Subject: getting rfcs > > help: ways_to_get_rfcs > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to RFC-Manager(a)RFC-EDITOR.ORG. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution.echo > Submissions for Requests for Comments should be sent to > RFC-EDITOR(a)RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC > Authors, for further information. > > > Joyce K. Reynolds and Sandy Ginoza > USC/Information Sciences Institute > > ... > > Below is the data which will enable a MIME compliant Mail Reader > implementation to automatically retrieve the ASCII version > of the RFCs. >

1 0

IPv6 joint policy meeting minutes
by David Kessens 23 Dec '00

23 Dec '00

Hi, Please see below for the minutes of the joint session of the ipv6 wg and lir wg regarding ipv6 allocation policies at RIPE37. The minutes will be declared final by January 5 if I don't receive any comments other than typographical errors and other minor corrections. I would like to thank Vesna for taking the minutes. Thanks, David K. --- IPv6 joint policy meeting RIPE ipv6-wg & lir-wg Wednesday, 13 September 2000 RIPE 37 Chair: David Kessens Agenda i Statement of current policy draft ii IAB/IESG recommendations iii Panel discussion iv AOB =i= Statement of current policy draft -- Joao Damas, RIPE NCC One year ago 3 Regional Internet Registries produced document that outlines allocation of IPv6 address space. * size of end user assignments * multihoming considerations * what is the meaning of 80% usage in ipv6? We need the clear picture of these issues to move forward. [chair: Bob Hinden tries to present the opinion of the IAB/IESG as closely as possible, but he is not the official spokesman of those bodies] = ii = IAB/IESG Recommendations on IPv6 Address Allocation - Bob Hinden URL: http://www/ripe/meetings/archive/ripe-37/presentations/ripe-ipv6-hinden/ We do not have real issue on service provider allocations size. Our recommendation is: /48 fixed boundary for all subscribers. This is consistent with responsible stewardship of the IPv6 Address space. Reasoning: - allocation policies influence the deployment; policies should make deployment easy, not slow - renumbering is (still) not painless or automatic Exceptions: - very large subscribers should get multiple /48:s, or /47 - transient nodes (roaming, dial-up) (/64) - explicitly no interest in subnetting Justifications for fixed boundary: - easy to change ISP:s (does not require restructuring of subnets) - straightforward renumbering - compatible with current multihoming proposals - allows easy growth of subscribers - reduces burden of ISP:s and RIR:s to judge customers' needs - no need for details of customers' networks - no need to judge rates of consumption - no scarcity of subscriber's space: no need for NAT - allows single reverse DNS zone (for all prefixes) Conservation: - does this waste IPv6 address space? No. - this distribution had better H ratio (RFC1715) then many others today - still, only one of the Format Prefixes (001) is going to be used; it leaves 85% of total IPv6 space for future usage and possible stricter policy Multihoming: IETF is still looking for input on this issue. = iii= Panel discussion: 1. Stephen Burley (UUNET) 2. Steve Deering (ipng) 3. Joao Damas (RIPE NCC) 4. Bob Hinden (ipng) 5. Randy Bush (ngtrans) 6. Juergen Rauschenbach (ipv6 forum) Q: What is criteria for ISP allocation? How much IPv6 address space does an ISP get? A: (Randy) This proposal is not changing other parts of policy. All will still get a /35. Normal slow start. Q: (Dave Pratt) Could you clarify what is meant by the 80% rule? A: (Bob) 80% of number of customers (ISP needs to allocate 80%, not the subscribers) Q: (Dave) I guess what I really mean is to do with ISP/LIR addressing hierarchy. It's difficult to build in hierarchy if aiming for 80% utilisation before more addresses will become available. Steve: H-ratio may be more appropriate rather than a percentage. A: I would suggest 20%. For example with 20% you can reserve addresses for 8 regions, and not worry if 6 of the 8 sites have small take up rates. A: (Steve) "you can start without hierarchy, and then add it later when the need arises". A: We could add hierarchy later, but maybe not really ***(same problems later as at start)***. We should be designing our networks correctly from the beginning. A: Discussion of possibility of H ratio's also being applied also to the LIR/ISP address range. Randy points out that with allocating /48s in a /35, the H ratio might be different, but the principle still holds, and there is a believe that there are enough addresses in IPv6 (also mentions in passing that the same believe existed in the early days of IPv4) Q: (Wilfred Woeber) Thank you for the clear document and clarification. Remaining issue: number of bits available for infrastructure. There should be a recommendation to start with the least significant bits. A: (Steve) We need an analysis regarding building an efficient hierarchy in the top 8 bits. If the community agrees on the /48 boundary, we may have to review the size of the initial allocation (/35 subTLA size). Joao explains why the /35 has been chosen. One gets 8192 NLA ranges, which can each by itself be structured and managed. This means it is actually more than if one gets a /19 in IPv4. Randy wonders why WW thinks one has a different problem in v than today in v4. The ISP he works for aggregates per pop, very strict and successful about it, but announce a /19 or shorter per pop. /35 feels as comfortable. Tries to understand if people don't feel comfortable with that and why. A: 13 bits (/35) is fine, it allows for aggregation per pop, the problem is the 80% usage rate. Randy: isn't the problem the percent, not matter how much it is? A: Problem is if the pops grow at different speed. A: Gert Doering, space net, Germany: We started with /19. by now, we have /16 and few /19:s, and they are not aggregated. We have resellers, and they have theirs. It fragments awfully. i am in favour of /56; or, i do not mind /48 if we can get bigger prefix (more bits) in the front. I do not need more space, but more possibility to build the hierarchy and aggregate. Joao: You have /29 contiguous block reserved to grow into. Gert: I don't see the need for slow start. There are a so many /29s the routing tables would explode before the /29s were exhausted. Bob suggests that might be solvable by rethinking the 80% usage rate (so that ISPs are not penalised for taking a long-term view from the start). Randy: He is in Frankfurt and Bon, and peers with Jurgen at both places, and announces same /35 at both places and Jurgen does not know to which one to send traffic. Chair: Want to refocus back on the recommendations of the draft. People seem to be OK with the /48. Let's move on. Need to come up with something to put in the multihoming section. For now, IPv4 method of multihoming should be used, as a short term recommendation. There is also the option to use multiple prefixes. The philosophy should be that addresses are cheap, so if someone wants to experiment with the multi address multihoming, let them and give them the addresses. Q: (Dave Pratt) Present PI space is authorised by RIPE and does NOT come from provider assigned space. I think this is a good rule *** (until better multihoming techniques are developed)*** that should be continued for IPv6. Alain Durand: Wants to emphasise that it's early in deployment and we need lots of feedback regarding whether multihoming techniques etc work. Be generous with /48s. Randy: From the proposal "if they need more address space, they get multiple /48:s". I would suggest /47. Steve: Looking to create a team to investigate how to measure usage. Maybe find a H ratio measure to apply instead of the 80% rule. Joao: the conservation is not the only issue here. WW: We want to keep the routing table small. (...) Randy: Small number of providers having TLA does not look good from the market point of view and it would create the small club who owns the Internet. A: The requirement is not only to aggregate well (shrinks the table), but also to find neutral mechanism of allocation; how to get into that club. Chair: Do you have enough info on /48 proposal? (yes) Chair: OK recommendations of this group are that /48 assignments are to go ahead. This will be taken to ARIN and APNIC.

1 0

RIPE Whois RPSL Migration
by RIPE NCC 21 Dec '00

21 Dec '00

[ Apologies for duplicate mails ] RIPE Whois RPSL Migration The RIPE Database re-implementation project is nearing completion. A key feature of the new database is the implementation of RPSL, to replace the old RIPE-181 standard. RPSL is similar, but not identical, to RIPE-181. The RIPE NCC expects that many programs that use the RIPE Whois database will continue to operate properly without modification. However, some programs may have problems parsing the RPSL format, or be confused by differences in behaviour. We would like to ensure that the transition to RPSL is as easy as possible. Therefore, we are working with the RIPE community to provide resources you can use to check any programs or scripts that you have that use the RIPE Whois database. Please visit our Migration page for further information: http://www.ripe.net/ripencc/pub-services/db/rpsl/index.html This page will be updated regularly with the latest information. We will provide additional tools and information as they become available. The actual timeline of when the RPSL server will replace the existing RIPE-181 server will be decided at the RIPE-38 meeting. If you want input on when the change will occur, then you should either attend this meeting or post your comments on the RIPE DB mailing list. http://www.ripe.net/ripe/meetings/current/ripe-38/index.html http://www.ripe.net/ripe/wg/db/index.html Regards, The RIPE Database Group. RIPE NCC

1 0

Reaseon for AS&PI
by Jevgenijs Vaikulis 15 Dec '00

15 Dec '00

Hello, Before writing request to RIPE for new AS and PI i would like to ask Your advice. The main reason for new AS(and PI) - security. We provide some services for local (national, like *.lv) users only (like irc). Firewall dosnt helps, when attacker send a ton of flood our international channel going down. With a AS ill anounce this AS only for national providers. So, is it reason for gettin A&PI? If someone have expirience with such problem, i`ll be very grateful for advice. P.S. Sorry for my poor english. ----------------------------------------------------------------- Jevgenijs Vaikulis(EV298-RIPE) +371 7777723 DELFI Internet +371 7777777 Elijas 17, Riga, Latvia http://internet.delfi.lv -----------------------------------------------------------------

2 1

Allocations for "always-on" ISPs
by Bruno Ciscato 14 Dec '00

14 Dec '00

Hi! With the advent of technologies like ADSL and Ethernet to the home, several new ISP in Europe are starting to offer "always on" Internet access. The allocation strategies vary, if they give a subnet to each household this is usually a /29, if they group more than one household in each subnet the average IPv4 address consumption by each household can be a little less. In any case they need a lot of addresses, i.e. a few millions. Can someone help me to see if what I think it would happen is correct? 1) they request address space to RIPE, with a nicely written documentation that clearly shows that they need millions of addresses 2) nonetheless they won't receive more than a /20 to begin with 3) when they have used more than 80% of this /20, and can prove it, another one will be assigned, most likely not contiguous 4) and so on and so forth, at a very fast pace, until they will have a very fragmented address space Is this correct ? Is it safe to assume that if they start using public address, where really needed, they will always receive new allocations if they can prove they need it until IPv4 addresses last ? Is there any way to reduce the address space fragmentation due to new non contiguous allocations ? Thanks bruno

15 27