From bruno at flashnet.it Wed Dec 6 13:25:16 2000 From: bruno at flashnet.it (Bruno Ciscato) Date: Wed, 06 Dec 2000 13:25:16 +0100 Subject: Allocations for "always-on" ISPs Message-ID: <4.3.2.7.2.20001206130105.00decea0@amsterdam.cisco.com> Hi! With the advent of technologies like ADSL and Ethernet to the home, several new ISP in Europe are starting to offer "always on" Internet access. The allocation strategies vary, if they give a subnet to each household this is usually a /29, if they group more than one household in each subnet the average IPv4 address consumption by each household can be a little less. In any case they need a lot of addresses, i.e. a few millions. Can someone help me to see if what I think it would happen is correct? 1) they request address space to RIPE, with a nicely written documentation that clearly shows that they need millions of addresses 2) nonetheless they won't receive more than a /20 to begin with 3) when they have used more than 80% of this /20, and can prove it, another one will be assigned, most likely not contiguous 4) and so on and so forth, at a very fast pace, until they will have a very fragmented address space Is this correct ? Is it safe to assume that if they start using public address, where really needed, they will always receive new allocations if they can prove they need it until IPv4 addresses last ? Is there any way to reduce the address space fragmentation due to new non contiguous allocations ? Thanks bruno From neil at COLT.NET Wed Dec 6 17:36:38 2000 From: neil at COLT.NET (Neil J. McRae) Date: Wed, 6 Dec 2000 16:36:38 +0000 (GMT) Subject: Allocations for "always-on" ISPs In-Reply-To: <4.3.2.7.2.20001206130105.00decea0@amsterdam.cisco.com> from Bruno Ciscato at "Dec 6, 2000 01:25:16 pm" Message-ID: <200012061636.QAA29207@NetBSD.noc.COLT.NET> NAT is your friend - very few home users need real IP addresses. > Hi! > With the advent of technologies like ADSL and Ethernet to the home, several new ISP in Europe are starting to offer "always on" Internet access. > The allocation strategies vary, if they give a subnet to each household this is usually a /29, if they group more than one household in each subnet the average IPv4 address consumption by each household can be a little less. > In any case they need a lot of addresses, i.e. a few millions. > Can someone help me to see if what I think it would happen is correct? > 1) they request address space to RIPE, with a nicely written documentation that clearly shows that they need millions of addresses > 2) nonetheless they won't receive more than a /20 to begin with > 3) when they have used more than 80% of this /20, and can prove it, another one will be assigned, most likely not contiguous > 4) and so on and so forth, at a very fast pace, until they will have a very fragmented address space > Is this correct ? > Is it safe to assume that if they start using public address, where really needed, they will always receive new allocations if they can prove they need it until IPv4 addresses last ? > Is there any way to reduce the address space fragmentation due to new non contiguous allocations ? > > Thanks > > bruno > > > From denesh at cyberstrider.net Wed Dec 6 17:44:57 2000 From: denesh at cyberstrider.net (Denesh Bhabuta) Date: Wed, 06 Dec 2000 16:44:57 +0000 Subject: Allocations for "always-on" ISPs In-Reply-To: <4.3.2.7.2.20001206130105.00decea0@amsterdam.cisco.com> Message-ID: <4.3.2.20001206163155.04474bf0@mail.own.cyberstrider.net> At 12:25 06/12/00, Bruno Ciscato wrote: >With the advent of technologies like ADSL and Ethernet to the home, >several new ISP in Europe are starting to offer "always on" Internet access. >The allocation strategies vary, if they give a subnet to each household >this is usually a /29, if they group more than one household in each >subnet the average IPv4 address consumption by each household can be a >little less. Ahem! You mean Assignment strategy. ;) (Allocation is what RIPE NCC gives the LIR, Assignment is what the LIR gives to it's customer) Why a /29? Why not a /30? On the other hand, why not /32 assignments to a customer, just like in a static IP dialup where the customer uses NAT? Alternatively, have your DSL network covered in RFC 1918 addresses and do DHCP addressing within that to end users. >In any case they need a lot of addresses, i.e. a few millions. >Can someone help me to see if what I think it would happen is correct? >1) they request address space to RIPE, with a nicely written documentation >that clearly shows that they need millions of addresses >2) nonetheless they won't receive more than a /20 to begin with This is correct.. you need to prove that you need those millions of addresses first. Most DSL IP requirements currently, AFAICS, are based on projection figures in an unknown market. Has DSL actually taken off in a big a way as was predicted 6 months ago? >3) when they have used more than 80% of this /20, and can prove >it, another one will be assigned, most likely not contiguous However if you have quickly used up this /20, I do not see why the next block will not be contiguous.. if according to your requirements you need millions of addresses then these should fill up pretty quickly. >Is there any way to reduce the address space fragmentation due to new non >contiguous allocations ? I guess you need to use up your allocated block quickly enough to allow you to get the next contiguous block. :) Regards Denesh -- Denesh Bhabuta Chairman, CEO and Principal Consultant Cyberstrider Limited www.cyberstrider.net Internet and E-Commerce: Strategy, Consultancy and Solutions From kurtis at kpnqwest.net Thu Dec 7 08:47:30 2000 From: kurtis at kpnqwest.net (Kurt Erik Lindqvist) Date: Thu, 7 Dec 2000 08:47:30 +0100 (MET) Subject: Allocations for "always-on" ISPs In-Reply-To: <200012061636.QAA29207@NetBSD.noc.COLT.NET> Message-ID: That ofcourse depends on what services you want to offer your customers..... I don't see why you want to break services in order to solve assignment policies? This said, I do realise that there is a assignment policy aspect to this as well. - kurtis - > NAT is your friend - very few home users need real IP addresses. > > > > Hi! > > With the advent of technologies like ADSL and Ethernet to the home, several new ISP in Europe are starting to offer "always on" Internet access. > > The allocation strategies vary, if they give a subnet to each household this is usually a /29, if they group more than one household in each subnet the average IPv4 address consumption by each household can be a little less. > > In any case they need a lot of addresses, i.e. a few millions. > > Can someone help me to see if what I think it would happen is correct? > > 1) they request address space to RIPE, with a nicely written documentation that clearly shows that they need millions of addresses > > 2) nonetheless they won't receive more than a /20 to begin with > > 3) when they have used more than 80% of this /20, and can prove it, another one will be assigned, most likely not contiguous > > 4) and so on and so forth, at a very fast pace, until they will have a very fragmented address space > > Is this correct ? > > Is it safe to assume that if they start using public address, where really needed, they will always receive new allocations if they can prove they need it until IPv4 addresses last ? > > Is there any way to reduce the address space fragmentation due to new non contiguous allocations ? > > > > Thanks > > > > bruno > > > > > > > > > Kurt Erik Lindqvist Kurtis.Lindqvist at KPNQwest.SE KPNQwest Sweden @ The speed of light http://www.kpnqwest.se PO Box 23163 S-10435 Stockholm From Phil.Sykes at cweurope.net Thu Dec 7 10:57:30 2000 From: Phil.Sykes at cweurope.net (Sykes, Phil) Date: Thu, 7 Dec 2000 10:57:30 +0100 Subject: Allocations for "always-on" ISPs Message-ID: >> Is there any way to reduce the address space fragmentation >> due to new non contiguous allocations ? > > I guess you need to use up your allocated block quickly > enough to allow you to get the next contiguous block. :) Also worth noting - your initial allocation can be larger than a /20 if you can convince RIPE that it will be needed quickly, and any further allocation will be of a size representative of how quickly you have used your current address space. Thus, if you burn through a /20 in a week, your next allocation will be somewhat larger. The figures for how quickly you have to go to justify larger address blocks are, I guess, not published. Cheers, Phil Sykes, Network Engineer Cable & Wireless Global Network p: +49 89 92699 204 m: +49 172 89 79 727 From nurani at ripe.net Thu Dec 7 12:16:20 2000 From: nurani at ripe.net (Nurani Nimpuno) Date: Thu, 07 Dec 2000 12:16:20 +0100 Subject: Allocations for "always-on" ISPs In-Reply-To: Your message of Wed, 06 Dec 2000 13:25:16 +0100. <4.3.2.7.2.20001206130105.00decea0@amsterdam.cisco.com> References: <4.3.2.7.2.20001206130105.00decea0@amsterdam.cisco.com> Message-ID: <200012071116.MAA00366@x7.ripe.net> Dear Bruno, Bruno Ciscato writes: * Hi! * With the advent of technologies like ADSL and Ethernet to the home, several * new ISP in Europe are starting to offer "always on" Internet access. * The allocation strategies vary, if they give a subnet to each household this * is usually a /29, if they group more than one household in each subnet the * average IPv4 address consumption by each household can be a little less. * In any case they need a lot of addresses, i.e. a few millions. * Can someone help me to see if what I think it would happen is correct? * 1) they request address space to RIPE, with a nicely written documentation t * hat clearly shows that they need millions of addresses * 2) nonetheless they won't receive more than a /20 to begin with It is correct that all LIRs receive a /20 as a *first* Allocation. This is to ensure a fair distribution of address space. * 3) when they have used more than 80% of this /20, and can prove it, another * one will be assigned, most likely not contiguous This is not entirely correct. Yes, the LIR does need to show 80% utilisation. Depending on how quickly the LIR comes back, the LIR might be able to get a contiguous block of addresses. If the first allocation is used up very quickly, the higher the chances that the next allocation is contiguous. The future allocations are not necessarily a /20 however. Based on the utilisation rate of the initial /20 Allocation, the LIR will receive an allocation, presumably large enough to cover the need in the following two years. In other words: the first allocation is a /20, the future allocation is based on the utilisation rate. If the second allocation is larger than a /20 and there is a /20 contiguous to first allocation available, the LIR is asked whether they want the contiguous /20 plus another separate range to cover the full needs, or if they prefer getting the entire second (larger) allocation from a separate address range. Hope this made things clearer. Cheers, -- Nurani Nimpuno Registration Services Manager RIPE NCC As Bhabuta pointed out, this depends * 4) and so on and so forth, at a very fast pace, until they will have a very * fragmented address space * Is this correct ? * Is it safe to assume that if they start using public address, where really n * eeded, they will always receive new allocations if they can prove they need * it until IPv4 addresses last ? * Is there any way to reduce the address space fragmentation due to new non co * ntiguous allocations ? * * Thanks * * bruno * * * From jee at alcom.aland.fi Thu Dec 7 12:19:41 2000 From: jee at alcom.aland.fi (Jan-Erik Eriksson) Date: Thu, 7 Dec 2000 13:19:41 +0200 (EET) Subject: Allocations for "always-on" ISPs In-Reply-To: Message-ID: On Thu, 7 Dec 2000, Kurt Erik Lindqvist wrote: > >That ofcourse depends on what services you want to offer your >customers..... > >I don't see why you want to break services in order to solve assignment >policies? This said, I do realise that there is a assignment policy aspect >to this as well. > >- kurtis - I agree. >> NAT is your friend - very few home users need real IP addresses. More like an uninvited guest, I would say. NAT severely restricts the range of services you can offer and will give you problems in the future. -- Janne >> >> >> > Hi! >> > With the advent of technologies like ADSL and Ethernet to the home, several new ISP in Europe are starting to offer "always on" Internet access. >> > The allocation strategies vary, if they give a subnet to each household this is usually a /29, if they group more than one household in each subnet the average IPv4 address consumption by each household can be a little less. >> > In any case they need a lot of addresses, i.e. a few millions. >> > Can someone help me to see if what I think it would happen is correct? >> > 1) they request address space to RIPE, with a nicely written documentation that clearly shows that they need millions of addresses >> > 2) nonetheless they won't receive more than a /20 to begin with >> > 3) when they have used more than 80% of this /20, and can prove it, another one will be assigned, most likely not contiguous >> > 4) and so on and so forth, at a very fast pace, until they will have a very fragmented address space >> > Is this correct ? >> > Is it safe to assume that if they start using public address, where really needed, they will always receive new allocations if they can prove they need it until IPv4 addresses last ? >> > Is there any way to reduce the address space fragmentation due to new non contiguous allocations ? >> > >> > Thanks >> > >> > bruno >> > >> > >> > >> >> >> > >Kurt Erik Lindqvist Kurtis.Lindqvist at KPNQwest.SE >KPNQwest Sweden @ The speed of light http://www.kpnqwest.se >PO Box 23163 >S-10435 Stockholm > > ------------- Elcom ------------- Network Operations Center --------- Jan-Erik Eriksson mailto: jee at alcom.aland.fi Elcom phone: +358 18 23500 PB 233, Torggatan 10 fax: +358 18 14643 FIN-22100 Mariehamn URL: http://www.alcom.aland.fi From denesh at cyberstrider.net Thu Dec 7 12:27:17 2000 From: denesh at cyberstrider.net (Denesh Bhabuta) Date: Thu, 07 Dec 2000 11:27:17 +0000 Subject: Allocations for "always-on" ISPs In-Reply-To: References: <200012061636.QAA29207@NetBSD.noc.COLT.NET> Message-ID: <4.3.2.20001207112251.03ddb840@mail.own.cyberstrider.net> At 07:47 07/12/00, Kurt Erik Lindqvist wrote: >That ofcourse depends on what services you want to offer your >customers..... >I don't see why you want to break services in order to solve assignment >policies? This said, I do realise that there is a assignment policy aspect >to this as well. Yes.. in exactly the same way in any other traditional business (say building or something), the builders will not commit to building something for a customer if certain special materials the customer wants are not available. Thus, products you want to offer customers should be specified based on what you can supply.. not on a dream. If it is not a realistic product, no matter how much a customer wants it, then how can one supply it? I come across this every day where product managers spec up a product to make it sound nice and then argue with the tech departments for causing a slow down in sales. :( Regards Denesh -- Denesh Bhabuta Chairman, CEO and Principal Consultant Cyberstrider Limited www.cyberstrider.net Internet and E-Commerce: Strategy, Consultancy and Solutions From skals at cybercity.dk Thu Dec 7 12:29:22 2000 From: skals at cybercity.dk (Simon Skals) Date: Thu, 07 Dec 2000 12:29:22 +0100 Subject: Allocations for "always-on" ISPs In-Reply-To: References: <200012061636.QAA29207@NetBSD.noc.COLT.NET> Message-ID: <4.3.2.20001207120514.01fd3cb0@www4.cybercity.dk> It seems Kurt Erik Lindqvist wrote: >That ofcourse depends on what services you want to offer your >customers..... > >I don't see why you want to break services in order to solve assignment >policies? This said, I do realise that there is a assignment policy aspect >to this as well. You might realise that you will end up breaking promises to customers if the offered services collide with acceptable assignment policies. While it is - at first - easy for an ISP to hand out /29's to home users, I really hope that the RIPE NCC will make an effort to prevent service providers from offering this as an off-the-shelf product for Mr. and Mrs. Always-On. We are going to run out of IPv4 space very quickly if the assignment of, for instance, /29's to home users becomes standard procedure at ISP's - and bruno's mail does indicate that this is already happening: "[...]several new ISP in Europe are starting to offer "always on" Internet access. The allocation strategies vary, if they give a subnet to each household this is usually a /29 [...]" Has the RIPE NCC seen any signs of this actually being a trend? If so, is it seen as an acceptable assignment policy? Being an IP bloke with a conscience, I would personally hate to provide our regular home users with /29's. However, should our competitors start doing this, we would of course have to respond. It would be a shame, however, if the commercial struggles should end up leading to a swift exhaustion of IPv4 space. Cheers /Simon From neil at COLT.NET Thu Dec 7 12:32:36 2000 From: neil at COLT.NET (Neil J. McRae) Date: Thu, 7 Dec 2000 11:32:36 +0000 (GMT) Subject: Allocations for "always-on" ISPs In-Reply-To: from Jan-Erik Eriksson at "Dec 7, 2000 01:19:41 pm" Message-ID: <200012071132.LAA06753@NetBSD.noc.COLT.NET> > More like an uninvited guest, I would say. NAT severely restricts the > range of services you can offer and will give you problems in the > future. Perhaps you could expand on what NAT restricts and why it will give you problems? Regards, Neil. From jee at alcom.aland.fi Thu Dec 7 14:01:54 2000 From: jee at alcom.aland.fi (Jan-Erik Eriksson) Date: Thu, 7 Dec 2000 15:01:54 +0200 (EET) Subject: Allocations for "always-on" ISPs In-Reply-To: <200012071132.LAA06753@NetBSD.noc.COLT.NET> Message-ID: On Thu, 7 Dec 2000, Neil J. McRae wrote: >> More like an uninvited guest, I would say. NAT severely restricts the >> range of services you can offer and will give you problems in the >> future. > >Perhaps you could expand on what NAT restricts and why it will >give you problems? Certainly. NAT:ed addresses means that the customers' (private) address is not reachable from outside the point in which you do the NAT. This point resides within the primary (point of sale) operator's network. Now, say that an ASP wants to offer some service to your customers (generating traffic = revenue) which has a communication pattern in which the ASP needs to connect to the customer's PC. Because of NAT, this is not possible. A common application is remote access by IPSEC connections from mobile/residential users to the office. IPSEC+NAT is not a good combination. It has been known to work through NAT under some special circumstances, but typically gives you problems. The fact is that the customers' addresses are not reachable from outside the NAT:ed area. This limits your ability to provide services to your customers. NAT may be used successfully in some scenarios, and unsuccessfully in others. In my opinion, it should be every operator's choice whether to deploy NAT, and not regulated by eg RIPE, and hence should not be considered as a solution for the "always-on" allocation problem. Kindly, -- Janne ------------- Elcom ------------- Network Operations Center --------- Jan-Erik Eriksson mailto: jee at alcom.aland.fi Elcom phone: +358 18 23500 PB 233, Torggatan 10 fax: +358 18 14643 FIN-22100 Mariehamn URL: http://www.alcom.aland.fi From neil at COLT.NET Thu Dec 7 14:04:22 2000 From: neil at COLT.NET (Neil J. McRae) Date: Thu, 7 Dec 2000 13:04:22 +0000 (GMT) Subject: Allocations for "always-on" ISPs In-Reply-To: from Jan-Erik Eriksson at "Dec 7, 2000 03:01:54 pm" Message-ID: <200012071304.NAA07330@NetBSD.noc.COLT.NET> > NAT:ed addresses means that the customers' (private) address is not > reachable from outside the point in which you do the NAT. This point > resides within the primary (point of sale) operator's network. > > Now, say that an ASP wants to offer some service to your customers > (generating traffic = revenue) which has a communication pattern in which > the ASP needs to connect to the customer's PC. Because of NAT, this is not > possible. Yes it is, you just have to put in the configuration. > > A common application is remote access by IPSEC connections from > mobile/residential users to the office. IPSEC+NAT is not a good > combination. It has been known to work through NAT under some > special circumstances, but typically gives you problems. This is true. > The fact is that the customers' addresses are not reachable from outside > the NAT:ed area. This limits your ability to provide services to your > customers. Some services yes but not all. > NAT may be used successfully in some scenarios, and unsuccessfully in > others. In my opinion, it should be every operator's choice whether to > deploy NAT, and not regulated by eg RIPE, and hence should not be > considered as a solution for the "always-on" allocation problem. I 100% agree. Neil. From jee at alcom.aland.fi Thu Dec 7 14:40:16 2000 From: jee at alcom.aland.fi (Jan-Erik Eriksson) Date: Thu, 7 Dec 2000 15:40:16 +0200 (EET) Subject: Allocations for "always-on" ISPs In-Reply-To: <4.3.2.20001207120514.01fd3cb0@www4.cybercity.dk> Message-ID: On Thu, 7 Dec 2000, Simon Skals wrote: >Being an IP bloke with a conscience, I would personally hate to provide our >regular home users with /29's. However, should our competitors start doing >this, we would of course have to respond. It would be a shame, however, if >the commercial struggles should end up leading to a swift exhaustion of >IPv4 space. Note that there are technologies available for always-on where you "only" need one IP-address per customer, not a /29-subnet. It is still routed, and they have no layer 2 connectivity. This works fine with eg ADSL. Of course, some network scenarios require a subnet. But it is up to every operator to decide what technology to use. RIPE could regulate this by refusing to allocate addresses for /29-technologies for residential usage. Just like they did in the past with allocating address space for WWW-hosting, in favor of IP-less virtual hosting. -- Janne ------------- Elcom ------------- Network Operations Center --------- Jan-Erik Eriksson mailto: jee at alcom.aland.fi Elcom phone: +358 18 23500 PB 233, Torggatan 10 fax: +358 18 14643 FIN-22100 Mariehamn URL: http://www.alcom.aland.fi From neil at COLT.NET Thu Dec 7 14:47:05 2000 From: neil at COLT.NET (Neil J. McRae) Date: Thu, 7 Dec 2000 13:47:05 +0000 (GMT) Subject: Allocations for "always-on" ISPs In-Reply-To: from Jan-Erik Eriksson at "Dec 7, 2000 03:45:10 pm" Message-ID: <200012071347.NAA07593@NetBSD.noc.COLT.NET> [Charset ISO-8859-1 unsupported, filtering to ASCII...] > On Thu, 7 Dec 2000, Neil J. McRae wrote: > > >> Now, say that an ASP wants to offer some service to your customers > >> (generating traffic = revenue) which has a communication pattern in which > >> the ASP needs to connect to the customer's PC. Because of NAT, this is not > >> possible. > > > >Yes it is, you just have to put in the configuration. Well depending on the service port mapping can be used to deliver services to customers - it doesn't work with everything but it does work - I used to use it for Napster. Regards, Neil. From jee at alcom.aland.fi Thu Dec 7 14:45:10 2000 From: jee at alcom.aland.fi (Jan-Erik Eriksson) Date: Thu, 7 Dec 2000 15:45:10 +0200 (EET) Subject: Allocations for "always-on" ISPs In-Reply-To: <200012071304.NAA07330@NetBSD.noc.COLT.NET> Message-ID: On Thu, 7 Dec 2000, Neil J. McRae wrote: >> Now, say that an ASP wants to offer some service to your customers >> (generating traffic = revenue) which has a communication pattern in which >> the ASP needs to connect to the customer's PC. Because of NAT, this is not >> possible. > >Yes it is, you just have to put in the configuration. Could you please elaborate this statement? Regards, -- Janne ------------- Elcom ------------- Network Operations Center --------- Jan-Erik Eriksson mailto: jee at alcom.aland.fi Elcom phone: +358 18 23500 PB 233, Torggatan 10 fax: +358 18 14643 FIN-22100 Mariehamn URL: http://www.alcom.aland.fi From lmb at suse.de Thu Dec 7 14:28:37 2000 From: lmb at suse.de (Lars Marowsky-Bree) Date: Thu, 7 Dec 2000 14:28:37 +0100 Subject: Allocations for "always-on" ISPs In-Reply-To: <4.3.2.20001207120514.01fd3cb0@www4.cybercity.dk>; from "Simon Skals" on 2000-12-07T12:29:22 References: <200012061636.QAA29207@NetBSD.noc.COLT.NET> <4.3.2.20001207120514.01fd3cb0@www4.cybercity.dk> Message-ID: <20001207142837.R671@marowsky-bree.de> On 2000-12-07T12:29:22, Simon Skals said: > We are going to run out of IPv4 space very quickly if the assignment of, > for instance, /29's to home users becomes standard procedure at ISP's - and > bruno's mail does indicate that this is already happening: Good good. Maybe that will finally push IPv6. Sincerely, Lars Marowsky-Brie -- Perfection is our goal, excellence will be tolerated. -- J. Yahl From neil at COLT.NET Thu Dec 7 15:20:42 2000 From: neil at COLT.NET (Neil J. McRae) Date: Thu, 7 Dec 2000 14:20:42 +0000 (GMT) Subject: Allocations for "always-on" ISPs In-Reply-To: from Jan-Erik Eriksson at "Dec 7, 2000 04:17:56 pm" Message-ID: <200012071420.OAA08006@NetBSD.noc.COLT.NET> > Yes it works, but is this realistic for a large customer base? You are > going to have a _lot_ of non-standard port services around that you need > to administer and coordinate with ASPs. I wouldn't propose that its going to solve every single possiblity but with some product development around it, it would possible solve around 40-50% of the average users requirements. i.e. run a web server on port 80 mail on 25. There are applications that will require real address space and if the user can justify it then they should be given it. > > Speaking for myself only, I do not consider it an alterative. > > Regards, > > -- Janne > > ------------- _lcom ------------- Network Operations Center --------- > Jan-Erik Eriksson mailto: jee at alcom.aland.fi > _lcom phone: +358 18 23500 > PB 233, Torggatan 10 fax: +358 18 14643 > FIN-22100 Mariehamn URL: http://www.alcom.aland.fi > > From jee at alcom.aland.fi Thu Dec 7 15:17:56 2000 From: jee at alcom.aland.fi (Jan-Erik Eriksson) Date: Thu, 7 Dec 2000 16:17:56 +0200 (EET) Subject: Allocations for "always-on" ISPs In-Reply-To: <200012071347.NAA07593@NetBSD.noc.COLT.NET> Message-ID: On Thu, 7 Dec 2000, Neil J. McRae wrote: >[Charset ISO-8859-1 unsupported, filtering to ASCII...] >> On Thu, 7 Dec 2000, Neil J. McRae wrote: >> >> >> Now, say that an ASP wants to offer some service to your customers >> >> (generating traffic = revenue) which has a communication pattern in which >> >> the ASP needs to connect to the customer's PC. Because of NAT, this is not >> >> possible. >> > >> >Yes it is, you just have to put in the configuration. > >Well depending on the service port mapping can be used to deliver >services to customers - it doesn't work with everything but it does >work - I used to use it for Napster. Yes it works, but is this realistic for a large customer base? You are going to have a _lot_ of non-standard port services around that you need to administer and coordinate with ASPs. Speaking for myself only, I do not consider it an alterative. Regards, -- Janne ------------- Elcom ------------- Network Operations Center --------- Jan-Erik Eriksson mailto: jee at alcom.aland.fi Elcom phone: +358 18 23500 PB 233, Torggatan 10 fax: +358 18 14643 FIN-22100 Mariehamn URL: http://www.alcom.aland.fi From netmaster at space.net Thu Dec 7 15:15:20 2000 From: netmaster at space.net (Gert Doering, Netmaster) Date: Thu, 7 Dec 2000 15:15:20 +0100 Subject: Allocations for "always-on" ISPs In-Reply-To: <200012071304.NAA07330@NetBSD.noc.COLT.NET>; from neil@COLT.NET on Thu, Dec 07, 2000 at 01:04:22PM +0000 References: <200012071304.NAA07330@NetBSD.noc.COLT.NET> Message-ID: <20001207151520.G1037@Space.Net> Hi, On Thu, Dec 07, 2000 at 01:04:22PM +0000, Neil J. McRae wrote: > > NAT:ed addresses means that the customers' (private) address is not > > reachable from outside the point in which you do the NAT. This point > > resides within the primary (point of sale) operator's network. [..] > > Yes it is, you just have to put in the configuration. Protocols like H.232 need special support in the NAT box to work at all, and even then, they break if the customer has more than one box that he wants to reach from the outside, like "a PC in the living room and one in the office", which could be done with a /29. While I do not advocate giving everybody a /29 (or a fixed address at all, for that matter), I don't think that NAT can be the answer for every customer network. Some are quite happy with NAT, others want to do things that are not supported by current NAT boxes, so we should not try to force NAT upon them. If the IPv4 address space runs out, let's go to IPv6... it's there :-) (but I agree it certainly needs more work). Gert Doering -- NetMaster -- SpaceNet GmbH Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From kj at eircom.net Thu Dec 7 16:18:14 2000 From: kj at eircom.net (Karl Jeacle) Date: Thu, 7 Dec 2000 15:18:14 +0000 Subject: Allocations for "always-on" ISPs Message-ID: <20001207151813.A54804@eircom.net> "Neil J. McRae" wrote: > NAT is your friend - very few home users need real IP addresses. True, but the problem is logging the NAT translations to track down abuse cases. Since attacks on other sites will appear to come from NAT pool address, it's impossible(?) to find out which NAT'd user had a particular public IP address at a particular time. Sure, you might know what private IP address they had, but how do you log the translations? I think this make it very difficult to justify using NAT in public ADSL/Cable environments. I've heard that NAT logging is somewhere on Cisco's roadmap, but until it's available, or some other scalable NAT logging solution is possible, it looks like public IP addresses are the only viable option. Karl From leigh at insnet.net Thu Dec 7 16:51:06 2000 From: leigh at insnet.net (Leigh Porter) Date: Thu, 07 Dec 2000 15:51:06 +0000 Subject: Allocations for "always-on" ISPs References: <200012071347.NAA07593@NetBSD.noc.COLT.NET> Message-ID: <3A2FB1EA.F5FB2129@insnet.net> "Neil J. McRae" wrote: And if they need address space the ASP knows, about, they can use some kind of tunneling mechanism back to the ASP network so they have consistant addressing, even if their providor uses dynamic addressing. -- Leigh Porter C&W > > [Charset ISO-8859-1 unsupported, filtering to ASCII...] > > On Thu, 7 Dec 2000, Neil J. McRae wrote: > > > > >> Now, say that an ASP wants to offer some service to your customers > > >> (generating traffic = revenue) which has a communication pattern in which > > >> the ASP needs to connect to the customer's PC. Because of NAT, this is not > > >> possible. > > > > > >Yes it is, you just have to put in the configuration. > > Well depending on the service port mapping can be used to deliver > services to customers - it doesn't work with everything but it does > work - I used to use it for Napster. > > Regards, > Neil. From kurtis at kpnqwest.net Thu Dec 7 16:14:01 2000 From: kurtis at kpnqwest.net (Kurt Erik Lindqvist) Date: Thu, 7 Dec 2000 16:14:01 +0100 (MET) Subject: Allocations for "always-on" ISPs In-Reply-To: <4.3.2.20001207120514.01fd3cb0@www4.cybercity.dk> Message-ID: > It seems Kurt Erik Lindqvist wrote: > >That ofcourse depends on what services you want to offer your > >customers..... > > > >I don't see why you want to break services in order to solve assignment > >policies? This said, I do realise that there is a assignment policy aspect > >to this as well. > > You might realise that you will end up breaking promises to customers if > the offered services collide with acceptable assignment policies. I do. That is why I wrote that I realise that this is a problem. But I am seeing more and more companies offering Internet connections while in reality what the customer is getting is more or less a Intranet connection. This is a complex issue that in the end is up to what the customer has bought. > We are going to run out of IPv4 space very quickly if the assignment of, > for instance, /29's to home users becomes standard procedure at ISP's - and > bruno's mail does indicate that this is already happening: > > "[...]several new ISP in Europe are starting to offer "always on" Internet > access. The interesting part is ofcourse not that people are offering it. The interesting part is how many do actually sign up? Always on Internet have been around in Europe since the early '80:s. The price might have been somewhat high for consumers though...:) As I pointed out earlier and others as well - Maybe buy starting to use the address space for what it was intended for (to provide a Internet connection) we can get a real push to go for another addressing scheme like IPv6 or IPv8 (just kidding). Or maybe something completly new. Best regards, - kurtis - Kurt Erik Lindqvist Kurtis.Lindqvist at KPNQwest.SE KPNQwest Sweden @ The speed of light http://www.kpnqwest.se PO Box 23163 S-10435 Stockholm From woeber at cc.univie.ac.at Thu Dec 7 16:43:07 2000 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 07 Dec 2000 16:43:07 MET-DST Subject: Allocations for "always-on" ISPs Message-ID: <009F43F5.3D4532FE.23@cc.univie.ac.at> [ individual addresses stripped... ] Leigh, =From: Leigh Porter =Subject: Re: Allocations for "always-on" ISPs = ="Neil J. McRae" wrote: = =And if they need address space the ASP knows, about, they can use some =kind of tunneling mechanism ...now I'm lost! What is the _some_ in "some kind of tunneling mechanism? And how do you propose to take care of the re-configuration on the customer's end for the tunnel? Dynamic DNS with TTL close to 0? Whater it is, it should be available for all of the "popular" operating systems, btw. =back to the ASP network so they have consistant addressing, even if their =providor uses dynamic addressing. Which requires some sort of (non-trivial?) static routing entries on the customer's end nodes and/or some sort of routing support by the "basic" transport provider. =-- =Leigh Porter =C&W If there is a reasonable solution for that, I'd really like to deploy that for my ADSL link (which only offers dynamic addresses ;-). Both for becoming a subnet in my universities LAN as well as for IPv6! Wilfried. _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber at CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From leigh at insnet.net Thu Dec 7 17:40:50 2000 From: leigh at insnet.net (Leigh Porter) Date: Thu, 07 Dec 2000 16:40:50 +0000 Subject: Allocations for "always-on" ISPs References: <009F43F5.3D4532FE.23@cc.univie.ac.at> Message-ID: <3A2FBD92.B88A7DF1@insnet.net> "Wilfried Woeber, UniVie/ACOnet" wrote: > > [ individual addresses stripped... ] > > Leigh, > > =From: Leigh Porter > =Subject: Re: Allocations for "always-on" ISPs > = > ="Neil J. McRae" wrote: > = > =And if they need address space the ASP knows, about, they can use some > =kind of tunneling mechanism > > ...now I'm lost! > What is the _some_ in "some kind of tunneling mechanism? And how do you > propose to take care of the re-configuration on the customer's end for > the tunnel? Dynamic DNS with TTL close to 0? Whater it is, it should be > available for all of the "popular" operating systems, btw. Why do you need dynamic DNS? The user turns their box on, their DSL is up and their tunnel client connects to the tunnel server at the ASP site, gets an address and knows how to route to the ASP network and the ASP network knows how to get to the users machine. GRE/IPIP tunnels are very avaliable, not sure about pptp though or anything else that could be used. > =back to the ASP network so they have consistant addressing, even if their > =providor uses dynamic addressing. > > Which requires some sort of (non-trivial?) static routing entries on the > customer's end nodes and/or some sort of routing support by the "basic" > transport provider. No, the ASP network just needs to know that it gets to its customers down tunnels and the customers box should have software intelligent enough to do "route add 10.9.8.0/24 gw tunnel1" Then anything for the ASP gets to go down the tunnel right to their front door and anything for the net goes out the usual route via their NAT things. It also does a lot for security because the ASP boxes do not have to be on routable address space. I do not know what kind of clients these ASP things use though. This is being used now, how do you think lots of people get to their corporate networks from their hotel/whatever dialups? They use pptp or somethig like that, connect to the net, then to their pptp server and talk to their company VPN over that, encrypted probobly. -- Leigh Porter C&W From nick.hueni at cablecom.ch Fri Dec 8 09:32:21 2000 From: nick.hueni at cablecom.ch (=?ISO-8859-1?B?TmljayBI/G5p?=) Date: Fri, 08 Dec 2000 09:32:21 +0100 Subject: Allocations for "always-on" ISPs Message-ID: Why don't you guys use the newsgroups instead of "spamming" your opinions all over busy people... Thnaks. Nick >>> Kurt Erik Lindqvist 12/07/00 17:01 PM >>> > It seems Kurt Erik Lindqvist wrote: > >That ofcourse depends on what services you want to offer your > >customers..... > > > >I don't see why you want to break services in order to solve assignment > >policies? This said, I do realise that there is a assignment policy aspect > >to this as well. > > You might realise that you will end up breaking promises to customers if > the offered services collide with acceptable assignment policies. I do. That is why I wrote that I realise that this is a problem. But I am seeing more and more companies offering Internet connections while in reality what the customer is getting is more or less a Intranet connection. This is a complex issue that in the end is up to what the customer has bought. > We are going to run out of IPv4 space very quickly if the assignment of, > for instance, /29's to home users becomes standard procedure at ISP's - and > bruno's mail does indicate that this is already happening: > > "[...]several new ISP in Europe are starting to offer "always on" Internet > access. The interesting part is ofcourse not that people are offering it. The interesting part is how many do actually sign up? Always on Internet have been around in Europe since the early '80:s. The price might have been somewhat high for consumers though...:) As I pointed out earlier and others as well - Maybe buy starting to use the address space for what it was intended for to provide a Internet connection) we can get a real push to go for another addressing scheme like IPv6 or IPv8 (just kidding). Or maybe something completly new. Best regards, - kurtis - Kurt Erik Lindqvist Kurtis.Lindqvist at KPNQwest.SE KPNQwest Sweden @ The speed of light http://www.kpnqwest.se PO Box 23163 S-10435 Stockholm From netmaster at space.net Fri Dec 8 11:06:06 2000 From: netmaster at space.net (Gert Doering, Netmaster) Date: Fri, 8 Dec 2000 11:06:06 +0100 Subject: Allocations for "always-on" ISPs In-Reply-To: ; from nick.hueni@cablecom.ch on Fri, Dec 08, 2000 at 09:32:21AM +0100 References: Message-ID: <20001208110606.J1037@Space.Net> Hi, On Fri, Dec 08, 2000 at 09:32:21AM +0100, Nick H|ni wrote: > Why don't you guys use the newsgroups instead of "spamming" your opinions all over busy people... The RIPE-LIR mailing list is there for *exactly* this purpose: doing policy discussions in the RIPE community. If you're not able to handle this little amount of e-mail, and don't care about LIR policies, maybe you should unsubscribe and quit trying to be ISP. Gert Doering -- NetMaster -- SpaceNet GmbH Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From graham at nsl.net Fri Dec 8 11:18:27 2000 From: graham at nsl.net (Graham Burke) Date: Fri, 8 Dec 2000 10:18:27 +0000 Subject: Allocations for "always-on" ISPs In-Reply-To: References: Message-ID: <00120810532300.00547@tabitha.nsl.net> Yeah dammit how dare you use an LIR mailing list to discuss lir issues.... What do you think you are ISPs. t'sich tsich :-) Graham On Fri, 08 Dec 2000, wrote: >Why don't you guys use the newsgroups instead of "spamming" your opinions all over busy people... > >Thnaks. >Nick > >>>> Kurt Erik Lindqvist 12/07/00 17:01 PM >>> > >> It seems Kurt Erik Lindqvist wrote: >> >That ofcourse depends on what services you want to offer your >> >customers..... >> > >> >I don't see why you want to break services in order to solve assignment >> >policies? This said, I do realise that there is a assignment policy aspect >> >to this as well. >> >> You might realise that you will end up breaking promises to customers if >> the offered services collide with acceptable assignment policies. > >I do. That is why I wrote that I realise that this is a problem. But I am >seeing more and more companies offering Internet connections while in >reality what the customer is getting is more or less a Intranet >connection. > >This is a complex issue that in the end is up to what the customer has >bought. > >> We are going to run out of IPv4 space very quickly if the assignment of, >> for instance, /29's to home users becomes standard procedure at ISP's - and >> bruno's mail does indicate that this is already happening: >> >> "[...]several new ISP in Europe are starting to offer "always on" Internet >> access. > >The interesting part is ofcourse not that people are offering it. The >interesting part is how many do actually sign up? Always on Internet have >been around in Europe since the early '80:s. The price might have been >somewhat high for consumers though...:) > >As I pointed out earlier and others as well - Maybe buy starting to use >the address space for what it was intended for to provide a Internet >connection) we can get a real push to go for another addressing scheme >like IPv6 or IPv8 (just kidding). Or maybe something completly new. > > >Best regards, > >- kurtis - > >Kurt Erik Lindqvist Kurtis.Lindqvist at KPNQwest.SE >KPNQwest Sweden @ The speed of light http://www.kpnqwest.se >PO Box 23163 >S-10435 Stockholm -- Graham Burke Nic-hdl: GB10488-RIPE NSL (Internet) Ltd, 26 Forth Street, Edinburgh, EH1 3LH, UK tel + 44 (0)131 477 8215 fax + 44 (0)131 477 8223 Mob + 44(0)7818 448827 http://www.nsl.net http://www.iomart.com From ripe-dbm at ripe.net Fri Dec 8 16:24:43 2000 From: ripe-dbm at ripe.net (RIPE Database Administration) Date: Fri, 08 Dec 2000 16:24:43 +0100 Subject: Announcement: RIPE Whois Database version 3.0 beta is out Message-ID: <200012081524.QAA19739@birch.ripe.net> Dear All, [ Apologies for duplicate messages ] This mail is to inform you that version 3.0 beta of the RIPE Whois Database is out. Read on! You will be affected too. The RIPE Database is about to change its data format, from RIPE181 to RPSL (the Routing Policy Specification Language, see RFC2622). This will affect all object types, including "person", "domain" and "inetnum". The version 2 of the RIPE Database, the one currently in production on whois.ripe.net, will in the next months be replaced by version 3. All the entries in the RIPE Database will be translated into RPSL format, and that is the format you will get when you will be querying the Database. Don't be mistaken: for the moment, whois.ripe.net continues running with version 2 and answering to your queries in the old-fashioned way. But this will not last forever; in a few months, all will become RPSL. So if you use the Whois database, we encourage all of you to prepare for this change as soon as possible. We strongly suggest you to start to get used to RPSL and version 3.0 . In this aim, you can do the following: - Query rpsl.ripe.net at port 43. You will find there exactly the same objects that are in whois.ripe.net, mirrored live and in RPSL format. - If you have any script that runs by querying whois.ripe.net, test it by pointing it to rpsl.ripe.net and make it v3.0-compliant. - Try our CGI interface to the RPSL server: you can find it at http://www.ripe.net/ripencc/pub-services/db/reimp/. - Get to know the new update path: use our "sandbox" database for RPSL updates. Send your updates to and query the corresponding database at rpsl.ripe.net, port 4343 . Remember that in a few months, that's the way the RIPE Database will be running; so the earlier you start working with it, the less likely you are to be unpleasantly surprised later. We are currently preparing additional resources to help ease the transition; we will announce them as soon as they are available, which will happen later this month. Please note that the software is still in a "beta" phase. So we need your feedback! If you happen to find something that looks like a bug when you are testing the RPSL database, don't hesitate... Send us a bug report at ! If you want to actively participate to the migration effort, you could join the "RIP migration Task force" and let yourself be heard. Just write to and ask to join the Task Force. For the ones interested in viewing or trying the code, you can download it at: ftp://ftp.ripe.net/ripe/dbase/reimp/whois-rip-3.0beta1.tar.gz You can also join a discussion list related to version 3.0 beta of the RIPE Database Software. To subscribe to this list, send a message to with the line: subscribe db-beta in the body of your letter. It is a moderated mailing list so some delays in subscription are possible. Regards, The RIPE Database Group. From oystein at homelien.no Mon Dec 11 04:38:09 2000 From: oystein at homelien.no (=?ISO-8859-1?Q?=D8ystein_Homelien?=) Date: Mon, 11 Dec 2000 04:38:09 +0100 (CET) Subject: Allocations for "always-on" ISPs In-Reply-To: <200012061636.QAA29207@NetBSD.noc.COLT.NET> Message-ID: On Wed, 6 Dec 2000, Neil J. McRae wrote: > NAT is your friend - very few home users need real IP addresses. NAT is our enemy. It effectively turns the customer's IP access into something which is not the real Public Internet -- more like an intranet, offering access to a subset of the Public Internet. In time, this must and will prove detrimental to all those involved. Sadly, many ISPs consider this type of service a valid offering to un-suspecting customers. It may work for now, but it's not anything like the real Internet. And access customers are increasingly becoming aware of this. With regards to running out of IPv4 address space, who cares. Let's run out of them, and spawn a public discussion of why people are not focusing on IPv6 development and deployment. -- Oystein Homelien, CTO | oystein at powertech.no PowerTech Information Systems AS | http://www.powertech.no/ Nedre Slottsgate 5, N-0157 OSLO | tel: +47-23-010-010, fax: +47-2220-0333 From graham at nsl.net Mon Dec 11 10:38:19 2000 From: graham at nsl.net (Graham Burke) Date: Mon, 11 Dec 2000 09:38:19 +0000 Subject: Allocations for "always-on" ISPs In-Reply-To: References: Message-ID: <00121109501503.01486@tabitha.nsl.net> On Mon, 11 Dec 2000, ?ystein Homelien wrote: >On Wed, 6 Dec 2000, Neil J. McRae wrote: > >> NAT is your friend - very few home users need real IP addresses. > >NAT is our enemy. It effectively turns the customer's IP access into >something which is not the real Public Internet -- more like an intranet, >offering access to a subset of the Public Internet. - Morning I've been watching this thread for a few days. I fail to see your point, why are so many people against NAT? in an isp situation.. I admit it rasies an (slight) overhead and perhaps some latency but for the majority of your average ISP customers its ideal Why does Joe Blogs checking his mail and doing some surfing for books on amazon require a public ip address??? Its in the average users interest to be behind a nat'd firewall. it puts security in our hands and takes the emphasis away from the user. The best option is to offer only static ips to those who require them i.e corporate and experienced users who are willling to pay for the privilege. IP6 will hopefully be the solution to address depletion, lets just hope they allocate them properly from the outset this time :-) Just my Monday morning 2 cents worth Graham > >In time, this must and will prove detrimental to all those involved. >Sadly, many ISPs consider this type of service a valid offering to >un-suspecting customers. > >It may work for now, but it's not anything like the real Internet. And >access customers are increasingly becoming aware of this. > >With regards to running out of IPv4 address space, who cares. Let's run >out of them, and spawn a public discussion of why people are not focusing >on IPv6 development and deployment. > >-- >Oystein Homelien, CTO | oystein at powertech.no >PowerTech Information Systems AS | http://www.powertech.no/ >Nedre Slottsgate 5, N-0157 OSLO | tel: +47-23-010-010, fax: +47-2220-0333 -- Graham Burke Nic-hdl: GB10488-RIPE NSL (Internet) Ltd, 26 Forth Street, Edinburgh, EH1 3LH, UK tel + 44 (0)131 477 8215 fax + 44 (0)131 477 8223 Mob + 44(0)7818 448827 http://www.nsl.net http://www.iomart.com From hph at online.no Mon Dec 11 14:10:05 2000 From: hph at online.no (Hans Petter Holen) Date: Mon, 11 Dec 2000 14:10:05 +0100 Subject: Allocations for "always-on" ISPs References: <00121109501503.01486@tabitha.nsl.net> Message-ID: <001501c06373$ae2df450$a505e1c3@hph> > I fail to see your point, why are so many people against NAT? in an isp > situation.. There are lots of reasons for this, the most inportant perhaps is that it only supports well known/well behaved protocolls. (Personaly I have still not been able to make H.323 work properly with NAT from a "well known router manufacturer".) One view on this that was presented at the last RIPE meeting may be viewed at: - - -------------------------------------- 7. RESTORING THE TRANSPARENCY - - -------------------------------------- Presentation with slides by MASATAKA OHTA, Ph. D, Research Associate at the Computer Center of Tokyo Institute of Technology. http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/address/inde x.html -hph From mohta at necom830.hpcl.titech.ac.jp Mon Dec 11 14:58:02 2000 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Mon, 11 Dec 2000 22:57:02 +0859 () Subject: Allocations for "always-on" ISPs In-Reply-To: <00121109501503.01486@tabitha.nsl.net> from Graham Burke at "Dec 11, 2000 09:38:19 am" Message-ID: <200012111357.WAA08829@necom830.hpcl.titech.ac.jp> Graham; > >> NAT is your friend - very few home users need real IP addresses. > > > >NAT is our enemy. It effectively turns the customer's IP access into > >something which is not the real Public Internet -- more like an intranet, > >offering access to a subset of the Public Internet. > > - Morning > I've been watching this thread for a few days. > I fail to see your point, why are so many people against NAT? in an isp > situation.. Performance. > I admit it rasies an (slight) overhead and perhaps some latency > but for the majority of your average ISP customers its ideal > Why does Joe Blogs checking his mail and doing some surfing for books > on amazon require a public ip address??? To watch TV over broadband network. Masataka Ohta From agudgeon at firstnet.co.uk Mon Dec 11 15:05:50 2000 From: agudgeon at firstnet.co.uk (Alison Gudgeon) Date: Mon, 11 Dec 2000 14:05:50 -0000 Subject: AS Macro Message-ID: <000201c0637b$7859c450$0b0010ac@fnhl01a01> Hi All, Can anyone help with this quick question I want to create an AS Macro - do I submit this to hostmaster at ripe.net or via auto-dbm at ripe.net Also - who choses the AS Macro the ISP or RIPE? Many Thanks in Advance, Alison From dponzone at isdnet.net Mon Dec 11 15:08:52 2000 From: dponzone at isdnet.net (David Ponzone) Date: Mon, 11 Dec 2000 15:08:52 +0100 (MET) Subject: AS Macro In-Reply-To: <000201c0637b$7859c450$0b0010ac@fnhl01a01> Message-ID: On Mon, 11 Dec 2000, Alison Gudgeon wrote: > Hi All, > > Can anyone help with this quick question > > I want to create an AS Macro - do I submit this to hostmaster at ripe.net or > via auto-dbm at ripe.net auto-dbm at ripe.net > Also - who choses the AS Macro the ISP or RIPE? What do you mean by this ? You add an AS-macro and then you use it to describe your routing policy in your AS object. The RIPE is not involved in that. Regards, > Many Thanks in Advance, > > Alison > > -- David Ponzone - Network Operations Manager Cable & Wireless France - http://www.cw.com/fr Email: dponzone at isdnet.net Phone: +33 1 43 13 68 00 Fax: +33 1 43 13 68 68 Voicemail: +33 1 70 81 65 10 From kurtis at kpnqwest.net Mon Dec 11 20:11:45 2000 From: kurtis at kpnqwest.net (Kurt Erik Lindqvist) Date: Mon, 11 Dec 2000 20:11:45 +0100 (MET) Subject: Allocations for "always-on" ISPs In-Reply-To: <00121109501503.01486@tabitha.nsl.net> Message-ID: > I've been watching this thread for a few days. > I fail to see your point, why are so many people against NAT? in an isp > situation.. If what you want to offer your customer is a Intranet service, that is fine by me. Just don't mix this with a Internet service. > I admit it rasies an (slight) overhead and perhaps some latency > but for the majority of your average ISP customers its ideal > Why does Joe Blogs checking his mail and doing some surfing for books > on amazon require a public ip address??? Its in the average users interest to It will restrict the Internet services the user can access as discussed in previous emails. > be behind a nat'd firewall. it puts security in our hands and takes the > emphasis away from the user. You are going down a dangerous path if you want to take responsibility for your consumers computer security. > IP6 will hopefully be the solution to address depletion, lets just hope they > allocate them properly from the outset this time :-) Hopefully something will come along. But if there is nothing driving it we will never get there, instead we will be giving IPv4 intensive care until it's to late to think about something else. - kurtis - > > Just my Monday morning 2 cents worth > > Graham > > > > >In time, this must and will prove detrimental to all those involved. > >Sadly, many ISPs consider this type of service a valid offering to > >un-suspecting customers. > > > >It may work for now, but it's not anything like the real Internet. And > >access customers are increasingly becoming aware of this. > > > >With regards to running out of IPv4 address space, who cares. Let's run > >out of them, and spawn a public discussion of why people are not focusing > >on IPv6 development and deployment. > > > >-- > >Oystein Homelien, CTO | oystein at powertech.no > >PowerTech Information Systems AS | http://www.powertech.no/ > >Nedre Slottsgate 5, N-0157 OSLO | tel: +47-23-010-010, fax: +47-2220-0333 > -- > > Graham Burke > Nic-hdl: GB10488-RIPE > NSL (Internet) Ltd, 26 Forth Street, Edinburgh, EH1 3LH, UK > tel + 44 (0)131 477 8215 fax + 44 (0)131 477 8223 > Mob + 44(0)7818 448827 > http://www.nsl.net > http://www.iomart.com > Kurt Erik Lindqvist Kurtis.Lindqvist at KPNQwest.SE KPNQwest Sweden @ The speed of light http://www.kpnqwest.se PO Box 23163 S-10435 Stockholm From Okan.Cimen at Rumeli.Net Wed Dec 13 20:57:19 2000 From: Okan.Cimen at Rumeli.Net (Okan Cimen) Date: Wed, 13 Dec 2000 17:57:19 -0200 Subject: auto-dbm problems Message-ID: <3A37D49F.61300B62@Rumeli.Net> Hello, I am trying to update some information about our networks. I have sent the new information to auto-dbm at ripe.net but could not get a response for almost 6 hours. Does ayone have a suggestion about it? Is there a problem? Regards Okan From nurani at ripe.net Wed Dec 13 17:10:34 2000 From: nurani at ripe.net (Nurani Nimpuno) Date: Wed, 13 Dec 2000 17:10:34 +0100 Subject: Registration Services update Message-ID: <4.3.1.2.20001213163626.00a98ea0@localhost> Dear all, As a follow up on Axel's mail in October, I would like to provide an update of the current status of the Registration Services at the RIPE NCC. As you may have noticed, the wait queue has dramatically been reduced over the last couple of month and is now at more satisfactory 5 working days. We are aiming at further reducing the wait queue but our main priorities for the coming period is to try to stabilise the wait queue at an acceptable level. Over the last period, we have taken both long term and short term measures that have had an impact on the wait queue. These can be summarised as follows: 1. Priority to correctly filled out requests. Well filled-out requests are dealt with swifter and faster than other requests. 2. Less strict with documentation being 100% complete Requests that are not 100% ok, missing relevant but not essential information have been approved but with a request to provide this information in future requests. 3. Less strict with smaller requests/ statistical sampling Less information has been requested for smaller request and "statistical sampling" has been applied when evaluating some requests. 4. Stricter with LIRs who have not read relevant documentation LIRs completely unfamiliar with relevant documentation are requested to read the very basics before proceeding further with the request. 5. Pro-active Assignment Window raises The Assignment Window tool is now fully developed and in use, leading to more pro-active AW raises! LIRs that send in good requests with all necessary documentation quickly get an AW. 6. New staff We have hired five new hostmasters, we have a good team of competent and dedicated hostmasters which is showing in the results coming from the department. 7. Tools to members - The Asused-public tool can now be: A) downloaded and run locally (http://www.ripe.net/ripencc/mem-services/tools/index.html) B) run from our website (http://www.ripe.net/cgi-bin/webasused.pl.cgi) C) run by sending a mail to hostmaster at ripe.net, with SENDASUSED in the subject line. - The output will be sent to the 'e-mail' contact(s) of you LIR. We have received very good feedback on this tool and can see that it is resulting in better managed allocations and consequently less audit work for the RIPE NCC. - Asused-public output is also automatically sent to the LIR in New Allocation request. (This to encourage the LIRs to correct possible errors before the intervention of a RIPE NCC hostmaster.) 8. FAQ and TIPS page http://www.ripe.net/ripencc/faq/index.html http://www.ripe.net/ripencc/tips/tips.html We have received very positive feedback on both the FAQ and the TIPS pages. It has especially proven useful for newer LIRs that also represent the bulk of our workload. IN PROGRESS 9. Improving Address Request form With input from people in the community, we are currently working on improving the Request form, which we hope will result in less iterations between the RIPE NCC and LIRs. 10. Tools to members A secure website is currently under development, where LIRs will be able to log in and modify contact information, running audit tools on their own allocation and in the future also send in requests through the website. More information on this will come soon. 11. Increase of LIR courses 2001 The number of courses planned in 2001 has been increased in order to provide additional help and support to new LIRs. We have used several ideas from the May17 Taskforce, also taking in consideration the input from the LIR working group at RIPE 37. We have focused on giving priority to correctly filled out requests, shifting more responsibility to the LIRs, providing the LIRs with useful tools, trying to improve documentation etc. We are happy to see the immediate results some of these measures have had but we are also very aware of all the work we have ahead of us. We are determined to further improve both response time and quality of service and will continue our efforts in 2001. Kind regards, Nurani Nimpuno Registration Services Manager RIPE NCC http://www.ripe.net From margit at belanna.augsburg.net Wed Dec 13 17:10:06 2000 From: margit at belanna.augsburg.net (Margit Steidl) Date: Wed, 13 Dec 2000 17:10:06 +0100 (MET) Subject: auto-dbm problems In-Reply-To: <3A37D49F.61300B62@Rumeli.Net> Message-ID: Hello Okan! On Wed, 13 Dec 2000, Okan Cimen wrote: > From: Okan Cimen > To: lir-wg at ripe.net > Date: Wed, 13 Dec 2000 17:57:19 -0200 > Subject: auto-dbm problems > > Hello, > > I am trying to update some information about our networks. I have sent > the new information to auto-dbm at ripe.net but could not get a response > for almost 6 hours. Does ayone have a suggestion about it? Is there a > problem? > Yesterday it worked. Did you send it from an authorized email address or use the correct password? Do you have a notify: ... line within your object? If everything is correct on your side, perhaps there is a waiting queue there as well. > Regards > > Okan > Kind regards from Margit Steidl System Administrator of augsburg.net From Okan.Cimen at Rumeli.Net Wed Dec 13 21:32:19 2000 From: Okan.Cimen at Rumeli.Net (Okan Cimen) Date: Wed, 13 Dec 2000 18:32:19 -0200 Subject: auto-dbm problems References: Message-ID: <3A37DCD3.46CF5708@Rumeli.Net> Hi again, Thanks for all the replies ... Marcus Rist has sent me a very useful link. If you are interested please check.. http://www.ripe.net/ripencc/pub-services/db/mrtg/whois.html Thanks to all Regards Okan Margit Steidl wrote: > Hello Okan! > > On Wed, 13 Dec 2000, Okan Cimen wrote: > > > From: Okan Cimen > > To: lir-wg at ripe.net > > Date: Wed, 13 Dec 2000 17:57:19 -0200 > > Subject: auto-dbm problems > > > > Hello, > > > > I am trying to update some information about our networks. I have sent > > the new information to auto-dbm at ripe.net but could not get a response > > for almost 6 hours. Does ayone have a suggestion about it? Is there a > > problem? > > > Yesterday it worked. > Did you send it from an authorized email address or use the correct password? > Do you have a notify: ... line within your object? > > If everything is correct on your side, > perhaps there is a waiting queue there as well. > > > Regards > > > > Okan > > > > Kind regards from Margit Steidl > System Administrator of augsburg.net From javier at bitmailer.com Wed Dec 13 18:17:00 2000 From: javier at bitmailer.com (Javier Llopis) Date: Wed, 13 Dec 2000 17:17:00 +0000 Subject: auto-dbm problems Message-ID: <20001213161706.800F425C808@proxy.bitmailer.com> On Wed, 13 Dec 2000 17:57:19 -0200, Okan Cimen wrote: >I am trying to update some information about our networks. I have sent >the new information to auto-dbm at ripe.net but could not get a response >for almost 6 hours. Does ayone have a suggestion about it? Is there a >problem? Same thing here. I've just received a response for a request sent 4 hours ago. Regards Javier Llopis BitMailer, S.L. javier at bitmailer.com Juan Bravo 51, Dup. 1-Izq Tel: +34 91 402 1551 28006 Madrid Fax: +34 91 402 4115 SPAIN From andrei at ripe.net Wed Dec 13 17:19:23 2000 From: andrei at ripe.net (Andrei Robachevsky) Date: Wed, 13 Dec 2000 17:19:23 +0100 Subject: auto-dbm problems References: <3A37D49F.61300B62@Rumeli.Net> Message-ID: <3A37A18B.5A7A9CCF@ripe.net> Dear Okan Cimen, Okan Cimen wrote: > > Hello, > > I am trying to update some information about our networks. I have sent > the new information to auto-dbm at ripe.net but could not get a response > for almost 6 hours. Does ayone have a suggestion about it? Is there a > problem? > > Regards > > Okan Indeed we had some delay in processing, but this should not exceed 3 hours. Could you please contact with the details of your update so we could trace it? Regards, Andrei Robachevsky DB Group Manager RIPE NCC From piet at skynet.be Wed Dec 13 19:07:02 2000 From: piet at skynet.be (Pieterjan d'Hertog) Date: Wed, 13 Dec 2000 19:07:02 +0100 Subject: auto-dbm problems In-Reply-To: <3A37D49F.61300B62@Rumeli.Net> Message-ID: <5.0.2.1.2.20001213190605.00a4cec0@pop.skynet.be> Hi Okan, You can see the stats from the whois db on the following page : http://www.ripe.net/ripencc/pub-services/db/mrtg/whois.html At 17:57 13/12/00 -0200, Okan Cimen wrote: >Hello, > >I am trying to update some information about our networks. I have sent >the new information to auto-dbm at ripe.net but could not get a response >for almost 6 hours. Does ayone have a suggestion about it? Is there a >problem? > >Regards > >Okan Greetings, ------------------------------------------------------------------ B E L G A C O M S K Y N E T NV/SA Kolonel Bourgstraat 124 Pieterjan d'Hertog B-1140 Brussels Network Engineer PGP Key Tel +32(0)2 706.13.11 piet at skynet.be ID: 0xE4BB9D2E Fax +32(0)2 706.13.12 ------------------------------------------------------------------ These are my opinions -- not to be taken as official Skynet policy From bruno at flashnet.it Wed Dec 13 09:52:57 2000 From: bruno at flashnet.it (Bruno Ciscato) Date: Wed, 13 Dec 2000 09:52:57 +0100 Subject: Allocations for "always-on" ISPs In-Reply-To: References: <00121109501503.01486@tabitha.nsl.net> Message-ID: <4.3.2.7.2.20001213090851.00e14740@mbox.flashnet.it> I'm very glad my mail sparkled such an interesting discussion. I see three main threads developing: 1) NAT or not to NAT 2) prohibit /29 for residential users 3) where is IPv6 First of all let me try to put these problems in the context I was referring to in my mail. The service providers I was thinking about are those who want to offer an always on connection to customers that wont' simply surf the net. Once you have always on connectivity to the Internet you may end up buying an Internet washing machine (http://www.margherita2000.com) and an Internet camera (http://www.axis.com/products/camera_servers/index.htm). These are servers, not clients. Chances are that most devices like these will be manageable by a web browser,so they simply don't work behind a NAT/PAT. So, in this context, these are my opinions regarding the three threads : 1) NAT is bad for users that want to connect to the Internet, see http://www.ietf.org/rfc/rfc2993.txt and PAT is much worse. NAT/PAT is not an option in the scenario above. 2) how many addresses should RIPE allow a LIR to give to always home customers? /32, /30, /29 ? IF we want to couple a customer with a subnet, I agree with people that are thinking about a /29 at least, because a /30 leaves only one address for your PC. So you cannot use your camera to watch your washing machine doing its job ;-) An alternative would be not to couple a customer with a subnet and give each customer as many address as they need. This would work but would make security, multicast, and probably a few other thins harder to manage. 3) IPv6 is good, see http://search.ietf.org/internet-drafts/draft-iab-case-for-ipv6-06.txt and the service I'm describing would be much easier to deploy if we had it. Why don't we have it yet? Because we make a fundamental mistake in assessing IPv4 addresses exhaustion rate: we count how many addresses are actually allocated/assigned, not how many addresses people would actually need to access the Internet in a decent way. I've personally worked with two very big companies, one that offers always on Internet access, and the other GPRS. They have not even tried to contact the RIPE to request the public IPv4 addresses they would need to offer an architecturally sound service (see: http://www.ietf.org/rfc/rfc1958.txt) because they feel they will never get the number of addresses they anticipate to need!! So they try to get away with NAT, and fail. In this way we get the wrong picture and don't realize how much we need IPv6 today, and neither do the network equipment vendors. So I agree with Lars and Oystein: let's run out of IPv4 addresses once for ever, so we can move on to the next stage. And for that matter, let's stop being restrictive about allocations and assignment: let's give plentiful of addresses so we run out faster!! And I'm not kidding. Cheers bruno From marcus at netplace.de Wed Dec 13 16:58:21 2000 From: marcus at netplace.de (Marcus Rist) Date: Wed, 13 Dec 2000 16:58:21 +0100 Subject: auto-dbm problems In-Reply-To: <3A37D49F.61300B62@Rumeli.Net>; from Okan.Cimen@Rumeli.Net on Wed, Dec 13, 2000 at 05:57:19PM -0200 References: <3A37D49F.61300B62@Rumeli.Net> Message-ID: <20001213165821.P7257@snickers.netplace.de> Hello, Okan Cimen wrote To lir-wg at ripe.net: > I am trying to update some information about our networks. I have sent > the new information to auto-dbm at ripe.net but could not get a response > for almost 6 hours. Does ayone have a suggestion about it? Is there a > problem? Have you checked http://www.ripe.net/ripencc/pub-services/db/mrtg/whois.html ? About 5 hours seems to be "normal" right now. best regards -Marcus -- Marcus Rist email: marcus at netplace.de netplace Telematic GmbH fon: +49 89 551805-23 http://www.netplace.de/ fax: +49 89 551805-24 From Alessandro.Pelosi at swisscom-italy.com Thu Dec 14 08:47:21 2000 From: Alessandro.Pelosi at swisscom-italy.com (Pelosi Alessandro,Swisscom Italy) Date: Thu, 14 Dec 2000 08:47:21 +0100 Subject: R: Allocations for "always-on" ISPs Message-ID: <9B7535E4E5ABD411B16600508BF39F432B8DA5@VENERE> Ciao I read with a lot of interest the quantity of email regarding this problem. I think that we must avoid to generalize this problem. In most cases NAT or PAT are good solutions both to save waste of Ip addresses (v4 or v6)and to security. In many other cases there is the need to have public IP addresses both for clients and for servers, depends which applications run on these machine and how technology evolves. fortunately we are reducing the waste of ip addresses with new protocols and new features (http 1.1 teaches). Now we are assisting to the birth of many new services that need public ip addresses such as GPRS, video streaming, web controlled machines and so on. I think that in the lounch period of these services there will be a great deal of use of them simply because this is the simplest way to start and debug. I fund a little circuit that works like a web server and can be used to web remote control any kind of device, startink from the washing machine to the coffee distributor etc... http://world.std.com/~fwhite/ace/index.html http://world.std.com/~fwhite/ace/ace2.html To summarize I thing that we should allow to use public ip addresses to those who need and use them (home users, isp, companies and so...), with a little more control about the effective need and usage. Ing. Alessandro Pelosi Network Engineer SWISSCOM SpA Milano +39.02.40.934.312 -----Messaggio originale----- Da: Bruno Ciscato [mailto:bruno at flashnet.it] Inviato: mercoled? 13 dicembre 2000 9.53 A: lir-wg at ripe.net Oggetto: Re: Allocations for "always-on" ISPs I'm very glad my mail sparkled such an interesting discussion. I see three main threads developing: 1) NAT or not to NAT 2) prohibit /29 for residential users 3) where is IPv6 First of all let me try to put these problems in the context I was referring to in my mail. The service providers I was thinking about are those who want to offer an always on connection to customers that wont' simply surf the net. Once you have always on connectivity to the Internet you may end up buying an Internet washing machine (http://www.margherita2000.com) and an Internet camera (http://www.axis.com/products/camera_servers/index.htm). These are servers, not clients. Chances are that most devices like these will be manageable by a web browser,so they simply don't work behind a NAT/PAT. So, in this context, these are my opinions regarding the three threads : 1) NAT is bad for users that want to connect to the Internet, see http://www.ietf.org/rfc/rfc2993.txt and PAT is much worse. NAT/PAT is not an option in the scenario above. 2) how many addresses should RIPE allow a LIR to give to always home customers? /32, /30, /29 ? IF we want to couple a customer with a subnet, I agree with people that are thinking about a /29 at least, because a /30 leaves only one address for your PC. So you cannot use your camera to watch your washing machine doing its job ;-) An alternative would be not to couple a customer with a subnet and give each customer as many address as they need. This would work but would make security, multicast, and probably a few other thins harder to manage. 3) IPv6 is good, see http://search.ietf.org/internet-drafts/draft-iab-case-for-ipv6-06.txt and the service I'm describing would be much easier to deploy if we had it. Why don't we have it yet? Because we make a fundamental mistake in assessing IPv4 addresses exhaustion rate: we count how many addresses are actually allocated/assigned, not how many addresses people would actually need to access the Internet in a decent way. I've personally worked with two very big companies, one that offers always on Internet access, and the other GPRS. They have not even tried to contact the RIPE to request the public IPv4 addresses they would need to offer an architecturally sound service (see: http://www.ietf.org/rfc/rfc1958.txt) because they feel they will never get the number of addresses they anticipate to need!! So they try to get away with NAT, and fail. In this way we get the wrong picture and don't realize how much we need IPv6 today, and neither do the network equipment vendors. So I agree with Lars and Oystein: let's run out of IPv4 addresses once for ever, so we can move on to the next stage. And for that matter, let's stop being restrictive about allocations and assignment: let's give plentiful of addresses so we run out faster!! And I'm not kidding. Cheers bruno From kurtis at kpnqwest.net Wed Dec 13 21:49:42 2000 From: kurtis at kpnqwest.net (Kurt Erik Lindqvist) Date: Wed, 13 Dec 2000 21:49:42 +0100 (MET) Subject: Allocations for "always-on" ISPs In-Reply-To: <4.3.2.7.2.20001213090851.00e14740@mbox.flashnet.it> Message-ID: > 2) how many addresses should RIPE allow a LIR to give to always home customers? /32, /30, /29 ? IF we want to couple a customer with a subnet, I agree with people that are thinking about a /29 at least, because a /30 leaves only one address for your PC. So you cannot use your camera to watch your washing machine doing its job ;-) An alternative would be not to couple a customer with a subnet and give each customer as many address as they need. This would work but would make security, multicast, and probably a few other thins harder to manage. AFAI am concerned, a leased line is a leased line. Let them fill in a RIPE-141 (or simpler but equivalent) form and assign them the addresses they need/can motivate. Just as with any other customer. I am failing to see why we would use address assignments to split users into class A and class B (people who are allowed to get what they need and people who are not allowed). Who will then decide which applications should justify which type of addresses? Is someone working from home with a server for her company a valid use? Is a toaster a valid use? Why do you anticipate muticast beeing harder to support with this? Best regards, - kurtis - Kurt Erik Lindqvist Kurtis.Lindqvist at KPNQwest.SE KPNQwest Sweden @ The speed of light http://www.kpnqwest.se PO Box 23163 S-10435 Stockholm From netmaster at space.net Wed Dec 13 23:18:51 2000 From: netmaster at space.net (Gert Doering, Netmaster) Date: Wed, 13 Dec 2000 23:18:51 +0100 Subject: auto-dbm problems In-Reply-To: <20001213165821.P7257@snickers.netplace.de>; from marcus@netplace.de on Wed, Dec 13, 2000 at 04:58:21PM +0100 References: <3A37D49F.61300B62@Rumeli.Net> <20001213165821.P7257@snickers.netplace.de> Message-ID: <20001213231851.T1037@Space.Net> Hi, On Wed, Dec 13, 2000 at 04:58:21PM +0100, Marcus Rist wrote: > About 5 hours seems to be "normal" right now. Not that this is really satisfying - at good times, auto-dbm response has been nearly instantaneous (2 minutes). I'm convinced that the new database will fix this, once and for good. Gert Doering -- NetMaster -- SpaceNet GmbH Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From shane at ripe.net Thu Dec 14 11:41:05 2000 From: shane at ripe.net (Shane Kerr) Date: Thu, 14 Dec 2000 11:41:05 +0100 (CET) Subject: auto-dbm problems In-Reply-To: <20001213231851.T1037@Space.Net> Message-ID: On Wed, 13 Dec 2000, Gert Doering, Netmaster wrote: > On Wed, Dec 13, 2000 at 04:58:21PM +0100, Marcus Rist wrote: > > About 5 hours seems to be "normal" right now. > > Not that this is really satisfying - at good times, auto-dbm response > has been nearly instantaneous (2 minutes). > > I'm convinced that the new database will fix this, once and for good. Gert, The latest delay was not due to the database itself, but rather with PGP. We currently use the commercial PGP offering, and when you run "pgpv" on an encrypted file, it blocks waiting on TTY input, even when you use the --batch option. It works properly with *signed* messages, just not with encrypted messages. Unfortunately, this pauses the queue for other updates. We do try to monitor the queue length to check for this. It doesn't happen often (maybe once a month), but when it does a delay can occur. I'm DBM this week, so any delays yesterday were my fault. In the new implementation, we intend to use GnuPG, which does not have this problem. -- Shane Kerr Database Software Engineer RIPE NCC +31 20 535 4427 From mehdaoui at iam.net.ma Thu Dec 14 12:10:24 2000 From: mehdaoui at iam.net.ma (Mehdaoui Salma) Date: Thu, 14 Dec 2000 11:10:24 -0000 Subject: Ripe 141 problem Message-ID: <00be01c065be$74dce880$4b2b000a@tarik.iamdg.net.ma> Hello, I have sent a request for new addresses (ripe 141) and the answer was that I might have to wait up to a week for an initial response. I would like to precise that the request is very urgent, we need new addresses for our end users. I hope that we will have an answer as soon as possible, to enble us to satisfy our custmors requests. Please send a copy of your answer to satff at iam.net.ma Regards Salma -------------- next part -------------- An HTML attachment was scrubbed... URL: From nurani at ripe.net Thu Dec 14 13:30:57 2000 From: nurani at ripe.net (Nurani Nimpuno) Date: Thu, 14 Dec 2000 13:30:57 +0100 Subject: Ripe 141 problem In-Reply-To: Your message of Thu, 14 Dec 2000 11:10:24 GMT. <00be01c065be$74dce880$4b2b000a@tarik.iamdg.net.ma> References: <00be01c065be$74dce880$4b2b000a@tarik.iamdg.net.ma> Message-ID: <200012141230.NAA06666@x7.ripe.net> Dear Salma, For questions like this, please write to the RIPE NCC directly instead of the lir-wg mailing list. is a helpdesk mailbox set up for members only. It has a fast response time and can be used by any LIR for any types of questions related to Registration Services. Please not that we can not give higher priority to certain members as this would jeopardise the neutrality and impartiality of the RIPE NCC. However, if you need a New Allocation (a new /20 to further assign to your customers), you *do not* have to send in a ripe-141. You simply write an email (free format0 with a summary of your current assignments. By putting NEWBLOCK in the subject line, the RIPE NCC robot will tag it as a New Allocation and it will be given higher priority than assignment requests. (This cannot be done with ripe-141 forms.) I recommend you reading our TIPS pages at: http://www.ripe.net/ripencc/tips/alltips.html For details about how to request a New Allocation, please see: http://www.ripe.net/ripe/docs/ripe-185.html#toc43 Kind regards, -- Nurani Nimpuno Registration Services Manager RIPE NCC FAQ: http://www.ripe.net/ripencc/faq/index.html QUICK TIPS: http://www.ripe.net/ripencc/tips/tips.html "Mehdaoui Salma" writes: * Message en plusieurs parties et au format MIME. * * ------=_NextPart_000_00BB_01C065BE.74BB56C0 * Content-Type: text/plain; * charset="iso-8859-1" * Content-Transfer-Encoding: quoted-printable * * Hello, * I have sent a request for new addresses (ripe 141) and the answer was = * that I might have to wait up to a week for an initial response. I would = * like to precise that the request is very urgent, we need new addresses = * for our end users. * I hope that we will have an answer as soon as possible, to enble us to * satisfy our custmors requests. * * Please send a copy of your answer to satff at iam.net.ma * * Regards * Salma=20 * * * ------=_NextPart_000_00BB_01C065BE.74BB56C0 * Content-Type: text/html; * charset="iso-8859-1" * Content-Transfer-Encoding: quoted-printable * * * * * * * * * *
*
Hello,
I have sent a request for new addresses (ripe 141) and = * the answer=20 * was that I might have to wait up to a week for an initial response. I = * would like=20 * to precise that the request is very urgent, we need new addresses for = * our end=20 * users.
I hope that we will have an answer as soon as possible, to = * enble us=20 * to
satisfy our custmors requests.

