- ipv6-wg - mailman.ripe.net

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

[ipv6-wg@ripe.net] New Ghost Route Hunter Utility: Prefix Compare
by Jeroen Massar 19 Sep '04

19 Sep '04

Always wonder what was wrong with a prefix? Wondering which ISP's are not able to reach you and where it stops? GRH (Ghost Router Hunter *1) now has a new utility for doing prefix comparisons (*2). This feature was requested by Daniel Rösen for the purpose of comparing: 2001:5000::/21 with 2001:650::/32 (*3). Which are originated from the same ASN, but as the /21 is filtered at some places, have different or no paths to the participants (*4) that provide routes to GRH and many more ISP"s around the world. This utility thus allows you to see which participants of GRH do have the routes in question and the difference in the paths towards those participants. This allows a very quick view where a prefix is not accepted, most possibly of misconfigured filters. People who don't have, for instance, 2001:5000::/21 in their BGP, please figure out where the filtering is wrongly applied by looking at the utility and applying the current set of recommended filters, available from: http://www.space.net/~gert/RIPE/ipv6-filters.html It is good to see that ISP's have prefix filtering, but they really should update them. Though I'd rather see no prefix filtering but that they do RPF filtering on their customers. When you have (near) 0 IPv6 prefixes in your BGP, then you better start catching on ;) At the moment of writing you should have at least IPv6 499 prefixes, as then you have all the allocated, and currently announced, TLA's in your router, if you have less you are missing a number of them. For interested ISP's, GRH signup is, of course, free and can be done through the website (*5), the more peers join, the better the statistics of all the GRH utilities will be. Also, if you, like Daniel, miss a good utility, don't hesitate to bring it up. I would also like to thank all the already participating ISP's for providing their tables which have made it able to fix a large number of problems already over the almost 2 years GRH has been running. Last but not least, thanks to Daniel Rösen for the brilliant idea. Greets, Jeroen *1 = http://www.sixxs.net/tools/grh/ *2 = http://www.sixxs.net/tools/grh/compare/ *3 = http://www.sixxs.net/tools/grh/compare/?a=2001:5000::/21&b=2001:650::/32 *4 = http://www.sixxs.net/tools/grh/participants/ *5 = http://www.sixxs.net/tools/grh/signup/

2 1

[ipv6-wg@ripe.net] Agenda for ipv6 wg RIPE49
by David Kessens 16 Sep '04

16 Sep '04

Please see below for the agenda for the agenda for our session at RIPE49. Note that we have one topic on the agenda (Discussion of issues involved in deploying ipv6 in the DNS root) that is of interest for both DNS working group and ipv6 working group participants. Due to time considerations, we decided to have this topic discussed during the ipv6 working group session. Thanks & hope to see you all at RIPE 49, David Kessens --- Agenda for the IPv6 Working Group Meeting RIPE49 When: 14:00 - 18:00, Wednesday September 22, 2004 Where: Medici Room, Renaissance Hotel, Manchester, UK A. Administrative stuff - appointment of scribe - agenda bashing - approval of the minutes (David Kessens) B. Quick update from the RIPE NCC regarding ipv6 services (Andrei Robachevsky) C. Global IPv6 routing table status (Gert Doering) D. Report(s) about *actual* v6 traffic volume as compared to v4? *what's real* out there, not what's on powerpoint? (input from the audience) o IPv6 traffic in Geant (tentative) E. What are the deployment plans behind the larger ipv6 allocations ? o TeliaSonera (Mikael Lind) o Other big allocations (Jordi Palet Martinez) o Others ? F. Guidelines for ISPs on IPv6 assignments (Jordi Palet Martinez) http://www.europe.ipv6tf.org/PublicDocuments/guidelines_for_isp_on_ipv6_ass… -- break --- G. Discussion of issues involved in deploying ipv6 in the DNS root Speakers from the following root nameservers: B (tentative) F (speaker from ISC) I (speaker from Autonomica) K (tentative) H. Update on multihoming solutions from IETF (Geoff Huston) I. moonv6 (Jim Bound) J. Developments/initiatives regarding IPv6 in the RIPE region and beyond (input from the audience) K. Input for the RIPE NCC Activity Plan (input from the audience) Z. AOB ---

1 0

[ipv6-wg@ripe.net] Draft (v1) IPv6 WG minutes RIPE 48
by David Kessens 14 Sep '04

