From nick at inex.ie Mon Mar 1 17:18:40 2010 From: nick at inex.ie (Nick Hilliard) Date: Mon, 01 Mar 2010 16:18:40 +0000 Subject: [address-policy-wg] 80% rule, based on feedback from the NCC RS department In-Reply-To: <20100226142807.GB56228@Space.Net> References: <20100226142807.GB56228@Space.Net> Message-ID: <4B8BE8E0.1030403@inex.ie> On 26/02/2010 14:28, Gert Doering wrote: > Now, "just changing the text according to what the WG chair thinks" would > not be the right thing - so what I think is the way forward now is to > get feedback from *you*, and if there is clear guidance from the working > group on resolving this ambiguity, we run a formal proposal to change the > wording of the document in one way or the other. > > (Please don't get into sidetrack discussions on whether "80%" or "IPv4" > is useful, but focus on this specific question.) (tl;dr contingent: you can safely scroll to the exec summary at the bottom). Rather than look at the immediate issue of which 80% rule trumps which, it may be instructive to be slightly naughty and examine how the allocation top-up mechanism works in practice. >From what I remember (and I'm open to correction here), RIPE currently uses interpretation #1. I.e. all allocations must be at least 80% full before the LIR is entitled to request more address space. The net effect of this policy is that where it's applied, the overall LIR utilisation will have a lower bound of 80%, but will generally be higher than 80% overall. If we move to interpretation #2, we're lowering the bound to exactly 80%. There are 6145 LIRs with ipv4 allocations defined in the following file: ftp://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt If you'll excuse me for being sufficiently rude to post code, the top 50 LIRs have been allocated 236595200 ipv4 addresses (about 14 /8s) out of a total allocation space of 474883072 allocated addresses (about 28 /8s). So that's a little less than 0.8% of the LIRs holding 50% of the address space. For the purposes of this argument, I am ignoring the fact that most of the larger service providers around Europe operate multiple LIRs, so the number of addresses allocated to the largest 50 ipv4 address space holders in Europe will probably well exceed 50%. Now, these LIRs are entitled to request more address space when all their allocations are 80% utilised. Taking the top 50 LIRs, this means that under the current utilisation policy, there is fully legitimate slack space of 47319040 addresses, or almost 3 x /8s. Which brings us back to the 80% policy. I have two observations about it: 1. changing the policy to interpretation #2 will probably increase the slack space by a small percentage, and taking only the top 50 LIRs into account, this will work out to be a large number of addresses. 2. the slack ipv4 address space allocations held by the large LIRs already represents a very large amount of address space indeed. I contend that there is a legitimate argument to say that when the RIPE NCC runs out of virgin IANA ipv4 space to allocate, the slack space held by the tiny number of larger LIRs will effectively be allocated to them to the very significant disadvantage of the much larger number of smaller LIRs. Put another way, the 80% rule is fine for smaller LIRs, but is very biassed in favour of larger LIRs. If we're thinking about looking at how the 80% rule is applied, it may be appropriate to take the opportunity to creating either a minimum utilisation curve which starts out at 80% and increases monotonically towards something significantly larger, or else a step / gradient system which starts out at 80% for the first /x chunk of address space, 85% for the next /y%, and so forth. Nick -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: summarise-allocs.pl URL: From davidm at futureinquestion.net Sat Mar 6 02:40:55 2010 From: davidm at futureinquestion.net (David Monosov) Date: Sat, 06 Mar 2010 02:40:55 +0100 Subject: [address-policy-wg] Re: [ncc-services-wg] Status Update - Independent Resource Assignments (Policy Proposal 2007-01) In-Reply-To: References: Message-ID: <4B91B2A7.70900@futureinquestion.net> Dear Andrew, ncc-services-wg, address-policy-wg, Thank you kindly for this update, it is encouraging to see the success of this initiative. I can't help but notice that the number of marked resources you provide in this report appears to be significantly lower than that in a similar report Andrea Cima provided to address-policy-wg on 26/10/2009 (the previous report states 23,790 resources are marked, while only 22,958 are reported as marked in this update). Could you please elaborate on the nature of this adjustment? Additionally, it has been previously mentioned that a procedural document detailing Phase 3 of the implementation of this proposal will be made available before implementation begins. Seeing that the final deadline is less than two months and a fortnight away, how soon can we expect this document to be available, and are there any operational specifics you can already share with us? -- Respectfully yours, David Monosov Andrew de la Haye wrote: > Dear Colleagues, > > In March 2009, the RIPE NCC began Phase 1 of the policy implementation > "Contractual Requirements for Provider Independent Resource Holders in > the RIPE NCC Service Region". This phase focused on new assignments of > independent Internet number resources only (PI assignments, AS Numbers, > IPv6 Internet Exchange Point (IXP) assignments and Anycasting > assignments). The implementation was carried out successfully and the > majority of RIPE NCC members are aware of the policy and contractual > requirements and are able to provide the necessary documentation when > requesting independent resources on behalf of their End Users. > > Phase 2 of the policy implementation began at the end of May 2009. This > phase focuses on existing assignments (almost 27,000). In the first step > of this phase, the RIPE NCC approached LIRs and asked them to specify > whether: > - The resources were used for the LIR's network infrastructure > - The resources were used by one of the LIR's End Users > - The End User was no longer the LIR's customer > > LIRs must provide documentation for the resources marked as "My End > User" by the end of Phase 2. This documentation should be the "End User > Assignment Agreement" between the LIR and the End User regarding the > registration of the independent Internet resources the End User holds > and the official company registration documents of the End User > organisation. > > Initially, Phase 2 was scheduled to end on 31 December 2009. However, > due to the lower-than-expected number of documents received, the > deadline was first extended until 1 March 2010 and then until 17 May > 2010, which will be the final deadline. > > > The figures showing the progress of Phase 2, as of 1 March 2010, are > presented below. > > > LIRs Participating > ----------------------- > Total LIRs to participate in Phase 2: 4,903 > Number of LIRs participated at 1 March: 4,178 > Percentage of participating LIRs: 85.2% > > > Total Resources Marked > ------------------------------ > Total amount of resources to be marked in Phase 2: 26,940 > Total amount of resources marked at 1 March: 22,958 > Percentage of resources marked: 85.2% > > > Status of 22,958 Resources Marked > ------------------------------------------ > - 5,373 are marked "My Infrastructure" (23.4%) by 3,956 LIRs > - 6,025 are marked "Not My End User" (26.25%) by 712 LIRs > - 11,560 are marked "My End User" (50.35%) by 996 LIRs > > > Status of 11,560 Resources Marked "My End User" > ------------------------------------------------------------- > - 4,849 have missing documents (42%) > - 4,522 have submitted documents (39%) > - 2,189 have approved documents (19%) > > > Regards, > Andrew de la Haye From arne at ripe.net Tue Mar 9 10:56:42 2010 From: arne at ripe.net (Arne Kiessling) Date: Tue, 09 Mar 2010 10:56:42 +0100 Subject: [address-policy-wg] Re: [ncc-services-wg] Status Update - Independent Resource Assignments (Policy Proposal 2007-01) In-Reply-To: <4B91B2A7.70900@futureinquestion.net> References: <4B91B2A7.70900@futureinquestion.net> Message-ID: <4B961B5A.6070701@ripe.net> Dear David, Thank you for your reply and enquiry. David Monosov wrote: > Dear Andrew, ncc-services-wg, address-policy-wg, > > Thank you kindly for this update, it is encouraging to see the success of this > initiative. > > I can't help but notice that the number of marked resources you provide in this > report appears to be significantly lower than that in a similar report Andrea > Cima provided to address-policy-wg on 26/10/2009 (the previous report states > 23,790 resources are marked, while only 22,958 are reported as marked in this > update). Could you please elaborate on the nature of this adjustment? The statistics that were used for the update dated 26 October 2009 were based on the logs of the policy application in the LIR Portal, which RIPE NCC members were using to mark the independent resources listed in their registries in the first step of Phase 2 of the policy implementation. The RIPE NCC has developed new software that improves the method of gathering these statistics. Instead of using the logs from the policy application in the LIR Portal as the source for the statistics, we now look at the status of the independent resources listed in the registry files of LIRs. This means the statistics are now definite and reflect the information we have on record. Additionally, this phase of the policy implementation has encouraged LIRs to return independent resources to the free pool that are not in use or required anymore. LIRs also approach the RIPE NCC on a daily basis in order to update the selection they have made during the first step of Phase 2 of the implementation. These changes have to be processed manually and would have not been included and visible in the previous version of the statistics. Furthermore, the RIPE NCC has processed mergers, takeovers and closures of LIRs in the time period since the last update was given. This has also had an influence on the numbers and statistics. For the reasons mentioned above, the total amount of resources marked in Phase 2 of the policy implementation that we provided in the recent update are slightly lower than the numbers provided in the update from 26 October 2009. > Additionally, it has been previously mentioned that a procedural document > detailing Phase 3 of the implementation of this proposal will be made available > before implementation begins. Seeing that the final deadline is less than two > months and a fortnight away, how soon can we expect this document to be > available, and are there any operational specifics you can already share with us? The RIPE NCC is currently planning and creating a procedure based on experience and feedback received from our membership. We will give an update to the RIPE community at the RIPE 60 Meeting to be held in Prague from 3-7 May 2010. The procedural documentation and additional information for Phase 3 will be published before the implementation begins. > -- > Respectfully yours, > > David Monosov Kind regards, Arne Kiessling IP Resource Analyst RIPE NCC From millnert at csbnet.se Thu Mar 11 15:42:08 2010 From: millnert at csbnet.se (Martin Millnert) Date: Thu, 11 Mar 2010 15:42:08 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <3CA66B76-B6E9-4E2D-A248-E9A5BB3162EF@ripe.net> References: <3CA66B76-B6E9-4E2D-A248-E9A5BB3162EF@ripe.net> Message-ID: <1268318528.2878.144.camel@hsa.vpn.anti> Hello list, On Thu, 2009-12-03 at 14:28 +0100, Alex Le Heux wrote: > Dear Colleagues, > > During the discussion on the APWG list about 6rd, several people have > inquired about the exact way Registration Services evaluates requests > for 6rd deployment. This email will try to answer these inquiries. > > The RIPE NCC considers current policy to be completely agnostic to > 6rd, it neither specifically supports nor disallows 6rd deployment. > This means that Registration Services will evaluate IPv6 allocation > requests that include 6rd deployments according to the established > policies and procedures of justified need. > Another LIR, who has 3 million customers, intends to deploy 6rd with / > 60 assignments. Currently, the IPRA would consider 3 million /60 > assignments to fit into a /38, thus the default /32, while the 6rd > deployment would require a /28. > > Note that neither of these LIRs would qualify easily for an additional > allocation under the HD-ratio rules. I am curious how LIRs that employ 6RD today plan to motivate their need for the 15 extra /32:s they would be allocated following the example above, with the /28-instead-of-/32, once the 6RD transition phase is complete. IIRC RIPE are currently spacing their /32 assignments on a /29 basis. Eg, anticimex at hsa:~$ for i in `seq 0 8`; do whois 2a02:9a$i::/32 | egrep '(inet6num|netname)' ; done inet6num: 2a02:9a0::/32 netname: SE-SCS-20090203 inet6num: 2a00::/12 netname: EU-ZZ-2A00 [...] inet6num: 2a02:9a8::/32 netname: IT-SPIN-20090204 I guess that it would be trivial to fall back to the first /32, or whatever less-than-6RD-inflated prefix you had before, once the transition is over, as long as the LIR plans ahead accordingly. Best regards, -- Martin Millnert -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From ingrid at ripe.net Thu Mar 18 14:02:56 2010 From: ingrid at ripe.net (Ingrid Wijte) Date: Thu, 18 Mar 2010 14:02:56 +0100 Subject: [address-policy-wg] 2010-01 New Policy Proposal (Temporary Internet Number Assignment Policies) Message-ID: <20100318130259.9DBC46A006@postboy.ripe.net> PDP Number: 2010-01 Temporary Internet Number Assignment Policies Dear Colleagues A new RIPE Policy Proposal has been made and is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2010-01.html We encourage you to review this proposal and send your comments to before 15 April 2010. Regards Ingrid Wijte Policy Development Officer RIPE NCC From james.blessing at despres.co.uk Thu Mar 18 14:16:36 2010 From: james.blessing at despres.co.uk (James Blessing) Date: Thu, 18 Mar 2010 13:16:36 +0000 Subject: [address-policy-wg] 2010-01 New Policy Proposal (Temporary Internet Number Assignment Policies) In-Reply-To: <20100318130259.9DBC46A006@postboy.ripe.net> References: <20100318130259.9DBC46A006@postboy.ripe.net> Message-ID: <4BA227B4.5080209@despres.co.uk> On 18/03/2010 13:02, Ingrid Wijte wrote: > PDP Number: 2010-01 > Temporary Internet Number Assignment Policies > A few comments :) "Following the conclusion of the experiment the results must be published free of charge and free from disclosure constraints." What about 'security work' if someone was doing research on botnets and they only want to publish the general report to the public and withhold the 'sensitive' part to those under NDA? Surely this should be a 'negotiated' part of the process where the applicant indicates under what conditions they will release the information and NCC can make a judgement based on specific criteria (to be added to the proposal of course) "Resources issued must not be used for commercial purposes during or following the conclusion of the experiment." What is the definition of commercial in this case? If I carry out research and then monetise the results, surely this is a commercial purpose. Would the goals of this proposal not be better set by creating a collection of temporary objects under a dedicated LIR that is clearly marked as such that are 'loaned' to organisations using them rather than creating a new class of registrations in the RIR? J -- James Blessing http://www.despres.co.uk/ 07989 039 476 From nick at inex.ie Thu Mar 18 14:28:16 2010 From: nick at inex.ie (Nick Hilliard) Date: Thu, 18 Mar 2010 13:28:16 +0000 Subject: [address-policy-wg] 2010-01 New Policy Proposal (Temporary Internet Number Assignment Policies) In-Reply-To: <4BA227B4.5080209@despres.co.uk> References: <20100318130259.9DBC46A006@postboy.ripe.net> <4BA227B4.5080209@despres.co.uk> Message-ID: <4BA22A70.7000102@inex.ie> On 18/03/2010 13:16, James Blessing wrote: > "Following the conclusion of the experiment the results must be > published free of charge and free from disclosure constraints." [...] > "Resources issued must not be used for commercial purposes during or > following the conclusion of the experiment." James, The proposal suggests that this text be removed. The new policy begins at the heading "b. New policy text", and continues until just before the heading "Rationale". Nick From james.blessing at despres.co.uk Thu Mar 18 14:34:11 2010 From: james.blessing at despres.co.uk (James Blessing) Date: Thu, 18 Mar 2010 13:34:11 +0000 Subject: [address-policy-wg] 2010-01 New Policy Proposal (Temporary Internet Number Assignment Policies) In-Reply-To: <4BA22A70.7000102@inex.ie> References: <20100318130259.9DBC46A006@postboy.ripe.net> <4BA227B4.5080209@despres.co.uk> <4BA22A70.7000102@inex.ie> Message-ID: <4BA22BD3.30105@despres.co.uk> On 18/03/2010 13:28, Nick Hilliard wrote: > On 18/03/2010 13:16, James Blessing wrote: >> "Following the conclusion of the experiment the results must be >> published free of charge and free from disclosure constraints." > > [...] > >> "Resources issued must not be used for commercial purposes during or >> following the conclusion of the experiment." > > James, > > The proposal suggests that this text be removed. The new policy begins at > the heading "b. New policy text", and continues until just before the > heading "Rationale". Right (misread it) New set of comments :) 2. I thought the differentiation between 16bit and 32bit ASN was removed I'll stand by my comments about the creation of a separate LIR for this purpose J -- James Blessing http://www.despres.co.uk/ 07989 039 476 From randy at psg.com Thu Mar 18 14:56:43 2010 From: randy at psg.com (Randy Bush) Date: Thu, 18 Mar 2010 06:56:43 -0700 Subject: [address-policy-wg] 2010-01 New Policy Proposal (Temporary Internet Number Assignment Policies) In-Reply-To: <4BA227B4.5080209@despres.co.uk> References: <20100318130259.9DBC46A006@postboy.ripe.net> <4BA227B4.5080209@despres.co.uk> Message-ID: > "Following the conclusion of the experiment the results must be > published free of charge and free from disclosure constraints." there is a gap between conclusion of an experiment and publication of an academic paper where the researcher(s) does not wish to disclose. > Would the goals of this proposal not be better set by creating a > collection of temporary objects under a dedicated LIR that is clearly > marked as such that are 'loaned' to organisations using them rather > than creating a new class of registrations in the RIR? sometimes one wants 'unknown' space, i.e. space not known being used for research. or one wants 'new' space, i.e. testing bogon filters. randy From nick at inex.ie Thu Mar 18 16:15:48 2010 From: nick at inex.ie (Nick Hilliard) Date: Thu, 18 Mar 2010 15:15:48 +0000 Subject: [address-policy-wg] 2010-01 New Policy Proposal (Temporary Internet Number Assignment Policies) In-Reply-To: <4BA22BD3.30105@despres.co.uk> References: <20100318130259.9DBC46A006@postboy.ripe.net> <4BA227B4.5080209@despres.co.uk> <4BA22A70.7000102@inex.ie> <4BA22BD3.30105@despres.co.uk> Message-ID: <4BA243A4.6020109@inex.ie> On 18/03/2010 13:34, James Blessing wrote: > 2. I thought the differentiation between 16bit and 32bit ASN was removed There are and always will be technical differences between the two. e.g. there's no GLOP addresses for 32 bit ASNs, and there are differences in the way that ASNs are handled at a protocol level. There are fewer distinctions drawn at an assignment level, but they are not related to the technical characteristics of the numbers. > Would the goals of this proposal not be better set by creating a > collection of temporary objects under a dedicated LIR that is clearly > marked as such that are 'loaned' to organisations using them rather than > creating a new class of registrations in the RIR? That would possibly suit PA assignments, but not PI assignments. This proposal is about PI assignments. Nick From james.blessing at despres.co.uk Thu Mar 18 16:20:42 2010 From: james.blessing at despres.co.uk (James Blessing) Date: Thu, 18 Mar 2010 15:20:42 +0000 Subject: [address-policy-wg] 2010-01 New Policy Proposal (Temporary Internet Number Assignment Policies) In-Reply-To: <4BA243A4.6020109@inex.ie> References: <20100318130259.9DBC46A006@postboy.ripe.net> <4BA227B4.5080209@despres.co.uk> <4BA22A70.7000102@inex.ie> <4BA22BD3.30105@despres.co.uk> <4BA243A4.6020109@inex.ie> Message-ID: <4BA244CA.3010309@despres.co.uk> On 18/03/2010 15:15, Nick Hilliard wrote: > On 18/03/2010 13:34, James Blessing wrote: >> Would the goals of this proposal not be better set by creating a >> collection of temporary objects under a dedicated LIR that is clearly >> marked as such that are 'loaned' to organisations using them rather than >> creating a new class of registrations in the RIR? > > That would possibly suit PA assignments, but not PI assignments. This > proposal is about PI assignments. Is this PI only or both PI and PA ? i.e. if I need a temporary PA block so that I can test a new access product I need it to be PA as I would be an LIR (technically if not actually) J -- James Blessing http://www.despres.co.uk/ 07989 039 476 From nick at inex.ie Thu Mar 18 16:38:46 2010 From: nick at inex.ie (Nick Hilliard) Date: Thu, 18 Mar 2010 15:38:46 +0000 Subject: [address-policy-wg] 2010-01 New Policy Proposal (Temporary Internet Number Assignment Policies) In-Reply-To: <4BA244CA.3010309@despres.co.uk> References: <20100318130259.9DBC46A006@postboy.ripe.net> <4BA227B4.5080209@despres.co.uk> <4BA22A70.7000102@inex.ie> <4BA22BD3.30105@despres.co.uk> <4BA243A4.6020109@inex.ie> <4BA244CA.3010309@despres.co.uk> Message-ID: <4BA24906.7040505@inex.ie> On 18/03/2010 15:20, James Blessing wrote: > Is this PI only or both PI and PA ? i.e. if I need a temporary PA block > so that I can test a new access product I need it to be PA as I would be > an LIR (technically if not actually) This is PI only (didn't I just say that a few minutes ago? :-). If you're an end-user and need a temporary PA block, talk to your LIR. If you're an organisation which operates a LIR, I don't think that there's anything stopping you from either assigning some space from the LIR allocated blocks (on the basis of necessity), or requesting a temporary assignment under this policy. Nick From leo.vegoda at icann.org Thu Mar 18 17:06:53 2010 From: leo.vegoda at icann.org (Leo Vegoda) Date: Thu, 18 Mar 2010 09:06:53 -0700 Subject: [address-policy-wg] Re: [policy-announce] 2010-01 New Policy Proposal (Temporary Internet Number Assignment Policies) In-Reply-To: <20100318130259.9DBC46A006@postboy.ripe.net> References: <20100318130259.9DBC46A006@postboy.ripe.net> Message-ID: On 18 Mar 2010, at 6:02, Ingrid Wijte wrote: [...] > A new RIPE Policy Proposal has been made and is now available for > discussion. > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2010-01.html I agree with James that by distinguishing between 16 and 32-bit AS Numbers in section 2, this text is inconsistent with the main ASN policy. I suspect that the RIPE NCC staff can reserve a couple of small AS Numbers for this purpose and there is such a large number of big AS Numbers that a reservation is probably not necessary. The proposed policy text does not state that these assignments are subject to a contract, presumably because that is specified in the text of the main policy. Am I right in thinking that requesters would need to sign a contract to get resources under this policy? While it is an implementation detail, it would be nice if the time frame was documented in the contract. Also, if I have read it correctly, this proposal text removes the publication requirement for assignments made to experiments and academic research. What is the reason for removing this requirement? Finally, in the rationale section a., I think the phrase "a negligible effect on the final RIPE NCC IANA-supplied IPv4 address pool depletion date" should be "a negligible effect on the IANA-supplied RIPE NCC address pool depletion date" to improve clarity. Regards, Leo Vegoda From nick at inex.ie Thu Mar 18 19:13:41 2010 From: nick at inex.ie (Nick Hilliard) Date: Thu, 18 Mar 2010 18:13:41 +0000 Subject: [address-policy-wg] Re: [policy-announce] 2010-01 New Policy Proposal (Temporary Internet Number Assignment Policies) In-Reply-To: References: <20100318130259.9DBC46A006@postboy.ripe.net> Message-ID: <4BA26D55.1020102@inex.ie> On 18/03/2010 16:06, Leo Vegoda wrote: > I agree with James that by distinguishing between 16 and 32-bit AS > Numbers in section 2, this text is inconsistent with the main ASN > policy. I suspect that the RIPE NCC staff can reserve a couple of small > AS Numbers for this purpose and there is such a large number of big AS > Numbers that a reservation is probably not necessary. The latter is certainly the case. When drafting the policy, I didn't want to prevent the RIPE NCC doing what they think might be necessary with ASN32s. Under the terms of the policy proposal, they're authorised to reserve some ASN32s; whether they choose to actually reserve them is an operational matter for them to decide. As regards distinguishing between ASN16s and ASN32s, the fact of the matter is that there are technical differences between the two, regardless of what the current policies state. Perhaps the main ASN policy needs to note this? > The proposed policy text does not state that these assignments are > subject to a contract, presumably because that is specified in the text > of the main policy. Am I right in thinking that requesters would need to > sign a contract to get resources under this policy? Yes, correct. This is covered by section 3.4 - "Compliance with Other RIPE NCC Assignment Policies". There is value in not repeating policy text which appears in other documents, although it would probably be useful to note the "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" document explicitly. > While it is an > implementation detail, it would be nice if the time frame was documented > in the contract. yes, good point. > Also, if I have read it correctly, this proposal text removes the > publication requirement for assignments made to experiments and academic > research. What is the reason for removing this requirement? Several reasons actually. - I'm not sure of the intent of the original experimentation requirement, but suspect that it was a quid-pro-quo: that in order to make it possible for researchers to get large chunks of address space, they had to prove that they were really doing research, and in order to prove it, there was an obligation to publish the results. But given that the ipv4 address assignment landscape is shortly going to change irrevocably, it didn't make sense (to me) to have two temporary assignment categories. - given this, it would be discrimination or an encumbrance which did not apply to other assignment categories. This struck me as not being particularly fair. - most research journals will not accept articles which have been published elsewhere or where there is a contingent requirement for the researcher to publish elsewhere. "Elsewhere" includes FoC publishing on the Internet. This could create a chain of potentially serious problems for any researcher who needed temporary address space for the purposes of their work, given that the research cycle generally goes: grant application -> work -> publish -> grant application based on impact factor of journal where previous work was published. - if there were such an encumbrance in place for just researchers, they would probably end up requesting the address space on terms which had no such encumbrance (e.g. time limited project). By removing the encumbrance requirement, people will be less tempted to be dishonest on the application form. > Finally, in the rationale section a., I think the phrase "a negligible > effect on the final RIPE NCC IANA-supplied IPv4 address pool depletion > date" should be "a negligible effect on the IANA-supplied RIPE NCC > address pool depletion date" to improve clarity. That would be clearer, yes. Nick From goz at idecogateway.com Mon Mar 29 12:41:35 2010 From: goz at idecogateway.com (Sergey Gotsulyak) Date: Mon, 29 Mar 2010 16:41:35 +0600 Subject: [address-policy-wg] Easy to remember IP-address Message-ID: <144276706.20100329164135@idecogateway.com> Gentlemen, Some days ago, I told Jaap Akkerhuis about allocation of 2.2.2.0/24 address space for our DNS-service and he advice me to contact this workgroup. Our company Ideco is located in Russia and is in the business of developing and selling Internet gateways for small and middle businesses in Russia as well as billing software for ISPs. We?re now starting a new project for Russia and Eastern Europe that will provide secure Internet access for educational institutions, commercial and non-profit organizations. We?re planning to set up a number of DNS-centers that will block malware, adult websites and phishing links. For this project we?ll need an easy to remember IP-address, for example like the one for Google Public DNS service (8.8.8.8) We have contacted RIPE NCC with a request to get a block of addresses 2.2.2.0/24, but were told that the standard procedure does not allow us to choose an address range. Is it possible to modify current Address Policy? -- Kind regards, Sergey Gotsulyak Ideco Sales Team 280 Madison Ave, Suite 912 New York, NY 10016 Phone: (800) 715-3502 Email: goz at idecogateway.com Web: www.idecogateway.com From gert at space.net Mon Mar 29 12:58:30 2010 From: gert at space.net (Gert Doering) Date: Mon, 29 Mar 2010 12:58:30 +0200 Subject: [address-policy-wg] Easy to remember IP-address In-Reply-To: <144276706.20100329164135@idecogateway.com> References: <144276706.20100329164135@idecogateway.com> Message-ID: <20100329105830.GL69383@Space.Net> Hi, On Mon, Mar 29, 2010 at 04:41:35PM +0600, Sergey Gotsulyak wrote: > Is it possible to modify current Address Policy? Yes. RIPE has a well-defined policy development process, which can be used for that - it's documented here: http://www.ripe.net/ripe/docs/pdp.html Now, there's of course a catch - the PDP takes a while to run through (a couple of months at best, some times much longer), and you need *consensus* for a proposed policy change to become policy - so you need to convince the RIPE community that it's of common interest to change this. Since we're running out of addresses quickly, even if you succeed in changing the policy, the subnet containing 2.2.2.2 might already be handed out to someone else. So I wouldn't bet the success of my company on the chance of receiving 2.2.2.2 - you might succeed, but you might as well not. Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 150584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From slz at baycix.de Mon Mar 29 13:06:53 2010 From: slz at baycix.de (Sascha Lenz) Date: Mon, 29 Mar 2010 13:06:53 +0200 Subject: [address-policy-wg] Easy to remember IP-address In-Reply-To: <20100329105830.GL69383@Space.Net> References: <144276706.20100329164135@idecogateway.com> <20100329105830.GL69383@Space.Net> Message-ID: <4BB089CD.3020305@baycix.de> Hay, Am 29.03.2010 12:58, schrieb Gert Doering: > Hi, > > On Mon, Mar 29, 2010 at 04:41:35PM +0600, Sergey Gotsulyak wrote: >> Is it possible to modify current Address Policy? > > Yes. RIPE has a well-defined policy development process, which can > be used for that - it's documented here: > > http://www.ripe.net/ripe/docs/pdp.html > > Now, there's of course a catch - the PDP takes a while to run through > (a couple of months at best, some times much longer), and you need > *consensus* for a proposed policy change to become policy - so you need > to convince the RIPE community that it's of common interest to change > this. > > Since we're running out of addresses quickly, even if you succeed in > changing the policy, the subnet containing 2.2.2.2 might already be > handed out to someone else. So I wouldn't bet the success of my > company on the chance of receiving 2.2.2.2 - you might succeed, but > you might as well not. or to put it simpler: If we would have such a policy, all nice vanity addresses would have been "sold out" (mind the quotes) by now already anways. And you might not have the budget to "buy" a nice address either because it would cost a fortune like sex.com or so :-) But, fortunately, IP addresses are not Domain Names.... -- ====================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Design & Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ====================================================================== From shane at time-travellers.org Mon Mar 29 13:35:07 2010 From: shane at time-travellers.org (Shane Kerr) Date: Mon, 29 Mar 2010 13:35:07 +0200 Subject: [address-policy-wg] Easy to remember IP-address In-Reply-To: <20100329105830.GL69383@Space.Net> References: <144276706.20100329164135@idecogateway.com> <20100329105830.GL69383@Space.Net> Message-ID: <4BB0906B.6080400@time-travellers.org> Gert, On 2010-03-29 12:58, Gert Doering wrote: > Hi, > > On Mon, Mar 29, 2010 at 04:41:35PM +0600, Sergey Gotsulyak wrote: >> Is it possible to modify current Address Policy? > > Yes. RIPE has a well-defined policy development process, which can > be used for that - it's documented here: > > http://www.ripe.net/ripe/docs/pdp.html > > Now, there's of course a catch - the PDP takes a while to run through > (a couple of months at best, some times much longer), and you need > *consensus* for a proposed policy change to become policy - so you need > to convince the RIPE community that it's of common interest to change > this. > > Since we're running out of addresses quickly, even if you succeed in > changing the policy, the subnet containing 2.2.2.2 might already be > handed out to someone else. So I wouldn't bet the success of my > company on the chance of receiving 2.2.2.2 - you might succeed, but > you might as well not. All true. Still, there are other easy-to-remember blocks, like 2.3.4.0/24 or 2.22.22.0/24, and so on. Geoff Huston and George Michaelson at APNIC have been doing some research into what "interesting" addresses there are, since APNIC had the bad (?) luck to get allocated 1.0.0.0/8 recently. You can ask them for some hints as to what people tend to use. :) I note that there is some precedence for this kind of request, at least at ARIN (I hear AS42 was assigned when asked for, although I was not involved with this so it is just a rumor). As for actually getting the RIPE NCC to issue a resource based on a request... I think there are two ways to go about this. One is making it a POLICY matter, and going through the PDP and updating the relevant documents. The other is solving it PROCEDURALLY, which basically means convincing the RIPE NCC to accept special requests and handle them when possible. I generally think it is in everyone's best interest to keep the policies as simple as possible. I think it is especially in the RIPE NCC's interest to handle requests for specific resources procedurally and not have a policy, because if there is a policy then every new LIR will see this and of course they will look for "interesting" numbers to request, meaning lots of extra work for everyone involved. In summary: * I support allowing people to request specific unused resources * I hope that can be done without a policy change -- Shane From bmanning at vacation.karoshi.com Mon Mar 29 12:57:05 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 29 Mar 2010 10:57:05 +0000 Subject: [address-policy-wg] Easy to remember IP-address In-Reply-To: <144276706.20100329164135@idecogateway.com> References: <144276706.20100329164135@idecogateway.com> Message-ID: <20100329105705.GC17934@vacation.karoshi.com.> You forgot the ladies. RIR policies are set by the members of the RIR... so yes, it is possible to modify current address policy. I'll note that in the case you referece, Google made a deal with the folks who were allocated the net 8 space, not with the RIR. --bill On Mon, Mar 29, 2010 at 04:41:35PM +0600, Sergey Gotsulyak wrote: > Gentlemen, > > Some days ago, I told Jaap Akkerhuis about allocation of 2.2.2.0/24 > address space for our DNS-service and he advice me to contact this > workgroup. > > Our company Ideco is located in Russia and is in the business of > developing and selling Internet gateways for small and middle > businesses in Russia as well as billing software for ISPs. > > Webre now starting a new project for Russia and Eastern Europe > that will provide secure Internet access for educational institutions, > commercial and non-profit organizations. Webre planning to set up a > number of DNS-centers that will block malware, adult websites and phishing > links. > > For this project webll need an easy to remember IP-address, for > example like the one for Google Public DNS service (8.8.8.8) > > We have contacted RIPE NCC with a request to get a block of addresses > 2.2.2.0/24, but were told that the standard procedure does not allow > us to choose an address range. > > Is it possible to modify current Address Policy? > > -- > Kind regards, > Sergey Gotsulyak > > Ideco Sales Team > 280 Madison Ave, Suite 912 > New York, NY 10016 > > Phone: (800) 715-3502 > Email: goz at idecogateway.com > Web: www.idecogateway.com > From jim at rfc1035.com Mon Mar 29 14:26:58 2010 From: jim at rfc1035.com (Jim Reid) Date: Mon, 29 Mar 2010 13:26:58 +0100 Subject: [address-policy-wg] Vanity address allocations and the end of IPv4 In-Reply-To: <4BB0906B.6080400@time-travellers.org> References: <144276706.20100329164135@idecogateway.com> <20100329105830.GL69383@Space.Net> <4BB0906B.6080400@time-travellers.org> Message-ID: <2535B396-E301-4922-8D03-30B865D35084@rfc1035.com> On 29 Mar 2010, at 12:35, Shane Kerr wrote: > * I support allowing people to request specific unused resources Of course. Unused resources are there to be used. > * I hope that can be done without a policy change By that I hope you don't mean that the NCC does some fancy footwork around the current policies to give an LIR the particular address block they want. It is extremely important now that we're in the end- game for IPv4 that the current non-discriminatory policies based on technical need are followed. If there is a new requirement for allocating the remaining resources -- eg vanity addresses -- that simply has to go through the policy making process. IMO it would be very unwise to tinker with these policies for non-technical reasons as IPv4 runs out. Very Bad Things will happen if the RIRs allocate resources in ways that violate our policies. Or there's a suggestion that the current rules are not being followed. Or a suspiciion that needs-based allocation no longer applies. Governments, regulators and competition authorities are going to be paying special attention to what RIRs do with the remaining IPv4 space. So it's essential that there's not even a hint of the RIRs treating allocation requests differently by applying criteria which are not part of the current policies. The week before last, the ITU had a meeting where they discussed the possibility of becoming an RIR. [Some of the motivations for that included "fairness towards developing countries", "reduced cost" and "addressing the imblance of IPv4 allocations." Sigh.] If the RIRs are suspected of bending their own policies, this will give ammunition to those who say that these Internet people are not to be trusted -- "See! They ignore their own rules/processes or make them up as they go along!" -- and it's time for the ITU to step in and provide adult supervision. As far as getting the block containing 2.2.2.2 goes, I think the way forward should be for the LIR to keep an eye out for when that block is about to be allocated, submit a template at the appropriate point and take their chances. IIUC this is what some folk have sort of done with AS numbers. I have heard of people who monitor the RIR databases and watch for "interesting" ASNs to be handed back. When such a number is returned to the RIR, they then submit a template for a new ASN and hope it gets allocated the one that was just returned. From shane at time-travellers.org Mon Mar 29 15:48:58 2010 From: shane at time-travellers.org (Shane Kerr) Date: Mon, 29 Mar 2010 15:48:58 +0200 Subject: [address-policy-wg] Vanity address allocations and the end of IPv4 In-Reply-To: <2535B396-E301-4922-8D03-30B865D35084@rfc1035.com> References: <144276706.20100329164135@idecogateway.com> <20100329105830.GL69383@Space.Net> <4BB0906B.6080400@time-travellers.org> <2535B396-E301-4922-8D03-30B865D35084@rfc1035.com> Message-ID: <4BB0AFCA.8000102@time-travellers.org> Jim, On 2010-03-29 14:26, Jim Reid wrote: > On 29 Mar 2010, at 12:35, Shane Kerr wrote: > >> * I support allowing people to request specific unused resources > > Of course. Unused resources are there to be used. > >> * I hope that can be done without a policy change > > By that I hope you don't mean that the NCC does some fancy footwork > around the current policies to give an LIR the particular address block > they want. It is extremely important now that we're in the end-game for > IPv4 that the current non-discriminatory policies based on technical > need are followed. If there is a new requirement for allocating the > remaining resources -- eg vanity addresses -- that simply has to go > through the policy making process. IMO it would be very unwise to tinker > with these policies for non-technical reasons as IPv4 runs out. To be clear, we're not talking about anyone getting more or less address space, or allocating in a way that makes aggregation more difficult. I thought those were the two basic goals of IP allocation policy, right? The RIPE NCC does not have any restrictions on which particular resources it allocates or assigns. In fact, I am pretty sure that any sensible person would argue that the RIPE NCC should have as much freedom as possible to do things in the most efficient way. So I think the RIPE NCC already has the power to issue "vanity addresses" in the rare case where someone asks for these. Mostly I find it a pity that the NCC wasn't more accommodating and that we're having this discussion at all. Maybe the software used for this process does not have a manual override or something? Oh well, compared to the horror stories I hear about the bad old days, I guess we have no complaints.... In the end I suppose we can just let the addresses fall wherever and let "the market" sort it out, now that there is a "trading" policy. While the desire for vanity addresses might accelerate the process of IP addresses becoming property, that is probably inevitable, so it won't change the big picture too much. -- Shane From jim at rfc1035.com Mon Mar 29 16:24:18 2010 From: jim at rfc1035.com (Jim Reid) Date: Mon, 29 Mar 2010 15:24:18 +0100 Subject: [address-policy-wg] Vanity address allocations and the end of IPv4 In-Reply-To: <4BB0AFCA.8000102@time-travellers.org> References: <144276706.20100329164135@idecogateway.com> <20100329105830.GL69383@Space.Net> <4BB0906B.6080400@time-travellers.org> <2535B396-E301-4922-8D03-30B865D35084@rfc1035.com> <4BB0AFCA.8000102@time-travellers.org> Message-ID: On 29 Mar 2010, at 14:48, Shane Kerr wrote: > To be clear, we're not talking about anyone getting more or less > address > space, or allocating in a way that makes aggregation more difficult. I > thought those were the two basic goals of IP allocation policy, right? I'm not sure Shane that an allocation of vanity addresses would fit with these goals. If it does, then fine. Though I'm doubtful. If there were "too many" vanity assignments, that may well fragment the unused space in a way that prevents another LIR getting a contiguous allocation that's big enough for their genuine technical needs. It might also encourage a land-grab by people gobbling up vanity space that they don't actually need in the hope that they could sell it on later. From bmanning at vacation.karoshi.com Mon Mar 29 16:27:16 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 29 Mar 2010 14:27:16 +0000 Subject: [address-policy-wg] Vanity address allocations and the end of IPv4 In-Reply-To: References: <144276706.20100329164135@idecogateway.com> <20100329105830.GL69383@Space.Net> <4BB0906B.6080400@time-travellers.org> <2535B396-E301-4922-8D03-30B865D35084@rfc1035.com> <4BB0AFCA.8000102@time-travellers.org> Message-ID: <20100329142716.GB22218@vacation.karoshi.com.> On Mon, Mar 29, 2010 at 03:24:18PM +0100, Jim Reid wrote: > On 29 Mar 2010, at 14:48, Shane Kerr wrote: > > >To be clear, we're not talking about anyone getting more or less > >address > >space, or allocating in a way that makes aggregation more difficult. I > >thought those were the two basic goals of IP allocation policy, right? > > I'm not sure Shane that an allocation of vanity addresses would fit > with these goals. If it does, then fine. Though I'm doubtful. If there > were "too many" vanity assignments, that may well fragment the unused > space in a way that prevents another LIR getting a contiguous > allocation that's big enough for their genuine technical needs. It > might also encourage a land-grab by people gobbling up vanity space > that they don't actually need in the hope that they could sell it on > later. to be clear, a "vanity" address is in the eye of the beholder. --bill From marcoh at marcoh.net Mon Mar 29 18:14:16 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Mon, 29 Mar 2010 18:14:16 +0200 Subject: [address-policy-wg] Vanity address allocations and the end of IPv4 In-Reply-To: <4BB0AFCA.8000102@time-travellers.org> References: <144276706.20100329164135@idecogateway.com> <20100329105830.GL69383@Space.Net> <4BB0906B.6080400@time-travellers.org> <2535B396-E301-4922-8D03-30B865D35084@rfc1035.com> <4BB0AFCA.8000102@time-travellers.org> Message-ID: > To be clear, we're not talking about anyone getting more or less address > space, or allocating in a way that makes aggregation more difficult. I > thought those were the two basic goals of IP allocation policy, right? But it could lead to a less then optimal address distribution if somebody runs of with a vanity /24, leaving a bunch of smaller blocks for the poor fellow who can justify his /16. MarcoH From leo.vegoda at icann.org Mon Mar 29 18:39:00 2010 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 29 Mar 2010 09:39:00 -0700 Subject: [address-policy-wg] Easy to remember IP-address In-Reply-To: <144276706.20100329164135@idecogateway.com> References: <144276706.20100329164135@idecogateway.com> Message-ID: <50D8C6F3-4C6F-46B6-BA1C-0138BCDB7DAD@icann.org> On 29 Mar 2010, at 3:41, Sergey Gotsulyak wrote: [...] > Some days ago, I told Jaap Akkerhuis about allocation of 2.2.2.0/24 > address space for our DNS-service and he advice me to contact this > workgroup. It may be worth noting that the RIPE NCC has already committed not to allocate prefixes longer than a /21 from 2.0.0.0/8. See: http://www.ripe.net/ripe/docs/ripe-479.html It appears that if you want an IPv4 prefix as long as a /24 from the RIPE NCC it will come from 91/8, 193/8 or 194/7. Regards, Leo Vegoda From ocl at gih.com Mon Mar 29 20:30:25 2010 From: ocl at gih.com (Olivier MJ Crepin-Leblond) Date: Mon, 29 Mar 2010 19:30:25 +0100 Subject: [address-policy-wg] Easy to remember IP-address In-Reply-To: <144276706.20100329164135@idecogateway.com> References: <144276706.20100329164135@idecogateway.com> Message-ID: <4BB0F1C1.7030309@gih.com> Hello Sergey, Le 29/03/2010 11:41, Sergey Gotsulyak a ?crit : > We have contacted RIPE NCC with a request to get a block of addresses > 2.2.2.0/24, but were told that the standard procedure does not allow > us to choose an address range. > > Is it possible to modify current Address Policy? > I know this is not going to answer your question, but you're better off going for IPv6. :-) Modifying current address policy to add value (through simplicity) to IP addresses? Unlikely. It was designed the way it is today, specifically to avoid this and all its resulting head-aches. Warm regards, Olivier -- Olivier MJ Cr?pin-Leblond, PhD http://www.gih.com/ocl.html From mohta at necom830.hpcl.titech.ac.jp Tue Mar 30 14:37:06 2010 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 30 Mar 2010 21:37:06 +0900 Subject: [address-policy-wg] Easy to remember IP-address In-Reply-To: <144276706.20100329164135@idecogateway.com> References: <144276706.20100329164135@idecogateway.com> Message-ID: <4BB1F072.90404@necom830.hpcl.titech.ac.jp> Sergey Gotsulyak wrote: > For this project we?ll need an easy to remember IP-address, for > example like the one for Google Public DNS service (8.8.8.8) I'm afraid you typed wrong characters for "we'll", which is a problem, among many, of unicode Anyway, 4 byte addresses of IPv4 is not so bad to memorize. You are right, however, that IPv6 addresses are impossible to remember not only for end users but also for network operators, which is one of a reason why IPv6 is NOT deployable. The magic number for memory is 7. That is, one can easily remember 4 bytes and may be able to remember 8 bytes. However, it is virtually impossible to remember 16 bytes. That is, for fairness, IPv6 is unusable. Instead, everyone should be able to remember 4 byte IPv4 addresses and 2 byte short port numbers as was documented in When an ISP operate a NAT gateway, the ISP should, for fairness between customers, reserve some well know port numbers and assign small port numbers evenly to all the customers. > We have contacted RIPE NCC with a request to get a block of addresses > 2.2.2.0/24, but were told that the standard procedure does not allow > us to choose an address range. > > Is it possible to modify current Address Policy? You had better to abandone IPv6 and IPv6 address policies and just stick to IPv4 with A+P including, but not limited to, . Masataka Ohta From garry at nethinks.com Tue Mar 30 15:30:07 2010 From: garry at nethinks.com (Garry Glendown) Date: Tue, 30 Mar 2010 15:30:07 +0200 Subject: [address-policy-wg] Easy to remember IP-address In-Reply-To: <4BB1F072.90404@necom830.hpcl.titech.ac.jp> References: <144276706.20100329164135@idecogateway.com> <4BB1F072.90404@necom830.hpcl.titech.ac.jp> Message-ID: <4BB1FCDF.5080408@nethinks.com> On 30.03.2010 14:37, Masataka Ohta wrote: > Sergey Gotsulyak wrote: > > >> For this project we?ll need an easy to remember IP-address, for >> example like the one for Google Public DNS service (8.8.8.8) >> > I'm afraid you typed wrong characters for "we'll", which is > a problem, among many, of unicode > > Anyway, 4 byte addresses of IPv4 is not so bad to memorize. > > You are right, however, that IPv6 addresses are impossible to > remember not only for end users but also for network operators, > which is one of a reason why IPv6 is NOT deployable. > Sorry, but you must be one sieve-brain (is there such a word in english?) of a network operator if you aren't able to remember your /32 prefix .. As for end users - end users do not have to remember ANY IPs ... that's what DHCP, DNS etc. are for, as well as (if necessary) documents given to end users when they sign up and receive their login information... or would you state that the initial setup information for a dial-up account (e.g. username/password) is shorter than some single IP-address (both v4 and v6)? Please stop spreading FUD about IPv6, just because _YOU_ are either incapable or unwilling to deploy IPv6 doesn't mean that the other currently >2000 prefix owners would prefer to wait another n years to see whether your RFC-draft would be implemented by one single vendor ... > The magic number for memory is 7. That is, one can easily remember > 4 bytes and may be able to remember 8 bytes. However, it is virtually > impossible to remember 16 bytes. > Let's see. "ipv6.google.com". Looks easy to remember to me. And my computer - what a surprise - automagically converts that to those "impossible" to remember numbers like 2a00:1450:8001::63. Just like that. Seems like at least the computer had no trouble at all remembering them ... Oh, and I have no trouble remembering the IPs for my mailserver ... both v4 and v6 ... along with several dozens of other v4 and v6 addresses for personal and customer servers, firewalls and routers that I need more or less ... as do many if not all of our tech staff ... and in case somebody may not remember a specific IP from time to time - that's what documentation is for ... > That is, for fairness, IPv6 is unusable. > for you, maybe. Now go home and play with your draft while the rest of the world goes ahead with technical progress ... > Instead, everyone should be able to remember 4 byte IPv4 > addresses and 2 byte short port numbers as was documented in > > Exactly. Because "www.site1.de:1234" and "www.site2.com:1324" and "www.site3.org:1243" are so d at mn easy to remember for the average-joe-enduser ... compared to impossible to remember "www.site1.de", "www.site2.com" and "www.site3.org", which unnoticed by the enduser are resolved to either IPv4 or IPv6 addresses and just simply work ... now tell me, what exactly does the end user gain from sticking with YAPOSNL? (yet another POS nat layer) -gg From trejrco at gmail.com Tue Mar 30 15:40:28 2010 From: trejrco at gmail.com (TJ) Date: Tue, 30 Mar 2010 09:40:28 -0400 Subject: [address-policy-wg] Easy to remember IP-address In-Reply-To: <4BB1F072.90404@necom830.hpcl.titech.ac.jp> References: <144276706.20100329164135@idecogateway.com> <4BB1F072.90404@necom830.hpcl.titech.ac.jp> Message-ID: <71bfd60c1003300640ucff8346m909ec5cf3a8af5bb@mail.gmail.com> Actually it is quite possible to memorize IPv6 addresses - break it into two pieces (say, perhaps, network and host). Especially when the high-order side of your address is fairly static ... although obviously this becomes less easy when some portion was randomly chosen, but those addresses aren't usually the ones you need to memorize. And I didn't realize "memorizability" was a key design criteria for a network protocol - if only we had some way of converting words into those oh-so-hard-to-remember numbers ... /TJ *And with continued deployment advances from Google, Microsoft, NetFlix, Comcast, Verizon Wireless, certain US DoD Components, etc. etc. ... overall, it is looking like a good year for IPv6 :).* On Tue, Mar 30, 2010 at 08:37, Masataka Ohta < mohta at necom830.hpcl.titech.ac.jp> wrote: > Sergey Gotsulyak wrote: > > > For this project we?ll need an easy to remember IP-address, for > > example like the one for Google Public DNS service (8.8.8.8) > > I'm afraid you typed wrong characters for "we'll", which is > a problem, among many, of unicode > > Anyway, 4 byte addresses of IPv4 is not so bad to memorize. > > You are right, however, that IPv6 addresses are impossible to > remember not only for end users but also for network operators, > which is one of a reason why IPv6 is NOT deployable. > > The magic number for memory is 7. That is, one can easily remember > 4 bytes and may be able to remember 8 bytes. However, it is virtually > impossible to remember 16 bytes. > > That is, for fairness, IPv6 is unusable. > > Instead, everyone should be able to remember 4 byte IPv4 > addresses and 2 byte short port numbers as was documented in > > > When an ISP > operate a NAT gateway, the ISP should, for fairness between > customers, reserve some well know port numbers and assign small port > numbers evenly to all the customers. > > > We have contacted RIPE NCC with a request to get a block of addresses > > 2.2.2.0/24, but were told that the standard procedure does not allow > > us to choose an address range. > > > > Is it possible to modify current Address Policy? > > You had better to abandone IPv6 and IPv6 address policies and just > stick to IPv4 with A+P including, but not limited to, > . > > Masataka Ohta > > -- /TJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From niels=apwg at bakker.net Tue Mar 30 22:00:35 2010 From: niels=apwg at bakker.net (niels=apwg at bakker.net) Date: Tue, 30 Mar 2010 22:00:35 +0200 Subject: [address-policy-wg] Easy to remember IP-address In-Reply-To: <4BB1F072.90404@necom830.hpcl.titech.ac.jp> References: <144276706.20100329164135@idecogateway.com> <4BB1F072.90404@necom830.hpcl.titech.ac.jp> Message-ID: <20100330200035.GD77019@burnout.tpb.net> * mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) [Tue 30 Mar 2010, 14:45 CEST]: >Sergey Gotsulyak wrote: >>For this project we?ll need an easy to remember IP-address, for >>example like the one for Google Public DNS service (8.8.8.8) > >I'm afraid you typed wrong characters for "we'll", which is >a problem, among many, of unicode He didn't write in Unicode but used a Microsoft-proprietary character set wrapped in a layer of quoted-unprintable. Get a fucking clue and learn to read mail headers before you run your mouth again. >The magic number for memory is 7. That is, one can easily remember >4 bytes and may be able to remember 8 bytes. However, it is virtually >impossible to remember 16 bytes. Wow, doing shopping must be such a hardship for you. The only way you survive must be by doing separate trips to the mall for breakfast and dinner each day. -- Niels. -- From mohta at necom830.hpcl.titech.ac.jp Wed Mar 31 02:34:29 2010 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 31 Mar 2010 09:34:29 +0900 Subject: [address-policy-wg] Easy to remember IP-address In-Reply-To: <4BB1FCDF.5080408@nethinks.com> References: <144276706.20100329164135@idecogateway.com> <4BB1F072.90404@necom830.hpcl.titech.ac.jp> <4BB1FCDF.5080408@nethinks.com> Message-ID: <4BB29895.1010804@necom830.hpcl.titech.ac.jp> Garry Glendown wrote: >>Anyway, 4 byte addresses of IPv4 is not so bad to memorize. >> >>You are right, however, that IPv6 addresses are impossible to >>remember not only for end users but also for network operators, >>which is one of a reason why IPv6 is NOT deployable. > Sorry, but you must be one sieve-brain (is there such a word in > english?) of a network operator if you aren't able to remember your /32 > prefix .. So? Note that there is no guarantee that IPv6 prefix length is /32. The fact is that many, if not all, network operators can't remember IPv6 addresses, which is a major, among many, obstacle against IPv6. > Please stop spreading FUD about IPv6, just because _YOU_ are either > incapable or unwilling to deploy IPv6 doesn't mean that the other > currently >2000 prefix owners would prefer to wait another n years to > see whether your RFC-draft would be implemented by one single vendor ... 2000 prefixes in some private network 15 years after rfc1883??? No, my interest is on >300000 prefixes routed over the real internet. > Let's see. "ipv6.google.com". Looks easy to remember to me. I'm not talking about end users. >>Instead, everyone should be able to remember 4 byte IPv4 >>addresses and 2 byte short port numbers as was documented in >> > Exactly. Because "www.site1.de:1234" and "www.site2.com:1324" and > "www.site3.org:1243" are so d at mn easy to remember for the > average-joe-enduser ... Exactly, which is why my draft says: assign small port numbers evenly to all the customers. Read it. A user may be assined ports 100, 199, 298, ... while another user may be assigned ports 101, 200, 299, ... > compared to impossible to remember > "www.site1.de", "www.site2.com" and "www.site3.org", which unnoticed by > the enduser are resolved to either IPv4 or IPv6 addresses and just > simply work ... Let DNS map from domain names to 6 byte address+port is no more difficult than to let DNS map from domain names to IPv6 address. > now tell me, what exactly does the end user gain from > sticking with YAPOSNL? (yet another POS nat layer) End to end transparency. Masataka Ohta From gert at space.net Wed Mar 31 08:13:53 2010 From: gert at space.net (Gert Doering) Date: Wed, 31 Mar 2010 08:13:53 +0200 Subject: [address-policy-wg] Easy to remember IP-address In-Reply-To: <4BB29895.1010804@necom830.hpcl.titech.ac.jp> References: <144276706.20100329164135@idecogateway.com> <4BB1F072.90404@necom830.hpcl.titech.ac.jp> <4BB1FCDF.5080408@nethinks.com> <4BB29895.1010804@necom830.hpcl.titech.ac.jp> Message-ID: <20100331061353.GG69383@Space.Net> Hi, can we please stop this thread? Whether or not IPv6 addresses are easier to remember than IPv4 addresses or not is NOT RELEVANT to address policy, and as such, completely off-topic here. Masaka, may I suggest you go and post to nanog, or some other place where IPv6<->IPv4 advocacy is commonplace? List, please stop feeding the troll. We have more important work to do. Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 150584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From mohta at necom830.hpcl.titech.ac.jp Wed Mar 31 14:06:08 2010 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 31 Mar 2010 21:06:08 +0900 Subject: [address-policy-wg] Easy to remember IP-address In-Reply-To: <20100331061353.GG69383@Space.Net> References: <144276706.20100329164135@idecogateway.com> <4BB1F072.90404@necom830.hpcl.titech.ac.jp> <4BB1FCDF.5080408@nethinks.com> <4BB29895.1010804@necom830.hpcl.titech.ac.jp> <20100331061353.GG69383@Space.Net> Message-ID: <4BB33AB0.2050208@necom830.hpcl.titech.ac.jp> Gert Doering wrote: > Masaka, may I suggest you go and post to nanog, or some other place where > IPv6<->IPv4 advocacy is commonplace? Do you mean some other place not censored by IPv6 fundamentalists? > List, please stop feeding the troll. Note that you trolls eat rocks. Masataka Ohta From gert at space.net Wed Mar 31 18:15:08 2010 From: gert at space.net (Gert Doering) Date: Wed, 31 Mar 2010 18:15:08 +0200 Subject: [address-policy-wg] Easy to remember IP-address In-Reply-To: <4BB33AB0.2050208@necom830.hpcl.titech.ac.jp> References: <144276706.20100329164135@idecogateway.com> <4BB1F072.90404@necom830.hpcl.titech.ac.jp> <4BB1FCDF.5080408@nethinks.com> <4BB29895.1010804@necom830.hpcl.titech.ac.jp> <20100331061353.GG69383@Space.Net> <4BB33AB0.2050208@necom830.hpcl.titech.ac.jp> Message-ID: <20100331161508.GI69383@Space.Net> Hi, On Wed, Mar 31, 2010 at 09:06:08PM +0900, Masataka Ohta wrote: > Gert Doering wrote: > > > Masaka, may I suggest you go and post to nanog, or some other place where > > IPv6<->IPv4 advocacy is commonplace? > > Do you mean some other place not censored by IPv6 fundamentalists? This list is here to decide on the rules for handling out numbers to members of the RIPE NCC and to end users in the RIPE service region (= "address policy"). Address policy for IPv4 addresses, for IPv6 addresses, and for AS numbers is on-topic - and all discussions that have direct implications on policy. It is *NOT* the right place to discuss whether IPv4 or IPv6 is "better". Feel free to voice anything that you concern relevant to *address policy* - but the question or not "IPv6 sucks because you don't want to use DNS" is completely irrelevant to the rules of responsible stewardship for limited resources. Which *this* list is about. Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 150584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: