From berni at birkenwald.de Wed Oct 6 23:23:47 2004 From: berni at birkenwald.de (Bernhard Schmidt) Date: Wed, 6 Oct 2004 23:23:47 +0200 Subject: [ipv6-wg@ripe.net] RPSLng database deployment? Message-ID: <20041006212347.GA23610@obelix.birkenwald.intern> 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 From dr at cluenet.de Wed Oct 6 23:41:05 2004 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 6 Oct 2004 23:41:05 +0200 Subject: [ipv6-wg@ripe.net] RPSLng database deployment? In-Reply-To: <20041006212347.GA23610@obelix.birkenwald.intern> References: <20041006212347.GA23610@obelix.birkenwald.intern> Message-ID: <20041006214105.GA21568@srv01.cluenet.de> On Wed, Oct 06, 2004 at 11:23:47PM +0200, Bernhard Schmidt wrote: > 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? Good question... > I am using rpslng.ripe.net, but unfortunately almost noone else does. Probably because people don't have too much time to devote to playing around. :-Z I would love to see a production version of the RPSLng server... Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From alh-ietf at tndh.net Thu Oct 7 02:09:25 2004 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 6 Oct 2004 17:09:25 -0700 Subject: [ipv6-wg@ripe.net] RPSLng database deployment? In-Reply-To: <20041006212347.GA23610@obelix.birkenwald.intern> Message-ID: <20041007000937.D2C8451E29@postman.ripe.net> 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 at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of > Bernhard Schmidt > Sent: Wednesday, October 06, 2004 2:24 PM > To: db-wg at ripe.net > Cc: ipv6-wg at ripe.net > Subject: [ipv6-wg at 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 From alh-ietf at tndh.net Thu Oct 7 02:12:13 2004 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 6 Oct 2004 17:12:13 -0700 Subject: [ipv6-wg@ripe.net] RPSLng database deployment? Message-ID: <20041007001223.C69014E3CB@postman.ripe.net> Sorry, this was a reply to the wrong message. Tony > -----Original Message----- > From: Tony Hain [mailto:alh-ietf at tndh.net] > Sent: Wednesday, October 06, 2004 5:09 PM > To: 'Bernhard Schmidt'; 'db-wg at ripe.net' > Cc: 'ipv6-wg at ripe.net' > Subject: RE: [ipv6-wg at 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 at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf > Of > > Bernhard Schmidt > > Sent: Wednesday, October 06, 2004 2:24 PM > > To: db-wg at ripe.net > > Cc: ipv6-wg at ripe.net > > Subject: [ipv6-wg at 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 From shane at ripe.net Thu Oct 7 09:43:46 2004 From: shane at ripe.net (Shane Kerr) Date: Thu, 07 Oct 2004 09:43:46 +0200 Subject: [ipv6-wg@ripe.net] RPSLng database deployment? In-Reply-To: <20041006214105.GA21568@srv01.cluenet.de> References: <20041006212347.GA23610@obelix.birkenwald.intern> <20041006214105.GA21568@srv01.cluenet.de> Message-ID: <4164F3B2.4010502@ripe.net> Daniel Roesen wrote: > On Wed, Oct 06, 2004 at 11:23:47PM +0200, Bernhard Schmidt wrote: > >>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? > > > Good question... > > >>I am using rpslng.ripe.net, but unfortunately almost noone else does. > > > Probably because people don't have too much time to devote to playing > around. :-Z > > I would love to see a production version of the RPSLng server... The RPSLng draft is currently in the IETF RFC editor queue. We are co-ordinating with Merit, who run RADB, to try to put RPSLng into production at the same time. I expect we will do this in a few months. -- Shane Kerr RIPE NCC From dr at cluenet.de Thu Oct 7 10:52:06 2004 From: dr at cluenet.de (Daniel Roesen) Date: Thu, 7 Oct 2004 10:52:06 +0200 Subject: [ipv6-wg@ripe.net] RPSLng database deployment? In-Reply-To: <4164F3B2.4010502@ripe.net> References: <20041006212347.GA23610@obelix.birkenwald.intern> <20041006214105.GA21568@srv01.cluenet.de> <4164F3B2.4010502@ripe.net> Message-ID: <20041007085206.GA25644@srv01.cluenet.de> On Thu, Oct 07, 2004 at 09:43:46AM +0200, Shane Kerr wrote: > The RPSLng draft is currently in the IETF RFC editor queue. We are > co-ordinating with Merit, who run RADB, to try to put RPSLng into > production at the same time. I expect we will do this in a few months. Thanks Shane. Let us know if there's anything we can do to speed that up. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From dr at cluenet.de Sat Oct 9 21:57:26 2004 From: dr at cluenet.de (Daniel Roesen) Date: Sat, 9 Oct 2004 21:57:26 +0200 Subject: [ipv6-wg@ripe.net] RPSLng database deployment? In-Reply-To: <4166A2FA.8080608@noc.ntua.gr> References: <20041006212347.GA23610@obelix.birkenwald.intern> <20041006214105.GA21568@srv01.cluenet.de> <4166A2FA.8080608@noc.ntua.gr> Message-ID: <20041009195726.GA23354@srv01.cluenet.de> Hi Dimitrios, btw... your posting didn't came through on db-wg/ipv6-wg mailing lists for unknown reasons. On Fri, Oct 08, 2004 at 05:23:54PM +0300, Dimitrios Kalogeras wrote: > >>I am using rpslng.ripe.net, but unfortunately almost noone else does. > > > So how do they produce the bgp policy configuration ? All I've seen: manual. > What do big ISP do with IPv6 policy configuration ? Again, all manual. Same as with IPv4. I've never seen anyone actually using RtConfig output for anything else then destilling prefix/aspath lists from them in order to use those in own generator tools. Given my own very basic and short playing with RtConfig, I can somewhat understand why. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From iljitsch at muada.com Sat Oct 9 22:54:05 2004 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sat, 9 Oct 2004 22:54:05 +0200 Subject: [ipv6-wg@ripe.net] RPSLng database deployment? In-Reply-To: <20041009195726.GA23354@srv01.cluenet.de> References: <20041006212347.GA23610@obelix.birkenwald.intern> <20041006214105.GA21568@srv01.cluenet.de> <4166A2FA.8080608@noc.ntua.gr> <20041009195726.GA23354@srv01.cluenet.de> Message-ID: <5B8D008C-1A35-11D9-9F59-000A95CD987A@muada.com> On 9-okt-04, at 21:57, Daniel Roesen wrote: >> What do big ISP do with IPv6 policy configuration ? > Again, all manual. Same as with IPv4. > I've never seen anyone actually using RtConfig output for anything > else then destilling prefix/aspath lists from them in order to use > those in own generator tools. Given my own very basic and short > playing with RtConfig, I can somewhat understand why. It would make countless lives much easier if it were possible to submit a query to the db that gives back the desired output rather than having to use these very complex tools. That doesn't solve the problem that many people don't register their stuff in the db very well, if at all, though. From dr at cluenet.de Sat Oct 9 23:14:03 2004 From: dr at cluenet.de (Daniel Roesen) Date: Sat, 9 Oct 2004 23:14:03 +0200 Subject: [ipv6-wg@ripe.net] RPSLng database deployment? In-Reply-To: <5B8D008C-1A35-11D9-9F59-000A95CD987A@muada.com> References: <20041006212347.GA23610@obelix.birkenwald.intern> <20041006214105.GA21568@srv01.cluenet.de> <4166A2FA.8080608@noc.ntua.gr> <20041009195726.GA23354@srv01.cluenet.de> <5B8D008C-1A35-11D9-9F59-000A95CD987A@muada.com> Message-ID: <20041009211403.GA23650@srv01.cluenet.de> On Sat, Oct 09, 2004 at 10:54:05PM +0200, Iljitsch van Beijnum wrote: > >I've never seen anyone actually using RtConfig output for anything > >else then destilling prefix/aspath lists from them in order to use > >those in own generator tools. Given my own very basic and short > >playing with RtConfig, I can somewhat understand why. > > It would make countless lives much easier if it were possible to submit > a query to the db that gives back the desired output rather than having > to use these very complex tools. Agreed, IRRd actually offers that. > That doesn't solve the problem that many people don't register their > stuff in the db very well, if at all, though. Well... my main gripe about all this is the lack of authorization control over route objects. For RIPE it's fine as you normally cannot register a route object without having the authorization of the IP space holder, but this doesn't hold true for all other IRR registries. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From dkalo at noc.ntua.gr Fri Oct 8 16:23:54 2004 From: dkalo at noc.ntua.gr (Dimitrios Kalogeras) Date: Fri, 08 Oct 2004 17:23:54 +0300 Subject: [ipv6-wg@ripe.net] RPSLng database deployment? In-Reply-To: <20041006214105.GA21568@srv01.cluenet.de> References: <20041006212347.GA23610@obelix.birkenwald.intern> <20041006214105.GA21568@srv01.cluenet.de> Message-ID: <4166A2FA.8080608@noc.ntua.gr> Hi Daniel, Daniel Roesen wrote: > On Wed, Oct 06, 2004 at 11:23:47PM +0200, Bernhard Schmidt wrote: > >>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? > > > Good question... > > >>I am using rpslng.ripe.net, but unfortunately almost noone else does. > So how do they produce the bgp policy configuration ? What do big ISP do with IPv6 policy configuration ? > > Probably because people don't have too much time to devote to playing > around. :-Z > Partly true. I have devoted some time to integrate our current RPSL to RPSLng. So check in for AS5408. The next task to do is to assure that RtConfig produces the desired result. > I would love to see a production version of the RPSLng server... > Yup that is the next thing I would like to have too. Best regards, Dimitrios > > Best regards, > Daniel > -- -- Dimitrios K. Kalogeras Electrical Engineer Ph.D. Network Manager NTUA/GR-Net Network Management Center _____________________________________ icq: 11887484 voice: +30-210-772 1863 fax: +30-210-772 1866 e-mail: D.Kalogeras at noc.ntua.gr pub 1024D/F2A69A72 2002-12-13 Dimitrios Kalogeras Key fingerprint = 64C5 646D 8D33 A3FF 14D1 66C6 5127 54CC F2A6 9A72 From mrp at mrp.net Mon Oct 11 12:54:07 2004 From: mrp at mrp.net (Mark Prior) Date: Mon, 11 Oct 2004 20:24:07 +0930 Subject: [db-wg] Re: [ipv6-wg@ripe.net] RPSLng database deployment? In-Reply-To: <5B8D008C-1A35-11D9-9F59-000A95CD987A@muada.com> References: <20041006212347.GA23610@obelix.birkenwald.intern> <20041006214105.GA21568@srv01.cluenet.de> <4166A2FA.8080608@noc.ntua.gr> <20041009195726.GA23354@srv01.cluenet.de> <5B8D008C-1A35-11D9-9F59-000A95CD987A@muada.com> Message-ID: <416A664F.5000008@mrp.net> Iljitsch van Beijnum wrote: > On 9-okt-04, at 21:57, Daniel Roesen wrote: >> I've never seen anyone actually using RtConfig output for anything >> else then destilling prefix/aspath lists from them in order to use >> those in own generator tools. Given my own very basic and short >> playing with RtConfig, I can somewhat understand why. > > > It would make countless lives much easier if it were possible to submit > a query to the db that gives back the desired output rather than having > to use these very complex tools. Not a huge ISP but I certainly build my access list and route-maps (and the equivalent Procket policy stuff) using RtConfig with no other magic involved. In my previous job at one of Australia's tier ones we did it that way too. See AS7575 (current policy) and/or AS2764 (previous one) for outrageous aut-num objects. I don't use inet-rtr objects though. Personally I don't think driving RtConfig is all that difficult. Mark. From Joao_Damas at isc.org Mon Oct 11 15:38:42 2004 From: Joao_Damas at isc.org (Joao Damas) Date: Mon, 11 Oct 2004 15:38:42 +0200 Subject: [ipv6-wg@ripe.net] RPSLng database deployment? In-Reply-To: <20041009211403.GA23650@srv01.cluenet.de> References: <20041006212347.GA23610@obelix.birkenwald.intern> <20041006214105.GA21568@srv01.cluenet.de> <4166A2FA.8080608@noc.ntua.gr> <20041009195726.GA23354@srv01.cluenet.de> <5B8D008C-1A35-11D9-9F59-000A95CD987A@muada.com> <20041009211403.GA23650@srv01.cluenet.de> Message-ID: On 9 Oct, 2004, at 23:14, Daniel Roesen wrote: > On Sat, Oct 09, 2004 at 10:54:05PM +0200, Iljitsch van Beijnum wrote: >>> I've never seen anyone actually using RtConfig output for anything >>> else then destilling prefix/aspath lists from them in order to use >>> those in own generator tools. Given my own very basic and short >>> playing with RtConfig, I can somewhat understand why. >> >> It would make countless lives much easier if it were possible to >> submit >> a query to the db that gives back the desired output rather than >> having >> to use these very complex tools. > > Agreed, IRRd actually offers that. > Hmm, that's interesting. Last time I checked the RIPE server provided the same features (except for route-set expansion, mainly due to the fact that when rpsl was defined it was not entirely clear how the expansion was to be performed). To the best of my recollection no one has ever manifested interest in having the RIPE server do that. Joao From david.kessens at nokia.com Tue Oct 12 06:58:57 2004 From: david.kessens at nokia.com (David Kessens) Date: Mon, 11 Oct 2004 21:58:57 -0700 Subject: [ipv6-wg@ripe.net] Draft Minutes (v1) from IPv6 WG - RIPE 49 Message-ID: <20041012045857.GC9321@nokia.com> Please see below for the draft (v1) minutes of the ipv6 working group session for RIPE 49. The minutes will be declared final if no substantial changes are proposed before Fri Oct 22. I hope this helps, David Kessens --- RIPE 49 Manchester IPv6 Working Group Wednesday 22 September 2004 WG Chair David Kessens Scribe Adrian Bedford (RIPE NCC) Attendees: 121 Administration and Agenda Presented by David Kessens Adrian Bedford of the RIPE NCC was appointed scribe. Agenda was agreed Minutes from both RIPE 47 and 48 were approved. Update from the RIPE NCC Presented by Andrei Robachevsky, RIPE NCC As of August, k-root is IPv6 enabled The new version of the RIPE website (to be launched shortly) will also be IPv6 enabled. An Overview of the Global IPv6 Routing Table Presented by Gert Doering (Spacenet) A number of anomalies have been observed in the Global IPv6 Routing table, though in most cases these could be explained by traffic engineering, internal transitions and in one case a prefix leak. One person used the Jabber Remote Feedback system to ask why IXPs are announcing /48s with no export. It was explained that, for example, AMSIX doesn't want it's neighbors to make it's prefix globally visible. It remains a contentious issue as to whether something should be globally visible. What are the Deployment Plans Behind the Larger IPv6 Allocations? Presented by: Mikael Lind (TeliaSonera) David Kessens asked whether there were plans to allocate /64s for mobile use. Mikael confirmed that this was likely and that TeliaSonera was also looking at /48s for this use. Kurtis Lindqvist asked whether TeliaSonera has been talking with vendors to co-ordinate hardware and equipment. Mikael explained that this has not yet happened, as they feel right now there is little incentive to do so. David asked if Mikael would consider returning to a future RIPE Meeting to provide an update when TeliaSonera is further along in the development and deployment process, Mikael indicated that he would be happy to do so. Deployment Plans Behind Larger IPv6 Allocations Presented by Jordi Palet (Consulintel) Jordi will continue to keep the Working Group posted on feedback. He will also encourage non-respondents to contribute. Geant IPv6 Presented by Jordi Palet (Consulintel) Guidelines for ISPs on IPv6 Assignments to Customers Presented by Jordi Palet (Consulintel) This presentation was a follow on from the one given at RIPE 48. < BREAK > IPv6 Glue for the Root Nameservers Presented by Johan Ihr?n (Autonomica) Iljitsch van Beijnum asked how long the process is likely to take. Johan commented that it would depend on who was prepared to take on the task, Johan is willing to do this, though added that nothing is root server specific, if people argue that we need v6 glue now, then they should step up and offer to help out. There is no specific target date for this to happen, since testing needs to be completed. Randy Bush asked that since we tend to assume that we should upgrade when something breaks, how is he to know when something has in fact broken. How, as an operator will he actually know there is something wrong? Johan agreed with Randy, there needs to be an agreed process. This could mean that things may not happen universally at the same time. Much will depend on the level of ambition of those involved - the tasks could be more or less complex. Gert Doering commented that as we see ccTLDs adding v6 glue, they might already know some of the issues that could arise. He suggested that someone speak to the ccTLD Operators and find someone who is willing to help with testing. It was also suggested that prudence might be a good idea. If a ccTLD Operator decides to deploy v6 transitions to their nameservers, in the end it will be their own decision. A question was asked about whether anything could be done to improve I-root connectivity to Europe. Johan commented that this would fall into his domain and promised to provide more feedback on this by RIPE 50. Bill Manning commented that the group appeared to be talking as if testing had not in fact started, whereas people are doing tests, ccTLD Operators at already looking at the impacts of these tests. A timeframe was agreed at the last ISOC meeting to finish testing before their next report at the end of the year, enabling a report to made to ICANN. One obstacle here is that the last report to the ICANN board took six months to have approved. Doug Barton of ICANN commented that the process has been streamlined and lessons learned, it is felt that any such future report would receive a far quicker response. David Kessens asked if all root servers planned to have IPv6 connectivity at the same time. Johan replied that he thought it unlikely that everyone would approach this in the same way, adding that he felt diversity was not a bad thing. It would, he said, be likely that we would see some TLDs using basic glue with others holding off during the early phases. The day when we will see the v6 glue globally is still somewhere in the distant future as there are no specific plans at this point to co-ordinate such a deployment. To date eight have basic glue in place. David asked if this community could help and Johan said he felt it certainly could. There was discussion about asking the RIPE NCC for help, though Johan this was not necessary at this stage. From his point of view he did not feel the issue was who did this, rather thought needed to be given to identifying which tests are relevant. Time would need to be taken over inventory to find out what code is already out there. David rounded up the discussion by saying that volunteers would be welcomed, though this was not be taken as a specific action point. An Update on Multihoming in IPv6 Presented by Geoff Huston (APNIC) A comment was made that the slide detailing issues appeared to not consider the update rates for bindings and third party referrals. Geoff said that design decisions should avoid relying on DNS. Randy Bush commented that there had been some mission drift from multi-homing to mobility. A comment was made that if an opportunistic solution does not meet all the needs in the architecture, you are forced to use a structured identifier. Such an identifier would have to be unique to avoid collisions. This could give rise to a very complex registration infrastructure, which might be painful to administer. Geoff replied that uniqueness never comes cheap and needs enormous effort at a global level. This lead to a suggestion that it may be preferable to choose opportunistic styles. Geoff felt that this was down to personal taste; there were certainly benefits in avoiding global costs if set up problems could be avoided. A suggestion was made that we should consider developing a whole new protocol that could handle routing table growth, Geoff replied that it would be ideal to think that we could do both, groups do exist with experience in both fields. The IETF have working groups that work together to engineer solutions and ensure routing tables do not become too complex. Geoff agreed that many people do feel routing could provide a better answer Kuris Lindqvist pointed to work that had been done during an interim meeting in Santa Monica in June 2004, this looked at the architectural work done by Geoff and the 30-40 drafts submitted. The drafts were split into four or five categories and based upon these; a simple poll was carried out. In some categories, the authors withdrew their proposals and in others, there was little support. The consensus was that the architecture proposed by Geoff was the way the group wished to move forward at the moment. A speaker announced that he had prepared a draft on the use of PI to reduce pressures on routing tables, intended as a compromise and is accepting comments on this. A speaker added that during his presentation Geoff dismissed mobile IP for security and state management reasons. The IETF has already addressed security and state management could throw up more problems. He felt that having two solutions for these issues problem was unwise and we need to work towards a single solution for what seem like related problems. He felt that using security, as a reason to reject the architecture draft was a red herring. Geoff pointed out that this is not yet in the draft, though will be in the next version. Geoff agreed that some of the assumptions we made previously in mobile IPv6 now seem less secure. Security locators assume a stable home base - if it fails, everything else fails. Multi6 looks at the ?homeless vagrants? of the world that do not have a home all of the time and the home is not reachable. It then assumes that there is not a home locator that can always be contacted. The Multi6 team looked at the other approaches and aimed to learn from them. He remains unsure if this kind of binding works in mobile environments, it is far too early to make this assessment. David Kessens asked whether the group found updates from Multi6 useful, Kurtis suggested that it would be nice to have Geoff make a similar presentation in future Address Policy Working Group Sessions too. Gert Doering suggested that as co-chair of the Address Policy Working Group, he would like to see the drafts on PI Addressing discussed through the Address Policy Mailing List. Moonv6 Update Presented by Jim Bounds Kurtis Lindqvist asked whether security testing had been carried out in an isolated test environment. Jim clarified that filters had only been tested on IPv6 ports, addresses and protocols. He added that it showed there was confusion. Just because dual stack is not a security problem, IPv6 in itself is not an insecure protocol. Intrusion detection needs to be included into work. Kurtis asked what stage of the evolution process the project had reached. Jim replied that in this respect, research was still quite basic. Deploying 5,000 IPv6 Sites - XTEC Presented by Jordi Palet (Consulintel) Input to RIPE NCC Activity Plan Presented by David Kessens David asked if the group had any items to include in the 2005 RIPE NCC Activity Plan. There was no response. From ljb at merit.edu Tue Oct 12 17:08:18 2004 From: ljb at merit.edu (Larry J. Blunk) Date: Tue, 12 Oct 2004 11:08:18 -0400 Subject: [db-wg] Re: [ipv6-wg@ripe.net] RPSLng database deployment? In-Reply-To: References: <20041006212347.GA23610@obelix.birkenwald.intern> <20041009211403.GA23650@srv01.cluenet.de> Message-ID: <200410121108.18670.ljb@merit.edu> On Monday 11 October 2004 09:38, Joao Damas wrote: > On 9 Oct, 2004, at 23:14, Daniel Roesen wrote: > > On Sat, Oct 09, 2004 at 10:54:05PM +0200, Iljitsch van Beijnum wrote: > >>> I've never seen anyone actually using RtConfig output for anything > >>> else then destilling prefix/aspath lists from them in order to use > >>> those in own generator tools. Given my own very basic and short > >>> playing with RtConfig, I can somewhat understand why. > >> > >> It would make countless lives much easier if it were possible to > >> submit > >> a query to the db that gives back the desired output rather than > >> having > >> to use these very complex tools. > > > > Agreed, IRRd actually offers that. > > Hmm, that's interesting. Last time I checked the RIPE server provided > the same features (except for route-set expansion, mainly due to the > fact that when rpsl was defined it was not entirely clear how the > expansion was to be performed). To the best of my recollection no one > has ever manifested interest in having the RIPE server do that. > > Joao Just to clarify -- IRRd supports a "!i" command to expand route-sets and as-sets. Performing the expansions internally is somewhat of a complex operation and can potentially hit the CPU pretty hard (the RIPE db has a few very large route-sets). Up until a couple years ago, IRRd did not fully handle set expansions. Namely, the expansion code only supported up to two levels of nesting of set names, and did not resolve AS numbers present in route-sets into prefixes. There is also a "!g" command in IRRd which is the functional equivalent of an "-i origin" inverse query in the RIPE server. The main difference being that the "!g" output is in a more compact list of prefixes format. The RIPE server produces fairly compact output when combined with the "-K" flag and it should be pretty trivial to refine the output down to IRRd "!g" style list with a few lines of perl. Merit has not updated the "!g" and "!i" commands in IRRd to support IPv6 prefixes. Doing so would break existing tools. An option would be to add something like a "!6" switch command to let the server know you can handle IPv6 prefixes. We have added support for RIPE server style "-i origin" and "-i member-of" queries which should allow client-side expansions with RPSLng support without breaking existing tools (hopefully!). We could add a !6 switch at a later point if there is sufficient demand. I've been considering enhancing Todd Caine's IRR.pm perl module with support for RIPE style queries and RPSLng. If someone wants to beat me to it, Todd's code can be found here -- http://search.cpan.org/~tcaine/Net-IRR/lib/Net/IRR.pm -Larry Blunk Merit From dkalo at noc.ntua.gr Wed Oct 13 08:59:57 2004 From: dkalo at noc.ntua.gr (Dimitrios Kalogeras) Date: Wed, 13 Oct 2004 09:59:57 +0300 Subject: [db-wg] Re: [ipv6-wg@ripe.net] RPSLng database deployment? In-Reply-To: <416A664F.5000008@mrp.net> References: <20041006212347.GA23610@obelix.birkenwald.intern> <20041006214105.GA21568@srv01.cluenet.de> <4166A2FA.8080608@noc.ntua.gr> <20041009195726.GA23354@srv01.cluenet.de> <5B8D008C-1A35-11D9-9F59-000A95CD987A@muada.com> <416A664F.5000008@mrp.net> Message-ID: <416CD26D.8090507@noc.ntua.gr> Mark Prior wrote: > Iljitsch van Beijnum wrote: > >> On 9-okt-04, at 21:57, Daniel Roesen wrote: > > >>> I've never seen anyone actually using RtConfig output for anything >>> else then destilling prefix/aspath lists from them in order to use >>> those in own generator tools. Given my own very basic and short >>> playing with RtConfig, I can somewhat understand why. >> >> >> >> It would make countless lives much easier if it were possible to >> submit a query to the db that gives back the desired output rather >> than having to use these very complex tools. > > > Not a huge ISP but I certainly build my access list and route-maps (and > the equivalent Procket policy stuff) using RtConfig with no other magic > involved. In my previous job at one of Australia's tier ones we did it > that way too. See AS7575 (current policy) and/or AS2764 (previous one) > for outrageous aut-num objects. I don't use inet-rtr objects though. > > Personally I don't think driving RtConfig is all that difficult. > I have the same feeling. RPSL (and its ng variant) tend to become more complex (but hay life in terms of policy is complex too). So you need to invest almost 2 man months to have everything expressed in RPSL. Inet-rtr is too much for ISP operations and to be frank I do not beleive that irtr can be realistic in terms of description of a real life situation. I do not beleive that router configuration is terms of interface configurartion needs automatic tools. I beleive that the routing policy automatic configuration sould be our mission. I do not want to boast over what we have succeeded in GRNET. We have managed to describe our real life but yet complex policy in RPSL. All of our clients have either private or public AS. The route-maps and ACL are generated by RTConfig. Dimitrios, > Mark. -- -- Dimitrios K. Kalogeras Electrical Engineer Ph.D. Network Manager NTUA/GR-Net Network Management Center _____________________________________ icq: 11887484 voice: +30-210-772 1863 fax: +30-210-772 1866 e-mail: D.Kalogeras at noc.ntua.gr pub 1024D/F2A69A72 2002-12-13 Dimitrios Kalogeras Key fingerprint = 64C5 646D 8D33 A3FF 14D1 66C6 5127 54CC F2A6 9A72 From david.kessens at nokia.com Sat Oct 16 03:26:12 2004 From: david.kessens at nokia.com (David Kessens) Date: Fri, 15 Oct 2004 18:26:12 -0700 Subject: [ipv6-wg@ripe.net] IPv6 wg minutes RIPE47 Message-ID: <20041016012612.GA1594@nokia.com> Please see below for the minutes of RIPE 47 as approved during last working group 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-route.pdf C. Global IPv6 routing table status (Gert Doering) http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-ipv6-global-routing.pdf 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-disco.pdf - 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-peering.pdf F. Developments/initiatives regarding IPv6 in the RIPE region and beyond - latest IPv6 Land Speed Record (Edoardo Martelli (CERN)) --- From david.kessens at nokia.com Sat Oct 16 03:30:33 2004 From: david.kessens at nokia.com (David Kessens) Date: Fri, 15 Oct 2004 18:30:33 -0700 Subject: [ipv6-wg@ripe.net] IPv6 wg minutes RIPE48 Message-ID: <20041016013033.GB1594@nokia.com> Please see below for the minutes of RIPE 48 as approved during the working group session in Manchester. Only a few minor typographical corrections were made compared to the draft minutes as posted earlier. I hope this helps, David Kessens --- 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 at bit.nl or pim at ipng.nl B. Global IPv6 routing table status (Gert Doering, SPACENET) 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: 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) 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 at bit.nl or pim at 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) - 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 Vodafone, TeliaSonera and others) ACTION on Chair - keep this agenda point as an ongoing action. ACTION on community - send feedback for next RIPE meeting J. IPv6 home automation (Jordi Palet Martinez, Consulintel) There is a commercial powerline connectivity service operating in Spain, and other countries, which started with a big trial (3.000) in Zaragoza. Currently in IPv4 but possibly in IPv6 in future (some customers are using IPv6 but on experimental basis for the 6POWER project). 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/ From filiz at ripe.net Mon Oct 18 16:27:44 2004 From: filiz at ripe.net (Filiz Yilmaz) Date: Mon, 18 Oct 2004 16:27:44 +0200 Subject: [ipv6-wg@ripe.net] New IPv6 Address Block Allocated to RIPE NCC Message-ID: <20041018142743.GI9943@x13.ripe.net> Dear Colleagues, The RIPE NCC received the IPv6 address range 2001:4A00::/23 from the IANA in October 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: Regards, -- Filiz Yilmaz RIPE NCC From ljb at merit.edu Wed Oct 20 22:39:42 2004 From: ljb at merit.edu (Larry J. Blunk) Date: Wed, 20 Oct 2004 16:39:42 -0400 Subject: [db-wg] Re: [ipv6-wg@ripe.net] RPSLng database deployment? In-Reply-To: <20041007085206.GA25644@srv01.cluenet.de> References: <20041006212347.GA23610@obelix.birkenwald.intern> <4164F3B2.4010502@ripe.net> <20041007085206.GA25644@srv01.cluenet.de> Message-ID: <200410201639.42434.ljb@merit.edu> FYI, Merit announced production support of RPSLng in the RADB registry yesterday at NANOG. We also now support native IPv6 queries of the RADB. We decided not to add an AAAA record to whois.radb.net and have instead created a new name -- whois-v6.radb.net -- for the IPv6 address (v6.radb.net works as well). Finally, we've created a new mail list at irrc at merit.edu (subscribe at irrc-request at merit.edu) to discuss IRR coordination issues. The presentation is available at http://www.nanog.org/mtg-0410/pdf/blunk.pdf Regards, Larry Blunk Merit From cfriacas at fccn.pt Fri Oct 29 17:20:21 2004 From: cfriacas at fccn.pt (Carlos Friacas) Date: Fri, 29 Oct 2004 16:20:21 +0100 (WEST) Subject: [ipv6-wg@ripe.net] rootzone -> .com and .net in place :-) Message-ID: Hi, Anybody noticed this? Connectivity still not that good to 2001:503:..., however, happy to have it in place :-) They "IPv6-ized" A and B (2 out of 13 servers). -------------------- ; <<>> DiG 8.3 <<>> @192.5.5.241 com ns ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 15 ;; QUERY SECTION: ;; com, type = NS, class = IN ;; AUTHORITY SECTION: com. 2D IN NS C.GTLD-SERVERS.NET. com. 2D IN NS D.GTLD-SERVERS.NET. com. 2D IN NS E.GTLD-SERVERS.NET. com. 2D IN NS F.GTLD-SERVERS.NET. com. 2D IN NS G.GTLD-SERVERS.NET. com. 2D IN NS H.GTLD-SERVERS.NET. com. 2D IN NS I.GTLD-SERVERS.NET. com. 2D IN NS J.GTLD-SERVERS.NET. com. 2D IN NS K.GTLD-SERVERS.NET. com. 2D IN NS L.GTLD-SERVERS.NET. com. 2D IN NS M.GTLD-SERVERS.NET. com. 2D IN NS A.GTLD-SERVERS.NET. com. 2D IN NS B.GTLD-SERVERS.NET. ;; ADDITIONAL SECTION: A.GTLD-SERVERS.NET. 2D IN A 192.5.6.30 A.GTLD-SERVERS.NET. 2D IN AAAA 2001:503:a83e::2:30 B.GTLD-SERVERS.NET. 2D IN A 192.33.14.30 B.GTLD-SERVERS.NET. 2D IN AAAA 2001:503:231d::2:30 C.GTLD-SERVERS.NET. 2D IN A 192.26.92.30 D.GTLD-SERVERS.NET. 2D IN A 192.31.80.30 E.GTLD-SERVERS.NET. 2D IN A 192.12.94.30 F.GTLD-SERVERS.NET. 2D IN A 192.35.51.30 G.GTLD-SERVERS.NET. 2D IN A 192.42.93.30 H.GTLD-SERVERS.NET. 2D IN A 192.54.112.30 I.GTLD-SERVERS.NET. 2D IN A 192.43.172.30 J.GTLD-SERVERS.NET. 2D IN A 192.48.79.30 K.GTLD-SERVERS.NET. 2D IN A 192.52.178.30 L.GTLD-SERVERS.NET. 2D IN A 192.41.162.30 M.GTLD-SERVERS.NET. 2D IN A 192.55.83.30 ;; Total query time: 12 msec ;; FROM: atlas.fccn.pt to SERVER: 192.5.5.241 ;; WHEN: Fri Oct 29 16:16:43 2004 ;; MSG SIZE sent: 21 rcvd: 509 ; <<>> DiG 8.3 <<>> @192.5.5.241 net ns ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 15 ;; QUERY SECTION: ;; net, type = NS, class = IN ;; AUTHORITY SECTION: net. 2D IN NS J.GTLD-SERVERS.net. net. 2D IN NS K.GTLD-SERVERS.net. net. 2D IN NS L.GTLD-SERVERS.net. net. 2D IN NS M.GTLD-SERVERS.net. net. 2D IN NS A.GTLD-SERVERS.net. net. 2D IN NS B.GTLD-SERVERS.net. net. 2D IN NS C.GTLD-SERVERS.net. net. 2D IN NS D.GTLD-SERVERS.net. net. 2D IN NS E.GTLD-SERVERS.net. net. 2D IN NS F.GTLD-SERVERS.net. net. 2D IN NS G.GTLD-SERVERS.net. net. 2D IN NS H.GTLD-SERVERS.net. net. 2D IN NS I.GTLD-SERVERS.net. ;; ADDITIONAL SECTION: A.GTLD-SERVERS.net. 2D IN A 192.5.6.30 A.GTLD-SERVERS.net. 2D IN AAAA 2001:503:a83e::2:30 B.GTLD-SERVERS.net. 2D IN A 192.33.14.30 B.GTLD-SERVERS.net. 2D IN AAAA 2001:503:231d::2:30 C.GTLD-SERVERS.net. 2D IN A 192.26.92.30 D.GTLD-SERVERS.net. 2D IN A 192.31.80.30 E.GTLD-SERVERS.net. 2D IN A 192.12.94.30 F.GTLD-SERVERS.net. 2D IN A 192.35.51.30 G.GTLD-SERVERS.net. 2D IN A 192.42.93.30 H.GTLD-SERVERS.net. 2D IN A 192.54.112.30 I.GTLD-SERVERS.net. 2D IN A 192.43.172.30 J.GTLD-SERVERS.net. 2D IN A 192.48.79.30 K.GTLD-SERVERS.net. 2D IN A 192.52.178.30 L.GTLD-SERVERS.net. 2D IN A 192.41.162.30 M.GTLD-SERVERS.net. 2D IN A 192.55.83.30 ;; Total query time: 8 msec ;; FROM: atlas.fccn.pt to SERVER: 192.5.5.241 ;; WHEN: Fri Oct 29 16:18:33 2004 ;; MSG SIZE sent: 21 rcvd: 506 ./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!" From pim at ipng.nl Fri Oct 29 17:45:58 2004 From: pim at ipng.nl (Pim van Pelt) Date: Fri, 29 Oct 2004 17:45:58 +0200 Subject: [ipv6-wg@ripe.net] rootzone -> .com and .net in place :-) In-Reply-To: References: Message-ID: <20041029154558.GA16703@bfib.ipng.nl> On Fri, Oct 29, 2004 at 04:20:21PM +0100, Carlos Friacas wrote: | | Hi, | | Anybody noticed this? | | Connectivity still not that good to 2001:503:..., however, happy to have | it in place :-) This is very good news (thanks for bringing it :) | They "IPv6-ized" A and B (2 out of 13 servers). traceroute6 to 2001:503:231d::2:30 (2001:503:231d::2:30) from 2001:7b8:3:1000:260:8ff:fe46:4b3f, 64 hops max, 12 byte packets 1 office-gw.ipv6.network.bit.nl 0.436 ms 0.379 ms 0.295 ms 2 colo0-gw.ipv6.network.bit.nl 0.792 ms 0.676 ms 0.840 ms 3 jun1.telecity.ipv6.network.bit.nl 1.652 ms 1.645 ms 1.629 ms 4 sara.ams-ix.juniper-1.ipv6.network.scarlet.nl 2.253 ms 2.197 ms 2.105 ms 5 nikhef.ams-ix.ipv6.intouch.net 2.622 ms 2.586 ms 2.563 ms 6 3ffe:800::fffb:0:0:5 178.345 ms 178.789 ms 180.273 ms 7 isi-lap-enterzone-gw.cmh.ipv6.ENTERZONE.NET 248.952 ms 398.686 ms 247.995 ms 8 sl-bb1v6-rly-t-73.sprintv6.net 223.757 ms 223.650 ms 223.266 ms 9 sl-bb1v6-nyc-t-1000.sprintv6.net 233.280 ms 231.642 ms 231.314 ms 10 3ffe:2900:2001:3::2 240.155 ms !P 242.280 ms !P 234.123 ms !P Both addresses accept my connections to TCP port 53 though, that's nice too :) -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim at ipng.nl http://www.ipng.nl/ IPv6 Deployment -----------------------------------------------