14 Sep '04

Please see below for the draft minutes of RIPE 48. The minutes will be declared final at the next meeting if no substantial comments that require a revision of the minutes are received before next working group session at RIPE 49. I hope this helps, David Kessens --- Draft (v1) IPv6 Working Group Minutes RIPE48 When: 14:00 - 18:00, Wednesday May 5, 2004 Where: Grand Ballroom, Hotel Krasnapolsky, Amsterdam A. Administrative stuff - appointment of scribe: Timothy Lowe, RIPE NCC - agenda bashing ACTIONS - Chair, ask the mailing list if this document should become a RIPE document http://ip6.de.easynet.net/ipv6-minimum-peering.txt - Community, provide feedback update on larger then default v6 allocations - Pim van Pelt (BIT BV) is looking for people who would like to run public 6to4 relays e-mail: pim(a)bit.nl or pim(a)ipng.nl B. Global IPv6 routing table status (Gert Doering, SPACENET) <http://www.space.net/~gert/RIPE/R48-v6-table/> The rate of growth in IPv6 allocations is tapering off. There is public data available on the difference between allocated IPv4 space and BGP routed IPv4 space here: <http://bgp.potaroo.net/index-ale.html> This site contains a number of reports on the status of the IPv4 address space, together with some observations about its trends in consumption of this resource. C. "per country view" about IPv6 allocation on the RIPE/NCC (Carlos Friacas, FCCN) <http://www.ip6.fccn.pt/v6top.html> D. Report(s) about *actual* v6 traffic volume as compared to v4? *what's real* out there, not what's on powerpoint? (input from the audience) Questions: Pim van Pelt, BIT BV - 6to4 public relays are at 80 Mbs sustained. We would like people who want to run public 6to4 relays to contact us: pim(a)bit.nl or pim(a)ipng.nl E. Raising RPSLng Awareness (Carlos Friacas, Simon Leinen and Joao Damas, ISC) The RPSLng protocol draft is nearing completion (http://www.radb.net/rpslng.html) F. Discussion of: http://ip6.de.easynet.net/ipv6-minimum-peering.txt Should this document become a RIPE document? ACTION on Chair - to take this to the mailing list H. Latest IPv6 Land Speed Record (Edoardo Martelli, CERN) <http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-ipvy-lsr.pdf>- 15:08 G. IETF multi6 update (Kurtis Erik Lindqvist, Netnod Internet Exchange) There are two main camps in this discussion: Dividing the Identifier and addressing functions of the IP by a.) Using identifier tokens b.) Lightweight version without ID token distribution I. What are the deployment plans behind the larger then default ipv6 allocations (Jordi Palet Martinez as a liaison for Vodafoon) ACTION on Chair - keep this agenda point as an ongoing action. ACTION on community - send feedback for next RIPE meeting J. IPv6 home automation (Palet Jordi, Consulintel) There is a commercial powerline connectivity service operating in Zaragoza Spain. Currently in IPv4 but possibly in IPv6 in future. K. (brief) update from the RIPE NCC on ipv6 enabled services (Andrei Robachevsky, RIPE NCC) Verbal: These services are IPv6 enabled: DNS, whois, ttm, plan, new webserver, K root. N. Input for the RIPE NCC Activity Plan (input from the audience) NONE M. Developments/initiatives regarding IPv6 in the RIPE region and beyond (input from the audience) NONE L. IPv6 network management - IETF MIBs status, NetFlow v9, SNMPv6, and monitoring tools (Bernard Tuy - RENATER) K. AOB Skidder ip mapping tool for topology research. Trying to do this in v6 www.caida.org/~mjl/

1 0

[ipv6-wg@ripe.net] New IPv6 Address Block Allocated to RIPE NCC
by leo vegoda 13 Sep '04

13 Sep '04

Dear Colleagues, The RIPE NCC received the IPv6 address range 2001:5000::/20 from the IANA in September 2004. You may wish to adjust any filters you have in place accordingly. More information on the IP space administered by the RIPE NCC can be found on our web site at: <https://www.ripe.net/ripe/docs/smallest-alloc-sizes.html> Regards, -- leo vegoda Registration Services Manager RIPE NCC

1 0

Re: [ipv6-wg@ripe.net] DNS Weather Report 2004-09-07
by Daniel Karrenberg 13 Sep '04

