- db-wg - mailman.ripe.net

RE: [db-wg] Draft minutes of DB-WG meeting RIPE 49 V2.0
by Titley, Nigel 17 Jan '05

17 Jan '05

MarcoH wrote: >> [AP49.3 RIPE NCC] To produce a document detailing the programme for >> introducing the changes. >> >> [AP49.4 RIPE NCC] To implement the abuse-email: attribute in the >> irt, person and role objects. > > Not that I want to push people, but is there any progress on this > topic or can anybody from the NCC give some indication on when this > is expected to get done ? I would be expecting both of these to be complete by next meeting, in the absence of any response to the contrary by the Ripe NCC. Nigel -- Nigel Titley Peering Coordinator, FLAG Telecom +44 20 8564 5812 ********************************************************************** This e-mail message is confidential and is intended only for the use of the individual or entity named above and contains information which is or may be confidential, non-public or legally privileged. Any dissemination or distribution of this message other than to its intended recipient is strictly prohibited. You should not copy it or use it for any purpose nor disclose the contents to any other person. If you have received this message in error, please notify us by email to postmaster(a)flagtelecom.com immediately and delete the original message and all copies from all locations in your computer systems. This e-mail has been swept by Mailsweeper TM for viruses. However, FLAG Telecom cannot accept liability for any damage which you may sustain as a result of software viruses. ********************************************************************** This message has been scanned for viruses by MailControl - www.mailcontrol.com

1 0

CVS and Bugzilla for RIPE Whois Server
by RIPE Database Manager 17 Jan '05

17 Jan '05

Dear Colleagues, The RIPE NCC has the source codes of the RIPE Whois Database software available under CVS (a version control system) and is publishing the bugs via Bugzilla (a bug-tracking system). By doing so, this allows anyone to: * have early access to new features of the RIPE Database Whois Server Software and * submit patches to the RIPE Database Whois Server Software. It also provides an easy and accessible method for submitting and tracking bugs and enhancement requests. To accommodate this feature, a web interface is available to browse the source codes at: http://www.ripe.net/cgi-bin/cvsweb.cgi/whoisserver/ while you can submit and track bugs at: http://www.ripe.net/bugzilla/. Stable Source and Binary Releases are available at: ftp://ftp.ripe.net/ripe/dbase/software/. Getting the source codes: You should type the following commands to check out the latest source code under CVS: cvs -d :pserver:anonymous@cvs.ripe.net:/cvsroot login [ No password, so just press [ENTER] on password prompt ] cvs -d :pserver:anonymous@cvs.ripe.net:/cvsroot co whoisserver These commands apply to the command line version of the CVS client software. A directory of CVS clients is available at: http://dmoz.org/Computers/Software/Configuration_Management/Tools/Concurren… Any suggestions about the system can be directed to ripe-dbm(a)ripe.net . Best Regards, Related Links: More information about CVS is available at: http://www.gnu.org/software/cvs/#TOCintroduction More information about Bugzilla is available at: http://www.bugzilla.org/docs/ -- Can Bican RIPE NCC Software Engineering Department

1 0

whois_rip feature request, multiple inverse attribute queries needed
by Arnd Vehling 07 Jan '05

07 Jan '05

Hello, would it be possible to enhance the RDB query in a way that multiple inverse queries are possible?! I would like to be able to query objects which match a certain set of inverse attributes with only one whois-query. Right now i can only query one inverse attribute a time, which means i need to collect all objects which match one of the attributes and then sort out those who match both. This often results in very huge numbers of objects which i need to compare via a perl script. Would this enhancement be reasonable?! best regards, Arnd -- NetHead Network Design and Security Arnd Vehling av(a)nethead.De Gummersbacherstr. 27 Phone: +49 221 8809210 50679 Cologne, Germany Fax : +49 221 8809212

2 1

RIPE Whois Database maintenance
by Engin Gunduz 28 Dec '04

28 Dec '04

Dear Colleagues Apologies for any duplicate mails On Wednesday, 29 December 2004, we will perform maintenance on the RIPE Whois Database. After this, the RIPE Whois Database will support RPSLng. You can find more information about this at: http://www.ripe.net/db/news/rpslng-211204.html We plan to start the maintenance at 15:00 Amsterdam time (14:00 UTC). It will take around four hours. During this time, there will be no interruption to Whois queries, however: - You will not be able to make any updates to the Whois Database using either webupdates or the LIR Portal, - We will process any e-mail updates, sent to auto-dbm(a)ripe.net, after we complete the maintenance work. We apologise for any inconvenience this work might cause. Best regards Engin Gunduz RIPE NCC Software Engineering Department

1 0

Announcement: Policy Development Process in RIPE
by Rob Blokzijl 21 Dec '04

21 Dec '04

To the RIPE Community, later today I will publish a draft document that describes the policy making process in RIPE. It is draft, so your input is requested in order to come to a generally accepted final document. Logistics: - deadline for comments on the first draft: 1 Februari 2005 - discussion takes place on ripe-list(a)ripe.net - if you are not subscribed to ripe-list(a)ripe.net yet, go to http://www.ripe.net/mailman/listinfo/ripe-list#subscribers - for any questions, don't hesitate to contact chair(a)ripe.net As always, apologies for receiving multiple copies of this announcement. Best regards, Rob Blokzijl RIPE Chairman

