From bs at eunet.ch Sun Jun 24 10:50:59 2001 From: bs at eunet.ch (Bernard Steiner) Date: Sun, 24 Jun 2001 10:50:59 +0200 Subject: Modifying references to contact info in the RIPE DB In-Reply-To: Your message of "Thu, 24 Jun 1999 10:19:01 +0200." <199906240819.KAA19760@x41.ripe.net> Message-ID: <200106240850.KAA09195@eunet.ch> > That the original person referenced got deleted some time in the past and a new one with the same name was introduced into the database. Coming to think about it... How about catching such (obvious) cases where the first changed date of the person is younger or either of the changed dates is not available ? How much human intelligence would that require to sort out ? Bernard From bs at eunet.ch Sun Jun 24 17:45:16 2001 From: bs at eunet.ch (Bernard Steiner) Date: Sun, 24 Jun 2001 17:45:16 +0200 Subject: Modifying references to contact info in the RIPE DB In-Reply-To: Your message of "Thu, 24 Jun 1999 17:00:21 +0200." <199906241500.RAA21474@x41.ripe.net> Message-ID: <200106241545.RAA09683@eunet.ch> Hi, > So, can we agree to proceed with our suggestion as stated below? > ** > Change references by names to references by nic handle where these are unique > (there are not already more than two persons with the same referenced name). > ** Can we also decide that when a person decides she (sic) is not responsible for whatever record references hir, said person is allowed to have the reference removed ? (This problem exists already...) Bernard From ncc at ripe.net Fri Jun 1 18:23:48 2001 From: ncc at ripe.net (RIPE NCC Staff) Date: Fri, 01 Jun 2001 18:23:48 +0200 Subject: Summary: PA Allocation criteria discussion Message-ID: <200106011623.SAA04652@office.ripe.net> Dear all, Thank you for you input thus far in the discussion on portable address space. Many useful points have been raised on the matter of PI address space and PA Allocations. (The complete discussion can be read at: http://www.ripe.net/ripe/mail-archives/lir-wg/current/msg00130.html) Below is an attempt to summarise the discussion so far: The concept of smaller allocations (than current /20) was initially brought but the majority felt that this was not a realistic option. The comments showed concern about the exponential growth in the routing table and it was believed that smaller allocations would further contribute to this growth. There was consequently further discussion on how the RIR policies can prevent/reduce this through sensible address allocation/assignment criteria. On the subject of PI assignments, related to the current growth in the routing table, it was agreed that PI assignments should (as current policy states) be based on need and not routability. It was further stated that end users should be discouraged from multi-homing with globally visible address space. Some participants of the discussion argued for a complete discontinuation of PI. Most contributors agreed that /20 PA Allocations should be given to organisations who wish to further assign addresses to customers / end-users from their PA block. PA Allocations should not be made to organisations to satisfy pure multi-homing / independence needs. A set of criteria should therefore be determined to clarify this. Lastly, the majority agreed that the PA Allocation criteria should be based on previous efficient utilisation. There was further discussion with regards to the size of the efficiently utilised address space the requestor needs to demonstrate. The prefix sizes /22 and /21 were briefly discussed. If the community believes that this is a just summary of the discussion, I wish to move forward and determine the details of such criteria, through presenting a few very concrete discussion points. I would like your opinion on the following: 1. Do you agree on the following criteria to be set: The requesting organisation need to show - Demonstrated efficient utilisation of a /xx or - Immediate need for a /xx ? 2. If qualifying through the criterion of demonstrated efficient utilisation of address space, should the requestor need to demonstrate efficient utilisation of A. /22 or B. /21 ? 3. If qualifying through the criterion of demonstrated immediate need, should the requestor need to demonstrate an immediate need of a A. /22 or B. /21? 4. Should the requesting organisation be required to renumber depending on the sizes of its current aggregates? 4A. If so, what is a reasonable size of the smallest aggregate that an organisation would be required to renumber? I am looking forward to your input on these concrete points. Kind regards, Nurani Nimpuno RIPE NCC From huberman at gblx.net Fri Jun 1 19:16:05 2001 From: huberman at gblx.net (David R Huberman) Date: Fri, 1 Jun 2001 10:16:05 -0700 (MST) Subject: Summary: PA Allocation criteria discussion In-Reply-To: <200106011623.SAA04652@office.ripe.net> Message-ID: > 1. Do you agree on the following criteria to be set: > > The requesting organisation need to show > - Demonstrated efficient utilisation of a /xx > or > - Immediate need for a /xx ? I agree! > 2. If qualifying through the criterion of demonstrated efficient > utilisation of address space, should the requestor need to > demonstrate efficient utilisation of > A. /22 > or > B. /21 ? A /21 is a more responsible size, in my opinion. An organization that needs a /22 is less assured of ever using the full /20, much less using it in a reasonable time period. > 3. If qualifying through the criterion of demonstrated immediate > need, should the requestor need to demonstrate an immediate > need of a > A. /22 > or > B. /21? Definitely a /21. > 4. Should the requesting organisation be required to renumber > depending on the sizes of its current aggregates? No! Bad idea! I reiterate that I believe the RIRs have made a mistake in forcing organizations to renumber upstream space as part of the address request process. Such renumbering happens normally as the relationships between a downstream and an upstream evolve (or devolve, as it were). The administrative overhead required on RIPE's part to enforce a renumbering provision *are not acceptable* to Global Crossing at this time. RIPE has other priorities which take precedence. /david *--------------------------------* | Global Crossing IP Engineering | | Manager, Global IP Addressing | | TEL: (908) 720-6182 | | FAX: (703) 464-0802 | *--------------------------------* From neils at ednet.co.uk Wed Jun 6 12:35:10 2001 From: neils at ednet.co.uk (Neil Anderson Saunders) Date: Wed, 6 Jun 2001 11:35:10 +0100 (BST) Subject: IP Management Tool - Minimum Requirements In-Reply-To: <3946.985274717@ripe.net> Message-ID: Hi, I was just wondering if there has been any progress made in this project. Thanks Neil -- Hostmaster edNET t: +44 131 625 5560 (direct) t: +44 131 466 7003 (office) From BucklesBW at aol.com Sun Jun 10 10:00:49 2001 From: BucklesBW at aol.com (BucklesBW at aol.com) Date: Sun, 10 Jun 2001 04:00:49 EDT Subject: NAMEREGISTRY.COM - NICS.NET - DOMAINAMES.COM Message-ID: <4f.cdb112f.28548331@aol.com> DOMAIN PRICE 2000nic.net $1,000 800nic.net $1,500 888nic.net $1,500 abbreviaziones.com $3,500 abreger.com $3,000 abreviacao.com $4,500 abreviacao.net n/a abreviacao.org n/a abreviacaos.com $4,500 abreviacaos.net n/a abreviacaos.org n/a abreviacion.com $3,500 abreviaciones.com $4,000 abreviaciones.net n/a abreviar.com $3,000 abreviatura.com $4,000 abreviatura.net n/a abreviaturas.net $3,500 acronimo.net $3,500 acronyme.com $4,000 acronyme.net n/a acronymes.com $4,000 acronymes.net n/a addressmaster.com $3,500 addressregistry.com $12,000 aenic.com $1,500 afix.org $2,000 afrix.com $2,000 ahix.net $2,000 apix.org $2,500 ap-nic.net $2,000 arpanic.com $4,000 arpanic.net n/a arpanic.org n/a artsnic.com $2,500 artsnic.net n/a auix.com $3,000 auix.org n/a autonic.com $4,000 autonic.net n/a aznic.net $1,500 bankdirectory.com $10,000 banknic.net $3,000 bbnic.org $1,500 bdix.net $2,000 bdnic.org $1,500 bhnic.net $2,000 bhnic.org n/a bnnic.com $2,000 bnnic.org n/a boatnic.net $1,500 bonic.org $1,500 brnic.org $1,500 bynic.org $1,500 bznic.net $1,500 carnic.net $3,000 cctld.net $10,000 cctlds.com $15,000 cctlds.net n/a cfpnic.net $2,250 chironic.net $1,750 classifiedchannel.com $10,000 cnix.org $3,500 country-code.com $3,500 country-code.net n/a countrycode.net $4,000 countrycode.org n/a country-codes.com $3,000 countrycodes.net $4,000 countrycodes.org n/a cpanic.net $2,500 cparegistry.com $8,000 cunic.com $2,000 cunic.org n/a cyberegistry.com $5,000 cyberlocation.com $5,000 cybersecurity.com $15,000 cyberswamp.net $5,000 ddsnic.org $1,500 decimals.net $2,500 decimals.org n/a deix.net $2,000 digidomains.com $8,000 diginames.com $4,000 digitaladdress.com $5,000 digitalocation.com $5,000 digitalregistry.com $9,000 digitalwords.com $2,000 dknic.com $1,500 domainame.org $9,500 domainames.com $25,000 domainames.net n/a domainlogic.com $10,000 domainpower.com $13,000 domainshoppe.com $8,000 dznic.org $1,500 ecnic.com $3,500 ecnic.net n/a edunic.com $4,000 edunic.net n/a edunic.org n/a egnic.net $2,000 egnic.org n/a equations.net $4,000 equations.org n/a eurnic.com $3,500 eurnic.org n/a firmnic.com $2,000 firmnic.net n/a fjix.com $2,500 fjix.net n/a fjnic.com $1,500 fmnic.com $2,500 fxnic.com $1,500 gdix.net $2,000 gdnic.com $2,000 gdnic.net n/a grnic.com $1,500 gtnic.net $1,500 gzix.com $2,500 gzix.net n/a gznic.net $2,000 gznic.org n/a hbnic.com $2,500 hbnic.net n/a hbnic.org n/a healthnic.net $2,500 healthregistry.com $4,000 hillarygate.com $4,000 hlthnic.net $1,500 idix.org $2,000 ilix.net $2,000 ilnic.com $2,000 ilnic.net n/a indns.com $4,000 innic.com $4,500 innic.org n/a internetlocation.com $7,000 internetregistry.com $15,000 iprotocol.net $3,500 iqnic.net $1,750 irnic.net $2,000 irnic.org n/a iso3166.com $3,000 iso3166.net n/a iso3166code.com n/a iso-3166code.com n/a iso3166code.net n/a iso3166codes.com n/a iso-3166codes.com n/a iso3166codes.net n/a iso-3166codes.net n/a iso3166countrycode.com n/a iso-3166countrycode.com n/a iso3166countrycodes.com n/a iso-3166countrycodes.com n/a iso3166countrycodes.net n/a itldnic.net $1,500 itlds.com $13,000 itlds.net n/a iwords.net $4,000 jonic.net $1,500 jpix.org $2,000 kgnic.com $1,500 krix.org $2,000 kurzform.com $4,500 kurzform.net n/a kurzform.org n/a kwnic.com $2,500 kwnic.net n/a kwnic.org n/a laix.net $2,500 laix.org n/a lawnic.net $3,250 lawregistry.com $10,000 managedcare.org $10,000 mdnic.net $5,000 mednic.net $3,750 mednic.org n/a milnic.com $4,000 milnic.net n/a mindaddress.com $1,750 mnnic.com $1,500 moix.net $2,500 moix.org n/a movienic.org $1,500 myix.net $3,500 myix.org n/a name4sale.com $5,000 namechannel.com $6,000 namegiver.com $6,000 namehouse.com $4,000 namehut.com $6,000 namelogic.com $10,000 namemaster.com $10,000 nameregistry.com $18,000 namescape.com $10,000 nameservice.com $12,000 nameshoppe.com $6,000 namewarehouse.com $5,000 nanic.net $2,000 nanic.org n/a negatives.net $3,500 negatives.org n/a netlocation.com $10,000 newsnic.net $2,500 ngnic.net $1,500 nics.net $18,000 nlnic.com $2,000 ntlds.com $13,000 ntlds.net n/a numeral.net $3,000 numerals.net $3,000 numerals.org n/a numnic.com $1,750 numnic.net n/a orgnic.net $2,750 palabras.org $2,000 perfectdomains.com $10,000 perfectnames.com $6,000 perfectwords.com $2,000 phix.org $2,000 phnic.com $1,500 pknic.org $1,500 premierdomains.com $10,000 premiernames.com $6,000 premierwords.com $2,000 previewchannel.com $13,000 prnic.org $1,750 ptnic.net $1,500 qanic.com $1,750 qualitynames.com $6,000 qualitywords.com $2,000 recnic.org $2,000 ripe.org $6,000 ruix.com $3,000 ruix.net n/a ruix.org n/a runic.net $1,500 rxnic.com $2,750 rxnic.net n/a rxnic.org n/a sanic.org $1,500 sgix.net $3,500 sgix.org n/a shopnic.com $2,750 shopnic.net n/a siglas.net $4,000 siglas.org n/a storenic.com $2,750 storenic.net n/a strategicwords.com $2,000 superiordomains.com $10,000 superiornames.com $6,000 superiorwords.com $2,000 synic.net $1,500 thix.org $2,000 tjnic.com $2,000 tjnic.org n/a tmnic.com $3,000 tmnic.org n/a tpnic.org $1,500 trnic.org $1,500 tvdirectory.com $15,000 twnic.org $2,000 uanic.org $1,500 unnic.net $1,500 usadns.com $8,000 usadns.net n/a usaix.net $5,000 usaix.org n/a usanic.org $3,000 usanoc.com $4,000 usanoc.net n/a usnic.com $10,000 usnic.org n/a usnoc.net $4,000 uynic.com $1,500 uznic.com $1,500 venic.net $1,500 virtual-broker.com $8,000 vnix.net $2,500 vnix.org n/a vnnic.org $1,500 webword.net $5,000 wordbroker.com $2,000 wordirectory.com $4,000 wordlisting.com $3,000 wordlistings.com $3,000 wordshoppe.com $3,000 wordwarehouse.com $2,000 wordwizards.com $2,000 zaix.net $2,000 zanic.net $2,000 zanic.org n/a zjix.com $2,500 zjix.net n/a zjnic.com $2,500 zjnic.net n/a zjnic.org n/a zmnic.org $1,500 "N/A" indicates that the domain is part of a package. Contact: Brian Buckles 217-787-1701 From axel.pawlik at ripe.net Wed Jun 13 15:17:52 2001 From: axel.pawlik at ripe.net (Axel Pawlik) Date: Wed, 13 Jun 2001 15:17:52 +0200 Subject: Staffing update, and good news Message-ID: <5.0.2.1.2.20010613151443.02313e58@localhost> Dear all, it gives me great pleasure to announce that we have chosen Sabrina Waschke to fill the newly created position of Registration Services Operations Manager. As such, Sabrina will be responsible of the day to day operations of Registrations Services, overseeing the quality of service. A big part of her tasks is to take care of the Registration Services staff. Sabrina will report directly to the Managing Director. Sabrina has already started in her new position effective of 1 June. Also, as of 1 June, Nurani Nimpuno has become the Internet Address Policy Manager. Her responsiblities are primarily to maintain, and develop RS related policies. Also a major part of Nurani's tasks will be to closely monitor the relevant mailing lists (notably lir-wg), and to pro-actively contribute where and when appropriate. Further, as a result of the discussions between the RIRs over the last months, Nurani will be responsible to co-ordinate policies with the other RIRs; this will enable a globally more consistent policy making process. Nurani will continue to report to the Managing Director. I'm looking forward to working together closely with Sabrina and Nurani. kind regards, Axel Pawlik From axel.pawlik at ripe.net Wed Jun 13 15:53:24 2001 From: axel.pawlik at ripe.net (Axel Pawlik) Date: Wed, 13 Jun 2001 15:53:24 +0200 Subject: Good News.. Message-ID: <5.0.2.1.2.20010613153355.021d59f0@localhost> Dear all, [apologies for duplicate mails] During the INET conference, that took place last week in Stockholm, Brian Carpenter presented this year's Jonathan Postel Award to Daniel Karrenberg. To quote from the Internet Society's website: >The Jonathan B. Postel Service Award was established by the Internet >Society to honor a person who has made outstanding contributions in >service to the data communications community. It is named for Dr. Jonathan >B. Postel to recognize and commemorate the extraordinary stewardship >exercised by Jon over the course of a thirty year career in networking. Daniel, whom many of you know as one of the founding members of RIPE, and who conceived the concept of the RIPE NCC, and served as its General Manager from 1992 to 1999, was commended for his nearly 20 year long involvement with networking and the Internet in Europe, and for his continuously selfless contributions to the Internet community. It is with special delight that we congratulate Daniel today, and wish him equal success during the coming decades! And, of course, all of us at the RIPE NCC are very happy that Daniel is still "one of us"... kind regards, Axel Pawlik From arif.oktay at telekom.gov.tr Thu Jun 14 12:45:53 2001 From: arif.oktay at telekom.gov.tr (Arif OKTAY) Date: Thu, 14 Jun 2001 13:45:53 +0300 Subject: Private address and static IP as an commercial offer. Message-ID: <5.0.2.1.0.20010614133736.023dc8e0@mail.telekom.gov.tr> Hi All, I appreciate if someone clarifies the situations for the following; 1- Address Translation and Private Address Space Usage. Some of my customers want to use public addresses with no technical reason. Their main concern is to avoid the extra expenditure for a NAT/proxy/firewall. Should I force them to use one ? 2- I've seen the following advertisement on the net. Doesn't this constitute a violation of the policy as " IP addresses does not have any commercial value". There wasn't any extra info whether this amount was billed for dns records or any other service. Advertisement was from ARIN region. "For just an additional $15/month, you can get a single static IP address - perfect for using your company's VPN (Virtual Private Network) or accessing the corporate network. The Static IP feature is only available at your residential location. Currently, the feature is only available for new customers in certain areas. For more information and to order your Static IP address today, please call x-xxx-xxx-xxxx and ask for the "Static IP feature". " thnx arif ao189-ripe -------------------------------------------------------------- Arif OKTAY T?rk Telekom Turk Telekom Bili?im A?lar? Dairesi Informatics Department IP Uygulamalar? M?d?rl??? IP Applications Group Tel:+90 312 5551922 Fax:+90 312 5551959 -------------------------------------------------------------- JACK (V.O.) When deep space exploration ramps up, it will be corporations that name everything. The IBM Stellar Sphere. The Philip Morris Galaxy. Planet Starbucks. --------------------------------------- Fight Club --- From schiefne at mail.berlin.contrib.net Thu Jun 14 13:27:11 2001 From: schiefne at mail.berlin.contrib.net (Carsten Schiefner) Date: Thu, 14 Jun 2001 13:27:11 +0200 (MET DST) Subject: Private address and static IP as an commercial offer. In-Reply-To: <5.0.2.1.0.20010614133736.023dc8e0@mail.telekom.gov.tr> from "Arif OKTAY" at Jun 14, 2001 01:45:53 PM Message-ID: <200106141127.f5EBRBW08129@mail.berlin.contrib.net> Hi Arif. Arif OKTAY wrote: > 1- Address Translation and Private Address Space Usage. Some of my > customers want to use public addresses with no technical reason. Their main > concern is to avoid the extra expenditure for a NAT/proxy/firewall. Should > I force them to use one ? I wouldn't do so. Since it is not mandatory or at least strictly recommended to use NAT etc. the customer certainly can ask for public address space to connect his LAN or whatever to the Internet. And I would consider the try to avoid unnecessary expenditure (from their pont of view!) as quite reaso- nable - especially if it's a small, just starting company. Nevertheless it should generally be pointed out that the use of NAT etc. does have some benefits, i.e. address space conservation, and a LIR should offer this to customers as the first choice. > 2- I've seen the following advertisement on the net. Doesn't this > constitute a violation of the policy as " IP addresses does not have any > commercial value". There wasn't any extra info whether this amount was > billed for dns records or any other service. Advertisement was from ARIN > region. The absence of some mentioning of extra costs due to a static IP address doesn't imply the selling of an IP address itself for me, since inherently there might be some additional service costs for that (router config, reverse mapping etc. pp.) - but the question weather US$ 15/m (iow. US$ 180 per year!) for this kind of service are appropriate or not is another one... Best regards, Carsten iPrimus Telecommunications GmbH, Germany From afrench at vianetworks.com Thu Jun 14 13:52:58 2001 From: afrench at vianetworks.com (Alex French) Date: Thu, 14 Jun 2001 12:52:58 +0100 Subject: Private address and static IP as an commercial offer. In-Reply-To: <5.0.2.1.0.20010614133736.023dc8e0@mail.telekom.gov.tr> Message-ID: <5.1.0.14.0.20010614120341.03347ea8@192.168.200.10> At 11:45 14/06/2001, Arif OKTAY wrote: >2- I've seen the following advertisement on the net. Doesn't this >constitute a violation of the policy as " IP addresses does not have any >commercial value". There is an argument to be made that assigning static IPs places a monetizable cost on the ISP, in terms of extra systems, configuration, support etc. Wouldn't these be legitimate reasons for charging? Alex. From jhma at kpnqwest.net Thu Jun 14 14:31:59 2001 From: jhma at kpnqwest.net (James Aldridge) Date: Thu, 14 Jun 2001 14:31:59 +0200 Subject: Private address and static IP as an commercial offer. In-Reply-To: Your message of "Thu, 14 Jun 2001 13:45:53 +0300." <5.0.2.1.0.20010614133736.023dc8e0@mail.telekom.gov.tr> Message-ID: <200106141232.OAA17808@aegir.EU.net> Arif OKTAY wrote: > Hi All, > > I appreciate if someone clarifies the situations for the following; > > 1- Address Translation and Private Address Space Usage. Some of my > customers want to use public addresses with no technical reason. Their main > concern is to avoid the extra expenditure for a NAT/proxy/firewall. Should > I force them to use one ? To quote ripe-185: "Private Address Space: Using private addresses helps to meet the conservation goal. For this reason, users should always be informed that private addresses might be a viable option. In particular, private address space can be employed if not all hosts require network layer access to the Internet. Although users are not required to use private address space even if it would satisfy their needs, it is important that they have considered the possi- bility. The private-considered field in the network overview form should be checked after the requester has indicated whether it is applicable for the user's network." Thus, as long as a customer is made aware of the possibility of using private address space, there is no *requirement* that private address space is actually used. > 2- I've seen the following advertisement on the net. Doesn't this > constitute a violation of the policy as " IP addresses does not have any > commercial value". There wasn't any extra info whether this amount was > billed for dns records or any other service. Advertisement was from ARIN > region. > > "For just an additional $15/month, you can get a single static IP address - > perfect for using your company's VPN (Virtual Private Network) or accessing > the corporate network. The Static IP feature is only available at your > residential location. Currently, the feature is only available for new > customers in certain areas. For more information and to order your Static > IP address today, please call x-xxx-xxx-xxxx and ask for the "Static IP > feature". " In the RIPE region, again ripe-185 applies: 2) Charging Policies A Local IR must publish its charging policy. The policy is defined in ripe-152 [Norris96a]: "Address space is a finite resource with no intrinsic value and direct costs cannot be ascribed to it. While they may not charge for address space as such, registries may charge for their administrative and technical ser- vices. Registries must publish their operating procedures and details of the services they offer and the conditions and terms that apply, including scales of tariffs if applicable." Not knowing the details of this particular providers service, it's hard to comment too much. The $15/month (which may or may not be seen as reasonable) would probably be seen as an additional charge for "administrative and technical services" for the static IP *feature* rather than a charge for the IP address itself. James From arif.oktay at telekom.gov.tr Thu Jun 14 16:44:57 2001 From: arif.oktay at telekom.gov.tr (Arif OKTAY) Date: Thu, 14 Jun 2001 17:44:57 +0300 Subject: Private address and static IP as an commercial offer. Message-ID: <5.0.2.1.0.20010614174425.01d4dec0@mail.telekom.gov.tr> hi, so if we keep the ration on this logic this cost also should be proportional to the IP adresses assigned ? seems hard to justify what complies with the policy and what doesn't . arif, At 14.06.2001, you wrote: >At 11:45 14/06/2001, Arif OKTAY wrote: >>2- I've seen the following advertisement on the net. Doesn't this >>constitute a violation of the policy as " IP addresses does not have any >>commercial value". > >There is an argument to be made that assigning static IPs places a >monetizable cost on the ISP, in terms of extra systems, configuration, >support etc. Wouldn't these be legitimate reasons for charging? > >Alex. -------------------------------------------------------------- Arif OKTAY T?rk Telekom Turk Telekom Bili?im A?lar? Dairesi Informatics Department IP Uygulamalar? M?d?rl??? IP Applications Group Tel:+90 312 5551922 Fax:+90 312 5551959 -------------------------------------------------------------- JACK Why are you doing this? MARLA It's cheaper than a movie, and there's free coffee. --------------------------------------- Fight Club --- From huberman at gblx.net Thu Jun 14 17:19:41 2001 From: huberman at gblx.net (David R Huberman) Date: Thu, 14 Jun 2001 08:19:41 -0700 (MST) Subject: Private address and static IP as an commercial offer. In-Reply-To: <5.0.2.1.0.20010614174425.01d4dec0@mail.telekom.gov.tr> Message-ID: Hello Arif, > so if we keep the ration on this logic this cost also should be > proportional to the IP adresses assigned ? seems hard to justify what > complies with the policy and what doesn't . You are certainly entitled to charge customers/requestors for the reimbursement of administrative fees associated with IP address block request and fulfillment. That cost should probably not be proportional to the size of the block assigned, as in many cases, the size does not change your cost of administration. If your administrative costs, as an LIR, go up as the size of an assignment does, then so be it. /david *--------------------------------* | Global Crossing IP Engineering | | Manager, Global IP Addressing | | TEL: (908) 720-6182 | | FAX: (703) 464-0802 | *--------------------------------* From paul.mylotte at bt.com Thu Jun 14 17:26:47 2001 From: paul.mylotte at bt.com (paul.mylotte at bt.com) Date: Thu, 14 Jun 2001 16:26:47 +0100 Subject: IP address management tools available from RIPE Message-ID: Apologies, I have now added a more meaningful subject title :-) Paul P. S. Mylotte IP Addressing & Naming BTexact Technologies Adastral Park 01473 606333 / + 44 1473 606333 paul.mylotte at bt.com BTexact Technologies is a trademark of British Telecommunications plc Registered office 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British Telecommunications plc which may be priveleged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the number or address above) immediately. > -----Original Message----- > From: Mylotte,PS,Paul,DKF MYLOTTPS R > Sent: 14 June 2001 16:25 > To: lir-wg at ripe.net > Subject: RE: Summary: PA Allocation criteria discussion > > Folks, > > who do I contact regarding the availability (or otherwise) of > the S/W tool for LIR self auditing? In fact, what tools are > available for IPaddress management in general? > > Thanks in advance. > > Paul > > > P. S. Mylotte > IP Addressing & Naming > BTexact Technologies > Adastral Park > 01473 606333 / + 44 1473 606333 > paul.mylotte at bt.com > > BTexact Technologies is a trademark of British Telecommunications plc > Registered office 81 Newgate Street London EC1A 7AJ > Registered in England no. 1800000 > > This electronic message contains information from British > Telecommunications plc which may be priveleged or confidential. The > information is intended to be for the use of the individual(s) or entity > named above. If you are not the intended recipient be aware that any > disclosure, copying, distribution or use of the contents of this > information is prohibited. If you have received this electronic message in > error, please notify us by telephone or email (to the number or address > above) immediately. > > From paul.mylotte at bt.com Thu Jun 14 17:25:08 2001 From: paul.mylotte at bt.com (paul.mylotte at bt.com) Date: Thu, 14 Jun 2001 16:25:08 +0100 Subject: Summary: PA Allocation criteria discussion Message-ID: Folks, who do I contact regarding the availability (or otherwise) of the S/W tool for LIR self auditing? In fact, what tools are available for IPaddress management in general? Thanks in advance. Paul P. S. Mylotte IP Addressing & Naming BTexact Technologies Adastral Park 01473 606333 / + 44 1473 606333 paul.mylotte at bt.com BTexact Technologies is a trademark of British Telecommunications plc Registered office 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British Telecommunications plc which may be priveleged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the number or address above) immediately. From hph at online.no Thu Jun 14 17:04:56 2001 From: hph at online.no (Hans Petter Holen) Date: Thu, 14 Jun 2001 17:04:56 +0200 Subject: Private address and static IP as an commercial offer. References: <200106141127.f5EBRBW08129@mail.berlin.contrib.net> Message-ID: <000201c0f514$139a1530$0800000a@hph> | Nevertheless it should generally be pointed out that the use of NAT etc. does | have some benefits, i.e. address space conservation, and a LIR should offer | this to customers as the first choice. The current policy is not so. Alltough NAT has its advatages, it does also have its disadvatages. The current policy is, and shoud continue to be in my opinion, to give the customers the amount of addresses they can document a need for. -hph From axel.pawlik at ripe.net Wed Jun 13 15:17:52 2001 From: axel.pawlik at ripe.net (Axel Pawlik) Date: Wed, 13 Jun 2001 15:17:52 +0200 Subject: Staffing update, and good news Message-ID: <5.0.2.1.2.20010613151443.02313e58@localhost> Dear all, it gives me great pleasure to announce that we have chosen Sabrina Waschke to fill the newly created position of Registration Services Operations Manager. As such, Sabrina will be responsible of the day to day operations of Registrations Services, overseeing the quality of service. A big part of her tasks is to take care of the Registration Services staff. Sabrina will report directly to the Managing Director. Sabrina has already started in her new position effective of 1 June. Also, as of 1 June, Nurani Nimpuno has become the Internet Address Policy Manager. Her responsiblities are primarily to maintain, and develop RS related policies. Also a major part of Nurani's tasks will be to closely monitor the relevant mailing lists (notably lir-wg), and to pro-actively contribute where and when appropriate. Further, as a result of the discussions between the RIRs over the last months, Nurani will be responsible to co-ordinate policies with the other RIRs; this will enable a globally more consistent policy making process. Nurani will continue to report to the Managing Director. I'm looking forward to working together closely with Sabrina and Nurani. kind regards, Axel Pawlik From axel.pawlik at ripe.net Wed Jun 13 15:53:24 2001 From: axel.pawlik at ripe.net (Axel Pawlik) Date: Wed, 13 Jun 2001 15:53:24 +0200 Subject: Good News.. Message-ID: <5.0.2.1.2.20010613153355.021d59f0@localhost> Dear all, [apologies for duplicate mails] During the INET conference, that took place last week in Stockholm, Brian Carpenter presented this year's Jonathan Postel Award to Daniel Karrenberg. To quote from the Internet Society's website: >The Jonathan B. Postel Service Award was established by the Internet >Society to honor a person who has made outstanding contributions in >service to the data communications community. It is named for Dr. Jonathan >B. Postel to recognize and commemorate the extraordinary stewardship >exercised by Jon over the course of a thirty year career in networking. Daniel, whom many of you know as one of the founding members of RIPE, and who conceived the concept of the RIPE NCC, and served as its General Manager from 1992 to 1999, was commended for his nearly 20 year long involvement with networking and the Internet in Europe, and for his continuously selfless contributions to the Internet community. It is with special delight that we congratulate Daniel today, and wish him equal success during the coming decades! And, of course, all of us at the RIPE NCC are very happy that Daniel is still "one of us"... kind regards, Axel Pawlik From arif.oktay at telekom.gov.tr Thu Jun 14 12:45:53 2001 From: arif.oktay at telekom.gov.tr (Arif OKTAY) Date: Thu, 14 Jun 2001 13:45:53 +0300 Subject: Private address and static IP as an commercial offer. Message-ID: <5.0.2.1.0.20010614133736.023dc8e0@mail.telekom.gov.tr> Hi All, I appreciate if someone clarifies the situations for the following; 1- Address Translation and Private Address Space Usage. Some of my customers want to use public addresses with no technical reason. Their main concern is to avoid the extra expenditure for a NAT/proxy/firewall. Should I force them to use one ? 2- I've seen the following advertisement on the net. Doesn't this constitute a violation of the policy as " IP addresses does not have any commercial value". There wasn't any extra info whether this amount was billed for dns records or any other service. Advertisement was from ARIN region. "For just an additional $15/month, you can get a single static IP address - perfect for using your company's VPN (Virtual Private Network) or accessing the corporate network. The Static IP feature is only available at your residential location. Currently, the feature is only available for new customers in certain areas. For more information and to order your Static IP address today, please call x-xxx-xxx-xxxx and ask for the "Static IP feature". " thnx arif ao189-ripe -------------------------------------------------------------- Arif OKTAY T?rk Telekom Turk Telekom Bili?im A?lar? Dairesi Informatics Department IP Uygulamalar? M?d?rl??? IP Applications Group Tel:+90 312 5551922 Fax:+90 312 5551959 -------------------------------------------------------------- JACK (V.O.) When deep space exploration ramps up, it will be corporations that name everything. The IBM Stellar Sphere. The Philip Morris Galaxy. Planet Starbucks. --------------------------------------- Fight Club --- From paul.mylotte at bt.com Thu Jun 14 17:26:47 2001 From: paul.mylotte at bt.com (paul.mylotte at bt.com) Date: Thu, 14 Jun 2001 16:26:47 +0100 Subject: IP address management tools available from RIPE Message-ID: Apologies, I have now added a more meaningful subject title :-) Paul P. S. Mylotte IP Addressing & Naming BTexact Technologies Adastral Park 01473 606333 / + 44 1473 606333 paul.mylotte at bt.com BTexact Technologies is a trademark of British Telecommunications plc Registered office 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British Telecommunications plc which may be priveleged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the number or address above) immediately. > -----Original Message----- > From: Mylotte,PS,Paul,DKF MYLOTTPS R > Sent: 14 June 2001 16:25 > To: lir-wg at ripe.net > Subject: RE: Summary: PA Allocation criteria discussion > > Folks, > > who do I contact regarding the availability (or otherwise) of > the S/W tool for LIR self auditing? In fact, what tools are > available for IPaddress management in general? > > Thanks in advance. > > Paul > > > P. S. Mylotte > IP Addressing & Naming > BTexact Technologies > Adastral Park > 01473 606333 / + 44 1473 606333 > paul.mylotte at bt.com > > BTexact Technologies is a trademark of British Telecommunications plc > Registered office 81 Newgate Street London EC1A 7AJ > Registered in England no. 1800000 > > This electronic message contains information from British > Telecommunications plc which may be priveleged or confidential. The > information is intended to be for the use of the individual(s) or entity > named above. If you are not the intended recipient be aware that any > disclosure, copying, distribution or use of the contents of this > information is prohibited. If you have received this electronic message in > error, please notify us by telephone or email (to the number or address > above) immediately. > > From paul.mylotte at bt.com Thu Jun 14 17:25:08 2001 From: paul.mylotte at bt.com (paul.mylotte at bt.com) Date: Thu, 14 Jun 2001 16:25:08 +0100 Subject: Summary: PA Allocation criteria discussion Message-ID: Folks, who do I contact regarding the availability (or otherwise) of the S/W tool for LIR self auditing? In fact, what tools are available for IPaddress management in general? Thanks in advance. Paul P. S. Mylotte IP Addressing & Naming BTexact Technologies Adastral Park 01473 606333 / + 44 1473 606333 paul.mylotte at bt.com BTexact Technologies is a trademark of British Telecommunications plc Registered office 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British Telecommunications plc which may be priveleged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the number or address above) immediately. From arif.oktay at telekom.gov.tr Thu Jun 14 16:44:57 2001 From: arif.oktay at telekom.gov.tr (Arif OKTAY) Date: Thu, 14 Jun 2001 17:44:57 +0300 Subject: Private address and static IP as an commercial offer. Message-ID: <5.0.2.1.0.20010614174425.01d4dec0@mail.telekom.gov.tr> hi, so if we keep the ration on this logic this cost also should be proportional to the IP adresses assigned ? seems hard to justify what complies with the policy and what doesn't . arif, At 14.06.2001, you wrote: >At 11:45 14/06/2001, Arif OKTAY wrote: >>2- I've seen the following advertisement on the net. Doesn't this >>constitute a violation of the policy as " IP addresses does not have any >>commercial value". > >There is an argument to be made that assigning static IPs places a >monetizable cost on the ISP, in terms of extra systems, configuration, >support etc. Wouldn't these be legitimate reasons for charging? > >Alex. -------------------------------------------------------------- Arif OKTAY T?rk Telekom Turk Telekom Bili?im A?lar? Dairesi Informatics Department IP Uygulamalar? M?d?rl??? IP Applications Group Tel:+90 312 5551922 Fax:+90 312 5551959 -------------------------------------------------------------- JACK Why are you doing this? MARLA It's cheaper than a movie, and there's free coffee. --------------------------------------- Fight Club --- From huberman at gblx.net Thu Jun 14 17:19:41 2001 From: huberman at gblx.net (David R Huberman) Date: Thu, 14 Jun 2001 08:19:41 -0700 (MST) Subject: Private address and static IP as an commercial offer. In-Reply-To: <5.0.2.1.0.20010614174425.01d4dec0@mail.telekom.gov.tr> Message-ID: Hello Arif, > so if we keep the ration on this logic this cost also should be > proportional to the IP adresses assigned ? seems hard to justify what > complies with the policy and what doesn't . You are certainly entitled to charge customers/requestors for the reimbursement of administrative fees associated with IP address block request and fulfillment. That cost should probably not be proportional to the size of the block assigned, as in many cases, the size does not change your cost of administration. If your administrative costs, as an LIR, go up as the size of an assignment does, then so be it. /david *--------------------------------* | Global Crossing IP Engineering | | Manager, Global IP Addressing | | TEL: (908) 720-6182 | | FAX: (703) 464-0802 | *--------------------------------* From manuel at ripe.net Fri Jun 15 12:23:25 2001 From: manuel at ripe.net (Manuel Valente) Date: Fri, 15 Jun 2001 12:23:25 +0200 Subject: Summary: PA Allocation criteria discussion In-Reply-To: References: Message-ID: <20010615122325.1f888a7a.manuel@ripe.net> Greetings, On Thu, 14 Jun 2001 16:25:08 +0100 paul.mylotte at bt.com wrote: > who do I contact regarding the availability (or otherwise) of > the S/W tool for LIR self auditing? In fact, what tools are > available for IPaddress management in general? There is a project for the creation of an IP management tool to be distributed to the LIRs. Development on the project has not yet started, but a public mailing list is up for discussion - ipmt-dev at ripe.net. Please subscribe if you're interested in the development of the tool. Available right now, though, there is asused: Asused is a tool to check and summarise address space registered in the RIPE database. For a given list of allocations the tool prints various information concerning the allocations and the assignments they contain. The software is written in standard Perl 5 and uses several Perl modules. It was written and tested on BSD/OS 3.1, but should work with any modern UNIX-like operating system. All the files needed are stored in this file: ftp://ftp.ripe.net/tools/asused-3.52.tar.gz Of course, if other people have written tools for IP address management, we would be very happy to hear from them. Regards. -- Manuel Valente - Software Manager - RIPE NCC From neils at ednet.co.uk Fri Jun 15 15:02:06 2001 From: neils at ednet.co.uk (Neil Anderson Saunders) Date: Fri, 15 Jun 2001 14:02:06 +0100 (BST) Subject: IP address management tools available from RIPE In-Reply-To: Message-ID: On Thu, 14 Jun 2001, paul.mylotte at bt.com wrote: > > who do I contact regarding the availability (or otherwise) of > > the S/W tool for LIR self auditing? In fact, what tools are > > available for IPaddress management in general? Hi Paul, Guy Vegoda is currently tidying up such a system called Robo-Bijal which was demonstated at RIPE-38 and is now open source. He expects to release this shortly. Neil -- Hostmaster edNET t: +44 131 625 5560 (direct) t: +44 131 466 7003 (office) From ncc at ripe.net Fri Jun 15 17:06:16 2001 From: ncc at ripe.net (RIPE NCC Staff) Date: Fri, 15 Jun 2001 17:06:16 +0200 Subject: Initial PA Allocation Criteria Message-ID: <200106151506.RAA29122@office.ripe.net> Dear all, Further to my mail on PA Allocation criteria (see below), here follows a concrete proposal, including details of the actual criteria to be determined. Very little feedback was received on the last mail asking for input on the actual details of such criteria. Therefore, in order to move forward and establish the details of these criteria, please find below a clear proposal of criteria for the initial PA Allocation received by a newly established Local IR. Proposed Criteria for Initial /20 PA Allocation ----------------------------------------------- The Local IR is required to: - Demonstrate previous efficient utilisation of a /22 (1024 addresses). Or - Demonstrate immediate need for a /22 Renumbering: If current address space held by the Local IR amounts to a /22 or less, the Local IR is required to renumber that address space into the PA Allocation it will receive from the RIPE NCC. Can the lir-wg agree with the above proposed criteria? If no further objections are raised I would like to suggest that the RIPE NCC moves forward and implements this policy. Please let us know if you are not in agreement with the above. Kind regards, Nurani Nimpuno +------------------------------------+ | Nurani Nimpuno | | Internet Address Policy Manager | | RIPE Network Co-ordination Centre | | http://www.ripe.net | +------------------------------------+ ------- Forwarded Message Date: Fri, 01 Jun 2001 18:23:48 +0200 From: RIPE NCC Staff Resent-From: Nurani Nimpuno Sender: owner-lir-wg at ripe.net To: lir-wg at ripe.net Resent-To: ncc at ripe.net Subject: Summary: PA Allocation criteria discussion Dear all, Thank you for you input thus far in the discussion on portable address space. Many useful points have been raised on the matter of PI address space and PA Allocations. (The complete discussion can be read at: http://www.ripe.net/ripe/mail-archives/lir-wg/current/msg00130.html) Below is an attempt to summarise the discussion so far: The concept of smaller allocations (than current /20) was initially brought but the majority felt that this was not a realistic option. The comments showed concern about the exponential growth in the routing table and it was believed that smaller allocations would further contribute to this growth. There was consequently further discussion on how the RIR policies can prevent/reduce this through sensible address allocation/assignment criteria. On the subject of PI assignments, related to the current growth in the routing table, it was agreed that PI assignments should (as current policy states) be based on need and not routability. It was further stated that end users should be discouraged from multi-homing with globally visible address space. Some participants of the discussion argued for a complete discontinuation of PI. Most contributors agreed that /20 PA Allocations should be given to organisations who wish to further assign addresses to customers / end-users from their PA block. PA Allocations should not be made to organisations to satisfy pure multi-homing / independence needs. A set of criteria should therefore be determined to clarify this. Lastly, the majority agreed that the PA Allocation criteria should be based on previous efficient utilisation. There was further discussion with regards to the size of the efficiently utilised address space the requestor needs to demonstrate. The prefix sizes /22 and /21 were briefly discussed. If the community believes that this is a just summary of the discussion, I wish to move forward and determine the details of such criteria, through presenting a few very concrete discussion points. I would like your opinion on the following: 1. Do you agree on the following criteria to be set: The requesting organisation need to show - Demonstrated efficient utilisation of a /xx or - Immediate need for a /xx ? 2. If qualifying through the criterion of demonstrated efficient utilisation of address space, should the requestor need to demonstrate efficient utilisation of A. /22 or B. /21 ? 3. If qualifying through the criterion of demonstrated immediate need, should the requestor need to demonstrate an immediate need of a A. /22 or B. /21? 4. Should the requesting organisation be required to renumber depending on the sizes of its current aggregates? 4A. If so, what is a reasonable size of the smallest aggregate that an organisation would be required to renumber? I am looking forward to your input on these concrete points. Kind regards, Nurani Nimpuno RIPE NCC ------- End of Forwarded Message From gert at space.net Thu Jun 14 19:04:35 2001 From: gert at space.net (Gert Doering) Date: Thu, 14 Jun 2001 19:04:35 +0200 Subject: Private address and static IP as an commercial offer. In-Reply-To: <5.0.2.1.0.20010614133736.023dc8e0@mail.telekom.gov.tr>; from arif.oktay@telekom.gov.tr on Thu, Jun 14, 2001 at 01:45:53PM +0300 References: <5.0.2.1.0.20010614133736.023dc8e0@mail.telekom.gov.tr> Message-ID: <20010614190435.A17832@Space.Net> Hi, On Thu, Jun 14, 2001 at 01:45:53PM +0300, Arif OKTAY wrote: > I appreciate if someone clarifies the situations for the following; > > 1- Address Translation and Private Address Space Usage. Some of my > customers want to use public addresses with no technical reason. Their main > concern is to avoid the extra expenditure for a NAT/proxy/firewall. Should > I force them to use one ? "I do not want to use NAT" *is* a valid reason for public address space. RIPE policy is NOT to force NAT on people. The policy is "tell people that NAT exists, explain to them what the benefits are, tell them that addresses *are* sparse, but if they want real addresses, give 'em some". > 2- I've seen the following advertisement on the net. Doesn't this > constitute a violation of the policy as " IP addresses does not have any > commercial value". There wasn't any extra info whether this amount was > billed for dns records or any other service. Advertisement was from ARIN > region. In the RIPE region, it's highly discouraged to offer IP addresses "for money". It's not too unusual, though, that a dynamic IP dialup account *is* cheaper than one with static addresses (because it's much more work for the ISP). The real problem are things like "with this contract, you get 32 IPs, and for another $100/month, you get a full Class C". 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 vovik at lucky.net Sat Jun 16 00:26:21 2001 From: vovik at lucky.net (Vladimir A. Jakovenko) Date: Sat, 16 Jun 2001 01:26:21 +0300 Subject: Summary: PA Allocation criteria discussion In-Reply-To: ; from paul.mylotte@bt.com on Thu, Jun 14, 2001 at 04:25:08PM +0100 References: Message-ID: <20010616012621.K30852@lucky.net> On Thu, Jun 14, 2001 at 04:25:08PM +0100, paul.mylotte at bt.com wrote: >Folks, > >who do I contact regarding the availability (or otherwise) of >the S/W tool for LIR self auditing? In fact, what tools are >available for IPaddress management in general? You may try to look at Nets (http://www.open.com.ua/nets). Among other features it also supports some sort of IP address management. -- Regards, Vladimir. From randy at psg.com Mon Jun 18 09:48:28 2001 From: randy at psg.com (Randy Bush) Date: Mon, 18 Jun 2001 00:48:28 -0700 Subject: Private address and static IP as an commercial offer. References: <5.0.2.1.0.20010614133736.023dc8e0@mail.telekom.gov.tr> <20010614190435.A17832@Space.Net> Message-ID: > The policy is "tell people that NAT exists, explain to them what the > benefits are what benefits are there? and before you say "security" please go read just about any mailing list archive. the informal ietf position is that there are no advantages to nats, and lots of disadvantages. randy From src at contrib.com Mon Jun 18 09:39:43 2001 From: src at contrib.com (Heiko Blume) Date: Mon, 18 Jun 2001 09:39:43 +0200 (MET DST) Subject: cgi-bin/whois?query broken Message-ID: <15149.45119.37045.801511@mail.berlin.contrib.net> hello when inserting objects with like this: import: from AS1273 action pref=100; accept AND NOT {0.0.0.0/0} the query http://www.ripe.net/cgi-bin/whois?query=AS5427 will not display the data correctly: import: from AS1270 action pref=100; accept AND NOT {0.0.0.0/0} also, AFAIR previously the http output made the 'ASxxx' strings as links to the objects which was very convenient. will we see that again? regards, heiko -- Heiko Blume (HB21) mailto:heiko.blume at iprimus.de iPrimus Telecommunications GmbH http://www.iprimus.de Marienburger Str. 1, D-10405 Berlin Phone: +49.30/443366-0 Fax: -15 Core-l -- If you don't know then you don't need to know From gert at space.net Mon Jun 18 11:59:11 2001 From: gert at space.net (Gert Doering) Date: Mon, 18 Jun 2001 11:59:11 +0200 Subject: Private address and static IP as an commercial offer. In-Reply-To: ; from randy@psg.com on Mon, Jun 18, 2001 at 12:48:28AM -0700 References: <5.0.2.1.0.20010614133736.023dc8e0@mail.telekom.gov.tr> <20010614190435.A17832@Space.Net> Message-ID: <20010618115911.W16828@Space.Net> Hi, On Mon, Jun 18, 2001 at 12:48:28AM -0700, Randy Bush wrote: > > The policy is "tell people that NAT exists, explain to them what the > > benefits are > > what benefits are there? and before you say "security" please go read > just about any mailing list archive. Ease of changing ISPs, ease of internal network structuring (that is: "just use class Cs because that's the default netmask in Windoze"), *plus* security. Yes, there are drawbacks, and it's not the maximum security you can get, but as long as the router isn't broken, it's more secure than giving full access to every machine in your network. > the informal ietf position is that there are no advantages to nats, and > lots of disadvantages. Which is a known point of view :) 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 hph at online.no Mon Jun 18 14:12:42 2001 From: hph at online.no (Hans Petter Holen) Date: Mon, 18 Jun 2001 14:12:42 +0200 Subject: Private address and static IP as an commercial offer. References: <5.0.2.1.0.20010614133736.023dc8e0@mail.telekom.gov.tr> <20010614190435.A17832@Space.Net> <20010618115911.W16828@Space.Net> Message-ID: <001301c0f7ef$fa829480$a505e1c3@hph> | On Mon, Jun 18, 2001 at 12:48:28AM -0700, Randy Bush wrote: | > > The policy is "tell people that NAT exists, explain to them what the | > > benefits are | > | > what benefits are there? and before you say "security" please go read | > just about any mailing list archive. | | Ease of changing ISPs, I have to change my DHCP server, won't take too long. And if I had put in my sevrers there, with a static address it would be even simpler. >ease of internal network structuring (that is: | "just use class Cs because that's the default netmask in Windoze"), *plus* Since I am using DHCP I enter the netmask there, nowere else. | security. My main security concern is people sending confidential documents as email attachments... |Yes, there are drawbacks, and it's not the maximum security | you can get, but as long as the router isn't broken, it's more secure | than giving full access to every machine in your network. Oh, that is 1 line of configuration "deny all" which breaks excactly the same things as NAT. | | > the informal ietf position is that there are no advantages to nats, and | > lots of disadvantages. | | Which is a known point of view :) Maybe that point of view is there for a reason ? -hph From gert at space.net Mon Jun 18 14:14:53 2001 From: gert at space.net (Gert Doering) Date: Mon, 18 Jun 2001 14:14:53 +0200 Subject: Private address and static IP as an commercial offer. In-Reply-To: <001301c0f7ef$fa829480$a505e1c3@hph>; from hph@online.no on Mon, Jun 18, 2001 at 02:12:42PM +0200 References: <5.0.2.1.0.20010614133736.023dc8e0@mail.telekom.gov.tr> <20010614190435.A17832@Space.Net> <20010618115911.W16828@Space.Net> <001301c0f7ef$fa829480$a505e1c3@hph> Message-ID: <20010618141453.Z16828@Space.Net> Hi, On Mon, Jun 18, 2001 at 02:12:42PM +0200, Hans Petter Holen wrote: > | > the informal ietf position is that there are no advantages to nats, and > | > lots of disadvantages. > | Which is a known point of view :) > Maybe that point of view is there for a reason ? Well - the IETF considers IP an end-to-end thing, which is a valid point of view, but obviously not the only one. Especially for security reasons, things like proxies might be desireable, which also break end-to-end IP, just at a different layer. I'm not saying that NAT is the cure for all evils, I just want to state that it is not the *root* of all evils either. 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 crain at icann.org Mon Jun 18 20:37:21 2001 From: crain at icann.org (John Crain) Date: Mon, 18 Jun 2001 11:37:21 -0700 Subject: Private address and static IP as an commercial offer. In-Reply-To: <001301c0f7ef$fa829480$a505e1c3@hph> Message-ID: I think, at least when I worked for the RIPE registry we did, the registry only makes people aware of the technology and doesn't support or denounce it. This is as it should be. To NAT or not to NAT is often a business decision that needs to be made by the end user. Keeping end users informed of such technology is a good thing. Forcing people to either use it or not use it would be a bad thing. I get the impression that NATs are widely used throughout Europe. Often seen as a way of addressing IP conservation issues and security at the same time. Often people aren't aware of the disadvantages though. JC From afrench at vianetworks.com Tue Jun 19 14:05:13 2001 From: afrench at vianetworks.com (Alex French) Date: Tue, 19 Jun 2001 13:05:13 +0100 Subject: Private address and static IP as an commercial offer. In-Reply-To: References: <5.0.2.1.0.20010614133736.023dc8e0@mail.telekom.gov.tr> <20010614190435.A17832@Space.Net> Message-ID: <5.1.0.14.0.20010619130248.00af5b10@mail.via-europe.com> At 08:48 18/06/2001, Randy Bush wrote: > > The policy is "tell people that NAT exists, explain to them what the > > benefits are > >what benefits are there? In practice, a major benefit to using NAT is that it doesn't require the co-operation of either the ISP or the registry. For many small/medium enterprises, the turnaround time and extra form filling to obtain an assignment aren't worth it, especially when combined with the other benefits to NAT mentioned here. Alex. From crain at staff.icann.org Tue Jun 19 19:12:34 2001 From: crain at staff.icann.org (John Crain) Date: Tue, 19 Jun 2001 10:12:34 -0700 (PDT) Subject: Private address and static IP as an commercial offer. In-Reply-To: Message-ID: On Tue, 19 Jun 2001, Chris Hallam wrote: Hi Chris, Most of my knowledge is second hand so I would advise reading the RFC's on this (They are actually interesting reading). I have played around with a few NAT solutions and yes they work, to some peoples definition of the word "work". If you want to read a well worded and fairly level documentation on advantages and disadvantages I would advize reading rfc2993 which covers many different aspects of NAT issues. http://www.ietf.org/rfc/rfc2993.txt I wrote about four paragraphs here but deleted them, I was getting religious. This happens a lot when NATs are discussed:) Undeniably people are using NAT's now and they are communicating with each other and us. NATs have advantages in IP address management, I think the question people should ask is "In my specific situation do the advantages outweigh the disadvantages?". This is a business decision but I think that most people making the decision aren't even aware of the issues. If you get questions give people the link above. Let them make an informed decision. In case you ask, no I don't use NAT, my decision you make yours:) John > Hello John, > > Just out of interest, what would you say the disadvantages with NAT are? > > Please forward your response to the mailing list if you think that it is > appropriate. > > Thanks, > > Chris > > -----Original Message----- > From: John Crain [mailto:crain at icann.org] > Sent: 18 June 2001 19:37 > To: Hans Petter Holen > Cc: lir-wg at ripe.net > Subject: RE: Private address and static IP as an commercial offer. > > > > I think, at least when I worked for the RIPE registry we did, the registry > only makes people aware of the technology and doesn't support or denounce > it. > > This is as it should be. To NAT or not to NAT is often a business decision > that needs to be made by the end user. Keeping end users informed of such > technology is a good thing. Forcing people to either use it or not use it > would be a bad thing. > > I get the impression that NATs are widely used throughout Europe. Often seen > as a way of addressing IP conservation issues and security at the same time. > > Often people aren't aware of the disadvantages though. > > JC > > > > > ********************************************************************** > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please notify > the system manager. > > This footnote also confirms that this email message has been swept > for the presence of computer viruses. > > ********************************************************************** > From mguz at scotland.net Wed Jun 20 12:04:13 2001 From: mguz at scotland.net (Mark S. Guz) Date: Wed, 20 Jun 2001 11:04:13 +0100 Subject: Private address and static IP as an commercial offer. References: <5.0.2.1.0.20010614133736.023dc8e0@mail.telekom.gov.tr> <20010614190435.A17832@Space.Net> <5.1.0.14.0.20010619130248.00af5b10@mail.via-europe.com> Message-ID: <3B30751D.FB720261@scotland.net> Alex French wrote: > > At 08:48 18/06/2001, Randy Bush wrote: > > > The policy is "tell people that NAT exists, explain to them what the > > > benefits are > > > >what benefits are there? > > In practice, a major benefit to using NAT is that it doesn't require the > co-operation of either the ISP or the registry. For many small/medium > enterprises, the turnaround time and extra form filling to obtain an > assignment aren't worth it, especially when combined with the other > benefits to NAT mentioned here. > > Alex. Hello all, Working for an ISP I find that NAT is advantageous over legitimate addressing for several reasons. The first is that which Alex mentioned, no paperwork = no delay. The wait queue at the Ripe NCC can be lengthy sometimes. Secondly, address space conservation, as far as our own /19 allocation is concerned we can more effectively use this space for those that truly need legitimate address space. The majority of commercial connections need at best a /29 or /28 for a mail server and or a web server the rest of their lan is usually either behind a firewall or nat'd on the router. Thirdly security. We used double NAT for firewalling customers, meaning the firewall is nat'd at the router and the local lan is nat'd behind the firewall. With access lists on the router this increases the security by adding more layers to the security model, rather than hard shell soft centre. I always ask the customer to think about what they really need legitimate addressing for. 99% of the time they just have no need for public address space. just my 2p's worth! (or 2cents or .02 euros worth) -- Mark S. Guz Senior System/Network Engineer IT Scotland On Line Technology Park Gemini Crescent Dundee DD2 1SW Tel + 44 (0) 1382 429000 Fax + 44 (0) 1382 429001 http://www.scotlandonline.co.uk This message is confidential and may contain privileged information. You should not disclose its contents to any other person. If you are not the intended recipient, please notify the sender named above immediately. It is expressly declared that this e-mail does not constitute nor form part of a contract or unilateral obligation. Opinions, conclusions and other information in this message that do not relate to the official business of Scotland On Line Limited shall be understood as neither given nor endorsed by it. From Karsten.Koepp at lambdanet.net Wed Jun 20 14:56:14 2001 From: Karsten.Koepp at lambdanet.net (Koepp, Karsten) Date: Wed, 20 Jun 2001 14:56:14 +0200 Subject: Initial PA Allocation Criteria Message-ID: <39F27E3F569FD4119EF200508BAF85B90197BD7E@CCGNT30> Hi, after having read several opinions in this thread, I still don't agree to some points. I do think, the policy as proposed would represent a drawback for start-ups entering the market. > -----Urspruengliche Nachricht----- > Von: RIPE NCC Staff [SMTP:ncc at ripe.net] > Gesendet am: Freitag, 15. Juni 2001 17:06 > An: lir-wg at ripe.net > Betreff: Initial PA Allocation Criteria > > Dear all, > > Further to my mail on PA Allocation criteria (see below), here follows > a concrete proposal, including details of the actual criteria to be > determined. Very little feedback was received on the last mail asking > for input on the actual details of such criteria. Therefore, in order > to move forward and establish the details of these criteria, please > find below a clear proposal of criteria for the initial PA Allocation > received by a newly established Local IR. > > Proposed Criteria for Initial /20 PA Allocation > ----------------------------------------------- > The Local IR is required to: > > - Demonstrate previous efficient utilisation of a /22 (1024 > addresses). > > Or > > - Demonstrate immediate need for a /22 > Take a start-up access provider x.net that wants to be multi-homed. This proposal in turn means x.net will either have to make up figures to create this immediate need or will have to start with PI space. Will they get PI space without having enough customers? - no! I think taken the policy, those providers will have to start their business being single-homed with PA address space from their upstream provider. This is a major disadvantage. Only after having a /22 filled, the company could start to apply for a LIR, a somewhat time-consuming process. With a successful business, x.net will already have a /21 of borrowed PA space announced. > Renumbering: > If current address space held by the Local IR amounts to a /22 or > less, the Local IR is required to renumber that address space into the > PA Allocation it will receive from the RIPE NCC. Once x.net has reached the status of a LIR they can become multi-homed. Will they get their address space routed? Only if it is declared PI. If so, they should definitely not be forced to renumber. If x.net uses other one's PA so far, they will have to renumber for routability. X.net will have to approach their customers to renumber their network. Who of the readers would choose x.net as provider where you know you'd have to renumber at some stage? This is the second major disadvantage. > Can the lir-wg agree with the above proposed criteria? > If no further objections are raised I would like to suggest that the > RIPE NCC moves forward and implements this policy. > Honestly, I believe the community should take measures to preserve address space. The lowering of the initial assignment to /20 was such a measure. The proposal to revoke allocations is another good one. But I do object to this proposal, although our company is beyond this stage. > Please let us know if you are not in agreement with the above. > > Kind regards, > > Nurani Nimpuno > > +------------------------------------+ > | Nurani Nimpuno | > | Internet Address Policy Manager | > | RIPE Network Co-ordination Centre | > | http://www.ripe.net | > +------------------------------------+ > Kind regards Karsten - ------------------------------------------------------------- Karsten Koepp Core network planning IP Lambdanet Communications GmbH (AS13237) FirstMark Communications GmbH Guenther-Wagner-Allee 13 D-30177 Hannover (Germany) Phone +49 (0)511 / 84 88 - 12 55 Fax +49 (0)511 / 84 88 - 12 69 Mobile +49 (0)178 / 3 62 - 12 55 mailto:Karsten.Koepp at firstmark.de News & Facts finden Sie auf unserer Website: www.firstmark.de - ------------------------------------------------------------- ------- End of Forwarded Message From hph at online.no Thu Jun 21 13:51:47 2001 From: hph at online.no (Hans Petter Holen) Date: Thu, 21 Jun 2001 13:51:47 +0200 Subject: Initial PA Allocation Criteria References: <39F27E3F569FD4119EF200508BAF85B90197BD7E@CCGNT30> Message-ID: <004201c0fa48$8dc3e9b0$b90000c1@hph> | after having read several opinions in this thread, | I still don't agree to some points. I do think, | the policy as proposed would represent a drawback | for start-ups entering the market. But how do you propose to deal with that ? Lower the initial requirement to some lower percentage ? -hph From Daniel.Karrenberg at ripe.net Thu Jun 21 10:24:59 2001 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 21 Jun 2001 10:24:59 +0200 Subject: Private address and static IP as an commercial offer. In-Reply-To: References: <5.0.2.1.0.20010614133736.023dc8e0@mail.telekom.gov.tr> <20010614190435.A17832@Space.Net> Message-ID: <4.3.2.7.2.20010621101308.01c8fc40@localhost.ripe.net> At 09:48 AM 18.6.01, Randy Bush wrote: >what benefits are there? and before you say "security" please go read >just about any mailing list archive. The immediate benefit is that you can use a *large* amount of address space. This allows you to make an addressing plan that matches the current and expected structure of your network much better than the smaller amount that is strictly necessary according to the assignment rules for public address space. If your network is of a mainly private nature with well defined needs for external connectivity that are not expected to change rapidly, NAT is an option. If you want your hosts on the Internet all the time and want to be able to meet the needs of new applications quickly then NAT is probably not a good idea. At home I run a neighbourhood network behind a NAT. The reason to choose for a NAT here is to allow for easy build-out and extension with an un-plannable number of hosts. Basically each house has a largish block of DHCP distributed addresses. This way people do not have to interact with me when they connect a new machine. You won't believe how many computers have surfaced in some homes. The newest fad is laptoys. Still I have had no complaints about services people cannot use. Daniel From dp at planning.viaginterkom.de Thu Jun 21 11:38:41 2001 From: dp at planning.viaginterkom.de (Dave Pratt) Date: Thu, 21 Jun 2001 11:38:41 +0200 (MET DST) Subject: Initial PA Allocation Criteria In-Reply-To: <39F27E3F569FD4119EF200508BAF85B90197BD7E@CCGNT30> Message-ID: Hiya all, I am afraid I too must agree with this point of view (and we are also beyond the start up stage :). Perhaps a clause to permit allocations to organisations that provide or can prove intent to provide commercial services to third parties should be added. This clause would remove the obligation to have previously effectively used a /22, and thereby with correct planning also the requirement to renumber (themselves and their customers). Otherwise, I am all in favour - keep up the good work. Cheers Dave On Wed, 20 Jun 2001, Koepp, Karsten wrote: ->Hi, -> ->after having read several opinions in this thread, ->I still don't agree to some points. I do think, ->the policy as proposed would represent a drawback ->for start-ups entering the market. -> ->> -----Urspruengliche Nachricht----- ->> Von: RIPE NCC Staff [SMTP:ncc at ripe.net] ->> Gesendet am: Freitag, 15. Juni 2001 17:06 ->> An: lir-wg at ripe.net ->> Betreff: Initial PA Allocation Criteria ->> ->> Dear all, ->> ->> Further to my mail on PA Allocation criteria (see below), here ->follows ->> a concrete proposal, including details of the actual criteria to be ->> determined. Very little feedback was received on the last mail asking ->> for input on the actual details of such criteria. Therefore, in order ->> to move forward and establish the details of these criteria, please ->> find below a clear proposal of criteria for the initial PA Allocation ->> received by a newly established Local IR. ->> ->> Proposed Criteria for Initial /20 PA Allocation ->> ----------------------------------------------- ->> The Local IR is required to: ->> ->> - Demonstrate previous efficient utilisation of a /22 (1024 ->> addresses). ->> ->> Or ->> ->> - Demonstrate immediate need for a /22 ->> -> ->Take a start-up access provider x.net that wants to be ->multi-homed. ->This proposal in turn means x.net will either have to ->make up figures to create this immediate need or will ->have to start with PI space. Will they get PI space ->without having enough customers? - no! ->I think taken the policy, those providers will have ->to start their business being single-homed with PA ->address space from their upstream provider. This is ->a major disadvantage. ->Only after having a /22 filled, the company could start to ->apply for a LIR, a somewhat time-consuming process. With ->a successful business, x.net will already have a /21 of ->borrowed PA space announced. -> -> ->> Renumbering: ->> If current address space held by the Local IR amounts to a /22 or ->> less, the Local IR is required to renumber that address space into ->the ->> PA Allocation it will receive from the RIPE NCC. -> ->Once x.net has reached the status of a LIR they can become multi-homed. ->Will they get their address space routed? Only if it is declared PI. ->If so, they should definitely not be forced to renumber. If x.net uses ->other one's PA so far, they will have to renumber for routability. ->X.net will have to approach their customers to renumber their network. ->Who of the readers would choose x.net as provider where you know you'd ->have to renumber at some stage? ->This is the second major disadvantage. -> ->> Can the lir-wg agree with the above proposed criteria? ->> If no further objections are raised I would like to suggest that the ->> RIPE NCC moves forward and implements this policy. ->> -> ->Honestly, I believe the community should take measures to preserve ->address space. The lowering of the initial assignment to /20 was such a ->measure. The proposal to revoke allocations is another good one. ->But I do object to this proposal, although our company is beyond this ->stage. -> ->> Please let us know if you are not in agreement with the above. ->> ->> Kind regards, ->> ->> Nurani Nimpuno ->> ->> +------------------------------------+ ->> | Nurani Nimpuno | ->> | Internet Address Policy Manager | ->> | RIPE Network Co-ordination Centre | ->> | http://www.ripe.net | ->> +------------------------------------+ ->> ->Kind regards ->Karsten -> ->- ------------------------------------------------------------- ->Karsten Koepp ->Core network planning IP -> ->Lambdanet Communications GmbH (AS13237) ->FirstMark Communications GmbH ->Guenther-Wagner-Allee 13 ->D-30177 Hannover (Germany) -> ->Phone +49 (0)511 / 84 88 - 12 55 ->Fax +49 (0)511 / 84 88 - 12 69 ->Mobile +49 (0)178 / 3 62 - 12 55 ->mailto:Karsten.Koepp at firstmark.de -> ->News & Facts finden Sie auf unserer Website: www.firstmark.de ->- ------------------------------------------------------------- -> -> -> -> ->------- End of Forwarded Message -> -> From Karsten.Koepp at lambdanet.net Thu Jun 21 15:08:05 2001 From: Karsten.Koepp at lambdanet.net (Koepp, Karsten) Date: Thu, 21 Jun 2001 15:08:05 +0200 Subject: AW: Initial PA Allocation Criteria Message-ID: <39F27E3F569FD4119EF200508BAF85B90197BD86@CCGNT30> Hans Petter and all, I am not quite determined about the alternative. Yes, I think the initial requirement needs to be less then the /22, admitting that the situation will then not change dramatically, because a /24 is easy to prove. Concerning Dave's proposal: >Perhaps a clause to permit allocations to organisations that provide or can >prove intent to provide commercial services to third parties should be added. Who else is applying for a LIR? Couldn't everybody claim that? What about the already raised proposal to set-up a usage criteria and to (maybe bi-annually) revise allocations? Could that be handled from the NCC? And are we gonna have a further increase of LIR applications over the years to come? Is it worth it? More questions then answers. Regards Karsten > Von: Hans Petter Holen [SMTP:hph at online.no] > Gesendet am: Donnerstag, 21. Juni 2001 13:52 > An: Koepp, Karsten; lir-wg at ripe.net > Betreff: Re: Initial PA Allocation Criteria > > | after having read several opinions in this thread, > | I still don't agree to some points. I do think, > | the policy as proposed would represent a drawback > | for start-ups entering the market. > > But how do you propose to deal with that ? > Lower the initial requirement to some lower percentage ? > > -hph > From sabrina at ripe.net Thu Jun 21 19:22:48 2001 From: sabrina at ripe.net (Sabrina Waschke) Date: Thu, 21 Jun 2001 19:22:48 +0200 Subject: ARIN to Allocate from 67.0.0.0/8 and 68.0.0.0/8 (fwd) Message-ID: <200106211722.TAA01809@birch.ripe.net> Dear all, [Apologies for duplicate messages] Please see below ARIN's announcement of their new allocations. Kind regards, Sabrina Waschke Registration Services Operations Manager RIPE NCC ------- Forwarded Message Date: Thu, 21 Jun 2001 08:35:57 -0400 From: "Richard Jimmerson" To: , , , , Subject: ARIN to Allocate from 67.0.0.0/8 and 68.0.0.0/8 In the near future, ARIN will begin making allocations from 67.0.0.0/8 and 68.0.0.0/8. This will include allocations of /20 and shorter prefixes, according to ARIN's minimum allocation policy. For informational purposes, a list of ARIN's currently administered blocks can be found at http://www.arin.net/regserv/IPStats.html Regards, Richard Jimmerson Director of Operations American Registry for Internet Numbers (ARIN) ------- End of Forwarded Message From djp-ripe-lists at planning.viaginterkom.de Fri Jun 22 09:13:22 2001 From: djp-ripe-lists at planning.viaginterkom.de (Dave Pratt) Date: Fri, 22 Jun 2001 09:13:22 +0200 (MET DST) Subject: AW: Initial PA Allocation Criteria In-Reply-To: <39F27E3F569FD4119EF200508BAF85B90197BD86@CCGNT30> Message-ID: On Thu, 21 Jun 2001, Koepp, Karsten wrote: ->Concerning Dave's proposal: ->>Perhaps a clause to permit allocations to organisations that provide or can ->>prove intent to provide commercial services to third parties should be ->added. -> ->Who else is applying for a LIR? Couldn't everybody claim ->that? As I see it there are two main types of application. 1. ISP like folks with customers who I think everyone would agree need their own allocation as soon as possible. 2. Large (and not so large) organisations who become an LIR just to obtain a globally routable prefix for Multihoming purposes. My suggested clause should allow us to apply different policies to the two types of applicant. Cheers Dave From hph at online.no Mon Jun 25 00:48:26 2001 From: hph at online.no (Hans Petter Holen) Date: Mon, 25 Jun 2001 00:48:26 +0200 Subject: Call for Nominations for Representatives to the ASO Address Council - RIPE region Message-ID: <003301c0fcff$c8878ac0$0a00000a@hph> Dear colleagues, This is a call for nominations of individuals from the RIPE region to serve on the ASO Address Council. During October 2001, one RIPE region Address Council seat will become vacant and will be filled for the next three years by an individual nominated through this open call. This document describes the functions of the ASO and the Address Council, as well as the nomination and selection processes. If you are interested in nominating an individual, or if you are interested in being nominated as a member of the Address Council, please read this document carefully. 1. The Address Supporting Organisation - -------------------------------------- The ASO was formed in August 1999 as a consensus-based advisory body within the ICANN Framework, though a Memorandum of Understanding (MoU) signed by the current Regional Internet Registries and ICANN. The ICANN Bylaws (http://www.icann.org/general/bylaws.htm#VI-A) assign to the ASO the responsibility for the development of global policies relating to the distribution and registration of Internet address space, inter-domain routing identifiers and that part of the DNS name space that is used to name these addresses and identifiers. More information about the ASO is available at: http://www.aso.icann.org 2. The Address Council - ---------------------- The ASO Address Council co-ordinates the process of policy development in areas within the responsibility of the ASO, according to procedures defined within the MoU and by the AC itself. Specifically, these include the hosting of an annual open General Assembly meeting, and attending regular meetings by teleconference or in person at which policy issues and submissions may be considered. The other major responsibility of the Address Council is the appointment of individuals to fill ASO seats on the ICANN Board of Directors, according to procedures defined within the MoU. More information on the Address Council is available at: http://www.aso.icann.org/ac 3. The Role of Members of the Address Council - --------------------------------------------- Members of the Address Council do not represent any RIR, nor do they act as representatives of any other body. They are appointed in their individual capacity, and their membership cannot be proxied by any other individual or organisation. No member of the Address Council is entitled to any compensation from the ASO. No member can be indemnified by the ASO, nor can the ASO obtain insurance coverage relating to the liability of the actions of members of the Address Council. 4. Address Council Nominations Process - -------------------------------------- Through this nomination process, one individual from the RIPE region will be selected to serve on the Address Council for three years, replacing Hans Petter Holen who has served as an initial AC member for the past 2 years. The selection will be made though an open election from the set of individuals who have been nominated within this process. Any individual may be nominated, with the exception of any staff member of any Regional Internet Registry. Self-nominations are permitted. Nominations should be sent by email to , by midnight UTC on 5 September 2001. The information included with the nomination is to be in English and should include: Name of Nominee: Country of residence: Organisation: Email Address: Postal Address: Biographical information: Motivation for nomination: Name of nominating individual: Organisation: Email Address: All nominees will be contacted via email to confirm their willingness to serve on the Address Council. If a nominee is not contactable via email, or does not respond, then their nomination will not be confirmed and they will not be eligible for election to the Address Council. All confirmed nominations will be listed on the RIPE web site after they are confirmed. All nominees will have the opportunity to submit a written statement in support of their nomination, for publication on the web site. In addition, others may express support for nominated individuals simply by completing and submitting the nomination form provided above. 5. Address Council Selection Process - ------------------------------------ The process for selection of the nominee to serve on the Address Council will involve an open election to be held during the plenary session of the RIPE 40 Meeting, in Prague, Czech Republic, on 5 October 2001. See the following URL for details about the selection procedure: http://www.ripe.net/ripe/wg/lir/adress_council-election.html More information about RIPE 40 will be available shortly at: http://www.ripe.net/ripe/meetings http://www.ripe.net/ripe/meetings/current/ripe-40/ Important Dates: 5 September 2001 - deadline for Address Council nominations Regards, Hans Petter Holen Local IR WG chair From Robert.Kiessling at de.easynet.net Sat Jun 23 20:48:41 2001 From: Robert.Kiessling at de.easynet.net (Robert Kiessling) Date: Sat, 23 Jun 2001 20:48:41 +0200 Subject: IPv6 addresses for Exchange Points Message-ID: <15156.58505.166846.807175@doncamillo.local.easynet.de> The discussion on the issue of IPv6 allocations for exchange points seems to stagnate, and to me it looks like an agreement might be close. Could we expect a new suggestion from RIPE incorporating the previous discussion, together with remaining open questions? Exchanges have been waiting for many months, so a solution is overdue. Robert From ripe-dbm at ripe.net Mon Jun 25 12:08:36 2001 From: ripe-dbm at ripe.net (RIPE Database Administration) Date: Mon, 25 Jun 2001 12:08:36 +0200 Subject: Unprocessed update mails to RIPE Whois Database Message-ID: <200106251008.MAA20663@x47.ripe.net> Dear Colleagues, [apologies for duplicate messages] Between Thu Jun 14 16:19:15 2001 CEST and Fri Jun 15 10:34:29 2001 CEST, due to a failure in our systems which processes updates to RIPE Whois Database, the update message have not been processed, instead they were only stored. Most of the users who sent those messages noticed that they didn't get any acknowledgement from our system, and re-sent their updates. Realizing the failure on Friday Jun 22, we tried to find out those messages which were _not_ re-sent by the user, and we processed them. Thus, please don't be confused if you've got a late acknowledgement message. If you have any questions about the incident, please contact . We are sorry about the inconvenience this caused. Best Regards, Engin Gunduz RIPE NCC Database Group From mir at ripe.net Mon Jun 25 16:14:46 2001 From: mir at ripe.net (Mirjam Kuehne) Date: Mon, 25 Jun 2001 16:14:46 +0200 Subject: IPv6 addresses for Exchange Points In-Reply-To: Your message of Sat, 23 Jun 2001 20:48:41 +0200. <15156.58505.166846.807175@doncamillo.local.easynet.de> Message-ID: <200106251414.QAA12963@kantoor.ripe.net> Robert, Thanks for picking this up. We are currently working on a summary of the discussion. I will send it out tomorrow. Mirjam Kuehne RIPE NCC Robert Kiessling writes: * The discussion on the issue of IPv6 allocations for exchange points * seems to stagnate, and to me it looks like an agreement might be * close. * * Could we expect a new suggestion from RIPE incorporating the previous * discussion, together with remaining open questions? * * Exchanges have been waiting for many months, so a solution is overdue. * * Robert * * From mir at ripe.net Tue Jun 26 12:22:51 2001 From: mir at ripe.net (Mirjam Kuehne) Date: Tue, 26 Jun 2001 12:22:51 +0200 Subject: IPv6 for IXPs Message-ID: <200106261022.MAA13240@x30.ripe.net> Dear all, After the active discussion regarding IPv6 address for Internet Exchange Points (IXPs), we now need to come to a conclusion. I have reviewed the discussion again and will try to summarise it (quite a challenge :-). Many issues were raised, but so far no clear consensus was reached. Please bare with me if I have not included all opinions and comments or if some submissions are not summarised accurately. However, I hope that this summary will spark some further discussions and hopefully a conslusion at the end. I cc the eix-wg mailing list here and would like to explicitely encourage IXP operators to actively participate in this discussion. Kind Regards, Mirjam Kuehne RIPE NCC ---------- The following questions were raised during the discussion: 1. Is a special policy needed for IXPS (and following from this possibly also for other 'special purposes'? 2. What is the intended use of the addresses at the IXPs? 3. How is an IXP defined? 4. What size should be assigned? 1. special policy needed? ------------------------- Many participants believed that a policy for IXPs is needed, because they usually do not have an upstream provider and also do not want to use addresses from one of their members (for political rather than technical reasons). Some participants however felt that no special policy is needed for IXPs. They should either be treated as an end-user network or should be able to get a 'normal' (currently a /35) IPv6 allocation from the RIRs. 2. intended use of the addresses? ---------------------------------- Special policy would only be needed for addresses needed for the Exchange Point medium itself (usually a layer-2 network). Addresses needed for other purposes (e.g. additional services provided to the members) should be assigned by upstream ISPs. It was also discussed if the addresses should actually be announced. It was felt that this is not really necessary, but that some IXPs do it anyway. There was no conclusion if this should be part of the policy (e.g. the micro-allocation policy implemented in the ARIN region does require that the prefix is not announced). One option would be to warn the IXP that these addresses are likely not to be globally routable. 3. definition of an IXP ----------------------- It was generally felt that it is difficult to define an IXP, but that the following refined definition could be used as a starting point: Three or more ASes and thee or more separate entities attached to a LAN (a common layer 2 infrastructure) for the purpose of peering and more are welcome to join. 4. assignment size? ------------------- Some participants felt that a /64 would be appropriate if the IXP would consist of only one subnet. In all other cases a /48 should be assigned (this would be consistent with the IESG/IAB recommendation). Others felt that the address size should not be pre-defined, but should be based on need and discussed on a case-by-case basis between the requestor and the RIR. 5. Other issues raised ---------------------- Requests should only be sent by established LIRs or via an existing LIR. Reverse delegation would have to be done by the RIR (requested also via an existing LIR) From Robert.Kiessling at de.easynet.net Tue Jun 26 13:18:34 2001 From: Robert.Kiessling at de.easynet.net (Robert Kiessling) Date: Tue, 26 Jun 2001 13:18:34 +0200 Subject: IPv6 for IXPs In-Reply-To: <200106261022.MAA13240@x30.ripe.net> References: <200106261022.MAA13240@x30.ripe.net> Message-ID: <15160.28554.102524.789261@doncamillo.local.easynet.de> Mirjam, thank you for the summary. My EUR 0.02 follow. Mirjam Kuehne writes: > 1. Is a special policy needed for IXPS (and following from this > possibly also for other 'special purposes'? > 2. What is the intended use of the addresses at the IXPs? > 3. How is an IXP defined? > 4. What size should be assigned? > > > 1. special policy needed? Yes. Most exchange points are supposed to be neutral, so address space should be available to support that. This leaves the choice to the IXP whether to use neutral, non-routable or LIR-bound routable space, or get an IPv6 allocation themselves. > 2. intended use of the addresses? > ---------------------------------- > > Special policy would only be needed for addresses needed for the > Exchange Point medium itself (usually a layer-2 network). Ack. > One option would be to warn the IXP that these addresses are likely > not to be globally routable. I would make the wording for this as strong as possible and thus prefer "may not be globally announced", but that might not be possible since this is hard to define and RIPE's authority over this is questionable. So maybe something like "strongly discouraged to announce the addresses and likely not to be globally routable"? > 3. definition of an IXP > ----------------------- > > Three or more ASes and thee or more separate entities attached to a > LAN (a common layer 2 infrastructure) for the purpose of peering and > more are welcome to join. Fine. I don't think we should make this too strict, since there's enough /48 blocks available even for some "fake" IXPs. > 4. assignment size? > ------------------- > > Some participants felt that a /64 would be appropriate if the IXP > would consist of only one subnet. In all other cases a /48 should be > assigned (this would be consistent with the IESG/IAB recommendation). A /48 should also be assigned if the IXP only plans to expand to multiple networks. Apart from that I think we should indeed stick to standard assignment sizes as suggested. Robert From woeber at cc.univie.ac.at Tue Jun 26 15:30:04 2001 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 26 Jun 2001 15:30:04 +0200 Subject: IPv6 for IXPs Message-ID: <009FE1DD.562FC096.4@cc.univie.ac.at> >To: lir-wg at ripe.net >CC: eix-wg at ripe.net >Subject: IPv6 for IXPs >Date: Tue, 26 Jun 2001 12:22:51 +0200 >From: Mirjam Kuehne > >Dear all, > >After the active discussion regarding IPv6 address for Internet >Exchange Points (IXPs), we now need to come to a conclusion. I have >reviewed the discussion again and will try to summarise it (quite a >challenge :-). Many issues were raised, but so far no clear consensus >was reached. > >Please bare with me if I have not included all opinions and comments >or if some submissions are not summarised accurately. > >However, I hope that this summary will spark some further discussions >and hopefully a conslusion at the end. > >I cc the eix-wg mailing list here and would like to explicitely >encourage IXP operators to actively participate in this discussion. > >Kind Regards, > >Mirjam Kuehne >RIPE NCC >---------- > >The following questions were raised during the discussion: > >1. Is a special policy needed for IXPS (and following from this > possibly also for other 'special purposes'? >2. What is the intended use of the addresses at the IXPs? >3. How is an IXP defined? >4. What size should be assigned? > > >1. special policy needed? >------------------------- > >Many participants believed that a policy for IXPs is needed, because >they usually do not have an upstream provider and also do not want to >use addresses from one of their members (for political rather than >technical reasons). I strongly feel that leaving the term "political reasons" in here (and maybe even allow that to creep into some archive procedural description is setting off a time bomb! The "weakest" term I would accept (instead of requiring _technical_ reasons from the beginning) is "for reasons of stable operations"). >Some participants however felt that no special policy is needed for >IXPs. They should either be treated as an end-user network or should >be able to get a 'normal' (currently a /35) IPv6 allocation from the >RIRs. > > >2. intended use of the addresses? >---------------------------------- > >Special policy would only be needed for addresses needed for the >Exchange Point medium itself (usually a layer-2 network). Addresses >needed for other purposes (e.g. additional services provided to the >members) should be assigned by upstream ISPs. I fully agree with that, but at the same time this requiremet weakens the overall reasoning. Just as an observation. >It was also discussed if the addresses should actually be >announced. It was felt that this is not really necessary, but that >some IXPs do it anyway. There was no conclusion if this should be part >of the policy (e.g. the micro-allocation policy implemented in the >ARIN region does require that the prefix is not announced). > >One option would be to warn the IXP that these addresses are likely >not to be globally routable. I really like the proposal by Robert.Kiessling: "strongly discouraged to announce the addresses and likely not to be globally routable"? >3. definition of an IXP >----------------------- > >It was generally felt that it is difficult to define an IXP, but that >the following refined definition could be used as a starting point: What do you intend by saying "as a starting point"? >Three or more ASes and thee or more separate entities attached to a >LAN (a common layer 2 infrastructure) for the purpose of peering and >more are welcome to join. For the moment this seems to take care of the situations mentioned during the meeting. However, it might be too fuzzy in general - and too specific as regards the transport mechanism for the packets being exchanged according to the peering agreement. E.g. I might agree with 2 of my students to build an exchange point for IPv6 packets, but we would prefer to use the existing IPv4-based internet as a transport mechanism. Would that be compatible with "(a common layer 2 infrastructure)"? I don't have a better proposal for the moment, unfortunately, but I would like to see (hear :-) people think about those aspects. >4. assignment size? >------------------- > >Some participants felt that a /64 would be appropriate if the IXP >would consist of only one subnet. In all other cases a /48 should be >assigned (this would be consistent with the IESG/IAB recommendation). > >Others felt that the address size should not be pre-defined, but >should be based on need and discussed on a case-by-case basis between >the requestor and the RIR. Go for the provisions as outlined in the IAB/IESG Recommendation, and if in doubt, assign the bigger block. >5. Other issues raised >---------------------- > >Requests should only be sent by established LIRs or via an existing >LIR. Please s/should/must/ !! >Reverse delegation would have to be done by the RIR (requested also >via an existing LIR) Agreed. 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 mir at ripe.net Tue Jun 26 16:51:14 2001 From: mir at ripe.net (Mirjam Kuehne) Date: Tue, 26 Jun 2001 16:51:14 +0200 Subject: IPv6 for IXPs In-Reply-To: Your message of Tue, 26 Jun 2001 15:30:04 +0200. <009FE1DD.562FC096.4@cc.univie.ac.at> Message-ID: <200106261451.QAA14158@x30.ripe.net> Wilfried, "Wilfried Woeber, UniVie/ACOnet" writes: [..] * * >3. definition of an IXP * >----------------------- * > * >It was generally felt that it is difficult to define an IXP, but that * >the following refined definition could be used as a starting point: * * What do you intend by saying "as a starting point"? * I meant "as starting point for this discussion". In the end I hope we will have a definition we can all agree or live with. Mirjam RIPE NCC From randy at psg.com Tue Jun 26 17:40:21 2001 From: randy at psg.com (Randy Bush) Date: Tue, 26 Jun 2001 08:40:21 -0700 Subject: IPv6 for IXPs References: <200106261022.MAA13240@x30.ripe.net> <15160.28554.102524.789261@doncamillo.local.easynet.de> Message-ID: >> One option would be to warn the IXP that these addresses are likely >> not to be globally routable. > I would make the wording for this as strong as possible and thus > prefer "may not be globally announced", but that might not be possible > since this is hard to define and RIPE's authority over this is > questionable. So maybe something like "strongly discouraged to > announce the addresses and likely not to be globally routable"? and the level of indirection, it's the isps not the exchange which announces, makes it hard for the ix to act on this suggested policy (with which i agree, as well as your other points, fwiw) randy From cfriacas at fccn.pt Tue Jun 26 17:53:41 2001 From: cfriacas at fccn.pt (Carlos Friacas) Date: Tue, 26 Jun 2001 16:53:41 +0100 (WEST) Subject: IPv6 for IXPs In-Reply-To: <200106261022.MAA13240@x30.ripe.net> Message-ID: On Tue, 26 Jun 2001, Mirjam Kuehne wrote: > 3. How is an IXP defined? > (...) > > 3. definition of an IXP > ----------------------- > > It was generally felt that it is difficult to define an IXP, but that > the following refined definition could be used as a starting point: > > > Three or more ASes and thee or more separate entities attached to a > LAN (a common layer 2 infrastructure) for the purpose of peering and > more are welcome to join. My way of writing it, would be: "Three or more ASes owned/managed by 3 or more separate entities attached to a common layer 2 infrastructure, for the purpose of peering." - I dont see an IXP necessarily as a LAN. An IXP can be distributed geographically, so the IXP infrastructure can really be called a WAN. - The same way we dont refer what kind of peering is done (BGPv4, normally) i think we shouldnt limit the definition introducing the "more are welcome to join" part... Of course i want all IXPs to grow (regarding the number of peers) and especially the one i manage :-), but i feel this "welcome call" is more just another "political" issue. Thanks, ./Carlos "Networking is fun!" ------------------- , CMF8-RIPE, Wide Area Network WorkGroup http://www.fccn.pt F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax: +351 218472167 From Henk.Steenman at icoe.att.com Wed Jun 27 10:29:57 2001 From: Henk.Steenman at icoe.att.com (Henk Steenman) Date: Wed, 27 Jun 2001 10:29:57 +0200 Subject: IPv6 for IXPs In-Reply-To: <200106261022.MAA13240@x30.ripe.net> Message-ID: <5.1.0.14.2.20010627102005.02c27ea8@135.76.170.11> >3. definition of an IXP >----------------------- > >It was generally felt that it is difficult to define an IXP, but that >the following refined definition could be used as a starting point: > > >Three or more ASes and thee or more separate entities attached to a >LAN (a common layer 2 infrastructure) for the purpose of peering and >more are welcome to join. A physical network infrastructure operated by a single entity with the purpose to facilitate the exchange of Internet traffic between Internet service providers. The number of Internet Service providers connected should at least be three and there must be a clear and open policy for others to join. - Henk From mir at ripe.net Thu Jun 28 20:22:44 2001 From: mir at ripe.net (Mirjam Kuehne) Date: Thu, 28 Jun 2001 20:22:44 +0200 Subject: IPv6 for IXPs Message-ID: <200106281822.UAA07103@x30.ripe.net> Dear all, how about this (thanks to Henk): Definition: A physical network infrastructure (layer 2) operated by a single entity with the purpose to facilitate the exchange of Internet traffic between Internet service providers. The number of Internet Service providers connected should at least be three and there must be a clear and open policy for others to join. Addresses needed for other purposes (e.g. additional services provided to the members) should be assigned by upstream ISPs. Assignment size: - a /48 in most cases - a /64 if it is known that there will only be one subnet (basically following the IAB recommendation) Additional warning: The RIRs should warn the IXP that it is strongly discouraged to announce the addresses and that they will likely not to be globally routable. If this is agreeable the RIPE NCC will implement this policy and co-ordinate it with the other Regional Internet Registries. Mirjam Kuehne RIPE NCC From randy at psg.com Thu Jun 28 20:54:16 2001 From: randy at psg.com (Randy Bush) Date: Thu, 28 Jun 2001 11:54:16 -0700 Subject: IPv6 for IXPs References: <200106281822.UAA07103@x30.ripe.net> Message-ID: wording quibbles: > Addresses needed for other purposes (e.g. additional services provided > to the members) should be assigned by upstream ISPs. s/assigned by upstream ISPs/acquired through other appropriate means/ could be that the ix operator could qualify for normally allocated space all by themselves. > - a /48 in most cases > - a /64 if it is known that there will only be one subnet > (basically following the IAB recommendation) i suspect the 'most cases' is the /64, a single exchange mesh, and that the multiple interconnected meshes, which whould need the /48, is a rare case. > The RIRs should warn the IXP that it is strongly discouraged to > announce the addresses and that they will likely not to be globally > routable. the ix does not annouce mesh address. isps on the mesh may. so i would say the rirs should warn the ixp that isps usually do not announce mesh space to their peers, so that the ix space allocated under this policy is likely not to be visible globally. randy From gert at space.net Thu Jun 28 21:54:27 2001 From: gert at space.net (Gert Doering) Date: Thu, 28 Jun 2001 21:54:27 +0200 Subject: IPv6 for IXPs In-Reply-To: <200106281822.UAA07103@x30.ripe.net>; from mir@ripe.net on Thu, Jun 28, 2001 at 08:22:44PM +0200 References: <200106281822.UAA07103@x30.ripe.net> Message-ID: <20010628215427.O70191@Space.Net> Hi, On Thu, Jun 28, 2001 at 08:22:44PM +0200, Mirjam Kuehne wrote: > how about this (thanks to Henk): [..] I like it (for the number of reasons already mentioned in the lists and in the WG meeting). 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 Robert.Kiessling at de.easynet.net Fri Jun 29 02:55:31 2001 From: Robert.Kiessling at de.easynet.net (Robert Kiessling) Date: Fri, 29 Jun 2001 02:55:31 +0200 Subject: IPv6 for IXPs In-Reply-To: References: <200106281822.UAA07103@x30.ripe.net> Message-ID: <15163.53763.137022.686955@doncamillo.local.easynet.de> Randy Bush writes: > > [Things looking good to me] > > The RIRs should warn the IXP that it is strongly discouraged to > > announce the addresses and that they will likely not to be globally > > routable. > > the ix does not annouce mesh address. isps on the mesh may. so i would say The address space is assigned to the IXP, so the IXP has authority to disallow any announcement. Thus IMHO it's sufficient to address the IXP. Robert From paul.mylotte at bt.com Fri Jun 29 10:51:47 2001 From: paul.mylotte at bt.com (paul.mylotte at bt.com) Date: Fri, 29 Jun 2001 09:51:47 +0100 Subject: IPv6 addresses for IXPs Message-ID: In the RIPE Policy Statement under development I think we should state explicitely the support for both types of IPv6 exchanges, viz: 1 allocate addresses for IPv6 exchange infrastructure only (no > onwards allocation in the manner of a backbone ISP). > 2 allocate a sub TLA to the IPv6 exchange which will then act > in the manner of an ISP and allocate downstream. > > In order to progress this, I would like to propose: > 1 IPv6 exchanges that need addresses for the purpose of internal > addressing can apply for the addresses already set aside for this > purpose and held by IANA, as per RFC2928 (Initial IPv6 Sub-TLA ID Assignments) and RFC2450 (Proposed TLA and NLA Assignment Rules). In this case a /48 allocation will be sufficient. (How IPv6 > exchanges should apply for these addresses is out of scope > - either direct to IANA, or IANA allocates down to RIRs first). > 2 IPv6 exchanges that plan to onward allocate addresses in the > manner of an ISP should apply via the existing mechanism. The > existing mechanism is currently being reviewed and this review > should take account of any changes necessary to include IPv6 > exchanges explicitly desiring addresses for onward allocation as > being acceptable candidates for address space. > > > > Regards, > > Paul > > P. S. Mylotte > BTexact Technologies > Adastral Park > 01473 606333 / + 44 1473 606333 > paul.mylotte at bt.com > > BTexact Technologies is a trademark of British Telecommunications plc > Registered office 81 Newgate Street London EC1A 7AJ > Registered in England no. 1800000 > > This electronic message contains information from British > Telecommunications plc which may be priveleged or confidential. The > information is intended to be for the use of the individual(s) or entity > named above. If you are not the intended recipient be aware that any > disclosure, copying, distribution or use of the contents of this > information is prohibited. If you have received this electronic message in > error, please notify us by telephone or email (to the number or address > above) immediately. > From keith at xchangepoint.net Fri Jun 29 12:00:31 2001 From: keith at xchangepoint.net (Keith Mitchell) Date: Fri, 29 Jun 2001 11:00:31 +0100 Subject: IPv6 for IXPs References: <200106281822.UAA07103@x30.ripe.net> Message-ID: <3B3C51BF.BEA67EF1@xchangepoint.net> Mirjam Kuehne wrote: > Definition: > > A physical network infrastructure (layer 2) operated by a single > entity with the purpose to facilitate the exchange of Internet traffic > between Internet service providers. The number of Internet Service > providers connected should at least be three and there must be a clear > and open policy for others to join. I think this is as good a definition of an IXP as we will get. > Addresses needed for other purposes (e.g. additional services provided > to the members) should be assigned by upstream ISPs. I still believe this principle compromises the operational neutrality aspirations of any well-managed IXP (see my previous posting), and it is very important as Randy proposes that there is an alternative means for an IXP to get IPv6 space for these purposes in its own right (e.g. as an LIR as per IPv4). > Assignment size: > > - a /48 in most cases > - a /64 if it is known that there will only be one subnet > (basically following the IAB recommendation) Sounds plenty. > Additional warning: > > The RIRs should warn the IXP that it is strongly discouraged to > announce the addresses and that they will likely not to be globally > routable. So long as this as a consequence of how the ISPs announce the space, and not due to any property of (other than I guess prefix length), or policy restrictions adhering to, the space itself, I don't have any particular issue with this, and we'll look at encouraging our customers to adopt good practice on peering mesh announcements. Keith http://www.xchangepoint.net/contact/keith/ From Robert.Kiessling at de.easynet.net Fri Jun 29 12:18:32 2001 From: Robert.Kiessling at de.easynet.net (Robert Kiessling) Date: Fri, 29 Jun 2001 12:18:32 +0200 Subject: IPv6 for IXPs In-Reply-To: References: <200106281822.UAA07103@x30.ripe.net> Message-ID: <15164.22008.395562.371620@doncamillo.local.easynet.de> Randy Bush writes: > > - a /48 in most cases > > - a /64 if it is known that there will only be one subnet > > (basically following the IAB recommendation) > > i suspect the 'most cases' is the /64, a single exchange mesh, and that the > multiple interconnected meshes, which whould need the /48, is a rare case. Well, I'd think it's more the case that a /64 is "single now, and never plans to need more" and /48 is "likely to need some more in future", thus shifting "most cases" towards /48. Robert From randy at psg.com Fri Jun 29 17:28:02 2001 From: randy at psg.com (Randy Bush) Date: Fri, 29 Jun 2001 08:28:02 -0700 Subject: IPv6 for IXPs References: <200106281822.UAA07103@x30.ripe.net> <15164.22008.395562.371620@doncamillo.local.easynet.de> Message-ID: >>> - a /48 in most cases >>> - a /64 if it is known that there will only be one subnet >>> (basically following the IAB recommendation) >> i suspect the 'most cases' is the /64, a single exchange mesh, and that >> the multiple interconnected meshes, which whould need the /48, is a rare >> case. > Well, I'd think it's more the case that a /64 is "single now, and > never plans to need more" and /48 is "likely to need some more in > future", thus shifting "most cases" towards /48. i think of an ix as more like an isp than an end user enterprise. we are careful to allocate to isps based on reality, not hallucinations from the marketing department. randy From randy at psg.com Fri Jun 29 17:28:02 2001 From: randy at psg.com (Randy Bush) Date: Fri, 29 Jun 2001 08:28:02 -0700 Subject: IPv6 for IXPs References: <200106281822.UAA07103@x30.ripe.net> <15164.22008.395562.371620@doncamillo.local.easynet.de> Message-ID: >>> - a /48 in most cases >>> - a /64 if it is known that there will only be one subnet >>> (basically following the IAB recommendation) >> i suspect the 'most cases' is the /64, a single exchange mesh, and that >> the multiple interconnected meshes, which whould need the /48, is a rare >> case. > Well, I'd think it's more the case that a /64 is "single now, and > never plans to need more" and /48 is "likely to need some more in > future", thus shifting "most cases" towards /48. i think of an ix as more like an isp than an end user enterprise. we are careful to allocate to isps based on reality, not hallucinations from the marketing department. randy