13 Sep '04

Since a storm seems to be rising about this and it threatens to leave the tea cup here is some perspective. Daniel ----- Forwarded message from Daniel Karrenberg <daniel.karrenberg(a)ripe.net> ----- Date: Wed, 8 Sep 2004 08:21:23 +0200 From: Daniel Karrenberg <daniel.karrenberg(a)ripe.net> To: Daniel Roesen <dr(a)cluenet.de> Subject: Re: [ipv6-wg(a)ripe.net] DNS Weather Report 2004-09-07 On 08.09 00:00, Daniel Roesen wrote: > On Tue, Sep 07, 2004 at 11:49:48AM +0200, Daniel Karrenberg wrote: > > On 07.09 01:08, Daniel Roesen wrote: > > > DNS WEATHER REPORT for selected infrastructure zones > > > ==================================================== > > > > Please stop spamming mailing lists. > > OK, you made me curious. Why do you (you are the first, all the other > feedback was overly positive) consider this "spamming"? Sending *unsolicited* automatic reports to *multiple* mailing lists is considered bad netiquette. In your case even more so since similar and better defined reports are available on demand from more than one source. It would have been more acceptable to say something like: "Hey, I have made this useful report. What do you think about it? If you are interested you can subscribe to regular reports here." These days netiquette is violated so frequently that most people do not even care to point things out to violators; they just ignore messages from people who do not behave socially. Procmail is an easy tool. [I spent 6 minutes composing this message. Multiply by n>20 / day] > And: was your request as a representant of the RIPE NCC, or as a > private person? Take it as advice from me as a person. The RIPE NCC does not police RIPE mailing lists. Daniel ----- End forwarded message -----

4 7

[ipv6-wg@ripe.net] Draft agenda (v2) for ipv6 wg RIPE49
by David Kessens 11 Sep '04

11 Sep '04

Hi, Please see below for the second version of our proposed agenda. We still have some time left, so proposals for additional agenda items that are useful for ipv6 Internet service providers are still welcome. You might have noticed that the minutes for RIPE 48 are still missing. I am working with the RIPE NCC to get them posted as soon as possible. I hope this helps, David Kessens --- Updated agenda for the IPv6 Working Group Meeting RIPE49 When: 14:00 - 18:00, Wednesday September 22, 2004 Where: Medici Room, Renaissance Hotel, Manchester, UK A. Administrative stuff - appointment of scribe - agenda bashing - approval of the minutes (David Kessens) B. Global IPv6 routing table status (Gert Doering) C. Report(s) about *actual* v6 traffic volume as compared to v4? *what's real* out there, not what's on powerpoint? (input from the audience) D. What are the deployment plans behind the larger ipv6 allocations ? o TeliaSonera (Mikael Lind) o Others ? E. Guidelines for ISPs on IPv6 assignments (Jordi Palet Martinez) http://www.europe.ipv6tf.org/PublicDocuments/guidelines_for_isp_on_ipv6_ass… F. moonv6 (Jim Bound) -- break --- G. Update on multihoming solutions from IETF (Geoff Huston) H. Developments/initiatives regarding IPv6 in the RIPE region and beyond (input from the audience) I. Input for the RIPE NCC Activity Plan (input from the audience) Z. AOB ---

1 0

[ipv6-wg@ripe.net] Draft (v1) IPv6 wg minutes at RIPE 47
by David Kessens 11 Sep '04

11 Sep '04

Please see below for the draft minutes of RIPE 47. My apologies for the late publication. The minutes will be approved if no significant comments will be received before the next working roup session in Manchester. David Kessens --- ________________________________________________ Draft (v1) minutes for the IPv6 Working Group Meeting RIPE 47 When: 14:00 - 15:30, Tuesday January 27, 2004 Where: St Johns II, Hotel Krasnapolsky, Amsterdam A. Administrative stuff Scribe: Timothy Lowe (RIPE NCC) Attendees: 132 B. Ranges of ipv6 addresses and their use (Jeroen Massar) http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-ipv6-ghost-r… C. Global IPv6 routing table status (Gert Doering) http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-ipv6-global-… D. Report(s) about *actual* v6 traffic volume as compared to v4 - Tunnel Detection Tool (Lorenzo Colitti, RIPE NCC, TTM project) http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-ipv6-tunnel-… - IPv6 Network Management (Bernard Tuy) E. Operational issues with IPv6: RPSLng testing, policy issues, filtering practices, peering (Simon Leinen, Swiss IPv6 task force & ops group) http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-ipv6-swiss-p… F. Developments/initiatives regarding IPv6 in the RIPE region and beyond - latest IPv6 Land Speed Record (Edoardo Martelli (CERN)) ---