1 0

RPSLng in the RIPE Whois Database
by Shane Kerr 21 Dec '04

21 Dec '04

Dear Colleagues, Beginning Wednesday 29 December 2004, the RIPE Database will support RPSLng. RPSLng extends the Routing Policy Specification Language (RPSL) allowing description of IPv6 and multicast routing policies. It includes a new object type, ROUTE6, and new attributes, such as "mp-import:" and "mp-export:". RPSLng was submitted to the IETF to become an RFC. You can read the most recent draft at: http://www.radb.net/rpslng-08.html This change will not affect the current contents of the database. It is optional for any objects you maintain. The main differences for query users are as follows: - Currently a query for an IPv4 address or network may return INETNUM, ROUTE, and INET-RTR objects. A query for an IPv6 address or network can only return an INET6NUM object. After we put RPSLng into production, IPv6 queries will start to also return ROUTE6 and INET-RTR objects, if they are in the database. - Currently an inverse query (using the "-i" flag) for AUT-NUM objects may return ROUTE objects. After we put RPSLng into production, a query will return both ROUTE and ROUTE6 objects. If you want to limit your query, you can use the "-T" flag. For example, if you only want ROUTE objects returned to an inverse query, you can type: whois -h whois.ripe.net -T route -i origin AS3333 Please change your scripts if necessary. We will not move the contents of the RPSLng prototype Whois server to the RIPE Whois Database. You will have to create any objects that define your routing policy in the production RIPE Whois Database. You can update the RPSLng prototype Whois server until the start of January 2005. The query interface will be available until the end of January 2005. -- Shane Kerr Software Manager RIPE NCC

3 2

IRRToolSet maintenance moved from RIPE NCC to ISC
by Shane Kerr 17 Dec '04

17 Dec '04

Colleagues, We are happy to announce that the maintenance for the IRRToolSet has moved from the RIPE NCC to the Internet Systems Consortium (ISC). Starting now, ISC will support software development and maintenance of this suite. The new web page for this is: http://www.isc.org/sw/IRRToolSet/ The mailing list has been moved. The new address is <irrtoolset(a)isc.org>. E-mail will be forwarded from the existing mailing list (*). The RIPE NCC believes that ISC's software development model matches the IRRToolSet requirements, and that ISC will be a better home for the software. Operators and developers will have a set-up that is more typical to collaborative open source software, from a company that is experienced and focused on it. The RIPE NCC is grateful to ISC for agreeing to maintain this useful set of tools. We will continue to provide support for RIPE-specific portions and work with ISC in refining the software. -- Shane Kerr Software Manager RIPE NCC (*) When the mailing list forwarding began, Thursday 2004-12-16, filtering was removed. Shortly after the mailing list filtering policy was changed to "subscriber only". Apologies for the unwanted mail received during this period.

1 0

Re: [db-wg] Modifying the ACL for the whois server
by Nicolas Raux 06 Dec '04

06 Dec '04

when I try this set acl 127.0.0.1 deny=0 it seems ok (no error is returned) but I still can t query my local whois server here is what I get when I type : show acl ip maxprivate maxpublic maxdenials deny trustpass threshold maxconn 0.0.0.0/0 -1 -1 10 0 0 4 6 127.0.0.1/32 -1 -1 10 1 0 4 6 Found 2 nodes

2 1

Problems with ERX for 192.0.0.0/8
by leo vegoda 01 Dec '04

01 Dec '04

Dear Colleagues, An error in the software managing the ERX process for 192.0.0.0/8 resulted in the creation of INETNUM objects with incorrect contact information for registrations in this range. As a consequence, e-mail notifications were sent to incorrect contacts on 18 November. Errors made when registering the contact information in the database have now been corrected. Any user updates to these INETNUM objects or maintainers since 11 November have been undone. A new set of ERX notification e-mails will be sent to the relevant contacts and the schedule will be extended by two weeks. The completion date will now be 17 February 2005. We apologise for any inconvenience caused. Kind regards, -- leo vegoda Registration Services Manager RIPE NCC

1 0

Whois referrals changed source IP
by Robert Martin-Legene 18 Nov '04

18 Nov '04

For those of you (TLD's only?) who receives whois referrals from whois.ripe.net and thought they would always come from 193.0.0.0/24, it now seems that even though whois.ripe.net is in that range, the referrals can come from at least 193.0.4.152 (as it does right now). For us, we only allow the -V3.2.0,$IP option (stating the origin IP) if from an "NCC IP#". For all other IP## using that option we would give an error. Our last request from 193.0.0.0/24 was received Nov 17 11:16:46. Would the NCC be kind enough to officially inform of which range(s) the requests can come from? (I doubt it's the entire 193.0.0.0/21, which are server networks.) (And to think that it was actually Verisign who mailed us to let us know they had a problem using our whois server, I find kind of funny). -- Robert Martin-Legène IT security manager DK Hostmaster A/S

2 1

Alex Dempsey/Vodafone is out of the office.
by alex.dempsey＠vodafone.com 09 Nov '04