Please send a copy of your = * answer to=20 * satff at iam.net.ma

Regards
S= * alma=20 *
* * ------=_NextPart_000_00BB_01C065BE.74BB56C0-- * * * From netmaster at space.net Thu Dec 14 12:50:13 2000 From: netmaster at space.net (Gert Doering, Netmaster) Date: Thu, 14 Dec 2000 12:50:13 +0100 Subject: auto-dbm problems In-Reply-To: ; from shane@ripe.net on Thu, Dec 14, 2000 at 11:41:05AM +0100 References: <20001213231851.T1037@Space.Net> Message-ID: <20001214125013.U1037@Space.Net> Hi, On Thu, Dec 14, 2000 at 11:41:05AM +0100, Shane Kerr wrote: > The latest delay was not due to the database itself, but rather with PGP. > We currently use the commercial PGP offering, and when you run "pgpv" on > an encrypted file, it blocks waiting on TTY input, even when you use the > --batch option. It works properly with *signed* messages, just not with > encrypted messages. Unfortunately, this pauses the queue for other > updates. Thanks for explaining. Yes, commercial PGP is pretty broken. > In the new implementation, we intend to use GnuPG, which does not have > this problem. Which, unfortunately, has some interoperability problems with PGP 2 and/or PGP 5 as well :-( - but then, all users could change to GPG, which would be a good thing in itself :-) Gert Doering -- NetMaster -- SpaceNet GmbH Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From rob at insnet.net Thu Dec 14 13:22:14 2000 From: rob at insnet.net (Rob Woodward) Date: Thu, 14 Dec 2000 12:22:14 +0000 (GMT) Subject: Ripe 141 problem In-Reply-To: <00be01c065be$74dce880$4b2b000a@tarik.iamdg.net.ma> Message-ID: Hi, You just need to set your customers expectations correctly, in that it could take a little longer to get addresses under certain circumstances. Cheers, Rob On Thu, 14 Dec 2000, Mehdaoui Salma wrote: > Hello, > I have sent a request for new addresses (ripe 141) and the answer was that I might have to wait up to a week for an initial response. I would like to precise that the request is very urgent, we need new addresses for our end users. > I hope that we will have an answer as soon as possible, to enble us to > satisfy our custmors requests. > > Please send a copy of your answer to satff at iam.net.ma > > Regards > Salma > > ---- Rob Woodward. Senior Technical Specialist. Global Network Operations - UK Cable & Wireless INS Duckies are fun! From g.peritore at panservice.it Thu Dec 14 17:36:40 2000 From: g.peritore at panservice.it (Giuliano Peritore) Date: Thu, 14 Dec 2000 17:36:40 +0100 Subject: Allocations for "always-on" ISPs In-Reply-To: <4.3.2.7.2.20001213090851.00e14740@mbox.flashnet.it> References: <00121109501503.01486@tabitha.nsl.net> Message-ID: <5.0.2.1.0.20001214173456.02e0b060@moon.panservice.it> Hi Bruno, I think the world's moving towards always-on access. The wide deployment of flat-rate access and DSL service is a clear signal about this. As times goes by more and more equipment will be 'tcpized' and also Cisco's appliance program is another signal of this. Always on access and tcpized equipment means public address space increased needs. More users mean more ip space needed. The point is not to create strict rules based on who-you-are, but to strengthen the address allocation rules. So I think is a big mistake to define the size of a 'residential' subnet. A residential customer has to get one address as long as he/she does not need any more. The same for a small office or, why not, for a company. Only when the end user has a justified (what a deep concept :)) need of public IP addresses he/she's the right to get them (avoiding abuses and abnormal concentrations). As long as IP addresses will be available. When the addresses will be really scarce maybe that the infrastructural allocations will HAVE to have precedence. I don't think we're in an emergency _NOW_, as a bright reorganization could free lots of address space, but as the 'golden minds' of the internet showed us in the past (writing RFCs and drafts) we've to look at the future. Talk about this in eastern countries. Why there's so much interest towards IPv6 there ? There's a lot of people there. There'll be a lot of equipment, they'll need public space. Why IIJ (Internet Initiative Japan) is official sponsor of the Global IPv6 Summit in Japan ? Why NTT (Nippon Telephone and Telegraph) is higly interested in experimenting IPv6 trials also in Europe ? Why RIPE is involved GPRS infrastructure with GSM association ? Well, there's people thinking to the future, we're lucky. This does not mean that we'll see IPv6 anytime soon, especially in Europe I think. Large companies are too interested, at now, to collect users whatever way (commercial or technical mean) they succeed to connect them. IPv6 is too complicated to be explained and comprehended by the masses before it will become really 'commoditized' and autoconfigurable. But fortunately vendors are starting to release betas (think to Microsoft and Cisco) and who wants to use IPv6 is able at least to experiment (just think to the 6bone). I think that if we want to stop exchanging emails and wandering about allocations we just need to make people aware of the problem and get them to become future-looking. But lots of humans are just unable to do that as they will only understand a "no more IPv4 addresses" error message. Dull and real. I just hope that very few people like that are heading large IP carriers. Have a nice time you all and thanks to RIPE, as thanks to its activity european customers have still addresses to be allocated. Hoping to have not bothered I wish you a pleasant day. --------------------------------------------------- Dott. Giuliano Peritore - g.peritore at panservice.it Direzione - Panservice Servizi professionali per Internet ed il Networking Panservice e' associata AIIP -- RIPE Local Registry Phone: +39 0773 410020 Fax +39 0773 470219 Numero verde: 800 901492 - http://www.panservice.it --------------------------------------------------- From Jevgenijs.Vaikulis at delfi.lv Fri Dec 15 09:10:01 2000 From: Jevgenijs.Vaikulis at delfi.lv (Jevgenijs Vaikulis) Date: Fri, 15 Dec 2000 10:10:01 +0200 Subject: Reaseon for AS&PI Message-ID: <115316891892.20001215101001@delfi.lv> Hello, Before writing request to RIPE for new AS and PI i would like to ask Your advice. The main reason for new AS(and PI) - security. We provide some services for local (national, like *.lv) users only (like irc). Firewall dosnt helps, when attacker send a ton of flood our international channel going down. With a AS ill anounce this AS only for national providers. So, is it reason for gettin A&PI? If someone have expirience with such problem, i`ll be very grateful for advice. P.S. Sorry for my poor english. ----------------------------------------------------------------- Jevgenijs Vaikulis(EV298-RIPE) +371 7777723 DELFI Internet +371 7777777 Elijas 17, Riga, Latvia http://internet.delfi.lv ----------------------------------------------------------------- From lvv at macomnet.ru Fri Dec 15 10:02:40 2000 From: lvv at macomnet.ru (Vladimir V. Lobanov) Date: Fri, 15 Dec 2000 12:02:40 +0300 Subject: Reaseon for AS&PI In-Reply-To: <115316891892.20001215101001@delfi.lv> Message-ID: On Fri, 15 Dec 2000, Jevgenijs Vaikulis wrote: Hi, The best way (if it possible!) to stop such attacks: ask your upstream provider to investigate the situation (if you can't do it yourself) in order to filter the address/net on his backbone router. > Hello, > > Before writing request to RIPE for new AS and PI i would like to ask > Your advice. The main reason for new AS(and PI) - security. We provide some > services for local (national, like *.lv) users only (like irc). > Firewall dosnt helps, when attacker send a ton of flood our > international channel going down. With a AS ill anounce this AS only > for national providers. So, is it reason for gettin A&PI? If someone > have expirience with such problem, i`ll be very grateful for advice. > > P.S. Sorry for my poor english. > > ----------------------------------------------------------------- > Jevgenijs Vaikulis(EV298-RIPE) +371 7777723 > DELFI Internet +371 7777777 > Elijas 17, Riga, Latvia http://internet.delfi.lv > ----------------------------------------------------------------- > > > Regards, ____________________ Vladimir V. Lobanov Macomnet, Internet-Intranet Dep. tel: +7(095) 796-9079 fax: +7(095) 796-9067 e-mail: lvv at macomnet.ru From ncc at ripe.net Thu Dec 21 14:39:05 2000 From: ncc at ripe.net (RIPE NCC) Date: Thu, 21 Dec 2000 14:39:05 +0100 (CET) Subject: RIPE Whois RPSL Migration Message-ID: <200012211339.OAA01706@x17.ripe.net> [ Apologies for duplicate mails ] RIPE Whois RPSL Migration The RIPE Database re-implementation project is nearing completion. A key feature of the new database is the implementation of RPSL, to replace the old RIPE-181 standard. RPSL is similar, but not identical, to RIPE-181. The RIPE NCC expects that many programs that use the RIPE Whois database will continue to operate properly without modification. However, some programs may have problems parsing the RPSL format, or be confused by differences in behaviour. We would like to ensure that the transition to RPSL is as easy as possible. Therefore, we are working with the RIPE community to provide resources you can use to check any programs or scripts that you have that use the RIPE Whois database. Please visit our Migration page for further information: http://www.ripe.net/ripencc/pub-services/db/rpsl/index.html This page will be updated regularly with the latest information. We will provide additional tools and information as they become available. The actual timeline of when the RPSL server will replace the existing RIPE-181 server will be decided at the RIPE-38 meeting. If you want input on when the change will occur, then you should either attend this meeting or post your comments on the RIPE DB mailing list. http://www.ripe.net/ripe/meetings/current/ripe-38/index.html http://www.ripe.net/ripe/wg/db/index.html Regards, The RIPE Database Group. RIPE NCC From david at IPRG.nokia.com Sat Dec 23 22:17:11 2000 From: david at IPRG.nokia.com (David Kessens) Date: Sat, 23 Dec 2000 13:17:11 -0800 Subject: IPv6 joint policy meeting minutes Message-ID: <20001223131711.A17352@iprg.nokia.com> Hi, Please see below for the minutes of the joint session of the ipv6 wg and lir wg regarding ipv6 allocation policies at RIPE37. The minutes will be declared final by January 5 if I don't receive any comments other than typographical errors and other minor corrections. I would like to thank Vesna for taking the minutes. Thanks, David K. --- IPv6 joint policy meeting RIPE ipv6-wg & lir-wg Wednesday, 13 September 2000 RIPE 37 Chair: David Kessens Agenda i Statement of current policy draft ii IAB/IESG recommendations iii Panel discussion iv AOB =i= Statement of current policy draft -- Joao Damas, RIPE NCC One year ago 3 Regional Internet Registries produced document that outlines allocation of IPv6 address space. * size of end user assignments * multihoming considerations * what is the meaning of 80% usage in ipv6? We need the clear picture of these issues to move forward. [chair: Bob Hinden tries to present the opinion of the IAB/IESG as closely as possible, but he is not the official spokesman of those bodies] = ii = IAB/IESG Recommendations on IPv6 Address Allocation - Bob Hinden URL: http://www/ripe/meetings/archive/ripe-37/presentations/ripe-ipv6-hinden/ We do not have real issue on service provider allocations size. Our recommendation is: /48 fixed boundary for all subscribers. This is consistent with responsible stewardship of the IPv6 Address space. Reasoning: - allocation policies influence the deployment; policies should make deployment easy, not slow - renumbering is (still) not painless or automatic Exceptions: - very large subscribers should get multiple /48:s, or /47 - transient nodes (roaming, dial-up) (/64) - explicitly no interest in subnetting Justifications for fixed boundary: - easy to change ISP:s (does not require restructuring of subnets) - straightforward renumbering - compatible with current multihoming proposals - allows easy growth of subscribers - reduces burden of ISP:s and RIR:s to judge customers' needs - no need for details of customers' networks - no need to judge rates of consumption - no scarcity of subscriber's space: no need for NAT - allows single reverse DNS zone (for all prefixes) Conservation: - does this waste IPv6 address space? No. - this distribution had better H ratio (RFC1715) then many others today - still, only one of the Format Prefixes (001) is going to be used; it leaves 85% of total IPv6 space for future usage and possible stricter policy Multihoming: IETF is still looking for input on this issue. = iii= Panel discussion: 1. Stephen Burley (UUNET) 2. Steve Deering (ipng) 3. Joao Damas (RIPE NCC) 4. Bob Hinden (ipng) 5. Randy Bush (ngtrans) 6. Juergen Rauschenbach (ipv6 forum) Q: What is criteria for ISP allocation? How much IPv6 address space does an ISP get? A: (Randy) This proposal is not changing other parts of policy. All will still get a /35. Normal slow start. Q: (Dave Pratt) Could you clarify what is meant by the 80% rule? A: (Bob) 80% of number of customers (ISP needs to allocate 80%, not the subscribers) Q: (Dave) I guess what I really mean is to do with ISP/LIR addressing hierarchy. It's difficult to build in hierarchy if aiming for 80% utilisation before more addresses will become available. Steve: H-ratio may be more appropriate rather than a percentage. A: I would suggest 20%. For example with 20% you can reserve addresses for 8 regions, and not worry if 6 of the 8 sites have small take up rates. A: (Steve) "you can start without hierarchy, and then add it later when the need arises". A: We could add hierarchy later, but maybe not really ***(same problems later as at start)***. We should be designing our networks correctly from the beginning. A: Discussion of possibility of H ratio's also being applied also to the LIR/ISP address range. Randy points out that with allocating /48s in a /35, the H ratio might be different, but the principle still holds, and there is a believe that there are enough addresses in IPv6 (also mentions in passing that the same believe existed in the early days of IPv4) Q: (Wilfred Woeber) Thank you for the clear document and clarification. Remaining issue: number of bits available for infrastructure. There should be a recommendation to start with the least significant bits. A: (Steve) We need an analysis regarding building an efficient hierarchy in the top 8 bits. If the community agrees on the /48 boundary, we may have to review the size of the initial allocation (/35 subTLA size). Joao explains why the /35 has been chosen. One gets 8192 NLA ranges, which can each by itself be structured and managed. This means it is actually more than if one gets a /19 in IPv4. Randy wonders why WW thinks one has a different problem in v than today in v4. The ISP he works for aggregates per pop, very strict and successful about it, but announce a /19 or shorter per pop. /35 feels as comfortable. Tries to understand if people don't feel comfortable with that and why. A: 13 bits (/35) is fine, it allows for aggregation per pop, the problem is the 80% usage rate. Randy: isn't the problem the percent, not matter how much it is? A: Problem is if the pops grow at different speed. A: Gert Doering, space net, Germany: We started with /19. by now, we have /16 and few /19:s, and they are not aggregated. We have resellers, and they have theirs. It fragments awfully. i am in favour of /56; or, i do not mind /48 if we can get bigger prefix (more bits) in the front. I do not need more space, but more possibility to build the hierarchy and aggregate. Joao: You have /29 contiguous block reserved to grow into. Gert: I don't see the need for slow start. There are a so many /29s the routing tables would explode before the /29s were exhausted. Bob suggests that might be solvable by rethinking the 80% usage rate (so that ISPs are not penalised for taking a long-term view from the start). Randy: He is in Frankfurt and Bon, and peers with Jurgen at both places, and announces same /35 at both places and Jurgen does not know to which one to send traffic. Chair: Want to refocus back on the recommendations of the draft. People seem to be OK with the /48. Let's move on. Need to come up with something to put in the multihoming section. For now, IPv4 method of multihoming should be used, as a short term recommendation. There is also the option to use multiple prefixes. The philosophy should be that addresses are cheap, so if someone wants to experiment with the multi address multihoming, let them and give them the addresses. Q: (Dave Pratt) Present PI space is authorised by RIPE and does NOT come from provider assigned space. I think this is a good rule *** (until better multihoming techniques are developed)*** that should be continued for IPv6. Alain Durand: Wants to emphasise that it's early in deployment and we need lots of feedback regarding whether multihoming techniques etc work. Be generous with /48s. Randy: From the proposal "if they need more address space, they get multiple /48:s". I would suggest /47. Steve: Looking to create a team to investigate how to measure usage. Maybe find a H ratio measure to apply instead of the 80% rule. Joao: the conservation is not the only issue here. WW: We want to keep the routing table small. (...) Randy: Small number of providers having TLA does not look good from the market point of view and it would create the small club who owns the Internet. A: The requirement is not only to aggregate well (shrinks the table), but also to find neutral mechanism of allocation; how to get into that club. Chair: Do you have enough info on /48 proposal? (yes) Chair: OK recommendations of this group are that /48 assignments are to go ahead. This will be taken to ARIN and APNIC.