1 0

[ipv6-wg@ripe.net] Re: [dns-wg] IPv6 in .ie
by Jim Reid 09 Sep '04

09 Sep '04

>>>>> "Daniel" == Daniel Karrenberg <daniel.karrenberg(a)ripe.net> writes: Daniel> If I was IANA I would advise .ie strongly to rationalise Daniel> the names in their glue to save space. Yeah. Somebody needs to write up a draft on this as a BCP: using efficient label compression to avoid truncated responses.

5 5

[ipv6-wg@ripe.net] IPv6 in .ie (fwd)
by Carlos Friacas 08 Sep '04

08 Sep '04

One more today... Belgium (.BE), supported by BRUSSELS.NS.DNS.BE. (2001:6a8:3c60::be) ./Carlos -------------- http://www.ip6.fccn.pt/nativeRCTS2.html Wide Area Network (WAN) Workgroup, CMF8-RIPE, CF596-ARIN FCCN - Fundacao para a Computacao Cientifica Nacional http://www.fccn.pt "Internet is just routes (140068/465), naming (millions) and... people!" ---------- Forwarded message ---------- Date: Tue, 7 Sep 2004 08:54:30 +0100 (WEST) From: Carlos Friacas <cfriacas(a)fccn.pt> To: ipv6-wg(a)ripe.net Subject: [ipv6-wg(a)ripe.net] IPv6 in .ie (fwd) FYI, 19 TLDs already served by IPv6 nameservers w/glue-record on ".". Tue Sep 7 08:50:45 WEST 2004 ----------------------------- CH. DOMREG.NIC.CH. LI. DOMREG.NIC.CH. DE. A.NIC.DE. FR. C.NIC.FR. IE. NS6.IEDR.IE. JP. A.DNS.JP. JP. D.DNS.JP. JP. E.DNS.JP. JP. F.DNS.JP. KR. G.DNS.KR. IE. NS3.NS.ESAT.NET. TP. NS3.NS.ESAT.NET. AN. NS0.JA.NET. GB. NS0.JA.NET. GG. NS0.JA.NET. INT. NS0.JA.NET. JE. NS0.JA.NET. AN. NS0.JA.NET. GB. NS0.JA.NET. GG. NS0.JA.NET. INT. NS0.JA.NET. JE. NS0.JA.NET. INT. NS-SEC.RIPE.NET. AQ. NS-EXT.ISC.ORG. IL. NS-EXT.ISC.ORG. NL. NS-EXT.ISC.ORG. PH. NS-EXT.ISC.ORG. TN. NS.ATI.TN. TW. A.DNS.TW. TW. C.DNS.TW. TW. D.DNS.TW. ./Carlos -------------- http://www.ip6.fccn.pt/nativeRCTS2.html Wide Area Network (WAN) Workgroup, CMF8-RIPE, CF596-ARIN FCCN - Fundacao para a Computacao Cientifica Nacional http://www.fccn.pt "Internet is just routes (140068/465), naming (millions) and... people!" ---------- Forwarded message ---------- Date: Mon, 06 Sep 2004 18:05:11 +0100 From: Billy Glynn <billy.glynn(a)domainregistry.ie> To: ipv6-wg(a)ripe.net Cc: dns-wg(a)ripe.net, tech(a)lists.centr.org, ga(a)centr.org Subject: [ipv6-wg(a)ripe.net] IPv6 in .ie Hi, FYI, the IEDR in it's capacity as ccTLD manager of .ie have added a new IPv6 compatible name server ns6.iedr.ie. Additionally, we have added AAAA glue for one of our slaves ns3.ns.esat.net. ns3.ns.esat.net also slaves for the folks at .tp Kind regards -- ________________________________ Billy Glynn Network Operations Centre IE Domain Registry Ltd Tel: +353 (0)1 2365404 Mobile: +353 (0)87 9188317 billy.glynn(a)domainregistry.ie ________________________________

1 0