09 Nov '04

I will be out of the office starting 08/11/2004 and will not return until 22/11/2004. I will be out of the office starting 08/11/2004 and will not return until 22/11/2004. For any urgent queries, please call me on +353 87 6227222, otherwise I will respond to your message on my return. Regards, Alex Dempsey ****************************************************************************** The content of this e-mail may be confidential or legally privileged. If you are not the named addressee or the intended recipient please do not copy it or forward it to anyone. If you have received this email in error please destroy it and kindly notify the sender and postmaster.ie(a)vodafone.com. Email cannot be guaranteed to be secure or error-free, it is your responsibility to ensure that the message (including attachments) is safe and authorised for use in your environment. Vodafone Ireland Limited. Directors: Peter Bamford Chairman (UK), Pauline Best (UK), Paul Donovan Chief Executive (UK), Gerry Fahy, David Boorman (UK), David Smithwhite (UK), Patrick Teahon, Alfred Kane. Registered in Ireland at MountainView, Leopardstown, Dublin 18. Co Reg No.: 326967 VAT Reg No. IE6346967G ******************************************************************************

1 0

RIPE DB tertiary whois server
by Daniel Roesen 09 Nov '04

09 Nov '04

Hi, whatever this server is... can you please keep this one in production and not switch back to primary/secondary? :-) Wow, this one is really fast... Regards, Daniel -- CLUE-RIPE -- Jabber: dr(a)cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

3 3

RIPE-NCC-LOCKED-MNT
by Ulf Kieber 01 Nov '04

01 Nov '04

Re everybody, I accidentially stumbled into the following: kieber@rocky /home/wheel/kieber> whois -r -T inetnum 213.72.34.0/29 % This is the RIPE Whois secondary server. % The objects are in RPSL format. % % Rights restricted by copyright. % See http://www.ripe.net/db/copyright.html inetnum: 213.72.34.0 - 213.72.34.7 netname: RABUTLERCO27579SCH descr: RA Butler County Infant School country: GB admin-c: CL71-RIPE tech-c: CL71-RIPE status: ASSIGNED PA mnt-by: RIPE-NCC-LOCKED-MNT remarks: Maintainer RIPE-NCC-NONE-MNT removed and object remarks: LOCKED by the RIPE NCC due to remarks: deprecation of the NONE authentication scheme. remarks: Please visit the following URL to unlock this object remarks: http://www.ripe.net/db/none-deprecation-042004.html changed: cmorrison(a)rmplc.co.uk 20000803 changed: ripe-dbm(a)ripe.net 20040429 source: RIPE kieber@rocky /home/wheel/kieber> whois -r -T inetnum -l 213.72.34.0/29 % This is the RIPE Whois secondary server. % The objects are in RPSL format. % % Rights restricted by copyright. % See http://www.ripe.net/db/copyright.html inetnum: 213.72.0.0 - 213.72.255.255 org: ORG-RMp1-RIPE netname: UK-RESEARCHMACHINES-20000316 descr: Research Machines descr: PROVIDER Local Internet Registry country: GB admin-c: RMS4-RIPE tech-c: RMS4-RIPE status: ALLOCATED PA notify: registry(a)rmplc.co.uk mnt-by: RIPE-NCC-HM-MNT mnt-lower: RMIFL-MNT mnt-routes: RMIFL-MNT changed: hostmaster(a)ripe.net 20000316 changed: hostmaster(a)ripe.net 20011127 source: RIPE kieber@rocky /home/wheel/kieber> I suggest RIPE NCC changes all occurences of mnt-by: RIPE-NCC-LOCKED-MNT in objects with status: ASSIGNED PA to mnt-by: <the value of mnt-lower in the one level less specific inetnum> In the above mentioned case mnt-by: RIPE-NCC-LOCKED-MNT should be changed to mnt-by: RMIFL-MNT RIPE NCC should never have to lock ASSIGNED PA inetnums. -- Ulf Kieber email: ukieber(a)cogentco.com Sr. Network Engineer voice: +49-69-299896-21 C.C.D. Cogent Communications Deutschland GmbH fax : +49-69-299896-40 Optical Internet www : www.cogentco.com Brilliantly Fast. Elegantly Simple. AIM : ulfkieber

1 0

ccTLD data in RIPE DB?
by Ulf Kieber 26 Oct '04

26 Oct '04

Re, weren't ccTLD domain registries supposed to remove their stuff from the database? Do a "whois -r -T domain -i notify notify(a)nic.gm". Which ccTLDs are still holding their registry data in the RIPE DB anyway? -- Ulf Kieber email: ukieber(a)cogentco.com Sr. Network Engineer voice: +49-69-299896-21 C.C.D. Cogent Communications Deutschland GmbH fax : +49-69-299896-40 Optical Internet www : www.cogentco.com Brilliantly Fast. Elegantly Simple. AIM : ulfkieber

3 3

RPSLng database deployment?
by Bernhard Schmidt 20 Oct '04

20 Oct '04

