From bs at eunet.ch Sun Feb 11 12:04:46 2001 From: bs at eunet.ch (Bernard Steiner) Date: Sun, 11 Feb 2001 12:04:46 +0100 Subject: lowering maximum assignment window In-Reply-To: Your message of "Wed, 10 Feb 1999 20:46:21 +0100." <23395.918675981@critter.freebsd.dk> Message-ID: <200102111104.MAA08813@eunet.ch> Folks, > Just for reference, I ran over 12-14h worth of trafic data (cisco > NetFlow), starting at jan27 midnight, looking for source IP numbers > which have a RIPE record of status "ALLOCATED" but not one of > "ASSIGNED". > *na: EU-EUNET-950315 > 193.73.103.80 Note: AFAIK, this is actually EUnet's PA address space. Unfortunately, the customer ran away with it and refused to give it back. I don't see why EUnet should be held responsible for keeping the database up-to-date in this case. I also wonder how many cases like this one there are out there (people running off with PA address space). Just my \(= 0.02 worth. Bernard From saeed at vax.ipm.ac.ir Mon Feb 5 09:28:47 2001 From: saeed at vax.ipm.ac.ir (SAEED KHADEMI) Date: Mon, 05 Feb 2001 11:58:47 +0330 Subject: A Question Message-ID: <009F72F3.75DCBE02.1@ROSE.IPM.AC.IR> [ Moderator note: changed local-ir at ripe.net -> lir-wg at ripe.net ] Hello, Dear coleagues, Please excuse me if this is not the right place for this kind of questions. I am working as a LIR hostmaster since 5 years ago. Due to the act of people of another LIR, a question has rised in my mind. And I want to know about any defined regulation in this regard. The Question: Is it legal that technical persons of one LIR, ask their customer to return other LIR assignments, because the customer has asked for new IP assignment? This has been accured many times. Customer having some IP assignments from LIR-1, are applying for new IP assignments from LIR-2. But people at LIR-2 are saying that if you want new IP assignments, you HAVE TO return LIR-1 assignments !!!!!!! Any comment? Kind Regards, IPM LOCAL REGISTRY, Tehran/Iran Saeed. From andre at NL.UU.NET Mon Feb 5 10:45:10 2001 From: andre at NL.UU.NET (Andre Koopal) Date: Mon, 5 Feb 2001 10:45:10 +0100 Subject: A Question In-Reply-To: <009F72F3.75DCBE02.1@ROSE.IPM.AC.IR>; from SAEED KHADEMI on Mon, Feb 05, 2001 at 11:58:47AM +0330 References: <009F72F3.75DCBE02.1@ROSE.IPM.AC.IR> Message-ID: <20010205104509.C8201@NL.UU.NET> On Mon, Feb 05, 2001 at 11:58:47AM +0330, SAEED KHADEMI wrote: > [ Moderator note: changed local-ir at ripe.net -> lir-wg at ripe.net ] > > > Hello, > Dear coleagues, Please excuse me if this is not the right place for > this kind of questions. > I am working as a LIR hostmaster since 5 years ago. Due to the act of > people of another LIR, a question has rised in my mind. And I want to > know about any defined regulation in this regard. > The Question: > > Is it legal that technical persons of one LIR, ask their customer to > return other LIR assignments, because the customer has asked for new > IP assignment? > This has been accured many times. Customer having some IP assignments > from LIR-1, are applying for new IP assignments from LIR-2. But people > at LIR-2 are saying that if you want new IP assignments, you HAVE TO > return LIR-1 assignments !!!!!!! > > Any comment? > Some thoughts on this from me, not neccesarely the truth. As LIR they can say that if you don't return space, you have to much space, so the request isn't justified. If the customer can proof he has the need for both chunks of space ... As an ISP you can (and should) refuse the customer to route his ip-space from his old provider. Both together mean that in the ordinary case of a customer migrating from one ISP to another they can force the customer to return his old space. Regards, Andre From mariank at kpn.net Mon Feb 5 11:13:54 2001 From: mariank at kpn.net (Marian Kruydenhof) Date: Mon, 5 Feb 2001 11:13:54 +0100 Subject: A Question Message-ID: <01C08F64.BAB24240@asterix.cisnet> Hello Saeed, To my knowledge it is possible for a customer to have assignments from 2 LIR's. if the customer is requesting ip space from LIR2, LIR2 should make sure that the customer will not use the ip space for the same purpose as the ip space from LIR1. for example, the customer can not address a host with ip space from both LIR1 and LIR2. How the customer will use the address space is specified in the addressingplan template. You should take this into account when evaluating the addressingplan template. What you describe below is not our policy. regards Marian Kruydenhof KPN Telecom, Netherlands -----Original Message----- From: SAEED KHADEMI [SMTP:saeed at vax.ipm.ac.ir] Sent: Monday, February 05, 2001 9:29 AM To: local-ir at ripe.net Subject: A Question [ Moderator note: changed local-ir at ripe.net -> lir-wg at ripe.net ] Hello, Dear coleagues, Please excuse me if this is not the right place for this kind of questions. I am working as a LIR hostmaster since 5 years ago. Due to the act of people of another LIR, a question has rised in my mind. And I want to know about any defined regulation in this regard. The Question: Is it legal that technical persons of one LIR, ask their customer to return other LIR assignments, because the customer has asked for new IP assignment? This has been accured many times. Customer having some IP assignments from LIR-1, are applying for new IP assignments from LIR-2. But people at LIR-2 are saying that if you want new IP assignments, you HAVE TO return LIR-1 assignments !!!!!!! Any comment? Kind Regards, IPM LOCAL REGISTRY, Tehran/Iran Saeed. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 2926 bytes Desc: not available URL: From syuval at netvision.net.il Mon Feb 5 11:36:04 2001 From: syuval at netvision.net.il (Yuval Shchory) Date: Mon, 5 Feb 2001 12:36:04 +0200 Subject: A Question Message-ID: As far as I know, there are two feasible cases: 1. The customer MOVES from one ISP to another 2. The customer connects to ANOTHER ISP, while using the other ISP 2 is usually performed either by the use of BGP or by the use of static asymmetric routing, or RADWare's LinkProof. In the 1st case, there's no reason to continue the assignment, the customer is holding addresses which they cannot use. Period. In 99.9% of the cases a customer receives a fraction of a larger aggregate, and there's no reason/possibility that the new ISP will be able to route that fraction via BGP to the world. This means - no packets would arrive to that customer (with destination IP of the old IPs), which leads us to the conclusion that the assignment should be returned. In the 2nd case, the reason here is usually high availability and/or load balancing between links/ISPs. In this situation, the customer NEEDS both the assignments. I believe that 'legal', a LIR cannot just 'demand' that a customer would return their previously-assigned IPs unless there's a reason (i.e., the situation is case #1). It might be that that specific LIR is having problems with its AW (let's say their AW is 256 ips, and the customer already has IPs, it might be that the 'new' LIR needs to send a RIPE-141 to RIPE - and they might be too lazy to do that). Just my $0.0000000000002 Regards, --- Yuval Shchory Manager Security Group NetVision Ltd. interFax: +972-3-5480255 -----Original Message----- From: Andre Koopal [mailto:andre at NL.UU.NET] Sent: Monday, February 05, 2001 11:45 AM To: lir-wg at ripe.net Subject: Re: A Question On Mon, Feb 05, 2001 at 11:58:47AM +0330, SAEED KHADEMI wrote: > [ Moderator note: changed local-ir at ripe.net -> lir-wg at ripe.net ] > > > Hello, > Dear coleagues, Please excuse me if this is not the right place for > this kind of questions. > I am working as a LIR hostmaster since 5 years ago. Due to the act of > people of another LIR, a question has rised in my mind. And I want to > know about any defined regulation in this regard. > The Question: > > Is it legal that technical persons of one LIR, ask their customer to > return other LIR assignments, because the customer has asked for new > IP assignment? > This has been accured many times. Customer having some IP assignments > from LIR-1, are applying for new IP assignments from LIR-2. But people > at LIR-2 are saying that if you want new IP assignments, you HAVE TO > return LIR-1 assignments !!!!!!! > > Any comment? > Some thoughts on this from me, not neccesarely the truth. As LIR they can say that if you don't return space, you have to much space, so the request isn't justified. If the customer can proof he has the need for both chunks of space ... As an ISP you can (and should) refuse the customer to route his ip-space from his old provider. Both together mean that in the ordinary case of a customer migrating from one ISP to another they can force the customer to return his old space. Regards, Andre From saeed at vax.ipm.ac.ir Mon Feb 5 12:03:46 2001 From: saeed at vax.ipm.ac.ir (SAEED KHADEMI) Date: Mon, 05 Feb 2001 14:33:46 +0330 Subject: A Question Message-ID: <009F7309.1C297A42.1@ROSE.IPM.AC.IR> >As far as I know, there are two feasible cases: > >1. The customer MOVES from one ISP to another >2. The customer connects to ANOTHER ISP, while using the other ISP Hi, Many Thanks for all comments. The case I meant was exactly the 2nd one. Customer has an old connectivity to LIR-1 and have got a new connection from LIR-2. >2 is usually performed either by the use of BGP or by the use of static >asymmetric routing, or RADWare's LinkProof. That's the case. >In the 2nd case, the reason here is usually high availability and/or load >balancing between links/ISPs. In this situation, the customer NEEDS both the >assignments. In this case, what should people at LIR-1 Do? Can they ask LIR-2 people to stop forcing customers? And if the answer is positive, What's the rule, if LIR-2 people continue to behave like that? >I believe that 'legal', a LIR cannot just 'demand' that a customer would >return their previously-assigned IPs unless there's a reason (i.e., the >situation is case #1). It might be that that specific LIR is having problems >with its AW (let's say their AW is 256 ips, and the customer already has >IPs, it might be that the 'new' LIR needs to send a RIPE-141 to RIPE - and >they might be too lazy to do that). I agree. Another possiblity is that LIR-2's people are trying to fulfill their own test period ( according to RIPE NCC slow starting ) and somehow attack to LIR-1 reputation. Kind Regards, IPM LOCAL REGISTRY, Tehran-Iran Saeed. From nospam at nospam.geht.net Mon Feb 5 14:45:55 2001 From: nospam at nospam.geht.net (Valentin Hilbig) Date: Mon, 5 Feb 2001 14:45:55 +0100 Subject: A Question References: <009F72F3.75DCBE02.1@ROSE.IPM.AC.IR> Message-ID: <003301c08f79$ff40b760$8301010a@intra.skytecag.de> My personal thoughts about this: As a LIR technician you should know: This is perfectly legal because inescapable. According to RIPE regulations, you have to return your addresses when you drop the connection to a LIR. Only addresses which can be reached from Internet directly may continue to exist and PA addresses from another ISP are never reachable from Internet. As the addresses are PA and not PI you have to renumber your network. The customer has to be made aware of this fact by the LIR. In case the customer wasn't informed about this fact that changing the uplink provider means to change IPs too, this is a problem between the old uplink and the customer and not about the new uplink, as the new uplink cannot be held responsible for errors somebody other did. This even holds in case that the customer has 2 or more independent Internet connections. In this case the customer should switch to BGP4 and do following: a) Get some PI address space. I cannot recommend this as PI address space is not as good as PA and you cannot be sure that all ISPs in the world accept announcements with a higher prefix than /20. From reachability point of view PI addresses are definitively a problem if you care about the fact that one might have to provide best possible service to the customers. If you can ignore that perhaps you cannot reach some weird edges in asia or so, then take PI, but be sure to get a least a /24 block. I know someone myself who is happy with his /23 PI block. And with PI you never have to renumber if you change your uplink. b) Get some PA address space and redistribute it into BGP4. I cannot recommend this as PA addresses have the problem that many ISPs filter them according to the routing database. And I as a BGP4 sysop would ignore smaller aggregations in routing entries, as they are redundant or maybee an error. As a result the IPs don't take the shortest path back to the customer which may lead to higher costs at the customer's side. Besides the higher costs redistributing PA into BGP4 should have no bad sideeffect (or am I not aware of something?). In Europe the possibly higher imposed cost factor is so extreme, that I definitively can only discourage from using PA for BGP4 redistribution (in case you have M uplinks it my be that you have M times the traffic price when M-1 of your uplink lines go down). Another bad fact is that with PA you have to renumber when you drop the link to the LIR which issued the IPs. c) Become your own LIR. I can recommed this in case that you go multihomed with your own AS and don't want to renumber any more in future. Note that this is exactly what I am currently doing here ;) OK, that's my opinion, but I am no lawyer. -Tino PS: I send this to the list even that I read the other posts ;) ----- Original Message ----- From: "SAEED KHADEMI" To: Sent: Monday, February 05, 2001 9:28 AM Subject: A Question > [ Moderator note: changed local-ir at ripe.net -> lir-wg at ripe.net ] > > > Hello, > Dear coleagues, Please excuse me if this is not the right place for > this kind of questions. > I am working as a LIR hostmaster since 5 years ago. Due to the act of > people of another LIR, a question has rised in my mind. And I want to > know about any defined regulation in this regard. > The Question: > > Is it legal that technical persons of one LIR, ask their customer to > return other LIR assignments, because the customer has asked for new > IP assignment? > This has been accured many times. Customer having some IP assignments > from LIR-1, are applying for new IP assignments from LIR-2. But people > at LIR-2 are saying that if you want new IP assignments, you HAVE TO > return LIR-1 assignments !!!!!!! > > Any comment? > > Kind Regards, > IPM LOCAL REGISTRY, Tehran/Iran > Saeed. > > > From eamonn at ripe.net Tue Feb 6 10:59:42 2001 From: eamonn at ripe.net (Eamonn McGuinness) Date: Tue, 06 Feb 2001 10:59:42 +0100 Subject: A Question In-Reply-To: Your message of Mon, 05 Feb 2001 11:58:47 +0330. <009F72F3.75DCBE02.1@ROSE.IPM.AC.IR> References: <009F72F3.75DCBE02.1@ROSE.IPM.AC.IR> Message-ID: <200102060959.KAA08778@x15.ripe.net> Dear all, Thanks to those who have contributed to this discussion. We have seen some good advice. This is our contribution to clarify the policy. Firstly, end users are not restricted by the number of ISPs they connect to as long as the IP address space they use is for different purposes. It has been correctly pointed out that end users can and do apply to a 2nd provider for an additional connection for whatever reasons (i.e. load balancing) so they can apply to use addresses from this 2nd provider for these purposes. However, should an end user migrate from one LIR to another we would expect them to return their old assignment. If the new LIR has no assignment-window (AW) the request will have to be sent to us for our evaluation. We would expect the current address space to be documented in the Current Usage Template, plus comments on the changes in the network with the new LIR. But remember to write contracts with your customers. Use the paragraphs from ripe-127, irrespective of the type of address space you are assigning (PA/PI). At end of the day LIRs have different approaches to deal with different situations and that is their business. Here are the relevant sections of the European Internet Registry Policies and Procedures (RIPE-185) and our emphasis on important sentences : http://www.ripe.net/ripe/docs/ripe-185.html 3.5.Replacing IP Addresses [..] 3.5.Replacing IP Addresses While the procedures for numbering and renumbering hosts in an IP network are becoming less troublesome, ASKING OR FORCING END USERS TO RENUMBER IS SOMETIMES PROBLEMATIC. The renumbering process usually requires a considerable amount of time and effort both on the part of the end users and on the part of the ISPs and Local IRs involved. In some cases, there is a clear obligation to replace address space assignments, and LOCAL IRs SHOULD BE PREPARED TO SUPPORT THEIR CUSTOMERS IN THE PROCESS. A more general and very important case is the (voluntary) replacement of PI address space which for historical reasons has been randomly assigned and cannot be aggregated with other PA assignments. Such replacements can play a key role in containing the GROWTH OF ROUTING TABLES, and thus for the maintainability of the Internet as a whole. Because the renumbering process is nontrivial, the Internet Registry System as a whole must support the process as far as possible. During the period in which end users migrate individual services or parts of their networks to the new address space, complications may arise. In many cases, they may need to be CONNECTED TO MORE THAN ONE ISP FOR THE DURATION OF THE TRANSITION PERIOD, and sometimes ADDRESSES FROM BOTH THE OLD RANGE(S) AND THE NEW MIGHT HAVE TO BE MANAGED AND USED IN PARALLEL. With the goals of aggregation and conservation in mind, as well as to minimise duplicate logistics, this period should be kept as short as possible. IP Address Space Replacement Procedures: IN GENERAL, ADDRESS SPACE SHOULD BE REPLACED ON A ONE-TO-ONE BASIS. An assignment of PA space to replace previously assigned PI space can be made if the original assignment criteria are still met and if the address space to be replaced is currently used for the end user's network. Only if a large percentage of the original assignment is not in use (50% or more than 4096 addresses) will an end user be required to submit the usual documentation to the new registry. This part of the request is then treated like any other request for assignment of additional addresses. The address space to be replaced (the individual address ranges and the total size) must be properly documented with the standard IP address space assignment request forms. For address space that was allocated by Local IRs established within the framework of the RIPE NCC, a copy of the documentation is forwarded to the registry or registries that assigned the address space being replaced. Before assigning the new address space, an agreement (preferably contractual) should be reached regarding the maximum period within which the previously assigned addresses will be returned to the original registry or to the regional registry for eventual reassignment. After the renumbering is complete, the database must be updated to reflect the changes. Whenever a large amount of addresses are to be replaced (the equivalent of a /20 or more) the Regional IR must be informed about the intended replacement and the agreements on the maximum period of parallel assignments. In complex cases, the Regional IR may decide to provide guidance in the process of managing the address space replacement. In general A PERIOD OF 3 MONTHS SHOULD BE ALLOWED FOR THE END USER TO COMPLETE THE TRANSITION TO THE NEW ADDRESSES. RFC 2008 "Implications of Various Address Allocation Policies for Internet Routing" [Rekhter96a] recommends a grace period of at least 30 days, and no longer than six months. For exceptional cases, where the end user requests to keep both assignments for more than 6 months, approval should be obtained for the proposed time frame from the RIPE NCC. For those addresses that have not been assigned by a Local IR, or which were assigned by an IR that has since closed, the Regional IR will act in lieu of the original registry. 3.5.1.Multihomed Users AN END USER MAY HAVE REASON TO OBTAIN CONNECTIVITY THROUGH MORE THAN ONE SERVICE PROVIDER. IF SO, IT MAY BE NECESSARY TO OBTAIN ADDRESS SPACE ASSIGNMENTS FROM MORE THAN ONE IR TO SUPPORT DIFFERENT PARTS OF THE USER'S NETWORK. IN GENERAL, THERE IS NO PROBLEM WITH USERS ACQUIRING ADDRESS SPACE AND SERVICE FROM MORE THAN ONE IR. THEIR NETWORKS ARE THEN REFERRED TO AS MULTIHOMED. Because users can be multihomed, IRs must be especially careful in reviewing address space requests, and the corresponding CURRENT ADDRESS SPACE USAGE described in section 3.2.1.2. One must be sure that USERS ARE NOT ACQUIRING MULTIPLE ASSIGNMENTS FOR THE SAME PURPOSE FROM DIFFERENT IRs. Moreover, one must check that a similar address space request has not been refused by another IR for some valid reason. Kind regards, Eamonn McGuinness RIPE NCC Hostmaster Team Leader Go faster ! http://www.ripe.net/ripencc/tips/tips.html http://www.ripe.net/ripencc/faq/index.html WebAsused ! http://www.ripe.net/ripe/mail-archives/lir-wg/20001001-20010101/msg00029.html In message <009F72F3.75DCBE02.1 at ROSE.IPM.AC.IR>you write: >[ Moderator note: changed local-ir at ripe.net -> lir-wg at ripe.net ] > > >Hello, > Dear coleagues, Please excuse me if this is not the right place for >this kind of questions. > I am working as a LIR hostmaster since 5 years ago. Due to the act of >people of another LIR, a question has rised in my mind. And I want to >know about any defined regulation in this regard. > The Question: > > Is it legal that technical persons of one LIR, ask their customer to >return other LIR assignments, because the customer has asked for new >IP assignment? > This has been accured many times. Customer having some IP assignments >from LIR-1, are applying for new IP assignments from LIR-2. But people >at LIR-2 are saying that if you want new IP assignments, you HAVE TO >return LIR-1 assignments !!!!!!! > > Any comment? > >Kind Regards, >IPM LOCAL REGISTRY, Tehran/Iran >Saeed. > > > > From leo at ripe.net Wed Feb 7 16:34:50 2001 From: leo at ripe.net (leo vegoda) Date: Wed, 7 Feb 2001 16:34:50 +0100 Subject: Fixed Boundary (/29) Assignments Message-ID: <20010207163450.T11994@ripe.net> Dear all, In my presentation to the Working Group at RIPE 38 [0] I brought up the issue of assignment policies for ISPs wanting to assign all customers a fixed size network (/29). The RIPE NCC is experiencing an increase of requests for this type of setup and would therefore like the community's input on this matter. There is no specific mention of broadband connections or fixed-boundary assignments in the current policy. However, we believe that the policy now requires LIRs to make assignments on the usage-based requirements of the subscriber. This is consistent with the RIRs' goal of conservation. The method of assigning a standard prefix size is certainly quite wasteful as one quarter of the space is lost on network and broadcast addresses. The requester justification for this assignment method is an estimation of the number of customers taking IP based services or having multiple Internet connected terminals at home. As a reference, it may be worth noting that in recent discussions on the IETF mailing list, Bernard Aboba estimates [1] that currently 27% of homes have multiple 'PCs'. It is difficult to predict the take-up of non-Internet IP-based services. Based on the above, we would like the Working Group to consider whether: - a standard, fixed-boundary assignment is acceptable for residential broadband connections? Or - should the requester (the LIR) be required to ask the subscriber how many IP devices will be connected and base the assignment upon this? Regards, leo vegoda RIPE NCC Hostmaster [0] http://www.ripe.int/ripe/wg/lir/present/ [1] http://www.ietf.org/mail-archive/ietf/Current/msg10586.html From huberman at gblx.net Wed Feb 7 17:04:15 2001 From: huberman at gblx.net (David R Huberman) Date: Wed, 7 Feb 2001 09:04:15 -0700 (MST) Subject: Fixed Boundary (/29) Assignments In-Reply-To: <20010207163450.T11994@ripe.net> Message-ID: Hello everyone, It is my experience, both as a former RIR employee and as a former employee of a large residential DSL provider in the United States, that by affording all residential broadband provider the flexibility to make address policy along a fixed /29 boundary will result in MORE conservation of address space, not less. Residential broadband is a market that is demand driven. The RIRs should be seeking to take addressing out of the competitive side of the market, and equal the playing field for all providers in the name of address conservation. It has been my experience that customers will ask for MORE address space (3+ usable, publicly-unique addresses), not less (I only have one PC, so obviously I only need 1), when given a choice. If, other factors being equal, customers can shop broadband providers on the basis of 'how much publicly unique address space will you provide me', an imbalance will inevitably result - the long-term consequences of which would be increased IP wastage. RIPE needs to allow providers to assign /29s to residential broadband customers without question and apply its justification policies only for residential assignments shorter than a /29. /david *--------------------------------* | Global Crossing IP Engineering | | Manager, Global IP Addressing | | TEL: +1 908 720-6182 | | FAX: +1 703 464-0802 | *--------------------------------* From BCA at fakse.dk Wed Feb 7 17:07:01 2001 From: BCA at fakse.dk (Bjarne Carlsen) Date: Wed, 7 Feb 2001 17:07:01 +0100 Subject: Fixed Boundary (/29) Assignments Message-ID: My $0,02: As I stated on the RIPE-meeting, one should consider the goal of preservation most carefully when contemplating any standard assignments for specific services. The proposed /29 assignment seems to me, (and I work for a cable provider), to be wasteful. I vote for the second option. Let the LIR ask for current and expected use. Rgds Bjarne Carlsen Fakse Municipality From robin at cerbernet.co.uk Thu Feb 8 00:22:27 2001 From: robin at cerbernet.co.uk (Robin) Date: Wed, 07 Feb 2001 23:22:27 +0000 Subject: Fixed Boundary (/29) Assignments In-Reply-To: <20010207163450.T11994@ripe.net> Message-ID: <4.2.0.58.20010207224539.00a3bc90@mailhost.cerbernet.co.uk> Hi Leo, I have a few problems with several of the issues you have raised here. As regards assigning broadband customers a standard block, I think this is ignoring two very important features of everyone's favorite form, ripe-141, in particular the three year IP requirement and the potential to use NAT. In my experience, most residential customers are quite happy to use private IP addresses, especially those unfamiliar with internet security. As most home users only want something faster than their modem, there are few problems with this, other than Napster and netscape messenger not working. For those customers requiring real IP addressing, I find that many of these are businesses. As such, it is very limiting to leave them with a /29 (only five IP addresses usable to the customer) Especially if this is to be their assignment for the next three years. While I can see the time that can be saved by offering a standard IP assignment, I do not feel this is in the spirit of the 141 in determining the exact IP requirements of the customer. My main object is with assignment based on usage requirements . I know people who run offices with dozens of people of a dual channel ISDN line. Does this make them less worthy of IP addreses that a single home user with a 3Mb DSL line? I know that IP conservation is now more important than ever, but surely this could be policed better by promoting the use of private IP addressing, rather than by restricting users who cannot afford to buy more bandwidth. R At 16:34 07/02/01 +0100, you wrote: >Dear all, > >In my presentation to the Working Group at RIPE 38 [0] I brought up the >issue of assignment policies for ISPs wanting to assign all customers a >fixed size network (/29). > >The RIPE NCC is experiencing an increase of requests for this type of setup >and would therefore like the community's input on this matter. > >There is no specific mention of broadband connections or fixed-boundary >assignments in the current policy. However, we believe that the policy now >requires LIRs to make assignments on the usage-based requirements of the >subscriber. This is consistent with the RIRs' goal of conservation. > >The method of assigning a standard prefix size is certainly quite wasteful >as one quarter of the space is lost on network and broadcast addresses. > >The requester justification for this assignment method is an estimation of >the number of customers taking IP based services or having multiple >Internet connected terminals at home. > >As a reference, it may be worth noting that in recent discussions on the >IETF mailing list, Bernard Aboba estimates [1] that currently 27% of homes >have multiple 'PCs'. It is difficult to predict the take-up of non-Internet >IP-based services. > >Based on the above, we would like the Working Group to consider whether: > > - a standard, fixed-boundary assignment is acceptable for residential > broadband connections? > >Or > > - should the requester (the LIR) be required to ask the subscriber how > many IP devices will be connected and base the assignment upon this? > >Regards, > >leo vegoda >RIPE NCC Hostmaster >[0] http://www.ripe.int/ripe/wg/lir/present/ >[1] http://www.ietf.org/mail-archive/ietf/Current/msg10586.html From huberman at gblx.net Thu Feb 8 01:34:00 2001 From: huberman at gblx.net (David R Huberman) Date: Wed, 7 Feb 2001 17:34:00 -0700 (MST) Subject: Fixed Boundary (/29) Assignments In-Reply-To: <4.2.0.58.20010207224539.00a3bc90@mailhost.cerbernet.co.uk> Message-ID: > In my experience, most residential customers are quite happy to use private > IP addresses I must respectively disagree, and disagree vehemently. In my experiences, residential broadband customers, paying high monthly fees, demand publicly routable IP address space, citing both the very 'limitations' of private address space you articulate (e.g. Napster and other IP-dependent applications) and sales pitches of other providers who are willing to give them publicly unique address space just to close the deal. > For those customers requiring real IP addressing, I find that many of these > are businesses. As such, it is very limiting to leave them with a /29 We are not discussing commercial broadband customers. The fixed-boundary assignment 'proposal' is exclusively for residential broadband customers. > My main object is with assignment based on usage requirements . I know > people who run offices with dozens of people of a dual channel ISDN line. > Does this make them less worthy of IP addreses that a single home user with > a 3Mb DSL line? IP requirements for commercial customers are based on traditional address policies - as such, organizations can obtain as much address space as they require based on justification. No one is ever denied address space which they can justify, right? > I know that IP conservation is now more important than ever, but > surely this could be policed better by promoting the use of private IP > addressing, rather than by restricting users who cannot afford to buy > more bandwidth. Those who use private addressing schemes should certainly feel good about themselves, but no one is being restricted. If you can justify address space per the published criteria, you get it. More importantly, the conservationist's desire to promote the use of private address space should not take precedence over real-world business concerns. Market demand for residential DSL is high, and in many markets, IPs have become a selling point. By allowing fixed-boundary assignments, RIPE effectively removes that facet of competition, equalling and opening the playing field to all and reducing IP waste in the long-term. /david From ripe-ml at cyberstrider.net Thu Feb 8 09:15:58 2001 From: ripe-ml at cyberstrider.net (Denesh Bhabuta) Date: Thu, 08 Feb 2001 08:15:58 +0000 Subject: Fixed Boundary (/29) Assignments Message-ID: <5.0.2.1.2.20010208081551.03c6c868@mail.own.cyberstrider.net> At 15:34 07/02/2001, leo vegoda wrote: >In my presentation to the Working Group at RIPE 38 [0] I brought up the >issue of assignment policies for ISPs wanting to assign all customers a >fixed size network (/29). Please let me thank you for that presentation.. it was very good and showed RIPE being aware of the issue that will potentially explode in the coming months. >Based on the above, we would like the Working Group to consider whether: > - a standard, fixed-boundary assignment is acceptable for residential > broadband connections? >Or > - should the requester (the LIR) be required to ask the subscriber how > many IP devices will be connected and base the assignment upon this? I believe that both should be done depending on the end customer scenario. What is certain is that a lot of LIRs, mainly the new ones - telcos with (or trying to market) IP services are currently on the Broadband bandwaggon.. in todays marketing language this translates as xDSL and whether it is right to consider this as a broadband solution or not is a matter for another discussion.. ;-) What needs to be considered first is the industry and what the 'big' guys are doing... and how this affects what the smaller companies and the start-ups offer. This is what I see happening right now... as an example: Large European Telco 'Alman Telecom' sells it's DSL product very well. The marketing of the product spec actually mentions that the customer will be getting 16 IP addresses. Customers know the Alman brand, and they see what it offers and hence they go for it. As a side note, RIPE need to be aware that telcos are mentioning right now how many IPs are given in a product, and do not mention RIPE anywhere in the contract or make the customer aware that there is that RIPE obligation. Small Startup Telco 'LastChoice Telecommunications' offers the same product, but is new in the market. It has to compete for market share and has to offer something better than Alman. One way of doing this... and remember product managers are not always IP literate, is to offer more IP addresses. This strategy is also fine by the marketing director and every other director in the organisation - as they are not concerned about RIPE... to them, they have paid RIPE and they have the IP addresses (note that AFAICS, a lot of the new LIRs are telcos with non-IP people or people who are not experienced with RIPE - and I really believe that RIPE need to acknowledge this). Today, number of IP addresses given to a customer *are* used as a market share gaining tool. So, IMHO, the main issue is to look at the industry itself and look at how the big players are acting first, and to bring them in line. Further on from this, we need to look at how DSL is being rolled out and how the telcos want to sell the product. A lot of the telcos I talk to want to be doing a minimum of 100 xDSL sales per day! Under traditional techniques, this would require each telco to have a large number of hostmasters/people to deal with 141 forms in an efficient manner... telcos do not want to spend money on getting more people.. So what do they do instead? Either 141 forms do not get filled or 'standard' RIPE forms are filled in, and/or the quality of the data in a 141 form falls. In addition, RIPEs auditing activities become more resource hungry. My proposal would be a change in policy, incorporating the points that Leo has raised, such that: 1) Standard 141 forms / standard details are allowed for xDSL assignments. These standard forms should allow an automatic assignment to the end customer of 4 IP addresses (instead of 8 as suggested by Leo. This can cover both residential and business customers. After all, ISPs should push NAT in the main ;) 2) For those customers who require that bit more, they can go through the standard 'what we have come to love' RIPE-141 procedure. :-) So the best of both worlds.. standard set up customers throughout Europe - RIPE knows what is happening and most ISPs/Telcos can be happier where they can spend more time earning their money.. and for anything else, the standard RIPE procedures are followed. ISPs/Telcos should be kept to this policy and they should be discouraged from advertising 'x number of IP addresses' with their products... Oh, and those ISPs that push NATd xDSL with 1 static IP for the customer.. maybe a pat on their back. ;-) Regards Denesh -- Denesh Bhabuta Chairman, CEO and Principal Consultant Cyberstrider Limited www.cyberstrider.net Internet and E-Commerce: Strategy, Consultancy and Solutions From javier at bitmailer.com Thu Feb 8 11:11:14 2001 From: javier at bitmailer.com (Javier Llopis) Date: Thu, 08 Feb 2001 10:11:14 +0000 Subject: Fixed Boundary (/29) Assignments Message-ID: <20010208091141.7EFF39CCD4@proxy.bitmailer.com> On Wed, 7 Feb 2001 09:04:15 -0700 (MST), David R Huberman wrote: >Hello everyone, > >It is my experience, both as a former RIR employee and as a former >employee of a large residential DSL provider in the United States, that by >affording all residential broadband provider the flexibility to make >address policy along a fixed /29 boundary will result in MORE conservation >of address space, not less. I appreciate your insight, David, but I fail to see this point. How do you save IP space by assigning 8 IP addresses instead of just one? > >Residential broadband is a market that is demand driven. The RIRs should >be seeking to take addressing out of the competitive side of the market, >and equal the playing field for all providers in the name of address >conservation. Absolutely agreed, however, in the rest of your message you seem to imply that fixed boundary assignments are a must if one wants to stay competitive. I don't doubt that. Although I don't see this happening down here, I appreciate that you share your experience as an indication of the scenario we are going to be facing shortly. >It has been my experience that customers will ask for MORE address space >(3+ usable, publicly-unique addresses), not less (I only have one PC, so >obviously I only need 1), when given a choice. Yes, just as when they take five ketchup bags at McDonalds and they use only one. >From a consumer point of view, MORE no-matter-what is BETTER. I think it is sad that some people are starting to use IP addresses as assets to make their offer look better. >If, other factors being equal, customers can shop broadband providers on >the basis of 'how much publicly unique address space will you provide me', >an imbalance will inevitably result - the long-term consequences of which >would be increased IP wastage. > >RIPE needs to allow providers to assign /29s to residential broadband >customers without question and apply its justification policies only for >residential assignments shorter than a /29. Mmmm... Disallowing automatic fixed boundary assignments for that purpose for everyone would work just as good in balancing the market. I wish IPv6 technology would be common enough between LIRS so we could give every residential customer 32 IPv6 addresses or 1 IPv4 address at their choice, so that woud skyrocket the demand of low-end IPv6 hardware and solve the address problem forever. Regards Javier Llopis BitMailer javier at bitmailer.com Juan Bravo 51, Dup. 1-Izq Tel: +34 91 402 1551 28006 Madrid Fax: +34 91 402 4115 SPAIN From phk at critter.freebsd.dk Wed Feb 7 18:09:26 2001 From: phk at critter.freebsd.dk (Poul-Henning Kamp) Date: Wed, 07 Feb 2001 18:09:26 +0100 Subject: Fixed Boundary (/29) Assignments In-Reply-To: Your message of "Wed, 07 Feb 2001 17:07:01 +0100." Message-ID: <2402.981565766@critter> I think we need to make sure we make it *absolutely* clear to the endusers that they have borrowed one or more IPnumbers, and that they have no "IP-for-a-lifetime" claims to those numbers in any way, neither in the count of them nor in the specific numbers they have. I personally think that NAT technologies work well enough that people can survive just fine with a single IP number. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From BCA at fakse.dk Thu Feb 8 10:50:43 2001 From: BCA at fakse.dk (Bjarne Carlsen) Date: Thu, 8 Feb 2001 10:50:43 +0100 Subject: SV: Fixed Boundary (/29) Assignments Message-ID: > -----Oprindelig meddelelse----- > Fra: David R Huberman [SMTP:huberman at gblx.net] > Sendt: 8. februar 2001 01:34 > Til: Robin > Cc: lir-wg at ripe.net > Emne: Re: Fixed Boundary (/29) Assignments > > > > In my experience, most residential customers are quite happy to use > private > > IP addresses > > I must respectively disagree, and disagree vehemently. In my experiences, > residential broadband customers, paying high monthly fees, demand publicly > routable IP address space, citing both the very 'limitations' of private > address space you articulate (e.g. Napster and other IP-dependent > applications) [Bjarne Carlsen] This can easily be made with NAT or IP-masquerading. IME the average residential user does not give a hoot whether his address space is publicly routable or not, as long as he can run Napster or AGSatellite from all of his network, he is much more interested in IP-ports than in IP-addresses, since many providers block most IP-ports from their local network. > and sales pitches of other providers who are willing to give > them publicly unique address space just to close the deal. [Bjarne Carlsen] See answer to last para below. > > > For those customers requiring real IP addressing, I find that many of > these > > are businesses. As such, it is very limiting to leave them with a /29 > > We are not discussing commercial broadband customers. The fixed-boundary > assignment 'proposal' is exclusively for residential broadband customers. > > > My main object is with assignment based on usage requirements . I know > > people who run offices with dozens of people of a dual channel ISDN > line. > > Does this make them less worthy of IP addreses that a single home user > with > > a 3Mb DSL line? > > IP requirements for commercial customers are based on traditional address > policies - as such, organizations can obtain as much address space as they > require based on justification. No one is ever denied address space which > they can justify, right? [Bjarne Carlsen] Exactly - then why not let the users justify their actual needs instead of wasting up to 66% of the address space (this includes never-used IP's)? > > I know that IP conservation is now more important than ever, but > > surely this could be policed better by promoting the use of private IP > > addressing, rather than by restricting users who cannot afford to buy > > more bandwidth. > > Those who use private addressing schemes should certainly feel good about > themselves, but no one is being restricted. If you can justify address > space per the published criteria, you get it. > > More importantly, the conservationist's desire to promote the use of > private address space should not take precedence over real-world business > concerns. [Bjarne Carlsen] Maybe not, but the real-world business is trying to oversell a limited commodity. > Market demand for residential DSL is high, and in many markets, > IPs have become a selling point. By allowing fixed-boundary assignments, > RIPE effectively removes that facet of competition, equalling and opening > the playing field to all and reducing IP waste in the long-term. [Bjarne Carlsen] No way! RIPE will effectively remove that facet of competition by _enforcing_ the rules as they are today - not by wasting address space on the proposed /29-scheme. > /david > /Bjarne From neil at COLT.NET Thu Feb 8 10:22:27 2001 From: neil at COLT.NET (Neil J. McRae) Date: Thu, 8 Feb 2001 09:22:27 +0000 (GMT) Subject: Fixed Boundary (/29) Assignments In-Reply-To: <5.0.2.1.2.20010208081551.03c6c868@mail.own.cyberstrider.net> from Denesh Bhabuta at "Feb 8, 2001 08:15:58 am" Message-ID: <200102080922.JAA14924@NetBSD.noc.COLT.NET> Two things: Alot of what you state is not a new problem, I know of several organisations that have emailed the RIPE to complain about the activities of some SPs, with regards to IP addressing, secondly for this entire reply do a s/telcos/service provider/g > Large European Telco 'Alman Telecom' sells it's DSL product very well. The > marketing of the product spec actually mentions that the customer will be > getting 16 IP addresses. Customers know the Alman brand, and they see what > it offers and hence they go for it. > > As a side note, RIPE need to be aware that telcos are mentioning right now > how many IPs are given in a product, and do not mention RIPE anywhere in > the contract or make the customer aware that there is that RIPE obligation. Have you purchased anything from all of these big telcos? Have you gone through the proceses for every [any] telco? Whilst they may not mention RIPE alot of providers do a justification form within their order form [COLT and one other "major player" does this in the UK]. > Small Startup Telco 'LastChoice Telecommunications' offers the same > product, but is new in the market. It has to compete for market share and > has to offer something better than Alman. One way of doing this... and > remember product managers are not always IP literate, is to offer more IP > addresses. This strategy is also fine by the marketing director and every > other director in the organisation - as they are not concerned about > RIPE... to them, they have paid RIPE and they have the IP addresses (note > that AFAICS, a lot of the new LIRs are telcos with non-IP people or people > who are not experienced with RIPE - and I really believe that RIPE need to > acknowledge this). > > Today, number of IP addresses given to a customer *are* used as a market > share gaining tool. I don't think this is hugely widespread as you are implying although I do accept that it is happening - but this is an old problem, I remember the leased line "we'll give you a class C guv" issues. > So, IMHO, the main issue is to look at the industry itself and look at how > the big players are acting first, and to bring them in line. Absolute rubbish - The industry needs to be looked at across the board, and not just in this product line, many companies providing DSL access, who are not big players, but because of their speed to the market are gaining a large chunk of the market share. > Further on from this, we need to look at how DSL is being rolled out and > how the telcos want to sell the product. A lot of the telcos I talk to want > to be doing a minimum of 100 xDSL sales per day! Under traditional > techniques, this would require each telco to have a large number of > hostmasters/people to deal with 141 forms in an efficient manner... telcos > do not want to spend money on getting more people.. So what do they do > instead? Either 141 forms do not get filled or 'standard' RIPE forms are > filled in, and/or the quality of the data in a 141 form falls. In addition, > RIPEs auditing activities become more resource hungry. I agree that this is true. > > My proposal would be a change in policy, incorporating the points that Leo > has raised, such that: > > 1) Standard 141 forms / standard details are allowed for xDSL assignments. > These standard forms should allow an automatic assignment to the end > customer of 4 IP addresses (instead of 8 as suggested by Leo. This can > cover both residential and business customers. After all, ISPs should push > NAT in the main ;) If you do this it won't help this issue- most people want more than 1 usable address, esp if they have a firewall or mail server. > 2) For those customers who require that bit more, they can go through the > standard 'what we have come to love' RIPE-141 procedure. :-) I'm not sure what you mean by the RIPE-141 procedure? But in my view for any number of IP addresses >1 RIPE-141 data should be collected in the normal way, [to be frank anyone who doesn't know what their customer is doing isn't a good service provider and won't be able to upsell them lovely value adds :-)]. but I accept that this isn't everyones pitch, and in the residential market this is difficult to manage- but to be frank a SP has to take bank details address etc for installation is the data asked for in a 141 form really all that much more to ask for? I don't think so. [SP's could webify it and offer a 5-10 pound discount for orders placed via the web or something along those lines]. > So the best of both worlds.. standard set up customers throughout Europe - > RIPE knows what is happening and most ISPs/Telcos can be happier where they > can spend more time earning their money.. and for anything else, the > standard RIPE procedures are followed. > > ISPs/Telcos should be kept to this policy and they should be discouraged > from advertising 'x number of IP addresses' with their products... I agree with the above but in reality its almost impossible to achieve. > Oh, and those ISPs that push NATd xDSL with 1 static IP for the customer.. > maybe a pat on their back. ;-) Indeed, but again this applies to a number of products, dedicated access, hosting, cable access, isdn access and colo. The issue that it seems that is trying to be solved is mostly an old one and the fact that people have higher volumes of network requests shouldn't be the only factor in deciding policy. Regards, Neil. From tkernen at deckpoint.ch Thu Feb 8 16:48:19 2001 From: tkernen at deckpoint.ch (Thomas Kernen) Date: Thu, 8 Feb 2001 11:48:19 -0400 Subject: Fixed Boundary (/29) Assignments References: Message-ID: <030901c091e6$93088a90$0b00a8c0@WOLFORD> All, I would agree that the idea of /29 per residential customer is nice from a mangement point of view but I do believe that the extra overhead for handling the 141 form for each customer is required and that the assigned IP space should be on a per customer basis. As mentioned in many of the replies, customers and management are not aware of the RIPE IP assignement policies and need to know about this. Unfortunaly is has to be done and the marketing argument that competition provides as many IPs are the customer wishes is no solution to the problem. I've been handling IP addressing for a few service providers over the last 4-5 years and I do believe that IP addressing should be done on an indiviual basis that corresponds to the customer profile, even for residential customers. my 0.02$ Thomas From thk at nextra.com Thu Feb 8 12:48:32 2001 From: thk at nextra.com (Thor-Henrik Kvandahl) Date: Thu, 8 Feb 2001 12:48:32 +0100 (MET) Subject: Fixed Boundary (/29) Assignments In-Reply-To: Message-ID: I agree with Bjarne. The proposed /29 assignment is wasteful. DSL customers should be dealt with as all the other. One official dynamically assigned /32 (no NAT here) pr. customer should do it for the majority of the "non business" customers. And if some of them needs to be assigned official addresses they must fill in "the form". And if some providers market DSL products which include 8, 16, 32 or more IP addresses, this is OK as long as these customers document their needs. I also think the RIR's should take notice of this practice and perhaps focus their audits on these providers. -- Regards, Thor-Henrik Kvandahl Nextra AS On Wed, 7 Feb 2001, Bjarne Carlsen wrote: > My $0,02: > > As I stated on the RIPE-meeting, one should consider the goal of > preservation most carefully when contemplating any standard assignments for > specific services. The proposed /29 assignment seems to me, (and I work for > a cable provider), to be wasteful. > > I vote for the second option. Let the LIR ask for current and expected use. > > Rgds > Bjarne Carlsen > Fakse Municipality > > From nospam at nospam.geht.net Thu Feb 8 12:35:14 2001 From: nospam at nospam.geht.net (Valentin Hilbig) Date: Thu, 8 Feb 2001 12:35:14 +0100 Subject: Fixed Boundary (/29) Assignments References: <20010207163450.T11994@ripe.net> Message-ID: <01b501c091ca$17a53c20$8301010a@intra.skytecag.de> Two things to this from my side: 1) A /30 is even more waste and a /28 is usually not needed, so a /29 sounds reasonable if we are speaking of dumb modems. 2) However what should be discussed is if it is really impossible to assign a /30 which allows the use of 4 IP addresses. For this all you need is a clever DSL router with (yes, yuck!) Proxy-ARP enabled and disabled Broadcast-Option. I did a similiar setup for an Intranet on private IPs (thus conservation criterias were not interesting) and it was quite successfull as all those braindead NT boxes then had no problem to find each other. The advantage of this type of setup is that you can place the Router's IP at the "edge of the block" outside of the "smaller IP area", thus again conserve more IPs as all DLS modems within this block share the same IP address (on the interface side to the customer. If the DSL modem needs an IP for administration this can taken out of a private IP block. For ICMP/Traceroute the shared public IP can be utilized easily, the DSL modem itself does not need to be reachable from Internet. Note that for the intranet I did this to simplify networking setup of non-DHCP roaming machines, as all that has to be changed was the IP, netmask, gateway and routing table stayed unchanged everywhere). The idea is to have one huge network where the DSL's are connected to. Each endpoint gets a usable block of /30, thus 4 IPs. However the netmask is /24 or comparable (in the Intranet it was /16 and the locations got a /24). So you are allowed to use 4 IPs out of a bigger block and you can use them transparently because of the Proxy Arp. Users who are paranoied of such a setup because many braindead (namely Microsoft) tools out there treat IPs as "local" based on the netmask, can still fall back to a standard /30 setup, thus reducing their usable IPs to 1. So you have best of both: Either 1 IP usable for "standard Surfers" or 4 public usable for "power users" (as Power Users should have a DMZ this then is viable). And if this is not enough it's simple to extend it without waste by 4 more IPs which don't need to be aggregated ;) Another thing that happens with this setup is that the "lowest and the highest" Sub-Block cannot be given to the customer. This way you get two areas (3 usable IPs from 0 up and 2 from top down) which are "link local". I used it the way that I placed "public well known services" in the top block (like Nameservers and so) and "real local services" in the bottom. This is easy to remember as well. At locations where there was no dedicated "public well known services server" in the top block this was "imported" using a dedicated tunnel to a suitable server at another location. This should simplify network setup for the provider, too. I know what I write here. I know the implications. I know the objections. I know why I would do it ;) The only thing I want is to note it that with a little effort conservation can be done much more effectively (as this model halves the IP demand but reduces the usable IPs only by 1). However I don't recommend to take such a crude model as a "standard way", but one should keep it in mind for future developement. -Tino ----- Original Message ----- From: "leo vegoda" To: Sent: Wednesday, February 07, 2001 4:34 PM Subject: Fixed Boundary (/29) Assignments > Dear all, > > In my presentation to the Working Group at RIPE 38 [0] I brought up the > issue of assignment policies for ISPs wanting to assign all customers a > fixed size network (/29). > > The RIPE NCC is experiencing an increase of requests for this type of setup > and would therefore like the community's input on this matter. > > There is no specific mention of broadband connections or fixed-boundary > assignments in the current policy. However, we believe that the policy now > requires LIRs to make assignments on the usage-based requirements of the > subscriber. This is consistent with the RIRs' goal of conservation. > > The method of assigning a standard prefix size is certainly quite wasteful > as one quarter of the space is lost on network and broadcast addresses. > > The requester justification for this assignment method is an estimation of > the number of customers taking IP based services or having multiple > Internet connected terminals at home. > > As a reference, it may be worth noting that in recent discussions on the > IETF mailing list, Bernard Aboba estimates [1] that currently 27% of homes > have multiple 'PCs'. It is difficult to predict the take-up of non-Internet > IP-based services. > > Based on the above, we would like the Working Group to consider whether: > > - a standard, fixed-boundary assignment is acceptable for residential > broadband connections? > > Or > > - should the requester (the LIR) be required to ask the subscriber how > many IP devices will be connected and base the assignment upon this? > > Regards, > > leo vegoda > RIPE NCC Hostmaster > [0] http://www.ripe.int/ripe/wg/lir/present/ > [1] http://www.ietf.org/mail-archive/ietf/Current/msg10586.html > From djp at djp.net Thu Feb 8 16:44:12 2001 From: djp at djp.net (Dave Pratt) Date: Thu, 8 Feb 2001 16:44:12 +0100 (MET) Subject: Proposals on IPv6 Allocation policy Message-ID: Hiya all, Here are some thoughts on IPv6 allocation policy. Hopefully the resulting discussion will be active and constructive, resulting in appropriate feedback, policy, IETF-drafts, RFCs, etc. If the text below gets corrupted then you should be able to view it at: http://www.djp.net/ipv6/proposal.html This concerns the LIR and IPv6 WG at RIPE and I4ve sent to both lists accordingly. I suggest all replies/discussion be carried out primarily on the IPv6 list. Cheers Dave Viag Interkom GmbH ----------------------------- Proposals on IPv6 Allocation policy Hierarchy versus Address Conservation The RIR allocation policies for IPv6 appear to be based on the assumption that IPv6 addresses are a scarce resource that are about to run out. This assumption is totally untrue. Instead RIR allocation policies need to be focussed 90% on aggregation and hierarchy, and optimising the global routing table. One of the worst mistakes an RIR can make is to allocate too few addresses to an LIR, resulting in later subsequent allocations and pollution of the global routing table. Classbased versus Convenience: What is appropriate for an "alpine village" ISP is not appropriate for a large global ISP. LIR should not therefore all receive the same "standard prefix" but receive sensible allocations based on reasonable long term expectations on use. We should aim so that only 10% or so of LIR need to come back to ask for a second allocation within 5 years. Dividing on strange bit boundaries (eg. /35) in combination with the format of writing IPv6 addresses makes notation and calculation very hard for most people and will result in many mistakes over time. In such a large address space the benefits of always making allocations on a 4 bit boundary are greater than the resulting inflexibility. This is seen in the original TLA /16 and NLA /24 proposals. Allocations should be at /16, /24 or /32 - possibly /20 /28. Sub allocations by LIR to their customer ISPs should similarly be /32 /40, or possibly /36 /44. Present Allocation sizes: Bit usage density should be allocated evenly over the addressing hierarchy. I could use rfc1715's h-ratio here but refuse to use a measurement unit where everything is squashed between 0 and 0.301. At present a "site" has 80 bits (fixed at /48). Of these the average usage is likely to be 10 to 100 nodes (ranging from 10k for a medium corporation to 1-5 for the far more predominant home user). The usage density is therefore approx: 2^80/100 or well over 1 in 10^20 !!! can be certain there will not be more than around 100,000 top level routes. Accordingly the usage density is 2^35/100,000 or approx 1 in 350,000. An LIR with a present /35 and only a single customer (/48) has already reached a density of 1 in 8192 !!! Does anyone know why the service provider is treated differently ? The need for hierarchy within an LIR: In practise an LIR must introduce hierarchy to prevent excessive routes. Global LIRs must do this at multiple levels. Typically a Global LIR might have about 10 regions and about 10 areas per region - although hopefully these would not all be fixed in size. This hierarchy must be set at the outset, although a fraction (say up to 2/3) could be reserved to provide additional resources to areas/regions that grow faster than originally expected. In each of these approx. 100 areas, the larger LIRs (national or global) will have predominantly X customers who are small and/or medium size ISP's. The smallest of these would typically expect to have enough addresses to serve 256 customers - /40. Accordingly a minimum allocation for such an LIR forseeable at the outset is at least a /24. Minimal initial allocation based on registered IPv4 usage We must not allocate too few addresses to an LIR since this will cause problems for us all, and especially him and his customers now and in the future. Since addresses are not in short supply, and one of the worst mistakes an RIR can make is to allocate too few addresses, a minimum first allocation could be based on the customers current REGISTERED IPv4 usage. In fitting with the above sections a possible simple yet flexible approach would be to adopt the following table: Small - /40 Medium - /32 Large/National - /24 International - /16 These categories also fit extremely well with the present RIPE membership categories which could help reduce administrative checking of claims to be Large/National, etc. Until Multihoming issues are sorted (see also below) we must adopt a similar approach to corporate LIRs. With the category used calculated as if they were not a corporate LIR. A side effect of this rule is that it will encourage owners of historical non-registered allocations to register them with one of the RIRs (if they want an appropriate IPv6 allocation). These are minimum initial allocations. Larger initial allocations can be requested if appropriately justified. For example a new 3G UMTS consortium operating in a major european country but which has no LIR background would typically qualify for the same prefix as a large/national LIR Usage requirements for additional allocations: IPv4 addresses are in short supply, appropriately there is therefore a rule stating that 80% of addresses at each level must be "used" before additional addresses are "provided". In IPv6 this rule is not only invalid, it just does not make sense. Even more crazily, RFC2450 states 90% !!! In order to prevent stupid wastage and bad network design, this rule should not be relaxed below about 10% (I am reminded of a network I came across using RFC1916 addresses where a /16 was assigned to each of 100 sites - which varied from 5 to 10,000 nodes). In contrast 80% or 90% is unnecessary and unreachable in IPv6 where addresses are not a scarce resource. Multihoming and allocations to non-service providers: At the time of writing no fully satisfactory multihoming technique is available. We must therefore provide current owners of globably routed IPv4 address space with a TLA with an appropriate mask. Failure to do this will actively discourage organisations considering a move to IPv6. We must be pragmatic, and at the same time encourage IPv6 use. From rbush at bainbridge.verio.net Thu Feb 8 17:01:59 2001 From: rbush at bainbridge.verio.net (Randy Bush) Date: Thu, 08 Feb 2001 08:01:59 -0800 Subject: Fixed Boundary (/29) Assignments References: Message-ID: why is dsl different, from an address allocation view, than e1, flame delay, point2point, etc. it's just the layer 1 point-to-point technology used for provisioning an end site. randy From ash at ash.de Thu Feb 8 17:39:13 2001 From: ash at ash.de (Hauke Johannknecht) Date: Thu, 8 Feb 2001 17:39:13 +0100 (MET) Subject: Fixed Boundary (/29) Assignments In-Reply-To: Message-ID: On Thu, 8 Feb 2001, Thor-Henrik Kvandahl wrote: > One official dynamically assigned /32 (no NAT here) pr. customer should do > it for the majority of the "non business" customers. And if some of them What is the reason for assigning dynamic addresses to permanent links? (except wanting to bill more for a fixed address by calling it "business access") Gruss, Hauke -- Hauke Johannknecht Berlin / Germany HJ422-RIPE Use PGP ! -> lynx -dump http://www.ash.de/ash.asc | pgp -kaf From clive at on-the-train.demon.co.uk Thu Feb 8 17:26:05 2001 From: clive at on-the-train.demon.co.uk (Clive D.W. Feather) Date: Thu, 8 Feb 2001 16:26:05 +0000 Subject: Fixed Boundary (/29) Assignments In-Reply-To: References: <4.2.0.58.20010207224539.00a3bc90@mailhost.cerbernet.co.uk> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- In message , David R Huberman writes >> In my experience, most residential customers are quite happy to use private >> IP addresses > >I must respectively disagree, and disagree vehemently. In my experiences, >residential broadband customers, paying high monthly fees, demand publicly >routable IP address space, citing both the very 'limitations' of private >address space you articulate (e.g. Napster and other IP-dependent >applications) and sales pitches of other providers who are willing to give >them publicly unique address space just to close the deal. [...] >More importantly, the conservationist's desire to promote the use of >private address space should not take precedence over real-world business >concerns. Market demand for residential DSL is high, and in many markets, >IPs have become a selling point. This debate sounds very like the static v dynamic IP debate for dialups. The people saying "NAT is good enough" are like the people saying "dialup customers don't need static IP". Well, such people are wrong. My opinion: it is not RIPE's job to restrict the type of service that an ISP provides in the name of "IP conservation". Conservation is important, but it is done by ensuring good practice, not by imposing arbitrary rules that prevent ISPs from providing innovative services. I'm agnostic on the /29 proposal, though I suspect it will save time and effort all round. But residential ADSL customers should be able to get reasonable amounts of IP space (and /30 is *not* reasonable) without significant pain. - -- Clive D.W. Feather | Internet Expert | Work: Tel: +44 20 8371 1138 | Demon Internet | Home: Fax: +44 20 8371 1037 | Thus plc | Web: Written on my laptop; please observe the Reply-To address -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.7.1 iQEVAwUBOoLInSNAHP3TFZrhAQFPyQgAj/fzhFyDaqkt+uYi94EYWgxk4VoT6YS/ Vl34sS4ikKusirEW/89mOeq4CJJ9RuY0zSEOtIKxbQfxhftqkm6eqJhOQC6aCszp Du8eBtI1Lt8l12MNjzrjf9HQnn/+H9zFjAQ+hjXygVQre6h/jIdRyGB/Fd8h6tJQ sg9O2g+HhInLfN27PkFS/4EHFaCabP85bx5fZYUjW9aBO6wTTFVBCH+BtNjL5ORZ vkTax3xDIroSo/AAxqcf0v9J4JGOz+UQlnGAtQbKuEKQM+h02x1WCCOLZXS3vG95 4wIeKLRoPcKm7IWl7YoqJjSjC+uG8gUnpG4Z4OwWeALnEwWjSTDmJw== =wnPy -----END PGP SIGNATURE----- From neil at COLT.NET Thu Feb 8 18:31:58 2001 From: neil at COLT.NET (Neil J. McRae) Date: Thu, 8 Feb 2001 17:31:58 +0000 (GMT) Subject: Fixed Boundary (/29) Assignments In-Reply-To: from "Clive D.W. Feather" at "Feb 8, 2001 04:26:05 pm" Message-ID: <200102081731.RAA17662@NetBSD.noc.COLT.NET> > This debate sounds very like the static v dynamic IP debate for dialups. > The people saying "NAT is good enough" are like the people saying > "dialup customers don't need static IP". Well, such people are wrong. I don't think anyone is sitting on the extreme side of the fence. To use your example, its fair to say that most dialup customers don't need static IP, and those that do should get what they need. > My opinion: it is not RIPE's job to restrict the type of service that an > ISP provides in the name of "IP conservation". Conservation is > important, but it is done by ensuring good practice, not by imposing > arbitrary rules that prevent ISPs from providing innovative services. Thats what we're discussing. :-) > I'm agnostic on the /29 proposal, though I suspect it will save time and > effort all round. But residential ADSL customers should be able to get > reasonable amounts of IP space (and /30 is *not* reasonable) without > significant pain. As I said anyone who needs more than 1 IP address should really be able to justify it. Regards, Neil. From jhma at KPNQwest.net Thu Feb 8 19:18:50 2001 From: jhma at KPNQwest.net (James Aldridge) Date: Thu, 08 Feb 2001 19:18:50 +0100 Subject: Fixed Boundary (/29) Assignments In-Reply-To: Your message of "Wed, 07 Feb 2001 16:34:50 +0100." <20010207163450.T11994@ripe.net> Message-ID: <200102081818.TAA15650@aegir.EU.net> leo vegoda wrote: > Based on the above, we would like the Working Group to consider whether: > > - a standard, fixed-boundary assignment is acceptable for residential > broadband connections? IMHO, no. Why should the amount of address space assigned have anything to do with the way that a network is connected to the outside world? > Or > > - should the requester (the LIR) be required to ask the subscriber how > many IP devices will be connected and base the assignment upon this? Yes, but maybe a simplfied version of ripe-141 might be adopted for these cases. Perhaps, where the amount address space being requested is small, the addressing plan and much of the request overview could be omitted. For example, reduce "addresses-immediate", "addresses-year-1", "addresses-year-2" to a single "addresses-immediate" (or "addresses-year-2"?) question; "subnets-immediate", "subnets-year-1", "subnets-year-2" could all be assumed to be 1 (subnetting a /29 doesn't make sense as you lose too much address space to net and broadcast addresses); PI-requested is inappropriate if such a small amount of address space is expected to be routed throughout the Internet. That would leave the service provider with a simple form something like: ---------- #[OVERVIEW OF ORGANIZATION TEMPLATE]# Private individual's home network #[REQUESTER TEMPLATE]# name: organisation: country: phone: fax-no: (optional) e-mail: #[USER TEMPLATE]# name: country: phone: fax-no: (optional) e-mail: #[REQUEST OVERVIEW TEMPLATE]# request-size: addresses-immediate: inet-connect: country-net: ---------- This assumes that no address space is being returned, etc. which would complicate matters and make it simpler to revert to using the normal ripe-141 form. James From hph at online.no Thu Feb 8 23:14:53 2001 From: hph at online.no (Hans Petter Holen) Date: Thu, 8 Feb 2001 23:14:53 +0100 Subject: Fixed Boundary (/29) Assignments References: Message-ID: <012c01c0921c$91bf5930$0400000a@hph> > why is dsl different, from an address allocation view, than e1, flame delay, > point2point, etc. it's just the layer 1 point-to-point technology used for > provisioning an end site. In my oppinion it is not at should not be different. But what is different is that we are rolling out mass marked "always on" products in a larger scale than we have seen before. What I don't think the poicies should do is to prevent products like home lans. I dont think policies should force providers or the customers to use NAT. So going back to the original question, is it OK to assign a /29 to a home network (beeing connected with wathever technology) ? I belive the answer is yes. I also belive that it is probably not reasonalble to expect an average customer to fill in the RIPE form. I also have a tendency to think that it is probably not usefull to demand the form to be filled out for a /29... So my opinion would be that: - the policy should not encourage an ISP to make /29 the default product - the policy should not prevent an ISP from making a product option to have more than one IP address in a home network. (enabeled by clicking on a web page or some such.) - I think it would be a huge vaste of resources if RIPE NCC hostmasters were to spend their time reviewing RIPE forms for /29 for dsl, 3G or whatever connected home? networks... On the even more general side, I think more and more that we should be realy carefull to create to strong restrictions on the use of address space available to new and smaller players today, while there are no such policies in place for legacy address space. -hph From Robert.Kiessling at de.easynet.net Thu Feb 8 19:38:08 2001 From: Robert.Kiessling at de.easynet.net (Robert Kiessling) Date: Thu, 8 Feb 2001 19:38:08 +0100 (MET) Subject: Fixed Boundary (/29) Assignments In-Reply-To: <200102081818.TAA15650@aegir.EU.net> References: <20010207163450.T11994@ripe.net> <200102081818.TAA15650@aegir.EU.net> Message-ID: <14978.59280.775504.214018@doncamillo.local.easynet.de> James Aldridge writes: > Yes, but maybe a simplfied version of ripe-141 might be adopted for these > cases. Why? We can assume that the provider's AW is larger than 8. So to fulfil RIPE requirements, it suffices to have have a form with user's address, number of computers permanently online and a statement that NAT is not sufficient, or some conditions a bit weaker. created. Robert From thk at nextra.com Thu Feb 8 22:05:03 2001 From: thk at nextra.com (Thor-Henrik Kvandahl) Date: Thu, 8 Feb 2001 22:05:03 +0100 (MET) Subject: Fixed Boundary (/29) Assignments In-Reply-To: Message-ID: On Thu, 8 Feb 2001, Hauke Johannknecht wrote: > On Thu, 8 Feb 2001, Thor-Henrik Kvandahl wrote: > > > One official dynamically assigned /32 (no NAT here) pr. customer should do > > it for the majority of the "non business" customers. And if some of them > > What is the reason for assigning dynamic addresses to permanent links? > (except wanting to bill more for a fixed address by calling it > "business access") You don't need to manage it, you just count ports. And you can reorganize the IPs easily. -- Regards Thor-Henrik Kvandahl Nextra AS > > Gruss, > Hauke > > -- > Hauke Johannknecht Berlin / Germany HJ422-RIPE > Use PGP ! -> lynx -dump http://www.ash.de/ash.asc | pgp -kaf > From BCA at fakse.dk Fri Feb 9 10:25:06 2001 From: BCA at fakse.dk (Bjarne Carlsen) Date: Fri, 9 Feb 2001 10:25:06 +0100 Subject: Fixed Boundary (/29) Assignments Message-ID: > -----Oprindelig meddelelse----- > Fra: Hans Petter Holen [SMTP:hph at online.no] > Sendt: 8. februar 2001 23:15 > Til: lir-wg at ripe.net > Emne: Re: Fixed Boundary (/29) Assignments > > > > > why is dsl different, from an address allocation view, than e1, flame > delay, > > point2point, etc. it's just the layer 1 point-to-point technology used > for > > provisioning an end site. > > In my oppinion it is not at should not be different. But what is different > is that we > are rolling out mass marked "always on" products in a larger scale than we > have > seen before. [Bjarne Carlsen] But what is different about it? It is - as Randy said - just the layer 1 point-to-point technology used for provisioning an end site (blatant cut'n paste here). The only real difference from "the good old days" that I can see, is that we are dealing with customers as single persons/families with lesser need for address space instead of companies with comparatively greater needs. > What I don't think the poicies should do is to prevent products like home > lans. > I dont think policies should force providers or the customers to use NAT. [Bjarne Carlsen] I agree, but I still think that the customers should be required by policy to somehow justify their needs for addresses. > So going back to the original question, is it OK to assign a /29 to a home > network > (beeing connected with wathever technology) ? [Bjarne Carlsen] That was not the original question. The question was whether a standard /29 assignment to all DSL/cable/insert-your-own-new-technology users would be feasible. > > I belive the answer is yes. [Bjarne Carlsen] I heartily disagree: With a standard assignment, there is absolutely no justification for the used space. The proposed policy does not even assume that all addresses will actually be used - not even that they will be used eventually. > I also belive that it is probably not > reasonalble to > expect an average customer to fill in the RIPE form. I also have a > tendency > to think > that it is probably not usefull to demand the form to be filled out for a > /29... [Bjarne Carlsen] Right, but the administration will have to be done at some point - whether it is done via a RIPE-141 or it is done some other way. The administrator should be the LIR in my opinion. > So my opinion would be that: > - the policy should not encourage an ISP to make /29 the default product > - the policy should not prevent an ISP from making a product option to > have > more than one IP address in a home network. (enabeled by clicking on a web > page > or some such.) [Bjarne Carlsen] And in my opinion the policy should not even _allow_ a /29 as default product - no tickee, no launly; no justification, no addresses. > - I think it would be a huge vaste of resources if RIPE NCC hostmasters > were > to spend their time reviewing RIPE forms for /29 for dsl, 3G or whatever > connected home? networks... [Bjarne Carlsen] Yes, but the administration will still have to be done somewhere in the system... > On the even more general side, I think more and more that we should be > realy > carefull to > create to strong restrictions on the use of address space available to new > and smaller players > today, while there are no such policies in place for legacy address space. > [Bjarne Carlsen] Couldn't have said that better myself. > -hph > /Bjarne From lporter at cw.net Fri Feb 9 11:14:31 2001 From: lporter at cw.net (Leigh Porter) Date: Fri, 09 Feb 2001 10:14:31 +0000 Subject: Fixed Boundary (/29) Assignments References: <200102081818.TAA15650@aegir.EU.net> Message-ID: <3A83C307.70FC0052@cw.net> James Aldridge wrote: > > leo vegoda wrote: > > Based on the above, we would like the Working Group to consider whether: > > > > - a standard, fixed-boundary assignment is acceptable for residential > > broadband connections? > > IMHO, no. Why should the amount of address space assigned have anything to do > with the way that a network is connected to the outside world? I think the important bit is the word "residential" and not the connection method. -- Leigh Porter Cable and Wireless From joshua at roughtrade.net Fri Feb 9 10:46:04 2001 From: joshua at roughtrade.net (Joshua Goodall) Date: Fri, 9 Feb 2001 10:46:04 +0100 (CET) Subject: Fixed Boundary (/29) Assignments In-Reply-To: <200102081731.RAA17662@NetBSD.noc.COLT.NET> Message-ID: On Thu, 8 Feb 2001, Neil J. McRae wrote: > I don't think anyone is sitting on the extreme side of the fence. To use > your example, its fair to say that most dialup customers don't need > static IP, and those that do should get what they need. I'm very inclined to agree. Unfortunately, telco marketing departments have subzero IP clue. So, what are the implications if telco xDSL LIR's start handing out /29's as standard netnames? 1. Millions of /29 objects in the RIPE database. 2. Millions of /29 RIPE-141 requests (noting that the startup LIR's will have AW=0). 3. RIPE is effectively powerless to force deallocation. Literally, the order of magnitude is 10^6. No. 3 is based on experience - RIPE NCC being community based, it is hard to take space away from users. I'm not referring to unused LIR /16's here. Another gotcha for the policy-enforcers: RIPE NCC does not set operational policy. I don't speak on RIPE's behalf but I do know several staff personally and although this is never explicit, the conservation of IP space is not achieved through stating "You may only have this many for this function". Any address *usage* is acceptable, as long as there is one. This is a subtle gotcha. I have known the NCC make recommendations, and I'm sure this discussion will lead to one. I would suggest that, as well as approaching the LIR wg, the NCC approaches the xDSL providers en masse directly to achieve a consensus. I doubt that every telco beginner LIR is reading this. Can I also point to RFC3021, using 31-bit prefixes for point-to-point links? This is relevant. Joshua From woeber at cc.univie.ac.at Fri Feb 9 10:48:01 2001 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 09 Feb 2001 10:48:01 +0100 Subject: Fixed Boundary (/29) Assignments Message-ID: <009F760E.3C8E616E.20@cc.univie.ac.at> => IMHO, no. Why should the amount of address space assigned have anything to do => with the way that a network is connected to the outside world? = =I think the important bit is the word "residential" and not the =connection method. For the moment I cannot see clear-cut criteria to label one network as residential and another one as [implied from context] business, and to do so consistently over teh life-time of the connection/network. Which IMO makes that aspect useless to base address distribution policies on. Wilfried. From beri at kpnqwest.net Fri Feb 9 11:40:23 2001 From: beri at kpnqwest.net (Berislav Todorovic) Date: Fri, 9 Feb 2001 11:40:23 +0100 (CET) Subject: Fixed Boundary (/29) Assignments In-Reply-To: <20010207163450.T11994@ripe.net> Message-ID: On Wed, 7 Feb 2001, leo vegoda wrote: >> - a standard, fixed-boundary assignment is acceptable for residential >> broadband connections? Like Wilfried and few other people already pointed out: it's pointless to try distinguishing between residential and business customers, like phone companies do it. They have a strong reason to do it, since they want to impose separate call charges for those two categories of customers. I think it's better to discuss whether we still want to register /29's in the RIPE Database - or to treat them like we treat /30's now (that is - not register each /29 in the database). Regards, Beri --------- Berislav Todorovic, Network Engineer --------- ------- KPNQwest N.V. - IP NOC (formerly EUnet NOC) ------- ---- Wilhelmina van Pruisenweg 78, 2595 AN Den Haag, NL ---- --- Phone: +31-70-379-3990; Mobile: +31-651-333-641 --- -- Email: beri at kpnqwest.net <=> beri at EU.net -- --- _ _ ____ _ .--. ____ ____ __/_ --- ----- /__/ /___/ /\ / / / | / /___/ /___ / ------ ------ _/ \_ / _/ \/ (__.\ |/\/ /___ ____/ (__. ----- From stephenb at uk.uu.net Fri Feb 9 12:43:20 2001 From: stephenb at uk.uu.net (Stephen Burley) Date: Fri, 09 Feb 2001 11:43:20 +0000 Subject: Fixed Boundary (/29) Assignments References: <009F760E.3C8E616E.20@cc.univie.ac.at> Message-ID: <3A83D7D8.84A5D2F5@uk.uu.net> "Wilfried Woeber, UniVie/ACOnet" wrote: > > => IMHO, no. Why should the amount of address space assigned have anything to do > => with the way that a network is connected to the outside world? > = > =I think the important bit is the word "residential" and not the > =connection method. > > For the moment I cannot see clear-cut criteria to label one network as > residential and another one as [implied from context] business, and to > do so consistently over teh life-time of the connection/network. > > Which IMO makes that aspect useless to base address distribution > policies on. > What he said. I agree. > Wilfried. -- ------------------------------------------------------------------------ Stephen Burley "If patience is a virtue, and ignorance is bliss, UUNET EMEA Hostmaster you can have a pretty good life [SB855-RIPE] if you're stupid and willing to wait" ------------------------------------------------------------------------ From joshua at roughtrade.net Fri Feb 9 13:23:14 2001 From: joshua at roughtrade.net (Joshua Goodall) Date: Fri, 9 Feb 2001 13:23:14 +0100 (CET) Subject: Fixed Boundary (/29) Assignments In-Reply-To: <01020911360001.27525@ewe.noc.u-net.net> Message-ID: On Fri, 9 Feb 2001, Adrian Bool wrote: > I see little point in giving a user one usable IP address by assigning > eitehr a /31 or /30 to the point to point link. All you achive with that is > wasting *2 or *4 the number of IP addresses used. Sure, this is true. But you've missed my point. Unless RIPE chooses to decide the network architecture for ISPs - which it has never done before, and is surely unenforceable - these remain recommendations at best. > If the /24 is a 'stanard' range agree amonst us that would probably > make things easier. Do windows boxes have a default private IP > it assigns to ethernert interfaces? If so, using that seems like a > good option. yes, they do - they follow the DHCP expectations and use 169.254.0.0/16 (see http://www.ietf.org/internet-drafts/draft-manning-dsua-06.txt) but that is a block that should never be routed. joshua From netmaster at space.net Fri Feb 9 12:03:05 2001 From: netmaster at space.net (Gert Doering, Netmaster) Date: Fri, 9 Feb 2001 12:03:05 +0100 Subject: Fixed Boundary (/29) Assignments In-Reply-To: <20010208091141.7EFF39CCD4@proxy.bitmailer.com>; from javier@bitmailer.com on Thu, Feb 08, 2001 at 10:11:14AM +0000 References: <20010208091141.7EFF39CCD4@proxy.bitmailer.com> Message-ID: <20010209120305.W1037@Space.Net> Hi, On Thu, Feb 08, 2001 at 10:11:14AM +0000, Javier Llopis wrote: > I wish IPv6 technology would be common enough between LIRS so we could give every > residential customer 32 IPv6 addresses or 1 IPv4 address at their choice, so that > woud skyrocket the demand of low-end IPv6 hardware and solve the address problem > forever. Just as a side note: with IPv6, according to current proposals, every customer gets a /48 - that's not 32 IPv6 addresses, but 2^80. Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From aid at vianetworks.net Fri Feb 9 12:36:00 2001 From: aid at vianetworks.net (Adrian Bool) Date: Fri, 9 Feb 2001 11:36:00 +0000 Subject: Fixed Boundary (/29) Assignments In-Reply-To: References: Message-ID: <01020911360001.27525@ewe.noc.u-net.net> On Friday 09 February 2001 09:46, Joshua Goodall wrote:> > Can I also point to RFC3021, using 31-bit prefixes for point-to-point > links? This is relevant. I see little point in giving a user one usable IP address by assigning eitehr a /31 or /30 to the point to point link. All you achive with that is wasting *2 or *4 the number of IP addresses used. All we need to do it route a /32 down the link - as we alredy do for all out dialu customers - be then dynamic or statically assigned. I think one nice solution would be to allocate all users one /32 that is routed down the connection, and also one /24 of private IP address space - NATed by the ISP. This way - a user may use mutiple machines without any effort (by using the /24) yet can have an unrestricted access to the internet by using the /32. If the /24 is a 'stanard' range agree amonst us that would probably make things easier. Do windows boxes have a default private IP it assigns to ethernert interfaces? If so, using that seems like a good option. regards, aid -- Adrian Bool | http://noc.vianetworks.net/ Director, Global Network | tel://+44.1925.484061/ VIA NET.WORKS Inc. | fax://+44.1925.484466/ From matthew at crescent.org.uk Fri Feb 9 14:07:42 2001 From: matthew at crescent.org.uk (Matthew Robinson) Date: Fri, 9 Feb 2001 13:07:42 -0000 Subject: Fixed Boundary (/29) Assignments In-Reply-To: <01020911360001.27525@ewe.noc.u-net.net> Message-ID: My 2 pence. Overloaded NAT space for users is fine if that's what they've been sold. If the user is expecting to see real address space and a network that can be reached from everywhere then overloaded NAT is not going to go down well. Most users though, as someone mentioned earlier, are simply after fast surfing so reachability is not a problem. Certainly I would be more than happy with rfc1918 space and a fast connection. With the correct hardware doing to overloaded NAT users should find few programs that won't work properly. This approach would probably split the user base into home and business where business require reachability and home users do not. Hence we can conserve space by developing two service offerings so that only users that need addresses get them - as it should be! All the best Matthew > -----Original Message----- > From: owner-lir-wg at ripe.net [mailto:owner-lir-wg at ripe.net]On Behalf Of > Adrian Bool > Sent: 09 February 2001 11:36 > To: Joshua Goodall > Cc: lir-wg at ripe.net > Subject: Re: Fixed Boundary (/29) Assignments > > > On Friday 09 February 2001 09:46, Joshua Goodall wrote:> > > Can I also point to RFC3021, using 31-bit prefixes for point-to-point > > links? This is relevant. > > I see little point in giving a user one usable IP address by assigning > eitehr a /31 or /30 to the point to point link. All you achive > with that is > wasting *2 or *4 the number of IP addresses used. > > All we need to do it route a /32 down the link - as we alredy do for > all out dialu customers - be then dynamic or statically assigned. > > I think one nice solution would be to allocate all users one /32 that > is routed down the connection, and also one /24 of private IP address > space - NATed by the ISP. From leo at ripe.net Fri Feb 9 14:47:25 2001 From: leo at ripe.net (leo vegoda) Date: Fri, 9 Feb 2001 14:47:25 +0100 Subject: Fixed Boundary (/29) Assignments In-Reply-To: ; from huberman@gblx.net on Wed, Feb 07, 2001 at 05:34:00PM -0700 References: <4.2.0.58.20010207224539.00a3bc90@mailhost.cerbernet.co.uk> Message-ID: <20010209144724.E1260@ripe.net> Hiya, On Wed, Feb 07, 2001 at 05:34:00PM -0700, in message , David R Huberman (huberman at gblx.net) wrote: Re: Re: Fixed Boundary (/29) Assignments [...] > We are not discussing commercial broadband customers. The fixed-boundary > assignment 'proposal' is exclusively for residential broadband customers. I get the impression that people have confused the requests we have received with a desire on our part to change the policy. The slide in question is . Can I quickly point out that RIPE NCC is not proposing a change to the policy - merely asking the Working Group to discuss the policy and decide what it ought to be. Many thanks, -- leo vegoda RIPE NCC Bloke From woeber at cc.univie.ac.at Fri Feb 9 15:10:06 2001 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 09 Feb 2001 15:10:06 +0100 Subject: Fixed Boundary (/29) Assignments Message-ID: <009F7632.D962A7CE.2@cc.univie.ac.at> =From: "Hans Petter Holen" =To: =Subject: Re: Fixed Boundary (/29) Assignments =Date: Thu, 8 Feb 2001 23:14:53 +0100 = => why is dsl different, from an address allocation view, than e1, flame delay, => point2point, etc. it's just the layer 1 point-to-point technology used for => provisioning an end site. = =In my oppinion it is not at should not be different. But what is different =is that we are rolling out mass marked "always on" products in a larger =scale than we have seen before. Correct. And we are going to see other technologies than xDSL posing the same challenge (WLL, mobile, someone might find metered usage of ISDN dropping, so offer a 24x7 package). From my pint of view, the only thing that is "new" - if at all - is the fact that bigger players are going after the commodity Internet market. And this definitely is not a criticism! =What I don't think the poicies should do is to prevent products like home =lans. I dont think policies should force providers or the customers to =use NAT. Again, I fully agree. Address distribution policy is not the appropriate mechanism to develop operational or technical recommendations. The RIRs would be very ill-advised to get dragged into that tar pit. =So going back to the original question, is it OK to assign a /29 to a home =network (beeing connected with wathever technology) ? =I belive the answer is yes. I also belive that it is probably not =reasonalble to expect an average customer to fill in the RIPE form. I also =have a tendency to think that it is probably not usefull to demand the =form to be filled out for a /29... Again, I fully agree. However this is _not_ to be read as an endorsement for giving away an address block of whatever size as a _default_ approach. Also, I agree that a sizeable fraction of the customer base can be reasonably served by a mix of technical solutions as outlined by other contributions. However, we should accept the reality that another sizeable fraction of the customers looking at those new services do indeed require "the real thing". Pointing to NAT, masquerading, you name it is not going to work. (see 1) In particular, any art of dynamic address or port management is probably going to impede the deployment of IPv6 for the mass-market, simply accelerating the consumption of IPv4 address space instead of contributing to breaking the exponential trend. =So my opinion would be that: =- the policy should not encourage an ISP to make /29 the default product I agree. But again, this is outside the access policy and documentation policy to obtain IPv4 addresses. =- the policy should not prevent an ISP from making a product option to have =more than one IP address in a home network. (enabeled by clicking on a web =page or some such.) Whatever the accepted means of documenting the "request for real addresses by the customer" is, is what should be considered here. And how the mechanisms would look like for certain bands of address consumption. In the end, "wasting" a few addresses from a /29 (or /30) address block is not too different from allowing network growth claims over 12..24 month of the order of slightly less than 50% in the "regular" 141 process for, say a /25. =- I think it would be a huge vaste of resources if RIPE NCC hostmasters =were to spend their time reviewing RIPE forms for /29 for dsl, 3G or =whatever connected home? networks... What we have (painfully) seen over the last 6(..8) month is that micro-management on the LIR's end is not going to work. And that fact hits *everyone*. In order to make the whole process survive, we have to face reality! And, unless *all of us* are prepared to spend a *lot* of money and a *lot* of time to do that, we should focus on a reasonable solution for the mass-deployment scenario. Whatever that solution in reality is, I really don't care too much. We can either go the path of setting a cut-off block size where we no longer require public registration and the keeping of individual records (e.g. a 141 or equivalent for every customer), or we can go towards "charging" those addresses to the ISPs own address space assignment. That approach would require us to revisit the interaction between incremental self-assignment and the AW (which we should do anyway - but that is a completely different thread ;-). I guess there are other approaches as well. =On the even more general side, I think more and more that we should be =realy carefull to create to strong restrictions on the use of address =space available to new and smaller players today, while there are no such =policies in place for legacy address space. While this certainly is true, I am more worried about the "message" we might be sending to the community: "the end-to-end approach in the Internet is no longer supported" Go for a shrink-wrapped package of 1 address (wait a minute: why do you even need that one? We are offereing you an application gateway anyway? You are using a web-browser most of the time anyway, and we do have a cache, so what?). And the Internet (plus competiton and technical development) would simply look very different in a short while... =-hph 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 randy at psg.com Fri Feb 9 15:15:30 2001 From: randy at psg.com (Randy Bush) Date: Fri, 09 Feb 2001 06:15:30 -0800 Subject: Fixed Boundary (/29) Assignments References: Message-ID: > [Bjarne Carlsen] But what is different about it? It is - as Randy said - > just the layer 1 point-to-point technology used for provisioning an end > site (blatant cut'n paste here). The only real difference from "the good > old days" that I can see, is that we are dealing with customers as single > persons/families with lesser need for address space instead of companies > with comparatively greater needs. are we? we see folk using dsl at t1 rates to replace p2p t1 lines because it's a very different cost for the circuit. (here, t1 is expensive and dsl is based on old alarm circuit tarrifs) >> I dont think policies should force providers or the customers to use NAT. > [Bjarne Carlsen] I agree, but I still think that the customers should be > required by policy to somehow justify their needs for addresses. yup, exactly like any other dedicated line customer does/should. just to push this to the limit. in the states, we usually have free local dialup. so we have analog "nail up" customers, i.e. they stay dialed up 7x24. it's just another form of p2p dedicated circuit. and, as far as address allocation policy goes, treat them the same as an OC12 customer, they justify what address space they need. randy From woeber at cc.univie.ac.at Fri Feb 9 15:22:11 2001 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 09 Feb 2001 15:22:11 +0100 Subject: Fixed Boundary (/29) Assignments [ 1) missing] Message-ID: <009F7634.8989E95E.22@cc.univie.ac.at> I forgot to attach my footnote here... > However, we should accept the reality that another sizeable fraction of > the customers looking at those new services do indeed require "the real > thing". Pointing to NAT, masquerading, you name it is not going to work. > (see 1) Looking at _my_ "residential" requirements, I am hard pressed to work without a range of fixed addresses for waht I want to use without spending all my time to reconfigure boxes: - 1 ANT - 1 router (Ethernet and tunnels (v4,v6)) - 2 "full size PCs" - 2 Laptops (my wife's and mine) - a WS with a "traditional" operating system multiple boots and peripherals on the PCs and a mixture of Linux, W95, W/NT, (Solaris8/Intel, freeBSD to come) And no, this is not a university link, this is my link to a regular commercial service. But I want to talk my university, of course... Wilfried. From randy at psg.com Fri Feb 9 15:56:49 2001 From: randy at psg.com (Randy Bush) Date: Fri, 09 Feb 2001 06:56:49 -0800 Subject: Fixed Boundary (/29) Assignments References: <20010208091141.7EFF39CCD4@proxy.bitmailer.com> <20010209120305.W1037@Space.Net> Message-ID: > Just as a side note: with IPv6, according to current proposals, every > customer gets a /48 - that's not 32 IPv6 addresses, but 2^80. uh, 2^32, as the lower 48 are the mac address (or ersatz-mac for privacy reasons). randy From ash at ash.de Fri Feb 9 16:32:39 2001 From: ash at ash.de (Hauke Johannknecht) Date: Fri, 9 Feb 2001 16:32:39 +0100 (MET) Subject: Fixed Boundary (/29) Assignments In-Reply-To: Message-ID: On Fri, 9 Feb 2001, Randy Bush wrote: > > Just as a side note: with IPv6, according to current proposals, every > > customer gets a /48 - that's not 32 IPv6 addresses, but 2^80. > uh, 2^32, as the lower 48 are the mac address (or ersatz-mac for privacy > reasons). well, it would be 2^16 since the 48bit mac (or replacement) are just a part of the 64bit "local" part in EUI64. but these 2^16 are the v6-networks (each containing 2^64 IPs), not the v6-IPs Gert was talking about. :) Gruss, Hauke -- Hauke Johannknecht Berlin / Germany HJ422-RIPE Use PGP ! -> lynx -dump http://www.ash.de/ash.asc | pgp -kaf From nospam at nospam.geht.net Fri Feb 9 17:02:58 2001 From: nospam at nospam.geht.net (Valentin Hilbig) Date: Fri, 9 Feb 2001 17:02:58 +0100 Subject: Fixed Boundary (/29) Assignments References: <4.2.0.58.20010207224539.00a3bc90@mailhost.cerbernet.co.uk> <20010209144724.E1260@ripe.net> Message-ID: <019201c092b1$f01be300$8301010a@intra.skytecag.de> The answer to this slides is quick and easy: The justification for the demand is wrong, so the demand has to be denied. Those type of access noted in the slides should be (from the implementations point of view) possible with private/NAT IP space, too. Thus you cannot justify a possible future IP demand with a false implementation of services. There might be other justifications, but widely deployed Internet TV and VoIP which is designed to need non-private IP space at the customers side is the proof for that something is wrong with the implementation of Internet TV and VoIP. This is simply a mathematical fact as there are less IPs (4 Billion) than possible customers (5 Billion, and for VoIP plus Internet-TV you then need 10 Billion IPs). Here the full story: a) Internet TV. I can get video streams with my NATted IPs without *any* problem. The only thing to give Internet TV watchers a non-private IP is for marketing, to identify the consumer. Thus alone from the privacy side of view this demand has to be declined. As the customers don't have the knowledge themself somebody should take care of it. And I have no problems with this if RIPE protects the innocent ;) b) VoIP. VoIP needs an assigned IP if you want to be called. This can be regarded as a bug in the standard. It definitively should be possible to do VoIP over NATted lines *with* the possibility to receive a call, too! Thus, from an administrative point of view of people who are responsible for the security of corporate networks, there should be a way to hide the complete corporate behind a VoIP gateway and make it possible to route this service directly into the telephony gateway. To be usable the service must be able to distinct between different endpoints without need to consult a directory. A second thing is that VoIP has a privacy problem, because you can decode the VoIP packets without problems if you have access to the right internet node (router). Thus there is really nothing wrong with such VoIP gateways who concentrate such connections, there is something seriously wrong with VoIP and nobody should point to things like IPsec, because it takes decades until it is deployed in a usable fashion. Same holds for Service Providers or ISPs. They should provide the VoIP gateway option to their customers, such that the customer does not need non-private IPs for VoIP. Thus I vote again for denying such a possible future demand. We should not do "proposed allocations on existing bugs". And this way you will see the correct implementations to do Internet TV and VoIP will spring in existence very quickly by demand, such that NAT users can start to use them, too. Besides: Yes, this renders the Microsoft implementation "Net2Phone" as unusable as it should be. It's rediculous not even to consider Proxies or NAT-Gateways. And no, you simply cannot do as described in the Net2Phone doc as there just do not exist 100K ports in IP to hide a bigger corporate network behind 1 IP. And if you have to use more than 1 IP there is something wrong with the service, as all newer services *have* to be designed with IPv4 conservation in mind. ----- Original Message ----- From: "leo vegoda" To: Sent: Friday, February 09, 2001 2:47 PM Subject: Re: Fixed Boundary (/29) Assignments > Hiya, > > On Wed, Feb 07, 2001 at 05:34:00PM -0700, in message , David R Huberman (huberman at gblx.net) wrote: Re: Re: Fixed Boundary (/29) Assignments > > [...] > > > We are not discussing commercial broadband customers. The fixed-boundary > > assignment 'proposal' is exclusively for residential broadband customers. > > I get the impression that people have confused the requests we have > received with a desire on our part to change the policy. The slide in > question is . > > Can I quickly point out that RIPE NCC is not proposing a change to the > policy - merely asking the Working Group to discuss the policy and decide > what it ought to be. > > Many thanks, > > -- > leo vegoda > RIPE NCC Bloke > From randy at psg.com Fri Feb 9 17:17:23 2001 From: randy at psg.com (Randy Bush) Date: Fri, 09 Feb 2001 08:17:23 -0800 Subject: Fixed Boundary (/29) Assignments References: <4.2.0.58.20010207224539.00a3bc90@mailhost.cerbernet.co.uk> <20010209144724.E1260@ripe.net> <019201c092b1$f01be300$8301010a@intra.skytecag.de> Message-ID: > Those type of access noted in the slides should be (from the > implementations point of view) possible with private/NAT IP space, > too. because something is possible does not mean it should be done. randy From hph at online.no Mon Feb 12 00:32:35 2001 From: hph at online.no (Hans Petter Holen) Date: Mon, 12 Feb 2001 00:32:35 +0100 Subject: Fixed Boundary (/29) Assignments References: Message-ID: <004a01c09482$ea10c200$0300000a@hph> >[Bjarne Carlsen] ... The only real >difference from "the good old days" that I can see, is that we are dealing >with customers as single persons/families with lesser need for address space >instead of companies with comparatively greater needs. My point was that we are dealing with lots of customers and a small amount of address space. You would not want to implement product where your mass market customers have to justify their address ned by filling in a RIPE form. > What I don't think the poicies should do is to prevent products like home > lans. > I dont think policies should force providers or the customers to use NAT. [Bjarne Carlsen] I agree, but I still think that the customers should be required by policy to somehow justify their needs for addresses. How to you propose to do that ? By pushing a button on your web site saying "yes I have more that one PC" or by sending you pictures of all their computers ? I know that it may be sightly controversal, but for this small amount of address space I belive that the ony justification needed from the customer is an active choice of one product over another. > So going back to the original question, is it OK to assign a /29 to a home > network > (beeing connected with wathever technology) ? [Bjarne Carlsen] That was not the original question. The question was whether a standard /29 assignment to all DSL/cable/insert-your-own-new-technology users would be feasible. Well, you may be right, but you cant adapt my conclusion to a slightly different question. > I belive the answer is yes. [Bjarne Carlsen] I heartily disagree: With a standard assignment, there is absolutely no justification for the used space. The proposed policy does not even assume that all addresses will actually be used - not even that they will be used eventually. I agree, but I was trying to reason around that, sorry for not beeing clear. (My wording should have been: So going back to what should have been the original question) -hph From hph at online.no Mon Feb 12 00:43:29 2001 From: hph at online.no (Hans Petter Holen) Date: Mon, 12 Feb 2001 00:43:29 +0100 Subject: Fixed Boundary (/29) Assignments References: Message-ID: <006a01c09484$7002cec0$0300000a@hph> > treat them the same as an OC12 customer, > they justify what address space they need. t To be concrete, what kind of justification do you require from a customer requireing a /29 ? Forms to be filled in ? Bills of equipment ? -hph From randy at psg.com Mon Feb 12 00:50:01 2001 From: randy at psg.com (Randy Bush) Date: Sun, 11 Feb 2001 15:50:01 -0800 Subject: Fixed Boundary (/29) Assignments References: <006a01c09484$7002cec0$0300000a@hph> Message-ID: > To be concrete, what kind of justification do you require from a customer > requireing a /29 ? > Forms to be filled in ? > Bills of equipment ? a form modeled after the old ripe form randy From joshua at roughtrade.net Mon Feb 12 02:37:32 2001 From: joshua at roughtrade.net (Joshua Goodall) Date: Mon, 12 Feb 2001 02:37:32 +0100 (CET) Subject: Fixed Boundary (/29) Assignments In-Reply-To: Message-ID: On Sun, 11 Feb 2001, Randy Bush wrote: > > To be concrete, what kind of justification do you require from a customer > > requireing a /29 ? > > Forms to be filled in ? > > Bills of equipment ? > > a form modeled after the old ripe form ... or possibly "a document similar in spirit to the old ripe form". i.e. "justify thyself here". No other similarities need be implied. Imagine the joy of the support desk fielding "hey... what is a relative subnet offset?" a few thousand times. Note also that it is not sane to have a single English-language form for European/Middle Eastern/North African residential users. One ends up with a few simple, localised questions: * Name * Address * Customer ID * Do you have address space from any other ISP? * Number of interfaces to connect within 6 months. What else would you want for residential customers? Decide quick, WG... otherwise (based on experience) the telcos will just go and do their own random thing. my 4c (consultancy rate) joshua From Tarmo.Ainsaar at eenet.ee Fri Feb 9 18:18:19 2001 From: Tarmo.Ainsaar at eenet.ee (Tarmo Ainsaar) Date: Fri, 9 Feb 2001 19:18:19 +0200 (EET) Subject: Fixed Boundary (/29) Assignments In-Reply-To: Message-ID: On Fri, 9 Feb 2001, Randy Bush wrote: > > Those type of access noted in the slides should be (from the > > implementations point of view) possible with private/NAT IP space, > > too. > > because something is possible does not mean it should be done. And contrary - because something is convenient or attractive does not mean it is the right way to do. The philosophy will not help too much here. I can suggest to pollute the earth more aggressively, just to speed up the space colonisation; nobody would take me seriously before the technics for latter are severely improved. (Read: I can suggest to waste the IPv4 more aggressively, just to speed up the IPv6 implementation; nobody would take me seriously before the application side for latter is severely improved.) Supporting conservationist's point of view.. -- Tarmo Ainsaar EENet From netmaster at space.net Sat Feb 10 21:00:21 2001 From: netmaster at space.net (Gert Doering, Netmaster) Date: Sat, 10 Feb 2001 21:00:21 +0100 Subject: Fixed Boundary (/29) Assignments In-Reply-To: <019201c092b1$f01be300$8301010a@intra.skytecag.de>; from nospam@nospam.geht.net on Fri, Feb 09, 2001 at 05:02:58PM +0100 References: <4.2.0.58.20010207224539.00a3bc90@mailhost.cerbernet.co.uk> <20010209144724.E1260@ripe.net> <019201c092b1$f01be300$8301010a@intra.skytecag.de> Message-ID: <20010210210021.X1037@Space.Net> Hi, On Fri, Feb 09, 2001 at 05:02:58PM +0100, Valentin Hilbig wrote: > Those type of access noted in the slides should be (from the implementations > point of view) possible with private/NAT IP space, too. Thus you cannot > justify a possible future IP demand with a false implementation of services. Just to make sure this is clear: current policy does NOT force NAT and private space on anyone. It is made sure that requestors have thought about private address space and then decided to apply for public IP space, but no pressure is applied(!). There are lots of applications that do not work properly with NAT (most kind of "incoming multimedia apps", like CuSeeMee, Netmeeting, etc.) and those will gain in popularity in the years to come. So while NAT will work for some, it is not a solution for everybody. > There might be other justifications, but widely deployed Internet TV and > VoIP which is designed to need non-private IP space at the customers side is > the proof for that something is wrong with the implementation of Internet TV > and VoIP. No - it just shows that the IETF is right with their belief that "NAT is evil" (not all IETF activists, but many). > This is simply a mathematical fact as there are less IPs (4 > Billion) than possible customers (5 Billion, and for VoIP plus Internet-TV > you then need 10 Billion IPs). Yes. This is why we should go to IPv6 as quickly as possible. Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From netmaster at space.net Sat Feb 10 21:04:39 2001 From: netmaster at space.net (Gert Doering, Netmaster) Date: Sat, 10 Feb 2001 21:04:39 +0100 Subject: Fixed Boundary (/29) Assignments In-Reply-To: ; from randy@psg.com on Fri, Feb 09, 2001 at 06:56:49AM -0800 References: <20010208091141.7EFF39CCD4@proxy.bitmailer.com> <20010209120305.W1037@Space.Net> Message-ID: <20010210210439.Y1037@Space.Net> Hi, On Fri, Feb 09, 2001 at 06:56:49AM -0800, Randy Bush wrote: > > Just as a side note: with IPv6, according to current proposals, every > > customer gets a /48 - that's not 32 IPv6 addresses, but 2^80. > > uh, 2^32, as the lower 48 are the mac address (or ersatz-mac for privacy > reasons). Ummm, no - you have 2^16 networks, and can have 2^64 machines in each network (or at least 2^48, assuming "ethernet technology" and unique MAC addresses). Certainly more than 2^32 - but even then, it doesn't matter at all, as it is "enough", and it's a lot more than "32 IPv6 addresses" as in the original proposal I was responding to. Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From jan.czmok at jippiigroup.com Sun Feb 11 01:20:18 2001 From: jan.czmok at jippiigroup.com (Jan-Ahrent Czmok) Date: Sun, 11 Feb 2001 01:20:18 +0100 Subject: IP Address Tracking Software Message-ID: <20010211012018.A7262@intenso.misc.de.jippii.net> Hi! After reading through all the mails at nanog and other forums, i am asking: why not we all together work on a software which works together with RIPE, ARIN, APNIC ? Isn't that what internet was build on ? People doing great things. So let's get all ideas together and work together with the registries to solve that "evil" and "old" problem. Just my .2 cents (or euros, whatever) Jan From clive at demon.net Mon Feb 12 09:57:12 2001 From: clive at demon.net (Clive D.W. Feather) Date: Mon, 12 Feb 2001 08:57:12 +0000 Subject: Fixed Boundary (/29) Assignments In-Reply-To: <01020911360001.27525@ewe.noc.u-net.net>; from aid@vianetworks.net on Fri, Feb 09, 2001 at 11:36:00AM +0000 References: <01020911360001.27525@ewe.noc.u-net.net> Message-ID: <20010212085712.A99432@demon.net> Adrian Bool said: > I think one nice solution would be to allocate all users one /32 that > is routed down the connection, and also one /24 of private IP address > space - NATed by the ISP. > > This way - a user may use mutiple machines without any effort > (by using the /24) yet can have an unrestricted access to the > internet by using the /32. If it's "unrestricted", how do I run two web servers ? -- Clive D.W. Feather | Work: | Tel: +44 20 8371 1138 Internet Expert | Home: | Fax: +44 20 8371 1037 Demon Internet | WWW: http://www.davros.org | DFax: +44 20 8371 4037 Thus plc | | Mobile: +44 7973 377646 From lmb at suse.de Mon Feb 12 10:13:11 2001 From: lmb at suse.de (Lars Marowsky-Bree) Date: Mon, 12 Feb 2001 10:13:11 +0100 Subject: Fixed Boundary (/29) Assignments In-Reply-To: <20010212085712.A99432@demon.net>; from "Clive D.W. Feather" on 2001-02-12T08:57:12 References: <01020911360001.27525@ewe.noc.u-net.net> <20010212085712.A99432@demon.net> Message-ID: <20010212101311.B11465@marowsky-bree.de> On 2001-02-12T08:57:12, "Clive D.W. Feather" said: > > This way - a user may use mutiple machines without any effort > > (by using the /24) yet can have an unrestricted access to the > > internet by using the /32. > If it's "unrestricted", how do I run two web servers ? Virtual hosting, like you are supposed to anyway. Sincerely, Lars Marowsky-Brie SuSE Linux AG at the SAP LinuxLab - lmb at suse.de -- Perfection is our goal, excellence will be tolerated. -- J. Yahl From aid at vianetworks.net Mon Feb 12 10:34:41 2001 From: aid at vianetworks.net (Adrian Bool) Date: Mon, 12 Feb 2001 09:34:41 +0000 Subject: Fixed Boundary (/29) Assignments In-Reply-To: <20010212085712.A99432@demon.net> References: <01020911360001.27525@ewe.noc.u-net.net> <20010212085712.A99432@demon.net> Message-ID: <01021209344100.14196@ewe.noc.u-net.net> On Monday 12 February 2001 08:57, Clive D.W. Feather wrote: > Adrian Bool said: > > I think one nice solution would be to allocate all users one /32 that > > is routed down the connection, and also one /24 of private IP address > > space - NATed by the ISP. > > > > This way - a user may use mutiple machines without any effort > > (by using the /24) yet can have an unrestricted access to the > > internet by using the /32. > > If it's "unrestricted", how do I run two web servers ? MMM.. let's alter your question a little - how you do run 10,000 web servers? You can't create a generic allocation based upon any possible need. Nothing states that the user may not apply for more IP space in the normal fashion - if they so require it. It's just that will the private block and one public address 95% (or greater?) of the users will be sorted. If the user is setting multiple servers on the end if their DSL connection they should be able to get an IP allocation form filled in. Regards, aid -- Adrian Bool | http://noc.vianetworks.net/ Director, Global Network | tel://+44.1925.484061/ VIA NET.WORKS Inc. | fax://+44.1925.484466/ From BCA at fakse.dk Mon Feb 12 12:14:50 2001 From: BCA at fakse.dk (Bjarne Carlsen) Date: Mon, 12 Feb 2001 12:14:50 +0100 Subject: SV: Fixed Boundary (/29) Assignments Message-ID: > -----Oprindelig meddelelse----- > Fra: Randy Bush [SMTP:randy at psg.com] > Sendt: 9. februar 2001 15:16 > Til: Bjarne Carlsen > Cc: lir-wg at ripe.net > Emne: RE: Fixed Boundary (/29) Assignments > > are we? we see folk using dsl at t1 rates to replace p2p t1 lines because > it's a very different cost for the circuit. (here, t1 is expensive and > dsl > is based on old alarm circuit tarrifs) [Bjarne Carlsen] OK - in other words, you don't even see the small difference, that I see on this side of the pond.. > just to push this to the limit. in the states, we usually have free local > dialup. so we have analog "nail up" customers, i.e. they stay dialed up > 7x24. it's just another form of p2p dedicated circuit. and, as far as > address allocation policy goes, treat them the same as an OC12 customer, > they justify what address space they need. [Bjarne Carlsen] Yes, but make it somehow easier for them, since there is one significant difference between private an corporate customers, (at least as seen from this little backwater), namely that the corporate customer usually understands the technical jargon used in documents like RIPE-141 and the private customer invariably says "Huh, er... what is an IP-address??" /Bjarne From huberman at gblx.net Tue Feb 13 00:17:26 2001 From: huberman at gblx.net (David R Huberman) Date: Mon, 12 Feb 2001 16:17:26 -0700 (MST) Subject: Conclusions? Re: Fixed Boundary (/29) Assignments In-Reply-To: Message-ID: Hello everyone, Monday has now concluded for most of the world, and we have now engaged in a fairly vibrant discussion of Leo Vegoda's residential broadband assignment presentation. How should we proceed now, as a WG? Beyond just the remaining discussions, many of which will inevitably analyze an interesting facet of the main thread but which will not talk directly to the thread's focus, how else can we approach the idea of fixed boundary assignments before putting this to a vote? Leo, what are your views at this point? I think NCC staff input might be appropriate now. It is my opinion that we should all be prepared to vote on a recommendation to the NCC at the Bologna meeting. Thoughts/flames? /david *--------------------------------* | Global Crossing IP Engineering | | Manager, Global IP Addressing | | TEL: (908) 720-6182 | | FAX: (703) 464-0802 | *--------------------------------* From randy at psg.com Tue Feb 13 00:22:47 2001 From: randy at psg.com (Randy Bush) Date: Mon, 12 Feb 2001 15:22:47 -0800 Subject: Conclusions? Re: Fixed Boundary (/29) Assignments References: Message-ID: i vote that large sites get a /8, medium a /16, and small a /24. i always loved architecture by democracy. randy From huberman at gblx.net Tue Feb 13 00:37:20 2001 From: huberman at gblx.net (David R Huberman) Date: Mon, 12 Feb 2001 16:37:20 -0700 (MST) Subject: Conclusions? Re: Fixed Boundary (/29) Assignments In-Reply-To: Message-ID: Randy Bush wrote: > i vote that large sites get a /8, medium a /16, and small a /24. i always > loved architecture by democracy. Actually, I was going to put up a proposal that those providers who do aggressive route filtering get a /16, and those that don't must use NAT. But seriously, last I checked RIPE was still a member-driven organization. In the absence of an issue which requires direct IETF oversight, I'm pretty sure we still get to help shape the address assignment policies by which we all must abide. /david From hph at online.no Tue Feb 13 00:44:13 2001 From: hph at online.no (Hans Petter Holen) Date: Tue, 13 Feb 2001 00:44:13 +0100 Subject: Conclusions? Re: Fixed Boundary (/29) Assignments References: Message-ID: <008301c0954d$b4cd0790$0300000a@hph> > How should we proceed now, as a WG? Someone should try to formulate a consensus from the previous discussion. Post that to the list, and present it to the wg in Bologna. Any voulenteers ? -hph PS: strictly speaking we don't have a concept of voting, check out http://www.ripe.net/ripe/wg/lir/index.html under "How to develope RIPE policy " http://www.ripe.net/ripe/wg/lir/howto_devolep.html From mohta at necom830.hpcl.titech.ac.jp Tue Feb 13 00:48:04 2001 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 13 Feb 2001 08:47:04 +0859 () Subject: Conclusions? Re: Fixed Boundary (/29) Assignments In-Reply-To: from David R Huberman at "Feb 12, 2001 04:17:26 pm" Message-ID: <200102122347.IAA09278@necom830.hpcl.titech.ac.jp> David R Huberman; > Monday has now concluded for most of the world, and we have now engaged in > a fairly vibrant discussion of Leo Vegoda's residential broadband > assignment presentation. > > How should we proceed now, as a WG? > > Beyond just the remaining discussions, many of which will inevitably > analyze an interesting facet of the main thread but which will not talk > directly to the thread's focus, how else can we approach the idea of fixed > boundary assignments before putting this to a vote? Leo, what are your > views at this point? I think NCC staff input might be appropriate now. > > It is my opinion that we should all be prepared to vote on a > recommendation to the NCC at the Bologna meeting. > > Thoughts/flames? You should be aware that the issue is more fundamental than to vote on an alternative way to conserve the space. We will run out of the space anyway (perhaps sooner than you expect because of various factors) that: Leo Vegoda> This is consistent with the RIRs' goal of conservation. the current purposeless conservation is a meaningless goal. The meaningful goal is purposeful consumption. Masataka Ohta From ggm at apnic.net Tue Feb 13 01:41:14 2001 From: ggm at apnic.net (George Michaelson) Date: Tue, 13 Feb 2001 10:41:14 +1000 Subject: 1. draft minutes of joint Routing/DB wg session RIPE38 In-Reply-To: Your message of "Mon, 12 Feb 2001 19:30:47 EST." <66.c1a7c1b.27b9da37@aol.com> Message-ID: <20272.982024874@apnic.net> > Andrei also showed which OSs are currently supported for the database > software > o Solaris 2.8 (Intel & Sparc) > o Linux (RedHat, SuSe). > o FreeBSD I submitted codemods for FreeBSD but I would hesitate to say its known to work on FreeBSD. If that port is verified from other sources I'm happy! APNIC runs registry on SCO OpenServer. Thats a critical dependency for APNIC and right now, the code is only beginning to work. I realize APNIC is not on the 'critical path' for your migration timeline. This is more in the sense of an FYI. cheers -George From SchmitzJo at aol.com Tue Feb 13 01:30:47 2001 From: SchmitzJo at aol.com (SchmitzJo at aol.com) Date: Mon, 12 Feb 2001 19:30:47 EST Subject: 1. draft minutes of joint Routing/DB wg session RIPE38 Message-ID: <66.c1a7c1b.27b9da37@aol.com> R I P E 3 8 A M S T E R D A M Joint Session DB and Routing 24-Jan-2001 Draft Minutes Chairs: Joachim Schmitz, Wilfried Woeber Scribe: Engin Gunduz Participants: 97 Joint Session of Routing and Database Working Groups Due to the importance of the subject, and the overlap in topic, the chairmen of Routing and Database WG (Wilfried Woeber) decided to have a joint session of both WGs. Joachim introduced the audience to the session, and chaired it together with Wilfried. E. Migration to the new RIPE database (Andrei Robachevsky, RIPE NCC) (20min) [ The presentatino is available at http://www.ripe.net/ripe/meetings/archive/ripe-38/presentations/r38-reimp-andr ei/index.html ] Andrei gave an overview of what to expect for the migration to the new RIPE database. He began with asking who would be affected by the migration, and the answer is: everybody. Reasons are - RPSL format - new access control - new database format - new version mirroring protocol He supported this by a set of examples, and made suggestions on how to prepare for the migration, depending on which usage group a database user belongs to - query users - update users - adaptation of scripts - near real time mirroring Following that a schedule was presented which summarized the proposed final transition dates - 23-Apr-2001: switching to the RPSL database Queries return RPSL only Mirroring follows new format and rules at whois.ripe.net, port 4444 RPSL updates go to auto-rpsl at ripe.net RIPE-181 updates are still possible and still go to auto-dbm at ripe.net, but are autmatically converted to RPSL - 14-May-2001: exchanging mail addresses auto-dbm at ripe.net only accepts RPSL updates RIPE-181 updates are still possible but now go to auto-181 at ripe.net and are automatically converted to RPSL - 15-Oct-2001: RIPE-181 updates are no longer possible The crucial date is the first one. It will not be possible to go back after that date. The RIPE NCC has prepared a vast set of aides to assist in the transition, and to get used to RPSL format. All details are available at the RIPE-181 to RPSL transition web page http://www.ripe.net/rpsl The presentation led to a vivid discussion, in particular whether the first transition date is too early or too late. Ping Lu was suggesting to move the dates further into the future because - they are using a lot of off-line tools - the downstreams need to be educated He later explains that he himself would transition rather earlier than later but he is worried about their vast customer base. Joachim pointed out that the transition should not be delayed because RADB is already running RPSL since quite some time, making it more complicated for people using both RADB and RIPE. Moreover, he thought that someone had written some tool to perform at least in part some back conversion from RPSL to RIPE-181, which as Wilfried Woeber pointed out would only be possible for a limited number of objects. However, such tool never was available. Christan Panigl reminded the audience that the idea had come up to supply a RAToolSet tutorial at the next RIPE meeting. He suggested to run it before the transition to the RPSL database, essentially before 23-Apr. The audience wants to have this tutorial parallel to the next RIPE meeting. However, this would delay the first transition date into May. A quick poll showed that 10 people in the audience knew RAToolSet, and that actually 2 were using it in conjunction with RADB. It obviously makes sense to have a tutorial -> action 38.R1 on Wilfried Woeber and Joachim Schmitz to organize a RAToolSet tutorial at the RIPE39 meeting Ruediger Volk points out that a transition very shortly after the tutorial does not make much sense. He also stresses that he objects against postponing the transition, because other transition projects within his company have already been delayed due to the not yet factual transition with RIPE. Jake Khuon agrees with Ruediger. He also points out that many of the objects are doubly registered both in RADB and RIPE. Joachim asked the audience who of them are actually using any kind of automated tools in conjunction with the database, and it turned out that these were more or less the same people who also knew RAToolSet. Accordingly, most of the people requesting a tutorial on RAToolSet do not need it right now and are thus also not affected for automation. This decouples the dates of when the tutorial will be held, and the transition to RPSL. Consequently, even though these are only proposed dates, Wilfried suggests to stick to these dates, and people who think that they have real technical problems must speak up to the community to have those reviewed. -> action 38.R2 on Wilfried Woeber and Joachim Schmitz to send around the transition dates, get input from the community, with a following decision on the dates Ping Lu thinking of interaction of databases then brings up the topic of global NIC handles. Wilfried explains that globally unique NIC handles are not related to RPSL, or the transition to RPSL. He has it on his agenda for the Database WG session tomorrow (25-Jan). F. Report from the DB migration task force (Wilfried Woeber, Andrei Robachevsky) Wilfried reported that the DB migration task force did a review and besides a set of questions identified by some active members of the user community, the following open issues were identified - Outreach The RIPE NCC has taken every effort to notify all parties repeatedly who will be affected by the transition. Disappointingly, the feedback on these efforts has been small. - Other items are * broken PGP keys * unprotected aut-num objects * object names not compliant with RPSL which were discussed in a short presentation by Andrei Andrei gave a few statistics on those items, first on their efforts to contact parties which need to be involved, and then on the open issues where Joao Damas explained the proposed solutions. - Broken PGP keys The old PGP programs generated non-compliant PGP keys. Those keys will be refused by version 3 software. It turns out that 7 out of 409 PGP keys are broken. The proposed solution is to delete the key certificates. This does not affect security for a simple reason: If someone wants to apply a change to objects protected that way, the software does not find the corresponding key certificate, and thus rejects the update. The party who wants to submit the change will then be required to contact the RIPE NCC. It was general consensus in the audience to follow that approach. - Unprotected aut-num objects In the past, it had become mandatory to have aut-num objects protected by a maintainer. However, 119 out of 4008 aut-num objects still today do not have a mnt-by attribute. So far, they enjoy a "special" protection: Only ripe-dbm can modify them. Surprisingly, none of them was ever touched in all the time since the original change of requirements. It is still mandatory to have a maintainer with each aut-num object in RPSL. The question is of how to proceed. The proposed solution is to add a special RIPE NCC maintainer. By that way, no security breach is opened, and no change compared to the situation today is introduced. If anybody ever wants to touch that aut-num object again, they still need to contact ripe-dbm. It was general consensus in the audience to follow that approach. - Reserved RPSL names Quite a lot of objects in the database have names which do not comply with RPSL rules. An example are 108 aut-num objects using the reserved prefix "AS-" in the AS-name attribute, or 7 maintainer objects with other reserved prefixes. The proposed solution is to change the names prior to transition in a way which still needs to be agreed upon. A suggestion is to contact all parties who own those objects, and also publish them on appropriate RIPE mailing lists. It was general consensus in the audience to follow that approach. Those results were taken to the Database WG. Ping Lu raised the question whether there was the intention to implement global maintainers. Andrei explained that so far all references must be resolved locally. Andrei also showed which OSs are currently supported for the database software o Solaris 2.8 (Intel & Sparc) o Linux (RedHat, SuSe). o FreeBSD The inquiry from Wilfried showed that this list is accepted by everybody, and no other OSs seem to be used by any company of registry, meaning from that side no problems are expected. Wilfried asked the NCC to release the database software for all platforms without putting too much effort into performance tweaking for each individual OS, just assuring its overall functionality. Anybody who wants to participate in the transition discussion is free to join the migration task force mailing list reimp-mig-tf at ripe.net Summary of Open Action Points from the Joint Session of DB and Routing 38.R1 on J.Schmitz, W.Woeber Organize RaToolSet tutorial at RIPE 39 status: new 38.R2 on J.Schmitz, W.Woeber Collect final community input on DB migration dates status: new Engin Gunduz, Joachim Schmitz, February 2001 From ggm at apnic.net Tue Feb 13 01:53:47 2001 From: ggm at apnic.net (George Michaelson) Date: Tue, 13 Feb 2001 10:53:47 +1000 Subject: 1. draft minutes of joint Routing/DB wg session RIPE38 In-Reply-To: Your message of "Tue, 13 Feb 2001 10:41:14 +1000." <20272.982024874@apnic.net> Message-ID: <21325.982025627@apnic.net> > APNIC runs registry on SCO OpenServer. Mea culpa. s/OpenServer/UnixWare 7./ cheers -George -- George Michaelson | DSTC Pty Ltd Email: ggm at dstc.edu.au | University of Qld 4072 Phone: +61 7 3365 4310 | Australia Fax: +61 7 3365 4311 | http://www.dstc.edu.au From oppermann at telehouse.ch Tue Feb 13 09:03:27 2001 From: oppermann at telehouse.ch (Andre Oppermann) Date: Tue, 13 Feb 2001 09:03:27 +0100 Subject: Conclusions? Re: Fixed Boundary (/29) Assignments References: <008301c0954d$b4cd0790$0300000a@hph> Message-ID: <3A88EA4F.AB00E5E8@telehouse.ch> Hans Petter Holen wrote: > > > How should we proceed now, as a WG? > > Someone should try to formulate a consensus from the previous discussion. > > Post that to the list, and present it to the wg in Bologna. > > Any voulenteers ? Maybe the address space usage should be categorized by sort of access, see below. This can then be documented in a policy recommendation like the policy on single-IP webhosting and static-dialup IP's today. As I have see so far there are different ways how the carriers/ISP's are handling technologies like xDSL/CableModem: Most often we can differentiate between some sort of virtual dial-up and shared media, examples: - Many xDSL require PPPoE or PPPoA on the client side to establish a connection to the Internet. -> This is simply a virtualized dial-up, same rules apply, eg. you get a real IP out of an pool when you dial in. If you allow more concurrent connection from a customer is your problem. The need for a static IP has to be justified just as it is today with analog/ISDN dial-up (RIPE-141). Here the number of concurrent users is significant. This can be usually at most one per customer (always-on). - Many CableModem operator run their network segments as simple LAN's and assign an IP address dynamically by DHCP (or some other mechanism). -> This can also be treated as virtualized dial-up, same rules etc. The number of concurrent computers (devices) online depends on the operator. As far as I know many allow only one. The need for a static IP has to be justified just as it is today with analog/ISDN dial-up (RIPE-141). Here again the number of concurrent users is significant. This can be usually at most one per customer (always-on). - Sometimes xDSL lines are run like a full blown leased line with line IP's and a subnet on the customers side. -> This should be discouraged like ip-based webhosting unless justified with a RIPE-141 form as this wastes not only a /29 (in the case of a general assignment) but also the line IP's, so the efficiency goes even further down. Any use of leased line type access should be discouraged for the average residential / small business mom-and-pop shop unless justified by an RIPE-141 form. As long as you get at least one real IP you either have your PC directly connected or you have some sort of 'smart' router equipment (mention Cisco, ZyXEL, BinTec, etc.) which can do NAT/PAT or masquerading just fine, even for services like Napster and such. - Are there any sorts of "new" broadband accesses I forgot? Yes, based on the response to this post I would volunteer to make this a full RIPE document and present it in Bologna. -- Andre Oppermann AO6-RIPE From shane at ripe.net Tue Feb 13 09:55:57 2001 From: shane at ripe.net (Shane Kerr) Date: Tue, 13 Feb 2001 09:55:57 +0100 (CET) Subject: 1. draft minutes of joint Routing/DB wg session RIPE38 In-Reply-To: <20272.982024874@apnic.net> Message-ID: George, On Tue, 13 Feb 2001, George Michaelson wrote: > > Andrei also showed which OSs are currently supported for the database > > software > > o Solaris 2.8 (Intel & Sparc) > > o Linux (RedHat, SuSe). > > o FreeBSD > > I submitted codemods for FreeBSD but I would hesitate to say its > known to work on FreeBSD. If that port is verified from other > sources I'm happy! Linux and FreeBSD are more of an "intended target" for the server at this point. The server compiles and runs on Linux, but is largely untested. The port to FreeBSD has been accomplished largely by you (thanks George). We're concentrating on stability and accurracy on Solaris right now, because that's our own environment, and we need to make 100% sure it works for the cutover on April 23rd. Having said that, we WILL make the code work on Linux and FreeBSD as soon as possible, hopefully before the cutover as well. > APNIC runs registry on SCO OpenServer. Thats a critical dependency > for APNIC and right now, the code is only beginning to work. I hesitate to do this, but... I have two questions related to this. Is anybody else running SCO? And is anybody else running another operating system (Unix-like, although I suppose a Cygnus port is theoretically possible for Windows) that they plan to run RIPE Whois 3.0 on? -- Shane From hph at online.no Tue Feb 13 11:27:54 2001 From: hph at online.no (Hans Petter Holen) Date: Tue, 13 Feb 2001 11:27:54 +0100 Subject: Policy and PR problem Message-ID: <003601c095a7$a37980e0$9b014382@hph> Hi, I am just attending a seminar in Broad band networks, and met again the claim that -"it is currently very difficult to get IP address space" and as a result of that we have to plan complex network solutions with a combination of private and public addresses. This claim is very different from the one I tend to make: "you get the addresses you need as long as you can provide documentation that you realy need them". personally I think that we have a serious PR problem here: is it so that the rules and regulations have become so strict and complicated that we, the lirs, tell our customers that this is very difficult and you should realy use private addresses, rather than explaining how the procedures and policies realy work ? Is this what we want ? -hph From mike.norris at heanet.ie Tue Feb 13 11:58:05 2001 From: mike.norris at heanet.ie (mike.norris at heanet.ie) Date: Tue, 13 Feb 2001 10:58:05 -0000 Subject: Policy and PR problem In-Reply-To: <3F2D1A940FB8D1118A1F00609783612958BA15@nt-server.heanet.ie> Message-ID: <3F2D1A940FB8D1118A1F0060978361295890C0@nt-server.heanet.ie> > I am just attending a seminar in Broad band networks, and met again the > claim that > > -"it is currently very difficult to get IP address space" and as a result of > that we have to plan complex network solutions with a combination of private > and public addresses. This might be true if the words "For those who don't take the trouble to understand and follow the agreed procedures," were inserted at the start of the sentence. > > This claim is very different from the one I tend to make: "you get the > addresses you need as long as you can provide documentation that you realy > need them". This is my experience and my expectation of RIPE NCC. > > personally I think that we have a serious PR problem here: is it so that the > rules and regulations have become so strict and complicated that we, the > lirs, tell our customers that this is very difficult and you should realy > use private addresses, rather than explaining how the procedures and > policies realy work ? > > Is this what we want ? You're right, we do need to get the positive message across. RIPE NCC, and RIPE representatives such as yourself, Peter, have been doing this at various levels, and I think the effort is increasing. Perhaps we need to direct some attention to the more popular media, to explain the importance, the function and the challenges of address registration in the European Internet. Regards. Mike From denesh at cyberstrider.net Tue Feb 13 11:39:44 2001 From: denesh at cyberstrider.net (Denesh Bhabuta) Date: Tue, 13 Feb 2001 10:39:44 +0000 Subject: Policy and PR problem In-Reply-To: <003601c095a7$a37980e0$9b014382@hph> Message-ID: <5.0.2.1.2.20010213103020.02a91e30@mail.own.cyberstrider.net> At 10:27 13/02/2001, Hans Petter Holen wrote: >personally I think that we have a serious PR problem here: is it so that the >rules and regulations have become so strict and complicated that we, the >lirs, tell our customers that this is very difficult and you should realy >use private addresses, rather than explaining how the procedures and >policies realy work ? IMHO, the main problem seems to be clueless salesmen who do not understand RIPEs procedures, and the clueless product managers who will go and design a solution without knowing what procedures they have to follow or restrictions they have when it comes to IP addresses. This leaves the poor hostmaster trying to explain to the company that it can not do what it wants to do and by then it is almost too late.. advertising etc is all done. What may be worth doing is getting 'salesmen' to go to RIPE training courses - as it is these people who talk to customers directly for that signature on the contract. :) What we need to realise is how companies in this industry conduct business nowadays.. (I am not including those companies who have followed the RIPE rules from time immemorial). I have also already spoken to Axel about RIPE maybe looking at an Outreach program (something that Nominet - the .uk not for profit registry - is doing now)... this will be good for PR. The other aspect I have briefly spoken to Axel about and also to Margriet is how to make the new LIR sign up process less administratively heavy. I am not saying that we change the RIPE NCC we have all come to love over the years.. just that we need to be aware of business in this industry and the way it is going. Regards Denesh -- Denesh Bhabuta Chairman, CEO and Principal Consultant Cyberstrider Limited www.cyberstrider.net Internet and E-Commerce: Strategy, Consultancy and Solutions From lporter at cw.net Tue Feb 13 12:35:06 2001 From: lporter at cw.net (Leigh Porter) Date: Tue, 13 Feb 2001 11:35:06 +0000 Subject: Policy and PR problem References: <003601c095a7$a37980e0$9b014382@hph> Message-ID: <3A891BEA.40EB2307@cw.net> Hans Petter Holen wrote: > personally I think that we have a serious PR problem here: is it so that the > rules and regulations have become so strict and complicated that we, the > lirs, tell our customers that this is very difficult and you should realy > use private addresses, rather than explaining how the procedures and > policies realy work ? > > Is this what we want ? Well, if they have come up with a successfull solution that uses private address space that fulfills their requirments, then they obviously did not really need public address space in the first place. Therefore you could assume that their application for address space would have been returned to them, so really you just saved your customer some time :) -- Leigh Porter Cable and Wireless From netmaster at space.net Tue Feb 13 11:52:44 2001 From: netmaster at space.net (Gert Doering, Netmaster) Date: Tue, 13 Feb 2001 11:52:44 +0100 Subject: Policy and PR problem In-Reply-To: <003601c095a7$a37980e0$9b014382@hph>; from hph@online.no on Tue, Feb 13, 2001 at 11:27:54AM +0100 References: <003601c095a7$a37980e0$9b014382@hph> Message-ID: <20010213115244.C1037@Space.Net> Hi, On Tue, Feb 13, 2001 at 11:27:54AM +0100, Hans Petter Holen wrote: > personally I think that we have a serious PR problem here: is it so that the > rules and regulations have become so strict and complicated that we, the > lirs, tell our customers that this is very difficult and you should realy > use private addresses, rather than explaining how the procedures and > policies realy work ? that "they are urged to force NAT on their customers, as much as possible". This is not how I understood policy ("always consider NAT, but the decision is the customer's - and everybody can get as much addresses as they can show their need for"), so maybe the current policy isn't documented clearly enough... Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From nurani at ripe.net Tue Feb 13 13:08:01 2001 From: nurani at ripe.net (Nurani Nimpuno) Date: Tue, 13 Feb 2001 13:08:01 +0100 Subject: Policy and PR problem In-Reply-To: Your message of Tue, 13 Feb 2001 11:52:44 +0100. <20010213115244.C1037@Space.Net> References: <20010213115244.C1037@Space.Net> Message-ID: <200102131208.NAA24755@x7.ripe.net> Dear all, I find it useful that you bring this up Hans-Petter. I will not try to provide any replies or solutions at this point in the discussion as I am interested in the input from our members (and others in the community). However, what I can say is that we at the RIPE NCC are very aware of how complicated it is for new LIRs to learn all policies and procedures involved in obtaining IP address space and AS numbers. (And indeed there are quite a few.) We invest a enormous amount of resources in educating these people, correcting them, explaining policies, justifying procedures, referring to documentation etc etc. In fact, this is where you see the bulk of our workload. Although it has always been seen as part of the hostmaster role to educate the LIRs, it is not an easy task with the current dramatic growth of LIRs. We have partly discussed this with the May 17 Taskforce and we are also constantly discussing it internally at the RIPE NCC, trying to find more efficient ways of coping with the workload and the growth. But this if of course only one aspect/consequence of the problem. If the perception is as you describe, then there is a more serious problem and we need to look at other solutions. This may be a PR problem. It is also possible that the policies simply have become too complicated for new members. (Can it be that the policies which are developed by experienced and clueful members of the Internet community is not necessarily easy for newer, less experienced LIRs?) Is the problem possibly a combination of the two? I am very interested in how this is perceived in the membership before trying to give my analysis. Let's first try to define the problem and then continue discussing possible solutions. Kind regards, -- Nurani Nimpuno Registration Services Manager RIPE NCC http://www.ripe.net "Gert Doering, Netmaster" writes: * Hi, * * On Tue, Feb 13, 2001 at 11:27:54AM +0100, Hans Petter Holen wrote: * > personally I think that we have a serious PR problem here: is it so that t * he * > rules and regulations have become so strict and complicated that we, the * > lirs, tell our customers that this is very difficult and you should realy * > use private addresses, rather than explaining how the procedures and * > policies realy work ? * * that "they are urged to force NAT on their customers, as much as possible". * * This is not how I understood policy ("always consider NAT, but the decision * is the customer's - and everybody can get as much addresses as they can * show their need for"), so maybe the current policy isn't documented clearly * enough... * * Gert Doering * -- NetMaster * -- * SpaceNet AG Mail: netmaster at Space.Net * Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 * 80807 Muenchen Fax : +49-89-32356-299 * * * From mdavids at forfun.net Tue Feb 13 13:05:30 2001 From: mdavids at forfun.net (Marco Davids) Date: Tue, 13 Feb 2001 13:05:30 +0100 (CET) Subject: Policy and PR problem Message-ID: On Tue, 13 Feb 2001, Hans Petter Holen wrote: > -"it is currently very difficult to get IP address space" and as a result of > that we have to plan complex network solutions with a combination of private > and public addresses. > > This claim is very different from the one I tend to make: "you get the > addresses you need as long as you can provide documentation that you realy > need them". I agree with that, although I use to have a hard time convincing my manager to come up with copy's of invoice and all kinds of other 'strategic' information to proof to RIPE that we really needed the IP-space that was required by that time. I wonder what RIPE does with all this information? I trust they destroy it, after the IP-request has been approved? And how about returning IP-space? The procedures there are not very clear to me (except for the case when the LIR does not pay its fee). Can allocated address-blocks for example be transferred to another party without mediation of RIPE after a merge of company's or something of that kind? Cheers, -- Marco From leo at ripe.net Tue Feb 13 13:38:54 2001 From: leo at ripe.net (leo vegoda) Date: Tue, 13 Feb 2001 13:38:54 +0100 Subject: Conclusions? Re: Fixed Boundary (/29) Assignments In-Reply-To: ; from huberman@gblx.net on Mon, Feb 12, 2001 at 04:17:26PM -0700 References: Message-ID: <20010213133854.D820@ripe.net> Hello all, The RIPE NCC will be glad to summarise the discussion on this list and at the Bologna meeting, if required. However, we would like to give the Working Group a few more days to discuss this subject before we summarise as we want to be sure that everyone wishing to contribute has an opportunity to do so. Best regards, leo vegoda RIPE NCC Bloke From mdavids at forfun.net Tue Feb 13 13:55:22 2001 From: mdavids at forfun.net (Marco Davids) Date: Tue, 13 Feb 2001 13:55:22 +0100 (CET) Subject: Policy and PR problem Message-ID: On Tue, 13 Feb 2001, Hans Petter Holen wrote: > -"it is currently very difficult to get IP address space" and as a result of > that we have to plan complex network solutions with a combination of private > and public addresses. > > This claim is very different from the one I tend to make: "you get the > addresses you need as long as you can provide documentation that you realy > need them". I agree with that, although I use to have a hard time convincing my manager to come up with copy's of invoice and all kinds of other 'strategic' information to proof to RIPE that we really needed the IP-space that was required by that time. I wonder what RIPE does with all this information? I trust they destroy it, after the IP-request has been approved? And how about returning IP-space? The procedures there are not very clear to me (except for the case when the LIR does not pay its fee). Can allocated address-blocks for example be transferred to another party without mediation of RIPE after a merge of company's or something of that kind? Cheers, -- Marco From ripe-ml at cyberstrider.net Tue Feb 13 11:58:38 2001 From: ripe-ml at cyberstrider.net (Denesh Bhabuta) Date: Tue, 13 Feb 2001 10:58:38 +0000 Subject: Policy and PR problem Message-ID: <5.0.2.1.2.20010213105830.0413ae10@mail.own.cyberstrider.net> At 10:27 13/02/2001, Hans Petter Holen wrote: >personally I think that we have a serious PR problem here: is it so that the >rules and regulations have become so strict and complicated that we, the >lirs, tell our customers that this is very difficult and you should realy >use private addresses, rather than explaining how the procedures and >policies realy work ? IMHO, the main problem seems to be clueless salesmen who do not understand RIPEs procedures, and the clueless product managers who will go and design a solution without knowing what procedures they have to follow or restrictions they have when it comes to IP addresses. This leaves the poor hostmaster trying to explain to the company that it can not do what it wants to do and by then it is almost too late.. advertising etc is all done. What may be worth doing is getting 'salesmen' to go to RIPE training courses - as it is these people who talk to customers directly for that signature on the contract. :) What we need to realise is how companies in this industry conduct business nowadays.. (I am not including those companies who have followed the RIPE rules from time immemorial). I have also already spoken to Axel about RIPE maybe looking at an Outreach program (something that Nominet - the .uk not for profit registry - is doing now)... this will be good for PR. The other aspect I have briefly spoken to Axel about and also to Margriet is how to make the new LIR sign up process less administratively heavy. I am not saying that we change the RIPE NCC we have all come to love over the years.. just that we need to be aware of business in this industry and the way it is going. Regards Denesh -- Denesh Bhabuta Chairman, CEO and Principal Consultant Cyberstrider Limited www.cyberstrider.net Internet and E-Commerce: Strategy, Consultancy and Solutions From nurani at ripe.net Tue Feb 13 13:50:56 2001 From: nurani at ripe.net (Nurani Nimpuno) Date: Tue, 13 Feb 2001 13:50:56 +0100 Subject: Policy and PR problem In-Reply-To: Your message of Tue, 13 Feb 2001 13:05:30 +0100. References: Message-ID: <200102131251.NAA25046@x7.ripe.net> Dear Marco, Marco Davids writes: * I wonder what RIPE does with all this information? I trust they destroy * it, after the IP-request has been approved? No, we do not destroy it as it may be necessary to refer back to this information in future requests. It is all stored and kept in the strictest confidentiality. * And how about returning IP-space? The procedures there are not very clear * to me (except for the case when the LIR does not pay its fee). Can * allocated address-blocks for example be transferred to another * party without mediation of RIPE after a merge of company's or something * of that kind? I will make sure you get an explanation to your question, but off this list. The mailbox is open for any questions you as members may have and is usually responded to within one working day. I will not go into detail in answering your questions here on the list as the questions themselves are out of the scope of this discussion. cheers Nurani -- Nurani Nimpuno Registration Services Manager RIPE NCC http://www.ripe.net * Cheers, * * -- * Marco * * * From hph at online.no Tue Feb 13 13:46:57 2001 From: hph at online.no (Hans Petter Holen) Date: Tue, 13 Feb 2001 13:46:57 +0100 Subject: Policy and PR problem References: <003601c095a7$a37980e0$9b014382@hph> <3A891BEA.40EB2307@cw.net> Message-ID: <002901c095bb$2291d720$7705e1c3@hph> > > Is this what we want ? > > Well, if they have come up with a successfull solution that uses private > address space that fulfills their requirments, then they obviously did > not > really need public address space in the first place. Therefore you could > assume that their application for address space would have been returned > to them, so really you just saved your customer some time :) Well, my interpretation is that they have come up with a complex solution with limitations that costs the customers more in consultant fees in order to make the complex addressing structure work. -hph From woeber at cc.univie.ac.at Tue Feb 13 13:40:44 2001 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 13 Feb 2001 13:40:44 +0100 Subject: Policy and PR problem Message-ID: <009F794B.076A206E.21@cc.univie.ac.at> Hi Nurani, Thanks for your comments, and I agree that your "the Hostmaster Role's" point of view is of interest of course, eventually, but that the community still has to do a bit more thinking and brain-storming before we can wrap up. >However, what I can say is that we at the RIPE NCC are very aware of >how complicated it is for new LIRs to learn all policies and >procedures involved in obtaining IP address space and AS numbers. >(And indeed there are quite a few.) One of the things that adds to complexity (IMHO) is the fact that the policies (you have to make your needs known, and to do so in a way that can be reviewed) are not clearly separated from the procedures involved. While I think the basic *policy* is more or less straightforward: You get what you need and as much as you can reasonably argue for, and we don't interfere with the engineering approach for your networks by making *policy* that cripples certain design approaches. (With a very few exceptions) We do, however require the applicant to think about alternative approaches, and to make a conscious decision in favour of one or another approach, like rfc1918, http 1.1, ... What indeed has become too complex is the *procedures*. What has been appropriate a few years ago, is not necessarily appropriate any longer for every application everywhere. The Internet has changed a bit. There are more diverse entities active now which have to look at some other boundary conditions in addition to network engineering and address space conservation (as the "only" goal) like size, internal structure, business models, investments, security, helpdesk and customer care issues, and last but not least privacy issues.... >Although it has always been seen as part of the hostmaster role to >educate the LIRs, it is not an easy task with the current dramatic >growth of LIRs. We have partly discussed this with the May 17 >Taskforce and we are also constantly discussing it internally at the >RIPE NCC, trying to find more efficient ways of coping with the >workload and the growth. Indeed. >This may be a PR problem. It is also possible that the policies >simply have become too complicated for new members. (Can it be that >the policies which are developed by experienced and clueful members >of the Internet community is not necessarily easy for newer, less >experienced LIRs?) Is the problem possibly a combination of the two? We should put the effort in dealing with the scaling problem of the *procedures*. While I do not know (and do not want to know) which application made Leo "go public", I would like to report to the community that I had a few very interesting private discussions during the last RIPE Meeting with a sizable company planning the roll-out of a "mass-market" product, and they indeed were a) present at the meeting, and b) had *very* sound questions to ask and were looking for input from the community. So "they" are out there, trying to do "the right thing". But the community should try to understand their position as well, and the scaling problems. Otherwise nobody should be surprised to hear the claims, that it is not possible for them to work with and as part of the "established" community, and that "they" have to build something else that fits their needs.... Wilfried. From stephenb at uk.uu.net Tue Feb 13 16:20:59 2001 From: stephenb at uk.uu.net (Stephen Burley) Date: Tue, 13 Feb 2001 15:20:59 +0000 Subject: Conclusions? Re: Fixed Boundary (/29) Assignments References: <20010213133854.D820@ripe.net> Message-ID: <3A8950DB.F3FAB4D0@uk.uu.net> leo vegoda wrote: > > Hello all, > > The RIPE NCC will be glad to summarise the discussion on this list and > at the Bologna meeting, if required. > > However, we would like to give the Working Group a few more days to > discuss this subject before we summarise as we want to be sure that > everyone wishing to contribute has an opportunity to do so. > > Best regards, > > leo vegoda > RIPE NCC Bloke Sorry to be a pain but could you please summerise where we are in the current discussion so we can try and formulate the ideas more fimly in our thinking processes. Many thanks, -- ------------------------------------------------------------------------ Stephen Burley "If patience is a virtue, and ignorance is bliss, UUNET EMEA Hostmaster you can have a pretty good life [SB855-RIPE] if you're stupid and willing to wait" ------------------------------------------------------------------------ From matt at fdd.co.uk Tue Feb 13 12:59:50 2001 From: matt at fdd.co.uk (Matt Clark) Date: Tue, 13 Feb 2001 11:59:50 -0000 Subject: Policy and PR problem In-Reply-To: <20010213115244.C1037@Space.Net> Message-ID: <000a01c095b4$78e35470$0e88a5d5@fdd.co.uk> > This is not how I understood policy ("always consider NAT, > but the decision > is the customer's - and everybody can get as much addresses > as they can > show their need for"), so maybe the current policy isn't > documented clearly > enough... > > Gert Doering > -- NetMaster In my experience part of the problem is the word "need". Many people assume that "need" implies that there is no alternative solution available, which is a very hard thing to demonstrate. In fact current policy is much easier, since "need" is usually interpreted to be "want to use". For instance, if I have designed a system that will use 200 public addresses, one per website, then I do not have to prove to RIPE that virtual hosting is not an option for me, I just assert that the addresses will be used once allocated. In this case, I may well not "need" the space in the strong sense, but I do "need" it in the weak sense. Perhaps this ambiguity is a significant part of the problem? Matt Clark FDD/Netscalibur From mir at ripe.net Fri Feb 16 11:04:02 2001 From: mir at ripe.net (Mirjam Kuehne) Date: Fri, 16 Feb 2001 11:04:02 +0100 Subject: Summary: Fixed Boundary (/29) Assignments Message-ID: <200102161004.LAA18004@x30.ripe.net> Dear LIR-WG, Here is an attempt to summarise the recent discussions on this mailing list regarding possible fixed size assignments. Following a review of the comments, it looks like the majority does not believe that a special assignment policy is needed. Most contributors agreed that there is no need to make a distinction in policy relating to different access methods. All assignments should be made on actual needs and according to the current IP address policies. The comments showed concerns about the administrative procedures required for these kinds of assignments. However, it was felt that these addresses need to be accounted for in some way. A possible way forward would be to initiate discussion surrounding the set of information necessary to justify these assignments while providing an efficient way for the LIRs to provide services to their customers. I realise that I did not touch on every aspect of the discussion but I hope that this is a fair summary in order for you to move forward Looking forward to a continuation of this debate. Best Regards, Mirjam Kuehne RIPE NCC From oppermann at telehouse.ch Fri Feb 16 11:42:35 2001 From: oppermann at telehouse.ch (Andre Oppermann) Date: Fri, 16 Feb 2001 11:42:35 +0100 Subject: Summary: Fixed Boundary (/29) Assignments References: <200102161004.LAA18004@x30.ripe.net> Message-ID: <3A8D041B.8827BA0D@telehouse.ch> Mirjam Kuehne wrote: > > Dear LIR-WG, > > Here is an attempt to summarise the recent discussions on this mailing > list regarding possible fixed size assignments. > > Following a review of the comments, it looks like the majority does > not believe that a special assignment policy is needed. Most > contributors agreed that there is no need to make a distinction in > policy relating to different access methods. All assignments should be > made on actual needs and according to the current IP address policies. > > The comments showed concerns about the administrative procedures > required for these kinds of assignments. However, it was felt that > these addresses need to be accounted for in some way. A possible way > forward would be to initiate discussion surrounding the set of > information necessary to justify these assignments while providing an > efficient way for the LIRs to provide services to their customers. How about some entries in the FAQ for these cases? Something along the lines I posted on Monday referring to similiar policies like dial-up and virtual webhosting. -- Andre > I realise that I did not touch on every aspect of the discussion but I > hope that this is a fair summary in order for you to move forward > Looking forward to a continuation of this debate. > > Best Regards, > Mirjam Kuehne > RIPE NCC From maldwyn at ripe.net Fri Feb 16 15:41:53 2001 From: maldwyn at ripe.net (Maldwyn Morris) Date: Fri, 16 Feb 2001 15:41:53 +0100 Subject: IP Management Tool - Minimum Requirements Message-ID: <200102161441.PAA18927@x40.ripe.net> Hi, Following a presentation of an IP Management Tool by Guy Vegoda at the last RIPE Meeting Tools BOF, interest was expressed in the development of an Open Source version of such a tool and I agreed to use the lirwg list to try and draw up Requirements for this. Hopefully this can be refined into something that we can then begin writing Specifications for. Please remember that these are *Requirements* - i.e. what the users want the tool to do. Please confine remarks to this area and avoid mixing in the *Specifications* - i.e. how those requirements will be met - which we will come to, in good time. It should also be emphasised that we would at this stage like to concentrate on _minimum_ requirements for a simple tool, such that it would be useful to a large number of LIRs. I think we can use these Minimum Requirements to produce something that may or may not include more advanced features as well, knowing that we would at least have covered the basic needs. Comments on this process and the document are most welcome, and we would also like a good name. Thanks to Guy Vegoda, Leo Vegoda and Nigel Titley for their help in drawing up this document, and especially to Guy for presenting his tool. Cheers, Maldwyn Morris Software Manager RIPE NCC -- Minimum Requirements for an IP Management Tool ---------------------------------------------- 0. Introduction Guy Vegoda presented an IP Management Tool at the Tools BOF at RIPE 38 [1]. This document is an attempt to specify the minimum requirements for a similar tool, with the aim of producing an Open Source version for anyone who wants to use it. Below, I address 1. General Points about the project, 2. The Requirements themselves, 3. External Constraint that must be considered, and 4. A list of References. 1. General Points Name: Let's use IPMT ( IP Management Tool ) as a placeholder for now. Users: We will target as users 'The Hostmaster staff of Local Internet Registries which are Customers of the RIPE NCC and who need to manage their IP Allocations and Assignments and the requests for same that they send to the RIPE NCC' [phew]. We will call one of these people a 'LIRHostmaster' and their organisation an 'LIR'. It may also be useful to other people in other organisations to do other things, but that will not influence the requirements. Open Source: We will release this software under the LGPL licence [2]. We use this instead of GPL [3] because this means we will remain able to using non-GPL'ed libraries, should that prove necessary. The RIPE NCC is happy to support this project, but of course its Open Source nature means anyone else can use the code to begin their own Open Source project. We are also happy about that. IPV6: We would be foolish not to consider the possibility of using this tool for managing IPV6 addresses and writing it such that this is possible, but we think it will be useful even if it does not and do not consider IPV6 support a requirement. 2. Requirements General functionality: IPMT should provide the LIRHostmasters with list, create, update, and delete access to information regarding their LIR's IPV4 allocations. These actions must be undoable where necessary. Basic validity checks will be performed on all input. IPMT should provide the LIRHostmasters with list, create, update, and delete access to information regarding their LIR's IPV4 assignments. These actions must be undoable where necessary. Basic validity checks will be performed on all input. IPMT should allow the LIRHostmasters to receive requests for IPV4 assignments from the customers of their LIR and allow them to process them. IPMT should allow LIRHostmasters to send well-formatted email requests for new IPv4 assignments to the RIPE NCC and allow the LIRHostmasters to receive and process responses from the RIPE NCC. IPMT should allow LIRHostmasters to send well-formatted email requests for new IPv4 allocations to the RIPE NCC and allow the LIRHostmasters to receive and process responses from the RIPE NCC. User Interface: LIRHostmasters should be able to conveniently access IPMT functions from a wide range of Desktop Operating Systems, possibly including non-modern, non-Unix-like ones. A GUI interface is the minimal acceptable convenience level. A less-convenient interface to IPMT for more complex functions and administration is acceptable. 3. External constraints The RIPE NCC only accepts requests for new IPv4 Assignments and Allocations via email to hostmaster at ripe.net and replies only via email [4]. IPV4 Assignment requests must be in RIPE 141 format [5]. Requests for new IPV4 Allocations have no special format. LIRHostmasters handle customer requests for Assignments via telephone, email and web pages. IPMT must have access to the RIPE DB [6] or a local mirror thereof. 4. References [1] http://www/ripe/meetings/archive/ripe-38/index.html [2] http://www.gnu.org/copyleft/lesser.html [3] http://www.gnu.org/copyleft/gpl.html [4] http://www.ripe.net/ripencc/mem-services/registration/status.html [5] http://www.ripe.net/ripe/docs/ripe-141.html [6] http://www.ripe.net/ripencc/pub-services/db/ From judithh at excitehome.net Sat Feb 17 07:53:55 2001 From: judithh at excitehome.net (Judith Heffernan) Date: Fri, 16 Feb 2001 22:53:55 -0800 Subject: Fixed Boundary (/29) Assignments Message-ID: <3A8E2003.16EA9D22@excitehome.net> As an employee of a large broadband provider, I agree with the recommendation of allowing ISPs the ability to provide residential subscribers multiple IP addresses without having the subscriber provide usage-based requirements. It doesn't scale to extend the rules that apply to commercial end users to residential subscribers. This would be equivalent to a tier 1 ISP having to manage the justification of IP address requests of 3million tier 2 ISPs. It doesn't scale. The subscriber should not just be assigned /29 worth of address space when they sign up for the service whether they need it or not. However, if the subscriber sign's up for the service requesting 2 or 3 CPE addresses, they shouldn't have to submit a RIPE-141 form or provide some other justification. It should simply be a service that the ISP can provide. We have many subscribers with multiple CPE addresses - however, that doesn't necessarily mean they have their own subnet. In a broadband cable environment, the subscribers off of the same downstream shares the same broadcast domain. The downstream is assign /24 which the subscribers are addressed out of. A subscriber with two CPE's may not have consecutive IP addresses. Would this mean the subscriber would have to register each /32? Or that the ISP has to ensure that the subscriber gets consecutive addresses (that would be a huge operational overhead for the ISP). The ISP should be responsible of ensuring the /24 is being effectively utilized. And this can be done the same way it is today for one CPE as it can for multiple. -Judith From SchmitzJo at aol.com Sat Feb 17 00:45:46 2001 From: SchmitzJo at aol.com (SchmitzJo at aol.com) Date: Fri, 16 Feb 2001 18:45:46 EST Subject: RIPE: last call for comments RPSL transition Message-ID: Hello all, as you are aware, we are preparing the migration of the RIPE database software to support and deploy the new RPSL format. The required steps have been discussed in depth on various occassions (for references, see end of mail). We are now preparing the most important step, really transitioning from old RIPE-181 to new RPSL format: proposed transition date is 23-Apr-2001. This step, once taken, will not be reversed. The majority of the user community takes a neutral role, while some want an earlier, and a few a later date for migration. During the joint session of Routing and DB WG at RIPE38, the chairmen of both WGs were tasked to file a last call for comments on that date, in particular whether there are serious, unresolvable technical or operational problems which would benefit from a slightly longer warning period. According to consensus at the session: If you are convinced that the transition date as proposed would lead to significant operational problems, please explain and justify why within the next 2 weeks: deadline for transition comments: 1-Mar-2001 Only well founded reasoning (including an educated guess about the time and resources required to resolve the issue) shall be accepted by the community in order to consider postponing the transition. With the discussion about the migration going on for quite some time, and information available from various places, we do not expect a delay, but we would want to give everybody a last opportunity to comment. To summarize the dates, we are looking at: o 23-Apr-2001: switching to the RPSL database - All objects are automatically converted to RPSL format - Queries return RPSL only - Mirroring follows new format and rules at whois.ripe.net, port 4444 - RPSL formatted updates can be submitted to auto-rpsl at ripe.net - RIPE-181 updates are still accepted at auto-dbm at ripe.net, but are autmatically converted to RPSL - RFC2725 (Routing Policy Security System) rules apply throughout o 14-May-2001: exchanging mail addresses for submitting RIPE181 and RPSL- formatted updates - auto-dbm at ripe.net only accepts RPSL updates - RIPE-181 updates are still possible but now go to auto-181 at ripe.net and are automatically converted to RPSL (again, RFC2725 rules apply here as well) o 15-Oct-2001: RIPE-181 updates are no longer accepted For further reading, please refer to the migration web page http://www.ripe.net/rpsl or for the discussion during the joint session of the DB/Routing WGs please review the minutes. For technical specifications of RPSL please refer to - rfc2622: "Routing Policy Specification Language (RPSL)" Status: PROPOSED STANDARD, - rfc2650: "Using RPSL in Practice" Status: INFORMATIONAL - rfc2725: "Routing Policy System Security" Status: PROPOSED STANDARD Thanks a lot - the RIPE NCC and the chairmen of Routing: Joachim Schmitz DB: Wilfried Woeber LIR: Hans Peter Holen From chris.luke at group.easynet.net Sun Feb 18 01:59:58 2001 From: chris.luke at group.easynet.net (Chris Luke) Date: Sun, 18 Feb 2001 00:59:58 +0000 Subject: Fixed Boundary (/29) Assignments In-Reply-To: <3A8E2003.16EA9D22@excitehome.net>; from judithh@excitehome.net on Fri, Feb 16, 2001 at 10:53:55PM -0800 References: <3A8E2003.16EA9D22@excitehome.net> Message-ID: <20010218005958.C40833@easynet.net> Judith Heffernan wrote (on Feb 17): > they shouldn't have to submit a RIPE-141 form or provide some > other justification. None of my customers fill in -141's. Just an order form with relevant questions. These get translated into a -141 "behind the scenes". This is no drama and ensures we get the right details for the -141. What's the problem here? Chris. -- == chris.luke at group.easynet.net T: +44 20 7900 4444 == Group Network Manager for Easynet Group PLC F: +44 845 333 0122 From guy at sirius-cybernetics-corporation.com Mon Feb 26 12:50:36 2001 From: guy at sirius-cybernetics-corporation.com (Guy Vegoda) Date: Mon, 26 Feb 2001 11:50:36 +0000 Subject: IP Management Tool - Minimum Requirements In-Reply-To: <200102161441.PAA18927@x40.ripe.net>; from maldwyn@ripe.net on Fri, Feb 16, 2001 at 03:41:53PM +0100 References: <200102161441.PAA18927@x40.ripe.net> Message-ID: <20010226115036.A25127@sirius-cybernetics-corporation.com> Other than adding that it should be useable simulteniously by multiple users without data corruption, shall I go away and write it now? Guy (Since no one else seems interested) > Hi, > > Following a presentation of an IP Management Tool by Guy Vegoda at the > last RIPE Meeting Tools BOF, interest was expressed in the development > of an Open Source version of such a tool and I agreed to use the lirwg > list to try and draw up Requirements for this. Hopefully this can be > refined into something that we can then begin writing Specifications > for. > > Please remember that these are *Requirements* - i.e. what the users > want the tool to do. Please confine remarks to this area and avoid > mixing in the *Specifications* - i.e. how those requirements will be > met - which we will come to, in good time. > > It should also be emphasised that we would at this stage like to > concentrate on _minimum_ requirements for a simple tool, such that it > would be useful to a large number of LIRs. I think we can use these > Minimum Requirements to produce something that may or may not include > more advanced features as well, knowing that we would at least have > covered the basic needs. > > Comments on this process and the document are most welcome, and > we would also like a good name. > > Thanks to Guy Vegoda, Leo Vegoda and Nigel Titley for their help in > drawing up this document, and especially to Guy for presenting his > tool. > > Cheers, > > Maldwyn Morris > Software Manager > RIPE NCC > > -- > > Minimum Requirements for an IP Management Tool > ---------------------------------------------- > > 0. Introduction > > Guy Vegoda presented an IP Management Tool at the Tools BOF at RIPE 38 > [1]. This document is an attempt to specify the minimum requirements > for a similar tool, with the aim of producing an Open Source version > for anyone who wants to use it. > > Below, I address 1. General Points about the project, 2. The > Requirements themselves, 3. External Constraint that must be > considered, and 4. A list of References. > > > 1. General Points > > Name: > > Let's use IPMT ( IP Management Tool ) as a placeholder for now. > > Users: > > We will target as users 'The Hostmaster staff of Local Internet > Registries which are Customers of the RIPE NCC and who need to manage > their IP Allocations and Assignments and the requests for same that > they send to the RIPE NCC' [phew]. We will call one of these people a > 'LIRHostmaster' and their organisation an 'LIR'. It may also be > useful to other people in other organisations to do other things, but > that will not influence the requirements. > > Open Source: > > We will release this software under the LGPL licence [2]. > We use this instead of GPL [3] because this means we will remain able > to using non-GPL'ed libraries, should that prove necessary. > > The RIPE NCC is happy to support this project, but of course its Open > Source nature means anyone else can use the code to begin their own > Open Source project. We are also happy about that. > > IPV6: > > We would be foolish not to consider the possibility of using this tool > for managing IPV6 addresses and writing it such that this is possible, > but we think it will be useful even if it does not and do not consider > IPV6 support a requirement. > > > 2. Requirements > > General functionality: > > IPMT should provide the LIRHostmasters with list, create, update, and > delete access to information regarding their LIR's IPV4 allocations. > These actions must be undoable where necessary. > Basic validity checks will be performed on all input. > > IPMT should provide the LIRHostmasters with list, create, update, and > delete access to information regarding their LIR's IPV4 assignments. > These actions must be undoable where necessary. > Basic validity checks will be performed on all input. > > IPMT should allow the LIRHostmasters to receive requests for IPV4 > assignments from the customers of their LIR and allow them to process > them. > > IPMT should allow LIRHostmasters to send well-formatted email requests > for new IPv4 assignments to the RIPE NCC and allow the LIRHostmasters > to receive and process responses from the RIPE NCC. > > IPMT should allow LIRHostmasters to send well-formatted email requests > for new IPv4 allocations to the RIPE NCC and allow the LIRHostmasters > to receive and process responses from the RIPE NCC. > > User Interface: > > LIRHostmasters should be able to conveniently access IPMT functions > from a wide range of Desktop Operating Systems, possibly including > non-modern, non-Unix-like ones. A GUI interface is the minimal > acceptable convenience level. > > A less-convenient interface to IPMT for more complex functions and > administration is acceptable. > > > 3. External constraints > > The RIPE NCC only accepts requests for new IPv4 Assignments and > Allocations via email to hostmaster at ripe.net and replies only via > email [4]. > > IPV4 Assignment requests must be in RIPE 141 format [5]. > Requests for new IPV4 Allocations have no special format. > > LIRHostmasters handle customer requests for Assignments via telephone, > email and web pages. > > IPMT must have access to the RIPE DB [6] or a local mirror thereof. > > > 4. References > > [1] http://www/ripe/meetings/archive/ripe-38/index.html > [2] http://www.gnu.org/copyleft/lesser.html > [3] http://www.gnu.org/copyleft/gpl.html > [4] http://www.ripe.net/ripencc/mem-services/registration/status.html > [5] http://www.ripe.net/ripe/docs/ripe-141.html > [6] http://www.ripe.net/ripencc/pub-services/db/ > > -- Guy Vegoda \ guy at vegoda.org *Please do not send html* NIC: GUY-RIPE \ guy at cryptography.org.uk *attachments* Unix, Linux Hobbyist \ +44(0)20 7961 8318 (work) www.thenakedfrenchman.com \ +44(0)958 469 532 (cell) From arif.oktay at telekom.gov.tr Mon Feb 26 15:14:27 2001 From: arif.oktay at telekom.gov.tr (Arif OKTAY) Date: Mon, 26 Feb 2001 16:14:27 +0200 Subject: IP Management Tool - Minimum Requirements Message-ID: Hi all, I was thinking whether it may be possible -usefull ?- to add some criteria for how succesfull the adress space managed. Regards, arif ao189-ripe -----Original Message----- From: Guy Vegoda To: lir-wg at ripe.net Sent: 2/26/01 1:50 PM Subject: Re: IP Management Tool - Minimum Requirements Other than adding that it should be useable simulteniously by multiple users without data corruption, shall I go away and write it now? Guy (Since no one else seems interested) > Hi, > > Following a presentation of an IP Management Tool by Guy Vegoda at the > last RIPE Meeting Tools BOF, interest was expressed in the development > of an Open Source version of such a tool and I agreed to use the lirwg > list to try and draw up Requirements for this. Hopefully this can be > refined into something that we can then begin writing Specifications > for. > > Please remember that these are *Requirements* - i.e. what the users > want the tool to do. Please confine remarks to this area and avoid > mixing in the *Specifications* - i.e. how those requirements will be > met - which we will come to, in good time. > > It should also be emphasised that we would at this stage like to > concentrate on _minimum_ requirements for a simple tool, such that it > would be useful to a large number of LIRs. I think we can use these > Minimum Requirements to produce something that may or may not include > more advanced features as well, knowing that we would at least have > covered the basic needs. > > Comments on this process and the document are most welcome, and > we would also like a good name. > > Thanks to Guy Vegoda, Leo Vegoda and Nigel Titley for their help in > drawing up this document, and especially to Guy for presenting his > tool. > > Cheers, > > Maldwyn Morris > Software Manager > RIPE NCC > > -- > > Minimum Requirements for an IP Management Tool > ---------------------------------------------- > > 0. Introduction > > Guy Vegoda presented an IP Management Tool at the Tools BOF at RIPE 38 > [1]. This document is an attempt to specify the minimum requirements > for a similar tool, with the aim of producing an Open Source version > for anyone who wants to use it. > > Below, I address 1. General Points about the project, 2. The > Requirements themselves, 3. External Constraint that must be > considered, and 4. A list of References. > > > 1. General Points > > Name: > > Let's use IPMT ( IP Management Tool ) as a placeholder for now. > > Users: > > We will target as users 'The Hostmaster staff of Local Internet > Registries which are Customers of the RIPE NCC and who need to manage > their IP Allocations and Assignments and the requests for same that > they send to the RIPE NCC' [phew]. We will call one of these people a > 'LIRHostmaster' and their organisation an 'LIR'. It may also be > useful to other people in other organisations to do other things, but > that will not influence the requirements. > > Open Source: > > We will release this software under the LGPL licence [2]. > We use this instead of GPL [3] because this means we will remain able > to using non-GPL'ed libraries, should that prove necessary. > > The RIPE NCC is happy to support this project, but of course its Open > Source nature means anyone else can use the code to begin their own > Open Source project. We are also happy about that. > > IPV6: > > We would be foolish not to consider the possibility of using this tool > for managing IPV6 addresses and writing it such that this is possible, > but we think it will be useful even if it does not and do not consider > IPV6 support a requirement. > > > 2. Requirements > > General functionality: > > IPMT should provide the LIRHostmasters with list, create, update, and > delete access to information regarding their LIR's IPV4 allocations. > These actions must be undoable where necessary. > Basic validity checks will be performed on all input. > > IPMT should provide the LIRHostmasters with list, create, update, and > delete access to information regarding their LIR's IPV4 assignments. > These actions must be undoable where necessary. > Basic validity checks will be performed on all input. > > IPMT should allow the LIRHostmasters to receive requests for IPV4 > assignments from the customers of their LIR and allow them to process > them. > > IPMT should allow LIRHostmasters to send well-formatted email requests > for new IPv4 assignments to the RIPE NCC and allow the LIRHostmasters > to receive and process responses from the RIPE NCC. > > IPMT should allow LIRHostmasters to send well-formatted email requests > for new IPv4 allocations to the RIPE NCC and allow the LIRHostmasters > to receive and process responses from the RIPE NCC. > > User Interface: > > LIRHostmasters should be able to conveniently access IPMT functions > from a wide range of Desktop Operating Systems, possibly including > non-modern, non-Unix-like ones. A GUI interface is the minimal > acceptable convenience level. > > A less-convenient interface to IPMT for more complex functions and > administration is acceptable. > > > 3. External constraints > > The RIPE NCC only accepts requests for new IPv4 Assignments and > Allocations via email to hostmaster at ripe.net and replies only via > email [4]. > > IPV4 Assignment requests must be in RIPE 141 format [5]. > Requests for new IPV4 Allocations have no special format. > > LIRHostmasters handle customer requests for Assignments via telephone, > email and web pages. > > IPMT must have access to the RIPE DB [6] or a local mirror thereof. > > > 4. References > > [1] http://www/ripe/meetings/archive/ripe-38/index.html > [2] http://www.gnu.org/copyleft/lesser.html > [3] http://www.gnu.org/copyleft/gpl.html > [4] http://www.ripe.net/ripencc/mem-services/registration/status.html > [5] http://www.ripe.net/ripe/docs/ripe-141.html > [6] http://www.ripe.net/ripencc/pub-services/db/ > > -- Guy Vegoda \ guy at vegoda.org *Please do not send html* NIC: GUY-RIPE \ guy at cryptography.org.uk *attachments* Unix, Linux Hobbyist \ +44(0)20 7961 8318 (work) www.thenakedfrenchman.com \ +44(0)958 469 532 (cell) From heidrich at heidrich.hu Mon Feb 26 14:53:15 2001 From: heidrich at heidrich.hu (Heidrich Attila) Date: Mon, 26 Feb 2001 13:53:15 +0000 Subject: IP Management Tool - Minimum Requirements References: <200102161441.PAA18927@x40.ripe.net> <20010226115036.A25127@sirius-cybernetics-corporation.com> Message-ID: <3A9A5FCB.59DDF330@heidrich.hu> Guy Vegoda wrote: > > Other than adding that it should be useable > simulteniously by multiple users without data > corruption, shall I go away and write it now? > > Guy > > (Since no one else seems interested) Well... I have one tool like this... This is in PostgreSQL, and RoxenWebservers pike and XML extensions. It is let's say half way to go. We have been using it since november 2000. It do handle transactions, and many database definition is written in PL/PgSQL and stored in the database. If anyone is interested, I create a new empty database and put it on my webserver for tests, and maybe further developement... Attila -- ( Y ) (o-o) http://heidrich.hu (")_(")o attila at heidrich.hu X-NCC-RegID: hu.deltav From guy at sirius-cybernetics-corporation.com Mon Feb 26 16:05:43 2001 From: guy at sirius-cybernetics-corporation.com (Guy Vegoda) Date: Mon, 26 Feb 2001 15:05:43 +0000 Subject: IP Management Tool - Minimum Requirements In-Reply-To: ; from arif.oktay@telekom.gov.tr on Mon, Feb 26, 2001 at 04:14:27PM +0200 References: Message-ID: <20010226150543.C25497@sirius-cybernetics-corporation.com> > Hi all, > > I was thinking whether it may be possible -usefull ?- to add some > criteria for how succesfull the adress space managed. > I am not sure I know what you mean by how successful... Let's define some metrics. Guy -- Guy Vegoda \ guy at vegoda.org *Please do not send html* NIC: GUY-RIPE \ guy at cryptography.org.uk *attachments* Unix, Linux Hobbyist \ +44(0)20 7961 8318 (work) www.thenakedfrenchman.com \ +44(0)958 469 532 (cell) From guy at sirius-cybernetics-corporation.com Mon Feb 26 17:39:55 2001 From: guy at sirius-cybernetics-corporation.com (Guy Vegoda) Date: Mon, 26 Feb 2001 16:39:55 +0000 Subject: IPv6 representation in perl Message-ID: <20010226163955.B55934@sirius-cybernetics-corporation.com> On an entirely different point, I would like to start a separate thread about the best way to represent IPv6 numbers in Perl. I have the following thoughts. Possible ways may be: (1) Using a 128 element binary array, and writing all the binary maths yourself to manipulate that. (2) Using a 4 element array storing four hex characters from 0 to F. Probably far slower than the above method, but smaller for storing many IPs. I know that Perl can natively think in hex, so maybe it would be faster than I think. (3) Having a complex structure, where the IP number is stored in parts - the top /48 (in any of several formats), with variable structure subnets underneath that. Could be tricky for the maths, if the variable bits are badly thought out. (4) Storing four "IPv4-esque" decimal strings in an array, or as part of an object. Then do the maths on each of those separately. Probably fast. (5) Storing a single parant /48 object (in any format) and have child objects with only the bottom parts of the IP to worry about. I wonder how that would work. -------- When I have gone away and read more of Mastering Algorithms with Perl, I will come back and maybe make some more comments. Just as a disclaimer - I am in no way making any comments on Manuel's already excellent libraries. I have already spoken to him about them, and would not want to appear to "go behind his back". This is an entirely intellectual exercise only. In fact, I would very much like to see Manuel post his own thoughts and real world experiences on the subject (of which I have none). I wish every one well, Guy -- Guy Vegoda \ guy at vegoda.org *Please do not send html* NIC: GUY-RIPE \ guy at cryptography.org.uk *attachments* Unix, Linux Hobbyist \ +44(0)20 7961 8318 (work) www.thenakedfrenchman.com \ +44(0)958 469 532 (cell) From guy at sirius-cybernetics-corporation.com Mon Feb 26 17:19:51 2001 From: guy at sirius-cybernetics-corporation.com ('guy@sirius-cybernetics-corporation.com') Date: Mon, 26 Feb 2001 16:19:51 +0000 Subject: IP Management Tool - Minimum Requirements In-Reply-To: ; from arif.oktay@telekom.gov.tr on Mon, Feb 26, 2001 at 06:06:20PM +0200 References: Message-ID: <20010226161951.C44278@sirius-cybernetics-corporation.com> > Yes I know about asused. It is a good tool for determining overlap > status or some missing attributes/contact informations and to get some > statistical information. I think it will be usefull to access asused from > IPMT. But my main concern was also whether we can find such a > criteria/metric that can be used both RIR's and LIR's ? Here are some > metrics I have thought; > > - Possible largest allocation left in the totall allocation of LIR > - How fragmented the allocation space (may be mapped to above one) > - How summarizable are the address space assigned to a customer. > - How summarizable are total allocations ? > > > Summarizability issues seem to conflict with RIR policies. However > I think that it is a fact of routing world. > > Regards > arif I do not think there is anything wrong with detailed reporting. I think that maybe the program needs a specification before we can really use metrics to measure anything. I too would like to see IPMT eventually give verbose output on the state of the registry. However, will this not to some extent duplicate functionality of programs such as asused-public that already exist? Please clarify what you would like, because I think I am still confused. I think that Maldwyn's comments would be useful here. Guy -- Guy Vegoda \ guy at vegoda.org *Please do not send html* NIC: GUY-RIPE \ guy at cryptography.org.uk *attachments* Unix, Linux Hobbyist \ +44(0)20 7961 8318 (work) www.thenakedfrenchman.com \ +44(0)958 469 532 (cell) From guy at sirius-cybernetics-corporation.com Mon Feb 26 17:26:25 2001 From: guy at sirius-cybernetics-corporation.com (Guy Vegoda) Date: Mon, 26 Feb 2001 16:26:25 +0000 Subject: IP Management Tool - Minimum Requirements In-Reply-To: <20010226161554.A2140@enigma.ie>; from niallm-ripe@enigma.ie on Mon, Feb 26, 2001 at 04:15:54PM +0000 References: <200102161441.PAA18927@x40.ripe.net> <20010226115036.A25127@sirius-cybernetics-corporation.com> <20010226161554.A2140@enigma.ie> Message-ID: <20010226162625.A55934@sirius-cybernetics-corporation.com> > Would there not be intellectual property difficulties if you > wrote a similar system for another company? > > Niall > > (Interested but also enmeshed in IP problems) I guess that depends on how similar you mean by similar (-: I don't think IPMT will be anything like Robo-Bijal, code-wise. (Not least because: (1) I will not be the only coder, (2) Manuel's IP libraries are open source, (3) It will probably support IPv6, which Robo-Bijal doesn't, and (4) I would like to do it in OO perl. ) So should hopefully all work out. Guy -- Guy Vegoda \ guy at vegoda.org *Please do not send html* NIC: GUY-RIPE \ guy at cryptography.org.uk *attachments* Unix, Linux Hobbyist \ +44(0)20 7961 8318 (work) www.thenakedfrenchman.com \ +44(0)958 469 532 (cell) From herbert.baerten at hostit.be Tue Feb 27 10:27:41 2001 From: herbert.baerten at hostit.be (Herbert Baerten) Date: Tue, 27 Feb 2001 10:27:41 +0100 Subject: Refuse een assignment because it 'cannot' be routed? Message-ID: Dear colleagues, in the discussion about assigning fixed address space to residential always-on customers, I concluded that most ISPs are eager to provide their customers with this service, even using it as a weapon in the competition battle. However in some countries apparently the contrary is going on. All ISPs there offer 2 classes of DSL service: cheap subscriptions (low traffic, dynamic ip, no options) on one hand and an expensive 'pro' contract (high traffic volume, static ip, router etc.) on the other. Now a customer would like to get a static ip but does not want the router, large volume etc so he does not want to pay 4 times as much per month (real-life example) just to get a static ip. If the customers sends a RIPE-141 request to the ISP, can the ISP assign a range but not route it to the customer? Can it refuse the request on the grounds that it cannot route the assigned range to a dynamic ip? Or is the ISP obliged to assign a range and route it (no matter how, presumably by assigning the customer a static ip anyway) ? With or without additional (reasonable?) cost to the customer? tia best regards, Herbert -- HB5351 Herbert Baerten Network Manager HostIT Benelux From beri at kpnqwest.net Tue Feb 27 12:40:35 2001 From: beri at kpnqwest.net (Berislav Todorovic) Date: Tue, 27 Feb 2001 12:40:35 +0100 (CET) Subject: Refuse een assignment because it 'cannot' be routed? In-Reply-To: Message-ID: On Tue, 27 Feb 2001, Herbert Baerten wrote: >> Now a customer would like to get a static ip but does not want the router, >> large volume etc so he does not want to pay 4 times as much per month >> (real-life example) just to get a static ip. ONE static IP address? PA, I assume? >> If the customers sends a RIPE-141 request to the ISP, can the ISP assign a >> range but not route it to the customer? ... which would be extremely useful for ??? >> Can it refuse the request on the grounds that it cannot route the assigned >> range to a dynamic ip? ... so, you want to rent a house and put a security guard on the entrance door not allowing people who bought it to move in. Interesting ... >> Or is the ISP obliged to assign a range and route it (no matter how, >> presumably by assigning the customer a static ip anyway) ? With or without >> additional (reasonable?) cost to the customer? Well, there is no formal policy obligation for you to route the addresses you assigned, but what would those addresses then be good for? Regards, Beri --------- Berislav Todorovic, Network Engineer --------- ------- KPNQwest N.V. - IP NOC (formerly EUnet NOC) ------- ---- Wilhelmina van Pruisenweg 78, 2595 AN Den Haag, NL ---- --- Phone: +31-70-379-3990; Mobile: +31-651-333-641 --- -- Email: beri at kpnqwest.net <=> beri at EU.net -- --- _ _ ____ _ .--. ____ ____ __/_ --- ----- /__/ /___/ /\ / / / | / /___/ /___ / ------ ------ _/ \_ / _/ \/ (__.\ |/\/ /___ ____/ (__. ----- From afrench at vianetworks.com Mon Feb 26 17:45:24 2001 From: afrench at vianetworks.com (Alex French) Date: Mon, 26 Feb 2001 16:45:24 +0000 Subject: IPv6 representation in perl In-Reply-To: <20010226163955.B55934@sirius-cybernetics-corporation.com> Message-ID: <5.0.2.1.0.20010226164458.0307ae38@192.168.200.10> At 16:39 26/02/2001, Guy Vegoda wrote: >On an entirely different point, I would like to >start a separate thread about the best way to >represent IPv6 numbers in Perl. > I know there is a module that does this, Net::IP perhaps? -- Alex French Product Architect E: afrench at vianetworks.com VIA NET.WORKS, Inc. T: +353 (86) 818 8118 12100 Sunset Hills Rd, Reston VA 20190 F: +353 (865) 818 8118 From herbert.baerten at hostit.be Tue Feb 27 14:40:22 2001 From: herbert.baerten at hostit.be (Herbert Baerten) Date: Tue, 27 Feb 2001 14:40:22 +0100 Subject: Refuse een assignment because it 'cannot' be routed? In-Reply-To: Message-ID: > >> Now a customer would like to get a static ip but does not want > ONE static IP address? PA, I assume? Yes, PA. > >> If the customers sends a RIPE-141 request to the ISP, can the > ISP assign a > >> range but not route it to the customer? > > ... which would be extremely useful for ??? In order to force the customer to buy a more expensive service which includes fixed ip! Please understand that nor I nor my employer is doing this or even advocating this practice. To the contrary: I'm just observing that it happens and am so displeased about this that I am looking for ways to counter it. > >> Can it refuse the request on the grounds that it cannot route > the assigned > >> range to a dynamic ip? > > ... so, you want to rent a house and put a security guard on the entrance > door not allowing people who bought it to move in. Interesting ... I think it is more appropriate to state that someone is looking for a house but all landlords he meets will move his front door every day unless he pays tripple rent. I suppose the question can be phrased more theoretically as: "If a LIR is obliged to assign address space (is it?), wouldn't it make sense to oblige a provider to route it" or the other way'round: "If an address space request is made, is the non-willingness of an ISP to route it sufficient grounds to deny the request?" > Well, there is no formal policy obligation for you to route the addresses > you assigned, but what would those addresses then be good for? That's the point. Can the customer somehow (e.g. by submitting a ripe-141) force the ISP to assign him a static ip address? Or will it get him nowhere? BTW, you seem to assume that I represent the ISP, not the customer. Perhaps I should have added that I posed this question partly out of practical personal interest as a home user interested in ADSL, and partly out of theoretical professional interest as an employee at a LIR. So I tried to state the case in an objective fashion :) regards, Herbert From marcel at eu.uu.net Tue Feb 27 17:23:48 2001 From: marcel at eu.uu.net (Anne Marcel Roorda) Date: Tue, 27 Feb 2001 16:23:48 +0000 Subject: Refuse een assignment because it 'cannot' be routed? In-Reply-To: Your message of "Tue, 27 Feb 2001 14:40:22 +0100." Message-ID: > > >> Now a customer would like to get a static ip but does not want > > ONE static IP address? PA, I assume? > > Yes, PA. > > > > >> If the customers sends a RIPE-141 request to the ISP, can the > > ISP assign a > > >> range but not route it to the customer? > > > > ... which would be extremely useful for ??? > > In order to force the customer to buy a more expensive service which > includes fixed ip! > Please understand that nor I nor my employer is doing this or even > advocating this practice. To the contrary: I'm just observing that it > happens and am so displeased about this that I am looking for ways to > counter it. > > > > >> Can it refuse the request on the grounds that it cannot route > > the assigned > > >> range to a dynamic ip? > > > > ... so, you want to rent a house and put a security guard on the entrance > > door not allowing people who bought it to move in. Interesting ... > > I think it is more appropriate to state that someone is looking for a house > but all landlords he meets will move his front door every day unless he pays > tripple rent. > > I suppose the question can be phrased more theoretically as: > > "If a LIR is obliged to assign address space (is it?), wouldn't it make > sense to oblige a provider to route it" > > or the other way'round: > > "If an address space request is made, is the non-willingness of an ISP to > route it sufficient grounds to deny the request?" > > > > Well, there is no formal policy obligation for you to route the addresses > > you assigned, but what would those addresses then be good for? > > That's the point. Can the customer somehow (e.g. by submitting a ripe-141) > force the ISP to assign him a static ip address? Or will it get him nowhere? > Hi, This is a very interesting problem. As far as I am aware there is no obligation to assign IP space when someone becomes a customer of an entity served by a LIR. Possible problems when submitting a RIPE-141 document: - There is no obligation to process the request - The LIR may charge for processing the request - The LIR may charge for the assignment - The provider may charge for the routing You could opt to ask RIPE for a PI allocation, but noone is required to route it for you. Regards, - marcel From woeber at cc.univie.ac.at Tue Feb 27 17:57:27 2001 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 27 Feb 2001 17:57:27 +0100 Subject: Refuse een assignment because it 'cannot' be routed? Message-ID: <009F846F.35C18EBE.25@cc.univie.ac.at> > > >> Now a customer would like to get a static ip but does not want > > ONE static IP address? PA, I assume? > > Yes, PA. > > > > >> If the customers sends a RIPE-141 request to the ISP, can the > > ISP assign a > > >> range but not route it to the customer? I guess, formally, the answer is YES. Because when the customer can document his/her need, then the LIR *may* assign addresses But, holding a block of addresses does not in any way "guarantee" connectivity... > > > > ... which would be extremely useful for ??? routing can be very different things: - distribute the announcement for that address space only within the ISPs IGP - distribute the announcement to direct EGP peers, but with "no-propagate", i.e. for providing access to a particaular server, or to suppoort dual-homing/mutual backup - make the address block (potentially) visible from "everywhere", by announcing the encopmpassing aggregate and/or the particular (more specific) prefix. The usefulness is subject to effects of aggregation and filtering - ... > In order to force the customer to buy a more expensive service which > includes fixed ip! Formally, definition of prodcut packages and charging for services is outside the scope of the rules for address assignment - with the exception that the address space itself must not be sold. > Please understand that nor I nor my employer is doing this or even > advocating this practice. To the contrary: I'm just observing that it > happens and am so displeased about this that I am looking for ways to > counter it. As I said in a different thread, this should be discussed in the frame-work of a BCP, either within RIPE or somewhere else. We might also want to leave it to competition to eventually deal with that (don't hold your breath ;-) > > >> Can it refuse the request on the grounds that it cannot route > > the assigned > > >> range to a dynamic ip? > > > > ... so, you want to rent a house and put a security guard on the entrance > > door not allowing people who bought it to move in. Interesting ... > > I think it is more appropriate to state that someone is looking for a house > but all landlords he meets will move his front door every day unless he pays > tripple rent. > > I suppose the question can be phrased more theoretically as: > > "If a LIR is obliged to assign address space (is it?), No, it is not. An IPS's LIR may have very good reasons (financial, security, AUP...) *not* to assign addresses to an entity wanting to become connected and obtain services, and even become a customer :-) > wouldn't it make > sense to oblige a provider to route it" No. That's what contracts are invented for, either implicitely by subscribing to a service or explicitely by negotiating ToS/QoS. > or the other way'round: > > "If an address space request is made, is the non-willingness of an ISP to > route it sufficient grounds to deny the request?" I think so. Unless there are other valid reasons for an LIR to perform an address assignment for a customer or peer (i.e. PI space, that is *not* accepted by the IPSs routing layer, but may be used on other links of the customer). > > Well, there is no formal policy obligation for you to route the addresses > > you assigned, but what would those addresses then be good for? > > That's the point. Can the customer somehow (e.g. by submitting a ripe-141) > force the ISP to assign him a static ip address? Or will it get him nowhere? It depends what the definition of "customer" looks like in that case. When the ISP does offer a package that includes the privilege to obtain service from the ISP's LIR, then the customer can probably (try to) use force (legal measures or refusing to pay fees). Trying to throw a 141 form at some free dial-in service provider would probably "get you nowhere" :-) But in general I would try to find a different ISP... ______________________________________________________________________ =Hi, = = This is a very interesting problem. = = As far as I am aware there is no obligation to assign IP space =when someone becomes a customer of an entity served by a LIR. Again, I share this view. = Possible problems when submitting a RIPE-141 document: = =- There is no obligation to process the request True =- The LIR may charge for processing the request True =- The LIR may charge for the assignment Not really. This is seen as "selling" addresses! =- The provider may charge for the routing True = You could opt to ask RIPE for a PI allocation, You could find an LIR that is willing to process PI requests, either for a charge or for free, or you can build your own LIR ;-) =but noone is required to route it for you. True, and for both, PI *and* PA =Regards, = =- marcel Regards, Wilfried. From hph at online.no Tue Feb 27 19:52:50 2001 From: hph at online.no (Hans Petter Holen) Date: Tue, 27 Feb 2001 19:52:50 +0100 Subject: Refuse een assignment because it 'cannot' be routed? References: Message-ID: <001b01c0a0ee$7e547a20$0a00000a@hph> > I think it is more appropriate to state that someone is looking for a house > but all landlords he meets will move his front door every day unless he pays > tripple rent. My analogy would be that unless you pay tripple rent you are not allowed to sub-let (connect more PCs with official addresses, atough you could always get married (NAT)) or start a small shop in your garage (put up a Warez sorry Web server) Moving from a volume charge service (dialup) to a fixed fee service (DSL) I do not find it that unreasonable to in some way limit the amout of Internet you can consume. > "If a LIR is obliged to assign address space (is it?), I don't think so. > wouldn't it make sense to oblige a provider to route it" I have always assumed that IP addresses is a comodity ISPs hand out with their services. If you buy service from an ISP then you get a reasonable number of IP addresses to use that service. If you buy a singe-user service, you get 1 IP address, if you buy a LAN service you get several addresses. > or the other way'round: > > "If an address space request is made, is the non-willingness of an ISP to > route it sufficient grounds to deny the request?" If you don't buy the right kind of service from me, I am not going to acknowledge your IP address request. > That's the point. Can the customer somehow (e.g. by submitting a ripe-141) > force the ISP to assign him a static ip address? Or will it get him nowhere? In my opinion: Hardy. The ISP may then loose the customer of course bu that that is a comercial desicion. But Hey, I would love to buy a high speed domestic internet connection with some IP addresses to connect my computers, but unfortunately nobody is willing to offer me that yet. -hph From ripe-mail-list at seven.it Wed Feb 28 08:31:24 2001 From: ripe-mail-list at seven.it (Roberto Pezzile) Date: Wed, 28 Feb 2001 08:31:24 +0100 Subject: LIR Charging Publications Message-ID: Hello to all colleagues, I am Roberto Pezzile, network and telecommunications manager of Seven, in Castelfranco Veneto, Italy. We have recently become a new LIR. In the documentation given, I have a few questions regarding the publication of "Charging by Local Internet Registries" - precisely, ripe-152.txt; where "5. Recommendations" urges all registries to publish operating procedures, service details,and relative charges. In my working experience, mostly in Italy, but occasionally in the US, Brasil, Germany, France and China, I have never seen such Charging Information published at all, by anyone. Perhaps I've missed something somewhere. Even reference documents ripe-104 and ripe-112 did not offer additional information . I would like to know: 1. Is there a form to fill out and send to RIPE for eventual publication ? 2. Is there another LIR in our area which can show us an example of their charging policies and procedures ? 3. What is intended by ".....achieving consensus within the community served regarding the disposal of any surplus revenues"? I look forward to receiving information on the above, based on the practical working experiences of those kind enough to give me a hand. Thankyou very much Roberto From marcel at eu.uu.net Tue Feb 27 19:35:19 2001 From: marcel at eu.uu.net (Anne Marcel Roorda) Date: Tue, 27 Feb 2001 18:35:19 +0000 Subject: Refuse een assignment because it 'cannot' be routed? In-Reply-To: Your message of "Tue, 27 Feb 2001 17:57:27 +0100." <009F846F.35C18EBE.25@cc.univie.ac.at> Message-ID: > =Hi, > = > = This is a very interesting problem. = > = As far as I am aware there is no obligation to assign IP space > =when someone becomes a customer of an entity served by a LIR. > > Again, I share this view. > > = Possible problems when submitting a RIPE-141 document: > = > =- There is no obligation to process the request > > True > > =- The LIR may charge for processing the request > > True > > =- The LIR may charge for the assignment > > Not really. This is seen as "selling" addresses! Hi, I'm not to sure about that. IIRC the LIR may charge a nominal fee for administrivia. This fee can be recurring. > > =- The provider may charge for the routing > > True > > = You could opt to ask RIPE for a PI allocation, > > You could find an LIR that is willing to process PI requests, > either for a charge or for free, or you can build your own LIR ;-) > > =but noone is required to route it for you. > > True, and for both, PI *and* PA Getting an assignment from a LIR is usually coupled to the routability of that assignment. I'd be mildly surprised to find assigned PA address space for which no intention of routing existed. Regards, - marcel From herbert.baerten at hostit.be Wed Feb 28 10:41:40 2001 From: herbert.baerten at hostit.be (Herbert Baerten) Date: Wed, 28 Feb 2001 10:41:40 +0100 Subject: Refuse een assignment because it 'cannot' be routed? In-Reply-To: <001b01c0a0ee$7e547a20$0a00000a@hph> Message-ID: > My analogy would be that unless you pay tripple rent you are not allowed > to sub-let (connect more PCs with official addresses, atough you could > always > get married (NAT)) or start a small shop in your garage (put up a Warez > sorry > Web server) No! no! no! :) I only want a fixed frontdoor (1 fixed IP address), but I am trying to force my landlord into letting me have it without paying tripple rent, by asking the government (RIPE) to give me a building permission to install more doors. Not because I want more doors, but to keep the landlord from moving my single door every day :) > Moving from a volume charge service (dialup) to a fixed fee service (DSL) > I do not find it that unreasonable to in some way limit the amout of > Internet > you can consume. I agree totally, but that is not my point. The point is that currently among all ADSL providers in my area, I can only choose between - package A: 1 dynamic IP, 1 or 10 GB traffic/month, no servers etc. and - package B: 1 static IP, 25 GB traffic/month or more, guaranteed minimum speed, web/mail server allowed, router+webspace+mailboxes included etc. Package A is fine for me, except the dynamic IP. I do not want to run servers or connect multiple computers (unless by using NAT). I want to connect through a firewall that only allows connections based on source IP address. > I have always assumed that IP addresses is a comodity ISPs hand out with > their services. If you buy service from an ISP then you get a reasonable > number > of IP addresses to use that service. If you buy a singe-user service, you > get > 1 IP address, if you buy a LAN service you get several addresses. Again I totally agree, but this is not the case in my area, imho. > If you don't buy the right kind of service from me, I am not going to > acknowledge > your IP address request. I am indeed afraid that this will be the ISPs' opinions, so I (sorry: the customer :)) guess threatening to go to the competition is the only way. But if there is no competitor offering what the customer wants, it's going to be a meaningless threat... thanks for your opinions, Herbert From marcel at eu.uu.net Wed Feb 28 12:34:34 2001 From: marcel at eu.uu.net (Anne Marcel Roorda) Date: Wed, 28 Feb 2001 11:34:34 +0000 Subject: Refuse een assignment because it 'cannot' be routed? In-Reply-To: Your message of "Wed, 28 Feb 2001 10:41:40 +0100." Message-ID: > > My analogy would be that unless you pay tripple rent you are not allowed > > to sub-let (connect more PCs with official addresses, atough you could > > always > > get married (NAT)) or start a small shop in your garage (put up a Warez > > sorry > > Web server) > > No! no! no! :) > I only want a fixed frontdoor (1 fixed IP address), but I am trying to force > my landlord into letting me have it without paying tripple rent, by asking > the government (RIPE) to give me a building permission to install more > doors. Not because I want more doors, but to keep the landlord from moving > my single door every day :) > Hi, Hmm... this analogy isn't correct. RIPE is not the government in this. RIPE, or your local LIR can give you a door (address assignment), but you still need to get a permit from the local counsil to place it (Getting your service provider to actually route it). One of the things your local LIR may require before selling you a door is having a permit. Buying the door somewhere else (RIPE) does not automagically entitle you to a permit. > > > Moving from a volume charge service (dialup) to a fixed fee service (DSL) > > I do not find it that unreasonable to in some way limit the amout of > > Internet > > you can consume. > > I agree totally, but that is not my point. The point is that currently among > all ADSL providers in my area, I can only choose between > - package A: 1 dynamic IP, 1 or 10 GB traffic/month, no servers etc. > and > - package B: 1 static IP, 25 GB traffic/month or more, guaranteed minimum > speed, web/mail server allowed, router+webspace+mailboxes included etc. > > Package A is fine for me, except the dynamic IP. I do not want to run > servers or connect multiple computers (unless by using NAT). I want to > connect through a firewall that only allows connections based on source IP > address. > > > > I have always assumed that IP addresses is a comodity ISPs hand out with > > their services. If you buy service from an ISP then you get a reasonable > > number > > of IP addresses to use that service. If you buy a singe-user service, you > > get > > 1 IP address, if you buy a LAN service you get several addresses. > > Again I totally agree, but this is not the case in my area, imho. > > > > If you don't buy the right kind of service from me, I am not going to > > acknowledge > > your IP address request. > > I am indeed afraid that this will be the ISPs' opinions, so I (sorry: the > customer :)) guess threatening to go to the competition is the only way. But > if there is no competitor offering what the customer wants, it's going to be > a meaningless threat... If this service is not currently being offered in your neighbourhood then you could always start selling and provisioning it yourself if you think there is a market for it. Regards, - marcel From woeber at cc.univie.ac.at Wed Feb 28 14:03:18 2001 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 28 Feb 2001 14:03:18 +0100 Subject: Refuse een assignment because it 'cannot' be routed? Message-ID: <009F8517.AACFE69E.14@cc.univie.ac.at> To continue that (cute | silly | pick-your-choice) analogy... => I only want a fixed frontdoor (1 fixed IP address), but I am trying to force => my landlord into letting me have it without paying tripple rent, by asking => the government (RIPE) to give me a building permission to install more => doors. Not because I want more doors, but to keep the landlord from moving => my single door every day :) => = =Hi, = = Hmm... this analogy isn't correct. RIPE is not the government in this. =RIPE, or your local LIR can give you a door (address assignment), but =you still need to get a permit from the local counsil to place it =(Getting your service provider to actually route it). = =One of the things your local LIR may require before selling you a door =is having a permit. Buying the door somewhere else (RIPE) does not =automagically entitle you to a permit. ...what we are seeing in reality, though, is something like the "government" (the RIPE NCC) coming back with a question about the colour and style of the door. And - depending on your answer - either going ahead issuing a _permanent_ permit for e.g. an Ethernet- or leased-line-style door ("static"), but limiting the validity of the permit for an xDSL- style or dial-up door to as long as you, or someone from your family, happens stay at home ("dynamic"). As soon as you go to work, or even worse - take a couple of days off, duhh!!! - you have to submit another application for installing a door. And, the "government", suggests to the manufaturers of the doors (and/or to the landlord), to give you a call on the phone every, say, 8 hours, to confirm that you haven't left for shopping (physicly) or turned to RTFM (virtually/mentally logging off). That's exactly what happens to me, back home, with my ADSL link being dropped every 8 hours by the ISP *on purpose*, because the NCC sort of "suggests" to the ISPs to use dial-up ratio mechanisms for 24x7 xDSL, flat rate billing. Very clever, indeed, in particular when someone tries to do stuff that is security-aware. But I have beaten that one to death before (technology independence of assignment rules). Sigh... 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Tr?ume darf man nicht verbieten, sonst werden sie Wirklichkeit...