Dear all, having missed the last RIPE meeting I'm unfortunately somewhat out of date regarding this, but could someone please enlighten me about the current plans for deployment of RPSLng in the regular RIPE database? I am using rpslng.ripe.net, but unfortunately almost noone else does. Running a network without any sustainable prefix authorization sucks quite hard, it is a real pain to have to contact your upstream by mail if you have a new prefix (besides other things). Are there any problems with RPSLng currently? Thanks Bernhard

6 6

Recent Database update changes
by Denis Walker 13 Oct '04

13 Oct '04

[ Apologies for duplicate messages ] Dear Colleagues, In preparation of a new release of the Whois software we have fixed several bugs and implemented some of the simple features asked for over the last few months for the update program, dbupdate. A brief description follows of the features implemented. 1) Change to the overall result of a mail update message. During the re-structuring of the dbupdate program we changed the way we report the overall result of a mail update. This caused some confusion and we have now returned to the behaviour of the previous version of dbupdate. To make this clear here are the outcomes we now report: A blank update message - FAILED: ANY object update failed - FAILED: Otherwise - SUCCESS: 2) Handling of keywords in the Subject: line of a mail update. Currently there are only two keywords used by dbupdate. These are NEW and HELP (HOWTO is also valid but taken to mean the same as HELP). NEW forces all objects found in the mail message to be treated as a creation request. Any object that already exists will result in an error. HELP returns help text. To use a keyword it has to be put in the Subject: line of the mail message, with NO other words present. If any other word is found for example Subject: NEW objects then none of the words are actioned as keywords and they are all reported in the acknowledgement reply as invalid keywords. In this context it is impossible for dbupdate to know if a word is a keyword. As many users often include their own reference in the Subject: line it means it is impossible for them to also use a keyword and they always get their references reported in the Warning messages af the acknowledgement. To overcome these problems we have introduced a KEYWORDS: tag. When this tag is found in a Subject: line all text up to and including this KEYWORDS: tag is ignored by dbupdate. Only what follows this tag is checked for valid keywords. The same rules apply as before. If a word is found after the KEYWORDS: tag that is not a valid keyword none of the words are actioned as keywords. In this case all the words following the KEYWORDS: tag are reported as invalid keywords in the acknowledgement reply. Adding the KEYWORDS: tag at the end of a Subject: line means that valid keywords can still be used with a users reference in the same line. By adding the KEYWORDS: tag at the end of the Subject: line with no keywords following it means that the users reference will not be reported as invalid keywords. The default behaviour is unaltered. A keyword can still be placed on a line with no other words and actioned. We could easily make another change, if users would prefer it, so that keywords will ONLY be accepted if they follow the KEYWORDS: tag. This would make the default behaviour ignore the whole Subject: line and not report any of it as errors if the KEYWORDS: tag is not found. This default behaviour may be more appropriate to the way the Subject: line is currently used in most cases. Please let us know if this is preferred. All keywords and the KEYWORDS: tag are case insensitive. 3) Differnce in notification messages We have been asked to highlight changes in the notification message between the old and new objects for a modification operation. This is particularly useful when "import:" and "export:" attributes are changed in large AUT-NUM objects. This has now been implemented as a selectable option. To request it the user includes the keyword DIFF. When this DIFF keyword is used each object in the notification message that is a modify operation will include a difference before the standard output of the old and new versions of the objects. So the output will have the difference listing followed by the old and new objects. For example, a new subject line may look like this Subject: changes to aut-num: as1234 KEYWORDS: DIFF The difference is the standard unix diff, but with one slight change. In our acknowledgement and notification messages we have used three dashes --- followed by a new line to signify the start of a section relating to an object. This is to make it easy to parse the output and find the start of each object in the message. Unfortunately diff also uses --- to seperate lines that have changed. So we have had to replace --- with === in the diff output. If the DIFF keyword is not used the output remains unchanged. Using a simple PERSON object as the example the new output is as follows: --- OBJECT BELOW MODIFIED: Differences in [person] TP10-DB-TEST 7c7,8 < notify: case040-1(a)ripe.net === > changed: dbtest(a)ripe.net 20040101 > notify: case040-2(a)ripe.net person: Test Person address: Singel 258 address: Amsterdam phone: +31 20 535 4444 nic-hdl: TP10-DB-TEST changed: dbtest(a)ripe.net 20020101 notify: case040-1(a)ripe.net source: DB-TEST REPLACED BY: person: Test Person address: Singel 258 address: Amsterdam phone: +31 20 535 4444 nic-hdl: TP10-DB-TEST changed: dbtest(a)ripe.net 20020101 changed: dbtest(a)ripe.net 20040101 notify: case040-2(a)ripe.net source: DB-TEST 4) Include person/role name in creation results. The last additional feature is to include the name of a PERSON or ROLE object in the acknowledgement output after a successful creation. Previously only the new nic-hdl was listed. For example, if two PERSON objects are created using AUTO- nic-hdls for Denis Walker and David Wilkinson the reply would only say DW23-RIPE and DW24-RIPE have been created. The user would then have to do a whois lookup to determine which was which. The reply now states: --- Create SUCCEEDED: [person] DW23-DB-TEST Denis Walker --- Create SUCCEEDED: [person] DW24-DB-TEST David Wilkinson Regards Denis Walker RIPE NCC Software Engineering Department.

7 6

Draft Minutes DB-WG session RIPE 49
by Titley, Nigel 08 Oct '04

08 Oct '04

Gentlefolk, Please find the first draft of the minutes of the DB-WG session at RIPE 49 Comments to the list, or direct to me. As usual, I'll publish these on the website in about a week's time. Best regards Nigel -- Nigel Titley Peering Coordinator, FLAG Telecom +44 20 7478 9579 ********************************************************************** This e-mail message is confidential and is intended only for the use of the individual or entity named above and contains information which is or may be confidential, non-public or legally privileged. Any dissemination or distribution of this message other than to its intended recipient is strictly prohibited. You should not copy it or use it for any purpose nor disclose the contents to any other person. If you have received this message in error, please notify us by email to postmaster(a)flagtelecom.com immediately and delete the original message and all copies from all locations in your computer systems. This e-mail has been swept by Mailsweeper TM for viruses. However, FLAG Telecom cannot accept liability for any damage which you may sustain as a result of software viruses. ********************************************************************** This message has been scanned for viruses by MailControl - www.mailcontrol.com

1 0

RE: [ipv6-wg@ripe.net] RPSLng database deployment?
by Tony Hain 07 Oct '04

07 Oct '04

Sorry, this was a reply to the wrong message. Tony > -----Original Message----- > From: Tony Hain [mailto:alh-ietf@tndh.net] > Sent: Wednesday, October 06, 2004 5:09 PM > To: 'Bernhard Schmidt'; 'db-wg(a)ripe.net' > Cc: 'ipv6-wg(a)ripe.net' > Subject: RE: [ipv6-wg(a)ripe.net] RPSLng database deployment? > > A few additional comments now that the text is cleaned up: > > The last sentence of 2.1 is out of context to the heading. The point it is > making really belongs in 2.2. It makes a nice lead-in sentence, and taking > the word 'these' out would probably fix the sentence to make sense as the > start of the next section. > > 2.2 ... ', and hence there is no specific security value in the NAT > function.' That should probably be a stand alone sentence with the 'NAT' > string replaced by 'address translation'. > > The perceived security comes from the lack of pre-established mapping > state. Dynamically establishing state in response to internal requests > prevents unexpected external connections to internal devices. > > ... the security policy is already likely to consist of multiple > components such as Firewalls, data-filters activity logging and intrusion > detection systems. Simplified forms of these for the less security aware > users could assist to make their private networks more secure. > -delete list- > > 2.4 ... they do prevent the external tracking and profiling of individual > host computers by means of their IP addresses. > -(2.3 just talked about how to track if one has access to the NAT, so this > one needs to be explicit about external)- > > ... which some enterprises believe is a useful ... > - replace 'enterprises' with 'network managers' - > > 2.5 ... unique and routable IPv4 address will continue increasing as > allocation policies tighten so that they become more difficult to obtain. > > 'This mechanism allows the simultaneous usage of certain IPv4 prefix for > various end-customers or end-systems. The overall benefit to the provider > is that fewer globally unique IPv4 addresses are required.' > - This is confusing unless the reader understands the need for stability > in IPv4 end system configurations. RE: how does simultaneous use of an > IPv4 address allow the ISP to use fewer addresses? It really doesn't. The > ISP will use as many addresses as it takes for independent instances of an > application. What NAT does in this situation is allow the IPv4 end systems > to have stable addresses that may overlap with other organizations, and > the ISP only needs as many public addresses as there are simultaneous > instances of a given app. - > > This type of local control of address resources allow a clean and > hierarchical addressing structure in the network that is not restricted by > the size of the publicly routed address pool. > > 2.6.1 ... larger (probably with less-administrative overhead) IPv4 address > range ... > > 2.6.2 'only have only' -->> 'have' > > 'For this type of private networks mainly RFC 1918 addressing is used > internally to reduce the needed amount of global routable prefixes, > because there no need for owned IPv4 prefixes by the enterprise and for > simplicity of the administrative overhead by the lack of a dedicated NOC.' > - I don't buy the argument to begin with. 'Lack of need' is bogus and we > shouldn't propagate it here because it will deflate the value of the IPv6 > argument later. We should put this in the context of a cost trade-off, > forfeiting some applications in favor of reduced access costs. How about: > Small networks typically deploy RFC 1918 addressing internally to limit > the explicit charges for publicly routable addresses. This approach also > has the advantage of avoiding the administrative overhead and dedicated > NOC associated with acquiring blocks of publicly routed address space. > > 2.6.3 ... 'due to the operational stateful operation' ... > - I think the first operational should go. > > 2.7 - drop the last sentence. For one those savings are only short term, > the long term costs of dealing with conflicting space will be higher. For > two, the point of the paper is to show how IPv6 makes things better, and > even the simplified renumbering will appear to be more expensive than > throwing a NAT at the problem. If you really want to say something about > cost, put it in the context of -perception-, -short term-, and -simple-. > - > > Why is 2.8 different from 2.2? > > I though you were going to align the numbering. > 2.1 -> 3.2 > 2.2 -> 3.3 > I think we should be able to summarize with a table like: > Function 2.x (IPv4) 3.x (IPv6) > x.1 Simple Gateway simple management DHCP-PD > x.2 Simple security stateful filter reflexive acl > x.3 tracking nat state table global uniqueness > x.4 topology hiding nat as virtual presence MIPv6 > x.5 addressing control RFC 1918 RFC 3177 & ULA > x.6 address allocation RFC 1918 RFC 3177 & ULA > x.7 renumbering RFC 1918 Multiple addr/interface > > Just trying to populate that table might clean up the overlaps and make it > clear what the point of each section should be. If we can delineate the > functions in crisp one or two word labels we can both make it simpler to > understand and more consistent between the versions. As it is even I am > having trouble figuring out if that table is correct. For example 3041 is > listed in 3.5, but it does absolutely nothing for topology hiding. Yes > privacy is one aspect of topology hiding, but end system privacy has > nothing to do with masking the network topology. > > 3.2 - why are renumbering & firewalls being discussed in the simple > gateway section? - > > 3.3 - the first two paragraphs are really summary material about ongoing > evolution in best practices and shouldn't be here. The last paragraph is > somewhat unrelated to the NAT->IPv6 effort. If it stays, comparable text > should be in the IPv4 section that makes it clear that open ports through > a nat will map to multiple machines, so configured state to run servers in > the private space are just as exposed as they would be without the nat. - > > 3.4 - all of this appears to be too much detail except the next to last > paragraph. The last paragraph is about IPv4 and is already stated there so > it should not be here. - > > 3.5 - End system privacy and network topology privacy are very separate > topics and shouldn't be in the same section. - > > - recommending that people use different subnet structures for internal & > external is just asking for trouble. Most 1st level ops have a hard enough > time with subnets anyway, so making this unnecessarily complex is just a > bad idea. 'Untraceable'/host-routes are a much better plan yet not even > mentioned here. - > > 3.6 - should be replaced with: > IPv6 provides for autonomy in local use addresses through ULAs (draft-???). > At the same time IPv6 simplifies simultaneous use of multiple addresses > per interface so that a NAT is not required (or even defined) between the > ULA and the public Internet. Nodes that need access to the public Internet > should have a global use address, and may simultaneously have a local use > ULA. Since the IPv6 address space for global use is not a scarce resource > like it is in IPv4, each network should be able to acquire a sufficient > quantity for its needs. While global IPv6 allocation policy is managed > through the Regional Internet Registries, it is expected that they will > continue with derivatives of RFC 3177 for the foreseeable future. > > 3.7.1 - seems to wander over several topics without a point. - > > 3.7.3 - if the ISP is allocating /128's then 3041 is not possible. > > 3.7.x - I still don't see the point in separating these out. There is > nothing that says an ISP can't or shouldn't use DHCP-PD for *every* > customer interface. The point is the length is flexible so any size > network fits. If there is to be a static mapping it should be done on the > back side of the DHCP server. The only time you might get into size > distinction here is if the customer is not part of the ISP aggregate and > is therefore injecting routes. The thing is injecting routes is not a > function of IPv4/NAT, so it really doesn't belong in this document. - > > 3.9 is really a subset of 3.3 > > I need to call it a day. I don't have a problem with the current draft > going out as a -00, but we should follow it with a fixed up -01 asap. > > Tony > > > > -----Original Message----- > > From: ipv6-wg-admin(a)ripe.net [mailto:ipv6-wg-admin@ripe.net] On Behalf > Of > > Bernhard Schmidt > > Sent: Wednesday, October 06, 2004 2:24 PM > > To: db-wg(a)ripe.net > > Cc: ipv6-wg(a)ripe.net > > Subject: [ipv6-wg(a)ripe.net] RPSLng database deployment? > > > > Dear all, > > > > having missed the last RIPE meeting I'm unfortunately somewhat out of > > date regarding this, but could someone please enlighten me about the > > current plans for deployment of RPSLng in the regular RIPE database? > > > > I am using rpslng.ripe.net, but unfortunately almost noone else does. > > Running a network without any sustainable prefix authorization sucks > > quite hard, it is a real pain to have to contact your upstream by mail > > if you have a new prefix (besides other things). > > > > Are there any problems with RPSLng currently? > > > > Thanks > > Bernhard

1 0

Announcement Routing Registry Training Courses
by RIPE NCC Training 04 Oct '04

04 Oct '04

Dear Colleagues, [apologies for duplicate postings] As a service to its members the RIPE NCC offers the "Routing Registry Training Course". The main objective of the "Routing Registry Training Course" is to familiarise the LIRs with the features of the Routing Registry, while introducing the relevant tools and services of the RIPE NCC. The course also offers practical exercises. OVERVIEW OF TOPICS COVERED IN THE COURSE: - Routing Registry as a part of the RIPE Whois Database and the Internet Routing Registry (IRR) - Specifying routing policies using (RPSL) Routing Policy Specification Language and the RtConfig tool - IRRToolSet - Routing Information Service (RIS) - Routing Registry Consistency Check Project Please note that this is an advanced course. It will: - NOT teach the basics of routing - NOT teach the basics of RIPE Database operations, - NOT describe how to receive Internet resources from the RIPE NCC - NOT describe how to operate a Local Internet Registry (LIR) The target audience of the course are technical staff of LIRs: e.g. network operators, engineers etc. This course is not intended for administrative or management staff (e.g. Hostmasters) . It is assumed that all attendees will be familiar with Border Gateway Protocol routing and with the RIPE Database (i.e. creating/modifying objects). This course is based on interactive exercises in a local network set-up. Please bring your laptops equipped with the following: - A working Ethernet card, - Three meters of Ethernet cable, - A secure connection client, - A web browser. Please be prepared to share your laptop (or at least allow another attendee to "look over your shoulder") if necessary. The Routing Registry Training Course is conducted in the English language and is free of charge, since it is covered by the membership fee. More information about the Routing Registry Training Course can be found at: http://www.ripe.net/training/rr/ REGISTRATION: You can register for a Routing Registry Training Course at the following URL: http://www.ripe.net/cgi-bin/trainingform.pl.cgi Or by completing the registration form at the end of this e-mail and replying to <training(a)ripe.net> . In order to register for a Routing Registry Training Course you must be an employee of an LIR and either: - be an LIR contact - be confirmed by an LIR contact LIR contacts are those employees of an LIR who are registered with RIPE NCC as authoritative contact persons. It is expected that most of those interested in the Routing Registry Training Course will not be an authoritative contact person for their LIR, and therefore will be, refused by the course registration "robot". In order to be admitted to the course, a confirmation e-mail must be sent to <training(a)ripe.net>. Please approach the LIR contacts from your organisation personally, since the identity of LIR contacts is confidential, and the RIPE NCC is unable to divulge contact persons for any given LIR. Kind Regards, Rumy Kanis Training Services Manager RIPE NCC **************************************************************************** COURSE DATES AND VENUES ======================== Date: Tuesday 23 November 2004 Time: 0900 - 1700 Location: Damascus,Syria AND: Date: Friday 14 January 2005 Time: 0900 - 1700 Location: Berlin, Germany AND: Date: Friday 18 March 2005 Time: 0900 - 1700 Location: Barcelona, Spain AND: Date: Friday 15 April 2005 Time: 0900 - 1700 Location: Amsterdam, The Netherlands AND: Date: Friday 22 April 2005 Time: 0900 - 1700 Location: St. Petersburg, Russian Federation ***************************************************************************** REGISTRATION FORM ================= %START PART 1 - Registration 1) Your name Enter First name, Last name in full e.g. John Doe Mary-Beth Walton # NAME [ ] 2) Your Registry ID (format: country-code.<name of registry>) # REG [ ] 3) Your e-mail address # EMAIL [ ] 4) Your NIC handle (optional) # NICHANDLE [ ] 5) The course you plan to attend (date and location) # COURSE [ ] %END

1 0

Fwd: [Apnic-announce] Privacy of customer assignment records - implementation update
by leo vegoda 23 Sep '04

23 Sep '04

Hi, APNIC have announced a change in the default behaviour of their Whois server. The change will be made on 30 September. People using their Whois service from this region may be interested in the announcement. Kind regards, -- leo vegoda Registration Services Manager RIPE NCC Begin forwarded message: > From: APNIC Secretariat <secretariat(a)apnic.net> > Date: September 23, 2004 2:02:27 am BST > To: apnic-announce(a)apnic.net > Cc: Subject: [Apnic-announce] Privacy of customer assignment records - > implementation update > Reply-To: apnic-talk(a)apnic.net, secretariat(a)apnic.net > > Dear colleagues, > > This is an important announcement on the implementation of APNIC > approved proposal prop-007-v001 regarding privacy of customer > assignment records. The proposal document, presentation, minutes, and > discussion are available at: > > http://www.apnic.net/docs/policy/proposals/prop-007-v001.html > > The APNIC Secretariat will be implementing this proposal on 30 > September 2004. > > Please note that after this date, customer assignment objects will no > longer be visible in the APNIC Whois Database, unless the APNIC > account holder chooses to make public the customer records for their > allocated address range. > > A set of Frequently Asked Questions about this project is now > available at: > > http://www.apnic.net/info/faq/privacy-faq.html > > If you have any concerns or questions regarding this policy, please > contact the APNIC helpdesk at: > > E-mail: helpdesk(a)apnic.net > Phone: +617 3858 3188 > Fax: +617 3858 3199 > > Regards > > ______________________________________________________________________ > APNIC Secretariat <secretariat(a)apnic.net> > Asia Pacific Network Information Centre (APNIC) Tel: +61-7-3858-3100 > PO Box 2131 Milton, QLD 4064 Australia Fax: +61-7-3858-3199 > ______________________________________________________________________ > _______________________________________________ > Apnic-announce mailing list > Apnic-announce(a)lists.apnic.net > http://mailman.apnic.net/mailman/listinfo/apnic-announce >

2 1

Abuse contacts in RIPE database and whois
by Rodney Tillotson 22 Sep '04

22 Sep '04

In this afternoon's session of the Anti-spam WG we discussed the issue of publishing abuse contacts and I agreed to present this consensus view and request. As time is short this is not yet published in the minutes of the meeting, but it will be! Rodney Tillotson Chair, RIPE anti-spam WG =========================================================== The Anti-spam WG asks the Database WG to take some timely action to improve the availability of abuse contacts for IP addresses allocated through RIPE: 1. to publish an explicit abuse contact address where possible for every address; 2. to lower the profile of other addresses currently in the database and published through whois, which were never intended for the abuse function. While it is for the Database WG to decide the best way to implement such improvements, the Anti-spam WG noted that of the various technical changes which have been proposed or partly implemented, one combination which we would find acceptable is: A. modify the IRT object to include an explicit 'abuse-mail' attribute and to remove the mandatory requirement for PGP or similar authentication (or introduce a similar new object with those properties); and B. modify the default behaviour of the whois interfaces to find and present an abuse address if there is one and to suppress other e-mail addresses. 22nd September 2004. ===========================================================

1 0

Agenda V3
by Titley, Nigel 16 Sep '04

16 Sep '04

Gentlefolk, Following a kind offer by Shane Kerr to give a run down on CRISP please find version 3 of the DB WG agenda. Nigel -- Nigel Titley Peering Coordinator, FLAG Telecom +44 20 7478 9579 ********************************************************************** This e-mail message is confidential and is intended only for the use of the individual or entity named above and contains information which is or may be confidential, non-public or legally privileged. Any dissemination or distribution of this message other than to its intended recipient is strictly prohibited. You should not copy it or use it for any purpose nor disclose the contents to any other person. If you have received this message in error, please notify us by email to postmaster(a)flagtelecom.com immediately and delete the original message and all copies from all locations in your computer systems. This e-mail has been swept by Mailsweeper TM for viruses. However, FLAG Telecom cannot accept liability for any damage which you may sustain as a result of software viruses. ********************************************************************** This message has been scanned for viruses by MailControl - www.mailcontrol.com

1 0

RE: [db-wg] draft agenda (V1) for DB-WG meeting, RIPE 49, Manches ter, UK
by Titley, Nigel 15 Sep '04

15 Sep '04

MarcoH wrote: > Hate to come up with it again, but there are various actions points > open > on the abuse-c stuff. One of them lists the 'implement whatever > concensus there is on the mailinglist'. > > These should already be on the agenda as open action points, but it > might > be worth planning some time for discussion or at least an overview of > what > the outcome of the mail discussion was. Sounds like a good idea. Do we have any volunteers to do a short presentation on where we got to? > It's hard to say there is consensus on this subject, although in they > end there weren't much comments posted and everybody seems to be > happy (or > tired of it). I think it just fizzled out. I'm not sure that we got to any consensus. Nigel -- Nigel Titley Peering Coordinator, FLAG Telecom +44 20 7478 9579 ********************************************************************** This e-mail message is confidential and is intended only for the use of the individual or entity named above and contains information which is or may be confidential, non-public or legally privileged. Any dissemination or distribution of this message other than to its intended recipient is strictly prohibited. You should not copy it or use it for any purpose nor disclose the contents to any other person. If you have received this message in error, please notify us by email to postmaster(a)flagtelecom.com immediately and delete the original message and all copies from all locations in your computer systems. This e-mail has been swept by Mailsweeper TM for viruses. However, FLAG Telecom cannot accept liability for any damage which you may sustain as a result of software viruses. ********************************************************************** This message has been scanned for viruses by MailControl - www.mailcontrol.com

1 0

draft agenda (V1) for DB-WG meeting, RIPE 49, Manchester, UK
by Wilfried Woeber, UniVie/ACOnet 13 Sep '04

13 Sep '04

Dear DB-WG community, attached please find the draft agenda V1 for the DB-WG meeting during RIPE49 in Manchester, UK. As some of us have still been on vacation recently, we may have to update the draft agenda as we get closer to the meeting date. Please feel free to propose additional topics by either replying to the WG mailing list or in private mail to Nigel (who has volunteered to manage the meeting in Manchester - thank you very much!) and myself. Have a nice and successful meeting in Manchester! Wilfried. ++++++++ A. Administrative Matters - scribe - list of participants - agenda - minutes - "remote participation" coordination (if needed) - meeting schedule for 2005 B. DB Operational Update (N.N., RIPE NCC) tbc [~20 min] C. ERX Report [196/8, 198/8] (Leo V., RIPE NCC) [~15 min] D. RAToolSet software maintenance (N.N., RIPE NCC) tbc [~10 min] E. Routing Registry Courses (Vesna M., RIPE NCC) [~05 min] Y. Input from other WGs Z. AOB -------------------------------------------------------------------------------- 7-SEP-2004 12:55:00 UTC

7 12

Re: [db-wg] domain: object normalization
by Wilfried Woeber, UniVie/ACOnet 13 Sep '04

13 Sep '04

I'd like to come back to the *original* question or suggestion: to teach the DB software to accept FQDN notation (trailing ".") for lookup keys that denote domain names. Pro / Con? As a dumb user of the DB I definitely stumble into that one myself, sometimes, so I am in favour of this (hopefully simple?) change. Btw, if this gets implemented, it should also work for the referral domain objects! Wilfried.

2 1