From filiz at ripe.net Tue May 1 15:53:25 2007 From: filiz at ripe.net (Filiz Yilmaz) Date: Tue, 01 May 2007 15:53:25 +0200 Subject: [address-policy-wg] 2007-04 New Policy Proposal (IANA Policy for Allocation of ASN Blocks to RIRs) Message-ID: <20070501135325.A54662F583@herring.ripe.net> PDP Number: 2007-04 IANA Policy for Allocation of ASN Blocks to RIRs Dear Colleagues A new RIPE Policy Proposal has been made and is now available for discussion. This proposal is to have a global policy for the Regional Internet Registries (RIRs) to receive blocks of Autonomous System Numbers (ASNs) from the Internet Assigned Numbers Authority (IANA). You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2007-04.html We encourage you to review this proposal and send your comments to before 29 May 2007. Regards Filiz Yilmaz RIPE NCC Policy Development Officer From Thorsten.Toenges at merck.de Tue May 1 16:01:04 2007 From: Thorsten.Toenges at merck.de (Thorsten.Toenges at merck.de) Date: Tue, 1 May 2007 16:01:04 +0200 Subject: [address-policy-wg] =?ISO-8859-1?Q?Thorsten_Toenges=2FEMD=2FMerck_ist_au=DFer_Haus=2E__?= Message-ID: I will be out of the office starting 27.04.2007 and will not return until 07.05.2007. Ich werde Ihre Nachricht nach meiner R?ckkehr beantworten. Bei technischen Fragen wenden Sie sich bitte an den User Support unter 7777 This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you must not copy this message or attachment or disclose the contents to any other person. If you have received this transmission in error, please notify the sender immediately and delete the message and any attachment from your system. Merck does not accept liability for any omissions or errors in this message which may arise as a result of E-Mail-transmission or for damages resulting from any unauthorized changes of the content of this message and any attachment thereto. Merck does not guarantee that this message is free of viruses and does not accept liability for any damages caused by any virus transmitted therewith. From president at ukraine.su Wed May 2 03:25:51 2007 From: president at ukraine.su (Max Tulyev) Date: Wed, 02 May 2007 01:25:51 +0000 Subject: [address-policy-wg] 2007-01 New Policy Proposal (Direct Internet Resource Assignments to End Users from the RIPE NCC) In-Reply-To: <20070430152516.GS73965@Space.Net> References: <20070419140255.BFEC62F583@herring.ripe.net> <4629575F.8050004@baycix.de> <20070430152516.GS73965@Space.Net> Message-ID: <4637E89F.70702@ukraine.su> Hi, Domestic contracts (LIR-User) is much simple (and in some not so rare cases - is only way) than international (RIPE NCC-User) one. RIPE NCC did a lot of things in Russia to make special Russian contract, and it really works now here. But there is still a lot of problems to sign and legally use of this contract because of local laws. In Ukraine situation is worse: at first, because of laws are more ugly, at second, there is no local Ukrainian contract. In fact, ALL of Ukrainian RIPE NCC members signed standard (unchanged) service agreement acts ILLEGALLY at Ukrainian side. Unable to pay money to RIPE NCC legally is most harmless consequence of it. A month ago Ukrainian local work group is started to make Ukrainian local contract like in Russia. But I didn't hear anything about this for other ex-USSR countries with similar laws: Kazakhstan, Uzbekistan, Georgia and so on. A week ago I requested from RIPE NCC Russian agreement for our registry based in Ukraine. It fits here as mostly similar legal demand and Russian language documents are still often accepted in Ukraine. But I got reply "wait for special Ukrainian agreement" from RIPE NCC. Gert Doering wrote: > Hi, > > On Sat, Apr 21, 2007 at 02:14:23AM +0200, Sascha Lenz wrote: >> With the actual situation in Russia - probably otherwhere too, it might >> make more sense to look into another concept, probably somehow like >> DENIC (.de ccTLD) handles it for Domains here (someone correct me if i >> talk rubbish here): > > I think this is a good approach, and should work for all countries where > LIRs can find a way to make a contract with the RIPE NCC. > > Max, is that something that would work in your environment? I don't know > the legal obstacles in Russia, Ukraine, etc. well enough to be sure it > would work out. > > Gert Doering > -- APWG chair -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From filiz at ripe.net Wed May 2 16:00:47 2007 From: filiz at ripe.net (Filiz Yilmaz) Date: Wed, 02 May 2007 16:00:47 +0200 Subject: [address-policy-wg] 2007-05 New Policy Proposal (IPv6 ULA-Central) Message-ID: <20070502140047.E6CF22F583@herring.ripe.net> PDP Number: 2007-05 IPv6 ULA-Central Dear Colleagues A new RIPE Policy Proposal has been made and is now available for discussion. This policy proposal is intended to allow the assignment of IPv6 blocks within the so-called 'Centrally Assigned Unique Local IPv6 Unicast Addresses' to organisations or individuals requiring it. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2007-05.html We encourage you to review this proposal and send your comments to before 30 May 2007. Regards Filiz Yilmaz RIPE NCC Policy Development Officer From shane at time-travellers.org Wed May 2 17:03:23 2007 From: shane at time-travellers.org (Shane Kerr) Date: Wed, 2 May 2007 17:03:23 +0200 Subject: [address-policy-wg] 2007-05 New Policy Proposal (IPv6 ULA-Central) In-Reply-To: <20070502140047.E6CF22F583@herring.ripe.net> References: <20070502140047.E6CF22F583@herring.ripe.net> Message-ID: <20070502150323.GB3041@borg.c-l-i.net> All, I think the draft this proposal refers to: http://tools.ietf.org/html/draft-ietf-ipv6-ula-central-01 Is an early version of what eventually became RFC 4193: http://tools.ietf.org/html/rfc4193 The RFC does not have any centrally assigned addresses. I didn't actually follow the discussion in the IETF about this document, so I don't know why the centrally assigned version was removed. It's not actually clear to me what the policy proposal is. Does it intend for the RIPE NCC to act as a central registry for all local IPv6 addresses? Does it intend for a special membership category be set up for this? -- Shane From jordi.palet at consulintel.es Wed May 2 17:23:16 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 02 May 2007 16:23:16 +0100 Subject: [address-policy-wg] 2007-05 New Policy Proposal (IPv6 ULA-Central) In-Reply-To: <20070502150323.GB3041@borg.c-l-i.net> Message-ID: Hi Shane, No, it is a different thing (local/RFC4193 vs. central). This draft (ula-central-01) is already being updated. The policy proposes to act as one of the central (consider one of the draft options "central but distributed in several entities", take that as one or several RIRs) registries. I need to clarify that this is something that has been consulted for months with the NRO and the NRO answer was: "fine, but go to each region with a policy proposal, otherwise we can't do it". Regards, Jordi > De: Shane Kerr > Responder a: > Fecha: Wed, 2 May 2007 17:03:23 +0200 > Para: "address-policy-wg at ripe.net" > Asunto: Re: [address-policy-wg] 2007-05 New Policy Proposal (IPv6 ULA-Central) > > All, > > I think the draft this proposal refers to: > > http://tools.ietf.org/html/draft-ietf-ipv6-ula-central-01 > > Is an early version of what eventually became RFC 4193: > > http://tools.ietf.org/html/rfc4193 > > The RFC does not have any centrally assigned addresses. > > I didn't actually follow the discussion in the IETF about this > document, so I don't know why the centrally assigned version was > removed. > > It's not actually clear to me what the policy proposal is. Does it > intend for the RIPE NCC to act as a central registry for all local > IPv6 addresses? Does it intend for a special membership category be > set up for this? > > -- > Shane > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From shane at time-travellers.org Wed May 2 19:24:30 2007 From: shane at time-travellers.org (Shane Kerr) Date: Wed, 2 May 2007 19:24:30 +0200 Subject: [address-policy-wg] 2007-05 New Policy Proposal (IPv6 ULA-Central) In-Reply-To: References: <20070502150323.GB3041@borg.c-l-i.net> Message-ID: <20070502172430.GD3041@borg.c-l-i.net> Jordi, On Wed, May 02, 2007 at 04:23:16PM +0100, JORDI PALET MARTINEZ wrote: > > No, it is a different thing (local/RFC4193 vs. central). > > This draft (ula-central-01) is already being updated. I really looks like RFC 4193 is ula-central-01 with the central registry taken out. I mention this because the central registry must have been taken out for a reason, and I think it would be easier if we knew those reasons rather than having to guess at them. > The policy proposes to act as one of the central (consider one of > the draft options "central but distributed in several entities", > take that as one or several RIRs) registries. > > I need to clarify that this is something that has been consulted for > months with the NRO and the NRO answer was: "fine, but go to each > region with a policy proposal, otherwise we can't do it". Right, so the idea is that the NRO will run a registry, and that the RIRs will act as registrars for this. Hopefully the policies will be similar in each region. And the proposal that these addresses will be issued directly by the RIPE NCC to end users? I think this is interesting, but if that is the idea, then the whole structure (NRO->RIR->end users) seems really complicated. There are about 1 trillion of these /48's. I think a much better idea would be for the NRO to set up a web page where you type in your credit card number and for 5 euros (or 10 or 20 or whatever) you get a /48. (Not an original idea of mine, but I can't remember who suggested it to me.) If you don't want to spend the 5 euros (or 10 or 20 or whatever), you can always use a random /48 from RFC 4193. If the NRO demands that this be a policy action within each region, there's no special reason the NRO has to be involved, is there? Anyone with a server can run this. -- Shane From pk at DENIC.DE Wed May 2 19:07:10 2007 From: pk at DENIC.DE (Peter Koch) Date: Wed, 2 May 2007 19:07:10 +0200 Subject: [address-policy-wg] 2007-02 New Policy Proposal (Change in IP Assignments for Anycasting DNS Policy) In-Reply-To: <20070423132426.B75702F583@herring.ripe.net> References: <20070423132426.B75702F583@herring.ripe.net> Message-ID: <20070502170710.GI866@unknown.office.denic.de> > PDP Number: 2007-02 > Change in IP Assignments for Anycasting DNS Policy Without questioning the particular needs of the proponent, the proposal as it stands has some issues to be resolved (quoting only the v4 part for ripe405 here): > 6.9 Anycasting Name servers > > If the name server set of an organisation running DNS without using It is unclear to me whether "an organisation" refers to the domain holder, zone maintainer or the DNS infrastructure provider, if any. The original proposal deliberately chose the term TLD here, referring to the TLD manager, not the service provider and if this proposal intends to change that, it should be made more explicit. > anycasting technology would not pass the 'IANA Administrative Procedure for > Root Zone Name Server Delegation and Glue Data' the organisation may receive > a single dedicated /24 network prefix for the sole purpose of anycasting > name servers, as described in RFC 3258. > The organisation should demonstrate that the number of name servers or IP > addresses for these name servers in the delegation exceeds eight and that > without anycasting their zone size exceeds the UDP datagram size. During the discussion of the original anycast policy proposal it was carefully avoided -- after some looping debate -- to encode explicit DNS parameters into said proposal. That's the whole point of referring to IANA's delegation procedure. Now, I understand that IANA's procedures aren't applicable to non-TLDs, but at the same time it isn't obvious where the number "eight" originates from. To make matters more complicated, the basic procedure IANA is supposed to apply would indeed fit well, but then depends on the respective parent's glue and registration policy. Again, I'm not sure anyone would want the RIPE NCC to engage in cumbersome tests and judgements, so even a fixed number might be fine - if there's some rationale given. NIT: "their zone size exceeds the UDP datagram size" should probably read "a referral response for their domain would exceed the 512 octet UDP payload limit". > The organisation should also demonstrate that they need to do anycasting > due to the geographical diversity of their DNS setup. The organisation will > be required to demonstrate that anycasting will be used in diverse > geographical locations. The existence of the real servers should be > demonstrated with anycasting nodes that can be pinged and tracerouted. That should be topological diversity instead. I'm not so confident that pings and traceroutes can differentiate between anycast and multihoming uses. The basic question is whether checks should be applied at all. > The prefix will be assigned by the RIPE NCC directly to the organisation, > upon a request submitted via an existing LIR and will be registered with a > status of 'ASSIGNED ANYCAST' in the RIPE Database. The prefix must be > returned to the RIPE NCC if no longer in use for anycast DNS. Within the "arguments opposing the proposal" I'd suggest to change the reason from "... be opened to organisations that are not a ccTLD or a gTLD." to something like "... no longer have an upper bound of {some fraction of 267}." Actually, the proliferation of anycast assignments could lead to more rigid filtering. -Peter From gert at space.net Wed May 2 22:27:33 2007 From: gert at space.net (Gert Doering) Date: Wed, 2 May 2007 22:27:33 +0200 Subject: [address-policy-wg] 2007-05 New Policy Proposal (IPv6 ULA-Central) In-Reply-To: <20070502172430.GD3041@borg.c-l-i.net> References: <20070502150323.GB3041@borg.c-l-i.net> <20070502172430.GD3041@borg.c-l-i.net> Message-ID: <20070502202732.GW73965@Space.Net> Hi, On Wed, May 02, 2007 at 07:24:30PM +0200, Shane Kerr wrote: > And the proposal that these addresses will be issued directly by the > RIPE NCC to end users? One could argue for "use the LIR structure for that" or for "do it directly, for a one-up charge". > I think this is interesting, but if that is the idea, then the whole > structure (NRO->RIR->end users) seems really complicated. There are > about 1 trillion of these /48's. I think a much better idea would be > for the NRO to set up a web page where you type in your credit card > number and for 5 euros (or 10 or 20 or whatever) you get a /48. (Not > an original idea of mine, but I can't remember who suggested it to > me.) This would be a possible approach as well. Unfortunately, the NRO doesn't want to do this "out of the blue", so we need the RIR policy process to get a mandate to the RIRs into place "make the NRO (or whoever else) distribute ULA-central addresses!". [..] > If the NRO demands that this be a policy action within each region, > there's no special reason the NRO has to be involved, is there? Anyone > with a server can run this. Sure. Anyone with a server, and the backing that *this* is the entity that has the IETF/IANA/user community blessing to do so. Otherweise we'll have multiple ULA central "registries", which is not what we want. That's what ULA local is for. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 113403 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 gih at apnic.net Thu May 3 00:20:21 2007 From: gih at apnic.net (Geoff Huston) Date: Thu, 03 May 2007 08:20:21 +1000 Subject: [address-policy-wg] 2007-05 New Policy Proposal (IPv6 ULA-Central) In-Reply-To: <20070502150323.GB3041@borg.c-l-i.net> References: <20070502140047.E6CF22F583@herring.ripe.net> <20070502150323.GB3041@borg.c-l-i.net> Message-ID: <7.0.0.16.2.20070503081258.02703898@apnic.net> At 01:03 AM 3/05/2007, Shane Kerr wrote: >All, > >I think the draft this proposal refers to: > >http://tools.ietf.org/html/draft-ietf-ipv6-ula-central-01 > >Is an early version of what eventually became RFC 4193: > >http://tools.ietf.org/html/rfc4193 > >The RFC does not have any centrally assigned addresses. > >I didn't actually follow the discussion in the IETF about this >document, so I don't know why the centrally assigned version was >removed. The IETF history of this document was that an original proposal was for two pools of ULA addresses - one a "self-draw" and one "centrally assigned". The draft was split into two drafts, and the draft describing the "self-draw" pool was published as RFC4193 while the IPv6 working group abandoned work on the centrally assigned address pool >It's not actually clear to me what the policy proposal is. Does it >intend for the RIPE NCC to act as a central registry for all local >IPv6 addresses? Does it intend for a special membership category be >set up for this? I posted the following comments and question to the Afrinic policy mailing list in response to this proposal - I suspect that these questions and comments are relevant here as well. When this was under consideration within the IETF some years back I performed an evaluation of the draft from the perspective of the RIRs as a potential operator of this service. In reading through this proposal these considerations appear to remain relevant today, and it may be useful to consider these issues when considering the operational aspects of provision of such a registry service. The evaluation report included the following considerations: ----------------------------------------------------------------- - the 'nature' of the distribution function for this part of the IPv6 address appears to be an allocation to be undertaken in perpetuity. It is possible to interpret this allocation in terms comparable to some form of 'freehold property' given that the self-allocation via the central registry gives the entity exclusive unqualified right of access without any form of expiration or renewal of the original allocation. Current RIR allocations of unicast public address space are undertaken under conditions that are broadly consistent with a non- assignable lease. It may be that this issue of assignments performed in perpetuity vs fixed period renewable assignments should be a matter of choice by the client as the time of assignment, and that pricing for this address assignment reflect the different cost structure of secure maintenance of assignment records for a fixed period vs costs for this record maintenance to be undertaken in perpetuity. - it is unclear whether the privacy of the assignee is intended to absolute or under what circumstances the central registry operator would divulge this information and to whom. It was noted that all information held by the RIR is not covered by any binding privilege. It is the case that such RIR-held information is discoverable by others using legal means under certain circumstances. Open questions include: Would anyone be able to ask whether a specific prefix was allocated or not? Would a holder be able to 'recover' their prefix from the registry? Could a holder request the registry to expose their holding to a specific third party? Could the privacy requirement be changed at a later date? Would any future changes to the privacy requirement (or any other characteristics of these addresses) be a policy matter to be determined within the addressing community, or would any changes to the characteristics of this space remain solely within the purview of the IETF? - Permanence of allocation. Should there be a capability for an assignee to voluntarily return an allocation? How can the assignee and the returnee be matched? If the allocation is not public knowledge how can a return be effected? Should these allocations be permanent or of some fixed term with a periodic renewal option? - Distribution functions. Should there be some form of 'wholesale' form of bulk access to this registry, to allow, for example, a manufacturer to place pre-paid prefixes into manufactured devices? If not, could this form of use of the central registry services be supported using mechanisms described in the current proposal? - Associated information and pointers. The proposal is silent on reverse DNS for these prefixes. Perhaps the final version of this document could explicitly say that this requires private DNS (two- faced DNS) deployment and that placing these prefixes in the ip6.arpa zone is not to be supported. Or should such reverse DNS delegation be allowed? After all these global IDs are unique and in and of itself putting them in the public DNS is not going to harm the DNS. Of course the random nature of these assignments has the potential to, over time, create an extremely large flat DNS zone. This may have implications in terms of signing the zone with DNSSEC of course. Some guidance the preferred approach of populating the DNS reverse zones would be preferred, if reverse DNS is to be supported for these addresses. If this reverse DNS is to be allowed, does this compromise the private nature of the assignment? The proposal is also silent on WHOIS entries. It appears that there is an explicit privacy issue where that precludes any inclusion in the WHOIS databases, but an explicit statement to this effect in a final version of this document would be preferred. It is probable that inclusion in the public DNS, whois information and the privacy of these assignments are related matters. - Routability of these prefixes. The RIRs maintain that they take no position on the routeability of prefixes that they assign. It would appear that this position extends to this central registry managed site local prefix. - There is no doubt that there would be some effort expended on the part of the RIRs to implement this registry operation. Pricing for the service may need to be determined within the parameters of a cost recovery function for operation of the function distinct from the costs of other RIR functions, and within the parameters of the anticipated costs of secure maintenance of records in perpetuity. The is some consideration about the true distinction between C-ULA address blocks and conventional unicast address blocks. If the address allocations in the C-ULA block are published by the RIRs in precisely the same manner as other unicast address allocations, are able to be entered into the reverse DNS in the same manner as other unicast address allocations, and if the RIRs are not the determiners of whether an address block is actually routeable or not, then what precisely is the distinction between this C-ULA address distribution function and the conventional unicast address distribution function? Why are C-ULA address necessary? What problem is this proposal actually attempting to solve here? And if the problem can be identified clearly then the subsequent question is whether there are alternative mechanisms that could solve the same problem in different ways? i.e. What is the problem that C-ULA addresses are intended to solve and what alternatives are available to us in looking at this problem? So far I have yet to see the proposer of this policy address this quite basic question. I suspect that the proposal would be a fair deal clearer in intent, and a fair deal clearer in terms of whether or not the proposal should be adopted, if we all clearly understood what the underlying problem (or what shortfall in the existing address distribution mechanisms) is that this proposal is intending to address. From jordi.palet at consulintel.es Thu May 3 02:30:53 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 03 May 2007 01:30:53 +0100 Subject: [address-policy-wg] 2007-05 New Policy Proposal (IPv6 ULA-Central) In-Reply-To: <7.0.0.16.2.20070503081258.02703898@apnic.net> Message-ID: Hi Geoff, I guess it is important to clarify that the authors of the draft are working on a new version. I've not yet seen it, so I'm not sure if it is addressing already any of your points below. Trying to answer your points below, but as a general comment, I think they are operational aspects that the community should rely on the RIRs staff to manage. At least, I personally trust them. There have been many similar examples discussed in other regions of operational issues and once the RIRs are asked about if they want to have a policy, the message is clearly negative: They need freedom to implement things. In this case it is more evident. The implementation can be different if it is taken by one or several RIRs, or by the NRO itself, etc. I'm happy if the result of the implementation is that somebody can get allocated a ULA-central prefix (I don't really care the price, because I understand need to be based on a cost recovery model and to be decided by the board), to be used as for the example in the proposal for infrastructure microallocations, instead of wasting global address space. I also guess that this can be done with a much simple document not detailing so much as the actual ID. This is why I think this "parallel" (RIRs+IETF) process is important, because it may actually help to provide inputs for subsequent versions of the ID. See below, in-line. Regards, Jordi > De: Geoff Huston > Responder a: > Fecha: Thu, 03 May 2007 08:20:21 +1000 > Para: Shane Kerr , "address-policy-wg at ripe.net" > > Asunto: Re: [address-policy-wg] 2007-05 New Policy Proposal (IPv6 ULA-Central) > > At 01:03 AM 3/05/2007, Shane Kerr wrote: >> All, >> >> I think the draft this proposal refers to: >> >> http://tools.ietf.org/html/draft-ietf-ipv6-ula-central-01 >> >> Is an early version of what eventually became RFC 4193: >> >> http://tools.ietf.org/html/rfc4193 >> >> The RFC does not have any centrally assigned addresses. >> >> I didn't actually follow the discussion in the IETF about this >> document, so I don't know why the centrally assigned version was >> removed. > > > The IETF history of this document was that an original proposal was for > two pools of ULA addresses - one a "self-draw" and one "centrally assigned". > The draft was split into two drafts, and the draft describing the "self-draw" > pool > was published as RFC4193 while the IPv6 working group abandoned work on > the centrally assigned address pool > > > >> It's not actually clear to me what the policy proposal is. Does it >> intend for the RIPE NCC to act as a central registry for all local >> IPv6 addresses? Does it intend for a special membership category be >> set up for this? > > I posted the following comments and question to the Afrinic policy mailing > list in response to this proposal - I suspect that these questions and > comments are relevant here as well. > > When this was under consideration within the IETF some years back I > performed an evaluation of the draft from the perspective of the RIRs > as a potential operator of this service. In reading through this proposal > these considerations appear to remain relevant today, and it may be > useful to consider these issues when considering the operational > aspects of provision of such a registry service. I guess this document was feed into the IPv6 WG. It will be interesting to know the answers provided by the IETF process then. > > The evaluation report included the following considerations: > > ----------------------------------------------------------------- > > - the 'nature' of the distribution function for this part of the > IPv6 address appears to be an allocation to be undertaken in > perpetuity. It is possible to interpret this allocation in terms > comparable to some form of 'freehold property' given that the > self-allocation via the central registry gives the entity > exclusive unqualified right of access without any form of > expiration or renewal of the original allocation. > > Current RIR allocations of unicast public address space are > undertaken under conditions that are broadly consistent with a non- > assignable lease. I think we do that with other special addresses, such as multicast, etc., via direct allocation from IANA. What is the difference ? > > It may be that this issue of assignments performed in perpetuity > vs fixed period renewable assignments should be a matter of choice > by the client as the time of assignment, and that pricing for this > address assignment reflect the different cost structure of secure > maintenance of assignment records for a fixed period vs costs for > this record maintenance to be undertaken in perpetuity. I don't think the policy proposal precludes doing so. We may need to decide if this should be so clearly defined by the policy or trust the board. I will think the last one, as they policies don't define fees. > > - it is unclear whether the privacy of the assignee is intended to > absolute or under what circumstances the central registry operator > would divulge this information and to whom. It was noted that all > information held by the RIR is not covered by any binding > privilege. It is the case that such RIR-held information is > discoverable by others using legal means under certain > circumstances. Open questions include: > > Would anyone be able to ask whether a specific prefix was > allocated or not? I don't think we can define an absolute "privacy". Lawful interception is always something under the relevant authority control, so definitively they should be able to ask if prefix "x" belongs to somebody and in that case, whom. > > Would a holder be able to 'recover' their prefix from the > registry? I don't see why it can't be feasible. I will say that those are good ideas for the staff implementing it. > > Could a holder request the registry to expose their holding to a > specific third party? Same answer as the previous one. > > Could the privacy requirement be changed at a later date? By whom ? Any specific example of why you think this may be required ? > > Would any future changes to the privacy requirement (or any > other characteristics of these addresses) be a policy matter to > be determined within the addressing community, or would any > changes to the characteristics of this space remain solely > within the purview of the IETF? I think we should follow the draft, or provide inputs to update it, and this may be one of the issues, but probably an example of why you think this is important could help. > > - Permanence of allocation. Should there be a capability for an > assignee to voluntarily return an allocation? How can the assignee I think this could be a nice to have feature, of course. > and the returnee be matched? If the allocation is not public > knowledge how can a return be effected? Should these allocations be Implementing privacy doesn't necessary means that the RIR don't know who owns a prefix, in fact this is required in order to execute the contract as stated in the policy proposal. > permanent or of some fixed term with a periodic renewal option? I will not really care if the board decides to implement a periodic renewal fee. > > - Distribution functions. Should there be some form of 'wholesale' > form of bulk access to this registry, to allow, for example, a > manufacturer to place pre-paid prefixes into manufactured devices? > If not, could this form of use of the central registry services be > supported using mechanisms described in the current proposal? I don't see right now if this could be useful, but if you have a specific example, I guess it could be considered then in the implementation. > > - Associated information and pointers. The proposal is silent on reverse > DNS for these prefixes. Perhaps the final version of this document > could explicitly say that this requires private DNS (two- faced DNS) > deployment and that placing these prefixes in the ip6.arpa zone is not > to be supported. Or should such reverse DNS delegation be allowed? > After all these global IDs are unique and in and of itself putting > them in the public DNS is not going to harm the DNS. Of course the > random nature of these assignments has the potential to, over time, > create an extremely large flat DNS zone. This may have implications in > terms of signing the zone with DNSSEC of course. Some guidance the > preferred approach of populating the DNS reverse zones would be > preferred, if reverse DNS is to be supported for these addresses. If > this reverse DNS is to be allowed, does this compromise the private > nature of the assignment? The proposal is also silent on WHOIS > entries. > > It appears that there is an explicit privacy issue where that > precludes any inclusion in the WHOIS databases, but an explicit > statement to this effect in a final version of this document would be > preferred. It is probable that inclusion in the public DNS, whois > information and the privacy of these assignments are related matters. I think the usage I'm perceiving for ULA-central could be made with two-faced DNS, but I may be wrong. > > - Routability of these prefixes. The RIRs maintain that they take no > position on the routeability of prefixes that they assign. It would > appear that this position extends to this central registry managed > site local prefix. Yes, but that's doesn't preclude to have routability statements across many policies. In this proposal we only state what is not the intend of this prefix, and this could be tied in the future to resource certification in the same way as the rest of the prefixes. > > - There is no doubt that there would be some effort expended on the part > of the RIRs to implement this registry operation. Pricing for the > service may need to be determined within the parameters of a cost > recovery function for operation of the function distinct from the > costs of other RIR functions, and within the parameters of the > anticipated costs of secure maintenance of records in perpetuity. Agree, as stated above, I don't really care about the price for the registration and trust the staff to evaluate the cost and the board to implement the relevant contracts and fees, as we do with the rest of the policies. > > > The is some consideration about the true distinction between C-ULA address > blocks and conventional unicast address blocks. If the address allocations > in the C-ULA block are published by the RIRs in precisely the same manner > as other unicast address allocations, are able to be entered into the > reverse DNS in the same manner as other unicast address allocations, and if > the RIRs are not the determiners of whether an address block is actually > routeable or not, then what precisely is the distinction between this C-ULA > address distribution function and the conventional unicast address > distribution function? Why are C-ULA address necessary? What problem is > this proposal actually attempting to solve here? And if the problem can be > identified clearly then the subsequent question is whether there are > alternative mechanisms that could solve the same problem in different ways? Why using global unicast for something which already has an allocated prefix since it was designed for that by IETF ? For sure there are alternative mechanisms, as usually there are many solutions for doing everything :-), and that may require an alternative ID if we can't achieve consensus on this one. > > i.e. What is the problem that C-ULA addresses are intended to solve and > what alternatives are available to us in looking at this problem? So far I > have yet to see the proposer of this policy address this quite basic > question. I suspect that the proposal would be a fair deal clearer in > intent, and a fair deal clearer in terms of whether or not the proposal > should be adopted, if we all clearly understood what the underlying problem > (or what shortfall in the existing address distribution mechanisms) is that > this proposal is intending to address. > I tried to make it clear in the proposal text. I think it can be summarized as: The issue is avoid wastefully using global unicast resources for infrastructure microallocations if it can be done with a prefix from another block which is already reserved for this type of functionalities. > > > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From gih at apnic.net Thu May 3 03:33:37 2007 From: gih at apnic.net (Geoff Huston) Date: Thu, 03 May 2007 11:33:37 +1000 Subject: [address-policy-wg] 2007-05 New Policy Proposal (IPv6 ULA-Central) In-Reply-To: References: <7.0.0.16.2.20070503081258.02703898@apnic.net> Message-ID: <7.0.0.16.2.20070503112932.02706218@apnic.net> At 10:30 AM 3/05/2007, JORDI PALET MARTINEZ wrote: >Hi Geoff, > >I guess it is important to clarify that the authors of the draft are working >on a new version. I've not yet seen it, so I'm not sure if it is addressing >already any of your points below. I'm getting very confused - If I understand the situation at this point in time this is a policy proposal in the RIR process that is based on a document that is actually in preparation at this point in time? If this is indeed the case then possibly you might wish to consider suspending the policy proposal until such time as the document is completed. regards, Geoff From jordi.palet at consulintel.es Thu May 3 09:21:28 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 03 May 2007 08:21:28 +0100 Subject: [address-policy-wg] 2007-05 New Policy Proposal (IPv6 ULA-Central) In-Reply-To: <7.0.0.16.2.20070503112932.02706218@apnic.net> Message-ID: Some have raised the concern (in other lists) that the ID is expired, so I'm telling that before it comes back here again. The way the policy proposal is written is to avoid entering into implementation issues (which as said, I believe should be decided by the RIRs staff), and thus in principle, if the authors change implementation aspects, the policy proposal don't need to be modified. Regards, Jordi > De: Geoff Huston > Responder a: > Fecha: Thu, 03 May 2007 11:33:37 +1000 > Para: , "address-policy-wg at ripe.net" > > Asunto: Re: [address-policy-wg] 2007-05 New Policy Proposal (IPv6 ULA-Central) > > At 10:30 AM 3/05/2007, JORDI PALET MARTINEZ wrote: >> Hi Geoff, >> >> I guess it is important to clarify that the authors of the draft are working >> on a new version. I've not yet seen it, so I'm not sure if it is addressing >> already any of your points below. > > > I'm getting very confused - If I understand the situation at this > point in time this is a policy proposal in the RIR process that is > based on a document that is actually in preparation at this point in time? > > If this is indeed the case then possibly you might wish to consider > suspending the policy proposal until such time as the document is completed. > > regards, > > Geoff > > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From michael.dillon at bt.com Thu May 3 12:41:10 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 3 May 2007 11:41:10 +0100 Subject: [address-policy-wg] 2007-05 New Policy Proposal (IPv6 ULA-Central) In-Reply-To: References: <20070502150323.GB3041@borg.c-l-i.net> Message-ID: > This draft (ula-central-01) is already being updated. > > The policy proposes to act as one of the central (consider one of the > draft > options "central but distributed in several entities", take that as one or > several RIRs) registries. If it is a draft then these ULA addresses do not exist. If they do not exist, how can an RIR set up a registry for them? Or are you suggesting that the RIRs should overthrow the IETF? --Michael Dillon From jordi.palet at consulintel.es Thu May 3 13:14:14 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 03 May 2007 12:14:14 +0100 Subject: [address-policy-wg] 2007-05 New Policy Proposal (IPv6 ULA-Central) In-Reply-To: Message-ID: Not at all. However, there is nothing in the PDP that precludes to work in parallel. In fact it has been done before. The block is already reserved also by the RFC4193. Last, but not least, we have already been there. All the 4-bytes ASN policy proposals had been developed while it was still I-D work. We can perfectly be in the situation that we move ahead with this from the policy perspective, but RFC is not yet there, and then we either wait for implementation to have the RFC or work in a global policy to "replace" the lack of an RFC. Regards, Jordi > De: > Responder a: > Fecha: Thu, 3 May 2007 11:41:10 +0100 > Para: > Conversaci?n: [address-policy-wg] 2007-05 New Policy Proposal (IPv6 > ULA-Central) > Asunto: RE: [address-policy-wg] 2007-05 New Policy Proposal (IPv6 ULA-Central) > >> This draft (ula-central-01) is already being updated. >> >> The policy proposes to act as one of the central (consider one of the >> draft >> options "central but distributed in several entities", take that as > one or >> several RIRs) registries. > > If it is a draft then these ULA addresses do not exist. If they do not > exist, how can an RIR set up a registry for them? > > Or are you suggesting that the RIRs should overthrow the IETF? > > --Michael Dillon > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From gert at space.net Thu May 3 13:26:52 2007 From: gert at space.net (Gert Doering) Date: Thu, 3 May 2007 13:26:52 +0200 Subject: [address-policy-wg] 2007-05 New Policy Proposal (IPv6 ULA-Central) In-Reply-To: References: <20070502150323.GB3041@borg.c-l-i.net> Message-ID: <20070503112652.GI73965@Space.Net> Hi, On Thu, May 03, 2007 at 11:41:10AM +0100, michael.dillon at bt.com wrote: > If it is a draft then these ULA addresses do not exist. If they do not > exist, how can an RIR set up a registry for them? > > Or are you suggesting that the RIRs should overthrow the IETF? We're working on both ends in parallel, given that the PDP process will usually take quite some time (especially for a global policy). So this is sort of a "if the IETF should make space available for ULAs, will you be happy with this policy?" thing. (And on the other side, the question is "if the RIRs are willing to set up a central registry, would the IETF make available ULAs?" - so we can't just wait for the IETF without having some sort of consensus that the RIR system will do this) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 113403 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 rumy at ripe.net Thu May 3 13:42:14 2007 From: rumy at ripe.net (Rumy Kanis) Date: Thu, 03 May 2007 13:42:14 +0200 Subject: [address-policy-wg] New E-Learning Module: Using PGP and X509 to Protect MNTNER Objects Message-ID: <4639CA96.9050505@ripe.net> Dear Colleagues, We are pleased to announce the launch of the latest module on the RIPE NCC E-Learning Centre: - Using PGP Keys and X509 Certificates in MNTNER objects This module explains the steps required to use a PGP Key and/or X509 Certificate to protect objects in the RIPE Database. The module provides step-by-step guidelines for: - Creating a KEY-CERT object - Adding the KEY-CERT object to an existing MNTNER object as a method of authentication - Updating an object protected by that MNTNER using the PGP key or X509 certificate The RIPE NCC E-Learning Centre is a free of charge service available to everyone, and can be found at https://e-learning.ripe.net. If you have any questions, please feel free to contact us at: e-learning at ripe.net Happy Learning, Rumy Kanis Training Services Manager From filiz at ripe.net Thu May 3 14:00:14 2007 From: filiz at ripe.net (Filiz Yilmaz) Date: Thu, 03 May 2007 14:00:14 +0200 Subject: [address-policy-wg] 2006-02 New Draft Document Published (IPv6 Address Allocation and Assignment Policy) Message-ID: <20070503120014.4899D2F583@herring.ripe.net> PDP Number: 2006-02 IPv6 Address Allocation and Assignment Policy Dear Colleagues We have published a draft document for the proposal described in 2006-02. This proposal is to change the IPv6 Initial Allocation criteria and the End Site definition in the "IPv6 Address Allocation and Assignment Policy". You can find the full proposal at: http://ripe.net/ripe/policies/proposals/2006-02.html and the draft document at: http://ripe.net/ripe/draft-documents/2006-02-draft.html We encourage you to read the draft document text and send any comments to address-policy-wg at ripe.net before 31 May 2007. Regards Filiz Yilmaz RIPE NCC Policy Development Officer From marc.van.selm at nc3a.nato.int Fri May 4 08:47:12 2007 From: marc.van.selm at nc3a.nato.int (Marc van Selm) Date: Fri, 4 May 2007 08:47:12 +0200 Subject: [address-policy-wg] 2006-02 New Draft Document Published (IPv6 Address Allocation and Assignment Policy) In-Reply-To: <20070503120014.4899D2F583@herring.ripe.net> References: <20070503120014.4899D2F583@herring.ripe.net> Message-ID: <200705040847.12865.marc.van.selm@nc3a.nato.int> That would work for me (and NATO I think). Marc On Thursday 03 May 2007 14:00, Filiz Yilmaz wrote: > PDP Number: 2006-02 > IPv6 Address Allocation and Assignment Policy > > Dear Colleagues > > We have published a draft document for the proposal described in > 2006-02. > > This proposal is to change the IPv6 Initial Allocation criteria and > the End Site definition in the "IPv6 Address Allocation and > Assignment Policy". > > You can find the full proposal at: > > http://ripe.net/ripe/policies/proposals/2006-02.html > > and the draft document at: > > http://ripe.net/ripe/draft-documents/2006-02-draft.html > > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net before 31 May 2007. > > Regards > > Filiz Yilmaz > RIPE NCC > Policy Development Officer -- Marc van Selm NATO C3 Agency CIS Division E-mail: marc.van.selm at nc3a.nato.int (PGP capable) From rumy at ripe.net Thu May 3 13:42:14 2007 From: rumy at ripe.net (Rumy Kanis) Date: Thu, 03 May 2007 13:42:14 +0200 Subject: [address-policy-wg] [ncc-announce] New E-Learning Module: Using PGP and X509 to Protect MNTNER Objects Message-ID: <4639CA96.9050505@ripe.net> Dear Colleagues, We are pleased to announce the launch of the latest module on the RIPE NCC E-Learning Centre: - Using PGP Keys and X509 Certificates in MNTNER objects This module explains the steps required to use a PGP Key and/or X509 Certificate to protect objects in the RIPE Database. The module provides step-by-step guidelines for: - Creating a KEY-CERT object - Adding the KEY-CERT object to an existing MNTNER object as a method of authentication - Updating an object protected by that MNTNER using the PGP key or X509 certificate The RIPE NCC E-Learning Centre is a free of charge service available to everyone, and can be found at https://e-learning.ripe.net. If you have any questions, please feel free to contact us at: e-learning at ripe.net Happy Learning, Rumy Kanis Training Services Manager From tcremer at cw.net Fri May 4 11:26:46 2007 From: tcremer at cw.net (Tobias Cremer) Date: Fri, 04 May 2007 11:26:46 +0200 Subject: [address-policy-wg] 2007-02 New Policy Proposal (Change in IP Assignments for Anycasting DNS Policy) In-Reply-To: <20070502170710.GI866@unknown.office.denic.de> References: <20070423132426.B75702F583@herring.ripe.net> <20070502170710.GI866@unknown.office.denic.de> Message-ID: <463AFC56.1000000@cw.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Peter, On 02.05.2007 19:07, Peter Koch wrote: >> 6.9 Anycasting Name servers >> >> If the name server set of an organisation running DNS without using > > It is unclear to me whether "an organisation" refers to the domain holder, > zone maintainer or the DNS infrastructure provider, if any. The original > proposal deliberately chose the term TLD here, referring to the TLD manager, > not the service provider and if this proposal intends to change that, it should > be made more explicit. As the proposal intends to open the policy not only to TLD nameservers but to all Anycasting DNS setups (with some more requirements than just anycasting), you can't refer only to the TLD manager anymore. "An organisation" is the organisation that operates the DNS servers. One could include again the term of the TLD manager, but I think it doesn't make much sense here as operating a TLD is not a requirement anymore. >> anycasting technology would not pass the 'IANA Administrative Procedure for >> Root Zone Name Server Delegation and Glue Data' the organisation may receive >> a single dedicated /24 network prefix for the sole purpose of anycasting >> name servers, as described in RFC 3258. > >> The organisation should demonstrate that the number of name servers or IP >> addresses for these name servers in the delegation exceeds eight and that >> without anycasting their zone size exceeds the UDP datagram size. > > During the discussion of the original anycast policy proposal it was carefully > avoided -- after some looping debate -- to encode explicit DNS parameters > into said proposal. That's the whole point of referring to IANA's delegation > procedure. Now, I understand that IANA's procedures aren't applicable to > non-TLDs, but at the same time it isn't obvious where the number "eight" > originates from. Why is the IANA procedure not applicable to non-TLDs? It is clear that the IANA document only refers to TLD nameservers, but one can apply the requirements to other DNS setups as well. And in my opinion this is a good procedure, as the IANA policy in regards to the UDP packet size is a reasonably clear and well-defined requirement for having the need of an anycasting setup. > To make matters more complicated, the basic procedure IANA > is supposed to apply would indeed fit well, but then depends on the > respective parent's glue and registration policy. Sorry, can you explain this a bit further? > Again, I'm not sure > anyone would want the RIPE NCC to engage in cumbersome tests and > judgements, so even a fixed number might be fine - if there's some > rationale given. Yes, basically we can refer to the number of nameservers instead solely, but I meant to have a more technical justification (the size of the UDP datagrams) would be helpful. > NIT: "their zone size exceeds the UDP datagram size" should probably read > "a referral response for their domain would exceed the 512 octet UDP > payload limit". I'd be fine with changing the text accordingly. >> The organisation should also demonstrate that they need to do anycasting >> due to the geographical diversity of their DNS setup. The organisation will >> be required to demonstrate that anycasting will be used in diverse >> geographical locations. The existence of the real servers should be >> demonstrated with anycasting nodes that can be pinged and tracerouted. > > That should be topological diversity instead. I'm not so confident that > pings and traceroutes can differentiate between anycast and multihoming uses. > The basic question is whether checks should be applied at all. The checks were meant to provide a possibility for a check as last means if the application is clear enough. And for maintenance reasons, every anycasting DNS server is reachable by a dedicated IP, right? > Actually, the proliferation of anycast assignments could lead to more rigid > filtering. If that's the case, the current practice and policy of PI address assignments should lead to that as well. Regards: Tobias - -- Tobias Cremer M.A. IP Admin Engineer Cable & Wireless Telecommunication Services GmbH Landsbergerstr. 155 80687 Muenchen Germany Tel +49 89 926 99 0 -- FAX +49 89 926 99 180 -- COMNET 7 49 9169 Gesch?ftsf?hrer Francois Goreux, Richard Pennal Amtsgericht M?nchen HRB 146 617 www.cw.com/de - -- Every message GnuPG signed -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGOvxVhC6y11CNwvcRAmCwAJ44LwLrB+FIGsmDNI2lO8vU0lT2pgCgxEzP KLL+TVQcNN69Rk7YQLvf+5w= =qVfh -----END PGP SIGNATURE----- From shane at time-travellers.org Fri May 4 11:54:22 2007 From: shane at time-travellers.org (Shane Kerr) Date: Fri, 4 May 2007 11:54:22 +0200 Subject: [address-policy-wg] 2007-05 New Policy Proposal (IPv6 ULA-Central) In-Reply-To: <7.0.0.16.2.20070503081258.02703898@apnic.net> References: <20070502140047.E6CF22F583@herring.ripe.net> <20070502150323.GB3041@borg.c-l-i.net> <7.0.0.16.2.20070503081258.02703898@apnic.net> Message-ID: <20070504095422.GD13136@borg.c-l-i.net> Geoff, Thanks for this background and analysis. > i.e. What is the problem that C-ULA addresses are intended to solve > and what alternatives are available to us in looking at this > problem? So far I have yet to see the proposer of this policy > address this quite basic question. I suspect that the proposal would > be a fair deal clearer in intent, and a fair deal clearer in terms > of whether or not the proposal should be adopted, if we all clearly > understood what the underlying problem (or what shortfall in the > existing address distribution mechanisms) is that this proposal is > intending to address. I think this is the key question. RFC 4193 hints at the use cases, although does not talk too much about the motivation for these addresses. The basic motivation for local IPv6 *seems* to be RFC 1918 space (10.0.0.0/8 and the like) for IPv6. That makes a certain amount of sense. RFC 4193 space basically works like that today, right? The motivation for a version with a central registry however is not so obvious to me. The only justification I can think of is that you can be sure not to pick the same /48 as someone else has picked. But the chances of that are *billions* (that's "thousands of millions" to British folk) to one! If you consider a 1:10000000000 odds too great for you, then there are a couple other options: - get a /48 from someone with an RIR allocated block - take an IPv4 address that you have been assigned and convert it to a 2002::/48 block People more clever than me will surely be able to think of other options. If the motivation is something beyond the scope of basic networking, then the use cases should be outlined more clearly. > - the 'nature' of the distribution function for this part of the > IPv6 address appears to be an allocation to be undertaken in > perpetuity. If we do decide we need a central registry for local IPv6 addresses, then looking at these local addresses as if they were comparable to the current RIR allocations is a mistake IMHO. If there were to be a central registry, I think the simplest model would be the best: - The *only* thing that the registry would contain is a list of which /48 have been allocated. - Once allocated a /48 is allocated forever. - The list would not be publically visible (I would prefer that it be visible in the interest of transparency, but then someone could learn *when* a specific /48 was allocated, which could in theory have some privacy implications). There is no "ownership" or "transferance", no privacy issues. If you somehow forget which /48 you had, get another one. The routeability issue is the same as for RFC 1918 space I think. The existing RFC already says in big letters "please don't be route this". I don't have any answers about DNS, because frankly I think reverse DNS is stupid, and IPv6 reverse doubly so. Hey, I'm prejudiced, I know. :) > - Distribution functions. Should there be some form of 'wholesale' > form of bulk access to this registry, to allow, for example, a > manufacturer to place pre-paid prefixes into manufactured devices? > If not, could this form of use of the central registry services be > supported using mechanisms described in the current proposal? This is a possible concern. But I think this indicates that there are other use cases that need to be considered. Right now the IETF seems like the best place to handle these, not the RIRs. -- Shane From jeroen at unfix.org Fri May 4 12:11:55 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 04 May 2007 11:11:55 +0100 Subject: [address-policy-wg] 2007-05 New Policy Proposal (IPv6 ULA-Central) In-Reply-To: <20070504095422.GD13136@borg.c-l-i.net> References: <20070502140047.E6CF22F583@herring.ripe.net> <20070502150323.GB3041@borg.c-l-i.net> <7.0.0.16.2.20070503081258.02703898@apnic.net> <20070504095422.GD13136@borg.c-l-i.net> Message-ID: <463B06EB.9030706@spaghetti.zurich.ibm.com> Shane Kerr wrote: [..] > The basic motivation for local IPv6 *seems* to be RFC 1918 space > (10.0.0.0/8 and the like) for IPv6. That makes a certain amount of > sense. RFC 4193 space basically works like that today, right? Yes. > The motivation for a version with a central registry however is not so > obvious to me. The only justification I can think of is that you can > be sure not to pick the same /48 as someone else has picked. But the > chances of that are *billions* (that's "thousands of millions" to > British folk) to one! Correct, though this is for bean counters of course who don't want to take that chance. > If you consider a 1:10000000000 odds too great for you, then there are > a couple other options: > > - get a /48 from someone with an RIR allocated block This is IMHO the best option for those beancounters. If they really are so desperate to get a block, get one from the RIR. Especially as most likely one will be connecting to the Internet one day or another anyway and then suddenly you either need to renumber from your private block or pay enough cash to get it routed anyway. IMHO, Central ULA has no place, folks requiring that strict kind of allocation should simply get a publicly registered block. There is a side reason for me to say so, and that is simply because folks will want these blocks and start doing NAT for IPv6, just because they 'like it so much' and 'are used to it'. Discouraging that as much as possible is a good idea to keep the Internet end-to-end. > - take an IPv4 address that you have been assigned and convert it to a > 2002::/48 block Very sane one, but it might cause issues when you are going to try and route it to the $world as you will be forcing yourself to use other folks 6to4 relays, as such this is not an option. Remember you should not announce prefixes smaller than 2002::/16 into BGP. [..] > I don't have any answers about DNS, because frankly I think reverse > DNS is stupid, and IPv6 reverse doubly so. Hey, I'm prejudiced, I > know. :) It's very handy in a lot more cases than you think ;) In combo with DNSSEC, or the believe that the DNS is giving you the right answer it can be used for access control based on DNS-labels/domains instead of IP numbers. It is great for logfiles (if you trust dns) and makes traceroutes much more visible. There are a load of other options that a lot of people do like and thus require it for. BUT as these would be LOCAL networks, the folks running these LOCAL and non-internet connected networks can easily set up their internal internet-disconnected DNS server to do the reserve resolving. Just like is currently already happening for RFC1918. This also means that it might be good if AS112 folks start adding these prefixes to their nameservers so that they can catch those prefixes. (or is it already being done? :) Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From gert at space.net Fri May 4 13:22:29 2007 From: gert at space.net (Gert Doering) Date: Fri, 4 May 2007 13:22:29 +0200 Subject: [address-policy-wg] 2007-05 New Policy Proposal (IPv6 ULA-Central) In-Reply-To: <20070504095422.GD13136@borg.c-l-i.net> References: <20070502140047.E6CF22F583@herring.ripe.net> <20070502150323.GB3041@borg.c-l-i.net> <7.0.0.16.2.20070503081258.02703898@apnic.net> <20070504095422.GD13136@borg.c-l-i.net> Message-ID: <20070504112229.GV73965@Space.Net> Hi, On Fri, May 04, 2007 at 11:54:22AM +0200, Shane Kerr wrote: > The motivation for a version with a central registry however is not so > obvious to me. The only justification I can think of is that you can > be sure not to pick the same /48 as someone else has picked. But the > chances of that are *billions* (that's "thousands of millions" to > British folk) to one! Take the "birthday paradoxon" into account. Chances for a clash with "someone else in the room" are actually much higher than the chance for a clash with "a *specific* number out of the ame pool". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 113403 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 gih at apnic.net Fri May 4 14:00:06 2007 From: gih at apnic.net (Geoff Huston) Date: Fri, 4 May 2007 20:00:06 +0800 Subject: [address-policy-wg] 2007-05 New Policy Proposal (IPv6 ULA-Central) In-Reply-To: <20070504112229.GV73965@Space.Net> References: <20070502140047.E6CF22F583@herring.ripe.net> <20070502150323.GB3041@borg.c-l-i.net> <7.0.0.16.2.20070503081258.02703898@apnic.net> <20070504095422.GD13136@borg.c-l-i.net> <20070504112229.GV73965@Space.Net> Message-ID: <8f5c68a40705040500l5cff5eeeqd11ca72cc821c5bd@mail.gmail.com> On 5/4/07, Gert Doering wrote: > > Hi, > > On Fri, May 04, 2007 at 11:54:22AM +0200, Shane Kerr wrote: > > The motivation for a version with a central registry however is not so > > obvious to me. The only justification I can think of is that you can > > be sure not to pick the same /48 as someone else has picked. But the > > chances of that are *billions* (that's "thousands of millions" to > > British folk) to one! > > Take the "birthday paradoxon" into account. Chances for a clash with > "someone else in the room" are actually much higher than the chance > for a clash with "a *specific* number out of the ame pool". The general solution of the probability of a collision after d draws from n possible values is given by: P = 1 - ((n!) / ((n**d)((n-d)!))) Given that the value for n is 2.199,023,255,552, then the objective is to find the lowest value of d for which P is greater than or equal to 0.5. In this case the value for d is some 1.24 million. http://draft-huston-ipv6-local-use-comments.potaroo.net Geoff -------------- next part -------------- An HTML attachment was scrubbed... URL: From Woeber at CC.UniVie.ac.at Fri May 4 15:08:21 2007 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 04 May 2007 13:08:21 +0000 Subject: [address-policy-wg] 2007-05 New Policy Proposal (IPv6 ULA-Central) In-Reply-To: <8f5c68a40705040500l5cff5eeeqd11ca72cc821c5bd@mail.gmail.com> References: <20070502140047.E6CF22F583@herring.ripe.net> <20070502150323.GB3041@borg.c-l-i.net> <7.0.0.16.2.20070503081258.02703898@apnic.net> <20070504095422.GD13136@borg.c-l-i.net> <20070504112229.GV73965@Space.Net> <8f5c68a40705040500l5cff5eeeqd11ca72cc821c5bd@mail.gmail.com> Message-ID: <463B3045.4090800@CC.UniVie.ac.at> Geoff Huston wrote: > On 5/4/07, Gert Doering wrote: > >> >> Hi, >> >> On Fri, May 04, 2007 at 11:54:22AM +0200, Shane Kerr wrote: >> > The motivation for a version with a central registry however is not so >> > obvious to me. The only justification I can think of is that you can >> > be sure not to pick the same /48 as someone else has picked. But the >> > chances of that are *billions* (that's "thousands of millions" to >> > British folk) to one! >> >> Take the "birthday paradoxon" into account. Chances for a clash with >> "someone else in the room" are actually much higher than the chance >> for a clash with "a *specific* number out of the ame pool". > > > > The general solution of > the probability of a collision after d draws from n possible values > is given by: > > P = 1 - ((n!) / ((n**d)((n-d)!))) > > Given that the value for n is 2.199,023,255,552, then the objective > is to find the lowest value of d for which P is greater than or equal > to 0.5. In this case the value for d is some 1.24 million. That formula does apply under the assumption(s) that the draws will be evenly distributed across the value space, correct? > http://draft-huston-ipv6-local-use-comments.potaroo.net > > Geoff > Wilfried. From shane at time-travellers.org Fri May 4 15:38:57 2007 From: shane at time-travellers.org (Shane Kerr) Date: Fri, 4 May 2007 15:38:57 +0200 Subject: [address-policy-wg] 2007-05 New Policy Proposal (IPv6 ULA-Central) In-Reply-To: <8f5c68a40705040500l5cff5eeeqd11ca72cc821c5bd@mail.gmail.com> References: <20070502140047.E6CF22F583@herring.ripe.net> <20070502150323.GB3041@borg.c-l-i.net> <7.0.0.16.2.20070503081258.02703898@apnic.net> <20070504095422.GD13136@borg.c-l-i.net> <20070504112229.GV73965@Space.Net> <8f5c68a40705040500l5cff5eeeqd11ca72cc821c5bd@mail.gmail.com> Message-ID: <20070504133857.GA16540@borg.c-l-i.net> On Fri, May 04, 2007 at 08:00:06PM +0800, Geoff Huston wrote: > On 5/4/07, Gert Doering wrote: > > > >On Fri, May 04, 2007 at 11:54:22AM +0200, Shane Kerr wrote: > >> The motivation for a version with a central registry however is > >> not so obvious to me. The only justification I can think of is > >> that you can be sure not to pick the same /48 as someone else has > >> picked. But the chances of that are *billions* (that's "thousands > >> of millions" to British folk) to one! > > > >Take the "birthday paradoxon" into account. Chances for a clash > >with "someone else in the room" are actually much higher than the > >chance for a clash with "a *specific* number out of the ame pool". > > The general solution of the probability of a collision after d > draws from n possible values is given by: > > P = 1 - ((n!) / ((n**d)((n-d)!))) > > Given that the value for n is 2.199,023,255,552, then the > objective is to find the lowest value of d for which P is greater > than or equal to 0.5. In this case the value for d is some 1.24 > million. > > http://draft-huston-ipv6-local-use-comments.potaroo.net Since this address space is "local", the only time a collision matters is when: 1. Two users have the same local space. 2. These users interoperate in some way. The formula given only measures the first value. To look at the degenerate case: If each local prefix is totally disconnected, then there is still no possibility for a collision that matters. Another next case: For the case where each local prefix connects to a single other local prefix, then the if there are 1.24 million prefixes which result in a single collision, there is still only a 1 in 600000 chance that this will affect any one of those 1.24 million prefixes at all. I'm not feeling mathematical enough on this Friday afternoon to figure out an exact formula for this (I'm not sure if you can use an average value for the interconnectedness of the prefixes, for instance), but intuitively I still claim this is not a problem. -- Shane From gih at apnic.net Fri May 4 16:18:56 2007 From: gih at apnic.net (Geoff Huston) Date: Sat, 05 May 2007 00:18:56 +1000 Subject: [address-policy-wg] 2007-05 New Policy Proposal (IPv6 ULA-Central) In-Reply-To: <463B3045.4090800@CC.UniVie.ac.at> References: <20070502140047.E6CF22F583@herring.ripe.net> <20070502150323.GB3041@borg.c-l-i.net> <7.0.0.16.2.20070503081258.02703898@apnic.net> <20070504095422.GD13136@borg.c-l-i.net> <20070504112229.GV73965@Space.Net> <8f5c68a40705040500l5cff5eeeqd11ca72cc821c5bd@mail.gmail.com> <463B3045.4090800@CC.UniVie.ac.at> Message-ID: <7.0.0.16.2.20070505001813.070ff180@apnic.net> At 11:08 PM 4/05/2007, Wilfried Woeber, UniVie/ACOnet wrote: >Geoff Huston wrote: > > > On 5/4/07, Gert Doering wrote: > > > >> > >> Hi, > >> > >> On Fri, May 04, 2007 at 11:54:22AM +0200, Shane Kerr wrote: > >> > The motivation for a version with a central registry however is not so > >> > obvious to me. The only justification I can think of is that you can > >> > be sure not to pick the same /48 as someone else has picked. But the > >> > chances of that are *billions* (that's "thousands of millions" to > >> > British folk) to one! > >> > >> Take the "birthday paradoxon" into account. Chances for a clash with > >> "someone else in the room" are actually much higher than the chance > >> for a clash with "a *specific* number out of the ame pool". > > > > > > > > The general solution of > > the probability of a collision after d draws from n possible values > > is given by: > > > > P = 1 - ((n!) / ((n**d)((n-d)!))) > > > > Given that the value for n is 2.199,023,255,552, then the objective > > is to find the lowest value of d for which P is greater than or equal > > to 0.5. In this case the value for d is some 1.24 million. > >That formula does apply under the assumption(s) that the draws >will be evenly distributed across the value space, correct? Yes, thats correct. Geoff From vaf at cisco.com Fri May 4 20:56:37 2007 From: vaf at cisco.com (Vince Fuller) Date: Fri, 4 May 2007 11:56:37 -0700 Subject: [address-policy-wg] 2007-05 New Policy Proposal (IPv6 ULA-Central) In-Reply-To: <8f5c68a40705040500l5cff5eeeqd11ca72cc821c5bd@mail.gmail.com> References: <20070502140047.E6CF22F583@herring.ripe.net> <20070502150323.GB3041@borg.c-l-i.net> <7.0.0.16.2.20070503081258.02703898@apnic.net> <20070504095422.GD13136@borg.c-l-i.net> <20070504112229.GV73965@Space.Net> <8f5c68a40705040500l5cff5eeeqd11ca72cc821c5bd@mail.gmail.com> Message-ID: <20070504185637.GA30292@cisco.com> > The general solution of > the probability of a collision after d draws from n possible values > is given by: > > P = 1 - ((n!) / ((n**d)((n-d)!))) > > Given that the value for n is 2.199,023,255,552, then the objective > is to find the lowest value of d for which P is greater than or equal > to 0.5. In this case the value for d is some 1.24 million. > > > http://draft-huston-ipv6-local-use-comments.potaroo.net Are people going to pick random values? I'd expect a more likely outcome to be that they will pick strings that are easy to remember. How many collisions will there be if that is the case? Remember DEADBEEF? --Vince From jeroen at unfix.org Fri May 4 21:16:40 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 04 May 2007 20:16:40 +0100 Subject: [address-policy-wg] 2007-05 New Policy Proposal (IPv6 ULA-Central) In-Reply-To: <20070504185637.GA30292@cisco.com> References: <20070502140047.E6CF22F583@herring.ripe.net> <20070502150323.GB3041@borg.c-l-i.net> <7.0.0.16.2.20070503081258.02703898@apnic.net> <20070504095422.GD13136@borg.c-l-i.net> <20070504112229.GV73965@Space.Net> <8f5c68a40705040500l5cff5eeeqd11ca72cc821c5bd@mail.gmail.com> <20070504185637.GA30292@cisco.com> Message-ID: <463B8698.1030006@spaghetti.zurich.ibm.com> Vince Fuller wrote: >> The general solution of >> the probability of a collision after d draws from n possible values >> is given by: >> >> P = 1 - ((n!) / ((n**d)((n-d)!))) >> >> Given that the value for n is 2.199,023,255,552, then the objective >> is to find the lowest value of d for which P is greater than or equal >> to 0.5. In this case the value for d is some 1.24 million. >> >> >> http://draft-huston-ipv6-local-use-comments.potaroo.net > > Are people going to pick random values? I'd expect a more likely outcome > to be that they will pick strings that are easy to remember. How many > collisions will there be if that is the case? Remember DEADBEEF? If one is doing that, then why even bother using ULA's. Just use 1234::/48 or something similar then ;) One can't engineer around stupid people unfortunately... Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From alh-ietf at tndh.net Tue May 8 11:01:18 2007 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 8 May 2007 12:01:18 +0300 Subject: [address-policy-wg] 2007-05 New Policy Proposal (IPv6 ULA-Central) In-Reply-To: <463B8698.1030006@spaghetti.zurich.ibm.com> References: <20070502140047.E6CF22F583@herring.ripe.net> <20070502150323.GB3041@borg.c-l-i.net> <7.0.0.16.2.20070503081258.02703898@apnic.net> <20070504095422.GD13136@borg.c-l-i.net> <20070504112229.GV73965@Space.Net> <8f5c68a40705040500l5cff5eeeqd11ca72cc821c5bd@mail.gmail.com> <20070504185637.GA30292@cisco.com> <463B8698.1030006@spaghetti.zurich.ibm.com> Message-ID: <023101c7914f$72160c80$56422580$@net> Randomness could be a natural outcome if the default configuration for SOHO routers was to create one and bury the ability to specify it under some 'Advanced/Experts-only' option. There is a 'need' for this space to satisfy Enterprise network managers that have external partnerships and are unwilling to deal with collisions no matter how unlikely. While these organizations could use their PI space for this, they don't want to because that ends up impacting their internal routing due to the number of deaggregates that get announced. Tony > -----Original Message----- > From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg- > admin at ripe.net] On Behalf Of Jeroen Massar > Sent: Friday, May 04, 2007 10:17 PM > To: Vince Fuller > Cc: address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] 2007-05 New Policy Proposal (IPv6 ULA- > Central) > > Vince Fuller wrote: > >> The general solution of > >> the probability of a collision after d draws from n possible values > >> is given by: > >> > >> P = 1 - ((n!) / ((n**d)((n-d)!))) > >> > >> Given that the value for n is 2.199,023,255,552, then the objective > >> is to find the lowest value of d for which P is greater than or > equal > >> to 0.5. In this case the value for d is some 1.24 million. > >> > >> > >> http://draft-huston-ipv6-local-use-comments.potaroo.net > > > > Are people going to pick random values? I'd expect a more likely > > outcome to be that they will pick strings that are easy to remember. > > How many collisions will there be if that is the case? Remember > DEADBEEF? > > If one is doing that, then why even bother using ULA's. Just use > 1234::/48 or something similar then ;) > > One can't engineer around stupid people unfortunately... > > Greets, > Jeroen From jeroen at unfix.org Tue May 8 11:26:25 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 08 May 2007 10:26:25 +0100 Subject: [address-policy-wg] 2007-05 New Policy Proposal (IPv6 ULA-Central) In-Reply-To: <023101c7914f$72160c80$56422580$@net> References: <20070502140047.E6CF22F583@herring.ripe.net> <20070502150323.GB3041@borg.c-l-i.net> <7.0.0.16.2.20070503081258.02703898@apnic.net> <20070504095422.GD13136@borg.c-l-i.net> <20070504112229.GV73965@Space.Net> <8f5c68a40705040500l5cff5eeeqd11ca72cc821c5bd@mail.gmail.com> <20070504185637.GA30292@cisco.com> <463B8698.1030006@spaghetti.zurich.ibm.com> <023101c7914f$72160c80$56422580$@net> Message-ID: <46404241.4030305@spaghetti.zurich.ibm.com> Tony Hain wrote: > Randomness could be a natural outcome if the default configuration for SOHO > routers was to create one and bury the ability to specify it under some > 'Advanced/Experts-only' option. > > There is a 'need' for this space to satisfy Enterprise network managers that > have external partnerships and are unwilling to deal with collisions no > matter how unlikely. While these organizations could use their PI space for > this, they don't want to because that ends up impacting their internal > routing due to the number of deaggregates that get announced. Can you elaborate that last sentence? Do you mean that these people do not know that there is an 'aggregate' knob on their routers and that they will be deaggregating this prefix when announcing to the Internet? As I mentioned, we can't engineer around stupid people. The default of those routers should be to aggregate to resolve this 'problem'. What is the difference between having: 2001:db8::/48 + fc00:db8:5678:1::/64 + fc00:db8:5678:2::/64 and: 2001:db8::/48 + 2001:db8:5678:1::/64 + 2001:db8:5678:2::/64 For both prefixes (excuse the ULA central bit) one would have to go to the registry to get it, and as one gets PI, one is already going there, why go there twice and claim 2x /48, which most likely is waaaaaay too much anyway. Did I misunderstand something in your statement? Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From leo.vegoda at icann.org Tue May 8 12:42:21 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Tue, 8 May 2007 13:42:21 +0300 Subject: [address-policy-wg] 2007-05 New Policy Proposal (IPv6 ULA-Central) In-Reply-To: <023101c7914f$72160c80$56422580$@net> References: <20070502140047.E6CF22F583@herring.ripe.net> <20070502150323.GB3041@borg.c-l-i.net> <7.0.0.16.2.20070503081258.02703898@apnic.net> <20070504095422.GD13136@borg.c-l-i.net> <20070504112229.GV73965@Space.Net> <8f5c68a40705040500l5cff5eeeqd11ca72cc821c5bd@mail.gmail.com> <20070504185637.GA30292@cisco.com> <463B8698.1030006@spaghetti.zurich.ibm.com> <023101c7914f$72160c80$56422580$@net> Message-ID: On 8 May 2007, at 12:01pm, Tony Hain wrote: > Randomness could be a natural outcome if the default configuration > for SOHO > routers was to create one and bury the ability to specify it under > some > 'Advanced/Experts-only' option. Do you see a lot of demand for separate internal and external addressing in SOHO networks? -- Leo Vegoda IANA Numbers Liaison From alh-ietf at tndh.net Tue May 8 13:39:30 2007 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 8 May 2007 14:39:30 +0300 Subject: [address-policy-wg] 2007-05 New Policy Proposal (IPv6 ULA-Central) In-Reply-To: <46404241.4030305@spaghetti.zurich.ibm.com> References: <20070502140047.E6CF22F583@herring.ripe.net> <20070502150323.GB3041@borg.c-l-i.net> <7.0.0.16.2.20070503081258.02703898@apnic.net> <20070504095422.GD13136@borg.c-l-i.net> <20070504112229.GV73965@Space.Net> <8f5c68a40705040500l5cff5eeeqd11ca72cc821c5bd@mail.gmail.com> <20070504185637.GA30292@cisco.com> <463B8698.1030006@spaghetti.zurich.ibm.com> <023101c7914f$72160c80$56422580$@net> <46404241.4030305@spaghetti.zurich.ibm.com> Message-ID: <025901c79165$8c1cca90$a4565fb0$@net> Jeroen Massar wrote: > Tony Hain wrote: > > Randomness could be a natural outcome if the default configuration for > > SOHO routers was to create one and bury the ability to specify it > > under some 'Advanced/Experts-only' option. > > > > There is a 'need' for this space to satisfy Enterprise network > > managers that have external partnerships and are unwilling to deal > > with collisions no matter how unlikely. While these organizations > > could use their PI space for this, they don't want to because that > > ends up impacting their internal routing due to the number of > deaggregates that get announced. > > Can you elaborate that last sentence? Do you mean that these people do > not know that there is an 'aggregate' knob on their routers and that > they will be deaggregating this prefix when announcing to the Internet? No. Consider a global organization that has multiple suppliers/partners with private interconnects for specific business functions. The goal is to restrict the private interconnect to use for the specific task, not to leave it open for all traffic between the organizations. To manage traffic they deaggregate the partner network and announce the specific part for the private link, and the aggregate via another path for the rest. The result is 2x entries for each partner. This is avoided in IPv4 by using nat to create an artificial internal aggregate leading to the edge where these partner networks are connected. By using the central ULA (and more efficiently by carving that by region), they can recreate this internal aggregate model while avoiding any possibility of collision. > > As I mentioned, we can't engineer around stupid people. The default of > those routers should be to aggregate to resolve this 'problem'. > > What is the difference between having: > 2001:db8::/48 + fc00:db8:5678:1::/64 + fc00:db8:5678:2::/64 > and: > 2001:db8::/48 + 2001:db8:5678:1::/64 + 2001:db8:5678:2::/64 Nothing. If they announce the full deaggregate for the ULA space the impact would be the same as using PI deaggregates. The value is to have fc00:/8 lead to the demarcation for all the partners, rather than explicitly announce every partner subnet throughout their own organization. > > For both prefixes (excuse the ULA central bit) one would have to go to > the registry to get it, and as one gets PI, one is already going there, > why go there twice and claim 2x /48, which most likely is waaaaaay too > much anyway. > > Did I misunderstand something in your statement? > > Greets, > Jeroen From alh-ietf at tndh.net Tue May 8 13:55:55 2007 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 8 May 2007 14:55:55 +0300 Subject: [address-policy-wg] 2007-05 New Policy Proposal (IPv6 ULA-Central) In-Reply-To: References: <20070502140047.E6CF22F583@herring.ripe.net> <20070502150323.GB3041@borg.c-l-i.net> <7.0.0.16.2.20070503081258.02703898@apnic.net> <20070504095422.GD13136@borg.c-l-i.net> <20070504112229.GV73965@Space.Net> <8f5c68a40705040500l5cff5eeeqd11ca72cc821c5bd@mail.gmail.com> <20070504185637.GA30292@cisco.com> <463B8698.1030006@spaghetti.zurich.ibm.com> <023101c7914f$72160c80$56422580$@net> Message-ID: <026101c79167$d7864b30$8692e190$@net> Leo Vegoda wrote: > On 8 May 2007, at 12:01pm, Tony Hain wrote: > > > Randomness could be a natural outcome if the default configuration > > for SOHO > > routers was to create one and bury the ability to specify it under > > some > > 'Advanced/Experts-only' option. > > Do you see a lot of demand for separate internal and external > addressing in SOHO networks? Separating reachability is what firewalling is all about... 'No route' is more effective than the fastest deep packet inspection engine. Consider that the default configuration for a printer should not be to bind to a global prefix because that is generally a local function. There are more examples related to home automation of what is to come, more so than what exists to create current demand. Either way, it is trivial for a SOHO device to generate the random prefix and avoid the problem of people all selecting the same thing. If it gets used or not is a completely independent discussion. Tony From jeroen at unfix.org Tue May 8 17:42:16 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 08 May 2007 16:42:16 +0100 Subject: [address-policy-wg] 2007-05 New Policy Proposal (IPv6 ULA-Central) In-Reply-To: <025901c79165$8c1cca90$a4565fb0$@net> References: <20070502140047.E6CF22F583@herring.ripe.net> <20070502150323.GB3041@borg.c-l-i.net> <7.0.0.16.2.20070503081258.02703898@apnic.net> <20070504095422.GD13136@borg.c-l-i.net> <20070504112229.GV73965@Space.Net> <8f5c68a40705040500l5cff5eeeqd11ca72cc821c5bd@mail.gmail.com> <20070504185637.GA30292@cisco.com> <463B8698.1030006@spaghetti.zurich.ibm.com> <023101c7914f$72160c80$56422580$@net> <46404241.4030305@spaghetti.zurich.ibm.com> <025901c79165$8c1cca90$a4565fb0$@net> Message-ID: <46409A58.8030808@spaghetti.zurich.ibm.com> Tony Hain wrote: [..] >> What is the difference between having: >> 2001:db8::/48 + fc00:db8:5678:1::/64 + fc00:db8:5678:2::/64 >> and: >> 2001:db8::/48 + 2001:db8:5678:1::/64 + 2001:db8:5678:2::/64 > > Nothing. If they announce the full deaggregate for the ULA space the impact > would be the same as using PI deaggregates. The value is to have fc00:/8 > lead to the demarcation for all the partners, rather than explicitly > announce every partner subnet throughout their own organization. Ok, if I understood correctly (guess a little drawing would help even more ;), you mean that, taking the above example, they will only have a 2001:db8::/48 and fc00::/8 route in their tables and nothing else? Otherwise they would end up with a large amount of /64's in their internal tables pointing to the partner. Also, they know that fc00::/8 is 'private' and that they need to firewall that in a different way. Which is a good property. But how is this different from having a single default to the edge routers + firewalls, which take care of the routing tables to the endsite? You then have a single location to maintain, and those entries are then popping up only there and nowhere else. Also, this sort of implies, from what I understood, that every host on the network will get multiple addresses, at least one from PI, and one from the ULA prefix. I do hope then that source address selection is being done correctly. Fortunately, fec00::/7 is at the top of the address space and thus can't easily be confused, like with 6to4 which is in the 'middle' and suddenly does get chosen for 2003::/16 and all other addresses, while the 2001::/16 prefix is used for 2001::/16 addresses. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From alh-ietf at tndh.net Wed May 9 05:40:24 2007 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 9 May 2007 06:40:24 +0300 Subject: [address-policy-wg] 2007-05 New Policy Proposal (IPv6 ULA-Central) In-Reply-To: <46409A58.8030808@spaghetti.zurich.ibm.com> References: <20070502140047.E6CF22F583@herring.ripe.net> <20070502150323.GB3041@borg.c-l-i.net> <7.0.0.16.2.20070503081258.02703898@apnic.net> <20070504095422.GD13136@borg.c-l-i.net> <20070504112229.GV73965@Space.Net> <8f5c68a40705040500l5cff5eeeqd11ca72cc821c5bd@mail.gmail.com> <20070504185637.GA30292@cisco.com> <463B8698.1030006@spaghetti.zurich.ibm.com> <023101c7914f$72160c80$56422580$@net> <46404241.4030305@spaghetti.zurich.ibm.com> <025901c79165$8c1cca90$a4565fb0$@net> <46409A58.8030808@spaghetti.zurich.ibm.com> Message-ID: <02cc01c791eb$c893a5d0$59baf170$@net> Jeroen Massar wrote: > Tony Hain wrote: > [..] > >> What is the difference between having: > >> 2001:db8::/48 + fc00:db8:5678:1::/64 + fc00:db8:5678:2::/64 > >> and: > >> 2001:db8::/48 + 2001:db8:5678:1::/64 + 2001:db8:5678:2::/64 > > > > Nothing. If they announce the full deaggregate for the ULA space the > > impact would be the same as using PI deaggregates. The value is to > > have fc00:/8 lead to the demarcation for all the partners, rather than > > explicitly announce every partner subnet throughout their own > organization. > > Ok, if I understood correctly (guess a little drawing would help even > more ;), you mean that, taking the above example, they will only have a > 2001:db8::/48 and fc00::/8 route in their tables and nothing else? > Otherwise they would end up with a large amount of /64's in their > internal tables pointing to the partner. Essentially this is the goal. Every situation will be different, like if there are 3 regional interconnects between a particular pair of companies that would likely mean 3 more explicit routes for the fc00/8 block, but not necessarily one for every partner in each region. > > Also, they know that fc00::/8 is 'private' and that they need to > firewall that in a different way. Which is a good property. > > But how is this different from having a single default to the edge > routers + firewalls, which take care of the routing tables to the > endsite? You then have a single location to maintain, and those entries > are then popping up only there and nowhere else. That would be true if the demarcation for the default route and the private interconnect block were in the same place. If the Internet default and the private peering are on different routers sets then you need a way to split off the traffic. > > Also, this sort of implies, from what I understood, that every host on > the network will get multiple addresses, at least one from PI, and one > from the ULA prefix. I do hope then that source address selection is > being done correctly. Fortunately, fec00::/7 is at the top of the > address space and thus can't easily be confused, like with 6to4 which is > in the 'middle' and suddenly does get chosen for 2003::/16 and all other > addresses, while the 2001::/16 prefix is used for 2001::/16 addresses. Address selection is a mystery to most, but we need to fix 3484 to replace the references to SL with ULA, then the right thing happens. Tony From sw+ripe-apwg at internetx.de Wed May 9 12:00:06 2007 From: sw+ripe-apwg at internetx.de (Sebastian Wiesinger) Date: Wed, 9 May 2007 12:00:06 +0200 Subject: [address-policy-wg] 2007-02 New Policy Proposal (Change in IP Assignments for Anycasting DNS Policy) In-Reply-To: <463AFC56.1000000@cw.net> References: <20070423132426.B75702F583@herring.ripe.net> <20070502170710.GI866@unknown.office.denic.de> <463AFC56.1000000@cw.net> Message-ID: <20070509100006.GA14765@lain.intern.internetx.de> * Tobias Cremer [2007-05-04 11:28]: > > During the discussion of the original anycast policy proposal it was carefully > > avoided -- after some looping debate -- to encode explicit DNS parameters > > into said proposal. That's the whole point of referring to IANA's delegation > > procedure. Now, I understand that IANA's procedures aren't applicable to > > non-TLDs, but at the same time it isn't obvious where the number "eight" > > originates from. > > Why is the IANA procedure not applicable to non-TLDs? It is clear that > the IANA document only refers to TLD nameservers, but one can apply the > requirements to other DNS setups as well. And in my opinion this is a > good procedure, as the IANA policy in regards to the UDP packet size is > a reasonably clear and well-defined requirement for having the need of > an anycasting setup. Hello, the company I work for would greatly appreciate this policy change. We're hosting a huge amount of zones. We would benefit from using anycast for our setup, but not so much in regard to the 512 byte limit of the referral response. We see the need for an anycast setup for other reasons. Most important to us: The mitigation of damage/effects from (D)DoS or disaster at / shutdown of a site. In this case the anycast setup would prevent bigger problems because other sites would handle the DNS requests. Besides that, anycast would improve our setup with load sharing between anycast locations and the possibility to deploy locations in other countries to improve response time. In this regard I would appreciate alternatives to the 8 NS rule in the policy. I must admit that I'm not quite sure what the alternatives should be, but I'm looking forward to comments/suggestions. Regards, Sebastian -- InterNetX GmbH Maximilianstr. 6 93047 Regensburg Germany Tel. +49 941 59559-480 Fax +49 941 59579-051 Gesch?ftsf?hrer/CEO: Thomas M?rz Amtsgericht Regensburg, HRB 7142 nic-hdl : SW1421-RIPE GPG-Key : 0x97F5A1D8 (0x8431335F97F5A1D8) GPG-Fingerprint : 6181 B041 3554 0B6F 4EF3 1B12 8431 335F 97F5 A1D8 From ondrej.sury at nic.cz Wed May 9 13:30:53 2007 From: ondrej.sury at nic.cz (=?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?=) Date: Wed, 09 May 2007 14:30:53 +0300 Subject: [address-policy-wg] 2007-02 New Policy Proposal (Change in IP Assignments for Anycasting DNS Policy) In-Reply-To: <20070509100006.GA14765@lain.intern.internetx.de> References: <20070423132426.B75702F583@herring.ripe.net> <20070502170710.GI866@unknown.office.denic.de> <463AFC56.1000000@cw.net> <20070509100006.GA14765@lain.intern.internetx.de> Message-ID: <1178710253.10077.21.camel@yuna> Sebastian Wiesinger p??e v St 09. 05. 2007 v 12:00 +0200: > We're hosting a huge amount of zones. We would benefit from using > anycast for our setup, but not so much in regard to the 512 byte limit > of the referral response. We see the need for an anycast setup for > other reasons. That's very good point. We don't have problem with 8 IP addresses since we are (will be shortly) running IPv6 on all our DNS nodes. We don't even have a problem to create 512 payload, since we are already almost at the limit and we plan to have more nodes. But our reasons for having anycasted DNS lies within stability and resiliency and not within "not able to fit in 512 bytes". I would rather have 4 anycasted nodes then to have 1 anycast and 7 unicast (or 2/6 setup). On the other hand I thought that this Anycasting DNS policy was made to cover "critical infrastructure of Internet". If we loosen this policy then anybody can create such DNS setup to grow bigger then 8 IP addresses and 512 and receive anycast IPv4/IPv6 address. I would be extremely careful to make those rules less strict (wearing my ccTLD hat now :-). Ondrej. -- Ond?ej Sur? technick? ?editel/Chief Technical Officer ----------------------------------------- CZ.NIC, z.s.p.o. -- .cz domain registry Americk? 23,120 00 Praha 2,Czech Republic mailto:ondrej.sury at nic.cz http://nic.cz/ sip:ondrej.sury at nic.cz tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 ----------------------------------------- From heather.skanks at gmail.com Wed May 9 15:11:55 2007 From: heather.skanks at gmail.com (heather skanks) Date: Wed, 9 May 2007 09:11:55 -0400 Subject: Fwd: [address-policy-wg] 2007-02 New Policy Proposal (Change in IP Assignments for Anycasting DNS Policy) In-Reply-To: <616812070705090548r12ece1bar7c877f709249cefd@mail.gmail.com> References: <20070423132426.B75702F583@herring.ripe.net> <462F3E4C.6010502@CC.UniVie.ac.at> <20070425142233.GP73965@Space.Net> <462F694A.4060901@inex.ie> <20070425145205.GQ73965@Space.Net> <5FCDC1C5A3A941E7852005C718E619B5@tungemaskin> <20070425150837.GU73965@Space.Net> <616812070705090548r12ece1bar7c877f709249cefd@mail.gmail.com> Message-ID: <616812070705090611u7422e2ddj87731b031f2162ec@mail.gmail.com> Sorry meant to send this to the list! --Heather ---------- Forwarded message ---------- From: heather skanks Date: May 9, 2007 8:48 AM Subject: Re: [address-policy-wg] 2007-02 New Policy Proposal (Change in IP Assignments for Anycasting DNS Policy) To: Gert Doering Why the assumptaion that anycast requires PI space in the first place? I can understand why it might be preferred that DNS operators have PI space, regardless of whether they anycast. They don't need a lot of space to run the service, and without a policy to allow them to get PI, they would be dependent on space from a provider. But, I think their need for PI has more to do with them being critical infrastructure, rather than the fact that they anycast. The fact that they don't need a lot of space to run the service and wouldn't otherwise qualify for PI, means that there needs to be a special policy for them. That said, the change from "If the name server set of a ccTLD or a gTLD " to: "If the name server set of an organisation running DNS" The rest of the policy goes on to make the requirement that they have 8 or more IP addresses for the services (pre anycasting) and demonstration of the need to do anycasting. The new text seems to change the policy to hinge more on the need to anycast as justification for this space, rather than the service being critical infrastructure. I don't know of anything inherent in anycast technology that would require provider independent space. --Heather On 4/25/07, Gert Doering wrote: > > Hi, > > On Wed, Apr 25, 2007 at 05:00:52PM +0200, J?rgen Hovland wrote: > > Why does this proposal say it's for DNS only? > > The protocol is changing an existing policy document, which has "DNS only" > > in it. It's not creating new policy. > > > I guess other anycast protocols aren't important enough? > > What other anycast protocols are in widespread use today? > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: 113403 > > 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 -------------- An HTML attachment was scrubbed... URL: From jorgen at hovland.cx Wed May 9 15:32:25 2007 From: jorgen at hovland.cx (=?UTF-8?Q?J=C3=B8rgen_Hovland?=) Date: Wed, 9 May 2007 15:32:25 +0200 Subject: [address-policy-wg] 2007-02 New Policy Proposal (Change in IP Assignments for Anycasting DNS Policy) In-Reply-To: <616812070705090611u7422e2ddj87731b031f2162ec@mail.gmail.com> References: <20070423132426.B75702F583@herring.ripe.net> <462F3E4C.6010502@CC.UniVie.ac.at> <20070425142233.GP73965@Space.Net> <462F694A.4060901@inex.ie> <20070425145205.GQ73965@Space.Net> <5FCDC1C5A3A941E7852005C718E619B5@tungemaskin> <20070425150837.GU73965@Space.Net> <616812070705090548r12ece1bar7c877f709249cefd@mail.gmail.com> <616812070705090611u7422e2ddj87731b031f2162ec@mail.gmail.com> Message-ID: <05C4EF902BB74DAAABFE2264E415C34F@tungemaskin> Hi Heather, ---------- Forwarded message ---------- From: heather skanks < heather.skanks at gmail.com> Date: May 9, 2007 8:48 AM Subject: Re: [address-policy-wg] 2007-02 New Policy Proposal (Change in IP Assignments for Anycasting DNS Policy) To: Gert Doering < gert at space.net> > Why the assumptaion that anycast requires PI space in the first place? I agree, and I already mentioned this 2 years ago: http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2005/msg01079.html The 8 ip-address limit only limits actual locations you can place your nameservers at. So 8 locations/different ISPs is with todays standard more than enough? At those 8 locations you can at each configure 80 network load balancing servers causing a total capacity of ~13 million queries per second with old hardware and bad dns software. There is no such thing as ?critical internet infrastructure?. The internet is never stronger than its weakest link. If that is ccTLD nameservers... okay. (This whole anycast problem only concerns nameservers with very few but extremely large zones. The others can just spread them into different nameservers) Cheers, -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeroen at unfix.org Wed May 9 15:35:33 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 09 May 2007 14:35:33 +0100 Subject: Fwd: [address-policy-wg] 2007-02 New Policy Proposal (Change in IP Assignments for Anycasting DNS Policy) In-Reply-To: <616812070705090611u7422e2ddj87731b031f2162ec@mail.gmail.com> References: <20070423132426.B75702F583@herring.ripe.net> <462F3E4C.6010502@CC.UniVie.ac.at> <20070425142233.GP73965@Space.Net> <462F694A.4060901@inex.ie> <20070425145205.GQ73965@Space.Net> <5FCDC1C5A3A941E7852005C718E619B5@tungemaskin> <20070425150837.GU73965@Space.Net> <616812070705090548r12ece1bar7c877f709249cefd@mail.gmail.com> <616812070705090611u7422e2ddj87731b031f2162ec@mail.gmail.com> Message-ID: <4641CE25.6040508@spaghetti.zurich.ibm.com> [ can people avoid using HTML please.... eyes hurt etc ] Heather Skanks wrote: [..] > That said, the change from > "If the name server set of a ccTLD or a gTLD " > to: > "If the name server set of an organisation running DNS" > The rest of the policy goes on to make the requirement that they have 8 > or more IP addresses for the services (pre anycasting) > and demonstration of the need to do anycasting. > > The new text seems to change the policy to hinge more on the need to > anycast as justification for this space, rather than the service being > critical infrastructure. As without that little rule I could simply ask for a nice chunk of /24 PI space for my "DNS servers" which are used for my single domain. (Gert I need a /24 PI for my unfix.org dns servers!!!! kidding :) That said, as this policy is specific for organizations running, why not simply have a "minimum amount of DNS 2nd and 1st level zones served". Giving the criteria "runs one or more TLD's" justification to apply to this policy. And "runs more than a 10.000 1st level domains" justification to apply to it too. (10k chosen arbitrarily, I'll let the folks here figure that number out :) Greets, Jeroen (in the above TLD = ".com", 1st level domain == "example.com", 2nd level domain would be "marketing.example.com", of course for TLD's like .uk, a 1st level domain is "example.co.uk") -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From jorgen at hovland.cx Wed May 9 15:45:44 2007 From: jorgen at hovland.cx (=?UTF-8?Q?J=C3=B8rgen_Hovland?=) Date: Wed, 9 May 2007 15:45:44 +0200 Subject: Fwd: [address-policy-wg] 2007-02 New Policy Proposal (Change in IP Assignments for Anycasting DNS Policy) In-Reply-To: <4641CE25.6040508@spaghetti.zurich.ibm.com> References: <20070423132426.B75702F583@herring.ripe.net> <462F3E4C.6010502@CC.UniVie.ac.at> <20070425142233.GP73965@Space.Net> <462F694A.4060901@inex.ie> <20070425145205.GQ73965@Space.Net> <5FCDC1C5A3A941E7852005C718E619B5@tungemaskin> <20070425150837.GU73965@Space.Net> <616812070705090548r12ece1bar7c877f709249cefd@mail.gmail.com> <616812070705090611u7422e2ddj87731b031f2162ec@mail.gmail.com> <4641CE25.6040508@spaghetti.zurich.ibm.com> Message-ID: I thought we learned from the 200 customer rule :-) j -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Jeroen Massar Sent: 9. mai 2007 15:36 To: Heather Skanks Cc: address-policy-wg at ripe.net Subject: Re: Fwd: [address-policy-wg] 2007-02 New Policy Proposal (Change in IP Assignments for Anycasting DNS Policy) [ can people avoid using HTML please.... eyes hurt etc ] Heather Skanks wrote: [..] > That said, the change from > "If the name server set of a ccTLD or a gTLD " > to: > "If the name server set of an organisation running DNS" > The rest of the policy goes on to make the requirement that they have 8 > or more IP addresses for the services (pre anycasting) > and demonstration of the need to do anycasting. > > The new text seems to change the policy to hinge more on the need to > anycast as justification for this space, rather than the service being > critical infrastructure. As without that little rule I could simply ask for a nice chunk of /24 PI space for my "DNS servers" which are used for my single domain. (Gert I need a /24 PI for my unfix.org dns servers!!!! kidding :) That said, as this policy is specific for organizations running, why not simply have a "minimum amount of DNS 2nd and 1st level zones served". Giving the criteria "runs one or more TLD's" justification to apply to this policy. And "runs more than a 10.000 1st level domains" justification to apply to it too. (10k chosen arbitrarily, I'll let the folks here figure that number out :) Greets, Jeroen (in the above TLD = ".com", 1st level domain == "example.com", 2nd level domain would be "marketing.example.com", of course for TLD's like .uk, a 1st level domain is "example.co.uk") From jeroen at unfix.org Wed May 9 15:54:08 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 09 May 2007 14:54:08 +0100 Subject: Fwd: [address-policy-wg] 2007-02 New Policy Proposal (Change in IP Assignments for Anycasting DNS Policy) In-Reply-To: References: <20070423132426.B75702F583@herring.ripe.net> <462F3E4C.6010502@CC.UniVie.ac.at> <20070425142233.GP73965@Space.Net> <462F694A.4060901@inex.ie> <20070425145205.GQ73965@Space.Net> <5FCDC1C5A3A941E7852005C718E619B5@tungemaskin> <20070425150837.GU73965@Space.Net> <616812070705090548r12ece1bar7c877f709249cefd@mail.gmail.com> <616812070705090611u7422e2ddj87731b031f2162ec@mail.gmail.com> <4641CE25.6040508@spaghetti.zurich.ibm.com> Message-ID: <4641D280.1020104@spaghetti.zurich.ibm.com> J?rgen Hovland wrote: > I thought we learned from the 200 customer rule :-) And what exactly did you learn from that rule? Ah indeed, that instead of requiring 200 customers, one could better simply let the requester justify the address space. If you have 1 zone to serve, and you request a PI block for that, I don't really see a real justification. If you have one or more TLD's, I definitely see a justification. If you have 10.000 zones, I can also be tricked into seeing a justification. As I mentioned, the 10k is an arbitrary number, to avoid exactly what the 200 number was for: that everybody can grab PI space for their need wherever they want. Of course, I can't care less so much about IPv4, it will make it run out even further, but letting junk into the IPv6 space is waste. Then again, one can of course say "I am a site" and get a nice /48 PI from ARIN already. Or just claim you are an IX of course. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From andy at nosignal.org Wed May 9 17:39:02 2007 From: andy at nosignal.org (Andy Davidson) Date: Wed, 9 May 2007 16:39:02 +0100 Subject: [address-policy-wg] 2007-02 New Policy Proposal (Change in IP Assignments for Anycasting DNS Policy) In-Reply-To: <4641D280.1020104@spaghetti.zurich.ibm.com> References: <20070423132426.B75702F583@herring.ripe.net> <462F3E4C.6010502@CC.UniVie.ac.at> <20070425142233.GP73965@Space.Net> <462F694A.4060901@inex.ie> <20070425145205.GQ73965@Space.Net> <5FCDC1C5A3A941E7852005C718E619B5@tungemaskin> <20070425150837.GU73965@Space.Net> <616812070705090548r12ece1bar7c877f709249cefd@mail.gmail.com> <616812070705090611u7422e2ddj87731b031f2162ec@mail.gmail.com> <4641CE25.6040508@spaghetti.zurich.ibm.com> <4641D280.1020104@spaghetti.zurich.ibm.com> Message-ID: <703E84C8-DA5C-4503-B0E8-4B569CA80EE8@nosignal.org> On 9 May 2007, at 14:54, Jeroen Massar wrote: > If you have 1 zone to serve, and you request a PI block for that, I > don't really see a real justification. What about if it's one very popular zone, and you want to get dns for it topologically close to as many end users as possible ? There's nothing to stop you breaking off a bit of your PA and getting that announced at lots of places where you host an anycast instance, but now we're causing deaggregation. -- Andy Davidson - ( http://www.andyd.net/ ) From maem at nic.ad.jp Wed May 9 18:28:38 2007 From: maem at nic.ad.jp (MAEMURA Akinori) Date: Thu, 10 May 2007 01:28:38 +0900 Subject: [address-policy-wg] 2007-03 New Policy Proposal (IPv4 Countdown Policy) In-Reply-To: <20070424133558.3DE412F583@herring.ripe.net> References: <20070424133558.3DE412F583@herring.ripe.net> Message-ID: <200705100128.FJI86988.BNFN@nic.ad.jp> Hi Colleagues, Thank you for your attention during today's address policy wg meeting. We understand the presentation today was the start of discussion for this proposal. Any of your input, including support, objection, suggestion, related deleberation, feeling and so on would be really appreciated for us to craft it in better shape. As you may know, the presentation slides are available on RIPE web site at http://www.ripe.net/ripe/meetings/ripe-54/presentations/IPv4_Countdown_Policy_Proposal.pdf Best Regards, Akinori MAEMURA for Author Team In message <20070424133558.3DE412F583 at herring.ripe.net> "[address-policy-wg] 2007-03 New Policy Proposal (IPv4 Countdown Policy)" "Filiz Yilmaz " wrote: | PDP Number: 2007-03 | IPv4 Countdown Policy | | Dear Colleagues | | A new RIPE Policy Proposal has been made and is now available for | discussion. | | This proposal proposes four general principles, which will be | needed to accomplish the smooth termination of IPv4 address | allocation. | | You can find the full proposal at: | | http://www.ripe.net/ripe/policies/proposals/2007-03.html | | We encourage you to review this proposal and send your comments to | before 22 May 2007. | | Regards | | Filiz Yilmaz | RIPE NCC | Policy Development Officer | | | From leo.vegoda at icann.org Wed May 9 21:58:10 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 9 May 2007 22:58:10 +0300 Subject: [address-policy-wg] 2007-02 New Policy Proposal (Change in IP Assignments for Anycasting DNS Policy) In-Reply-To: <703E84C8-DA5C-4503-B0E8-4B569CA80EE8@nosignal.org> References: <20070423132426.B75702F583@herring.ripe.net> <462F3E4C.6010502@CC.UniVie.ac.at> <20070425142233.GP73965@Space.Net> <462F694A.4060901@inex.ie> <20070425145205.GQ73965@Space.Net> <5FCDC1C5A3A941E7852005C718E619B5@tungemaskin> <20070425150837.GU73965@Space.Net> <616812070705090548r12ece1bar7c877f709249cefd@mail.gmail.com> <616812070705090611u7422e2ddj87731b031f2162ec@mail.gmail.com> <4641CE25.6040508@spaghetti.zurich.ibm.com> <4641D280.1020104@spaghetti.zurich.ibm.com> <703E84C8-DA5C-4503-B0E8-4B569CA80EE8@nosignal.org> Message-ID: <68B1206E-B911-48CB-9127-27CB532771E3@icann.org> On 9 May 2007, at 6:39pm, Andy Davidson wrote: >> >> If you have 1 zone to serve, and you request a PI block for that, >> I don't really see a real justification. > > What about if it's one very popular zone, and you want to get dns > for it topologically close to as many end users as possible ? > > There's nothing to stop you breaking off a bit of your PA and > getting that announced at lots of places where you host an anycast > instance, but now we're causing deaggregation. If you aren't the LIR then you probably need the agreement of the LIR before deaggregating their allocation. I suspect that lots of organisations would like to spread the DNS load but aren't LIRs. Regards, -- Leo Vegoda IANA Numbers Liaison From sw+ripe-apwg at internetx.de Thu May 10 09:50:04 2007 From: sw+ripe-apwg at internetx.de (Sebastian Wiesinger) Date: Thu, 10 May 2007 09:50:04 +0200 Subject: Fwd: [address-policy-wg] 2007-02 New Policy Proposal (Change in IP Assignments for Anycasting DNS Policy) In-Reply-To: <4641D280.1020104@spaghetti.zurich.ibm.com> References: <20070425142233.GP73965@Space.Net> <462F694A.4060901@inex.ie> <20070425145205.GQ73965@Space.Net> <5FCDC1C5A3A941E7852005C718E619B5@tungemaskin> <20070425150837.GU73965@Space.Net> <616812070705090548r12ece1bar7c877f709249cefd@mail.gmail.com> <616812070705090611u7422e2ddj87731b031f2162ec@mail.gmail.com> <4641CE25.6040508@spaghetti.zurich.ibm.com> <4641D280.1020104@spaghetti.zurich.ibm.com> Message-ID: <20070510075004.GA6355@lain.intern.internetx.de> * Jeroen Massar [2007-05-09 15:55]: > If you have 1 zone to serve, and you request a PI block for that, I > don't really see a real justification. > > If you have one or more TLD's, I definitely see a justification. > > If you have 10.000 zones, I can also be tricked into seeing a justification. I agree with Jeroen. We're having waaay more than 10.000 zones which (currently) don't go over the 512 byte limit. On the contrary, if I wanted to get PI, what would stop me from taking one zone, expand it's dns records up to 512+ byte and request the space? I'm more in favor for a "number of zones" limit. Regards, Sebastian -- InterNetX GmbH Maximilianstr. 6 93047 Regensburg Germany Tel. +49 941 59559-480 Fax +49 941 59579-051 Gesch?ftsf?hrer/CEO: Thomas M?rz Amtsgericht Regensburg, HRB 7142 nic-hdl : SW1421-RIPE GPG-Key : 0x97F5A1D8 (0x8431335F97F5A1D8) GPG-Fingerprint : 6181 B041 3554 0B6F 4EF3 1B12 8431 335F 97F5 A1D8 From michael.dillon at bt.com Thu May 10 11:09:26 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 10 May 2007 10:09:26 +0100 Subject: Fwd: [address-policy-wg] 2007-02 New Policy Proposal (Change in IP Assignments for Anycasting DNS Policy) In-Reply-To: <20070510075004.GA6355@lain.intern.internetx.de> References: <20070425142233.GP73965@Space.Net> <462F694A.4060901@inex.ie> <20070425145205.GQ73965@Space.Net> <5FCDC1C5A3A941E7852005C718E619B5@tungemaskin> <20070425150837.GU73965@Space.Net> <616812070705090548r12ece1bar7c877f709249cefd@mail.gmail.com> <616812070705090611u7422e2ddj87731b031f2162ec@mail.gmail.com> <4641CE25.6040508@spaghetti.zurich.ibm.com> <4641D280.1020104@spaghetti.zurich.ibm.com> <20070510075004.GA6355@lain.intern.internetx.de> Message-ID: > > If you have 10.000 zones, I can also be tricked into seeing a justification. > I agree with Jeroen. We're having waaay more than 10.000 zones which > (currently) don't go over the 512 byte limit. > > On the contrary, if I wanted to get PI, what would stop me from taking > one zone, expand it's dns records up to 512+ byte and request the > space? Why should address policy be so tightly tied to the technical details of the DNS protocol and its implementation? Are you saying that IPv4 Anycast is only justified if the application is DNS hosting and the number of separate zones (presumably you count SOA records) goes over a certain limit? No other application is justified? Only the organization hosting the DNS is eligible, i.e. a data centre operator who wants to provide hosting services is not eligible? Every DNS hoster with over x zones gets their own /24 even though you could aggregate over 200 such organizations into one /24 if they shared data centre infrastructure? It seems to me that this approach to IPv4 Anycast prefixes only reinforces an existing monopoly and blocks organizations who might want to take a fresh approach to DNS hosting or other types of application hosting. --Michael Dillon From sw+ripe-apwg at internetx.de Thu May 10 11:45:06 2007 From: sw+ripe-apwg at internetx.de (Sebastian Wiesinger) Date: Thu, 10 May 2007 11:45:06 +0200 Subject: Fwd: [address-policy-wg] 2007-02 New Policy Proposal (Change in IP Assignments for Anycasting DNS Policy) In-Reply-To: References: <20070425145205.GQ73965@Space.Net> <5FCDC1C5A3A941E7852005C718E619B5@tungemaskin> <20070425150837.GU73965@Space.Net> <616812070705090548r12ece1bar7c877f709249cefd@mail.gmail.com> <616812070705090611u7422e2ddj87731b031f2162ec@mail.gmail.com> <4641CE25.6040508@spaghetti.zurich.ibm.com> <4641D280.1020104@spaghetti.zurich.ibm.com> <20070510075004.GA6355@lain.intern.internetx.de> Message-ID: <20070510094506.GA10986@lain.intern.internetx.de> * michael.dillon at bt.com [2007-05-10 11:09]: > > I agree with Jeroen. We're having waaay more than 10.000 zones which > > (currently) don't go over the 512 byte limit. > > > > On the contrary, if I wanted to get PI, what would stop me from taking > > one zone, expand it's dns records up to 512+ byte and request the > > space? > > Why should address policy be so tightly tied to the technical details of > the DNS protocol and its implementation? > > Are you saying that IPv4 Anycast is only justified if the application is > DNS hosting and the number of separate zones (presumably you count SOA > records) goes over a certain limit? > > No other application is justified? No, I don't say that. I'm not happy with these "numerical" requirements. But I'm *more* happy with the SOA count (in our case) then the 512 byte limit. > Only the organization hosting the DNS is eligible, i.e. a data centre > operator who wants to provide hosting services is not eligible? > > Every DNS hoster with over x zones gets their own /24 even though you > could aggregate over 200 such organizations into one /24 if they shared > data centre infrastructure? > > It seems to me that this approach to IPv4 Anycast prefixes only > reinforces an existing monopoly and blocks organizations who might want > to take a fresh approach to DNS hosting or other types of application > hosting. You definitely have a point here. I'm hoping that someone comes up with a better plan for the requirement(s), I'm still thinking about one. It's a lot of space to give away, and there has to be some sort of limitation. Sebastian -- InterNetX GmbH Maximilianstr. 6 93047 Regensburg Germany Tel. +49 941 59559-480 Fax +49 941 59579-051 Gesch?ftsf?hrer/CEO: Thomas M?rz Amtsgericht Regensburg, HRB 7142 nic-hdl : SW1421-RIPE GPG-Key : 0x97F5A1D8 (0x8431335F97F5A1D8) GPG-Fingerprint : 6181 B041 3554 0B6F 4EF3 1B12 8431 335F 97F5 A1D8 From tcremer at cw.net Thu May 10 12:54:35 2007 From: tcremer at cw.net (Tobias Cremer) Date: Thu, 10 May 2007 12:54:35 +0200 Subject: Fwd: [address-policy-wg] 2007-02 New Policy Proposal (Change in IP Assignments for Anycasting DNS Policy) In-Reply-To: References: <20070425142233.GP73965@Space.Net> <462F694A.4060901@inex.ie> <20070425145205.GQ73965@Space.Net> <5FCDC1C5A3A941E7852005C718E619B5@tungemaskin> <20070425150837.GU73965@Space.Net> <616812070705090548r12ece1bar7c877f709249cefd@mail.gmail.com> <616812070705090611u7422e2ddj87731b031f2162ec@mail.gmail.com> <4641CE25.6040508@spaghetti.zurich.ibm.com> <4641D280.1020104@spaghetti.zurich.ibm.com> <20070510075004.GA6355@lain.intern.internetx.de> Message-ID: <4642F9EB.5090908@cw.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Michael, On 10.05.2007 11:09, michael.dillon at bt.com wrote: > Why should address policy be so tightly tied to the technical details of > the DNS protocol and its implementation? > > Are you saying that IPv4 Anycast is only justified if the application is > DNS hosting and the number of separate zones (presumably you count SOA > records) goes over a certain limit? > > No other application is justified? The reason is that there has been the need of an Anycast Assignment by the DNS people, and when asking the community what other services using currently anycast noone stood up. So the policy was made in regards to the DNS. At least that's the story as far as I remember. Additionally, the policy would not have reached consensus if it would have been open to all anycasting services. > Only the organization hosting the DNS is eligible, i.e. a data centre > operator who wants to provide hosting services is not eligible? Not even with the existing policy. > Every DNS hoster with over x zones gets their own /24 even though you > could aggregate over 200 such organizations into one /24 if they shared > data centre infrastructure? > > It seems to me that this approach to IPv4 Anycast prefixes only > reinforces an existing monopoly and blocks organizations who might want > to take a fresh approach to DNS hosting or other types of application > hosting. As it was said here in the Address Policy WG session at the RIPE Meeting, for v4 this may become obsolete when the policy reaches consensus that set the PI assignment size to a /24 minimum generally. v6 then still remains as unsolved. Tobias - -- Tobias Cremer M.A. IP Admin Engineer Cable & Wireless Telecommunication Services GmbH Landsbergerstr. 155 80687 Muenchen Germany Tel +49 89 926 99 0 -- FAX +49 89 926 99 180 -- COMNET 7 49 9169 Gesch?ftsf?hrer Francois Goreux, Richard Pennal Amtsgericht M?nchen HRB 146 617 www.cw.com/de - -- Every message GnuPG signed -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGQvnrhC6y11CNwvcRArtXAJ43WNgEuPWuJjp8mbz5EW/wrRuBFwCg4T/n U4zgdj7J5YNbKs+t4V9Ztsg= =Ck2T -----END PGP SIGNATURE----- From tcremer at cw.net Thu May 10 13:08:42 2007 From: tcremer at cw.net (Tobias Cremer) Date: Thu, 10 May 2007 13:08:42 +0200 Subject: Fwd: [address-policy-wg] 2007-02 New Policy Proposal (Change in IP Assignments for Anycasting DNS Policy) In-Reply-To: <20070510075004.GA6355@lain.intern.internetx.de> References: <20070425142233.GP73965@Space.Net> <462F694A.4060901@inex.ie> <20070425145205.GQ73965@Space.Net> <5FCDC1C5A3A941E7852005C718E619B5@tungemaskin> <20070425150837.GU73965@Space.Net> <616812070705090548r12ece1bar7c877f709249cefd@mail.gmail.com> <616812070705090611u7422e2ddj87731b031f2162ec@mail.gmail.com> <4641CE25.6040508@spaghetti.zurich.ibm.com> <4641D280.1020104@spaghetti.zurich.ibm.com> <20070510075004.GA6355@lain.intern.internetx.de> Message-ID: <4642FD3A.1090908@cw.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10.05.2007 09:50, Sebastian Wiesinger wrote: > I'm more in favor for a "number of zones" limit. I disagree here, as the number of zones a) is again a number - but which one? How can we decide how many zones you need to serve. And what if someone has x-1 zones? He won't be eligible for an anycasting assignment, even if he serves e.g. 9999 zones. b) is generally no criteria for being eligible for an anycasting assignment in my opinion. If it would be, it would mean "I'm more important because I have more zones, and thus may do anycast". Tobias - -- Tobias Cremer M.A. IP Admin Engineer Cable & Wireless Telecommunication Services GmbH Landsbergerstr. 155 80687 Muenchen Germany Tel +49 89 926 99 0 -- FAX +49 89 926 99 180 -- COMNET 7 49 9169 Gesch?ftsf?hrer Francois Goreux, Richard Pennal Amtsgericht M?nchen HRB 146 617 www.cw.com/de - -- Every message GnuPG signed -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGQv06hC6y11CNwvcRAhOaAJ4xj225RJp3RsmtaCl88/3CbBblmgCgpR1K HfAtaCA3aWTgJB4T9UnD3ig= =OyVX -----END PGP SIGNATURE----- From michael.dillon at bt.com Thu May 10 13:25:03 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 10 May 2007 12:25:03 +0100 Subject: Fwd: [address-policy-wg] 2007-02 New Policy Proposal (Change in IP Assignments for Anycasting DNS Policy) In-Reply-To: <20070510094506.GA10986@lain.intern.internetx.de> References: <20070425145205.GQ73965@Space.Net> <5FCDC1C5A3A941E7852005C718E619B5@tungemaskin> <20070425150837.GU73965@Space.Net> <616812070705090548r12ece1bar7c877f709249cefd@mail.gmail.com> <616812070705090611u7422e2ddj87731b031f2162ec@mail.gmail.com> <4641CE25.6040508@spaghetti.zurich.ibm.com> <4641D280.1020104@spaghetti.zurich.ibm.com> <20070510075004.GA6355@lain.intern.internetx.de> <20070510094506.GA10986@lain.intern.internetx.de> Message-ID: > No, I don't say that. I'm not happy with these "numerical" > requirements. But I'm *more* happy with the SOA count (in our case) > then the 512 byte limit. It is hard to do this kind of policy without numerical requirements. But we need to agree on what will be counted before deciding on the numbers. As you say, it seems bad to count bytes per DNS packet. Counting SOA records seems more reasonable but is still DNS specific and can be spoofed easily. However, counting data centre locations is harder to spoof and is more in line with IP addressing policy. We already allow physical locations as a justification for a subnet. Normally, we also count hosts within the location, but for IPv4 Anycast, multiple hosts hide behind a single IP address so host counting is problematic. Currently, the IPv4 Anycast policy seems to accept 99.6% wasted address space as OK. I am suggesting that the policy should try to reduce that waste, by offering a /24 to organizations which provide Anycast hosting services. Since you can't legitimately offer such a service without having some minimum number of data centre locations, then the policy could specify a minimum number. And if you gain more than 250 or so customers and need another /24 then that should be easy to get. People who want to anycast their DNS, then have the option to set up a generic anycast hosting service, or contract with a service provider who offers such a hosting service. And people who want to anycast something else, like map data or satellite photos, or financial data, can also use IPv4 anycast without chasing the RIR to change policies or pretending to be a DNS hosting service. And people won't complain that RIPE is anti-competitive. Technically, it seems to me that any hosting application which sends out predictable replies to queries from a static database could potentially benefit from anycasting. In any case, RIPE shouldn't tell people what to do, just make it possible for people to do things. --Michael Dillon From jorgen at hovland.cx Thu May 10 13:28:02 2007 From: jorgen at hovland.cx (=?UTF-8?Q?J=C3=B8rgen_Hovland?=) Date: Thu, 10 May 2007 13:28:02 +0200 Subject: Fwd: [address-policy-wg] 2007-02 New Policy Proposal (Change in IP Assignments for Anycasting DNS Policy) In-Reply-To: <4642F9EB.5090908@cw.net> References: <20070425142233.GP73965@Space.Net> <462F694A.4060901@inex.ie> <20070425145205.GQ73965@Space.Net> <5FCDC1C5A3A941E7852005C718E619B5@tungemaskin> <20070425150837.GU73965@Space.Net> <616812070705090548r12ece1bar7c877f709249cefd@mail.gmail.com> <616812070705090611u7422e2ddj87731b031f2162ec@mail.gmail.com> <4641CE25.6040508@spaghetti.zurich.ibm.com> <4641D280.1020104@spaghetti.zurich.ibm.com> <20070510075004.GA6355@lain.intern.internetx.de> <4642F9EB.5090908@cw.net> Message-ID: <9E5B4F5391BB486AAA63721D3F29268B@tungemaskin> -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Tobias Cremer Hi, >> Only the organization hosting the DNS is eligible, i.e. a data centre >> operator who wants to provide hosting services is not eligible? > > Not even with the existing policy. This depends on the definition. If a network announce their /16 prefix world-wide and decide to assign a customer a /29 for the use of anycast, they are entirely free to do so. The internal routing for the /29 within this network obviously needs to be configured for anycast use directed to the closest of the 15 different datacenters. The /29 is of course not announced to dfz, only the aggregate /16 is. Is the problem with this method perhaps that DNS operators don't seem to operate a real network and they are not willing to let the network operator to it for them? Or is the network operator unwilling to do it? Or is it just a bad plan? J From jeroen at unfix.org Thu May 10 14:18:32 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 10 May 2007 13:18:32 +0100 Subject: Fwd: [address-policy-wg] 2007-02 New Policy Proposal (Change in IP Assignments for Anycasting DNS Policy) In-Reply-To: References: <20070425145205.GQ73965@Space.Net> <5FCDC1C5A3A941E7852005C718E619B5@tungemaskin> <20070425150837.GU73965@Space.Net> <616812070705090548r12ece1bar7c877f709249cefd@mail.gmail.com> <616812070705090611u7422e2ddj87731b031f2162ec@mail.gmail.com> <4641CE25.6040508@spaghetti.zurich.ibm.com> <4641D280.1020104@spaghetti.zurich.ibm.com> <20070510075004.GA6355@lain.intern.internetx.de> <20070510094506.GA10986@lain.intern.internetx.de> Message-ID: <46430D98.3000209@spaghetti.zurich.ibm.com> michael.dillon at bt.com wrote: [..] > Currently, the IPv4 Anycast policy seems to accept 99.6% wasted address > space as OK. I am suggesting that the policy should try to reduce that > waste, by offering a /24 to organizations which provide Anycast hosting > services. Since you can't legitimately offer such a service without > having some minimum number of data centre locations, then the policy > could specify a minimum number. And if you gain more than 250 or so > customers and need another /24 then that should be easy to get. This sounds VERY acceptable to me, and IMHO this should definitely be incorporated into this new policy. This is the real justification that can be very easily verified by RIPE NCC to see if the requester really has a need for this address space. It can then indeed also be applied for other services that benefit from an anycast construct. Also, for the DB WG, should there maybe be a special way of notating anycast prefixes in the route/route6 object!? This way, when one does a whois it will pop up showing that the prefix is anycasted, and possibly from where, when documented. This allows for better debugging, otherwise you customer might be reporting "issues to reach X or Y", while it actually is going somewhere completely different for you. Of course traceroute is always a help there too, but how many customers know how to use that ;) Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From sw+ripe-apwg at internetx.de Thu May 10 14:24:13 2007 From: sw+ripe-apwg at internetx.de (Sebastian Wiesinger) Date: Thu, 10 May 2007 14:24:13 +0200 Subject: Fwd: [address-policy-wg] 2007-02 New Policy Proposal (Change in IP Assignments for Anycasting DNS Policy) In-Reply-To: <4642FD3A.1090908@cw.net> References: <20070425145205.GQ73965@Space.Net> <5FCDC1C5A3A941E7852005C718E619B5@tungemaskin> <20070425150837.GU73965@Space.Net> <616812070705090548r12ece1bar7c877f709249cefd@mail.gmail.com> <616812070705090611u7422e2ddj87731b031f2162ec@mail.gmail.com> <4641CE25.6040508@spaghetti.zurich.ibm.com> <4641D280.1020104@spaghetti.zurich.ibm.com> <20070510075004.GA6355@lain.intern.internetx.de> <4642FD3A.1090908@cw.net> Message-ID: <20070510122413.GA18979@lain.intern.internetx.de> * Tobias Cremer [2007-05-10 13:10]: > On 10.05.2007 09:50, Sebastian Wiesinger wrote: > > I'm more in favor for a "number of zones" limit. > > I disagree here, as the number of zones > > a) is again a number - but which one? How can we decide how many zones > you need to serve. And what if someone has x-1 zones? He won't be > eligible for an anycasting assignment, even if he serves e.g. 9999 zones. > > b) is generally no criteria for being eligible for an anycasting > assignment in my opinion. If it would be, it would mean "I'm more > important because I have more zones, and thus may do anycast". Yes, you're right. The same problem exists with the 512 byte limit. There are valid reasons for anycast without meeting these criteria. (And in my opinion they are even more important then number of zones/bytes). Michael Dillon suggests to use physical locations as a criteria. Perhaps we should go in that direction? Something like: You're providing a service which will benefit from anycast AND you have x? physical locations where you will deploy these services (Regardless of who "owns" the location). ?(x locations could be "multiple" or a number?) Regards, Sebastian -- InterNetX GmbH Maximilianstr. 6 93047 Regensburg Germany Tel. +49 941 59559-480 Fax +49 941 59579-051 Gesch?ftsf?hrer/CEO: Thomas M?rz Amtsgericht Regensburg, HRB 7142 nic-hdl : SW1421-RIPE GPG-Key : 0x97F5A1D8 (0x8431335F97F5A1D8) GPG-Fingerprint : 6181 B041 3554 0B6F 4EF3 1B12 8431 335F 97F5 A1D8 From tcremer at cw.net Thu May 10 14:41:23 2007 From: tcremer at cw.net (Tobias Cremer) Date: Thu, 10 May 2007 14:41:23 +0200 Subject: Fwd: [address-policy-wg] 2007-02 New Policy Proposal (Change in IP Assignments for Anycasting DNS Policy) In-Reply-To: <9E5B4F5391BB486AAA63721D3F29268B@tungemaskin> References: <20070425142233.GP73965@Space.Net> <462F694A.4060901@inex.ie> <20070425145205.GQ73965@Space.Net> <5FCDC1C5A3A941E7852005C718E619B5@tungemaskin> <20070425150837.GU73965@Space.Net> <616812070705090548r12ece1bar7c877f709249cefd@mail.gmail.com> <616812070705090611u7422e2ddj87731b031f2162ec@mail.gmail.com> <4641CE25.6040508@spaghetti.zurich.ibm.com> <4641D280.1020104@spaghetti.zurich.ibm.com> <20070510075004.GA6355@lain.intern.internetx.de> <4642F9EB.5090908@cw.net> <9E5B4F5391BB486AAA63721D3F29268B@tungemaskin> Message-ID: <464312F3.5040509@cw.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10.05.2007 13:28, J?rgen Hovland wrote: >>> Only the organization hosting the DNS is eligible, i.e. a data centre >>> operator who wants to provide hosting services is not eligible? >> >> Not even with the existing policy. > > This depends on the definition. If a network announce their /16 > prefix world-wide and decide to assign a customer a /29 for the use > of anycast, they are entirely free to do so. The internal routing for > the /29 within this network obviously needs to be configured for > anycast use directed to the closest of the 15 different datacenters. > The /29 is of course not announced to dfz, only the aggregate /16 is. Well, I was perhaps not precise enough. The existing DNS Anycasting Assignment policy is for dedicated Anycast assignments only for DNS Anycasting setups. Of course that doesn't mean that you can't anycasting others service, e.g. as you described above, but you cannot receive an own assignment for that. Tobias - -- Tobias Cremer M.A. IP Admin Engineer Cable & Wireless Telecommunication Services GmbH Landsbergerstr. 155 80687 Muenchen Germany Tel +49 89 926 99 0 -- FAX +49 89 926 99 180 -- COMNET 7 49 9169 Gesch?ftsf?hrer Francois Goreux, Richard Pennal Amtsgericht M?nchen HRB 146 617 www.cw.com/de - -- Every message GnuPG signed -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGQxLyhC6y11CNwvcRAvCBAKCe1RZOdXFQPNGWAcWoiRlvOwrIHQCggqhE 5YCfUk3pqZoMJcfwd30KeUM= =+MuI -----END PGP SIGNATURE----- From Woeber at CC.UniVie.ac.at Thu May 10 15:13:06 2007 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 10 May 2007 13:13:06 +0000 Subject: Fwd: [address-policy-wg] 2007-02 New Policy Proposal (Change in IP Assignments for Anycasting DNS Policy) In-Reply-To: <46430D98.3000209@spaghetti.zurich.ibm.com> References: <20070425145205.GQ73965@Space.Net> <5FCDC1C5A3A941E7852005C718E619B5@tungemaskin> <20070425150837.GU73965@Space.Net> <616812070705090548r12ece1bar7c877f709249cefd@mail.gmail.com> <616812070705090611u7422e2ddj87731b031f2162ec@mail.gmail.com> <4641CE25.6040508@spaghetti.zurich.ibm.com> <4641D280.1020104@spaghetti.zurich.ibm.com> <20070510075004.GA6355@lain.intern.internetx.de> <20070510094506.GA10986@lain.intern.internetx.de> <46430D98.3000209@spaghetti.zurich.ibm.com> Message-ID: <46431A62.3080202@CC.UniVie.ac.at> Jeroen Massar wrote: > michael.dillon at bt.com wrote: > [..] > >>Currently, the IPv4 Anycast policy seems to accept 99.6% wasted address >>space as OK. I am suggesting that the policy should try to reduce that >>waste, by offering a /24 to organizations which provide Anycast hosting >>services. Since you can't legitimately offer such a service without >>having some minimum number of data centre locations, then the policy >>could specify a minimum number. And if you gain more than 250 or so >>customers and need another /24 then that should be easy to get. > > > This sounds VERY acceptable to me, and IMHO this should definitely be > incorporated into this new policy. This is the real justification that > can be very easily verified by RIPE NCC to see if the requester really > has a need for this address space. It can then indeed also be applied > for other services that benefit from an anycast construct. > > Also, for the DB WG, should there maybe be a special way of notating > anycast prefixes in the route/route6 object!? Is the status: attribute the appropriate place or mechanism for this? Anycasting is more like a special routing setup, imho, so (just from a debugging point of view) the Routing Registry might be more appropriate? > This way, when one does a > whois it will pop up showing that the prefix is anycasted, and possibly > from where, when documented. This allows for better debugging, otherwise > you customer might be reporting "issues to reach X or Y", while it > actually is going somewhere completely different for you. Of course > traceroute is always a help there too, but how many customers know how > to use that ;) > > Greets, > Jeroen Wilfried. From jgutauer at cw.net Thu May 10 15:01:00 2007 From: jgutauer at cw.net (Johann Gutauer) Date: Thu, 10 May 2007 15:01:00 +0200 Subject: Fwd: [address-policy-wg] 2007-02 New Policy Proposal (Change in IP Assignments for Anycasting DNS Policy) In-Reply-To: <20070510094506.GA10986@lain.intern.internetx.de> References: <20070425145205.GQ73965@Space.Net> <5FCDC1C5A3A941E7852005C718E619B5@tungemaskin> <20070425150837.GU73965@Space.Net> <616812070705090548r12ece1bar7c877f709249cefd@mail.gmail.com> <616812070705090611u7422e2ddj87731b031f2162ec@mail.gmail.com> <4641CE25.6040508@spaghetti.zurich.ibm.com> <4641D280.1020104@spaghetti.zurich.ibm.com> <20070510075004.GA6355@lain.intern.internetx.de> <20070510094506.GA10986@lain.intern.internetx.de> Message-ID: <4643178C.4080700@cw.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sebastian Wiesinger wrote: > * michael.dillon at bt.com [2007-05-10 11:09]: [...] >> >> No other application is justified? > > No, I don't say that. I'm not happy with these "numerical" > requirements. But I'm *more* happy with the SOA count (in our case) > then the 512 byte limit. Everyone can create as many SOA-records as necessary. I don't think that this is a good idea to count the number of hosted domains. I've even seen customers which generate a subdomain for each A-record. The 512 byte limit is hard to prove but it's for protocol reasons. Nevertheless, does it still make sense? > > > Sebastian > Johann - -- Johann Gutauer, jgutauer at cw.net Sen. Netw. Engineer DNS Cable&Wireless Telecommunication Services GmbH Landsberger Str.155 D-80687 M?nchen Deutschland Gesch?ftsf?hrer Francois Goreux, Richard Pennal Amtsgericht M?nchen HRB 146 617 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGQxeMQ7r8ZjAASRARArPqAJ9f/FUAwNFA1fg+lm5U5c7P3tkXuQCfdgSN V4SXua4nc8c2WPrgVtVvYPc= =D+uF -----END PGP SIGNATURE----- From sw+ripe-apwg at internetx.de Thu May 10 16:48:31 2007 From: sw+ripe-apwg at internetx.de (Sebastian Wiesinger) Date: Thu, 10 May 2007 16:48:31 +0200 Subject: Fwd: [address-policy-wg] 2007-02 New Policy Proposal (Change in IP Assignments for Anycasting DNS Policy) In-Reply-To: <4643178C.4080700@cw.net> References: <20070425150837.GU73965@Space.Net> <616812070705090548r12ece1bar7c877f709249cefd@mail.gmail.com> <616812070705090611u7422e2ddj87731b031f2162ec@mail.gmail.com> <4641CE25.6040508@spaghetti.zurich.ibm.com> <4641D280.1020104@spaghetti.zurich.ibm.com> <20070510075004.GA6355@lain.intern.internetx.de> <20070510094506.GA10986@lain.intern.internetx.de> <4643178C.4080700@cw.net> Message-ID: <20070510144831.GA24643@lain.intern.internetx.de> * Johann Gutauer [2007-05-10 15:30]: > > No, I don't say that. I'm not happy with these "numerical" > > requirements. But I'm *more* happy with the SOA count (in our case) > > then the 512 byte limit. > > Everyone can create as many SOA-records as necessary. I don't think that this is a good idea to > count the number of hosted domains. I've even seen customers which generate a subdomain for each > A-record. You would have to restrict that to 1st-level domains to be effective, but there would surely be cases where this would exclude people who have a valid reason for anycast. At the moment the "physical location" requirement seems to be the one which covers most of the valid anycast setups, if I'm not mistaken? > The 512 byte limit is hard to prove but it's for protocol reasons. > Nevertheless, does it still make sense? I don't think it still makes sense. It doesn't cover for example (D)DoS, which is something you can fend of with anycast. Regards, Sebastian -- InterNetX GmbH Maximilianstr. 6 93047 Regensburg Germany Tel. +49 941 59559-480 Fax +49 941 59579-051 Gesch?ftsf?hrer/CEO: Thomas M?rz Amtsgericht Regensburg, HRB 7142 nic-hdl : SW1421-RIPE GPG-Key : 0x97F5A1D8 (0x8431335F97F5A1D8) GPG-Fingerprint : 6181 B041 3554 0B6F 4EF3 1B12 8431 335F 97F5 A1D8 From alh-ietf at tndh.net Fri May 11 06:01:02 2007 From: alh-ietf at tndh.net (Tony Hain) Date: Fri, 11 May 2007 07:01:02 +0300 Subject: [address-policy-wg] RE: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <97549.1178823530@sa.vix.com> References: <97549.1178823530@sa.vix.com> Message-ID: <013401c79381$003efa20$00bcee60$@net> I agree that this will help inform the debate, and while Iljitsch did a good job of outlining the issue, he left out a significant point::: People explicitly chose to be in the state of "as there is currently no obvious way to make services only available locally" by insisting that the local-scope addressing range have a global-scope as far as application developers were concerned. Now the application developers are complaining about the consequences of their choice, because the alternative to 'no routing path for an attack' is to insert a device that has to make policy decisions with limited information. The current ULA-central discussions will be directly involved in this issue. It is critical that all of the RIR's have policies establishing a mechanism for registering ULA-central prefixes & PI. For those who don't recall, the reason ULA-central was tabled was that it was seen as a potential end-run to acquire PI space in the absence of appropriate policy to do so out of a range recognized for global routing. The need for keeping some things local while others are global is real, and the lack of appropriate mechanisms to accomplish that through the routing system that is designed to deal with path selection leads to entire industries for fragile work-arounds along with their increased complexity. Tony > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > vixie at vix.com > Sent: Thursday, May 10, 2007 9:59 PM > To: ppml at arin.net > Subject: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica > (seen on slashdot) > > i think that this article will help inform the debate around the ipv6 > transition: > > http://arstechnica.com/articles/paedia/ipv6-firewall-mixed-blessing.ars > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml From michael.dillon at bt.com Fri May 11 09:28:54 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 11 May 2007 08:28:54 +0100 Subject: [address-policy-wg] RE: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: References: <97549.1178823530@sa.vix.com> <013401c79381$003efa20$00bcee60$@net> Message-ID: > I don't understand your point about why ULA need to be registered if > its not going to be globally routed. Also PI is not the same as ULA - > PI do come from RIRs and in IPv6 there was no way to get PI (except > in a few special cases) until recent ARIN's micro-allocation policy. ULA addresses *WILL* be globally routed on an IPv6 internetwork. It just won't be the IP internetwork known as the Internet. Remember, IP addresses are not for use on the Internet, they are for use on IP networks. --Michael Dillon From michael.dillon at bt.com Fri May 11 09:41:10 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 11 May 2007 08:41:10 +0100 Subject: [address-policy-wg] RE: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica(seen on slashdot) In-Reply-To: References: <97549.1178823530@sa.vix.com> <013401c79381$003efa20$00bcee60$@net> Message-ID: > The problem I have with this theory is that the delta between a > collection > of networks routing by mutual agreement and the internet is: > > A. Fuzzy > B. Non-Existant > C. There is no difference > D. Meaningless > E. Any and/or All of the above > > Pick your favorite answer from the above and you've pretty much got it. Perhaps it is time for the RIRs to develop clear definitions for the Internet and IP internetworks so that the delta between them is clear. > However, in it's current state of "license for > anyone who > wants to run a competing RIR for networks that choose to interoperate > on this basis" I think it's a pretty bad idea. The RIR process is the way that the organizations sharing IP number resources reach agreement on who gets what. These organizations have to work together outside of the RIRs to reach agreement on who connects to what and who routes what. If a group of organizations outside the RIR can reach agreement on global internetwork connectivity between them, but separate from the Internet, and if the IP number resource pool is big enough to let these organizations manage their own addressing requirements on that internetwork, then why should the RIRs be upset. Among the many IP networks operated by my company there is a global IPv4 internetwork that is completely separate from the Internet. It has thousands of companies connected to it and, naturally, it uses registered IPv4 addresses. It's not the only such global network. We run one for the financial services industry. There is also such a network for the auto-manufacturing industry, and for the airline industry. And there are probably others as well. --Michael Dillon From william at elan.net Fri May 11 09:03:08 2007 From: william at elan.net (william(at)elan.net) Date: Fri, 11 May 2007 00:03:08 -0700 (PDT) Subject: [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <013401c79381$003efa20$00bcee60$@net> References: <97549.1178823530@sa.vix.com> <013401c79381$003efa20$00bcee60$@net> Message-ID: I don't understand your point about why ULA need to be registered if its not going to be globally routed. Also PI is not the same as ULA - PI do come from RIRs and in IPv6 there was no way to get PI (except in a few special cases) until recent ARIN's micro-allocation policy. On Fri, 11 May 2007, Tony Hain wrote: > I agree that this will help inform the debate, and while Iljitsch did a good > job of outlining the issue, he left out a significant point::: > People explicitly chose to be in the state of "as there is currently no > obvious way to make services only available locally" by insisting that the > local-scope addressing range have a global-scope as far as application > developers were concerned. Now the application developers are complaining > about the consequences of their choice, because the alternative to 'no > routing path for an attack' is to insert a device that has to make policy > decisions with limited information. > > The current ULA-central discussions will be directly involved in this issue. > It is critical that all of the RIR's have policies establishing a mechanism > for registering ULA-central prefixes & PI. For those who don't recall, the > reason ULA-central was tabled was that it was seen as a potential end-run to > acquire PI space in the absence of appropriate policy to do so out of a > range recognized for global routing. > > The need for keeping some things local while others are global is real, and > the lack of appropriate mechanisms to accomplish that through the routing > system that is designed to deal with path selection leads to entire > industries for fragile work-arounds along with their increased complexity. > > Tony > > >> -----Original Message----- >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of >> vixie at vix.com >> Sent: Thursday, May 10, 2007 9:59 PM >> To: ppml at arin.net >> Subject: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica >> (seen on slashdot) >> >> i think that this article will help inform the debate around the ipv6 >> transition: >> >> http://arstechnica.com/articles/paedia/ipv6-firewall-mixed-blessing.ars >> _______________________________________________ >> This message sent to you through the ARIN Public Policy Mailing List >> (PPML at arin.net). >> Manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/ppml > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml From owen at delong.com Fri May 11 08:12:21 2007 From: owen at delong.com (Owen DeLong) Date: Thu, 10 May 2007 23:12:21 -0700 Subject: [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: References: <97549.1178823530@sa.vix.com> <013401c79381$003efa20$00bcee60$@net> Message-ID: ULA Central is intended so that some subset of the internet can reliably use it to interconnect while not being "globally" routed. The problem I have with this theory is that the delta between a collection of networks routing by mutual agreement and the internet is: A. Fuzzy B. Non-Existant C. There is no difference D. Meaningless E. Any and/or All of the above Pick your favorite answer from the above and you've pretty much got it. If ULA central were limited to not exiting the local AS (in some meaningful way, like routers won't forward routes or traffic to ULA addresses to external adjacencies), then, I might see it as something other than an end-run on the RIR process. However, in it's current state of "license for anyone who wants to run a competing RIR for networks that choose to interoperate on this basis" I think it's a pretty bad idea. Owen On May 11, 2007, at 12:03 AM, william(at)elan.net wrote: > > I don't understand your point about why ULA need to be registered if > its not going to be globally routed. Also PI is not the same as ULA - > PI do come from RIRs and in IPv6 there was no way to get PI (except > in a few special cases) until recent ARIN's micro-allocation policy. > > On Fri, 11 May 2007, Tony Hain wrote: > >> I agree that this will help inform the debate, and while Iljitsch >> did a good >> job of outlining the issue, he left out a significant point::: >> People explicitly chose to be in the state of "as there is >> currently no >> obvious way to make services only available locally" by insisting >> that the >> local-scope addressing range have a global-scope as far as >> application >> developers were concerned. Now the application developers are >> complaining >> about the consequences of their choice, because the alternative to >> 'no >> routing path for an attack' is to insert a device that has to make >> policy >> decisions with limited information. >> >> The current ULA-central discussions will be directly involved in >> this issue. >> It is critical that all of the RIR's have policies establishing a >> mechanism >> for registering ULA-central prefixes & PI. For those who don't >> recall, the >> reason ULA-central was tabled was that it was seen as a potential >> end-run to >> acquire PI space in the absence of appropriate policy to do so out >> of a >> range recognized for global routing. >> >> The need for keeping some things local while others are global is >> real, and >> the lack of appropriate mechanisms to accomplish that through the >> routing >> system that is designed to deal with path selection leads to entire >> industries for fragile work-arounds along with their increased >> complexity. >> >> Tony >> >> >>> -----Original Message----- >>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On >>> Behalf Of >>> vixie at vix.com >>> Sent: Thursday, May 10, 2007 9:59 PM >>> To: ppml at arin.net >>> Subject: [ppml] article about IPv6 vs firewalls vs NAT in >>> arstechnica >>> (seen on slashdot) >>> >>> i think that this article will help inform the debate around the >>> ipv6 >>> transition: >>> >>> http://arstechnica.com/articles/paedia/ipv6-firewall-mixed- >>> blessing.ars >>> _______________________________________________ >>> This message sent to you through the ARIN Public Policy Mailing List >>> (PPML at arin.net). >>> Manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/ppml >> >> _______________________________________________ >> This message sent to you through the ARIN Public Policy Mailing List >> (PPML at arin.net). >> Manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/ppml > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From jordi.palet at consulintel.es Fri May 11 10:37:36 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 11 May 2007 11:37:36 +0300 Subject: [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: Message-ID: Even if not globally routed, you may want to avoid a possible clash with another organization, for example in case of a merge. ULA-central is NOT intended to be uses as IPv6 PI. IPv6 PI is available already in ARIN, APNIC and AfriNIC. Ongoing policy proposals in both RIPE NCC and LACNIC. Regards, Jordi (I'm the the one that submitted the ULA-central policy proposal to all the regions, ARIN coming next) > De: "william(at)elan.net" > Responder a: > Fecha: Fri, 11 May 2007 00:03:08 -0700 (PDT) > Para: Tony Hain > CC: , , "address-policy-wg at ripe.net" > > Asunto: Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen > on slashdot) > > > I don't understand your point about why ULA need to be registered if > its not going to be globally routed. Also PI is not the same as ULA - > PI do come from RIRs and in IPv6 there was no way to get PI (except > in a few special cases) until recent ARIN's micro-allocation policy. > > On Fri, 11 May 2007, Tony Hain wrote: > >> I agree that this will help inform the debate, and while Iljitsch did a good >> job of outlining the issue, he left out a significant point::: >> People explicitly chose to be in the state of "as there is currently no >> obvious way to make services only available locally" by insisting that the >> local-scope addressing range have a global-scope as far as application >> developers were concerned. Now the application developers are complaining >> about the consequences of their choice, because the alternative to 'no >> routing path for an attack' is to insert a device that has to make policy >> decisions with limited information. >> >> The current ULA-central discussions will be directly involved in this issue. >> It is critical that all of the RIR's have policies establishing a mechanism >> for registering ULA-central prefixes & PI. For those who don't recall, the >> reason ULA-central was tabled was that it was seen as a potential end-run to >> acquire PI space in the absence of appropriate policy to do so out of a >> range recognized for global routing. >> >> The need for keeping some things local while others are global is real, and >> the lack of appropriate mechanisms to accomplish that through the routing >> system that is designed to deal with path selection leads to entire >> industries for fragile work-arounds along with their increased complexity. >> >> Tony >> >> >>> -----Original Message----- >>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of >>> vixie at vix.com >>> Sent: Thursday, May 10, 2007 9:59 PM >>> To: ppml at arin.net >>> Subject: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica >>> (seen on slashdot) >>> >>> i think that this article will help inform the debate around the ipv6 >>> transition: >>> >>> http://arstechnica.com/articles/paedia/ipv6-firewall-mixed-blessing.ars >>> _______________________________________________ >>> This message sent to you through the ARIN Public Policy Mailing List >>> (PPML at arin.net). >>> Manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/ppml >> >> _______________________________________________ >> This message sent to you through the ARIN Public Policy Mailing List >> (PPML at arin.net). >> Manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/ppml > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From jordi.palet at consulintel.es Fri May 11 10:54:10 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 11 May 2007 11:54:10 +0300 Subject: [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: Message-ID: If we want to avoid other entities acting as a central registry for ULA-central, then it is clear that the RIRs should do that, and for that, the only way is thru a policy. Regards, Jordi > De: Owen DeLong > Responder a: > Fecha: Thu, 10 May 2007 23:12:21 -0700 > Para: "william(at)elan.net" > CC: Tony Hain , , , > "address-policy-wg at ripe.net" > Asunto: [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT > in arstechnica (seen on slashdot) > > ULA Central is intended so that some subset of the internet can reliably > use it to interconnect while not being "globally" routed. > > The problem I have with this theory is that the delta between a > collection > of networks routing by mutual agreement and the internet is: > > A. Fuzzy > B. Non-Existant > C. There is no difference > D. Meaningless > E. Any and/or All of the above > > Pick your favorite answer from the above and you've pretty much got it. > If ULA central were limited to not exiting the local AS (in some > meaningful > way, like routers won't forward routes or traffic to ULA addresses to > external > adjacencies), then, I might see it as something other than an end-run on > the RIR process. However, in it's current state of "license for > anyone who > wants to run a competing RIR for networks that choose to interoperate > on this basis" I think it's a pretty bad idea. > > Owen > > > On May 11, 2007, at 12:03 AM, william(at)elan.net wrote: > >> >> I don't understand your point about why ULA need to be registered if >> its not going to be globally routed. Also PI is not the same as ULA - >> PI do come from RIRs and in IPv6 there was no way to get PI (except >> in a few special cases) until recent ARIN's micro-allocation policy. >> >> On Fri, 11 May 2007, Tony Hain wrote: >> >>> I agree that this will help inform the debate, and while Iljitsch >>> did a good >>> job of outlining the issue, he left out a significant point::: >>> People explicitly chose to be in the state of "as there is >>> currently no >>> obvious way to make services only available locally" by insisting >>> that the >>> local-scope addressing range have a global-scope as far as >>> application >>> developers were concerned. Now the application developers are >>> complaining >>> about the consequences of their choice, because the alternative to >>> 'no >>> routing path for an attack' is to insert a device that has to make >>> policy >>> decisions with limited information. >>> >>> The current ULA-central discussions will be directly involved in >>> this issue. >>> It is critical that all of the RIR's have policies establishing a >>> mechanism >>> for registering ULA-central prefixes & PI. For those who don't >>> recall, the >>> reason ULA-central was tabled was that it was seen as a potential >>> end-run to >>> acquire PI space in the absence of appropriate policy to do so out >>> of a >>> range recognized for global routing. >>> >>> The need for keeping some things local while others are global is >>> real, and >>> the lack of appropriate mechanisms to accomplish that through the >>> routing >>> system that is designed to deal with path selection leads to entire >>> industries for fragile work-arounds along with their increased >>> complexity. >>> >>> Tony >>> >>> >>>> -----Original Message----- >>>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On >>>> Behalf Of >>>> vixie at vix.com >>>> Sent: Thursday, May 10, 2007 9:59 PM >>>> To: ppml at arin.net >>>> Subject: [ppml] article about IPv6 vs firewalls vs NAT in >>>> arstechnica >>>> (seen on slashdot) >>>> >>>> i think that this article will help inform the debate around the >>>> ipv6 >>>> transition: >>>> >>>> http://arstechnica.com/articles/paedia/ipv6-firewall-mixed- >>>> blessing.ars >>>> _______________________________________________ >>>> This message sent to you through the ARIN Public Policy Mailing List >>>> (PPML at arin.net). >>>> Manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/ppml >>> >>> _______________________________________________ >>> This message sent to you through the ARIN Public Policy Mailing List >>> (PPML at arin.net). >>> Manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/ppml >> _______________________________________________ >> This message sent to you through the ARIN Public Policy Mailing List >> (PPML at arin.net). >> Manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/ppml > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From alh-ietf at tndh.net Fri May 11 14:06:02 2007 From: alh-ietf at tndh.net (Tony Hain) Date: Fri, 11 May 2007 14:06:02 +0200 Subject: [address-policy-wg] RE: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: References: <97549.1178823530@sa.vix.com> <013401c79381$003efa20$00bcee60$@net> Message-ID: <017601c793c4$c67c5aa0$53750fe0$@net> It is time to be blunt. The BS about being an end-run on PI is a tacit acknowledgement that people demand the utility of PI and will do whatever it takes to work around attempts to thwart them. The only reason ULA & PI are related is that there is no global acknowledgement that PI is necessary and will exist despite short-sighted attempts to squelch it. Also, just because someone else has a different deployment model off to the side that you don't see doesn't make it wrong. Enterprise networks need to keep private interconnect routing sorted out from their public side routing, and while complex IGP entries and ACLs will do the job, a simpler approach is to use the routing system for the job it was designed to do and use a local prefix for the non-global interconnect. PI does not solve the locality problem, so ULA is needed as well. For those organizations that don't want to consider even the remotest possibility that there will be an address collision with a future merger/acquisition/partner (having been burned on 1918), ULA-central makes more sense than ULA-local. Every PI block should automatically come with a ULA-central block. One could even argue that every RIR member should automatically receive a ULA-central block. Use is up to them. It has no ongoing cost so it would be cheaper to just set one up while doing the requested service than to have to come back and add it later. There is no shortage here. The RIR membership should really get past their preferred religion and start thinking long term revenue here. ULA-central doesn't cost anything substantial, yet provides a reason to justify RIR membership for those who don't consider ULA-local to be unique enough and would not otherwise become a member. Tony > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Friday, May 11, 2007 9:12 AM > To: william(at)elan.net > Cc: Tony Hain; vixie at vix.com; ppml at arin.net; address-policy-wg at ripe.net > Subject: Re: [ppml] article about IPv6 vs firewalls vs NAT in > arstechnica (seen on slashdot) > > ULA Central is intended so that some subset of the internet can reliably > use it to interconnect while not being "globally" routed. > > The problem I have with this theory is that the delta between a > collection > of networks routing by mutual agreement and the internet is: > > A. Fuzzy > B. Non-Existant > C. There is no difference > D. Meaningless > E. Any and/or All of the above > > Pick your favorite answer from the above and you've pretty much got it. > If ULA central were limited to not exiting the local AS (in some > meaningful > way, like routers won't forward routes or traffic to ULA addresses to > external > adjacencies), then, I might see it as something other than an end-run on > the RIR process. However, in it's current state of "license for > anyone who > wants to run a competing RIR for networks that choose to interoperate > on this basis" I think it's a pretty bad idea. > > Owen > > > On May 11, 2007, at 12:03 AM, william(at)elan.net wrote: > > > > > I don't understand your point about why ULA need to be registered if > > its not going to be globally routed. Also PI is not the same as ULA - > > PI do come from RIRs and in IPv6 there was no way to get PI (except > > in a few special cases) until recent ARIN's micro-allocation policy. > > > > On Fri, 11 May 2007, Tony Hain wrote: > > > >> I agree that this will help inform the debate, and while Iljitsch > >> did a good > >> job of outlining the issue, he left out a significant point::: > >> People explicitly chose to be in the state of "as there is > >> currently no > >> obvious way to make services only available locally" by insisting > >> that the > >> local-scope addressing range have a global-scope as far as > >> application > >> developers were concerned. Now the application developers are > >> complaining > >> about the consequences of their choice, because the alternative to > >> 'no > >> routing path for an attack' is to insert a device that has to make > >> policy > >> decisions with limited information. > >> > >> The current ULA-central discussions will be directly involved in > >> this issue. > >> It is critical that all of the RIR's have policies establishing a > >> mechanism > >> for registering ULA-central prefixes & PI. For those who don't > >> recall, the > >> reason ULA-central was tabled was that it was seen as a potential > >> end-run to > >> acquire PI space in the absence of appropriate policy to do so out > >> of a > >> range recognized for global routing. > >> > >> The need for keeping some things local while others are global is > >> real, and > >> the lack of appropriate mechanisms to accomplish that through the > >> routing > >> system that is designed to deal with path selection leads to entire > >> industries for fragile work-arounds along with their increased > >> complexity. > >> > >> Tony > >> > >> > >>> -----Original Message----- > >>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > >>> Behalf Of > >>> vixie at vix.com > >>> Sent: Thursday, May 10, 2007 9:59 PM > >>> To: ppml at arin.net > >>> Subject: [ppml] article about IPv6 vs firewalls vs NAT in > >>> arstechnica > >>> (seen on slashdot) > >>> > >>> i think that this article will help inform the debate around the > >>> ipv6 > >>> transition: > >>> > >>> http://arstechnica.com/articles/paedia/ipv6-firewall-mixed- > >>> blessing.ars > >>> _______________________________________________ > >>> This message sent to you through the ARIN Public Policy Mailing List > >>> (PPML at arin.net). > >>> Manage your mailing list subscription at: > >>> http://lists.arin.net/mailman/listinfo/ppml > >> > >> _______________________________________________ > >> This message sent to you through the ARIN Public Policy Mailing List > >> (PPML at arin.net). > >> Manage your mailing list subscription at: > >> http://lists.arin.net/mailman/listinfo/ppml > > _______________________________________________ > > This message sent to you through the ARIN Public Policy Mailing List > > (PPML at arin.net). > > Manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/ppml From michael.dillon at bt.com Fri May 11 15:35:25 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 11 May 2007 14:35:25 +0100 Subject: [address-policy-wg] Can the RIRs bypass the IETF and do their own thing? In-Reply-To: References: Message-ID: > If the draft RFC was resurrected > Would you still think this was an end-run on the RIR process? > > Would you be in support of the draft moving forward? Seems to me that if the draft is not resurrected, there are no ULA addresses for ARIN or RIPE to register, regardless of anything that ARIN or RIPE members might desire. > If you prefer the RIR process, would you be in favor of a global policy > submitted to ARIN that had the provisions of the expired ULA-central > draft, with the modification of removing "cental authority" and clearly > designating how IANA should divide the space among the existing RIRs? Seems to me that the NRO requires that identical policies be PASSED by all of the RIRs before they can be considered "global policy". This is an area where it makes a whole lot of sense to have discussions on several RIR mailing lists before ANY policy proposal is submitted to ANY of the 5 RIRs. I'm not going to quibble with the wording of the draft at this point. I just wonder whether it is appropriate for the RIR mailing lists to be used as a working group for writing Internet drafts? It seems to be a stupid way to proceed because there are at least 5 different mailing lists involved, one of which is primarily in Spanish. Crossposting is not a solution. If people are serious about this central ULA concept then they should get ONE of the RIRs to set up a working group (RIPE would be my first choice, ARIN second) and then have all of this discussion in that working group mailing list. People from all of the 5 RIRs should be invited to the working group by official RIR postings to whatever lists are appropriate. Some RIRs have announcement lists for such things or members-only lists to ensure that the word gets out. Then draft the document in your ONE SINGLE mailing list discussion, submit it to the IETF, and only then, after an agreed draft is formally in the IETF pipeline, submit your global policy proposals to each of the RIRs. The way this is being done right now is pure madness and I would expect that the RIR boards will reject any policies that arise through this UNFAIR AND DISJOINTED process. We have always allowed the IETF to take first place when it comes to creating new number resources. There is no good reason to change this for so-called central-ULA addresses. We do need the technical expertise that is in the IETF to review this before we can make any kind of policy decisions about a registry for these addresses. I know many people on the RIR policy lists are technical experts, but that doesn't count, because these are policy lists, not technical ones. It is one thing for a few technical people to convince a large number of non-technical people about a topic. It is another thing entirely, for those few technical people to convince the large number of technical people who participate in the IETF. It seems to me that the promoters of central-ULA are trying to bypass the IETF's technical review process and I don't like this. --Michael Dillon From jordi.palet at consulintel.es Fri May 11 23:23:26 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 11 May 2007 23:23:26 +0200 Subject: [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: Message-ID: I've talked with Leo from IANA about this details a few days ago. Basically there are two choices to make this happen (even both in parallel): 1) The ID becomes an RFC and possibly has further details, as for example a possible split of the FC00 in between several registries, or just a mention of the IANA as to designate the central registry (a single one or distributed across several), with an explicit mention of the RIRs as being that authority. 2) A global policy doing the same job. The risk here is that it is not accepted by any of the RIRs, and then we become stuck. I will say that the RFC path may be faster and actually is what I'm trying to follow with the ID authors. Regards, Jordi > De: Jason Schiller > Responder a: > Fecha: Fri, 11 May 2007 09:05:10 -0400 (EDT) > Para: Owen DeLong > CC: , , "address-policy-wg at ripe.net" > > Asunto: Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen > on slashdot) > > Owen, > > I just want to be clear about somehting you said. You view ULA central as > "an end-run on the RIR process." Is this because the expired ULC-central > draft suggests that some new "central allocation authority" be established > to assign these addresses? > > If the draft RFC was resurrected and all references to "cental allocation > authority" and "cental authority" were removed and replaced with clear > text explaining the following: > > - IANA should divide FC00::/8 into eight /11s > - Each RIR would be given one /11 to make ULA-Central assignments > - Three /11s would be held in reserve for new RIRs in the future. > > Would you still think this was an end-run on the RIR process? > > Would you be in support of the draft moving forward? > > Do you think this should not be decided by an RFC, but rather as a global > policy through each of the RIRs? > > If you prefer the RIR process, would you be in favor of a global policy > submitted to ARIN that had the provisions of the expired ULA-central > draft, with the modification of removing "cental authority" and clearly > designating how IANA should divide the space among the existing RIRs? > > ULA-central text snippets below. > > ___Jason > > > > draft-ietf-ipv6-ula-central-01.txt -- section 3.2.1 > "Global IDs should be assigned under the authority of a single > allocation organization because they are pseudo-random and without > any structure. This is easiest to accomplish if there is a single > authority for the assignments." > > draft-ietf-ipv6-ula-central-01.txt -- section 7.0 > > "The IANA is instructed to designate an allocation authority, based on > instructions from the IAB, for centrally assigned Unique Local IPv6 > unicast addresses. This allocation authority shall comply with the > requirements described in Section 3.2 of this document, including in > particular allocation on a permanent basis and with sufficient > provisions to avoid hoarding of numbers. If deemed appropriate, the > authority may also consist of multiple organizations performing the > allocation authority duties. > > The designated allocation authority is required to document how they > will meet the requirements described in Section 3.2 of this document > in an RFC. This RFC will be shepherd through the IETF by the IAB." > > > > > > ========================================================================== > Jason Schiller (703)886.6648 > Senior Internet Network Engineer fax:(703)886.0512 > Public IP Global Network Engineering schiller at uu.net > UUNET / Verizon jason.schiller at verizonbusiness.com > > The good news about having an email address that is twice as long is that > it increases traffic on the Internet. > > On Thu, 10 May 2007, Owen DeLong wrote: > >> Date: Thu, 10 May 2007 23:12:21 -0700 >> From: Owen DeLong >> To: "william(at)elan.net" >> Cc: vixie at vix.com, ppml at arin.net, address-policy-wg at ripe.net >> Subject: Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica >> (seen on slashdot) >> >> ULA Central is intended so that some subset of the internet can reliably >> use it to interconnect while not being "globally" routed. >> >> The problem I have with this theory is that the delta between a >> collection >> of networks routing by mutual agreement and the internet is: >> >> A. Fuzzy >> B. Non-Existant >> C. There is no difference >> D. Meaningless >> E. Any and/or All of the above >> >> Pick your favorite answer from the above and you've pretty much got it. >> If ULA central were limited to not exiting the local AS (in some >> meaningful >> way, like routers won't forward routes or traffic to ULA addresses to >> external >> adjacencies), then, I might see it as something other than an end-run on >> the RIR process. However, in it's current state of "license for >> anyone who >> wants to run a competing RIR for networks that choose to interoperate >> on this basis" I think it's a pretty bad idea. >> >> Owen >> >> >> On May 11, 2007, at 12:03 AM, william(at)elan.net wrote: >> >>> >>> I don't understand your point about why ULA need to be registered if >>> its not going to be globally routed. Also PI is not the same as ULA - >>> PI do come from RIRs and in IPv6 there was no way to get PI (except >>> in a few special cases) until recent ARIN's micro-allocation policy. >>> >>> On Fri, 11 May 2007, Tony Hain wrote: >>> >>>> I agree that this will help inform the debate, and while Iljitsch >>>> did a good >>>> job of outlining the issue, he left out a significant point::: >>>> People explicitly chose to be in the state of "as there is >>>> currently no >>>> obvious way to make services only available locally" by insisting >>>> that the >>>> local-scope addressing range have a global-scope as far as >>>> application >>>> developers were concerned. Now the application developers are >>>> complaining >>>> about the consequences of their choice, because the alternative to >>>> 'no >>>> routing path for an attack' is to insert a device that has to make >>>> policy >>>> decisions with limited information. >>>> >>>> The current ULA-central discussions will be directly involved in >>>> this issue. >>>> It is critical that all of the RIR's have policies establishing a >>>> mechanism >>>> for registering ULA-central prefixes & PI. For those who don't >>>> recall, the >>>> reason ULA-central was tabled was that it was seen as a potential >>>> end-run to >>>> acquire PI space in the absence of appropriate policy to do so out >>>> of a >>>> range recognized for global routing. >>>> >>>> The need for keeping some things local while others are global is >>>> real, and >>>> the lack of appropriate mechanisms to accomplish that through the >>>> routing >>>> system that is designed to deal with path selection leads to entire >>>> industries for fragile work-arounds along with their increased >>>> complexity. >>>> >>>> Tony >>>> >>>> >>>>> -----Original Message----- >>>>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On >>>>> Behalf Of >>>>> vixie at vix.com >>>>> Sent: Thursday, May 10, 2007 9:59 PM >>>>> To: ppml at arin.net >>>>> Subject: [ppml] article about IPv6 vs firewalls vs NAT in >>>>> arstechnica >>>>> (seen on slashdot) >>>>> >>>>> i think that this article will help inform the debate around the >>>>> ipv6 >>>>> transition: >>>>> >>>>> http://arstechnica.com/articles/paedia/ipv6-firewall-mixed- >>>>> blessing.ars >>>>> _______________________________________________ >>>>> This message sent to you through the ARIN Public Policy Mailing List >>>>> (PPML at arin.net). >>>>> Manage your mailing list subscription at: >>>>> http://lists.arin.net/mailman/listinfo/ppml >>>> >>>> _______________________________________________ >>>> This message sent to you through the ARIN Public Policy Mailing List >>>> (PPML at arin.net). >>>> Manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/ppml >>> _______________________________________________ >>> This message sent to you through the ARIN Public Policy Mailing List >>> (PPML at arin.net). >>> Manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/ppml >> >> > > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From jordi.palet at consulintel.es Fri May 11 23:32:47 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 11 May 2007 23:32:47 +0200 Subject: [address-policy-wg] Re: Can the RIRs bypass the IETF and do their own thing? In-Reply-To: Message-ID: I've already indicated this in previous occasions, but may be not in ppml ... We are proceeding in parallel, with the ID and the PDP at the same time. Nothing in the PDP precludes doing so. The RIRs don't depend on IETF at all, they can define global policies for things that the IETF failed to complete if that's the case. IANA can be instructed the same by the RIRs (which a global policy) than by the IETF itself with an RFC. Even when the IETF get the document as an RFC, the RIRs need a policy (in this case no need for a global one) to start using the resource. That's why both things are needed. The boards of the RIRs, if the policy reach consensus, should hold the implementation until the RFC is available or instead, a global policy reach consensus to replace the function of the RFC. This is something that it is natural to be done, but again, doesn't preclude to start debating about the policy and win some time. If anyone want to discuss about the ULA-central ID, I encourage to bring that discussion to the ipv6 WG mailing list, no need to create a new one. For discussions about the policy proposal, use the corresponding RIR mail exploder. Regards, Jordi > De: > Responder a: > Fecha: Fri, 11 May 2007 14:35:25 +0100 > Para: , , > Conversaci?n: Can the RIRs bypass the IETF and do their own thing? > Asunto: Can the RIRs bypass the IETF and do their own thing? > >> If the draft RFC was resurrected > >> Would you still think this was an end-run on the RIR process? >> >> Would you be in support of the draft moving forward? > > Seems to me that if the draft is not resurrected, there are no ULA > addresses for ARIN or RIPE to register, regardless of anything that ARIN > or RIPE members might desire. > >> If you prefer the RIR process, would you be in favor of a global > policy >> submitted to ARIN that had the provisions of the expired ULA-central >> draft, with the modification of removing "cental authority" and > clearly >> designating how IANA should divide the space among the existing RIRs? > > Seems to me that the NRO requires that identical policies be PASSED by > all of the RIRs before they can be considered "global policy". This is > an area where it makes a whole lot of sense to have discussions on > several RIR mailing lists before ANY policy proposal is submitted to ANY > of the 5 RIRs. > > I'm not going to quibble with the wording of the draft at this point. I > just wonder whether it is appropriate for the RIR mailing lists to be > used as a working group for writing Internet drafts? It seems to be a > stupid way to proceed because there are at least 5 different mailing > lists involved, one of which is primarily in Spanish. Crossposting is > not a solution. > > If people are serious about this central ULA concept then they should > get ONE of the RIRs to set up a working group (RIPE would be my first > choice, ARIN second) and then have all of this discussion in that > working group mailing list. People from all of the 5 RIRs should be > invited to the working group by official RIR postings to whatever lists > are appropriate. Some RIRs have announcement lists for such things or > members-only lists to ensure that the word gets out. Then draft the > document in your ONE SINGLE mailing list discussion, submit it to the > IETF, and only then, after an agreed draft is formally in the IETF > pipeline, submit your global policy proposals to each of the RIRs. > > The way this is being done right now is pure madness and I would expect > that the RIR boards will reject any policies that arise through this > UNFAIR AND DISJOINTED process. We have always allowed the IETF to take > first place when it comes to creating new number resources. There is no > good reason to change this for so-called central-ULA addresses. We do > need the technical expertise that is in the IETF to review this before > we can make any kind of policy decisions about a registry for these > addresses. > > I know many people on the RIR policy lists are technical experts, but > that doesn't count, because these are policy lists, not technical ones. > It is one thing for a few technical people to convince a large number of > non-technical people about a topic. It is another thing entirely, for > those few technical people to convince the large number of technical > people who participate in the IETF. It seems to me that the promoters of > central-ULA are trying to bypass the IETF's technical review process and > I don't like this. > > --Michael Dillon > > > > _______________________________________________ > Ietf mailing list > Ietf at ietf.org > https://www1.ietf.org/mailman/listinfo/ietf ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From jordi.palet at consulintel.es Fri May 11 23:37:43 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 11 May 2007 23:37:43 +0200 Subject: [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <90966F89-6CCB-44F5-8797-AD51317E0CC8@delong.com> Message-ID: This is something that could possibly be managed depending on how you setup the fees for ULA-central, but there may be other ways also. I think RIRs staff will make sure that one is not used instead of the other. Fraud (telling you need ULA-central and using as PI) is always a possibility with any policy, and there are means to verify it. I also believe that if transit providers understand the difference, they will not allow using ULA-central as PI, moreover, you will always have the risk of trying so and being filtered in part of the Internet. A PI requester will not risk (unless there is no PI, but now is available already in 3 regions, and I expect that will be in all before ULA-central is adopted in any). Regards, Jordi > De: Owen DeLong > Responder a: > Fecha: Fri, 11 May 2007 06:38:39 -0700 > Para: > CC: , "address-policy-wg at ripe.net" > Asunto: Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen > on slashdot) > > > On May 11, 2007, at 1:37 AM, JORDI PALET MARTINEZ wrote: > >> Even if not globally routed, you may want to avoid a possible clash >> with >> another organization, for example in case of a merge. >> >> ULA-central is NOT intended to be uses as IPv6 PI. >> > > Intent is not the problem. Probability of implementation outside of the > intent is the problem. > > ULA Central is only beneficial if it is somehow easier to get than > IPv6 PI. > > If it is easier to get and there is no solid (router-enforced) way to > preclude > it from being "globally routed", then, it will get abused as an > alternative > to IPv6 PI. > > Owen > > > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From bmanning at karoshi.com Mon May 14 07:30:40 2007 From: bmanning at karoshi.com (bmanning at karoshi.com) Date: Mon, 14 May 2007 05:30:40 +0000 Subject: [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: References: Message-ID: <20070514053040.GA18747@vacation.karoshi.com.> > > ULA-central is NOT intended to be uses as IPv6 PI. but there is no way to stop it from becoming so. From shane at time-travellers.org Mon May 14 09:51:15 2007 From: shane at time-travellers.org (Shane Kerr) Date: Mon, 14 May 2007 09:51:15 +0200 Subject: [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <20070514053040.GA18747@vacation.karoshi.com.> References: <20070514053040.GA18747@vacation.karoshi.com.> Message-ID: <20070514075115.GA2937@borg.c-l-i.net> On Mon, May 14, 2007 at 05:30:40AM +0000, bmanning at karoshi.com wrote: > > > > ULA-central is NOT intended to be uses as IPv6 PI. > > but there is no way to stop it from becoming so. In the same way that RFC 1918 space is such a huge problem for the IPv4 routing table, ULA-central would be a problem in IPv6. (I think ULA-central is completely unnecessary, but I also think the "oh mi gawd IPv6 PI!!!1" argument is bogus.) -- Shane From michael.dillon at bt.com Mon May 14 10:46:56 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 14 May 2007 09:46:56 +0100 Subject: [address-policy-wg] RE: [ppml] Can the RIRs bypass the IETF and do their own thing? In-Reply-To: References: Message-ID: > If anyone want to discuss about the ULA-central ID, I encourage to bring > that discussion to the ipv6 WG mailing list, no need to create a new one. > For discussions about the policy proposal, use the corresponding RIR mail > exploder. I don't know if Fred Baker's message on the IETF list made it to the RIR lists, but he offers a single central discussion place for the central ULA concept. -----quoted from IETF list--------- In your email, you noted the disjoint nature of the RIRs and the need to cross-post or whatever. Speaking as chair of IPv6 Operations (v6ops at ops.ietf.org), I would invite you and all those interested in the effort to use the v6ops list for the purpose and the v6ops working group as a venue to do the work. If you would like, we can arrange a v6ops interim meeting at the RIR meeting of your choice, or it could be discussed in the currently-planned meeting in the third week of July in Chicago. --------------- So, now there is no longer any need to complain that the IETF is too slow or that the RIRs need to work in parallel. Anyone can join the v6ops list (instructions here http://www.ietf.org/html.charters/v6ops-charter.html ) and anyone can propose how central ULAs could be made to work. And for those who wish to meet face-to-face, there is an opportunity in Chicago in July. Hopefully, the v6ops list will look at other alternatives such as using AS numbers to define a block of addresses similar to the way GLOP defined multicast addressing in RFC 3180 http://www.ietf.org/rfc/rfc3180.txt --Michael Dillon From jordi.palet at consulintel.es Mon May 14 10:53:50 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Mon, 14 May 2007 10:53:50 +0200 Subject: [address-policy-wg] Re: [ppml] Can the RIRs bypass the IETF and do their own thing? In-Reply-To: Message-ID: That may be true for IPv6 operational issues, however, following the IETF procedures, for discussing about ULA-central, which is an IPv6 WG item, it should be done at the ipv6 at ietf.org mail exploder. Regards, Jordi > De: > Responder a: > Fecha: Mon, 14 May 2007 09:46:56 +0100 > Para: , > Conversaci?n: [ppml] Can the RIRs bypass the IETF and do their own thing? > Asunto: Re: [ppml] Can the RIRs bypass the IETF and do their own thing? > > >> If anyone want to discuss about the ULA-central ID, I encourage to > bring >> that discussion to the ipv6 WG mailing list, no need to create a new > one. >> For discussions about the policy proposal, use the corresponding RIR > mail >> exploder. > > I don't know if Fred Baker's message on the IETF list made it to the RIR > lists, but he offers a single central discussion place for the central > ULA concept. > > -----quoted from IETF list--------- > In your email, you noted the disjoint nature of the RIRs and the need to > cross-post or whatever. Speaking as chair of IPv6 Operations > (v6ops at ops.ietf.org), I would invite you and all those interested in the > effort to use the v6ops list for the purpose and the v6ops working group > as a venue to do the work. If you would like, we can arrange a v6ops > interim meeting at the RIR meeting of your choice, or it could be > discussed in the currently-planned meeting in the third week of July in > Chicago. > --------------- > > So, now there is no longer any need to complain that the IETF is too > slow or that the RIRs need to work in parallel. Anyone can join the > v6ops list (instructions here > http://www.ietf.org/html.charters/v6ops-charter.html ) and anyone can > propose how central ULAs could be made to work. And for those who wish > to meet face-to-face, there is an opportunity in Chicago in July. > > Hopefully, the v6ops list will look at other alternatives such as using > AS numbers to define a block of addresses similar to the way GLOP > defined multicast addressing in RFC 3180 > http://www.ietf.org/rfc/rfc3180.txt > > --Michael Dillon > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From schiller at uu.net Fri May 11 15:05:10 2007 From: schiller at uu.net (Jason Schiller) Date: Fri, 11 May 2007 09:05:10 -0400 (EDT) Subject: [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: Message-ID: Owen, I just want to be clear about somehting you said. You view ULA central as "an end-run on the RIR process." Is this because the expired ULC-central draft suggests that some new "central allocation authority" be established to assign these addresses? If the draft RFC was resurrected and all references to "cental allocation authority" and "cental authority" were removed and replaced with clear text explaining the following: - IANA should divide FC00::/8 into eight /11s - Each RIR would be given one /11 to make ULA-Central assignments - Three /11s would be held in reserve for new RIRs in the future. Would you still think this was an end-run on the RIR process? Would you be in support of the draft moving forward? Do you think this should not be decided by an RFC, but rather as a global policy through each of the RIRs? If you prefer the RIR process, would you be in favor of a global policy submitted to ARIN that had the provisions of the expired ULA-central draft, with the modification of removing "cental authority" and clearly designating how IANA should divide the space among the existing RIRs? ULA-central text snippets below. ___Jason draft-ietf-ipv6-ula-central-01.txt -- section 3.2.1 "Global IDs should be assigned under the authority of a single allocation organization because they are pseudo-random and without any structure. This is easiest to accomplish if there is a single authority for the assignments." draft-ietf-ipv6-ula-central-01.txt -- section 7.0 "The IANA is instructed to designate an allocation authority, based on instructions from the IAB, for centrally assigned Unique Local IPv6 unicast addresses. This allocation authority shall comply with the requirements described in Section 3.2 of this document, including in particular allocation on a permanent basis and with sufficient provisions to avoid hoarding of numbers. If deemed appropriate, the authority may also consist of multiple organizations performing the allocation authority duties. The designated allocation authority is required to document how they will meet the requirements described in Section 3.2 of this document in an RFC. This RFC will be shepherd through the IETF by the IAB." ========================================================================== Jason Schiller (703)886.6648 Senior Internet Network Engineer fax:(703)886.0512 Public IP Global Network Engineering schiller at uu.net UUNET / Verizon jason.schiller at verizonbusiness.com The good news about having an email address that is twice as long is that it increases traffic on the Internet. On Thu, 10 May 2007, Owen DeLong wrote: > Date: Thu, 10 May 2007 23:12:21 -0700 > From: Owen DeLong > To: "william(at)elan.net" > Cc: vixie at vix.com, ppml at arin.net, address-policy-wg at ripe.net > Subject: Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica > (seen on slashdot) > > ULA Central is intended so that some subset of the internet can reliably > use it to interconnect while not being "globally" routed. > > The problem I have with this theory is that the delta between a > collection > of networks routing by mutual agreement and the internet is: > > A. Fuzzy > B. Non-Existant > C. There is no difference > D. Meaningless > E. Any and/or All of the above > > Pick your favorite answer from the above and you've pretty much got it. > If ULA central were limited to not exiting the local AS (in some > meaningful > way, like routers won't forward routes or traffic to ULA addresses to > external > adjacencies), then, I might see it as something other than an end-run on > the RIR process. However, in it's current state of "license for > anyone who > wants to run a competing RIR for networks that choose to interoperate > on this basis" I think it's a pretty bad idea. > > Owen > > > On May 11, 2007, at 12:03 AM, william(at)elan.net wrote: > > > > > I don't understand your point about why ULA need to be registered if > > its not going to be globally routed. Also PI is not the same as ULA - > > PI do come from RIRs and in IPv6 there was no way to get PI (except > > in a few special cases) until recent ARIN's micro-allocation policy. > > > > On Fri, 11 May 2007, Tony Hain wrote: > > > >> I agree that this will help inform the debate, and while Iljitsch > >> did a good > >> job of outlining the issue, he left out a significant point::: > >> People explicitly chose to be in the state of "as there is > >> currently no > >> obvious way to make services only available locally" by insisting > >> that the > >> local-scope addressing range have a global-scope as far as > >> application > >> developers were concerned. Now the application developers are > >> complaining > >> about the consequences of their choice, because the alternative to > >> 'no > >> routing path for an attack' is to insert a device that has to make > >> policy > >> decisions with limited information. > >> > >> The current ULA-central discussions will be directly involved in > >> this issue. > >> It is critical that all of the RIR's have policies establishing a > >> mechanism > >> for registering ULA-central prefixes & PI. For those who don't > >> recall, the > >> reason ULA-central was tabled was that it was seen as a potential > >> end-run to > >> acquire PI space in the absence of appropriate policy to do so out > >> of a > >> range recognized for global routing. > >> > >> The need for keeping some things local while others are global is > >> real, and > >> the lack of appropriate mechanisms to accomplish that through the > >> routing > >> system that is designed to deal with path selection leads to entire > >> industries for fragile work-arounds along with their increased > >> complexity. > >> > >> Tony > >> > >> > >>> -----Original Message----- > >>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > >>> Behalf Of > >>> vixie at vix.com > >>> Sent: Thursday, May 10, 2007 9:59 PM > >>> To: ppml at arin.net > >>> Subject: [ppml] article about IPv6 vs firewalls vs NAT in > >>> arstechnica > >>> (seen on slashdot) > >>> > >>> i think that this article will help inform the debate around the > >>> ipv6 > >>> transition: > >>> > >>> http://arstechnica.com/articles/paedia/ipv6-firewall-mixed- > >>> blessing.ars > >>> _______________________________________________ > >>> This message sent to you through the ARIN Public Policy Mailing List > >>> (PPML at arin.net). > >>> Manage your mailing list subscription at: > >>> http://lists.arin.net/mailman/listinfo/ppml > >> > >> _______________________________________________ > >> This message sent to you through the ARIN Public Policy Mailing List > >> (PPML at arin.net). > >> Manage your mailing list subscription at: > >> http://lists.arin.net/mailman/listinfo/ppml > > _______________________________________________ > > This message sent to you through the ARIN Public Policy Mailing List > > (PPML at arin.net). > > Manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/ppml > > From schiller at uu.net Fri May 11 15:14:36 2007 From: schiller at uu.net (Jason Schiller) Date: Fri, 11 May 2007 09:14:36 -0400 (EDT) Subject: [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: Message-ID: On Fri, 11 May 2007, JORDI PALET MARTINEZ wrote: > Even if not globally routed, you may want to avoid a possible clash with > another organization, for example in case of a merge. > I agree. The importance of it being assigned by an authority is that that authority provides uniqueness. This is often important when an address collision occurs, such that one entity can prove they have the legitmate claim to use those numbers. Although these addresses may be used "internally" it is also important that they be capable to be supported by DNS (without setting up a split-horrizon DNS), for ease of management __Jason From owen at delong.com Fri May 11 15:38:39 2007 From: owen at delong.com (Owen DeLong) Date: Fri, 11 May 2007 06:38:39 -0700 Subject: [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: References: Message-ID: <90966F89-6CCB-44F5-8797-AD51317E0CC8@delong.com> On May 11, 2007, at 1:37 AM, JORDI PALET MARTINEZ wrote: > Even if not globally routed, you may want to avoid a possible clash > with > another organization, for example in case of a merge. > > ULA-central is NOT intended to be uses as IPv6 PI. > Intent is not the problem. Probability of implementation outside of the intent is the problem. ULA Central is only beneficial if it is somehow easier to get than IPv6 PI. If it is easier to get and there is no solid (router-enforced) way to preclude it from being "globally routed", then, it will get abused as an alternative to IPv6 PI. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From owen at delong.com Fri May 11 15:58:55 2007 From: owen at delong.com (Owen DeLong) Date: Fri, 11 May 2007 06:58:55 -0700 Subject: [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: References: Message-ID: <5ACC8BD4-1ABC-4507-853E-7A5AD97C8496@delong.com> On May 11, 2007, at 6:05 AM, Jason Schiller wrote: > Owen, > > I just want to be clear about somehting you said. You view ULA > central as > "an end-run on the RIR process." Is this because the expired ULC- > central > draft suggests that some new "central allocation authority" be > established > to assign these addresses? > > If the draft RFC was resurrected and all references to "cental > allocation > authority" and "cental authority" were removed and replaced with clear > text explaining the following: > > - IANA should divide FC00::/8 into eight /11s > - Each RIR would be given one /11 to make ULA-Central assignments > - Three /11s would be held in reserve for new RIRs in the future. > > Would you still think this was an end-run on the RIR process? > I would not think it was an end-run on RIRs at that point. > Would you be in support of the draft moving forward? > It would depend on what provisions were in the draft to prevent it from being an end-run on PI policies. > Do you think this should not be decided by an RFC, but rather as a > global > policy through each of the RIRs? > I am not sure. I kind of like Tony's (malformed) suggestion that ULA- C should come with PI. If the qualifications for ULA-C were the same, or, if ULA-C was only available to orgs. that had PI, I think that would be acceptable. > If you prefer the RIR process, would you be in favor of a global > policy > submitted to ARIN that had the provisions of the expired ULA-central > draft, with the modification of removing "cental authority" and > clearly > designating how IANA should divide the space among the existing RIRs? > Not sure about that. I do support the idea of ULA-Central as intended, but, I'd have to see a policy or RFC that implemented it in such a way that I had reasonable confidence it wouldn't become "the easy way to get PI". If we're going to do that, I'd rather do it by relaxing the PI policy than by designating some "nudge nudge wink wink" address space. Owen > ULA-central text snippets below. > > ___Jason > > > > draft-ietf-ipv6-ula-central-01.txt -- section 3.2.1 > "Global IDs should be assigned under the authority of a single > allocation organization because they are pseudo-random and without > any structure. This is easiest to accomplish if there is a single > authority for the assignments." > > draft-ietf-ipv6-ula-central-01.txt -- section 7.0 > > "The IANA is instructed to designate an allocation authority, > based on > instructions from the IAB, for centrally assigned Unique Local IPv6 > unicast addresses. This allocation authority shall comply with the > requirements described in Section 3.2 of this document, > including in > particular allocation on a permanent basis and with sufficient > provisions to avoid hoarding of numbers. If deemed appropriate, > the > authority may also consist of multiple organizations performing the > allocation authority duties. > > The designated allocation authority is required to document how > they > will meet the requirements described in Section 3.2 of this > document > in an RFC. This RFC will be shepherd through the IETF by the IAB." > > > > > > ====================================================================== > ==== > Jason Schiller (703) > 886.6648 > Senior Internet Network Engineer fax:(703) > 886.0512 > Public IP Global Network Engineering > schiller at uu.net > UUNET / Verizon > jason.schiller at verizonbusiness.com > > The good news about having an email address that is twice as long > is that > it increases traffic on the Internet. > > On Thu, 10 May 2007, Owen DeLong wrote: > >> Date: Thu, 10 May 2007 23:12:21 -0700 >> From: Owen DeLong >> To: "william(at)elan.net" >> Cc: vixie at vix.com, ppml at arin.net, address-policy-wg at ripe.net >> Subject: Re: [ppml] article about IPv6 vs firewalls vs NAT in >> arstechnica >> (seen on slashdot) >> >> ULA Central is intended so that some subset of the internet can >> reliably >> use it to interconnect while not being "globally" routed. >> >> The problem I have with this theory is that the delta between a >> collection >> of networks routing by mutual agreement and the internet is: >> >> A. Fuzzy >> B. Non-Existant >> C. There is no difference >> D. Meaningless >> E. Any and/or All of the above >> >> Pick your favorite answer from the above and you've pretty much >> got it. >> If ULA central were limited to not exiting the local AS (in some >> meaningful >> way, like routers won't forward routes or traffic to ULA addresses to >> external >> adjacencies), then, I might see it as something other than an end- >> run on >> the RIR process. However, in it's current state of "license for >> anyone who >> wants to run a competing RIR for networks that choose to interoperate >> on this basis" I think it's a pretty bad idea. >> >> Owen >> >> >> On May 11, 2007, at 12:03 AM, william(at)elan.net wrote: >> >>> >>> I don't understand your point about why ULA need to be registered if >>> its not going to be globally routed. Also PI is not the same as >>> ULA - >>> PI do come from RIRs and in IPv6 there was no way to get PI (except >>> in a few special cases) until recent ARIN's micro-allocation policy. >>> >>> On Fri, 11 May 2007, Tony Hain wrote: >>> >>>> I agree that this will help inform the debate, and while Iljitsch >>>> did a good >>>> job of outlining the issue, he left out a significant point::: >>>> People explicitly chose to be in the state of "as there is >>>> currently no >>>> obvious way to make services only available locally" by insisting >>>> that the >>>> local-scope addressing range have a global-scope as far as >>>> application >>>> developers were concerned. Now the application developers are >>>> complaining >>>> about the consequences of their choice, because the alternative to >>>> 'no >>>> routing path for an attack' is to insert a device that has to make >>>> policy >>>> decisions with limited information. >>>> >>>> The current ULA-central discussions will be directly involved in >>>> this issue. >>>> It is critical that all of the RIR's have policies establishing a >>>> mechanism >>>> for registering ULA-central prefixes & PI. For those who don't >>>> recall, the >>>> reason ULA-central was tabled was that it was seen as a potential >>>> end-run to >>>> acquire PI space in the absence of appropriate policy to do so out >>>> of a >>>> range recognized for global routing. >>>> >>>> The need for keeping some things local while others are global is >>>> real, and >>>> the lack of appropriate mechanisms to accomplish that through the >>>> routing >>>> system that is designed to deal with path selection leads to entire >>>> industries for fragile work-arounds along with their increased >>>> complexity. >>>> >>>> Tony >>>> >>>> >>>>> -----Original Message----- >>>>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On >>>>> Behalf Of >>>>> vixie at vix.com >>>>> Sent: Thursday, May 10, 2007 9:59 PM >>>>> To: ppml at arin.net >>>>> Subject: [ppml] article about IPv6 vs firewalls vs NAT in >>>>> arstechnica >>>>> (seen on slashdot) >>>>> >>>>> i think that this article will help inform the debate around the >>>>> ipv6 >>>>> transition: >>>>> >>>>> http://arstechnica.com/articles/paedia/ipv6-firewall-mixed- >>>>> blessing.ars >>>>> _______________________________________________ >>>>> This message sent to you through the ARIN Public Policy Mailing >>>>> List >>>>> (PPML at arin.net). >>>>> Manage your mailing list subscription at: >>>>> http://lists.arin.net/mailman/listinfo/ppml >>>> >>>> _______________________________________________ >>>> This message sent to you through the ARIN Public Policy Mailing >>>> List >>>> (PPML at arin.net). >>>> Manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/ppml >>> _______________________________________________ >>> This message sent to you through the ARIN Public Policy Mailing List >>> (PPML at arin.net). >>> Manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/ppml >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From fred at cisco.com Fri May 11 16:14:41 2007 From: fred at cisco.com (Fred Baker) Date: Fri, 11 May 2007 07:14:41 -0700 Subject: [address-policy-wg] Re: Can the RIRs bypass the IETF and do their own thing? In-Reply-To: References: Message-ID: <4BEE8CD2-4F61-41AA-B502-631E99411F15@cisco.com> On May 11, 2007, at 6:35 AM, wrote: > I'm not going to quibble with the wording of the draft at this > point. I just wonder whether it is appropriate for the RIR mailing > lists to be used as a working group for writing Internet drafts? I don't see why not, but... In your email, you noted the disjoint nature of the RIRs and the need to cross-post or whatever. Speaking as chair of IPv6 Operations (v6ops at ops.ietf.org), I would invite you and all those interested in the effort to use the v6ops list for the purpose and the v6ops working group as a venue to do the work. If you would like, we can arrange a v6ops interim meeting at the RIR meeting of your choice, or it could be discussed in the currently-planned meeting in the third week of July in Chicago. One technical question I would ask. What does a "Central Authority" and "IANA Assignment" have to do with a "Local" address of any type? It seems in context that the major issue is an address prefix that is not advertised to neighboring ISPs and can be generally configured to be refused if offered by a neighboring ISP, in the same way that an RFC 1918 address is not advertised and is generally refused between IPv4 networks. In any draft on this topic, regardless of where it is discussed, if central assignment is in view, the reason for having such assignment should be clearly stated. From dlw+arin at tellme.com Fri May 11 18:08:57 2007 From: dlw+arin at tellme.com (David Williamson) Date: Fri, 11 May 2007 09:08:57 -0700 Subject: [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: References: <97549.1178823530@sa.vix.com> <013401c79381$003efa20$00bcee60$@net> Message-ID: <20070511160856.GR1343@shell01.corp.tellme.com> I hate to just parrot someone else's comments, but I'm entirely against the entire concept of ULA-central for exactly the reasons Owen outlines below. (Thanks, Owen, for getting that written so I don't have to!) -David On Thu, May 10, 2007 at 11:12:21PM -0700, Owen DeLong wrote: > ULA Central is intended so that some subset of the internet can reliably > use it to interconnect while not being "globally" routed. > > The problem I have with this theory is that the delta between a > collection > of networks routing by mutual agreement and the internet is: > > A. Fuzzy > B. Non-Existant > C. There is no difference > D. Meaningless > E. Any and/or All of the above > > Pick your favorite answer from the above and you've pretty much got it. > If ULA central were limited to not exiting the local AS (in some > meaningful > way, like routers won't forward routes or traffic to ULA addresses to > external > adjacencies), then, I might see it as something other than an end-run on > the RIR process. However, in it's current state of "license for > anyone who > wants to run a competing RIR for networks that choose to interoperate > on this basis" I think it's a pretty bad idea. > > Owen > > > On May 11, 2007, at 12:03 AM, william(at)elan.net wrote: > > > > >I don't understand your point about why ULA need to be registered if > >its not going to be globally routed. Also PI is not the same as ULA - > >PI do come from RIRs and in IPv6 there was no way to get PI (except > >in a few special cases) until recent ARIN's micro-allocation policy. > > > >On Fri, 11 May 2007, Tony Hain wrote: > > > >>I agree that this will help inform the debate, and while Iljitsch > >>did a good > >>job of outlining the issue, he left out a significant point::: > >>People explicitly chose to be in the state of "as there is > >>currently no > >>obvious way to make services only available locally" by insisting > >>that the > >>local-scope addressing range have a global-scope as far as > >>application > >>developers were concerned. Now the application developers are > >>complaining > >>about the consequences of their choice, because the alternative to > >>'no > >>routing path for an attack' is to insert a device that has to make > >>policy > >>decisions with limited information. > >> > >>The current ULA-central discussions will be directly involved in > >>this issue. > >>It is critical that all of the RIR's have policies establishing a > >>mechanism > >>for registering ULA-central prefixes & PI. For those who don't > >>recall, the > >>reason ULA-central was tabled was that it was seen as a potential > >>end-run to > >>acquire PI space in the absence of appropriate policy to do so out > >>of a > >>range recognized for global routing. > >> > >>The need for keeping some things local while others are global is > >>real, and > >>the lack of appropriate mechanisms to accomplish that through the > >>routing > >>system that is designed to deal with path selection leads to entire > >>industries for fragile work-arounds along with their increased > >>complexity. > >> > >>Tony > >> > >> > >>>-----Original Message----- > >>>From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > >>>Behalf Of > >>>vixie at vix.com > >>>Sent: Thursday, May 10, 2007 9:59 PM > >>>To: ppml at arin.net > >>>Subject: [ppml] article about IPv6 vs firewalls vs NAT in > >>>arstechnica > >>>(seen on slashdot) > >>> > >>>i think that this article will help inform the debate around the > >>>ipv6 > >>>transition: > >>> > >>>http://arstechnica.com/articles/paedia/ipv6-firewall-mixed- > >>>blessing.ars > >>>_______________________________________________ > >>>This message sent to you through the ARIN Public Policy Mailing List > >>>(PPML at arin.net). > >>>Manage your mailing list subscription at: > >>>http://lists.arin.net/mailman/listinfo/ppml > >> > >>_______________________________________________ > >>This message sent to you through the ARIN Public Policy Mailing List > >>(PPML at arin.net). > >>Manage your mailing list subscription at: > >>http://lists.arin.net/mailman/listinfo/ppml > >_______________________________________________ > >This message sent to you through the ARIN Public Policy Mailing List > >(PPML at arin.net). > >Manage your mailing list subscription at: > >http://lists.arin.net/mailman/listinfo/ppml > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml From Marcus.Gerdon at versatel.de Mon May 14 10:52:06 2007 From: Marcus.Gerdon at versatel.de (Marcus.Gerdon) Date: Mon, 14 May 2007 10:52:06 +0200 Subject: AW: [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) Message-ID: <9F66B1E4971A064794AF6AB952A3ADDD01800DF5@VTSVEXCH01.versatel.local> I don't quite see the DFZ table problem or 'PI-problem' with ULA if route filtering is done properly. The theoretical problem arises by ISP/NSP not filtering 'private' prefixes and other trash. For example in v4 DFZ table private ASN can be seen forwarded even by large ISP. If ULA's become routed and therefore usable as replacement for PI it is caused by lash filtering. Prefixes not intended/assigned/allocated for public/global use are to be filtered. In case the uplink ISP accepts an ULA prefix into the routing table *he* has to deal with his customers reachability problems. Imho some sort of PI is required to be supported in v6, and either way to assign it is fine. But it has to be kept distinguished from any RFC1918 equivalent to allow for filtering of private addresses. greetz, Marcus ------------------------------------------------------------------------------------------------ Systemtechnik Internet / Internet Engineering Versatel West-Deutschland GmbH Versatel-Gruppe Unterste-Wilms-Strasse 29 D-44143 Dortmund Sitz der Gesellschaft: Berlin, Amtsgericht Charlottenburg, HRB 94994 B Gesch?ftsf?hrer: Peer Knauer, Hai Cheng, Brian Cook, Marc L?tzenkirchen, Christian Schemann Fon: +49-(0)231-399-4486 | Fax: +49-(0)231-399-4491 marcus.gerdon at versatel.de | www.versatel.de ------------------------------------------------------------------------------------------------ AS8881 / AS8638 / AS15837 | MG3031-RIPE ------------------------------------------------------------------------------------------------ -----Urspr?ngliche Nachricht----- Von: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] Im Auftrag von Shane Kerr Gesendet: Montag, 14. Mai 2007 09:51 An: bmanning at karoshi.com Cc: ppml at arin.net; address-policy-wg at ripe.net Betreff: Re: [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) On Mon, May 14, 2007 at 05:30:40AM +0000, bmanning at karoshi.com wrote: > > > > ULA-central is NOT intended to be uses as IPv6 PI. > > but there is no way to stop it from becoming so. In the same way that RFC 1918 space is such a huge problem for the IPv4 routing table, ULA-central would be a problem in IPv6. (I think ULA-central is completely unnecessary, but I also think the "oh mi gawd IPv6 PI!!!1" argument is bogus.) -- Shane From brc at zurich.ibm.com Mon May 14 13:34:31 2007 From: brc at zurich.ibm.com (Brian E Carpenter) Date: Mon, 14 May 2007 13:34:31 +0200 Subject: [address-policy-wg] Re: Can the RIRs bypass the IETF and do their own thing? In-Reply-To: References: Message-ID: <46484947.6090702@zurich.ibm.com> On 2007-05-11 23:32, JORDI PALET MARTINEZ wrote: > I've already indicated this in previous occasions, but may be not in ppml > ... > > We are proceeding in parallel, with the ID and the PDP at the same time. > Nothing in the PDP precludes doing so. > > The RIRs don't depend on IETF at all, they can define global policies for > things that the IETF failed to complete if that's the case. IANA can be > instructed the same by the RIRs (which a global policy) than by the IETF > itself with an RFC. Not quite. The RIRs have authority delegated to them by IANA, and IANA operates under the terms of its MoU and SLA with the IETF. So the RIRs' scope is to set and implement policy within their delegated authority, which itself has to be within the terms of the IANA MoU and SLA. In this case, I would check out section 4.3 of RFC 2860, especially the clause (b) in the second paragraph. It's clear to me that centrally- allocated ULAs are in IETF scope under that clause. That being said, there's no conceivable problem with a draft being developed by any set of people that want to do so, and the RIR people are obviously strongly motivated to do so in this case. (Personally, I see little need for it, since the existing pseudo-random ULAs are good enough for any practical purpose, but that is a discussion we can have in the IETF once there is a draft to discuss.) Brian From brc at zurich.ibm.com Mon May 14 13:39:00 2007 From: brc at zurich.ibm.com (Brian E Carpenter) Date: Mon, 14 May 2007 13:39:00 +0200 Subject: [address-policy-wg] Re: Can the RIRs bypass the IETF and do their own thing? In-Reply-To: <4BEE8CD2-4F61-41AA-B502-631E99411F15@cisco.com> References: <4BEE8CD2-4F61-41AA-B502-631E99411F15@cisco.com> Message-ID: <46484A54.6050806@zurich.ibm.com> On 2007-05-11 16:14, Fred Baker wrote: ... > One technical question I would ask. What does a "Central Authority" and > "IANA Assignment" have to do with a "Local" address of any type? It > seems in context that the major issue is an address prefix that is not > advertised to neighboring ISPs and can be generally configured to be > refused if offered by a neighboring ISP, in the same way that an RFC > 1918 address is not advertised and is generally refused between IPv4 > networks. In any draft on this topic, regardless of where it is > discussed, if central assignment is in view, the reason for having such > assignment should be clearly stated. Fred, the point is that ULAs should be unambiguous, so that if they happen to meet (e.g. via a VPN, or following a merge of two previously separate networks) there is no collision. Currently ULAs include a pseudo-random prefix, which leaves open a theoretical possibility of collision. Centrally-allocated ULAs would not have this issue. Brian From shane at time-travellers.org Mon May 14 16:08:19 2007 From: shane at time-travellers.org (Shane Kerr) Date: Mon, 14 May 2007 16:08:19 +0200 Subject: [address-policy-wg] Re: Can the RIRs bypass the IETF and do their own thing? In-Reply-To: <46484947.6090702@zurich.ibm.com> References: <46484947.6090702@zurich.ibm.com> Message-ID: <20070514140819.GA7563@borg.c-l-i.net> Brian, On Mon, May 14, 2007 at 01:34:31PM +0200, Brian E Carpenter wrote: > On 2007-05-11 23:32, JORDI PALET MARTINEZ wrote: > > > >The RIRs don't depend on IETF at all, they can define global > >policies for things that the IETF failed to complete if that's the > >case. IANA can be instructed the same by the RIRs (which a global > >policy) than by the IETF itself with an RFC. > > Not quite. The RIRs have authority delegated to them by IANA, and > IANA operates under the terms of its MoU and SLA with the IETF. So > the RIRs' scope is to set and implement policy within their > delegated authority, which itself has to be within the terms of the > IANA MoU and SLA. The RIRs authority comes from their communities, not from IANA. That's what "bottom-up" means. Many industries need a neutral organisation to do business. Airlines have a system to handle reservations. Many industries use the ISO to set standards (paint colour, carpet thickness, and so on). Universities have accreditation bodies to insure a certain quality of education. And so on. The ISPs of the world need someone to handle resource allocation. The RIRs do that. They also do a bunch of other stuff. Really, the RIRs' scope is whatever their communities think it should be. If the RIRs decide to allocate numbers from dead:beef::/32 based on lunar tides, then the IETF and IANA and ICANN can complain about it all day long, but it's not their decision to make. Of course they can participate in the policy making process like everyone else. :) -- Shane From Woeber at CC.UniVie.ac.at Mon May 14 16:14:17 2007 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Mon, 14 May 2007 14:14:17 +0000 Subject: [address-policy-wg] RE: [ppml] Can the RIRs bypass the IETF and do their own thing? In-Reply-To: References: Message-ID: <46486EB9.8040303@CC.UniVie.ac.at> Just on a technical side-note... michael.dillon at bt.com wrote: [...] > Hopefully, the v6ops list will look at other alternatives such as using > AS numbers to define a block of addresses Are there enough bits to earmark for that, in a regime of 32bit AS numbers? > similar to the way GLOP > defined multicast addressing in RFC 3180 > http://www.ietf.org/rfc/rfc3180.txt > > --Michael Dillon Wilfried. From gert at space.net Mon May 14 23:31:11 2007 From: gert at space.net (Gert Doering) Date: Mon, 14 May 2007 23:31:11 +0200 Subject: [address-policy-wg] Re: Can the RIRs bypass the IETF and do their own thing? In-Reply-To: <20070514140819.GA7563@borg.c-l-i.net> References: <46484947.6090702@zurich.ibm.com> <20070514140819.GA7563@borg.c-l-i.net> Message-ID: <20070514213111.GW73965@Space.Net> Hi, On Mon, May 14, 2007 at 04:08:19PM +0200, Shane Kerr wrote: > If the RIRs decide to allocate numbers from dead:beef::/32 based on > lunar tides, then the IETF and IANA and ICANN can complain about it > all day long, but it's not their decision to make. Of course they can > participate in the policy making process like everyone else. :) Well, technically you are correct - but given the way "The Internet" works, it works better if there is agreement on where the numbers come from, and how they are distributed in a way that makes them unique. So the RIRs *do* try to cooperate with ICANN/IANA and the IETF :-) And please let's *not* use the RIPE APWG mailinglist for a fundamental debate on whether the RIR model is all broken, the IETF is too slow to be useful, or whatever gripes you have - we need to focus the discussions somewhat, otherwise too many people will just stop working with us. [If you really feel that the RIPE model is all broken, by all means say so -- but please open a new mail thread for it, instead of shanghaiing a specific policy proposal discussion] Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 113403 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 gert at space.net Mon May 14 23:36:31 2007 From: gert at space.net (Gert Doering) Date: Mon, 14 May 2007 23:36:31 +0200 Subject: [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <5ACC8BD4-1ABC-4507-853E-7A5AD97C8496@delong.com> References: <5ACC8BD4-1ABC-4507-853E-7A5AD97C8496@delong.com> Message-ID: <20070514213631.GX73965@Space.Net> Hi On Fri, May 11, 2007 at 06:58:55AM -0700, Owen DeLong wrote: > >Do you think this should not be decided by an RFC, but rather as a > >global > >policy through each of the RIRs? > > > I am not sure. I kind of like Tony's (malformed) suggestion that ULA- > C should > come with PI. If the qualifications for ULA-C were the same, or, if > ULA-C was > only available to orgs. that had PI, I think that would be acceptable. I can't really understand the reasoning behind that. What are you trying to achieve, why do you want to restrict handing out ULA-C to only a specific (small) subset of folks out there? I'd take a much simpler approach - install a one-time setup fee, which will prevent folks from just grabbing 10000s of ULA-C prefixes, and then just hand them out to whoever wants some (and pays the handling fee). There's enough /48s in that /8 so that the risk of running out is really low - if there is some mechanism to limit the amount of prefixes a single entity can request. Money works well for that, usually. [..] > Not sure about that. I do support the idea of ULA-Central as intended, > but, I'd have to see a policy or RFC that implemented it in such a way > that I had reasonable confidence it wouldn't become "the easy way to > get PI". If we're going to do that, I'd rather do it by relaxing the > PI policy > than by designating some "nudge nudge wink wink" address space. ULA-C becomes PI the moment folks will accept it in their routing table (and if that is a serious risk, ULA-L could as easily become PI the same way). But why should routing folks do that? I, for one, hereby state that I will not route other folks ULA space on AS5539. Period. Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 113403 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 alh-ietf at tndh.net Tue May 15 02:28:42 2007 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 14 May 2007 17:28:42 -0700 Subject: [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <5ACC8BD4-1ABC-4507-853E-7A5AD97C8496@delong.com> References: <5ACC8BD4-1ABC-4507-853E-7A5AD97C8496@delong.com> Message-ID: <071201c79687$fddbf2b0$f993d810$@net> Owen DeLong wrote: > ...... > > If you prefer the RIR process, would you be in favor of a global > > policy > > submitted to ARIN that had the provisions of the expired ULA-central > > draft, with the modification of removing "cental authority" and > > clearly > > designating how IANA should divide the space among the existing RIRs? > > > Not sure about that. I do support the idea of ULA-Central as intended, > but, I'd have to see a policy or RFC that implemented it in such a way > that I had reasonable confidence it wouldn't become "the easy way to > get PI". If we're going to do that, I'd rather do it by relaxing the > PI policy > than by designating some "nudge nudge wink wink" address space. The 'central authority' was not intended to preclude the RIR's, just not impose something upon them they didn't want. The RIR's are member organizations that don't sell or lease address space, they manage a resource on behalf of the members. If you want long term membership to grow and/or sustain the costs of running the organization, then you need to offer a service that is attractive. ULA-C space is an attractive resource to many organizations that have been burned on 1918 mergers. If you don't want that to become an alternate PI space, then recognize that PI space is another attractive resource that would justify sustaining membership. Most of the potential members that would be interested in one of those would also be interested in the other, so create a policy that automatically allocates both to reduce internal costs for interacting with the paperwork & database. The noise about PI blowing out the routing system is just that, -noise-. If all ~20k AS entities came and demanded PI space we would have a whopping 20k routing entries in the IPv6 DFZ BGP mesh. At 1/10th the IPv4 table, and basically stable vs. growing at a compound rate, that is not even noticeable. Tony From alh-ietf at tndh.net Tue May 15 02:28:47 2007 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 14 May 2007 17:28:47 -0700 Subject: [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <20070514053040.GA18747@vacation.karoshi.com.> References: <20070514053040.GA18747@vacation.karoshi.com.> Message-ID: <071301c79688$012662c0$03732840$@net> bmanning at karoshi.com wrote: > > ULA-central is NOT intended to be uses as IPv6 PI. > > but there is no way to stop it from becoming so. The only effective way to stop it is to make PI have a lower cost than ULA-C. The most straight forward way to implement that is; at the RIR policy level acknowledge that PI will exist and create the appropriate mechanisms to manage it; at the ISP level, recognize that PI is available and refuse (set exorbitant fees) to route ULA-C. Trying to stop something that is outside the RIR policy control through RIR policy is a waste of time and energy. Recognize that whatever you do PI will exist in some form, and avoid the situation where it is completely unmanageable by creating a formal process where it is easy enough to get that people won't bother with working around you. If you want something to be contained and managed then step up and manage it. Trying to abolish it will only ensure that it exists outside the realm of manageability. Tony From alh-ietf at tndh.net Tue May 15 02:42:47 2007 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 14 May 2007 17:42:47 -0700 Subject: [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <20070514213631.GX73965@Space.Net> References: <5ACC8BD4-1ABC-4507-853E-7A5AD97C8496@delong.com> <20070514213631.GX73965@Space.Net> Message-ID: <071d01c79689$f5f99910$e1eccb30$@net> Gert Doering wrote: > ... > I'd take a much simpler approach - install a one-time setup fee, which > will prevent folks from just grabbing 10000s of ULA-C prefixes, and then > just hand them out to whoever wants some (and pays the handling fee). A registration fee is a one-time event. RIR membership is ongoing and provides a way to know what is active. I doubt there would ever be need to reclaim/reuse any of the allocations, but this is an attractive resource, use it as such to provide a reason to be an RIR member. > ... > ULA-C becomes PI the moment folks will accept it in their routing table > (and if that is a serious risk, ULA-L could as easily become PI the same > way). But why should routing folks do that? PI will exist in whatever form it has to. If that means punching holes in PA space, then it will be that. Rather than trying to prevent the unpreventable through a disassociated policy, grab it and manage it. Create PI that is managed. If that exists in an easy to get form, the ULA-C discussion is moot because it will cost more to convince an ISP to route it than to just get recognized PI space. > > I, for one, hereby state that I will not route other folks ULA space > on AS5539. Period. > That is a fine position to take, but that is only one of ~20k AS's. Create a managed PI space, & ULA-C space, then the intended state will be easy for ISPs to enforce. Without both, unmanaged versions of both will be created and create confusion down the road. Tony From Woeber at CC.UniVie.ac.at Tue May 15 09:24:42 2007 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 15 May 2007 07:24:42 +0000 Subject: [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <071201c79687$fddbf2b0$f993d810$@net> References: <5ACC8BD4-1ABC-4507-853E-7A5AD97C8496@delong.com> <071201c79687$fddbf2b0$f993d810$@net> Message-ID: <4649603A.3020100@CC.UniVie.ac.at> Tony Hain wrote: > Owen DeLong wrote: > >>...... [...] > > The noise about PI blowing out the routing system is just that, -noise-. If > all ~20k AS entities came and demanded PI space we would have a whopping 20k > routing entries in the IPv6 DFZ BGP mesh. At 1/10th the IPv4 table, and > basically stable vs. growing at a compound rate, that is not even > noticeable. I have long since stopped listening to *that* "-noise-" as you put it. > Tony I am prepared to start listening again as soon as the "Gain"-figures in the CIDR report start to change dramatically: --- 11May07 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 217147 140280 76867 35.4% All ASes Wilfried. From gert at space.net Tue May 15 09:31:04 2007 From: gert at space.net (Gert Doering) Date: Tue, 15 May 2007 09:31:04 +0200 Subject: [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <071d01c79689$f5f99910$e1eccb30$@net> References: <5ACC8BD4-1ABC-4507-853E-7A5AD97C8496@delong.com> <20070514213631.GX73965@Space.Net> <071d01c79689$f5f99910$e1eccb30$@net> Message-ID: <20070515073104.GY73965@Space.Net> Hi, On Mon, May 14, 2007 at 05:42:47PM -0700, Tony Hain wrote: > PI will exist in whatever form it has to. If that means punching holes in PA > space, then it will be that. Rather than trying to prevent the unpreventable > through a disassociated policy, grab it and manage it. Create PI that is > managed. If that exists in an easy to get form, the ULA-C discussion is moot > because it will cost more to convince an ISP to route it than to just get > recognized PI space. Thanks for these thoughts. Wearing the APWG chair hat, I encourage people to think through this, in the light of the open policy proposals (for IPv6 PI, and for ULA-Central), and give us their feedback accordingly. Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 113403 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: 305 bytes Desc: not available URL: From jordi.palet at consulintel.es Tue May 15 09:57:06 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Tue, 15 May 2007 09:57:06 +0200 Subject: [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <071301c79688$012662c0$03732840$@net> Message-ID: And the only way to control ULA-central is to have it within the RIR system, instead of waiting for IETF to move ahead the document and doing themselves or thru and alternative third party organization. So having a "managed" path for ULA-central is in our hands. Regards, Jordi > De: Tony Hain > Responder a: > Fecha: Mon, 14 May 2007 17:28:47 -0700 > Para: , 'JORDI PALET MARTINEZ' > > CC: , > Asunto: RE: [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs > NAT in arstechnica (seen on slashdot) > > bmanning at karoshi.com wrote: > >>> ULA-central is NOT intended to be uses as IPv6 PI. >> >> but there is no way to stop it from becoming so. > > The only effective way to stop it is to make PI have a lower cost than > ULA-C. The most straight forward way to implement that is; at the RIR policy > level acknowledge that PI will exist and create the appropriate mechanisms > to manage it; at the ISP level, recognize that PI is available and refuse > (set exorbitant fees) to route ULA-C. > > Trying to stop something that is outside the RIR policy control through RIR > policy is a waste of time and energy. Recognize that whatever you do PI will > exist in some form, and avoid the situation where it is completely > unmanageable by creating a formal process where it is easy enough to get > that people won't bother with working around you. If you want something to > be contained and managed then step up and manage it. Trying to abolish it > will only ensure that it exists outside the realm of manageability. > > Tony > > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From nick-lists at netability.ie Mon May 14 14:30:01 2007 From: nick-lists at netability.ie (Nick Hilliard) Date: Mon, 14 May 2007 13:30:01 +0100 Subject: [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <20070514053040.GA18747@vacation.karoshi.com.> References: <20070514053040.GA18747@vacation.karoshi.com.> Message-ID: <46485649.6090408@netability.ie> bmanning at karoshi.com wrote: >> ULA-central is NOT intended to be uses as IPv6 PI. > > but there is no way to stop it from becoming so. Other than by issuing bogon lists, where the ULA-centra prefixes will be noted. You certainly can't stop it or any other type of ipv6 address from becoming PI. But you can stop it from being useful PI space, which is all you need to do. Nick From stephen at sprunk.org Mon May 14 14:45:41 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 14 May 2007 07:45:41 -0500 Subject: [address-policy-wg] Re: Can the RIRs bypass the IETF and do their own thing? References: <4BEE8CD2-4F61-41AA-B502-631E99411F15@cisco.com> <46484A54.6050806@zurich.ibm.com> Message-ID: <007c01c7962b$0d61c5a0$463816ac@atlanta.polycom.com> Thus spake "Brian E Carpenter" > Fred, the point is that ULAs should be unambiguous, so that if they > happen to meet (e.g. via a VPN, or following a merge of two previously > separate networks) there is no collision. Currently ULAs include > a pseudo-random prefix, which leaves open a theoretical possibility > of collision. Centrally-allocated ULAs would not have this issue. The chance is negligible until you have a number of organizations interconnecting that approaches the AS count on the public Internet. Those who are uncomfortable with those odds can get PIv6 space. ULA Central does not solve any problems that the existing tools already solve, and it creates new problems of its own. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From stephen at sprunk.org Mon May 14 16:24:19 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 14 May 2007 09:24:19 -0500 Subject: [address-policy-wg] Re: [ppml] Can the RIRs bypass the IETF and do their own thing? References: <4BEE8CD2-4F61-41AA-B502-631E99411F15@cisco.com><46484A54.6050806@zurich.ibm.com> <007c01c7962b$0d61c5a0$463816ac@atlanta.polycom.com> Message-ID: <00dc01c79634$21010810$463816ac@atlanta.polycom.com> Thus spake "Stephen Sprunk" > ULA Central does not solve any problems that the existing tools > already solve, and it creates new problems of its own. That should be "don't already solve". S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From brc at zurich.ibm.com Mon May 14 16:40:50 2007 From: brc at zurich.ibm.com (Brian E Carpenter) Date: Mon, 14 May 2007 16:40:50 +0200 Subject: [address-policy-wg] Re: Can the RIRs bypass the IETF and do their own thing? In-Reply-To: <20070514140819.GA7563@borg.c-l-i.net> References: <46484947.6090702@zurich.ibm.com> <20070514140819.GA7563@borg.c-l-i.net> Message-ID: <464874F2.5030504@zurich.ibm.com> On 2007-05-14 16:08, Shane Kerr wrote: > Brian, > > On Mon, May 14, 2007 at 01:34:31PM +0200, Brian E Carpenter wrote: >> On 2007-05-11 23:32, JORDI PALET MARTINEZ wrote: >>> The RIRs don't depend on IETF at all, they can define global >>> policies for things that the IETF failed to complete if that's the >>> case. IANA can be instructed the same by the RIRs (which a global >>> policy) than by the IETF itself with an RFC. >> Not quite. The RIRs have authority delegated to them by IANA, and >> IANA operates under the terms of its MoU and SLA with the IETF. So >> the RIRs' scope is to set and implement policy within their >> delegated authority, which itself has to be within the terms of the >> IANA MoU and SLA. > > The RIRs authority comes from their communities, not from IANA. > That's what "bottom-up" means. We're both right. It works because there is a wide consensus to both listen to the community and respect the mechanisms in place. Brian From dean at av8.com Mon May 14 21:04:19 2007 From: dean at av8.com (Dean Anderson) Date: Mon, 14 May 2007 15:04:19 -0400 (EDT) Subject: [address-policy-wg] Re: Can the RIRs bypass the IETF and do their own thing? In-Reply-To: <46484947.6090702@zurich.ibm.com> Message-ID: > Not quite. The RIRs have authority delegated to them by IANA, and IANA > operates under the terms of its MoU and SLA with the IETF. So the RIRs' > scope is to set and implement policy within their delegated authority, > which itself has to be within the terms of the IANA MoU and SLA. I looked into this some time ago, and found that the U.S. Department of Commerce delegated authority to ICANN, and that ICANN delegated to the RIRs. According to IANA, IANA is just the bookkeeper, and is run by ICANN under contract with the U.S. Government: According documents at http://www.icann.org/general/agreements.htm ICANN contracted with the U.S. Government to handle the IANA function. According to one MoU, the IETF "appointed" ICANN to perform IANA functions, however, there seems to be no authority for IETF to make such a delegation. This MoU is just a notice that the IETF concurs with the award of the U.S. Goverment contract. Using the word "appointed" doesn't mean the IETF has any actual authority to make appointments or to appoint someone else. I note that the IANA physical address is the same as ICANN: Internet Assigned Numbers Authority 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 USA +1-310-823-9358 (phone) +1-310-823-8649 (facsimile) The agreements that I've found with ICANN, e.g. http://www.icann.org/general/ietf-iana-agreement-v8.htm place the IETF as a technical collaborator to assist ICANN with the IANA function. The IETF provides technical experts to the ICANN/IANA. The IETF is just a technical consultant on IANA functions. Administative authority over RIRs resides in ICANN, and above ICANN, the U.S. Government. ICANN can end the MoU at any time, and find a new technical consultant. The IETF can also end the MoU at any time. But the IETF doesn't have the authority to appoint a new IANA operator. > In this case, I would check out section 4.3 of RFC 2860, especially > the clause (b) in the second paragraph. It's clear to me that centrally- > allocated ULAs are in IETF scope under that clause. Nothing in these MoUs supercede the U.S. Government contracts and agreements that delegate the actual final authority. Also, RFC2860 is superceded by the January 2007 MoU that I cited above. The authority goes top down: US Government ICANN RIRs The RIR's can do whatever ICANN and the US Government allow them to do. The IETF _can_ be taken out of the picture if there is cause to do so. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From owen at delong.com Tue May 15 00:47:28 2007 From: owen at delong.com (Owen DeLong) Date: Mon, 14 May 2007 15:47:28 -0700 Subject: [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <20070514213631.GX73965@Space.Net> References: <5ACC8BD4-1ABC-4507-853E-7A5AD97C8496@delong.com> <20070514213631.GX73965@Space.Net> Message-ID: On May 14, 2007, at 2:36 PM, Gert Doering wrote: > Hi > > On Fri, May 11, 2007 at 06:58:55AM -0700, Owen DeLong wrote: >>> Do you think this should not be decided by an RFC, but rather as a >>> global >>> policy through each of the RIRs? >>> >> I am not sure. I kind of like Tony's (malformed) suggestion that >> ULA- >> C should >> come with PI. If the qualifications for ULA-C were the same, or, if >> ULA-C was >> only available to orgs. that had PI, I think that would be >> acceptable. > > I can't really understand the reasoning behind that. What are you > trying to achieve, why do you want to restrict handing out ULA-C to > only a specific (small) subset of folks out there? > I don't want to give ULA-C to people who have an incentive to abuse it as PI. > I'd take a much simpler approach - install a one-time setup fee, which > will prevent folks from just grabbing 10000s of ULA-C prefixes, and > then > just hand them out to whoever wants some (and pays the handling fee). > I specifically don't want to achieve the suggested objective and would strongly oppose such an action. > There's enough /48s in that /8 so that the risk of running out is > really low - if there is some mechanism to limit the amount of > prefixes > a single entity can request. Money works well for that, usually. > I don't care about running out. I care about less stringent standards in ULA criteria being used to create an end-run on PI policy. > [..] >> Not sure about that. I do support the idea of ULA-Central as >> intended, >> but, I'd have to see a policy or RFC that implemented it in such a >> way >> that I had reasonable confidence it wouldn't become "the easy way to >> get PI". If we're going to do that, I'd rather do it by relaxing the >> PI policy >> than by designating some "nudge nudge wink wink" address space. > > ULA-C becomes PI the moment folks will accept it in their routing > table > (and if that is a serious risk, ULA-L could as easily become PI the > same > way). But why should routing folks do that? > Hopefully routing folks won't, but, in my experience, $$$ can lead routing folks to ignore what should or shouldn't be done from an internet context and, instead, focus on what makes money. I agree that ULA-L is a bad idea for all the same reasons. However, there is nothing which can be done about ULA-L at the RIR policy level. At the RIR Policy level, ULA-C can be addressed, at least for the moment. > I, for one, hereby state that I will not route other folks ULA space > on AS5539. Period. > Good for you. If you can get everyone else with an AS to make the same promise in writing and make that promise binding on their successors and assigns, then, we might have something. Owen > Gert Doering > -- APWG chair > -- > Total number of prefixes smaller than registry allocations: 113403 > > 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: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From gert at space.net Tue May 15 10:39:42 2007 From: gert at space.net (Gert Doering) Date: Tue, 15 May 2007 10:39:42 +0200 Subject: [address-policy-wg] Re: Can the RIRs bypass the IETF and do their own thing? In-Reply-To: References: <46484947.6090702@zurich.ibm.com> Message-ID: <20070515083942.GA73965@Space.Net> Hi, On Mon, May 14, 2007 at 03:04:19PM -0400, Dean Anderson wrote: [..] > ICANN can end the MoU at any time, and find a new technical consultant. > The IETF can also end the MoU at any time. But the IETF doesn't have the > authority to appoint a new IANA operator. [..] > The RIR's can do whatever ICANN and the US Government allow them to do. > The IETF _can_ be taken out of the picture if there is cause to do so. Not quite. If ICANN decides "we won't listen to IETF anymore", or "we try to inforce non-useful politics to the RIRs" there is no big reason why the RIRs couldn't just kick ICANN, install the NRO in its place, and change the structure to IETF -> NRO -> RIRs Remember: the existing mechanism works, because the communities (!!) agree that it's a useful way to handle address distribution. The US DoC might have some say for ARIN, but the rest of the world couldn't care less - and I'm sure that the DoC is well aware of this and won't try to break apart working structures. So this is all sort of academic. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 113403 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 plzak at arin.net Tue May 15 11:15:24 2007 From: plzak at arin.net (Ray Plzak) Date: Tue, 15 May 2007 05:15:24 -0400 Subject: [address-policy-wg] Re: Can the RIRs bypass the IETF and do their own thing? In-Reply-To: <20070515083942.GA73965@Space.Net> References: <46484947.6090702@zurich.ibm.com> <20070515083942.GA73965@Space.Net> Message-ID: The US DoC has as much say for ARIN as it does for the RIPE NCC. The RIRs existed before ICANN. The relationship between the RIRs and ICANN is defined in the ASO MoU, an agreement between ICANN on the one hand and the NRO on behalf of the RIRs on the other. There is no mention in the ICANN bylaws of the RIRs. Ray > -----Original Message----- > From: Gert Doering [mailto:gert at space.net] > Sent: Tuesday, May 15, 2007 4:40 AM > To: Dean Anderson > Cc: ppml at arin.net; address-policy-wg at ripe.net; > jordi.palet at consulintel.es; ietf at ietf.org > Subject: Re: [address-policy-wg] Re: Can the RIRs bypass the IETF and > do their own thing? > > Hi, > > On Mon, May 14, 2007 at 03:04:19PM -0400, Dean Anderson wrote: > [..] > > ICANN can end the MoU at any time, and find a new technical > consultant. > > The IETF can also end the MoU at any time. But the IETF doesn't have > the > > authority to appoint a new IANA operator. > [..] > > The RIR's can do whatever ICANN and the US Government allow them to > do. > > The IETF _can_ be taken out of the picture if there is cause to do > so. > > Not quite. If ICANN decides "we won't listen to IETF anymore", or "we > try to inforce non-useful politics to the RIRs" there is no big reason > why the RIRs couldn't just kick ICANN, install the NRO in its place, > and > change the structure to > > IETF -> NRO -> RIRs > > Remember: the existing mechanism works, because the communities (!!) > agree > that it's a useful way to handle address distribution. > > The US DoC might have some say for ARIN, but the rest of the world > couldn't care less - and I'm sure that the DoC is well aware of this > and > won't try to break apart working structures. > > So this is all sort of academic. > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: 113403 > > 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 > > _______________________________________________ > Ietf mailing list > Ietf at ietf.org > https://www1.ietf.org/mailman/listinfo/ietf From bmanning at karoshi.com Tue May 15 11:34:48 2007 From: bmanning at karoshi.com (bmanning at karoshi.com) Date: Tue, 15 May 2007 09:34:48 +0000 Subject: [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <46485649.6090408@netability.ie> References: <20070514053040.GA18747@vacation.karoshi.com.> <46485649.6090408@netability.ie> Message-ID: <20070515093448.GA28881@vacation.karoshi.com.> On Mon, May 14, 2007 at 01:30:01PM +0100, Nick Hilliard wrote: > bmanning at karoshi.com wrote: > >>ULA-central is NOT intended to be uses as IPv6 PI. > > > > but there is no way to stop it from becoming so. > > Other than by issuing bogon lists, where the ULA-centra prefixes will be > noted. You certainly can't stop it or any other type of ipv6 address > from becoming PI. But you can stop it from being useful PI space, which > is all you need to do. > > Nick you, my friend, have an over inflated view of your ability to effect "useful" for others. imho of course. --bill From bmanning at karoshi.com Tue May 15 12:05:35 2007 From: bmanning at karoshi.com (bmanning at karoshi.com) Date: Tue, 15 May 2007 10:05:35 +0000 Subject: [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <464981B0.2040303@inex.ie> References: <20070514053040.GA18747@vacation.karoshi.com.> <46485649.6090408@netability.ie> <20070515093448.GA28881@vacation.karoshi.com.> <464981B0.2040303@inex.ie> Message-ID: <20070515100535.GB28881@vacation.karoshi.com.> On Tue, May 15, 2007 at 10:47:28AM +0100, Nick Hilliard wrote: > bmanning at karoshi.com wrote: > >On Mon, May 14, 2007 at 01:30:01PM +0100, Nick Hilliard wrote: > >>Other than by issuing bogon lists, where the ULA-centra prefixes will > >>be noted. You certainly can't stop it or any other type of ipv6 > >>address from becoming PI. But you can stop it from being useful PI > >>space, which is all you need to do. > >> > >>Nick > > > > you, my friend, have an over inflated view of your ability > > to effect "useful" for others. imho of course. > > I make no claim of any such ability :-) er... perhaps I misread. you stated; "you can stop it from being useful PI space, which is all you need to do." i understand this as you (party Q) being able to effect any communications between myself (party R) and Gert (party S)... the single time this is effective is when party Q is in the transit path btwn R & S. > > The point is, if a block is carved out and marked specifically as being > non-routable on the public v6 internet, it will have degraded > connectivity to some degree or other. do i care? does that effect the usefulness of a given prefix if some ISP someplace filters out (refuses to listen) to the announcements? i posit that: a) i have zero influence on your operational behaviour when i have zero business relationship w/ you b) you have the ability to set whatever policies you like for packet acceptance into your network and packet egress from your network. > > On a related issue, I'd be interested to know what the reachability > degradation was like for the last of the 3ffe:: space after 6/6/6? You > didn't happen to do any measurements on it? for those parties still using the space, it is useful. i suspect that parties who filter prefixes "degrade" their clients ability to reach nodes/content in those filtered ranges. of course some clients utilize other tools (VPNs, tunnels, etc) to bypass crippled ISP thinking. (from the POV of the client ... kind of like many hotel networks) your general qustion (prefix reachability) is based on (imho again) a flawed premise... if i may, could you clarify the two endpoints for such a reachability study? > > Nick, > psychically effecting usefulness all over the v6 internet got me there... can you also bend spoons w/ your mental powers? :) --bill From heldal at eml.cc Tue May 15 12:30:03 2007 From: heldal at eml.cc (Per Heldal) Date: Tue, 15 May 2007 12:30:03 +0200 Subject: [ppml] [address-policy-wg] Re: article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <20070514053040.GA18747@vacation.karoshi.com.> References: <20070514053040.GA18747@vacation.karoshi.com.> Message-ID: <1179225003.4778.19.camel@localhost.localdomain> On Mon, 2007-05-14 at 05:30 +0000, bmanning at karoshi.com wrote: > > > > ULA-central is NOT intended to be uses as IPv6 PI. > > but there is no way to stop it from becoming so. What makes that different from any other randomly selected block of addresses if you don't apply some form of filter? The current routing-architecture applied to v6 will blow up in our face sooner or later without improved mechanisms to prevent excessive de-aggregation and unauthorised use of unallocated blocks. I'm no fan of private addressing, but it doesn't seem awfully hard to include the handling of ULA-central in such a solution. //per From gert at space.net Tue May 15 13:24:53 2007 From: gert at space.net (Gert Doering) Date: Tue, 15 May 2007 13:24:53 +0200 Subject: Fwd: [address-policy-wg] 2007-02 New Policy Proposal (Change in IP Assignments for Anycasting DNS Policy) In-Reply-To: References: <20070425145205.GQ73965@Space.Net> <5FCDC1C5A3A941E7852005C718E619B5@tungemaskin> <20070425150837.GU73965@Space.Net> <616812070705090548r12ece1bar7c877f709249cefd@mail.gmail.com> <616812070705090611u7422e2ddj87731b031f2162ec@mail.gmail.com> <4641CE25.6040508@spaghetti.zurich.ibm.com> <4641D280.1020104@spaghetti.zurich.ibm.com> <20070510075004.GA6355@lain.intern.internetx.de> Message-ID: <20070515112453.GF73965@Space.Net> Hi, On Thu, May 10, 2007 at 10:09:26AM +0100, michael.dillon at bt.com wrote: > Why should address policy be so tightly tied to the technical details of > the DNS protocol and its implementation? Just for the records: because this policy is an exeption to the normal rules - and an exception made for a very specific community (DNS TLD Ops) that made a good point for it. If the normal rules permitted anybody to get a /24 IPv4 PI and an IPv6 PI block (which might happen over time, we can't know yet), then we need no exception to the rule. As of now, neither is easily available in RIPE land, and thus a special case policy was made. (As for all the arguments going back and forth regarding the *existing* policy, please don't rehash them here - just go to the mailing list archives. Everything has been said before). So there's actually just two thing that we want to decide *now*: - do we want to change the rules for this specific policy to apply to other entities as well? - if yes, what shall the new rules be? The rules should always aim to - solve the problem (so it would be helpful if organizations that are *not* a TLD operator but would want to do an externally-visible anycast setup to speak up, say what they are doing, and why it can't be done using the standard way to build nameserver redundancy "just put up a good number of them") - be easy to evaluate by the RIPE NCC Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 113403 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 gert at space.net Tue May 15 13:29:13 2007 From: gert at space.net (Gert Doering) Date: Tue, 15 May 2007 13:29:13 +0200 Subject: Fwd: [address-policy-wg] 2007-02 New Policy Proposal (Change in IP Assignments for Anycasting DNS Policy) In-Reply-To: References: <20070425150837.GU73965@Space.Net> <616812070705090548r12ece1bar7c877f709249cefd@mail.gmail.com> <616812070705090611u7422e2ddj87731b031f2162ec@mail.gmail.com> <4641CE25.6040508@spaghetti.zurich.ibm.com> <4641D280.1020104@spaghetti.zurich.ibm.com> <20070510075004.GA6355@lain.intern.internetx.de> <20070510094506.GA10986@lain.intern.internetx.de> Message-ID: <20070515112913.GG73965@Space.Net> Hi, On Thu, May 10, 2007 at 12:25:03PM +0100, michael.dillon at bt.com wrote: > In any case, RIPE shouldn't tell people what to > do, just make it possible for people to do things. I want to remind the readers that there is no evil conspiracy called "RIPE", but that *you* are part of RIPE, as well as I am, and everybody else in RIPE land. Policy is made by community consensus - and if the community wants to be restrictive, those that do see a specific need are always welcome to come forward and present their case. Argueing that "someone else might want to do this!!!" even if nobody every showed up and said so isn't going to bring us forward (we had this discussion already last time this policy was under discussion, and nobody was able to present a case for working non-DNS wide-area anycast) Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 113403 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 gert at space.net Tue May 15 13:33:35 2007 From: gert at space.net (Gert Doering) Date: Tue, 15 May 2007 13:33:35 +0200 Subject: Fwd: [address-policy-wg] 2007-02 New Policy Proposal (Change in IP Assignments for Anycasting DNS Policy) In-Reply-To: <9E5B4F5391BB486AAA63721D3F29268B@tungemaskin> References: <20070425150837.GU73965@Space.Net> <616812070705090548r12ece1bar7c877f709249cefd@mail.gmail.com> <616812070705090611u7422e2ddj87731b031f2162ec@mail.gmail.com> <4641CE25.6040508@spaghetti.zurich.ibm.com> <4641D280.1020104@spaghetti.zurich.ibm.com> <20070510075004.GA6355@lain.intern.internetx.de> <4642F9EB.5090908@cw.net> <9E5B4F5391BB486AAA63721D3F29268B@tungemaskin> Message-ID: <20070515113335.GH73965@Space.Net> Hi, On Thu, May 10, 2007 at 01:28:02PM +0200, J?rgen Hovland wrote: > This depends on the definition. > If a network announce their /16 prefix world-wide and decide to > assign a customer a /29 for the use of anycast, they are entirely > free to do so. The internal routing for the /29 within this network > obviously needs to be configured for anycast use directed to the > closest of the 15 different datacenters. The /29 is of course not > announced to dfz, only the aggregate /16 is. Indeed, this could be a workable solution for entities that already operate a large network, and would want to have all of the anycast nodes inside their network ("under their direct control"). In that case, we don't need anything special policywise, as the whole anycast setup would not be visible in the global routing system, and we don't need special prefixes, etc. etc. This isn't possible for most of the TLD operators (as they do not have a large network, usually, but host their boxes at other networks, IXPs, etc.) - but it might be a workable approach for service providers that just want to provide reliable DNS service, and do not want/need an external routing table slot. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 113403 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 Tue May 15 13:45:53 2007 From: slz at baycix.de (Sascha Lenz) Date: Tue, 15 May 2007 13:45:53 +0200 Subject: Fwd: [address-policy-wg] 2007-02 New Policy Proposal (Change in IP Assignments for Anycasting DNS Policy) In-Reply-To: <20070515112453.GF73965@Space.Net> References: <20070425145205.GQ73965@Space.Net> <5FCDC1C5A3A941E7852005C718E619B5@tungemaskin> <20070425150837.GU73965@Space.Net> <616812070705090548r12ece1bar7c877f709249cefd@mail.gmail.com> <616812070705090611u7422e2ddj87731b031f2162ec@mail.gmail.com> <4641CE25.6040508@spaghetti.zurich.ibm.com> <4641D280.1020104@spaghetti.zurich.ibm.com> <20070510075004.GA6355@lain.intern.internetx.de> <20070515112453.GF73965@Space.Net> Message-ID: <46499D71.3060405@baycix.de> Hi, Gert Doering wrote: > Hi, [...] > So there's actually just two thing that we want to decide *now*: > > - do we want to change the rules for this specific policy to apply to > other entities as well? basically, yes. Anycast is a nice technology, works great for DNS and i don't like being hindered to deploy new technologies by outdated policies that much in general (even that i don't have any personal interest in DNS Anycast on the public internet atm.) What i'm not sure about is other-than-DNS Anycast usage. If anyone can come up with nice examples.... fine. Otherwise i would - for now - only deal with DNS-Anycast in any new/changed policy, and probably look into that issue again if there are clear ideas for other Anycast setups (on the public Internet). (That one is aimed towards those who would like to expand the policy change to anything beyond DNS...) > - if yes, what shall the new rules be? Always a good qustion - which i don't have much clue about since i never felt the need for DNS anycast (yet). As an outsider here, i'd rather like to have a not-so-strict policy/rules about that on a first glance. I probably want to be able to anycast my own small nameservers just for the fun of it sometimes - "i don't get Anycast Addresses due to anycast policy issues? Ok then i will just use some PI/Unspecific for that" ... (i guess you all get the idea of what i want to point out with that fictional statement). But i'm not familiar with DNS Setups which would require/benefit from anycast, so i'm really out of ideas about possible boundaries for a yes or no. > The rules should always aim to > > - solve the problem (so it would be helpful if organizations that are *not* > a TLD operator but would want to do an externally-visible anycast setup > to speak up, say what they are doing, and why it can't be done using > the standard way to build nameserver redundancy "just put up a good > number of them") > > - be easy to evaluate by the RIPE NCC I'd like to see some real-life ideas about WHY an entity wants to use DNS anycast here, too. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From nick at inex.ie Tue May 15 13:47:09 2007 From: nick at inex.ie (Nick Hilliard) Date: Tue, 15 May 2007 12:47:09 +0100 Subject: [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <20070515100535.GB28881@vacation.karoshi.com.> References: <20070514053040.GA18747@vacation.karoshi.com.> <46485649.6090408@netability.ie> <20070515093448.GA28881@vacation.karoshi.com.> <464981B0.2040303@inex.ie> <20070515100535.GB28881@vacation.karoshi.com.> Message-ID: <46499DBD.6080301@inex.ie> bmanning at karoshi.com wrote: > er... perhaps I misread. you stated; "you can stop it from > being useful PI space, which is all you need to do." > i understand this as you (party Q) being able to effect any > communications between myself (party R) and Gert (party S)... > the single time this is effective is when party Q is in the > transit path btwn R & S. "you" == RIRs/whoever publishing these blocks in a list of prefixes which should not be seen on the public ipv6 internet, due to community mandate. Well, we can talk about individual scenarios but let's not, because there's no problem cooking up situations where ULA-central could have some conceivable merit, in terms of regular reachability between two arbitrary parties on the public v6 internet, although I can't really think of any case where it would be more useful than, say regular PI or PA. Before abandoning this thought, consider: - do you want to base your bilateral communications and possibly your business on an something which is frankly unsupported as designed and could stop working at any stage if operator Q were to implement uncontroversial prefix filters? - do you want to go beyond communications between R and S? Prove the point, Bill. Go ahead and advertise 10/8 and use it in anger on the public ipv4 internet. When you've got some good figures which indicate how useful it is, let us know. >> The point is, if a block is carved out and marked specifically as being >> non-routable on the public v6 internet, it will have degraded >> connectivity to some degree or other. > > do i care? Given your position on announcing 3ffe::/24 and 3ffe:800::/24 until fairly recently, evidently not :-) > does that effect the usefulness of a given prefix > if some ISP someplace filters out (refuses to listen) to the > announcements? i posit that: > a) i have zero influence on your operational behaviour > when i have zero business relationship w/ you > b) you have the ability to set whatever policies you like > for packet acceptance into your network and packet > egress from your network. No argument there. But we're talking about different things. So far, you're talking about connectivity between exactly two specific parties. I'm not. >> On a related issue, I'd be interested to know what the reachability >> degradation was like for the last of the 3ffe:: space after 6/6/6? You >> didn't happen to do any measurements on it? > > your general qustion (prefix reachability) is based on (imho again) > a flawed premise... if i may, could you clarify the two endpoints for > such a reachability study? I was thinking more of X = time, Y = % of ipv6 space reachable from ${3ffe}, where 100% at a particular timepoint would be # of reachable prefixes from some place known to be relatively well connected (cue flames for fuzzy specification). Given your reaction to the question, it sounds like you haven't done looked into this, which is a minor pity. Nick, bill's friend(tm) From gert at space.net Tue May 15 14:18:39 2007 From: gert at space.net (Gert Doering) Date: Tue, 15 May 2007 14:18:39 +0200 Subject: Fwd: [address-policy-wg] 2007-02 New Policy Proposal (Change in IP Assignments for Anycasting DNS Policy) In-Reply-To: <46499D71.3060405@baycix.de> References: <20070425150837.GU73965@Space.Net> <616812070705090548r12ece1bar7c877f709249cefd@mail.gmail.com> <616812070705090611u7422e2ddj87731b031f2162ec@mail.gmail.com> <4641CE25.6040508@spaghetti.zurich.ibm.com> <4641D280.1020104@spaghetti.zurich.ibm.com> <20070510075004.GA6355@lain.intern.internetx.de> <20070515112453.GF73965@Space.Net> <46499D71.3060405@baycix.de> Message-ID: <20070515121839.GI73965@Space.Net> Hi, On Tue, May 15, 2007 at 01:45:53PM +0200, Sascha Lenz wrote: > I'd like to see some real-life ideas about WHY an entity wants to use > DNS anycast here, too. Well, for the original proposal, the reasoning was about this: - entity wants to deploy a LARGE number of nameservers for a given zone - the way DNS works limits the amount of NS records that can be returned by the parent - if more nameservers are to be deployed, they must "share an NS record" (sort of) -> anycast. - ("the DNS WG says that anycast is a useful approach", and they are the DNS experts, so it's not us to argue this statement) - added benefits are indeed "bring servers closer to the clients" (improve latency) and "DDoS spread" (DDoS usually hits not all of the instances, so lots of users are not affected at all) the last argument is hard to bring into a policy (because it's hard for the NCC to evaluate) - the first argument is a hard technical fact, and as such, can be measured, counted, and used for a decision. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 113403 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: 305 bytes Desc: not available URL: From nick at inex.ie Tue May 15 11:47:28 2007 From: nick at inex.ie (Nick Hilliard) Date: Tue, 15 May 2007 10:47:28 +0100 Subject: [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <20070515093448.GA28881@vacation.karoshi.com.> References: <20070514053040.GA18747@vacation.karoshi.com.> <46485649.6090408@netability.ie> <20070515093448.GA28881@vacation.karoshi.com.> Message-ID: <464981B0.2040303@inex.ie> bmanning at karoshi.com wrote: >On Mon, May 14, 2007 at 01:30:01PM +0100, Nick Hilliard wrote: >> Other than by issuing bogon lists, where the ULA-centra prefixes will be >> noted. You certainly can't stop it or any other type of ipv6 address >> from becoming PI. But you can stop it from being useful PI space, which >> is all you need to do. >> >> Nick > > you, my friend, have an over inflated view of your ability > to effect "useful" for others. imho of course. I make no claim of any such ability :-) The point is, if a block is carved out and marked specifically as being non-routable on the public v6 internet, it will have degraded connectivity to some degree or other. On a related issue, I'd be interested to know what the reachability degradation was like for the last of the 3ffe:: space after 6/6/6? You didn't happen to do any measurements on it? Nick, psychically effecting usefulness all over the v6 internet From plzak at arin.net Tue May 15 19:22:59 2007 From: plzak at arin.net (Ray Plzak) Date: Tue, 15 May 2007 13:22:59 -0400 Subject: [address-policy-wg] Re: Can the RIRs bypass the IETF and do their own thing? In-Reply-To: References: Message-ID: > > > The US DoC has as much say for ARIN as it does for the RIPE NCC. > > The US DoC, through IANA functions, says, e.g., what IP Address blocks > each can allocate. That seems to qualify as 'much say' > Didn't say how much say, just said that whatever say it had for ARIN it was the same as it had for the RIPE NCC. > You seem to be confusing delegation of authority with loss of > authority. > The DoC has contracted the IANA function to ICANN and doesn't involve > itself much, and ultimately plans to get out altogether. However, the > IANA operator (ICANN) then has 'much say'. But the DoC 'get out > altogether' event hasn't happened yet. So you can't write out the DoC > just yet. > Don't how you arrived at that conclusion based on a casual observation. Not writing them out, don't know how you got that. > > The RIRs existed before ICANN. The relationship between the RIRs and > > ICANN is defined in the ASO MoU, an agreement between ICANN on the > one > > hand and the NRO on behalf of the RIRs on the other. There is no > > mention in the ICANN bylaws of the RIRs. > > The fallacy of this claim was already stated: What is false about those statements? RIRs get their authority > and IP Address Allocations, etc from IANA. The fact that RIRs existed > before ICANN is irrelevant, because IANA existed before the RIRs. And, > as I noted, IANA functions are now contracted to ICANN. Technically, it > is in fact the IANA (not ICANN) that has direct control over RIRs. But, > as I pointed out, ICANN has full control over IANA functions by > contract > with the US Government. And, as I pointed out, the IETF is a technical > consultant to ICANN. The MoUs are just that: Memoranda of > Understanding. > MoUs can be terminated, and don't supercede the contracts with the US > Government. > Never intimated anything about authority lines or derivation of authority, just pointing out some of the factors in the relationship between ICANN and the RIRs. Ray From Woeber at CC.UniVie.ac.at Tue May 15 19:46:12 2007 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 15 May 2007 17:46:12 +0000 Subject: [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <42029.1179250652@sa.vix.com> References: <5ACC8BD4-1ABC-4507-853E-7A5AD97C8496@delong.com> <071201c79687$fddbf2b0$f993d810$@net> <4649603A.3020100@CC.UniVie.ac.at> <42029.1179250652@sa.vix.com> Message-ID: <4649F1E4.1080806@CC.UniVie.ac.at> Paul Vixie wrote: >>I am prepared to start listening again as soon as the "Gain"-figures in the >>CIDR report start to change dramatically: >> >> --- 11May07 --- >>ASnum NetsNow NetsAggr NetGain % Gain Description >>Table 217147 140280 76867 35.4% All ASes > > > i pretty much hate TE routes. companies who build their business plans on > TE routes are, as randy bush once called it, just grazing in the commons. > > but apparently nobody filters on prefix length any more. that surprises me. Surprised, not really... I simply take it as living proof that almost nobody really cares about seeing some (50..)70K+ routes more or less in their boxes, these days. Wilfried. From jeroen at unfix.org Tue May 15 20:05:44 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 15 May 2007 19:05:44 +0100 Subject: [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <4649F1E4.1080806@CC.UniVie.ac.at> References: <5ACC8BD4-1ABC-4507-853E-7A5AD97C8496@delong.com> <071201c79687$fddbf2b0$f993d810$@net> <4649603A.3020100@CC.UniVie.ac.at> <42029.1179250652@sa.vix.com> <4649F1E4.1080806@CC.UniVie.ac.at> Message-ID: <4649F678.80903@spaghetti.zurich.ibm.com> Wilfried Woeber, UniVie/ACOnet wrote: [..] > I simply take it as living proof that almost nobody really cares about seeing > some (50..)70K+ routes more or less in their boxes, these days. See it is a business trick: when there are say 300k routes in the routing tables, you are forcing your competition to also carry that amount of routes in their tables, that means your competition will also have to buy fast new cool routers with a lot of memory. This makes various vendors happy, but it also takes care of emptying your competitions pocket books. When they spend all their cash on routers, they won't be able to invest in other things or need to up their prices, resulting in those customers coming to you etc etc etc. Economics 101. Has not much to do with "The Internet" any more. The road to monopoly has many routes ;) Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From bmanning at karoshi.com Tue May 15 21:29:00 2007 From: bmanning at karoshi.com (bmanning at karoshi.com) Date: Tue, 15 May 2007 19:29:00 +0000 Subject: [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <46499DBD.6080301@inex.ie> References: <20070514053040.GA18747@vacation.karoshi.com.> <46485649.6090408@netability.ie> <20070515093448.GA28881@vacation.karoshi.com.> <464981B0.2040303@inex.ie> <20070515100535.GB28881@vacation.karoshi.com.> <46499DBD.6080301@inex.ie> Message-ID: <20070515192900.GA32430@vacation.karoshi.com.> On Tue, May 15, 2007 at 12:47:09PM +0100, Nick Hilliard wrote: > bmanning at karoshi.com wrote: > > er... perhaps I misread. you stated; "you can stop it from > > being useful PI space, which is all you need to do." > > i understand this as you (party Q) being able to effect any > > communications between myself (party R) and Gert (party S)... > > the single time this is effective is when party Q is in the > > transit path btwn R & S. > > "you" == RIRs/whoever publishing these blocks in a list of prefixes which > should not be seen on the public ipv6 internet, due to community mandate. i have problems w/ the term "public [I,i]nternet" - could you please define it? > - do you want to base your bilateral communications and possibly your > business on an something which is frankly unsupported as designed and > could stop working at any stage if operator Q were to implement > uncontroversial prefix filters? are you suggesting that party Q is the only option for communications btwn parties R & S? > - do you want to go beyond communications between R and S? sure... > Prove the point, Bill. Go ahead and advertise 10/8 and use it in anger on > the public ipv4 internet. When you've got some good figures which > indicate how useful it is, let us know. not a chance. i will note that there are a whole bunch of folks who do use 10.0.0.0/8 "in anger" on the internet - i see many packets w/ this netblock as a source address. > >>The point is, if a block is carved out and marked specifically as being > >>non-routable on the public v6 internet, it will have degraded > >>connectivity to some degree or other. > > > > do i care? > > Given your position on announcing 3ffe::/24 and 3ffe:800::/24 until fairly > recently, evidently not :-) marked by whom? (and wrt 3ffe:: space... folks are still using it and so i still annouce it. it remains useful for them. :) > > does that effect the usefulness of a given prefix > > if some ISP someplace filters out (refuses to listen) to the > > announcements? i posit that: > > a) i have zero influence on your operational behaviour > > when i have zero business relationship w/ you > > b) you have the ability to set whatever policies you like > > for packet acceptance into your network and packet > > egress from your network. > > No argument there. But we're talking about different things. So far, > you're talking about connectivity between exactly two specific parties. > I'm not. so your talking about multicast? last i checked, nearly all traffic was unicast; e.g. end to end, e.g. between exactly two specific parties. > > >>On a related issue, I'd be interested to know what the reachability > >>degradation was like for the last of the 3ffe:: space after 6/6/6? You > >>didn't happen to do any measurements on it? > > > > your general qustion (prefix reachability) is based on (imho again) > > a flawed premise... if i may, could you clarify the two endpoints > > for > > such a reachability study? > > I was thinking more of X = time, Y = % of ipv6 space reachable from > ${3ffe}, where 100% at a particular timepoint would be # of reachable > prefixes from some place known to be relatively well connected (cue flames > for fuzzy specification). Given your reaction to the question, it sounds > like you haven't done looked into this, which is a minor pity. but that is the wrong question. how in the world do you ensure reachability across thousands of ASNs, each of which is willing/able to set their own policies about prefix acceptance? I'm almost persuaded that I don't WANT reachability to all that v6 space... too many places to hid spambots. (and yes, the fuzzy specification is hard to code to... :) > Nick, > bill's friend(tm) thats a new one... :) care to take out a partnership in "Bills Bait & Sushi" ... there are franchise ops available. From brc at zurich.ibm.com Tue May 15 15:18:29 2007 From: brc at zurich.ibm.com (Brian E Carpenter) Date: Tue, 15 May 2007 15:18:29 +0200 Subject: [address-policy-wg] Re: Can the RIRs bypass the IETF and do their own thing? In-Reply-To: <20070514213111.GW73965@Space.Net> References: <46484947.6090702@zurich.ibm.com> <20070514140819.GA7563@borg.c-l-i.net> <20070514213111.GW73965@Space.Net> Message-ID: <4649B325.3020101@zurich.ibm.com> I fully agree with Gert! I'm looking forward to a draft to discuss on its technical merits. Brian On 2007-05-14 23:31, Gert Doering wrote: > Hi, > > On Mon, May 14, 2007 at 04:08:19PM +0200, Shane Kerr wrote: >> If the RIRs decide to allocate numbers from dead:beef::/32 based on >> lunar tides, then the IETF and IANA and ICANN can complain about it >> all day long, but it's not their decision to make. Of course they can >> participate in the policy making process like everyone else. :) > > Well, technically you are correct - but given the way "The Internet" > works, it works better if there is agreement on where the numbers come > from, and how they are distributed in a way that makes them unique. > > So the RIRs *do* try to cooperate with ICANN/IANA and the IETF :-) > > And please let's *not* use the RIPE APWG mailinglist for a fundamental > debate on whether the RIR model is all broken, the IETF is too slow to > be useful, or whatever gripes you have - we need to focus the discussions > somewhat, otherwise too many people will just stop working with us. > > [If you really feel that the RIPE model is all broken, by all means say > so -- but please open a new mail thread for it, instead of shanghaiing a > specific policy proposal discussion] > > Gert Doering > -- APWG chair From dean at av8.com Tue May 15 18:46:22 2007 From: dean at av8.com (Dean Anderson) Date: Tue, 15 May 2007 12:46:22 -0400 (EDT) Subject: [address-policy-wg] Re: Can the RIRs bypass the IETF and do their own thing? In-Reply-To: Message-ID: On Tue, 15 May 2007, Ray Plzak wrote: > The US DoC has as much say for ARIN as it does for the RIPE NCC. The US DoC, through IANA functions, says, e.g., what IP Address blocks each can allocate. That seems to qualify as 'much say' You seem to be confusing delegation of authority with loss of authority. The DoC has contracted the IANA function to ICANN and doesn't involve itself much, and ultimately plans to get out altogether. However, the IANA operator (ICANN) then has 'much say'. But the DoC 'get out altogether' event hasn't happened yet. So you can't write out the DoC just yet. > The RIRs existed before ICANN. The relationship between the RIRs and > ICANN is defined in the ASO MoU, an agreement between ICANN on the one > hand and the NRO on behalf of the RIRs on the other. There is no > mention in the ICANN bylaws of the RIRs. The fallacy of this claim was already stated: RIRs get their authority and IP Address Allocations, etc from IANA. The fact that RIRs existed before ICANN is irrelevant, because IANA existed before the RIRs. And, as I noted, IANA functions are now contracted to ICANN. Technically, it is in fact the IANA (not ICANN) that has direct control over RIRs. But, as I pointed out, ICANN has full control over IANA functions by contract with the US Government. And, as I pointed out, the IETF is a technical consultant to ICANN. The MoUs are just that: Memoranda of Understanding. MoUs can be terminated, and don't supercede the contracts with the US Government. So, it is possible for ICANN/IANA to disregard the technical advice of its technical consultant and so it is possible for ICANN/IANA to allow the RIRs to do something which the IETF doesn't approve. There is nothing the IETF can do about it. The IETF can't fire ICANN as IANA operator, but ICANN could fire the IETF as its technical consultant. Of course, the IETF can also quit as the technical consultant. The IETF has no exclusive monopoly on technical experts. The practical effect of a break with the IETF is to get rid of only the people in the IESG and IAB. Roughly ~25 experts are easily replaced. BTW, it is not the case that I think any of this _will_ happen, but it clarifies the relationships to know what is possible under the current contracts. I expect that people will reach reasonable accomodations with all the stakeholders involved. Of course, sometimes that doesn't happen. But, probably people are more reasonable when they realize the consequences of unreasonable intransigence. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From paul at vix.com Tue May 15 19:37:32 2007 From: paul at vix.com (Paul Vixie) Date: Tue, 15 May 2007 17:37:32 +0000 Subject: [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: Your message of "Tue, 15 May 2007 07:24:42 GMT." <4649603A.3020100@CC.UniVie.ac.at> References: <5ACC8BD4-1ABC-4507-853E-7A5AD97C8496@delong.com> <071201c79687$fddbf2b0$f993d810$@net> <4649603A.3020100@CC.UniVie.ac.at> Message-ID: <42029.1179250652@sa.vix.com> > I am prepared to start listening again as soon as the "Gain"-figures in the > CIDR report start to change dramatically: > > --- 11May07 --- > ASnum NetsNow NetsAggr NetGain % Gain Description > Table 217147 140280 76867 35.4% All ASes i pretty much hate TE routes. companies who build their business plans on TE routes are, as randy bush once called it, just grazing in the commons. but apparently nobody filters on prefix length any more. that surprises me. From heather.schiller at verizonbusiness.com Tue May 15 21:11:36 2007 From: heather.schiller at verizonbusiness.com (Heather Schiller) Date: Tue, 15 May 2007 19:11:36 +0000 (GMT) Subject: [ppml] [address-policy-wg] Re: article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <4649F678.80903@spaghetti.zurich.ibm.com> References: <5ACC8BD4-1ABC-4507-853E-7A5AD97C8496@delong.com> <071201c79687$fddbf2b0$f993d810$@net> <4649603A.3020100@CC.UniVie.ac.at> <42029.1179250652@sa.vix.com> <4649F1E4.1080806@CC.UniVie.ac.at> <4649F678.80903@spaghetti.zurich.ibm.com> Message-ID: On Tue, 15 May 2007, Jeroen Massar wrote: > Wilfried Woeber, UniVie/ACOnet wrote: > [..] >> I simply take it as living proof that almost nobody really cares about seeing >> some (50..)70K+ routes more or less in their boxes, these days. > > See it is a business trick: when there are say 300k routes in the > routing tables, you are forcing your competition to also carry that > amount of routes in their tables, that means your competition will also I'm going to assume by "300k routes in the routing tables" that you are referring to the 'global internet routing table'. Well remember there are 2 routing tables, the 'global internet routing table' and a providers internal routing table.. You aggregate where you can and don't send internal routes to peers, only PI and routes that get leaked for multihoming/traffic engineering reasons. The larger the provider and the more fragmented their address space, the larger their internal routing table. So by the time the 'global internet routing table' reaches 300k routes, your largest transit providers will be well past 300k. > have to buy fast new cool routers with a lot of memory. This makes Does this go for folks who think PI is great too? I'd be happy to deggregate to everyone, and get this over with right now.. but something tells me that wouldn't last more than a few hours. I'm not interested in making the competition have to buy hardware too -- unless it pushes the vendors along to build new hardware. I just want a vendor to make something that can support all the routes and not have to replace it by the time we get it deployed. > various vendors happy, but it also takes care of emptying your > competitions pocket books. When they spend all their cash on routers, > they won't be able to invest in other things or need to up their prices, > resulting in those customers coming to you etc etc etc. Economics 101. > Has not much to do with "The Internet" any more. > > The road to monopoly has many routes ;) > > Greets, > Jeroen > > ############################################### # Heather Schiller # # Customer Security & IP Address Management # # 800.900.0241 # # security at mci.com # ############################################### From gert at space.net Wed May 16 10:33:36 2007 From: gert at space.net (Gert Doering) Date: Wed, 16 May 2007 10:33:36 +0200 Subject: [address-policy-wg] Re: Can the RIRs bypass the IETF and do their own thing? In-Reply-To: References: Message-ID: <20070516083335.GJ73965@Space.Net> Hi, last word from my side on this (and then please take it off the APWG list, as it is getting increasingly off-topic - feel free to discuss this with me in private, though): On Tue, May 15, 2007 at 12:46:22PM -0400, Dean Anderson wrote: > > The RIRs existed before ICANN. The relationship between the RIRs and > > ICANN is defined in the ASO MoU, an agreement between ICANN on the one > > hand and the NRO on behalf of the RIRs on the other. There is no > > mention in the ICANN bylaws of the RIRs. > > The fallacy of this claim was already stated: RIRs get their authority > and IP Address Allocations, etc from IANA. RIRs get their authority from their respective communities. IANA is a tool to ease unique distribution of addresses. If the RIRs communities stop accepting their RIR's authority, there is nothing the DoC, ICANN, or the RIRs can do about it (how can the DoC tell me what addresses to use on my local part of the network?) - and that process works on all nodes in the tree. We already had the situation where ICANN didn't get their act together, and the RIRs seriously considered installing the NRO in its place. So please come down from your US-centric "the DoC rules the world" view - ICANN/IANA is there because they get the job done, and the RIR communities appreciate that. Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 113403 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: 305 bytes Desc: not available URL: From michael.dillon at bt.com Wed May 16 11:38:11 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 16 May 2007 10:38:11 +0100 Subject: [address-policy-wg] Re: Can the RIRs bypass the IETF and do their own thing? In-Reply-To: References: Message-ID: > > The US DoC has as much say for ARIN as it does for the RIPE NCC. > > The US DoC, through IANA functions, says, e.g., what IP Address blocks > each can allocate. That seems to qualify as 'much say' So it seems that you and Ray are in agreement. All the other details are not terribly relevant to RIR policy discussions because we have processes and structures to make sure that everything is done properly. We have no plans to change any of the structures because at the present time, they seem to work OK. As for the matter that started this, central ULAs, there is not need to worry about who controls what. The fact is that it is customary for new address types to be defined *FIRST* in the IETF and even if there is the possibility of an alternate process, we would not dream of exercising that unless the customary process, via the IETF, had broken down. The IETF process cannot be considered broken just because a draft has expired. In fact, expiry of a draft indicates that the original authors no longer care enough about the matter to progress it further. The WG chair of IPv6 Operations has already offered the v6ops list http://www.ietf.org/html.charters/v6ops-charter.html For those people who *DO* wish to progress a draft for Central ULA addresses. This is a sign that the IETF process is open for business in this case. At this point, I think it is inappropriate to continue the Central ULA discussion on the RIR policy lists. In fact, if any policy were to come out of such a discussion, I would vote against it even though my company could potentially benefit from something like a Central ULA address block. But at the same time, my company supports the IETF process in general and I don't believe we would want to be perceived as usurping the IETF. That is why I would vote against any policy proposal that is not based on an RFC. I urge all of you who have an interest in Central ULA addresses, both pro and con, to take your discussion to the v6ops list. And I urge the people in favour of Central ULA addresses to write an Internet draft explaining just what it is that you want to do. At this point in time, there is no valid draft document so I don't even know what it is that you are discussing. --Michael Dillon From shane at time-travellers.org Wed May 16 11:46:16 2007 From: shane at time-travellers.org (Shane Kerr) Date: Wed, 16 May 2007 11:46:16 +0200 Subject: [address-policy-wg] Re: Can the RIRs bypass the IETF and do their own thing? In-Reply-To: References: Message-ID: <20070516094616.GA15491@borg.c-l-i.net> Michael, [ stripping out a lot of content to just say what I want to say... ] On Wed, May 16, 2007 at 10:38:11AM +0100, michael.dillon at bt.com wrote: > At this point, I think it is inappropriate to continue the Central > ULA discussion on the RIR policy lists. Agreed. > In fact, if any policy were to come out of such a discussion, I > would vote against it [...] Me too (well, the RIPE region doesn't vote on policies, but rather say I would oppose Central ULA proposals). -- Shane From michael.dillon at bt.com Wed May 16 11:38:11 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 16 May 2007 10:38:11 +0100 Subject: [ppml] [address-policy-wg] Re: Can the RIRs bypass the IETF and do their own thing? In-Reply-To: References: Message-ID: > > The US DoC has as much say for ARIN as it does for the RIPE NCC. > > The US DoC, through IANA functions, says, e.g., what IP Address blocks > each can allocate. That seems to qualify as 'much say' So it seems that you and Ray are in agreement. All the other details are not terribly relevant to RIR policy discussions because we have processes and structures to make sure that everything is done properly. We have no plans to change any of the structures because at the present time, they seem to work OK. As for the matter that started this, central ULAs, there is not need to worry about who controls what. The fact is that it is customary for new address types to be defined *FIRST* in the IETF and even if there is the possibility of an alternate process, we would not dream of exercising that unless the customary process, via the IETF, had broken down. The IETF process cannot be considered broken just because a draft has expired. In fact, expiry of a draft indicates that the original authors no longer care enough about the matter to progress it further. The WG chair of IPv6 Operations has already offered the v6ops list http://www.ietf.org/html.charters/v6ops-charter.html For those people who *DO* wish to progress a draft for Central ULA addresses. This is a sign that the IETF process is open for business in this case. At this point, I think it is inappropriate to continue the Central ULA discussion on the RIR policy lists. In fact, if any policy were to come out of such a discussion, I would vote against it even though my company could potentially benefit from something like a Central ULA address block. But at the same time, my company supports the IETF process in general and I don't believe we would want to be perceived as usurping the IETF. That is why I would vote against any policy proposal that is not based on an RFC. I urge all of you who have an interest in Central ULA addresses, both pro and con, to take your discussion to the v6ops list. And I urge the people in favour of Central ULA addresses to write an Internet draft explaining just what it is that you want to do. At this point in time, there is no valid draft document so I don't even know what it is that you are discussing. --Michael Dillon _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML at arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml From nick at inex.ie Thu May 17 14:03:11 2007 From: nick at inex.ie (Nick Hilliard) Date: Thu, 17 May 2007 13:03:11 +0100 Subject: [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <20070515192900.GA32430@vacation.karoshi.com.> References: <20070514053040.GA18747@vacation.karoshi.com.> <46485649.6090408@netability.ie> <20070515093448.GA28881@vacation.karoshi.com.> <464981B0.2040303@inex.ie> <20070515100535.GB28881@vacation.karoshi.com.> <46499DBD.6080301@inex.ie> <20070515192900.GA32430@vacation.karoshi.com.> Message-ID: <464C447F.6040304@inex.ie> [this is getting far too pedantic and way off topic for address-policy-wg] bmanning at karoshi.com wrote: > i have problems w/ the term "public [I,i]nternet" - could you > please define it? In such a way that 1) you'd be happy with the definition and 2) we're stay relaticely on-topic for address-policy-wg at ripe? I doubt it. Your ability to pick nits far exceeds the charter of this mailing list - and, indeed my patience for creating water tight definitions. I'm aware of your position on "which [Ii]nternet are we talking about". >> - do you want to base your bilateral communications and possibly your >> business on an something which is frankly unsupported as designed and >> could stop working at any stage if operator Q were to implement >> uncontroversial prefix filters? > > are you suggesting that party Q is the only option for communications > btwn parties R & S? no, merely that allowing your money and livelihood to depend on something unsupported (as-designed) is not a wise move, imo. > marked by whom? (and wrt 3ffe:: space... folks are still using it > and so i still annouce it. it remains useful for them. :) Why not - if it makes you happy. Incidentally, would you mind if I also announced 3ffe::/24 to my v6 upstreams? Now that 3ffe space is deprecated (and let's not get into the "by whom" argument here), I'm sure you can't have any objections. I could make 3ffe::/24 useful to my peers too, I'm sure. What do you think? After all, sharing is caring. >> No argument there. But we're talking about different things. So far, >> you're talking about connectivity between exactly two specific parties. >> I'm not. > > so your talking about multicast? last i checked, nearly all traffic > was unicast; e.g. end to end, e.g. between exactly two specific parties. no, i'm talking about unicast between R and [A-P][S-Z]. I.e. generic connectivity on the public ipv6 Internet (note calculated use of undefined term) between relatively arbitrary parties also on the same public Internet. >> I was thinking more of X = time, Y = % of ipv6 space reachable from >> ${3ffe}, where 100% at a particular timepoint would be # of reachable >> prefixes from some place known to be relatively well connected (cue flames >> for fuzzy specification). Given your reaction to the question, it sounds >> like you haven't done looked into this, which is a minor pity. > > but that is the wrong question. how in the world do you ensure reachability > across thousands of ASNs, each of which is willing/able to set their own > policies about prefix acceptance? No idea. Global dictatorship? But policies can be defined which create a network of networks which generally interoperate and interconnect well, and where if you can't get connectivity from point A to point B, that might be considered enough of a problem for the relevant people to want to fix it. That's enough for me. >> bill's friend(tm) > > thats a new one... :) care to take out a partnership in "Bills Bait & Sushi" ... there are franchise ops available. In a different world, perhaps. It might appeal to me more if I were of the meat-eating inclination. Do you have any other appealing franchise options? Nick, "you know what I mean" From martin.hannigan at batelnet.bs Wed May 16 18:13:27 2007 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Wed, 16 May 2007 12:13:27 -0400 Subject: [ppml] [address-policy-wg] Re: article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) Message-ID: <464b2da7.373.825.29903@batelnet.bs> ----- Original Message ----- From: Jeroen Massar To: Woeber at CC.UniVie.ac.at Cc: ppml at arin.net, address-policy-wg at ripe.net Subject: Re: [ppml] [address-policy-wg] Re: article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) Date: Tue, 15 May 2007 19:05:44 +0100 > Wilfried Woeber, UniVie/ACOnet wrote: > [..] > > I simply take it as living proof that almost nobody > > really cares about seeing some (50..)70K+ routes more or > less in their boxes, these days. > > See it is a business trick: when there are say 300k routes > in the routing tables, you are forcing your competition to > also carry that amount of routes in their tables, that > means your competition will also have to buy fast new cool > routers with a lot of memory. This makes various vendors > happy, but it also takes care of emptying your > competitions pocket books. When they spend all their cash > on routers, they won't be able to invest in other things > or need to up their prices, resulting in those customers > coming to you etc etc etc. Economics 101. Has not much to > do with "The Internet" any more. > > The road to monopoly has many routes ;) The hyperbole is so thick that it can be cut with a chainsaw. -M< From Brian.Knight at us.mizuho-sc.com Fri May 18 20:14:33 2007 From: Brian.Knight at us.mizuho-sc.com (Knight, Brian) Date: Fri, 18 May 2007 14:14:33 -0400 Subject: [address-policy-wg] 2006-05 PI Assignment Size Message-ID: Hello, I am writing to voice support for proposal 2006-05, which would change assignment criteria for end-users requesting PI addressing for multihoming. I have recently found myself in a situation which, I believe, this policy proposal directly addresses. I work for an end-user organization which does business internationally. Though I myself am based in the US, I am also responsible for an office in the UK. This UK office has its own established network that connects independently to the Internet. We ordered connectivity from a second provider with the intention of multihoming with both connections, only to find out that both service providers *require* us to obtain and use PI space in order to do so. Neither provider will deaggregate space from their own assigned PA ranges for us to announce, which, in my experience, is something that US providers will often do for their customers. Our London-based network is rather small, and it does not, by itself, presently meet the address usage requirements for a /24 assignment, the longest commonly-accepted prefix size. However, the services that we provide over the Internet are business-critical, and they are the reason we intend to multihome. Being that this was my first time arranging multihoming with UK service providers, I wondered if this requirement for PI space to multihome was an exceptional case in the provider marketplace. But after a post to the UKNOF mailing list, it seems that the requirement is quite commonplace. We are currently pursuing other avenues of obtaining PI addressing, but had the proposed changes been in effect, we would be operational with both providers by now. Due to providers' requirement for PI space to multihome, the present policy unfairly restricts the end-users who may multihome only to those that can justify the space. Regards, -Brian Knight Sr. Network Engineer Mizuho Securities USA, Futures Division http://www.mizuhosecurities.com/ * Please note that I do not speak for my employer - only for myself. ----------------------------------------- ##################################################################################### CONFIDENTIAL: This e-mail, including its contents and attachments, if any, are confidential. It is neither an offer to buy or sell, nor a solicitation of an offer to buy or sell, any securities or any related financial instruments mentioned in it. If you are not the named recipient please notify the sender and immediately delete it. You may not disseminate, distribute, or forward this e-mail message or disclose its contents to anybody else. Unless otherwise indicated, copyright and any other intellectual property rights in its contents are the sole property of Mizuho Securities USA Inc. E-mail transmission cannot be guaranteed to be secure or error-free. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. Although we routinely screen for viruses, addressees should check this e-mail and any attachments for viruses. We make no representation or warranty as to the absence of viruses in this e-mail or any attachments. Please note that to ensure regulatory compliance and for the protection of our customers and business, we may monitor and read e-mails sent to and from our server(s). ##################################################################################### From Woeber at CC.UniVie.ac.at Fri May 18 22:04:50 2007 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 18 May 2007 20:04:50 +0000 Subject: [address-policy-wg] 2006-05 PI Assignment Size In-Reply-To: References: Message-ID: <464E06E2.2060305@CC.UniVie.ac.at> As you chose to include the attached disclaimer I am not allowed to understand your problem or to answer with regard to your "problem"... Best regards, Wilfried. * Please note that I do not speak for my employer - only for myself. Wondering what your very personal problem is regarding this issue? ..... Knight, Brian wrote: [....] > * Please note that I do not speak for my employer - only for myself. > ----------------------------------------- > ##################################################################################### > CONFIDENTIAL: This e-mail, including its contents and attachments, > if any, are confidential. It is neither an offer to buy or sell, > nor a solicitation of an offer to buy or sell, any securities or > any related financial instruments mentioned in it. If you are not > the named recipient please notify the sender and immediately delete > it. You may not disseminate, distribute, or forward this e-mail > message or disclose its contents to anybody else. Unless otherwise > indicated, copyright and any other intellectual property rights in > its contents are the sole property of Mizuho Securities USA Inc. > E-mail transmission cannot be guaranteed to be secure or > error-free. The sender therefore does not accept liability for any > errors or omissions in the contents of this message which arise as > a result of e-mail transmission. If verification is required > please request a hard-copy version. > Although we routinely screen for viruses, addressees should > check this e-mail and any attachments for viruses. We make no > representation or warranty as to the absence of viruses in this > e-mail or any attachments. Please note that to ensure regulatory > compliance and for the protection of our customers and business, we > may monitor and read e-mails sent to and from our server(s). > ##################################################################################### > > From port27910 at hotmail.com Fri May 18 23:39:49 2007 From: port27910 at hotmail.com (Brian Knight) Date: Fri, 18 May 2007 16:39:49 -0500 Subject: [address-policy-wg] 2006-05 PI Assignment Size Message-ID: Wilfried, Though you yourself were not mentioned by name in the email, you are a member of the mailing list which was a named recipient in the original email. I imagined that, by the virtue of your list membership, you would be privy to its contents. However I can easily see where one may interpret the disclaimer much more narrowly. In any case, below please find a re-posting of my comments made from my other email account, sans disclaimer. Apologies to all for the initial noise. Regards, -Brian Knight ------------------------------------------------------------- I am writing to voice support for proposal 2006-05, which would change assignment criteria for end-users requesting PI addressing for multihoming. I have recently found myself in a situation which, I believe, this policy proposal directly addresses. I work for an end-user organization which does business internationally. Though I myself am based in the US, I am also responsible for an office in the UK. This UK office has its own established network that connects independently to the Internet. We ordered connectivity from a second provider with the intention of multihoming with both connections, only to find out that both service providers *require* us to obtain and use PI space in order to do so. Neither provider will deaggregate space from their own assigned PA ranges for us to announce, which, in my experience, is something that US providers will often do for their customers. Our London-based network is rather small, and it does not, by itself, presently meet the address usage requirements for a /24 assignment, the longest commonly-accepted prefix size. However, the services that we provide over the Internet are business-critical, and they are the reason we intend to multihome. Being that this was my first time arranging multihoming with UK service providers, I wondered if this requirement for PI space to multihome was an exceptional case in the provider marketplace. But after a post to the UKNOF mailing list, it seems that the requirement is quite commonplace. We are currently pursuing other avenues of obtaining PI addressing, but had the proposed changes been in effect, we would be operational with both providers by now. Due to providers' requirement for PI space to multihome, the present policy unfairly restricts the end-users who may multihome only to those that can justify the space. Regards, -Brian Knight >From: "Knight, Brian" >To: >Subject: FW: [address-policy-wg] 2006-05 PI Assignment Size >Date: Fri, 18 May 2007 17:04:16 -0400 > > >-----Original Message----- >From: address-policy-wg-admin at ripe.net >[mailto:address-policy-wg-admin at ripe.net] On Behalf Of Wilfried Woeber, >UniVie/ACOnet >Sent: Friday, May 18, 2007 3:05 PM >To: Knight, Brian >Cc: address-policy-wg at ripe.net >Subject: Re: [address-policy-wg] 2006-05 PI Assignment Size > >As you chose to include the attached disclaimer I am not allowed to >understand your problem or to answer with regard to your "problem"... > >Best regards, >Wilfried. > > >* Please note that I do not speak for my employer - only for myself. > > >Wondering what your very personal problem is regarding this issue? ..... > >Knight, Brian wrote: > >[....] > > * Please note that I do not speak for my employer - only for myself. > > ----------------------------------------- > > ###################################################################### > > ############### > > CONFIDENTIAL: This e-mail, including its contents and attachments, if > > any, are confidential. It is neither an offer to buy or sell, nor a > > solicitation of an offer to buy or sell, any securities or any related > > financial instruments mentioned in it. If you are not the named > > recipient please notify the sender and immediately delete it. You may > > not disseminate, distribute, or forward this e-mail message or > > disclose its contents to anybody else. Unless otherwise indicated, > > copyright and any other intellectual property rights in its contents > > are the sole property of Mizuho Securities USA Inc. > > E-mail transmission cannot be guaranteed to be secure or > > error-free. The sender therefore does not accept liability for any > > errors or omissions in the contents of this message which arise as a > > result of e-mail transmission. If verification is required please > > request a hard-copy version. > > Although we routinely screen for viruses, addressees should check > > this e-mail and any attachments for viruses. We make no representation > > or warranty as to the absence of viruses in this e-mail or any > > attachments. Please note that to ensure regulatory compliance and for > > the protection of our customers and business, we may monitor and read > > e-mails sent to and from our server(s). > > ###################################################################### > > ############### > > > > From dennis at gippnet.com Mon May 21 12:56:58 2007 From: dennis at gippnet.com (=?ISO-8859-1?Q?Dennis_Lundstr=F6m?=) Date: Mon, 21 May 2007 12:56:58 +0200 Subject: [address-policy-wg] 2006-05 PI Assignment Size In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Well I suggest you contact the RIPE-NCC about this. There might be a way around this issue Without lying thru your teeth on the 2-year application form. If you get a green light from a hostmaster. I guess you can refer to that conversation to your ISP/LIR putting in your requests. However this is most likely NOT the correct procedure for application. Best regards! - --Dennis Lundstr?m GippNET AB AS34537 On 18 maj 2007, at 20.14, Knight, Brian wrote: > Hello, > > I am writing to voice support for proposal 2006-05, which would change > assignment criteria for end-users requesting PI addressing for > multihoming. > > I have recently found myself in a situation which, I believe, this > policy > proposal directly addresses. I work for an end-user organization > which does > business internationally. Though I myself am based in the US, I am > also > responsible for an office in the UK. This UK office has its own > established > network that connects independently to the Internet. > > We ordered connectivity from a second provider with the intention of > multihoming with both connections, only to find out that both service > providers *require* us to obtain and use PI space in order to do > so. Neither > provider will deaggregate space from their own assigned PA ranges > for us to > announce, which, in my experience, is something that US providers > will often > do for their customers. > > Our London-based network is rather small, and it does not, by itself, > presently meet the address usage requirements for a /24 assignment, > the > longest commonly-accepted prefix size. However, the services that > we provide > over the Internet are business-critical, and they are the reason we > intend to > multihome. > > Being that this was my first time arranging multihoming with UK > service > providers, I wondered if this requirement for PI space to multihome > was an > exceptional case in the provider marketplace. But after a post to > the UKNOF > mailing list, it seems that the requirement is quite commonplace. > > We are currently pursuing other avenues of obtaining PI addressing, > but had > the proposed changes been in effect, we would be operational with both > providers by now. Due to providers' requirement for PI space to > multihome, > the present policy unfairly restricts the end-users who may > multihome only to > those that can justify the space. > > Regards, > > -Brian Knight > Sr. Network Engineer > Mizuho Securities USA, Futures Division > http://www.mizuhosecurities.com/ > > * Please note that I do not speak for my employer - only for myself. > ----------------------------------------- > ###################################################################### > ############### > CONFIDENTIAL: This e-mail, including its contents and attachments, > if any, are confidential. It is neither an offer to buy or sell, > nor a solicitation of an offer to buy or sell, any securities or > any related financial instruments mentioned in it. If you are not > the named recipient please notify the sender and immediately delete > it. You may not disseminate, distribute, or forward this e-mail > message or disclose its contents to anybody else. Unless otherwise > indicated, copyright and any other intellectual property rights in > its contents are the sole property of Mizuho Securities USA Inc. > E-mail transmission cannot be guaranteed to be secure or > error-free. The sender therefore does not accept liability for any > errors or omissions in the contents of this message which arise as > a result of e-mail transmission. If verification is required > please request a hard-copy version. > Although we routinely screen for viruses, addressees should > check this e-mail and any attachments for viruses. We make no > representation or warranty as to the absence of viruses in this > e-mail or any attachments. Please note that to ensure regulatory > compliance and for the protection of our customers and business, we > may monitor and read e-mails sent to and from our server(s). > ###################################################################### > ############### > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGUXr6sqJZaeZjsn8RAoV4AJ9RyXCYO1upM4Oj9py7An0t/qNgEgCfQzq7 JCgh/pbxBy+Z3TsDIRBQzTE= =z5YP -----END PGP SIGNATURE----- From dean at av8.com Mon May 21 19:03:26 2007 From: dean at av8.com (Dean Anderson) Date: Mon, 21 May 2007 13:03:26 -0400 (EDT) Subject: [address-policy-wg] Re: Can the RIRs bypass the IETF and do their own thing? In-Reply-To: Message-ID: On Tue, 15 May 2007, Ray Plzak wrote: > > > > > The US DoC has as much say for ARIN as it does for the RIPE NCC. > > > > The US DoC, through IANA functions, says, e.g., what IP Address blocks > > each can allocate. That seems to qualify as 'much say' > > > > Didn't say how much say, just said that whatever say it had for ARIN > it was the same as it had for the RIPE NCC. Ok. Then we are agreed that "say" is equal. I think perhaps I misunderstood your message; so long as you aren't disputing that IANA and the DoC has influence over RIRs, we are in agreement. I think we are also in agreement that the RIRs and ICANN/IANA can bypass the IETF by agreeing to do so. The IETF doesn't have any authority to stop IANA from making decisions which contradict the IETF advice to IANA. The IETF doesn't appoint IANA. > > > The RIRs existed before ICANN. The relationship between the RIRs > > > and ICANN is defined in the ASO MoU, an agreement between ICANN on > > > the one hand and the NRO on behalf of the RIRs on the other. > > > There is no mention in the ICANN bylaws of the RIRs. > > > > The fallacy of this claim was already stated: > > What is false about those statements? A fallacy is the false implication of statements supporting a conclusion. One doesn't need false statements to have a fallacy---only a conclusion not supported by the statements. I thought you were asserting that there isn't any control by DoC over RIRs, and that those statements were your justification. That would be a fallacy, but it seems in retrospect you weren't disputing control of DoC over RIRs, so I guess I just misunderstood you. My apologies. However, a nit while I'm at it: The MoU is just a written understanding, and can be terminated at any time by either party. The ICANN bylaws do not need to mention the RIRs for ICANN to contract the IANA function. The absence of RIRs in ICANN bylaws is irrelevant. > > RIRs get their authority and IP Address Allocations, etc from IANA. > > The fact that RIRs existed before ICANN is irrelevant, because IANA > > existed before the RIRs. And, as I noted, IANA functions are now > > contracted to ICANN. Technically, it is in fact the IANA (not ICANN) > > that has direct control over RIRs. But, as I pointed out, ICANN has > > full control over IANA functions by contract with the US Government. > > And, as I pointed out, the IETF is a technical consultant to ICANN. > > The MoUs are just that: Memoranda of Understanding. MoUs can be > > terminated, and don't supercede the contracts with the US > > Government. > > > > Never intimated anything about authority lines or derivation of > authority, just pointing out some of the factors in the relationship > between ICANN and the RIRs. Sorry, this subject sounds to me like CORE, the MoUvement & January 1998 all over again. I may be overreacting to past history. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From shane at time-travellers.org Tue May 22 10:32:58 2007 From: shane at time-travellers.org (Shane Kerr) Date: Tue, 22 May 2007 10:32:58 +0200 Subject: [address-policy-wg] ARIN IPv6 resolution Message-ID: <20070522083258.GA18432@borg.c-l-i.net> All, You may have seen this in the news a bit, but if not, check it out: http://www.arin.net/v6/v6-resolution.html Even though it's written with stupid legal-sounding, fake-formal English, the meaning is good. I think it says: - You should migrate to IPv6 - ARIN staff will help the migration to IPv6 - We should change address policies to "encourage" people to migrate to IPv6 Iljitsch wrote an article about the resolution: http://tinyurl.com/2x594e -- Shane From iljitsch at muada.com Tue May 22 10:45:12 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 22 May 2007 10:45:12 +0200 Subject: [ppml] [address-policy-wg] Re: article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: References: <5ACC8BD4-1ABC-4507-853E-7A5AD97C8496@delong.com> <20070514213631.GX73965@Space.Net> Message-ID: <888F5B3F-854E-46C8-AD25-61DC219E763C@muada.com> [Funny those multi-mailinglist threads - I never know in which mailbox they'll congregate!] On 15-mei-2007, at 0:47, Owen DeLong wrote: >>> If the qualifications for ULA-C were the same, or, if ULA-C was >>> only available to orgs. that had PI, I think that would be >>> acceptable. >> I can't really understand the reasoning behind that. What are you >> trying to achieve, why do you want to restrict handing out ULA-C to >> only a specific (small) subset of folks out there? > I don't want to give ULA-C to people who have an incentive to abuse > it as PI. Don't forget that address space is only useful if it's (almost) universally accepted. This is almost certainly not going to be the case for any type of ULA. Apart from that, I would argue that if you want to make sure that ULAs can't be used as PI, it's beneficial to make sure that there are as many of those block out there as possible, so that the prospect of carrying even a subset of those becomes inpractical. And in my opinion, there is no reason to involve the RIRs in giving out ULA-c space, as there are no requirements that must be checked. Just make sure the price is high enough that people aren't going to use up excessively large amounts and any domain registry/registrar should be able to give those out. Something like 5 euros per year should make sure people won't register millions of them without creating a barrier for those who need ULA space and prefer the centrally assigned kind. >> ULA-C becomes PI the moment folks will accept it in their routing >> table >> (and if that is a serious risk, ULA-L could as easily become PI >> the same >> way). But why should routing folks do that? > Hopefully routing folks won't, but, in my experience, $$$ can lead > routing > folks to ignore what should or shouldn't be done from an internet > context > and, instead, focus on what makes money. If you can get 5% of the internet population to boycott routable ULAs that makes them unusable as such so this won't be a problem. From iljitsch at muada.com Tue May 22 11:02:06 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 22 May 2007 11:02:06 +0200 Subject: [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <464981B0.2040303@inex.ie> References: <20070514053040.GA18747@vacation.karoshi.com.> <46485649.6090408@netability.ie> <20070515093448.GA28881@vacation.karoshi.com.> <464981B0.2040303@inex.ie> Message-ID: On 15-mei-2007, at 11:47, Nick Hilliard wrote: > On a related issue, I'd be interested to know what the reachability > degradation was like for the last of the 3ffe:: space after 6/6/6? > You didn't happen to do any measurements on it? I wanted to keep my 3ffe block in the air as long as possible to see what would happen. Unfortunately, my ISP stopped routing it almost immediately and I was dead in the water... I was surprised to see how fast all of this went down. From iljitsch at muada.com Tue May 22 10:51:19 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 22 May 2007 10:51:19 +0200 Subject: [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: References: Message-ID: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> On 15-mei-2007, at 9:57, JORDI PALET MARTINEZ wrote: > And the only way to control ULA-central is to have it within the > RIR system, How would that work in practice? Approximately 100% of all organizations use RFC 1918 space. Obviously one use for RFC 1918 space goes away with IPv6 (NAT) but I'd say that the number of internet users requiring some kind of local addressing will still be 10, 20, 30 or more percent. The RIR membership is measured in thousands. So tens of thousands or even hundreds of thousands of organizations that may want ULA-c space have no relationship with an RIR. They may not even have a relationship with an ISP... So how are the RIRs supposed to manage their relationship with 10 or 100 times as many people as they have relationships with now? From jeroen at unfix.org Tue May 22 11:15:18 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 22 May 2007 10:15:18 +0100 Subject: [ppml] [address-policy-wg] Re: article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: References: <20070514053040.GA18747@vacation.karoshi.com.> <46485649.6090408@netability.ie> <20070515093448.GA28881@vacation.karoshi.com.> <464981B0.2040303@inex.ie> Message-ID: <4652B4A6.2020702@spaghetti.zurich.ibm.com> Iljitsch van Beijnum wrote: > On 15-mei-2007, at 11:47, Nick Hilliard wrote: > >> On a related issue, I'd be interested to know what the reachability >> degradation was like for the last of the 3ffe:: space after 6/6/6? >> You didn't happen to do any measurements on it? > > I wanted to keep my 3ffe block in the air as long as possible to see > what would happen. Unfortunately, my ISP stopped routing it almost > immediately and I was dead in the water... I was surprised to see how > fast all of this went down. As with everything in that order, see either RIS (http://ris.ripe.net) or of course http://www.sixxs.net/tools/grh/dfp/6bone/ Both 3ffe::/24 and 3ffe:800::/24 are still being announced by Bill Manning, the rest died off quite quickly in the week after Greets, Jeroen -- GRH 6bone list sorted: 2007-05-22 2 <-- still alive 2007-02-16 1 2006-12-15 1 2006-12-14 1 2006-10-07 1 2006-09-19 1 2006-07-29 1 2006-07-18 1 2006-07-08 1 2006-06-30 1 2006-06-26 1 2006-06-21 1 2006-06-19 1 2006-06-16 1 2006-06-15 2 2006-06-13 2 2006-06-12 1 2006-06-08 3 2006-06-07 11 2006-06-06 23 <-- 6GONE date 2006-06-05 1 2006-06-01 2 2006-05-30 1 2006-05-29 1 2006-05-24 2 2006-05-17 1 ... lot of other stuff... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From iljitsch at muada.com Tue May 22 10:51:19 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 22 May 2007 10:51:19 +0200 Subject: [ppml] [address-policy-wg] Re: article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: References: Message-ID: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> On 15-mei-2007, at 9:57, JORDI PALET MARTINEZ wrote: > And the only way to control ULA-central is to have it within the > RIR system, How would that work in practice? Approximately 100% of all organizations use RFC 1918 space. Obviously one use for RFC 1918 space goes away with IPv6 (NAT) but I'd say that the number of internet users requiring some kind of local addressing will still be 10, 20, 30 or more percent. The RIR membership is measured in thousands. So tens of thousands or even hundreds of thousands of organizations that may want ULA-c space have no relationship with an RIR. They may not even have a relationship with an ISP... So how are the RIRs supposed to manage their relationship with 10 or 100 times as many people as they have relationships with now? _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML at arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml From filiz at ripe.net Tue May 22 15:02:14 2007 From: filiz at ripe.net (Filiz Yilmaz) Date: Tue, 22 May 2007 15:02:14 +0200 Subject: [address-policy-wg] 2006-01 Discussion Period extended until 19 June 2007 (Provider Independent (PI) IPv6 Assignments for End User Organisations) Message-ID: <20070522130214.99CC72F583@herring.ripe.net> PDP Number: 2006-01 Provider Independent (PI) IPv6 Assignments for End User Organisations Dear Colleagues The text of the policy proposal 2006-01 has changed. We have published the new version today, as a result the discussion period for this proposal has been extended until 19 June 2007. This proposal is intended to provide a solution for organisations that need IPv6 Provider Independent (PI) assignments. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2006-01.html We encourage you to review this policy proposal and send your comments to . Regards Filiz Yilmaz RIPE NCC Policy Development Officer From jordi.palet at consulintel.es Tue May 22 15:52:41 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Tue, 22 May 2007 09:52:41 -0400 Subject: [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> Message-ID: It is a matter of having the same organization that allocated IP addresses doing allocation of IP addresses, despite the number of "possible customers", instead of having a *new* organization doing so. I really think it may become a political issue and breach for the RIRs system and I don't feel very comfortable with that. The allocation of the ULA-central addresses can be managed in a very automated way, so not a big issue if really becomes a "big" number of them (which I'm convinced will be the case, because only some big entities may want to avoid using ULA local, but enough to avoid wasting global unicast instead). Regards, Jordi > De: Iljitsch van Beijnum > Responder a: > Fecha: Tue, 22 May 2007 10:51:19 +0200 > Para: > CC: , "address-policy-wg at ripe.net" > Asunto: Re: [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs > NAT in arstechnica (seen on slashdot) > > On 15-mei-2007, at 9:57, JORDI PALET MARTINEZ wrote: > >> And the only way to control ULA-central is to have it within the >> RIR system, > > How would that work in practice? Approximately 100% of all > organizations use RFC 1918 space. Obviously one use for RFC 1918 > space goes away with IPv6 (NAT) but I'd say that the number of > internet users requiring some kind of local addressing will still be > 10, 20, 30 or more percent. The RIR membership is measured in > thousands. So tens of thousands or even hundreds of thousands of > organizations that may want ULA-c space have no relationship with an > RIR. They may not even have a relationship with an ISP... > > So how are the RIRs supposed to manage their relationship with 10 or > 100 times as many people as they have relationships with now? > > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From bmanning at karoshi.com Tue May 22 17:24:06 2007 From: bmanning at karoshi.com (bmanning at karoshi.com) Date: Tue, 22 May 2007 15:24:06 +0000 Subject: [ppml] [address-policy-wg] Re: article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <888F5B3F-854E-46C8-AD25-61DC219E763C@muada.com> References: <5ACC8BD4-1ABC-4507-853E-7A5AD97C8496@delong.com> <20070514213631.GX73965@Space.Net> <888F5B3F-854E-46C8-AD25-61DC219E763C@muada.com> Message-ID: <20070522152406.GA25888@vacation.karoshi.com.> On Tue, May 22, 2007 at 10:45:12AM +0200, Iljitsch van Beijnum wrote: > > Don't forget that address space is only useful if it's (almost) > universally accepted. that is hardly true. > Just make sure the price is high enough that people aren't going to > use up excessively large amounts and any domain registry/registrar > should be able to give those out. selling numbers eh? thats a neat trick. will RIPE sell me address space? --bill From nick at inex.ie Tue May 22 17:33:28 2007 From: nick at inex.ie (Nick Hilliard) Date: Tue, 22 May 2007 16:33:28 +0100 Subject: [ppml] [address-policy-wg] Re: article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <20070522152406.GA25888@vacation.karoshi.com.> References: <5ACC8BD4-1ABC-4507-853E-7A5AD97C8496@delong.com> <20070514213631.GX73965@Space.Net> <888F5B3F-854E-46C8-AD25-61DC219E763C@muada.com> <20070522152406.GA25888@vacation.karoshi.com.> Message-ID: <46530D48.1060803@inex.ie> bmanning at karoshi.com wrote: > selling numbers eh? thats a neat trick. will RIPE sell me address > space? 4 years from now, there will be an active IPv4 address space market, whatever about ipv6. Nick -- Network Ability Ltd. | Head of Operations | Tel: +353 1 6169698 3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 Dublin 2, Ireland | Exchange Association | Email: nick at inex.ie From randy at psg.com Tue May 22 17:41:35 2007 From: randy at psg.com (Randy Bush) Date: Tue, 22 May 2007 11:41:35 -0400 Subject: [ppml] [address-policy-wg] Re: article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <46530D48.1060803@inex.ie> References: <5ACC8BD4-1ABC-4507-853E-7A5AD97C8496@delong.com> <20070514213631.GX73965@Space.Net> <888F5B3F-854E-46C8-AD25-61DC219E763C@muada.com> <20070522152406.GA25888@vacation.karoshi.com.> <46530D48.1060803@inex.ie> Message-ID: <46530F2F.2050400@psg.com> > 4 years from now, there will be an active IPv4 address space market, > whatever about ipv6. bingo! what amazes me is the lack of real work on the problem that a a jillion v6-only sites can not connect to the internet in a useful scalable way. without that, everyone will continue to need ipv4 space for a loooooong time. and it will be sliced and diced, and bought and sold, in smaller and smaller pieces. and nats will be ubiquitous, as if they were not already. this is not a pleasing picture. but it's the likely reality. randy From bmanning at karoshi.com Tue May 22 17:45:30 2007 From: bmanning at karoshi.com (bmanning at karoshi.com) Date: Tue, 22 May 2007 15:45:30 +0000 Subject: [ppml] [address-policy-wg] Re: article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <46530D48.1060803@inex.ie> References: <5ACC8BD4-1ABC-4507-853E-7A5AD97C8496@delong.com> <20070514213631.GX73965@Space.Net> <888F5B3F-854E-46C8-AD25-61DC219E763C@muada.com> <20070522152406.GA25888@vacation.karoshi.com.> <46530D48.1060803@inex.ie> Message-ID: <20070522154530.GB25888@vacation.karoshi.com.> On Tue, May 22, 2007 at 04:33:28PM +0100, Nick Hilliard wrote: > bmanning at karoshi.com wrote: > > selling numbers eh? thats a neat trick. will RIPE sell me address > > space? > > 4 years from now, there will be an active IPv4 address space market, > whatever about ipv6. sucker bet. :) there is already an active IPv4 address space market. --bill > > Nick > > -- > Network Ability Ltd. | Head of Operations | Tel: +353 1 6169698 > 3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 > Dublin 2, Ireland | Exchange Association | Email: nick at inex.ie From port27910 at hotmail.com Tue May 22 17:53:31 2007 From: port27910 at hotmail.com (Brian Knight) Date: Tue, 22 May 2007 10:53:31 -0500 Subject: [address-policy-wg] 2006-05 PI Assignment Size In-Reply-To: Message-ID: Dennis, >From: Dennis Lundstr?m >To: "Knight, Brian" >CC: address-policy-wg at ripe.net >Subject: Re: [address-policy-wg] 2006-05 PI Assignment Size >Date: Mon, 21 May 2007 12:56:58 +0200 > >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Well I suggest you contact the RIPE-NCC about this. There might be a way >around this issue >Without lying thru your teeth on the 2-year application form. I followed up with RIPE NCC as suggested They replied that no exceptions could be made, nor did they have any other suggestions for obtaining this space. Thanks very much for your suggestion, though. -Brian >If you get a green light from a hostmaster. I guess you can refer to that >conversation to your ISP/LIR >putting in your requests. > >However this is most likely NOT the correct procedure for application. > >Best regards! > >- --Dennis Lundstr?m > GippNET AB AS34537 > > > >On 18 maj 2007, at 20.14, Knight, Brian wrote: > >>Hello, >> >>I am writing to voice support for proposal 2006-05, which would change >>assignment criteria for end-users requesting PI addressing for >>multihoming. [remainder deleted] From nick at inex.ie Tue May 22 17:58:46 2007 From: nick at inex.ie (Nick Hilliard) Date: Tue, 22 May 2007 16:58:46 +0100 Subject: [ppml] [address-policy-wg] Re: article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <46530F2F.2050400@psg.com> References: <5ACC8BD4-1ABC-4507-853E-7A5AD97C8496@delong.com> <20070514213631.GX73965@Space.Net> <888F5B3F-854E-46C8-AD25-61DC219E763C@muada.com> <20070522152406.GA25888@vacation.karoshi.com.> <46530D48.1060803@inex.ie> <46530F2F.2050400@psg.com> Message-ID: <46531336.3020006@inex.ie> Randy Bush wrote: > what amazes me is the lack of real work on the problem that a a jillion > v6-only sites can not connect to the internet in a useful scalable way. > without that, everyone will continue to need ipv4 space for a loooooong > time. and it will be sliced and diced, and bought and sold, in smaller > and smaller pieces. and nats will be ubiquitous, as if they were not > already. this is not a pleasing picture. but it's the likely reality. I see a two potential escape paths: 1. larger access providers run into the comcast problem[1] and realise that ipv4 is a dead end. this will lead to mass consumer ipv6 enablement, potentially with proxies to provide ipv4 transport. this will be particularly noticeable in emerging markets, where a) there is a relatively small install base which leads to a massive requirement for address space and b) there are language borders, which means that local content providers can service their entire market on ipv6 without having to worry about whether the current ipv4 install base can access it 2. wide-scale implementation of NAT at access levels is going to make people realise exactly how evil NAT is, and that ultimately, administration, hackery and capex costs for obtaining new ipv4 space are going to end up as more than the cost of moving to ipv6. There's nothing that concentrates the mind like having your business size constrained by a technical problem. But you're right on about fragmentation. It's going to happen in a big way and the effect on the internet is going to be savage. Ironically, massive fragmentation is a good driver for ipv6 takeup. Nick [1] http://www.nanog.org/mtg-0606/durand.html From david.conrad at icann.org Tue May 22 19:50:36 2007 From: david.conrad at icann.org (David Conrad) Date: Tue, 22 May 2007 10:50:36 -0700 Subject: [ppml] [address-policy-wg] Re: article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <46531336.3020006@inex.ie> References: <5ACC8BD4-1ABC-4507-853E-7A5AD97C8496@delong.com> <20070514213631.GX73965@Space.Net> <888F5B3F-854E-46C8-AD25-61DC219E763C@muada.com> <20070522152406.GA25888@vacation.karoshi.com.> <46530D48.1060803@inex.ie> <46530F2F.2050400@psg.com> <46531336.3020006@inex.ie> Message-ID: <976CD56B-CD81-49EE-A033-0892B637C31A@icann.org> Nick, On May 22, 2007, at 8:58 AM, Nick Hilliard wrote: > 1. larger access providers run into the comcast problem[1] and > realise that ipv4 is a dead end. this will lead to mass consumer > ipv6 enablement, potentially with proxies to provide ipv4 transport. Perhaps the best future scenario that has a reasonable chance of actually getting deployed is a world in which the core is v6 which provides IPv4 tunneled transit connectivity to v4 NAT/ALG endpoints. IPv6 native hosts within those endpoints could bypass the IPv4 NAT/ ALG to connect to IPv6 enabled content. > this will be particularly noticeable in emerging markets, where a) > there is a relatively small install base which leads to a massive > requirement for address space and b) there are language borders, > which means that local content providers can service their entire > market on ipv6 without having to worry about whether the current > ipv4 install base can access it This makes the assumption that emerging markets have no interest in existing Internet content, the vast majority of which is and will remain on IPv4 for the foreseeable future. > 2. wide-scale implementation of NAT at access levels is going to > make people realise exactly how evil NAT is, and that ultimately, > administration, hackery and capex costs for obtaining new ipv4 > space are going to end up as more than the cost of moving to ipv6. > There's nothing that concentrates the mind like having your > business size constrained by a technical problem. The most likely future is highly dependent on NAT/ALG. For the foreseeable future, most content on the Internet will continue to be provided by IPv4. In order for IPv6-only sites to access that content, you will need to have v6-to-v4 NAT/ALG at one end or the other. > But you're right on about fragmentation. It's going to happen in a > big way and the effect on the internet is going to be savage. > Ironically, massive fragmentation is a good driver for ipv6 takeup. OK, I give up. How does massive fragmentation drive IPv6 takeup? Thanks, -drc From iljitsch at muada.com Tue May 22 20:51:39 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 22 May 2007 20:51:39 +0200 Subject: [ppml] [address-policy-wg] Re: article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <46530F2F.2050400@psg.com> References: <5ACC8BD4-1ABC-4507-853E-7A5AD97C8496@delong.com> <20070514213631.GX73965@Space.Net> <888F5B3F-854E-46C8-AD25-61DC219E763C@muada.com> <20070522152406.GA25888@vacation.karoshi.com.> <46530D48.1060803@inex.ie> <46530F2F.2050400@psg.com> Message-ID: On 22-mei-2007, at 17:41, Randy Bush wrote: >> 4 years from now, there will be an active IPv4 address space market, >> whatever about ipv6. > bingo! ...and that will be the fastest way to kill the remaining v4 space. Triple word value! > what amazes me is the lack of real work on the problem that a a > jillion > v6-only sites can not connect to the internet in a useful scalable > way. Interconnection between IPv6 clients and IPv4 servers can work very well and it can be done at three layers: - application - transport - network At the application layer we have proxies. The problem is that applications need to be aware of them and you need different proxies for different applications. However, pretty much any client-to-server TCP application can make use of the CONNECT method created for HTTPS proxying without the proxy having to be aware of the application protocol. At the transport layer you can have a TCP relay with a DNS ALG, serves the same function as a CONNECT proxy but without the app having to know about it. Not widely implemented, though. And for the network layer the IETF defined NAT-PT (network address translation - protocol translation) which translates between IPv6 and IPv4 and performs IPv4 NAT. Haven't tested this myself due to lack of implementations I could get my hands on and then the IETF decided this wasn't a good idea after all so NAT-PT is either already gone or on the way out. So the good news is that it's fairly trivial to support IPv6-only clients if you have a dual stack proxy and mail server. This takes care of HTTP (90% of all apps right there), HTTPS, mail and basic IM functionality. There are two flavors of peer-to-peer. The first one is towards specific peers, such as with VoIP, so you either need to wait for everyone to have IPv6 or have application-specific proxies. The second type is towards any reasonable subset of a lot of peers, such as BitTorrent. You don't care which peers you talk to, as long as it's enough to get the file. So what you need here is a reasonable subset of peers that are dual stack to facilitate the movement of bits between IPv6-only and IPv4-only peers. There's also often a server or tracker, which would have to be proxied or dual stack. There you have it. You can actually run IPv6-only and get work done, even with the current state of affairs. From nick at inex.ie Tue May 22 22:49:58 2007 From: nick at inex.ie (Nick Hilliard) Date: Tue, 22 May 2007 21:49:58 +0100 Subject: [ppml] [address-policy-wg] Re: article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <976CD56B-CD81-49EE-A033-0892B637C31A@icann.org> References: <5ACC8BD4-1ABC-4507-853E-7A5AD97C8496@delong.com> <20070514213631.GX73965@Space.Net> <888F5B3F-854E-46C8-AD25-61DC219E763C@muada.com> <20070522152406.GA25888@vacation.karoshi.com.> <46530D48.1060803@inex.ie> <46530F2F.2050400@psg.com> <46531336.3020006@inex.ie> <976CD56B-CD81-49EE-A033-0892B637C31A@icann.org> Message-ID: <46535776.5030006@inex.ie> David Conrad wrote: > OK, I give up. How does massive fragmentation drive IPv6 takeup? Hmmm, my original comment looks like it came out my ass. The driver is that massive fragmentation will cause significant expansion of the default-free routing table. For operators who run on slightly older and less capable routers which are reaching their end-of-life in terms of fib explosion, this is going to provide them with a good driver to upgrade their core boxes. I'd propose that there would be two consequences to this: 1) any new system they are going to deploy is almost certainly going to support ipv6 out-of-the-box and 2) it's going to cause network engineers and - with any luck - bean-counters to realise that continuing problems with ipv4 have just taken a very large chunk out of their annual capex. Which gets back to my original point that ipv6 is not going to see any level of success until it becomes a financially more attractive option than ipv4. Let's rephrase the original comment as not so much driving ipv6 uptake but removing further obstacles to its uptake. Nick From leo.vegoda at icann.org Tue May 22 23:00:37 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Tue, 22 May 2007 17:00:37 -0400 Subject: [address-policy-wg] 2006-01 Discussion Period extended until 19 June 2007 (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: <20070522130214.99CC72F583@herring.ripe.net> References: <20070522130214.99CC72F583@herring.ripe.net> Message-ID: On 22 May 2007, at 9:02am, Filiz Yilmaz wrote: > PDP Number: 2006-01 > Provider Independent (PI) IPv6 Assignments for End User Organisations > > Dear Colleagues > > The text of the policy proposal 2006-01 has changed. The new text has the following statement: "PI IPv6 Assignment Size to End User Organisations: The minimum size of the assignment is /48. However, a larger assignment (shorter prefix) can be provided if duly documented and justified." I am not sure what documentation and justification is required to qualify for a prefix shorter than a /48. What do I need to show the RIPE NCC before they would be able to assign my network a /47? It would be helpful to people considering requesting a PI IPv6 prefix and the RIPE NCC if the policy gave a clear statement of what is required. Also, the proposed text does not define a maximum size for an IPv6 PI assignment. When this is combined with a lack of definition for the qualification requirements it seems that a /32 of IPv6 PI could be assigned. Is that intended? Regards, -- Leo Vegoda IANA Numbers Liaison From slz at baycix.de Wed May 23 02:50:56 2007 From: slz at baycix.de (Sascha Lenz) Date: Wed, 23 May 2007 02:50:56 +0200 Subject: [address-policy-wg] 2006-01 Discussion Period extended until 19 June 2007 (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: <20070522130214.99CC72F583@herring.ripe.net> References: <20070522130214.99CC72F583@herring.ripe.net> Message-ID: <46538FF0.80306@baycix.de> Hi, Filiz Yilmaz wrote: > PDP Number: 2006-01 > Provider Independent (PI) IPv6 Assignments for End User Organisations > > Dear Colleagues > > The text of the policy proposal 2006-01 has changed. > > We have published the new version today, as a result the discussion > period for this proposal has been extended until 19 June 2007. [...] for starters: the link to Version 2.0 http://www.ripe.net/ripe/policies/proposals/2006-01_v2.pdf ("Submission date: ..Previous versions v1.0 and v2.0 are available as PDF") does not work. Some webmaster at RIPE might want to fix this :-) - Then again, i'm a little puzzled about the most recent(?) changes. I wonder if i missed something, or if the proposal finally got completely useless, trying to find a consensus. Why do we concentrate on "multihoming" now as a requirement for PI-addresses? That's not what "Provider Independent" means to me, even if this is the most likely reason for such a request. What about those who just want a portable block, no renumbering? Why include some routing-policy in an address-policy again? Isn't it enough that the autonomous system request policy already requires >=2 peers? What does that have to do with numbering in the first place? Why isn't the only real thing we need, a contractual relationship of some kind a and small recurring fee good enough? Why other artificial barriers? THERE IS NO ROUTING TABLE PROBLEM. (you might shoot me if i'm proven wrong in 20years) . o O(X-No-Archive: Yes :-}) Simple IPv6 PI Assignment policy: - Being an end-site, not (sub-)assigning address-space to third parties - End-site explicitely states that PI addresses are desired for this assignment and that they are aware of possible the impact of PI vs. PA addresses - PI request MUST be approved by the RIPE NCC, not by a LIR - Maintaining a standardised contractual relationship with an active RIPE LIR or the RIPE NCC directely for the lifetime of the assignment - A recurring fee of 100EUR/y is charged from the RIPE NCC directely or via the handling LIR - RIPE NCC can revoke the assigment if the holder fails to pay the recurring fee within 6 months after the payment is due or is getting otherwise unresponsive - The assignment is at least a /48 from a dedicated supernet-block which clearly identifies it as Provider Independent Prefix - A shorter prefix may be assigned if the end-site provides a network plan and possible contracts with suppliers that hint that a /48 prefix might not contain enough subnets for the planned lifetime of the assignment. The same applies for subsequent assignments to the same end-site. [Actually, PI and PA requirement should just be the same here, but the PA policy isn't really stateing anything clear yet either] - A reservation for a growth up to a /44 is usually considered ..then adapt that to IPv4 PI, too, and we're done/done. ==> PA is still easy and cheap, PI is more hassle and a more expensive so it doesn't get the "default" - and we have some way to get it back to the free pool if it goes zombie, perfect. (DISCLAIMER: That is over-simplified; i'm aware of that - for example - we can't put "100EUR/y" in the policy itself) For the records: i don't really support the current 2006-01 draft in this incarnation. It doesn't really fit anymore. Main reason: Limitation to "multihoming". (I never would have thought that i object to a IPv6 PI policy until today...) -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From garry at nethinks.com Wed May 23 06:43:50 2007 From: garry at nethinks.com (Garry Glendown) Date: Wed, 23 May 2007 06:43:50 +0200 Subject: [address-policy-wg] 2006-01 Discussion Period extended until 19 June 2007 (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: <46538FF0.80306@baycix.de> References: <20070522130214.99CC72F583@herring.ripe.net> <46538FF0.80306@baycix.de> Message-ID: <4653C686.90906@nethinks.com> Sascha Lenz wrote: > Why do we concentrate on "multihoming" now as a requirement for > PI-addresses? That's not what "Provider Independent" means to me, even > if this is the most likely reason for such a request. > > What about those who just want a portable block, no renumbering? Agreed - from my 11+ years of being an ISP (well, mostly in the last 5 years or so) with the growing dependency on Internet for many companies, it's enough work for many places to renumber their network. IT-folks know it, try to avoid it as long as possible. When they finally need to do it, e.g. because of switching ISPs, they want to avoid it in the future at almost any cost. That's why we get almost all of our requests for PI space. Multi-homing, though not as common yet, may become an issue, maybe another 3-5 years down the road, but IMO isn't a reason at all for PI-space. All you have to do is make sure you get a provider that will allow a sub-allocation to be announced by another provider. Why PI then? > Simple IPv6 PI Assignment policy: Your short version seems to cover most anything I can think of. Agreed on the service fee, too. As for who charges it, there's two sides of the medal there ... I can't really tell yet if assigning the Provider to charge it for RIPE is a good idea or not. Probably the easiest, though additional hassles in case of an end user switching his (primary) ISP will follow. Or what happens if the customer refuses (or is unable) to pay the PI dues to the LIR? Couple of things need to be worked out I guess. -garry From iljitsch at muada.com Wed May 23 09:17:08 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 23 May 2007 09:17:08 +0200 Subject: Did CIDR teach us nothing? was: Re: [address-policy-wg] 2006-01 Discussion Period extended until 19 June 2007 (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: <46538FF0.80306@baycix.de> References: <20070522130214.99CC72F583@herring.ripe.net> <46538FF0.80306@baycix.de> Message-ID: On 23-mei-2007, at 2:50, Sascha Lenz wrote: > Why do we concentrate on "multihoming" now as a requirement for PI- > addresses? That's not what "Provider Independent" means to me, even > if this is the most likely reason for such a request. > What about those who just want a portable block, no renumbering? Why am I even bothering!? The IETF spent 5 years getting scalable multihoming off the ground. Then the operator community / RIR policy makers decided shim6 wasn't good enough before it was even finished and we need PI in IPv6 for multihoming just like in IPv4. That was a bad decision at the wrong time and we'll live to regret it, but it won't kill the IPv6 internet in the immediate future. But now we should go back to the good old days before the invention of CIDR where everyone gets a portable address block, no questions asked? Unlike IPv6 PI for multihoming this will be enough to kill IPv6 really fast if it comes into wide use, just like it almost killed IPv4 in the early 1990s. From slz at baycix.de Wed May 23 11:30:40 2007 From: slz at baycix.de (Sascha Lenz) Date: Wed, 23 May 2007 11:30:40 +0200 Subject: Did CIDR teach us nothing? was: Re: [address-policy-wg] 2006-01 Discussion Period extended until 19 June 2007 (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: References: <20070522130214.99CC72F583@herring.ripe.net> <46538FF0.80306@baycix.de> Message-ID: <465409C0.3050103@baycix.de> Hi, Iljitsch van Beijnum wrote: > On 23-mei-2007, at 2:50, Sascha Lenz wrote: > >> Why do we concentrate on "multihoming" now as a requirement for >> PI-addresses? That's not what "Provider Independent" means to me, even >> if this is the most likely reason for such a request. > >> What about those who just want a portable block, no renumbering? > > Why am I even bothering!? > > The IETF spent 5 years getting scalable multihoming off the ground. Then > the operator community / RIR policy makers decided shim6 wasn't good > enough before it was even finished and we need PI in IPv6 for > multihoming just like in IPv4. That was a bad decision at the wrong time > and we'll live to regret it, but it won't kill the IPv6 internet in the > immediate future. > > But now we should go back to the good old days before the invention of > CIDR where everyone gets a portable address block, no questions asked? > Unlike IPv6 PI for multihoming this will be enough to kill IPv6 really > fast if it comes into wide use, just like it almost killed IPv4 in the > early 1990s. > Come one, others here also *WERE* there back in the classful times, and screamed "we need a change!!" when their Cisco 3640s hit the end of their usefulnes - heck, even i supported the shim6 (or similiar) development. It's not only you that recognized that problem and started to fear the possible outcome, but you haven't realized that times are changing yet. I don't see any routing table problem for the forseeable future, you have plenty of time to come up with a new, scalable solution and start to deploy it. I still *DO* support *ANYTHING* that keeps the global internet routing tables small and shiny, i really do, but not to that extent that i render the Internet/IPv6 completely useless and "racist" by not allowing IPv6 provider independence. This is real-life internet free market economy nowerdays, deal with it. - I will explain to customers that renumbering is not a big deal if it really isn't in their cases - I will explain to customers that there are other possibilities for multihoming right now and see if that works for them first - I will use any possible other new solution to the problem ("shim6") if it fits the customers needs in the future - I will urge any customer to become a RIR member and explain all advantages of that to them - I will not solicit the usage of PI vs. PA or anything - I will not pass any PI requests or similar from customers if i'm not convinced that they really need it and know what they do but i will NOT deny anyone a routing-table slot just because of their size or monetary issues. So, please, continue with your quest for a better solution, i will appreciate it and bring it to use whereever applicable. P.S.: Anyone got any recent numbers about the percentage of PI announcements in the table vs. PA announcements + deaggregates? -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From Woeber at CC.UniVie.ac.at Wed May 23 11:47:24 2007 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 23 May 2007 09:47:24 +0000 Subject: Did CIDR teach us nothing? was: Re: [address-policy-wg] 2006-01 Discussion Period extended until 19 June 2007 (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: <465409C0.3050103@baycix.de> References: <20070522130214.99CC72F583@herring.ripe.net> <46538FF0.80306@baycix.de> <465409C0.3050103@baycix.de> Message-ID: <46540DAC.3050003@CC.UniVie.ac.at> Sascha, Sascha Lenz wrote: [...] > P.S.: Anyone got any recent numbers about the percentage of PI > announcements in the table vs. PA announcements + deaggregates? > that's probably not the fully adequate answer, but I considered the info in the following two slides (page 9 and 10) as very interesting in this context: http://www.ripe.net/ripe/meetings/ripe-54/presentations/RIPE_NCC_Statistics.pdf The bottom line is that the # of PI assignments has (considerably) surpassed the number of PA assignments since 2003, and that the load on the routing table for PI is thus bigger than for PA, although the *percentage* of PI space as compared to PA is approx. 2%. Or, the other way 'round, we use more than 50% of (additional) routing table slots for some 2% of address space (PI) and less than 50% for some 98% of PA. Wilfried. From iljitsch at muada.com Wed May 23 12:02:54 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 23 May 2007 12:02:54 +0200 Subject: Did CIDR teach us nothing? was: Re: [address-policy-wg] 2006-01 Discussion Period extended until 19 June 2007 (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: <46540DAC.3050003@CC.UniVie.ac.at> References: <20070522130214.99CC72F583@herring.ripe.net> <46538FF0.80306@baycix.de> <465409C0.3050103@baycix.de> <46540DAC.3050003@CC.UniVie.ac.at> Message-ID: On 23-mei-2007, at 11:47, Wilfried Woeber, UniVie/ACOnet wrote: > http://www.ripe.net/ripe/meetings/ripe-54/presentations/ > RIPE_NCC_Statistics.pdf > The bottom line is that the # of PI assignments has (considerably) > surpassed the number of PA assignments since 2003, and that the > load on the > routing table for PI is thus bigger than for PA, although the > *percentage* of > PI space as compared to PA is approx. 2%. (As a percentage of the address space, not a percentage of the number of blocks.) > Or, the other way 'round, we use more than 50% of (additional) > routing table > slots for some 2% of address space (PI) and less than 50% for some > 98% of PA. And that's with IPv4, where you have to show you really need a block of 256 addresses to qualify for a PI block. In IPv6, that hurdle has been removed so it has the potential to see even larger numbers of PI as soon as IPv6 deployment starts taking off. From Woeber at CC.UniVie.ac.at Wed May 23 12:15:50 2007 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 23 May 2007 10:15:50 +0000 Subject: Did CIDR teach us nothing? was: Re: [address-policy-wg] 2006-01 Discussion Period extended until 19 June 2007 (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: References: <20070522130214.99CC72F583@herring.ripe.net> <46538FF0.80306@baycix.de> <465409C0.3050103@baycix.de> <46540DAC.3050003@CC.UniVie.ac.at> Message-ID: <46541456.5040701@CC.UniVie.ac.at> A couple of additional comments which I should have added in the first place... Iljitsch van Beijnum wrote: > On 23-mei-2007, at 11:47, Wilfried Woeber, UniVie/ACOnet wrote: > >> http://www.ripe.net/ripe/meetings/ripe-54/presentations/ >> RIPE_NCC_Statistics.pdf > > >> The bottom line is that the # of PI assignments has (considerably) >> surpassed the number of PA assignments since 2003, and that the load >> on the >> routing table for PI is thus bigger than for PA, although the >> *percentage* of >> PI space as compared to PA is approx. 2%. > > > (As a percentage of the address space, not a percentage of the number > of blocks.) Correct. >> Or, the other way 'round, we use more than 50% of (additional) >> routing table >> slots for some 2% of address space (PI) and less than 50% for some >> 98% of PA. Which of course is not necessarily the full story as there probably are filters in place to prevent a good number of them to show up in the DFZ. > And that's with IPv4, where you have to show you really need a block of > 256 addresses to qualify for a PI block. Minor correction: you don't have to require a /24 equivalent to get PI. Actually, that is the (imho important) cross-link to the proposal for "upgrading" any smaller PI assignment to a /24 "if there are routing problems". Ref: http://www.ripe.net/ripe/policies/proposals/2006-05.html Otoh, going classful again for PIv4 would change the 2%/98% ratio ;-) > In IPv6, that hurdle has been > removed so it has the potential to see even larger numbers of PI as > soon as IPv6 deployment starts taking off. Wilfried. From mohacsi at niif.hu Wed May 23 11:59:11 2007 From: mohacsi at niif.hu (Mohacsi Janos) Date: Wed, 23 May 2007 11:59:11 +0200 (CEST) Subject: Did CIDR teach us nothing? was: Re: [address-policy-wg] 2006-01 Discussion Period extended until 19 June 2007 (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: <46540DAC.3050003@CC.UniVie.ac.at> References: <20070522130214.99CC72F583@herring.ripe.net> <46538FF0.80306@baycix.de> <465409C0.3050103@baycix.de> <46540DAC.3050003@CC.UniVie.ac.at> Message-ID: <20070523115600.X32663@mignon.ki.iif.hu> On Wed, 23 May 2007, Wilfried Woeber, UniVie/ACOnet wrote: > Sascha, > > Sascha Lenz wrote: > > [...] > >> P.S.: Anyone got any recent numbers about the percentage of PI >> announcements in the table vs. PA announcements + deaggregates? >> > that's probably not the fully adequate answer, but I considered the > info in the following two slides (page 9 and 10) as very interesting > in this context: > > http://www.ripe.net/ripe/meetings/ripe-54/presentations/RIPE_NCC_Statistics.pdf > > The bottom line is that the # of PI assignments has (considerably) > surpassed the number of PA assignments since 2003, and that the load on the > routing table for PI is thus bigger than for PA, although the *percentage* of > PI space as compared to PA is approx. 2%. > > Or, the other way 'round, we use more than 50% of (additional) routing table > slots for some 2% of address space (PI) and less than 50% for some 98% of PA. Are there similar statistics in the other RIR area? If the picture is similar we have in RIPE region, then we have think over PI address policy.... Only my 2 cents.... Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 From nick at inex.ie Wed May 23 12:47:47 2007 From: nick at inex.ie (Nick Hilliard) Date: Wed, 23 May 2007 11:47:47 +0100 Subject: Did CIDR teach us nothing? was: Re: [address-policy-wg] 2006-01 Discussion Period extended until 19 June 2007 (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: References: <20070522130214.99CC72F583@herring.ripe.net> <46538FF0.80306@baycix.de> Message-ID: <46541BD3.2060708@inex.ie> Iljitsch van Beijnum wrote: > The IETF spent 5 years getting scalable multihoming off the ground. They got shim6 off the ground at last? Excellent. Can you please tell me how to enable it on my mac? Or on my freebsd box at the office? Also, instructions for Linux and windows would be helpful. I await your advice eagerly. Nick From mohta at necom830.hpcl.titech.ac.jp Wed May 23 16:27:29 2007 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 23 May 2007 23:27:29 +0900 Subject: Did CIDR teach us nothing? was: Re: [address-policy-wg] 2006-01 Discussion Period extended until 19 June 2007 (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: References: <20070522130214.99CC72F583@herring.ripe.net> <46538FF0.80306@baycix.de> Message-ID: <46544F51.10604@necom830.hpcl.titech.ac.jp> Iljitsch van Beijnum wrote: Apparently, CIDR taught you nothing. > The IETF spent 5 years getting scalable multihoming off the ground. > Then the operator community / RIR policy makers decided shim6 wasn't > good enough before it was even finished and we need PI in IPv6 for > multihoming just like in IPv4. In general, spending 5 years on such a simple problem is the worst thing to do and, naturally, results in useless output. Actually, shim6, from the beginning, is wrongly architechted. It is not only useless but also harmful. Fortunately, as IPv6 is not deployed at all, we still have some time to start over again throwing away all the details of IPv6. Masataka Ohta From leo.vegoda at icann.org Wed May 23 17:18:18 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 23 May 2007 11:18:18 -0400 Subject: [address-policy-wg] 2006-01 Discussion Period extended until 19 June 2007 (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: <46538FF0.80306@baycix.de> References: <20070522130214.99CC72F583@herring.ripe.net> <46538FF0.80306@baycix.de> Message-ID: On 22 May 2007, at 8:50pm, Sascha Lenz wrote: [...] > Simple IPv6 PI Assignment policy: [...] > - A recurring fee of 100EUR/y is charged from the RIPE NCC directely > or via the handling LIR As you noted elsewhere, fee schedule decisions belong to the membership. [...] > - The assignment is at least a /48 from a dedicated supernet-block > which clearly identifies it as Provider Independent Prefix > - A shorter prefix may be assigned if the end-site provides a network > plan and possible contracts with suppliers that hint that a /48 > prefix might not contain enough subnets for the planned lifetime > of the assignment. Hint? If prefixes shorter than /48 should not be the default assignment then I think we need more than a "slight or indirect indication or suggestion" that more than a /48 is required. If I just need to hint that I might possibly need more than a /48 over the next 15 years to receive a /44, /40 or /32 then the policy is utterly broken. If you want a free-for-all then propose a policy that clearly and unambiguously states that there is a free for all. If you want restrictions then propose a policy that clearly and unambiguously states what the qualifying criteria are. Vague language makes things more difficult for requesters because they don't know if they qualify or not and so may be dissuaded from requesting something they need. It also makes things very awkward for the RIPE NCC staff. Without a clear set of criteria they aren't in a position to justify refusing an (apparently) unreasonable request. This is likely to lead to refusing all requests or approving all requests - but probably the latter. Regards, -- Leo Vegoda IANA Numbers Liaison From slz at baycix.de Wed May 23 18:07:35 2007 From: slz at baycix.de (Sascha Lenz) Date: Wed, 23 May 2007 18:07:35 +0200 Subject: [address-policy-wg] 2006-01 Discussion Period extended until 19 June 2007 (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: References: <20070522130214.99CC72F583@herring.ripe.net> <46538FF0.80306@baycix.de> Message-ID: <465466C7.5010105@baycix.de> Hi, Leo Vegoda wrote: > On 22 May 2007, at 8:50pm, Sascha Lenz wrote: > > [...] > >> Simple IPv6 PI Assignment policy: > > [...] > >> - A recurring fee of 100EUR/y is charged from the RIPE NCC directely >> or via the handling LIR > > As you noted elsewhere, fee schedule decisions belong to the membership. yes, i did. This is over-simplified to state my point WHAT a policy needs to look like *in the end*. Some people stressed their point that a vague pointing towards a not-yes-existing contractual relationship isn't going to fly for them as long as they don't know what might be in it, and you obviously don't like vague statements either. So i explicitely say what the outcome should look like - around how many corners that needs to be filed into policies, contracts, memberships etc.... someone from the NCC needs to help me/us with since we are technicians who don't have 100% clue about that. But this is a cruical part of the overall PI policy IMHO. > [...] > >> - The assignment is at least a /48 from a dedicated supernet-block >> which clearly identifies it as Provider Independent Prefix >> - A shorter prefix may be assigned if the end-site provides a network >> plan and possible contracts with suppliers that hint that a /48 >> prefix might not contain enough subnets for the planned lifetime >> of the assignment. > > Hint? If prefixes shorter than /48 should not be the default assignment > then I think we need more than a "slight or indirect indication or > suggestion" that more than a /48 is required. If I just need to hint > that I might possibly need more than a /48 over the next 15 years to > receive a /44, /40 or /32 then the policy is utterly broken. Facts: - The PA policy (http://www.ripe.net/ripe/docs/ipv6policy.html#assignment_size) doesn't really say anything specific either, and AFAIK there hasn't been a single End-User Request for If you want a free-for-all then propose a policy that clearly and > unambiguously states that there is a free for all. If you want > restrictions then propose a policy that clearly and unambiguously states > what the qualifying criteria are. You cannot predict all possible (valid) reasons for a bigger assignment. If you look at a network plan and you see that 16bit subnets is not enough.. fine. IF not, ask them to come back for a subsequent assignment (mind the /44 reservation suggestion) if they really run out of subnets and can show that by means of contracts or equipment bills (similar to IPv4 as mentioned above). (And btw, i think this will rarely happen since i'm not aware of any request Vague language makes things more difficult for requesters because they > don't know if they qualify or not and so may be dissuaded from > requesting something they need. It also makes things very awkward for > the RIPE NCC staff. Without a clear set of criteria they aren't in a > position to justify refusing an (apparently) unreasonable request. This > is likely to lead to refusing all requests or approving all requests - > but probably the latter. I still trust the RIPE NCC Hostmasters to be reasonable and clueful, but if you think we should start micro-managing via the policies... since it's you, i actually wouldn't object since you have some experience there ;-) But we need some realworld examples from the NCC here to find out what should go into the polic[y|ies] and what not. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From leo.vegoda at icann.org Wed May 23 19:33:00 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 23 May 2007 13:33:00 -0400 Subject: [address-policy-wg] 2006-01 Discussion Period extended until 19 June 2007 (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: <465466C7.5010105@baycix.de> References: <20070522130214.99CC72F583@herring.ripe.net> <46538FF0.80306@baycix.de> <465466C7.5010105@baycix.de> Message-ID: <17D5E431-E563-43E2-87F2-30D221531496@icann.org> Sascha, I think we broadly agree, actually :-) On 23 May 2007, at 12:07pm, Sascha Lenz wrote: [...] >>> - A recurring fee of 100EUR/y is charged from the RIPE NCC directely >>> or via the handling LIR >> As you noted elsewhere, fee schedule decisions belong to the >> membership. > > yes, i did. This is over-simplified to state my point WHAT a policy > needs to look like *in the end*. Fair enough and I agree that a contract for the assignment is a very important element. >>> - The assignment is at least a /48 from a dedicated supernet-block >>> which clearly identifies it as Provider Independent Prefix >>> - A shorter prefix may be assigned if the end-site provides a >>> network >>> plan and possible contracts with suppliers that hint that a /48 >>> prefix might not contain enough subnets for the planned lifetime >>> of the assignment. >> Hint? If prefixes shorter than /48 should not be the default >> assignment then I think we need more than a "slight or indirect >> indication or suggestion" that more than a /48 is required. If I >> just need to hint that I might possibly need more than a /48 over >> the next 15 years to receive a /44, /40 or /32 then the policy is >> utterly broken. > > Facts: > > - The PA policy (http://www.ripe.net/ripe/docs/ > ipv6policy.html#assignment_size) > doesn't really say anything specific either, and AFAIK there hasn't > been a single End-User Request for If the RIPE NCC thinks it can provide input on what they need here > or experience like how they deal with sites, i'm happy to hear them out. Should be similar to what end-user requests should look like. > I don't want to make a difference between PI and PA assignment > requirements here in the end, that's my plan at least. I think using the same criteria to evaluate PA and PI requests would be useful and fair. > - It's vague, but it's always stressed that the RIPE NCC hostmasters > usually know what they do and have the experience to tell if someone > provided the correct amount of information for a given request. > Why should that be different for IPv6 PI now? The difference is that the IPv4 using community has over a decade of experience and plenty of documents describing what is and is not efficient. There isn't much IPv6 deployment experience and what is considered efficient usage of a /48 isn't documented (I think). > Isn't some kind of contract or bills for equipment like i suggest > here > enough? That's what i'm usually asked to provide to the NCC if i > request some biiiiiiiiiig IPv4 assignment/allocation at least. > > PROBABLY the PI and PA policy needs something like "utilisation > within a 2year term" statement or so similar to the IPv4 assignment > policy; that is correct. But i intentionally left that out here > since it's not in the PA policy either. (RFC3177 doesn't say > anything about a specific timeframe either AFAICR). I agree that something like 'x subnets used in y years' would work. I don't know what x and y should be, though. When we have that I will know how many thousand subnets I have to use before my network qualifies for a /47. That will be genuinely useful for people deploying IPv6 networks. My concern isn't the tools the RIPE NCC will use to determine that someone qualifies. They will use whatever evaluation techniques are appropriate and I don't think the policy needs to worry about them. I just think the policy needs to let them know what they are measuring. [...] > I actually want to prevent big assignments to be granted just > because some bad network design. But how the hell should we predict > what's bad and what not here in writing? Happy to hear suggestions > how to prevent this. I personally think that this can only be > solved with clue++; at the RIPE NCC Hostmaster level in the end, > not by a rigid policy. I'm not worried about the RIPE NCC's clue level - they do well there. I just want them to be given the tools they will need when they have to justify their decisions. Regards, -- Leo Vegoda IANA Numbers Liaison From owen at delong.com Tue May 22 17:48:33 2007 From: owen at delong.com (Owen DeLong) Date: Tue, 22 May 2007 08:48:33 -0700 Subject: [ppml] [address-policy-wg] Re: article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot) In-Reply-To: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> Message-ID: <47C380E7-AF3C-47DF-A0DC-C60BA39989DC@delong.com> On May 22, 2007, at 1:51 AM, Iljitsch van Beijnum wrote: > On 15-mei-2007, at 9:57, JORDI PALET MARTINEZ wrote: > >> And the only way to control ULA-central is to have it within the >> RIR system, > > How would that work in practice? Approximately 100% of all > organizations use RFC 1918 space. Obviously one use for RFC 1918 > space goes away with IPv6 (NAT) but I'd say that the number of > internet users requiring some kind of local addressing will still be > 10, 20, 30 or more percent. The RIR membership is measured in > thousands. So tens of thousands or even hundreds of thousands of > organizations that may want ULA-c space have no relationship with an > RIR. They may not even have a relationship with an ISP... > First of all, at least in the case of ARIN, membership is not a requirement for obtaining Address space. I realize that in RIPE and APNIC, membership is required. However, nobody actually NEEDS local addressing, technically. Technically, people NEED addressing. The distinction between local and global addressing is mostly an administrative convenience. There is no local addressing purpose for which global addresses are inadequate or infeasible. I'm quite sure that the RIRs can handle additional business relationships just fine. If someone has neither a relationship with an ISP nor a relationship with an RIR, then, one of those two things will have to change before they get addresses assigned. Same way things work today, except for RFC-1918 and ULA-Local. > So how are the RIRs supposed to manage their relationship with 10 or > 100 times as many people as they have relationships with now? > Same way they do now. Might require beefier or more servers, and an increased staff, but, I would expect that with 10-100 times the fees rolling in, that won't be a problem. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From ms at man-da.de Thu May 24 10:15:54 2007 From: ms at man-da.de (Marcus Stoegbauer) Date: Thu, 24 May 2007 10:15:54 +0200 Subject: [address-policy-wg] 2006-01 Discussion Period extended until 19 June 2007 (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: <46538FF0.80306@baycix.de> References: <20070522130214.99CC72F583@herring.ripe.net> <46538FF0.80306@baycix.de> Message-ID: <465549BA.6040803@man-da.de> Sascha Lenz wrote: > Filiz Yilmaz wrote: >> PDP Number: 2006-01 >> Provider Independent (PI) IPv6 Assignments for End User Organisations >> >> Dear Colleagues >> >> The text of the policy proposal 2006-01 has changed. >> >> We have published the new version today, as a result the discussion >> period for this proposal has been extended until 19 June 2007. > [...] > > For the records: i don't really support the current 2006-01 draft in > this incarnation. It doesn't really fit anymore. Main reason: Limitation > to "multihoming". I agree with Sascha here, only considering multihoming as a reason for IPv6 PI space is a big step backwards from the former versions of the proposal. For me it is too big of a limitation to support the draft in this incarnation. Marcus -- man-da.de GmbH, AS8365 Phone: +49 6151 16-6956 Petersenstr. 30 Fax: +49 6151 16-3050 D-64287 Darmstadt e-mail: ms at man-da.de Gesch?ftsf?hrer Dr. J?rgen Ohrnberger AG Darmstadt, HRB 94 84 From flor at ripe.net Thu May 24 15:43:27 2007 From: flor at ripe.net (Flor Paredes) Date: Thu, 24 May 2007 15:43:27 +0200 Subject: Did CIDR teach us nothing? was: Re: [address-policy-wg] 2006-01 Discussion Period extended until 19 June 2007 (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: <20070523115600.X32663@mignon.ki.iif.hu> References: <20070522130214.99CC72F583@herring.ripe.net> <46538FF0.80306@baycix.de> <465409C0.3050103@baycix.de> <46540DAC.3050003@CC.UniVie.ac.at> <20070523115600.X32663@mignon.ki.iif.hu> Message-ID: <4655967F.602@ripe.net> Dear Janos, Please see below a presentation from RIPE 53, in which you can find statistics about PI address space assignments http://www.ripe.net/ripe/meetings/ripe-53/presentations/address_space.pdf May you required more information, do not hesitate to contact us Regards, Flor de Maria Paredes Mattos Registration Services Manager RIPE NCC Mohacsi Janos wrote: > On Wed, 23 May 2007, Wilfried Woeber, UniVie/ACOnet wrote: > >> Sascha, >> >> Sascha Lenz wrote: >> >> [...] >> >>> P.S.: Anyone got any recent numbers about the percentage of PI >>> announcements in the table vs. PA announcements + deaggregates? >>> >> that's probably not the fully adequate answer, but I considered the >> info in the following two slides (page 9 and 10) as very interesting >> in this context: >> >> http://www.ripe.net/ripe/meetings/ripe-54/presentations/RIPE_NCC_Statistics.pdf >> >> >> The bottom line is that the # of PI assignments has (considerably) >> surpassed the number of PA assignments since 2003, and that the load >> on the >> routing table for PI is thus bigger than for PA, although the >> *percentage* of >> PI space as compared to PA is approx. 2%. >> >> Or, the other way 'round, we use more than 50% of (additional) >> routing table >> slots for some 2% of address space (PI) and less than 50% for some >> 98% of PA. > > Are there similar statistics in the other RIR area? If the picture is > similar we have in RIPE region, then we have think over PI address > policy.... > > Only my 2 cents.... > > Janos Mohacsi > Network Engineer, Research Associate, Head of Network Planning and > Projects > NIIF/HUNGARNET, HUNGARY > Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 > From son at apnic.net Thu May 24 15:40:36 2007 From: son at apnic.net (Son Tran) Date: Thu, 24 May 2007 23:40:36 +1000 Subject: Did CIDR teach us nothing? was: Re: [address-policy-wg] 2006-01 Discussion Period extended until 19 June 2007 (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: <20070523115600.X32663@mignon.ki.iif.hu> References: <20070522130214.99CC72F583@herring.ripe.net> <46538FF0.80306@baycix.de> <465409C0.3050103@baycix.de> <46540DAC.3050003@CC.UniVie.ac.at> <20070523115600.X32663@mignon.ki.iif.hu> Message-ID: <465595D4.8080705@apnic.net> Hi Mohacsi Here is the statistic for PI (assignment) vs PA (allocation) for APNIC region. If you need more information please let us know. Year Number of PI Number of PA 2000 23 354 2001 36 337 2002 44 282 2003 62 368 2004 68 478 2005 118 576 2006 103 727 2007 49 244 We don't have the PI policy until 2000. Regards Son Mohacsi Janos wrote: > > > > On Wed, 23 May 2007, Wilfried Woeber, UniVie/ACOnet wrote: > >> Sascha, >> >> Sascha Lenz wrote: >> >> [...] >> >>> P.S.: Anyone got any recent numbers about the percentage of PI >>> announcements in the table vs. PA announcements + deaggregates? >>> >> that's probably not the fully adequate answer, but I considered the >> info in the following two slides (page 9 and 10) as very interesting >> in this context: >> >> http://www.ripe.net/ripe/meetings/ripe-54/presentations/RIPE_NCC_Statistics.pdf >> >> >> The bottom line is that the # of PI assignments has (considerably) >> surpassed the number of PA assignments since 2003, and that the load >> on the >> routing table for PI is thus bigger than for PA, although the >> *percentage* of >> PI space as compared to PA is approx. 2%. >> >> Or, the other way 'round, we use more than 50% of (additional) routing >> table >> slots for some 2% of address space (PI) and less than 50% for some 98% >> of PA. > > Are there similar statistics in the other RIR area? If the picture is > similar we have in RIPE region, then we have think over PI address > policy.... > > Only my 2 cents.... > > Janos Mohacsi > Network Engineer, Research Associate, Head of Network Planning and Projects > NIIF/HUNGARNET, HUNGARY > Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 > -- -------------------------------------------------------------------- Son Tran email: son at apnic.net Policy Development Manager, APNIC sip: son at voip.apnic.net http://www.apnic.net phone: +61 7 3858 3100 fax: +61 7 3858 3199 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3405 bytes Desc: S/MIME Cryptographic Signature URL: From patara at lacnic.net Thu May 24 22:13:57 2007 From: patara at lacnic.net (Ricardo Patara) Date: Thu, 24 May 2007 17:13:57 -0300 Subject: Did CIDR teach us nothing? was: Re: [address-policy-wg] 2006-01 Discussion Period extended until 19 June 2007 (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: <20070523115600.X32663@mignon.ki.iif.hu> References: <20070522130214.99CC72F583@herring.ripe.net> <46538FF0.80306@baycix.de> <465409C0.3050103@baycix.de> <46540DAC.3050003@CC.UniVie.ac.at> <20070523115600.X32663@mignon.ki.iif.hu> Message-ID: <20070524171357.57704ec7@marvin> hi > Are there similar statistics in the other RIR area? If the picture is > similar we have in RIPE region, then we have think over PI address > policy.... > > Only my 2 cents.... > > Janos Mohacsi > Network Engineer, Research Associate, Head of Network Planning and Projects > NIIF/HUNGARNET, HUNGARY > Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 this would be the comparison between number of allocations with number of assignments in our region: Allocation 1999 11 2000 42 2001 74 2002 70 2003 104 2004 153 2005 157 2006 202 Assignment 1999 0 2000 7 2001 3 2002 2 2003 6 2004 9 2005 6 2006 14 ricardo patara LACNIC Registration Service Manager -- From iljitsch at muada.com Mon May 28 14:30:30 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 28 May 2007 14:30:30 +0200 Subject: [address-policy-wg] Those pesky ULAs again In-Reply-To: <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> Message-ID: <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> On 27-mei-2007, at 22:51, Stephen Sprunk wrote: > Thus spake "Iljitsch van Beijnum" >> On 15-mei-2007, at 9:57, JORDI PALET MARTINEZ wrote: >>> And the only way to control ULA-central is to have it within the >>> RIR system, >> >> How would that work in practice? Approximately 100% of all >> organizations use RFC 1918 space. Obviously one use for >> RFC 1918 space goes away with IPv6 (NAT) but I'd say that >> the number of internet users requiring some kind of local >> addressing will still be 10, 20, 30 or more percent. The RIR >> membership is measured in thousands. > > All correct. > >> So tens of thousands or even hundreds of thousands of >> organizations that may want ULA-c space have no relationship >> with an RIR. They may not even have a relationship with an ISP... >> So how are the RIRs supposed to manage their relationship >> with 10 or 100 times as many people as they have relationships >> with now? > You have the flawed assumption that everyone who uses RFC1918 space > today will want/need ULA-C in the future. No, what I said was: >> Approximately 100% of all >> organizations use RFC 1918 space. Obviously one use for >> RFC 1918 space goes away with IPv6 (NAT) but I'd say that >> the number of internet users requiring some kind of local >> addressing will still be 10, 20, 30 or more percent. > The vast majority of folks will be fine with ULA-L Most people aren't very good with statistics, knowing for sure you have unique space is better than having just a 99.9999% probability that it's unique. > (or PA) space PA or PI is irrelevant to this discussion, people who need ULA may not even connect to the internet, and if they do, they need this space in ADDITION to routable address space, regardless of the type. > and the target market for ULA-C is identical to the target market > for PIv6. Nonsense. > so the debate comes down to why we want to put orgs on ULA-C space > instead of just giving them PI space. No-brainer: ULA-C space doesn't use up routing table slots. > If they're truly going to use it privately, they won't consume > routing slots in the DFZ, and if they aren't they'll be using PIv6 > anyways and won't have a need for ULA-C. You are being ridiculous. There is no connection between ULA-C and PI. Everyone can get ULA, not everyone can get PI. And ULA is even more important for people who have PA because that way they can have their internal infrastructure on stable addresses even when their routable address space is renumbered. Also, with IPv4, it's very common to use RFC 1918 space for internal infrastructure that must not be reachable from the internet. It's much more convenient to use unroutable address space for this rather than routable address space that is filtered. > there is significant risk that ULA-C will end up not being > "private" because there will be a set of ISPs that agree to route > the space for a fee. If that set grows to critical mass, ULA-C > will be no different than PIv6 anyways. I don't see the problem. We agree that routing ULA space is a bad idea. However, if someone is prepared to give me enough money to change my mind, how can that possibly be a problem? Or do you want to protect yourself from your own greed? From randy at psg.com Tue May 29 05:44:57 2007 From: randy at psg.com (Randy Bush) Date: Mon, 28 May 2007 17:44:57 -1000 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> Message-ID: <465BA1B9.1060003@psg.com> ok, i give. if ula address space is assigned/managed by registries, how is it actually different from pi space? if ipv6 space is effectively infinite (and we once thought ipv4 space was), then what is the use of ula address space? why not just assign vanilla ipv6 space? i am very confused by all the smoke and am trying to find the core of this stuff. randy From s.steffann at computel.nl Tue May 29 10:21:43 2007 From: s.steffann at computel.nl (Sander Steffann) Date: Tue, 29 May 2007 10:21:43 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <465BA1B9.1060003@psg.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> Message-ID: <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> Hi Randy, > ok, i give. if ula address space is assigned/managed by > registries, how is it actually different from pi space? Basically ULA space has the same 'routability' as RFC1918 space, with the added benefit of less (or in case of ULA central: no) possibility for conflicting addresses when merging/connecting separate networks. PI space is expected to be routed globally (if the user of the space wants to). > if ipv6 space is effectively infinite (and we once thought ipv4 space > was), then what is the use of ula address space? why not just assign > vanilla ipv6 space? At this moment there is no IPv6 PI spa From s.steffann at computel.nl Tue May 29 10:26:01 2007 From: s.steffann at computel.nl (Sander Steffann) Date: Tue, 29 May 2007 10:26:01 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <465BA1B9.1060003@psg.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> Message-ID: <031c01c7a1ca$fdc94400$dc128953@kantoor.computel.nl> Note: soryr for the previous message, I hit the wrong key and sent it by accident Hi Randy, > ok, i give. if ula address space is assigned/managed by > registries, how is it actually different from pi space? Basically ULA space has the same 'routability' as RFC1918 space, with the added benefit of less (or in case of ULA central: no) possibility for conflicting addresses when merging/connecting separate networks. PI space is expected to be routed globally (if the user of the space wants to). > if ipv6 space is effectively infinite (and we once thought ipv4 space > was), then what is the use of ula address space? why not just assign > vanilla ipv6 space? At this moment there is no IPv6 PI space (yet) in the RIPE region. When there is PI space, there will maybe be recurring costs for it (RIPE policy proposal 2007-01 is in discussion now). ULA space is free to use and has a low possibility of conflicts, and ULA Central will probably have one-time fee and is globally unique. So the main reason will probably be cost... - Sander From randy at psg.com Tue May 29 10:26:19 2007 From: randy at psg.com (Randy Bush) Date: Mon, 28 May 2007 22:26:19 -1000 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> Message-ID: <465BE3AB.8040305@psg.com> >> ok, i give. if ula address space is assigned/managed by >> registries, how is it actually different from pi space? > Basically ULA space has the same 'routability' as RFC1918 space which is a benefit because ...? rfc 1918 space is a hack to deal with an address space shortage. we are told ipv6 space is effectively infinite. hence we do not need rfc 1918 style space. > with the added benefit of less (or in case of ULA central: no) > possibility for conflicting addresses when merging/connecting > separate networks. because, in statistical hope, it will not overlap. i.e. it does not even conserve space a la 1918. so, again, what's the benefit? > PI space is expected to be routed globally (if the user of the space > wants to). as has been amply demonstrated, 1918 space leaks time and again. so this ula stuff will leak time and again. >> if ipv6 space is effectively infinite (and we once thought ipv4 >> space was), then what is the use of ula address space? why not >> just assign vanilla ipv6 space? > At this moment there is no IPv6 PI spa so we do this kinky thing to create a half-assed version of it? pfui! randy From jeroen at unfix.org Tue May 29 11:01:15 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 29 May 2007 10:01:15 +0100 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <465BE3AB.8040305@psg.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> Message-ID: <465BEBDB.2070200@spaghetti.zurich.ibm.com> (Tony, what where the exact thoughts about the below) Randy Bush wrote: >>> ok, i give. if ula address space is assigned/managed by >>> registries, how is it actually different from pi space? >> Basically ULA space has the same 'routability' as RFC1918 space > > which is a benefit because ...? rfc 1918 space is a hack to deal with > an address space shortage. we are told ipv6 space is effectively > infinite. hence we do not need rfc 1918 style space. The only 'real' benefit I heared up to now was iirc from Tony Hain who mentioned that it might in corporate cases be handy to be able to simply have ULA-Central space as the space that is used internally, and possibly by partner organizations linking in. Thus that you use fc00::/8 on internal + interconnected networks. While using other spaces on the internet (that big public thing). The main advantage is that firewalling becomes easier, as you know that space under fc00::/8 is internal and thus from another company. Splitting routing, doing firewalling etc thus becomes easier as you know what is public and what is not. [..] >> PI space is expected to be routed globally (if the user of the space >> wants to). > > as has been amply demonstrated, 1918 space leaks time and again. so > this ula stuff will leak time and again. ULA space should be !A'ed out by routers per default and have a special switch to enable forwarding for them. Security folks will be quite happy with that too I guess. >>> if ipv6 space is effectively infinite (and we once thought ipv4 >>> space was), then what is the use of ula address space? why not >>> just assign vanilla ipv6 space? IMHO there should not be a distinction between "PI" and "PA" space. Both will be broken up into blocks for "Traffic Engineering" purposes and other such things anyway, as can already be seen in BGP today. It should all simply be 'address space' and the size of the block received from the RIR should be based on the amount of address space they can justify and where possible only 1 such block per organization. The latter is unrealistic too as when an organization breaks up they might want to split that block etc yadiyadi. The only folks who can really stop that from happening is the ISP's themselves. Any organization with enough cash or importance can get any block fairly well routed onto the Internet. Lots of ISP's will protest, but to keep customers they will bend over anyway. If an ISP wants to keep the number of routes they accept low, they can already do this easily by taking all the inet6num's which have been delegated directly from the RIR's and use those to build filters. Filter list will be insanely large, but then you have the minimum you want to accept. Currently the classification between PA/PI sort of helps there as PA is From randy at psg.com Tue May 29 11:09:10 2007 From: randy at psg.com (Randy Bush) Date: Mon, 28 May 2007 23:09:10 -1000 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <465BEBDB.2070200@spaghetti.zurich.ibm.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <465BEBDB.2070200@spaghetti.zurich.ibm.com> Message-ID: <465BEDB6.3070109@psg.com> > ULA space should be !A'ed out by routers per default and have a > special switch to enable forwarding for them. oh, site-local. i remember that disaster. no wonder the internet-draft was stuffed. as i just told someone else in private email. you are asking that routers hard code the association between routability and address space. and next you only want this at site border routers and not 'internal' routers. this was called site-local, and was soundly rejected as a disaster in the making. use global space and filter your routing announcements and packets. randy From randy at psg.com Tue May 29 11:12:34 2007 From: randy at psg.com (Randy Bush) Date: Mon, 28 May 2007 23:12:34 -1000 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <465BEDB6.3070109@psg.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <465BEBDB.2070200@spaghetti.zurich.ibm.com> <465BEDB6.3070109@psg.com> Message-ID: <465BEE82.4000108@psg.com> Randy Bush wrote: >> ULA space should be !A'ed out by routers per default and have a >> special switch to enable forwarding for them. > oh, site-local. i remember that disaster. no wonder the internet-draft > was stuffed. RFC 1925 2(11) ?Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works.? randy From shane at time-travellers.org Tue May 29 11:18:05 2007 From: shane at time-travellers.org (Shane Kerr) Date: Tue, 29 May 2007 11:18:05 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <465BE3AB.8040305@psg.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> Message-ID: <20070529091805.GA15655@borg.c-l-i.net> Randy, On Mon, May 28, 2007 at 10:26:19PM -1000, Randy Bush wrote: > >> ok, i give. if ula address space is assigned/managed by > >> registries, how is it actually different from pi space? > > Basically ULA space has the same 'routability' as RFC1918 space > > which is a benefit because ...? rfc 1918 space is a hack to deal > with an address space shortage. we are told ipv6 space is > effectively infinite. hence we do not need rfc 1918 style space. The advantage of RFC 1918 space that ULA (non-central) provides is you don't have to talk to anyone to get your addresses. This is nice for things like labs, prototype environments, people who just want to use IPv6 within their home/office but don't have IPv6 connectivity, and so on. This advantage will get smaller over time, as most people will have a /48 from their Internet provider "by default", and can use that space for disconnected environments; 65536 is a lot of lab networks! :) There are no advantages to ULA (central), as I see it. Which is why I oppose it. -- Shane From randy at psg.com Tue May 29 11:20:24 2007 From: randy at psg.com (Randy Bush) Date: Mon, 28 May 2007 23:20:24 -1000 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <20070529091805.GA15655@borg.c-l-i.net> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> Message-ID: <465BF058.2090109@psg.com> [ arin dropped from cc:s as this is a local joke ] > The advantage of RFC 1918 space that ULA (non-central) provides is you > don't have to talk to anyone to get your addresses. italian isps seem to have figured out how to do that long ago :) randy From iljitsch at muada.com Tue May 29 11:31:14 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 29 May 2007 11:31:14 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <20070529091805.GA15655@borg.c-l-i.net> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> Message-ID: On 29-mei-2007, at 11:18, Shane Kerr wrote: > There are no advantages to ULA (central), as I see it. Which is why I > oppose it. It troubles me that so many people are willing to deprive others of something that those others consider useful just because they themselves don't find that thing useful. Quote from dr. Phil: "If your kid wakes up at night and says 'daddy I'm thirsty can I get some water' you don't say 'I'm not thirsty, you don't need water', you give the kid a glass of water. Everyone has different needs." From shane at time-travellers.org Tue May 29 12:00:00 2007 From: shane at time-travellers.org (Shane Kerr) Date: Tue, 29 May 2007 12:00:00 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> Message-ID: <20070529100000.GA16216@borg.c-l-i.net> On Tue, May 29, 2007 at 11:31:14AM +0200, Iljitsch van Beijnum wrote: > On 29-mei-2007, at 11:18, Shane Kerr wrote: > > >There are no advantages to ULA (central), as I see it. Which is why > >I oppose it. > > It troubles me that so many people are willing to deprive others of > something that those others consider useful just because they > themselves don't find that thing useful. If something is not useful to me, but might be useful to others, I generally don't oppose it. But I do not think ULA central is useful to anyone. Even if ULA central is useful, I don't think it is something the RIRs need to be involved in. If you insist on ULA central, my preferred implementation is a web page where you click on a button that says "give me a ULA prefix" and it allocates a random prefix that is not in use, and prints it on the screen. The only implementation question I'm not sure about is whether the list of allocated prefixes would be public or not; I lean towards making it public, although there is a (small) privacy concern. I think the cost of this implementation is low enough you could find a group of volunteers to host the system. -- Shane From gert at space.net Tue May 29 12:06:25 2007 From: gert at space.net (Gert Doering) Date: Tue, 29 May 2007 12:06:25 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <465BEE82.4000108@psg.com> References: <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <465BEBDB.2070200@spaghetti.zurich.ibm.com> <465BEDB6.3070109@psg.com> <465BEE82.4000108@psg.com> Message-ID: <20070529100625.GJ69215@Space.Net> Hi, On Mon, May 28, 2007 at 11:12:34PM -1000, Randy Bush wrote: > Randy Bush wrote: > >> ULA space should be !A'ed out by routers per default and have a > >> special switch to enable forwarding for them. > > oh, site-local. i remember that disaster. no wonder the internet-draft > > was stuffed. > > RFC 1925 2(11) ?Every old idea will be proposed again with a different > name and a different presentation, regardless of whether it works.? Actually there is a difference - site-locals are not unique between different sites that might be linked privately, eventually. I wasn't there when site-local was killed, but from what I understand, the "uniqueness" and "where is a site border?" arguments where the ones that people had most issues with. ULAs do solve this - but indeed, having PI space easily available would take away the need for "give me internal addresses that I do not want to see globally routed". OTOH, folks are afraid of PI, so ULAs are a possible answer to the question "how can I get address space for internal use, which is never meant to be visible on 'the global Internet'?". I agree with you that any sort of "hard-code filter in router software" is something to recommend to your competition :-) (after all, even if ULAs are not supposed to be "globally" routable, they *are* supposed to be used for private connetions between enterprises, and how is the router supposed to tell the difference?). Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 113403 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 iljitsch at muada.com Tue May 29 12:17:21 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 29 May 2007 12:17:21 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <20070529100000.GA16216@borg.c-l-i.net> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <20070529100000.GA16216@borg.c-l-i.net> Message-ID: <24EB3E8F-7E8F-43B1-92FC-2EDB8D079128@muada.com> On 29-mei-2007, at 12:00, Shane Kerr wrote: >> It troubles me that so many people are willing to deprive others of >> something that those others consider useful just because they >> themselves don't find that thing useful. > If something is not useful to me, but might be useful to others, I > generally don't oppose it. > But I do not think ULA central is useful to anyone. People have come out and said it's useful to them, so you are putting your judgment ahead of theirs. > Even if ULA central is useful, I don't think it is something the RIRs > need to be involved in. On that, we agree. > If you insist on ULA central, my preferred implementation is a web > page where you click on a button that says "give me a ULA prefix" and > it allocates a random prefix that is not in use, and prints it on the > screen. The only implementation question I'm not sure about is whether > the list of allocated prefixes would be public or not; I lean towards > making it public, although there is a (small) privacy concern. I think > the cost of this implementation is low enough you could find a group > of volunteers to host the system. I think a mechanism similar to IEEE MAC addresses would be good: organizations can buy a block for a price that's large enough to cover the costs of maintaining the IANA registry and also high enough to make sure people aren't going to buy unreasonable quantities ($/eu 1000 - 5000 or so for a block of a million /48s seems about right) and then the block holders can then redistribute the individual ULA prefixes in any way they see fit. Presumably, end-users would buy their prefixes from distributors that have a good system for enforcing uniqueness in place, but this can be traded off against other needs. From hisham at afrinic.net Tue May 29 11:43:53 2007 From: hisham at afrinic.net (Hisham R Rojoa) Date: Tue, 29 May 2007 13:43:53 +0400 Subject: Did CIDR teach us nothing? was: Re: [address-policy-wg] 2006-01 Discussion Period extended until 19 June 2007 (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: <20070524171357.57704ec7@marvin> Message-ID: <010d01c7a1d5$e15c3150$1d0001c4@DDVHC72J> Mohacsi Janos wrote thus on 05/23/2007 01:59 PM: > > Are there similar statistics in the other RIR area? If the > picture is similar we have in RIPE region, then we have > think over PI address policy.... If this helps, here is some data from the AfriNIC region: ------------------------------------------------------------------------ Year '98 '99 '00 '01 '02 '03 '04 '05 '06 ------------------------------------------------------------------------ PI /16 0 0 0 0.09 0.33 0.34 0.18 1.41 1.74 PA /16 1.81 1.13 3.88 5.81 3.70 3.06 7.58 14.36 39.82 ------------------------------------------------------------------------ rgds ernest -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Ricardo Patara Sent: 25 May 2007 00:14 To: Mohacsi Janos Cc: Wilfried Woeber, UniVie/ACOnet; Sascha Lenz; address-policy-wg at ripe.net Subject: Re: Did CIDR teach us nothing? was: Re: [address-policy-wg] 2006-01 Discussion Period extended until 19 June 2007 (Provider Independent (PI) IPv6 Assignments for End User Organisations) hi > Are there similar statistics in the other RIR area? If the picture is > similar we have in RIPE region, then we have think over PI address > policy.... > > Only my 2 cents.... > > Janos Mohacsi > Network Engineer, Research Associate, Head of Network Planning and > Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A > 145F 4300 6F64 7B00 70EF 9882 this would be the comparison between number of allocations with number of assignments in our region: Allocation 1999 11 2000 42 2001 74 2002 70 2003 104 2004 153 2005 157 2006 202 Assignment 1999 0 2000 7 2001 3 2002 2 2003 6 2004 9 2005 6 2006 14 ricardo patara LACNIC Registration Service Manager -- -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.467 / Virus Database: 269.8.0/817 - Release Date: 24/05/2007 16:01 From gert at space.net Tue May 29 12:56:20 2007 From: gert at space.net (Gert Doering) Date: Tue, 29 May 2007 12:56:20 +0200 Subject: Did CIDR teach us nothing? was: Re: [address-policy-wg] 2006-01 Discussion Period extended until 19 June 2007 (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: <010d01c7a1d5$e15c3150$1d0001c4@DDVHC72J> References: <20070524171357.57704ec7@marvin> <010d01c7a1d5$e15c3150$1d0001c4@DDVHC72J> Message-ID: <20070529105620.GM69215@Space.Net> Hi, On Tue, May 29, 2007 at 01:43:53PM +0400, Hisham R Rojoa wrote: > If this helps, here is some data from the AfriNIC region: > > ------------------------------------------------------------------------ > Year '98 '99 '00 '01 '02 '03 '04 '05 '06 > ------------------------------------------------------------------------ > PI /16 0 0 0 0.09 0.33 0.34 0.18 1.41 1.74 > PA /16 1.81 1.13 3.88 5.81 3.70 3.06 7.58 14.36 39.82 > ------------------------------------------------------------------------ Actually, the *number* of allocations would be more relevant for PI vs. PA than the sheer size. In the RIPE region, we have seen that there is much less *space* being used for PI - but it is much more fragmented, thus causing more pain in the routing tables. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 113403 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 Woeber at CC.UniVie.ac.at Tue May 29 13:08:49 2007 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 29 May 2007 11:08:49 +0000 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <20070529100000.GA16216@borg.c-l-i.net> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <20070529100000.GA16216@borg.c-l-i.net> Message-ID: <465C09C1.8050903@CC.UniVie.ac.at> Shane Kerr wrote: [...] > > If you insist on ULA central, my preferred implementation is a web > page where you click on a button that says "give me a ULA prefix" and > it allocates a random prefix that is not in use, and prints it on the > screen. The only implementation question I'm not sure about is whether > the list of allocated prefixes would be public or not; I lean towards > making it public, although there is a (small) privacy concern. I think > the cost of this implementation is low enough you could find a group > of volunteers to host the system. My take on this is that (general) ULA is supposed to provide access to "almost" unique prefixes. This can be managed in a distributed way. The "central" thing is supposed to take care of the 10^- chance that your's is used by someone else, too. Thus it is only (more) useful (than general ULA) if the distribution environment can guarantee uniqueness. Such a guarantee involves management and review, and complaint handling - eventually, plus protection against DoS-Attempts and legal protection. I am not convinced that a simple (=cheap / for free) mechanism is "good enough". > -- > Shane Wilfried. From jordi.palet at consulintel.es Tue May 29 13:18:39 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Tue, 29 May 2007 13:18:39 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <465C09C1.8050903@CC.UniVie.ac.at> Message-ID: Agree, and in addition to that, I'm convinced that it is not good at all that somebody else different than the RIRs start allocating addresses. Regards, Jordi > De: "Wilfried Woeber, UniVie/ACOnet" > Organizaci?n: UniVie - ACOnet > Responder a: > Fecha: Tue, 29 May 2007 11:08:49 +0000 > Para: Shane Kerr > CC: , "address-policy-wg at ripe.net" > Asunto: Re: [ppml] [address-policy-wg] Those pesky ULAs again > > Shane Kerr wrote: > > [...] >> >> If you insist on ULA central, my preferred implementation is a web >> page where you click on a button that says "give me a ULA prefix" and >> it allocates a random prefix that is not in use, and prints it on the >> screen. The only implementation question I'm not sure about is whether >> the list of allocated prefixes would be public or not; I lean towards >> making it public, although there is a (small) privacy concern. I think >> the cost of this implementation is low enough you could find a group >> of volunteers to host the system. > > My take on this is that (general) ULA is supposed to provide access > to "almost" unique prefixes. This can be managed in a distributed way. > > The "central" thing is supposed to take care of the 10^- > chance that your's is used by someone else, too. Thus it is only (more) > useful (than general ULA) if the distribution environment can guarantee > uniqueness. > > Such a guarantee involves management and review, and complaint handling > - eventually, plus protection against DoS-Attempts and legal protection. > I am not convinced that a simple (=cheap / for free) mechanism is "good > enough". > >> -- >> Shane > > Wilfried. > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From Woeber at CC.UniVie.ac.at Tue May 29 13:28:05 2007 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 29 May 2007 11:28:05 +0000 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: References: Message-ID: <465C0E45.5030800@CC.UniVie.ac.at> JORDI PALET MARTINEZ wrote: > Agree, and in addition to that, I'm convinced that it is not good at all > that somebody else different than the RIRs start allocating addresses. > > Regards, > Jordi Well, it depends.... As long as the operation (i.e. the resource access policies) of the RIRs is mostly influenced by the existing user community (ISPs and other *existing* stakeholders) I can understand people to argue in favour of establishing alternatives. But that is partially off-topic in this context. Wilfried. From iljitsch at muada.com Tue May 29 12:17:21 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 29 May 2007 12:17:21 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <20070529100000.GA16216@borg.c-l-i.net> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <20070529100000.GA16216@borg.c-l-i.net> Message-ID: <24EB3E8F-7E8F-43B1-92FC-2EDB8D079128@muada.com> On 29-mei-2007, at 12:00, Shane Kerr wrote: >> It troubles me that so many people are willing to deprive others of >> something that those others consider useful just because they >> themselves don't find that thing useful. > If something is not useful to me, but might be useful to others, I > generally don't oppose it. > But I do not think ULA central is useful to anyone. People have come out and said it's useful to them, so you are putting your judgment ahead of theirs. > Even if ULA central is useful, I don't think it is something the RIRs > need to be involved in. On that, we agree. > If you insist on ULA central, my preferred implementation is a web > page where you click on a button that says "give me a ULA prefix" and > it allocates a random prefix that is not in use, and prints it on the > screen. The only implementation question I'm not sure about is whether > the list of allocated prefixes would be public or not; I lean towards > making it public, although there is a (small) privacy concern. I think > the cost of this implementation is low enough you could find a group > of volunteers to host the system. I think a mechanism similar to IEEE MAC addresses would be good: organizations can buy a block for a price that's large enough to cover the costs of maintaining the IANA registry and also high enough to make sure people aren't going to buy unreasonable quantities ($/eu 1000 - 5000 or so for a block of a million /48s seems about right) and then the block holders can then redistribute the individual ULA prefixes in any way they see fit. Presumably, end-users would buy their prefixes from distributors that have a good system for enforcing uniqueness in place, but this can be traded off against other needs. _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML at arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml From stephen at sprunk.org Sun May 27 22:51:41 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Sun, 27 May 2007 15:51:41 -0500 Subject: [ppml] [address-policy-wg] Re: article about IPv6 vs firewallsvs NAT in arstechnica (seen on slashdot) References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> Message-ID: <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> Thus spake "Iljitsch van Beijnum" > On 15-mei-2007, at 9:57, JORDI PALET MARTINEZ wrote: >> And the only way to control ULA-central is to have it within the >> RIR system, > > How would that work in practice? Approximately 100% of all > organizations use RFC 1918 space. Obviously one use for > RFC 1918 space goes away with IPv6 (NAT) but I'd say that > the number of internet users requiring some kind of local > addressing will still be 10, 20, 30 or more percent. The RIR > membership is measured in thousands. All correct. > So tens of thousands or even hundreds of thousands of > organizations that may want ULA-c space have no relationship > with an RIR. They may not even have a relationship with an ISP... > > So how are the RIRs supposed to manage their relationship > with 10 or 100 times as many people as they have relationships > with now? You have the flawed assumption that everyone who uses RFC1918 space today will want/need ULA-C in the future. The vast majority of folks will be fine with ULA-L (or PA) space, and the target market for ULA-C is identical to the target market for PIv6. It will be the same number of orgs regardless of which type of space they request, so the debate comes down to why we want to put orgs on ULA-C space instead of just giving them PI space. If they're truly going to use it privately, they won't consume routing slots in the DFZ, and if they aren't they'll be using PIv6 anyways and won't have a need for ULA-C. I object to making orgs second-class IPv6 citizens under the guise of "private" addresses, and there is significant risk that ULA-C will end up not being "private" because there will be a set of ISPs that agree to route the space for a fee. If that set grows to critical mass, ULA-C will be no different than PIv6 anyways. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From ernest at afrinic.net Mon May 28 08:07:37 2007 From: ernest at afrinic.net (Ernest Byaruhanga (AfriNIC)) Date: Mon, 28 May 2007 10:07:37 +0400 Subject: Did CIDR teach us nothing? was: Re: [address-policy-wg] 2006-01 Discussion Period extended until 19 June 2007 (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: <20070523115600.X32663@mignon.ki.iif.hu> References: <20070522130214.99CC72F583@herring.ripe.net> <46538FF0.80306@baycix.de> <465409C0.3050103@baycix.de> <46540DAC.3050003@CC.UniVie.ac.at> <20070523115600.X32663@mignon.ki.iif.hu> Message-ID: <465A71A9.2090800@afrinic.net> Mohacsi Janos wrote thus on 05/23/2007 01:59 PM: > > Are there similar statistics in the other RIR area? If the > picture is similar we have in RIPE region, then we have > think over PI address policy.... If this helps, here is some data from the AfriNIC region: ------------------------------------------------------------------------ Year '98 '99 '00 '01 '02 '03 '04 '05 '06 ------------------------------------------------------------------------ PI /16 0 0 0 0.09 0.33 0.34 0.18 1.41 1.74 PA /16 1.81 1.13 3.88 5.81 3.70 3.06 7.58 14.36 39.82 ------------------------------------------------------------------------ rgds ernest From roger at jorgensen.no Mon May 28 14:46:11 2007 From: roger at jorgensen.no (Roger =?iso-8859-1?Q?J=F8rgensen?=) Date: Mon, 28 May 2007 14:46:11 +0200 (CEST) Subject: [address-policy-wg] Those pesky ULAs again In-Reply-To: <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> Message-ID: <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> On man, mai 28, 2007 14:30, Iljitsch van Beijnum wrote: > On 27-mei-2007, at 22:51, Stephen Sprunk wrote: >> Thus spake "Iljitsch van Beijnum" >>> On 15-mei-2007, at 9:57, JORDI PALET MARTINEZ wrote: >>> Approximately 100% of all >>> organizations use RFC 1918 space. Obviously one use for >>> RFC 1918 space goes away with IPv6 (NAT) but I'd say that >>> the number of internet users requiring some kind of local >>> addressing will still be 10, 20, 30 or more percent. > >> The vast majority of folks will be fine with ULA-L > > Most people aren't very good with statistics, knowing for sure you > have unique space is better than having just a 99.9999% probability > that it's unique. not really, I work a place where we just can?t have any more collision of address space, we have a few options and ULA-central is the best. 1.) get ula-central and know for sure we won?t get into this issue ever again. 2.) administrate our own local version of ULA-central for the organization we co-operate with 3.) get RIR-space with all the add on administration and documentation... For me, only option 1.) is a real option, the other two are just work-around since we don?t need global routing of the address space in question. >> (or PA) space > > PA or PI is irrelevant to this discussion, people who need ULA may > not even connect to the internet, and if they do, they need this > space in ADDITION to routable address space, regardless of the type. this go for the type of organization I work for. We have our own /32 already and it suite our need for public address space just fine given the 3 options above. >> and the target market for ULA-C is identical to the target market >> for PIv6. > Nonsense. Not often but sometimes I agree with Iljitsch, this is one of them. PI or no PI, PA or PI are completly irrelevant when we talk about the need for ULA-central or not. ULA-central will satisfy a need for non-routable address space that some bigger organization have. ULA-local are just a no go even with a 99,99999% chance of no collision at all. Or to put it in another context, renumbering or any change, experimentation or downtime of the infrastructure are just not an option when we?re talking about medicial/health related equipment. >> so the debate comes down to why we want to put orgs on ULA-C space >> instead of just giving them PI space. > No-brainer: ULA-C space doesn't use up routing table slots. see above, PI or PA have nothing todo in the discussion of ULA-C or not. Site-local, the one that got deprecated would have suited OUR (where I work) just fine but it isn?t there so we need a replacement and ULA-C is what we would need. >> If they're truly going to use it privately, they won't consume >> routing slots in the DFZ, and if they aren't they'll be using PIv6 >> anyways and won't have a need for ULA-C. > > You are being ridiculous. There is no connection between ULA-C and > PI. Everyone can get ULA, not everyone can get PI. And ULA is even > more important for people who have PA because that way they can have > their internal infrastructure on stable addresses even when their > routable address space is renumbered. Also, with IPv4, it's very > common to use RFC 1918 space for internal infrastructure that must > not be reachable from the internet. It's much more convenient to use > unroutable address space for this rather than routable address space > that is filtered. 100% correct for the organization I work for. We have in fact several very seperated network. To use RIR space, PI or PA for all of them is simply a waste since we don?t need global reachability for it. We just need _UNIQUE_ address space so we can when the need arrise connect any of them together. >> there is significant risk that ULA-C will end up not being >> "private" because there will be a set of ISPs that agree to route >> the space for a fee. If that set grows to critical mass, ULA-C >> will be no different than PIv6 anyways. > I don't see the problem. We agree that routing ULA space is a bad > idea. However, if someone is prepared to give me enough money to > change my mind, how can that possibly be a problem? Or do you want to > protect yourself from your own greed? I only have one thing to say, so what if the ISP agrees to route them? RIR space, PI or PA, give _global_ routability. ULA-C or ULA-Local give us the option to interconnect some closed network together anyway we want AND know it won?t get routed global. -- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger at jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- From stephen at sprunk.org Tue May 29 04:42:46 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 28 May 2007 21:42:46 -0500 Subject: [address-policy-wg] Those pesky ULAs again References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> Message-ID: <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> Thus spake "Roger J?rgensen" > On man, mai 28, 2007 14:30, Iljitsch van Beijnum wrote: >> On 27-mei-2007, at 22:51, Stephen Sprunk wrote: >>> The vast majority of folks will be fine with ULA-L >> >> Most people aren't very good with statistics, knowing for sure >> you have unique space is better than having just a 99.9999% >> probability that it's unique. > > not really, I work a place where we just can?t have any more > collision of address space, we have a few options and ULA- > central is the best. > > 1.) get ula-central and know for sure we won?t get into this > issue ever again. Unless the central administrator(s) screw up. The odds of that are non-zero, you know; in fact, as long as there's humans involved it's safe to say the odds are higher than a ULA-L collision. > 2.) administrate our own local version of ULA-central for > the organization we co-operate with Which is basically ULA-L, except that when someone new wants to join your private club, you'll need to spend a few seconds making sure they don't collide, and if they do (which is statistically unlikely, unless your club is on the scale of the public Internet) they'll need to renumber before they can join. > 3.) get RIR-space with all the add on administration and > documentation... The documentation is minimal unless you need a block larger than the minimum size, and the administration would be the same either way. > For me, only option 1.) is a real option, the other two are just > work-around since we don?t need global routing of the address > space in question. No, you've decided #1 is what you want, so you're downplaying its problems and potential harm to the community and criticizing all other options. >>> (or PA) space >> >> PA or PI is irrelevant to this discussion, people who need ULA >> may not even connect to the internet, and if they do, they need >> this space in ADDITION to routable address space, regardless >> of the type. > > this go for the type of organization I work for. We have our own > /32 already and it suite our need for public address space just > fine given the 3 options above. So why not carve out a /48, block it at your firewall to the public network, and get "local" addresses for free instead of paying for ULA-C? > ULA-central will satisfy a need for non-routable address space > that some bigger organization have. ULA-local are just a no go > even with a 99,99999% chance of no collision at all. Or to put it > in another context, renumbering or any change, experimentation > or downtime of the infrastructure are just not an option when > we?re talking about medicial/health related equipment. If you're in the medical field and your equipment can't withstand a few seconds of outage here and there (six nines = 31sec/yr downtime) without killing someone, you're going to have a lot of dead people on your hands. You and/or your vendors have failed. Networks have outages, period. In a typical network, most of them will be hardware-, circuit-, or design-related. I participated in a project for $BIG_TELCO and it took them several years of effort just to get from three nines to five nines consistently, and they never hit six nines. Nearly all of the remaining issues, when we were done, were due to humans making typos. If you think you're going to get to six (or more) nines of reliability, you're delusional in thinking that you're better at this than people literally throwing billions of dollars and thousands of engineers at the problem. Besides, renumbering should not cause any outages (at least more than what you normally see) unless your staff is incompetent. It's a lot of work, but it shouldn't cause an outage, much less death. >>> so the debate comes down to why we want to put orgs on >>> ULA-C space instead of just giving them PI space. >> >> No-brainer: ULA-C space doesn't use up routing table slots. > > see above, PI or PA have nothing todo in the discussion of > ULA-C or not. Yes, it does. If an org needs unique address space that will never appear in the DFZ, how does ULA-C meet their needs any better than PI? What is the purpose in creating yet another thing that needs to be registered when we already have two alternatives that fit every need I've seen proposed so far? > Site-local, the one that got deprecated would have suited OUR > (where I work) just fine but it isn?t there so we need a > replacement and ULA-C is what we would need. If SLAs would have worked for you, then you have no fundamental need for unique addresses and ULA-Ls are overkill, much less ULA-C. >>> If they're truly going to use it privately, they won't consume >>> routing slots in the DFZ, and if they aren't they'll be using PIv6 >>> anyways and won't have a need for ULA-C. >> >> You are being ridiculous. There is no connection between >> ULA-C and PI. Everyone can get ULA, not everyone can get PI. Anyone who is large enough to care about the extreme unlikelihood of collisions with ULA-L will be able to get PI, at least in ARIN's region. The bar is incredibly low; just about the only folks who don't qualify are people running home networks. And, for that matter, people can get a single PI block larger than /48, whereas someone who needs more than a /48 in ULA-C space would need multiple distinct blocks, presumably multiplying the fees to more than what PI costs. If your argument is that ULA-C will be cheaper, that is perhaps an argument that PI fees are too high -- not that anyone has stated if or how much cheaper ULA-C would be if it did pass. I have a hard time seeing anyone who has a legitimate need for ULA-C _or_ PI space whining about $100/yr. If they can't afford that, they can't afford anyone knowledgeable enough to care about the problems with ULA-L (or PA) space. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From roger at jorgensen.no Tue May 29 10:17:26 2007 From: roger at jorgensen.no (Roger =?iso-8859-1?Q?J=F8rgensen?=) Date: Tue, 29 May 2007 10:17:26 +0200 (CEST) Subject: [address-policy-wg] Those pesky ULAs again In-Reply-To: <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> Message-ID: <10709.83.108.102.34.1180426646.squirrel@webmail.e-konsult.no> On tir, mai 29, 2007 04:42, Stephen Sprunk wrote: > Thus spake "Roger J?rgensen" > Anyone who is large enough to care about the extreme unlikelihood of > collisions with ULA-L will be able to get PI, at least in ARIN's region. > The bar is incredibly low; just about the only folks who don't qualify are > people running home networks. And, for that matter, people can get a > single > PI block larger than /48, whereas someone who needs more than a /48 in > ULA-C > space would need multiple distinct blocks, presumably multiplying the fees > to more than what PI costs. without going into details, PA/PI space is really a waste to be used in a closed network that should never ever be directly connected to the public Internet. You can say we are building our own very closed version of Internet and other will be connected to us sooner or later. We need to know we have unique address space no mather how many other organization we connect with. > If your argument is that ULA-C will be cheaper, that is perhaps an > argument > that PI fees are too high -- not that anyone has stated if or how much > cheaper ULA-C would be if it did pass. I have a hard time seeing anyone > who > has a legitimate need for ULA-C _or_ PI space whining about $100/yr. If > they can't afford that, they can't afford anyone knowledgeable enough to > care about the problems with ULA-L (or PA) space. money isn?t on the table at all. It?s easier to get managment and other to understand that the addresses are unique with ULA-C than to explain how low the chances are to get a collission with ULA-L. It?s that easy. PI or PA or whatever you called it given out of the public routable address pool and to be used on a closed network is simply a waste. It?s that simple. -- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger at jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- From roger at jorgensen.no Tue May 29 10:29:25 2007 From: roger at jorgensen.no (Roger =?iso-8859-1?Q?J=F8rgensen?=) Date: Tue, 29 May 2007 10:29:25 +0200 (CEST) Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <465BA1B9.1060003@psg.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> Message-ID: <10933.83.108.102.34.1180427365.squirrel@webmail.e-konsult.no> On tir, mai 29, 2007 05:44, Randy Bush wrote: > if ipv6 space is effectively infinite (and we once thought ipv4 space > was), then what is the use of ula address space? why not just assign > vanilla ipv6 space? It?s not that infinite as people like to belive. We have something between 2^20 and 2^28 as the max number of global networks within the current structure of IPv6. It?s high but far from infinite. -- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger at jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- From hisham at afrinic.net Tue May 29 14:43:08 2007 From: hisham at afrinic.net (Hisham R Rojoa) Date: Tue, 29 May 2007 16:43:08 +0400 Subject: Did CIDR teach us nothing? was: Re: [address-policy-wg] 2006-01 Discussion Period extended until 19 June 2007 (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: <20070529105620.GM69215@Space.Net> Message-ID: <014b01c7a1ee$ecf50f00$1d0001c4@DDVHC72J> Please see below again for the AfriNIC region: ------------------------------------------------- '98 '99 '00 '01 '02 '03 '04 '05 '06 ------------------------------------------------- Alloc 10 8 27 28 21 20 43 82 105 Assigned 1 1 0 9 11 11 6 20 19 ------------------------------------------------- rgds ernest -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Gert Doering Sent: 29 May 2007 14:56 To: Hisham R Rojoa Cc: 'Ricardo Patara'; 'Mohacsi Janos'; 'Wilfried Woeber, UniVie/ACOnet'; 'Sascha Lenz'; address-policy-wg at ripe.net Subject: Re: Did CIDR teach us nothing? was: Re: [address-policy-wg] 2006-01 Discussion Period extended until 19 June 2007 (Provider Independent (PI) IPv6 Assignments for End User Organisations) Hi, On Tue, May 29, 2007 at 01:43:53PM +0400, Hisham R Rojoa wrote: > If this helps, here is some data from the AfriNIC region: > > ------------------------------------------------------------------------ > Year '98 '99 '00 '01 '02 '03 '04 '05 '06 > ------------------------------------------------------------------------ > PI /16 0 0 0 0.09 0.33 0.34 0.18 1.41 1.74 > PA /16 1.81 1.13 3.88 5.81 3.70 3.06 7.58 14.36 39.82 > ---------------------------------------------------------------------- > -- Actually, the *number* of allocations would be more relevant for PI vs. PA than the sheer size. In the RIPE region, we have seen that there is much less *space* being used for PI - but it is much more fragmented, thus causing more pain in the routing tables. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 113403 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 -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.472 / Virus Database: 269.8.1/822 - Release Date: 28/05/2007 11:40 From jorgen at hovland.cx Tue May 29 15:11:02 2007 From: jorgen at hovland.cx (=?utf-8?Q?J=C3=B8rgen_Hovland?=) Date: Tue, 29 May 2007 15:11:02 +0200 Subject: [address-policy-wg] Those pesky ULAs again In-Reply-To: <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> Message-ID: <6534CF9556E640FFB8565140862C0CFE@tungemaskin> -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Roger J?rgensen > 1.) get ula-central and know for sure we won?t get into this issue ever again. > >2.) administrate our own local version of ULA-central for the organization we co-operate with > >3.) get RIR-space with all the add on administration and documentation... > For me, only option 1.) is a real option, the other two are just > work-around since we don?t need global routing of the address space in > question. The RIRs already provide globally unique address space. This is what you want. Both ULA-C and the RIRs do not guarantee global routability anyway. ULA-L is never globally unique, so basically there is no such thing as "Unique Locally Assigned" addresses. Q: Is it correct that you can get a /26 IPv4 PA block, but you can't get a /96 IPv6 PA block? Why is that? Cheers, J From jordi.palet at consulintel.es Tue May 29 15:53:35 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Tue, 29 May 2007 15:53:35 +0200 Subject: [address-policy-wg] Those pesky ULAs again In-Reply-To: <6534CF9556E640FFB8565140862C0CFE@tungemaskin> Message-ID: The smaller subnet in IPv6, if you want to keep autoconfiguration and other things working, is /64, so why you want something smaller coming from the RIRs ? In addition to that, if you want to allow subneting for your customers and your own network, you need extra bits for that. So that's why typically you will get a minimum of /32 block from the RIR and customers will get a /48 from you. Regards, Jordi > De: J?rgen Hovland > Responder a: > Fecha: Tue, 29 May 2007 15:11:02 +0200 > Para: 'Roger J?rgensen' > CC: 'Stephen Sprunk' , 'ARIN PPML' , > > Asunto: RE: [address-policy-wg] Those pesky ULAs again > > > > -----Original Message----- > From: address-policy-wg-admin at ripe.net > [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Roger J?rgensen > >> 1.) get ula-central and know for sure we won?t get into this issue ever >> again. >> >> 2.) administrate our own local version of ULA-central for the organization we >> co-operate with >> >> 3.) get RIR-space with all the add on administration and documentation... >> For me, only option 1.) is a real option, the other two are just >> work-around since we don?t need global routing of the address space in >> question. > > > The RIRs already provide globally unique address space. This is what you want. > Both ULA-C and the RIRs do not guarantee global routability anyway. > > ULA-L is never globally unique, so basically there is no such thing as "Unique > Locally Assigned" addresses. > > > Q: Is it correct that you can get a /26 IPv4 PA block, but you can't get a /96 > IPv6 PA block? Why is that? > > Cheers, > > J > > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From randy at psg.com Tue May 29 16:49:38 2007 From: randy at psg.com (Randy Bush) Date: Tue, 29 May 2007 04:49:38 -1000 Subject: [address-policy-wg] Those pesky ULAs again In-Reply-To: <10709.83.108.102.34.1180426646.squirrel@webmail.e-konsult.no> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <10709.83.108.102.34.1180426646.squirrel@webmail.e-konsult.no> Message-ID: <465C3D82.90603@psg.com> > without going into details, PA/PI space is really a waste to be used in a > closed network that should never ever be directly connected to the public > Internet. You can say we are building our own very closed version of > Internet and other will be connected to us sooner or later. We need to > know we have unique address space no mather how many other organization we > connect with. and how is the ula *unique* address space different from pi/pa unique address space? randy From randy at psg.com Tue May 29 16:50:57 2007 From: randy at psg.com (Randy Bush) Date: Tue, 29 May 2007 04:50:57 -1000 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> Message-ID: <465C3DD1.50300@psg.com> >> There are no advantages to ULA (central), as I see it. Which is why I >> oppose it. > It troubles me that so many people are willing to deprive others of > something that those others consider useful just because they themselves > don't find that thing useful. nice emotional argument. all it lacks are technology and facts From s.steffann at computel.nl Tue May 29 16:55:44 2007 From: s.steffann at computel.nl (Sander Steffann) Date: Tue, 29 May 2007 16:55:44 +0200 Subject: [address-policy-wg] Those pesky ULAs again In-Reply-To: <465C3D82.90603@psg.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <10709.83.108.102.34.1180426646.squirrel@webmail.e-konsult.no> <465C3D82.90603@psg.com> Message-ID: <03b901c7a201$6f51fe60$dc128953@kantoor.computel.nl> Hi Randy, > and how is the ula *unique* address space different from pi/pa unique > address space? ULA space is supposed to be filtered on border routers. It's a kind of BCP: you should filter out ULA and route PI/PA. What you do is is ofcourse your own descision. - Sander From randy at psg.com Tue May 29 16:59:42 2007 From: randy at psg.com (Randy Bush) Date: Tue, 29 May 2007 04:59:42 -1000 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <20070529100000.GA16216@borg.c-l-i.net> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <20070529100000.GA16216@borg.c-l-i.net> Message-ID: <465C3FDE.7050708@psg.com> > If you insist on ULA central, my preferred implementation is a web > page where you click on a button that says "give me a ULA prefix" and > it allocates a random prefix that is not in use, and prints it on the > screen. sounds like a great idea for all of ipv6 allocation. what is the difference ula or pi/pa? randy From iljitsch at muada.com Tue May 29 18:58:47 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 29 May 2007 18:58:47 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <74CDAAB3-9267-43FA-9B8F-E84F91AFFAB0@delong.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <74CDAAB3-9267-43FA-9B8F-E84F91AFFAB0@delong.com> Message-ID: On 29-mei-2007, at 18:40, Owen DeLong wrote: > Advantages of ULA-C (even to those who claim there are some): > Virtually none. I'm sure you don't mind the plane renumbering in flight when it switches from one satellite connection to the next. Myself, I'd like to see the flight systems to have stable addressing regardless of the orientation of the satellite antennas. > Disadvantages of ULA-C: I can't believe you keep pounding on this dead horse. These are PRIVATE addresses. Period. From randy at psg.com Tue May 29 19:31:05 2007 From: randy at psg.com (Randy Bush) Date: Tue, 29 May 2007 07:31:05 -1000 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <20070529172557.GS5379@shell01.corp.tellme.com> References: <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <74CDAAB3-9267-43FA-9B8F-E84F91AFFAB0@delong.com> <20070529172557.GS5379@shell01.corp.tellme.com> Message-ID: <465C6359.7020508@psg.com> > ULA-C sounds to me like a request to the guys who spin silicon to help > people keep from screwing up their router configs. If someone can't > manage to filter their BGP such that they keep some (or all) of their > space private, I don't see why Cisco, Juniper, et al., need to do > that for them. or that the router vendors will do a more reliable job of it, given the complexity of knowing what is a site border and what is not, especially when folk are saying that there are actually multiple entities inside the border. and do we really want the vendors to hard-code address filters in the sillycone? this is the path on which site-local died, and the death was a good thing. RFC 1925 2(11) ?Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works.? randy From iljitsch at muada.com Tue May 29 19:32:27 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 29 May 2007 19:32:27 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <20070529172557.GS5379@shell01.corp.tellme.com> References: <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <74CDAAB3-9267-43FA-9B8F-E84F91AFFAB0@delong.com> <20070529172557.GS5379@shell01.corp.tellme.com> Message-ID: On 29-mei-2007, at 19:25, David Williamson wrote: >>> Disadvantages of ULA-C: >> I can't believe you keep pounding on this dead horse. These are >> PRIVATE addresses. Period. > Uh, neither of those reasons undermines the solution others have > proposed: use PI space. That's like saying people can use real money instead of monopoly money. I really don't get this. Did you guys bet a lot of money that there would never be ULA-C or something? If you don't like it, don't use it yourself and filter it, but PLEASE don't whine about it. From jeroen at unfix.org Tue May 29 19:51:19 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 29 May 2007 18:51:19 +0100 Subject: [address-policy-wg] ULA Registry Message-ID: <465C6817.4060701@spaghetti.zurich.ibm.com> [Major cross post, set reply-to to NANOG, please honor it... ] [Note: I am not talking about ULA Central here, though it could apply] To stop the pesky emails about ULA, I hereby present a (partial) solution to this problem. We have ULA as per RFC4193. With a little math one can generate a ULA prefix sized /48 which is most likely globally unique. According to the RFC with 10.000 connections the collision probability is still a huge 4.54*10^-05. Some people have expressed a problem with this, especially when they want to use the generated ULA prefix for their large organization. The simple, cheap and quick solution: a ULA registry. This comes close to ULA-Central, but what we do is simply make a list of the "in use" ULA's, without any allocation policies whatsoever except: first come first serve and no cash to pay. The tool is here: http://www.sixxs.net/tools/grh/ula/ The page allows one to generate a ULA based on a given MAC address (multicast + locally defined + unregistered are not accepted) and then register it. The Name + Email are mandatory to restrict abuse a little bit. Email is not shown, except in whois and can be used to possible contact people who are leaking ULA prefixes. Note, it is indeed a _partial_ solution. When somebody still generates the same ULA prefix and does not check the list you can still collide. As this is primarily a problem for big organizations, they should be checking this list for collisions and registering their prefix when they see that they have a need for that. The list is available from the website, but also per whois.sixxs.net which is now serving up fd00::/8. It does not cover ULA-C (fc00::/8). As SixXS is a private hobbyproject kind of thing, we of course are not liable for anything that this might cause to you, your family, company etc. But enjoy it nevertheless. Full copies of the list in inet6num format are available from the site. Greets, Jeroen PS: GRH still classifies ULA's as "BAD" of course PPS: Thanks to Peter van Dijk for the multicast/locally defined MACs PPPS: Folks registering prefixes like crazy will nicely get locked out automatically, so don't even try... PPPPS: Thanks to SUZUKI Shinsuke and Holger Zuleger for the generator. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From iljitsch at muada.com Tue May 29 20:59:15 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 29 May 2007 20:59:15 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <4161A246-5DD7-408B-A873-2E79BF420947@delong.com> References: <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <74CDAAB3-9267-43FA-9B8F-E84F91AFFAB0@delong.com> <20070529172557.GS5379@shell01.corp.tellme.com> <4161A246-5DD7-408B-A873-2E79BF420947@delong.com> Message-ID: <9D1FCE0E-816C-4AA9-B249-220B9C2EF3C0@muada.com> On 29-mei-2007, at 19:38, Owen DeLong wrote: >>> Uh, neither of those reasons undermines the solution others have >>> proposed: use PI space. >> That's like saying people can use real money instead of monopoly >> money. I really don't get this. Did you guys bet a lot of money >> that there would never be ULA-C or something? > Um, no. It's like saying that counterfeit money is bad and we'd > rather not > create a sponsored system for printing it. Your view that ULA-C is like counterfeit money while it's more like monopoly money nicely illustrates the entire point (or rather, pointlessness) of this discussion. On 29-mei-2007, at 19:39, David Williamson wrote: >> If you don't like it, don't use it yourself and filter it, but PLEASE >> don't whine about it. > Calling a debate "whining" is a bit rude. Whether DHCPv6 is better than stateless autoconfiguration is a debate. The people who think DHCPv6 is the way to go are wrong, but there is no harm in them thinking that: they can run DHCPv6 while I run stateless autoconfig and everyone is happy. The whole ULA-C thing is not a debate. The anti-group is trying to wear the pro-group down by repeating the same few arguments that don't make a whole lot of sense over and over, and try to deprive the pro-group from something that group feels is useful based on fear, uncertainty and doubt. It's bullying. > My "whining" isn't intended to change your mind - I don't think any > argument I make is likely to do that. My argument, however, is that > there's no problem solved by ULA-C that can't be solved by PI space, That's not really true, because ULA is recognizable as such, while PI space is presumed to be routable, even if routing it isn't desired. But more importantly, ULA-C would be exceedingly easy to get, while PI is exceedingly hard to get. > and the creation of ULA-C would entirely undermine the RIR-based PI > system. If only that were true. Unaggregatable PI is something we know can't work if widely deployed. But the realities of the RIR system are such that this is irrelevant. The only way ULA-C can effectively become PI is if everyone (for a large value of "everyone") accepts those advertisements. That will only happen if everyone thinks its a good idea, i.e., when you guys change your mind. Since there doesn't seem to be much danger of that happening (and people like me, who are also quite stubborn, are also against this) I don't see the problem. And IF we all change our minds, then obviously we'd have a good reason for that, wouldn't we? > If you seriously think that > ULA-C is entirely orthogonal to PI space, and will have zero impact > on the usage of PI space...well...we'll have to agree to disagree. You can agree to disagree on things that are a matter of opinion or believe. You can't agree to disagree on an engineering decision with global impact. > All of this, of course, distracts from the real underlying problem, as > Mr. Vixie points out. Identifier/locator split, you mean? There was no way they could have designed and implemented that successfully 25 years ago: not enough giants to stand on the shoulders of. We can probably do those parts now, but I'm not so sure about being able to deploy it, and if it's actually going to buy us something if we manage that. From randy at psg.com Tue May 29 16:59:42 2007 From: randy at psg.com (Randy Bush) Date: Tue, 29 May 2007 04:59:42 -1000 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <20070529100000.GA16216@borg.c-l-i.net> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <20070529100000.GA16216@borg.c-l-i.net> Message-ID: <465C3FDE.7050708@psg.com> > If you insist on ULA central, my preferred implementation is a web > page where you click on a button that says "give me a ULA prefix" and > it allocates a random prefix that is not in use, and prints it on the > screen. sounds like a great idea for all of ipv6 allocation. what is the difference ula or pi/pa? randy _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML at arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml From jordi.palet at consulintel.es Tue May 29 22:03:50 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Tue, 29 May 2007 22:03:50 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <20070529190802.GZ5379@shell01.corp.tellme.com> Message-ID: Agree, in ARIN region is not difficult to get, but in other two regions (LACNIC and RIPE NCC) is still impossible. However more difference to point to is that using PI for a function such as the one covered by ULA-Central is wasting space. It seems to me that this is quite contradictory for those folks that decided that /48 is too much for end sites and wanted to change it to /56. Some seems to be in favor of not "wasting" space, but when it comes to ULA-Central, the saving part is the less important one, even if implementing ULA-central will not damage at all to those that don't want to use it. Regards, Jordi > De: David Williamson > Responder a: > Fecha: Tue, 29 May 2007 12:08:02 -0700 > Para: Iljitsch van Beijnum > CC: ARIN PPML , "address-policy-wg at ripe.net" > > Asunto: Re: [ppml] [address-policy-wg] Those pesky ULAs again > > On Tue, May 29, 2007 at 08:59:15PM +0200, Iljitsch van Beijnum wrote: >> But more importantly, ULA-C would be exceedingly easy to get, while >> PI is exceedingly hard to get. > > I wasn't going to post again today to this list, but I cannot let > blatantly incorrect statements go by. PI is not hard to get, although > your experience may vary by region. My org holds a PI /48, and it > took me 2 days of duration and ten minutes of effort to receive it. > That's nearly trivial, in my book. > > -David > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From michael.dillon at bt.com Tue May 29 23:13:47 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 29 May 2007 22:13:47 +0100 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <74CDAAB3-9267-43FA-9B8F-E84F91AFFAB0@delong.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com><000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com><00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com><28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no><007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com><465BA1B9.1060003@psg.com><031b01c7a1ca$64904270$dc128953@kantoor.computel.nl><465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <74CDAAB3-9267-43FA-9B8F-E84F91AFFAB0@delong.com> Message-ID: > The policies for ULA-C are likely to be different from > the policies for PI. ULA-C doesn't exist. There is not even a current Internet draft to define what the acronym stands for. If any RIRs create a policy on that basis, then it will be the beginning of the end of the RIR system. The RIRs are supposed to be stewards, prudently managing a shared resource. --Michael Dillon From jordi.palet at consulintel.es Tue May 29 23:18:44 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Tue, 29 May 2007 23:18:44 +0200 Subject: [address-policy-wg] 2006-01 Discussion Period extended until 19 June 2007 (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: Message-ID: Hi Leo, See below, in-line. Regards, Jordi > De: Leo Vegoda > Responder a: > Fecha: Tue, 22 May 2007 17:00:37 -0400 > Para: "address-policy-wg at ripe.net" > CC: Jordi Palet Martinez > Asunto: Re: [address-policy-wg] 2006-01 Discussion Period extended until 19 > June 2007 (Provider Independent (PI) IPv6 Assignments for End User > Organisations) > > On 22 May 2007, at 9:02am, Filiz Yilmaz wrote: > >> PDP Number: 2006-01 >> Provider Independent (PI) IPv6 Assignments for End User Organisations >> >> Dear Colleagues >> >> The text of the policy proposal 2006-01 has changed. > > The new text has the following statement: > > "PI IPv6 Assignment Size to End User Organisations: > The minimum size of the assignment is /48. However, a larger > assignment (shorter prefix) can be provided if duly documented > and justified." > > I am not sure what documentation and justification is required to > qualify for a prefix shorter than a /48. What do I need to show the > RIPE NCC before they would be able to assign my network a /47? I just tried to keep it simple. I expect the Staff will use the same criteria they use today for providing, for example, a /31 instead of /32. > > It would be helpful to people considering requesting a PI IPv6 prefix > and the RIPE NCC if the policy gave a clear statement of what is > required. Not sure if that's so easy, and I'm not really sure is really needed. Do you have any idea ? We could also apply that "idea", may be, to the standard IPv6 allocation policy. It will be good to understand if the staff is having problems there, or it is just enough the way they are doing and it may be applied then here the same. > > Also, the proposed text does not define a maximum size for an IPv6 PI > assignment. When this is combined with a lack of definition for the > qualification requirements it seems that a /32 of IPv6 PI could be > assigned. Is that intended? Not at all, it is not intended to assign a /32. However, if the case justify it, we aren't closing the door. I really think it is difficult to find a case that could justify that, in fact probably is very difficult to justify cases that justify something shorter than /44, but you never know how big can be a data center or content provider, for example. > > Regards, > > -- > Leo Vegoda > IANA Numbers Liaison > > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From jordi.palet at consulintel.es Tue May 29 23:29:01 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Tue, 29 May 2007 23:29:01 +0200 Subject: [address-policy-wg] 2006-01 Discussion Period extended until 19 June 2007 (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: <46538FF0.80306@baycix.de> Message-ID: Hi Sascha, See below, in-line. Regards, Jordi > De: Sascha Lenz > Organizaci?n: BayCIX GmbH > Responder a: > Fecha: Wed, 23 May 2007 02:50:56 +0200 > Para: "address-policy-wg at ripe.net" > Asunto: Re: [address-policy-wg] 2006-01 Discussion Period extended until 19 > June 2007 (Provider Independent (PI) IPv6 Assignments for End User > Organisations) > > Hi, > > Filiz Yilmaz wrote: >> PDP Number: 2006-01 >> Provider Independent (PI) IPv6 Assignments for End User Organisations >> >> Dear Colleagues >> >> The text of the policy proposal 2006-01 has changed. >> >> We have published the new version today, as a result the discussion >> period for this proposal has been extended until 19 June 2007. > [...] > > for starters: > the link to Version 2.0 > > http://www.ripe.net/ripe/policies/proposals/2006-01_v2.pdf > > ("Submission date: ..Previous versions v1.0 and v2.0 are available as PDF") > does not work. > Some webmaster at RIPE might want to fix this :-) > > - > Then again, i'm a little puzzled about the most recent(?) changes. > I wonder if i missed something, or if the proposal finally got > completely useless, trying to find a consensus. > > Why do we concentrate on "multihoming" now as a requirement for > PI-addresses? That's not what "Provider Independent" means to me, even > if this is the most likely reason for such a request. I will prefer to have a policy proposal that can justify a criteria for *not only* multihoming, but it turned out that we can't find a way to objectively verify that (from the staff point of view). So I suggested in the last meeting starting, with this case, which is easy to justify in a criteria for the requester and my feeling was that the room agreed in that path. I think it is much better to cover at least some of the cases, instead of trying to cover all. So if you look to the target, right now is data centers and content providers, which are not ISPs. Presumably they are multihomend in 99.9% of the cases. Do you think other cases are not covered ? If so, do you have an idea of an alternative *objective* criteria ? > > What about those who just want a portable block, no renumbering? What will be the objective criteria for the staff to agree on that ? Typically who want to avoid renumbering is because it is multihomed. Do you see any other case ? > > Why include some routing-policy in an address-policy again? > Isn't it enough that the autonomous system request policy already > requires >=2 peers? What does that have to do with numbering in the > first place? Hmmm. If you are refering to: Assigning a /32 would make those blocks behave as other regular LIR allocated ones and follow generally accepted routing filtering practices. At the same time, the blocks would be identifiable as belonging to a special 'super block'. This would also allow organisations to become an LIR and avoid the need for renumbering. It is a mistake, that should have been removed from this version. > > Why isn't the only real thing we need, a contractual relationship of > some kind a and small recurring fee good enough? Why other artificial > barriers? If the rest of this group believe is ok, and staff also, I'm happy to go that way, but this is not what I heard from the last months discussions ! > > THERE IS NO ROUTING TABLE PROBLEM. > (you might shoot me if i'm proven wrong in 20years) > . o O(X-No-Archive: Yes :-}) > > Simple IPv6 PI Assignment policy: > > - Being an end-site, not (sub-)assigning address-space to third parties > - End-site explicitely states that PI addresses are desired for this > assignment and that they are aware of possible the impact of PI vs. PA > addresses > - PI request MUST be approved by the RIPE NCC, not by a LIR > - Maintaining a standardised contractual relationship with an active > RIPE LIR or the RIPE NCC directely for the lifetime of the assignment > - A recurring fee of 100EUR/y is charged from the RIPE NCC directely > or via the handling LIR > - RIPE NCC can revoke the assigment if the holder fails to pay the > recurring fee within 6 months after the payment is due or is getting > otherwise unresponsive > - The assignment is at least a /48 from a dedicated supernet-block > which clearly identifies it as Provider Independent Prefix > - A shorter prefix may be assigned if the end-site provides a network > plan and possible contracts with suppliers that hint that a /48 > prefix might not contain enough subnets for the planned lifetime > of the assignment. > The same applies for subsequent assignments to the same end-site. > [Actually, PI and PA requirement should just be the same here, but > the PA policy isn't really stateing anything clear yet either] > - A reservation for a growth up to a /44 is usually considered > > ..then adapt that to IPv4 PI, too, and we're done/done. > ==> PA is still easy and cheap, PI is more hassle and a more expensive > so it doesn't get the "default" - and we have some way to get it back to > the free pool if it goes zombie, perfect. > > (DISCLAIMER: That is over-simplified; i'm aware of that - for example - > we can't put "100EUR/y" in the policy itself) > > For the records: i don't really support the current 2006-01 draft in > this incarnation. It doesn't really fit anymore. Main reason: Limitation > to "multihoming". > (I never would have thought that i object to a IPv6 PI policy until > today...) > > -- > ======================================================================== > = Sascha Lenz SLZ-RIPE slz at baycix.de = > = Network Operations = > = BayCIX GmbH, Landshut * PGP public Key on demand * = > ======================================================================== > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From jordi.palet at consulintel.es Tue May 29 23:33:30 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Tue, 29 May 2007 23:33:30 +0200 Subject: [address-policy-wg] 2006-01 Discussion Period extended until 19 June 2007 (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: <4653C686.90906@nethinks.com> Message-ID: That short version is one of the possible paths that I tried, and I'm happy to follow it again, if: 1) RIPE NCC staff confirm that will be enough criteria for them 2) A good number of folks in the list agree and confirm *NOW* and even if a smaller number of folks confirm that they disagree *NOW* What I want to avoid at all means is to go back again for a path that will take months and then we may have nothing. In that case, I prefer to go in small steps and improve it once we have an IPv6 PI that covers a good % of the cases. I learned the lesson with previous proposals that trying to go for *all* in one shoot, don't really work. Regards, Jordi > De: Garry Glendown > Organizaci?n: NETHINKS GmbH, Fulda > Responder a: > Fecha: Wed, 23 May 2007 06:43:50 +0200 > Para: Sascha Lenz > CC: "address-policy-wg at ripe.net" > Asunto: Re: [address-policy-wg] 2006-01 Discussion Period extended until 19 > June 2007 (Provider Independent (PI) IPv6 Assignments for End User > Organisations) > > Sascha Lenz wrote: >> Why do we concentrate on "multihoming" now as a requirement for >> PI-addresses? That's not what "Provider Independent" means to me, even >> if this is the most likely reason for such a request. >> >> What about those who just want a portable block, no renumbering? > > Agreed - from my 11+ years of being an ISP (well, mostly in the last 5 > years or so) with the growing dependency on Internet for many companies, > it's enough work for many places to renumber their network. IT-folks > know it, try to avoid it as long as possible. When they finally need to > do it, e.g. because of switching ISPs, they want to avoid it in the > future at almost any cost. That's why we get almost all of our requests > for PI space. Multi-homing, though not as common yet, may become an > issue, maybe another 3-5 years down the road, but IMO isn't a reason at > all for PI-space. All you have to do is make sure you get a provider > that will allow a sub-allocation to be announced by another provider. > Why PI then? > >> Simple IPv6 PI Assignment policy: > > Your short version seems to cover most anything I can think of. Agreed > on the service fee, too. As for who charges it, there's two sides of the > medal there ... I can't really tell yet if assigning the Provider to > charge it for RIPE is a good idea or not. Probably the easiest, though > additional hassles in case of an end user switching his (primary) ISP > will follow. Or what happens if the customer refuses (or is unable) to > pay the PI dues to the LIR? Couple of things need to be worked out I guess. > > -garry > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From jordi.palet at consulintel.es Tue May 29 23:52:04 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Tue, 29 May 2007 23:52:04 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: Message-ID: That's broken. As it has been stated in previous messages some days ago, RIR communities can do whatever they want, especially if IETF fails. I'm doing IETF work, but it is clear that some times, for whatever reasons is too slow, or even fails. This community has the right to bypass that if required. And one more demonstration that this is broken: All the RIRs did 4-byte-ASN policies when no RFCs where available. As you can see the RIR system is still working. So yes, I will much prefer to have an RFC, and this is the way we are going, but nothing precludes to go in parallel, as it has been done in the 4-byte-ASN, and probably some other times I guess. And, in the worst case, if the IETF fails again on this (I'm sure will not be the case this time), we could always go for a global policy to instruct IANA to delegate that resource to the RIRs. Regards, Jordi > De: > Responder a: > Fecha: Tue, 29 May 2007 22:13:47 +0100 > Para: , > Conversaci?n: [ppml] [address-policy-wg] Those pesky ULAs again > Asunto: Re: [ppml] [address-policy-wg] Those pesky ULAs again > >> The policies for ULA-C are likely to be different from >> the policies for PI. > > ULA-C doesn't exist. There is not even a current Internet draft to > define what the acronym stands for. If any RIRs create a policy on that > basis, then it will be the beginning of the end of the RIR system. > > The RIRs are supposed to be stewards, prudently managing a shared > resource. > > --Michael Dillon > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From iljitsch at muada.com Wed May 30 00:06:48 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 30 May 2007 00:06:48 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: References: Message-ID: <4A8DC856-233A-4C16-9E65-1F5100392E77@muada.com> On 29-mei-2007, at 23:52, JORDI PALET MARTINEZ wrote: > That's broken. As it has been stated in previous messages some days > ago, RIR > communities can do whatever they want, especially if IETF fails. > I'm doing > IETF work, but it is clear that some times, for whatever reasons is > too > slow, or even fails. This community has the right to bypass that if > required. The IETF is far from perfect, but I'm not quite convinced that the RIRs stepping in when the IETF doesn't produce the desired results is going to work well. > And one more demonstration that this is broken: All the RIRs did 4- > byte-ASN > policies when no RFCs where available. There had been a draft for more than 5 years, the reason that there was no RFC was a process particularity (can't publish a routing RFC without there being interoperable implementations), not lack of consensus on any technical issue. > So yes, I will much prefer to have an RFC, and this is the way we > are going, What exactly is the way we are going? From alh-ietf at tndh.net Wed May 30 02:05:56 2007 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 29 May 2007 17:05:56 -0700 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> Message-ID: <1b7801c7a24e$4c0da560$e428f020$@net> Consolidated response to this barrage: Randy Bush wrote: > ok, i give. if ula address space is assigned/managed by registries, how > is it actually different from pi space? Policy expectations. If I get PI space from a registry, the ISP I call on knows I had to do some level of justification to get that. If I show up trying to get a ULA space routed, they know that took no justification, making it easier to refuse. > > if ipv6 space is effectively infinite (and we once thought ipv4 space > was), then what is the use of ula address space? why not just assign > vanilla ipv6 space? If people could get PI everywhere, without expectation that it would ever be routed, then your argument about equating them would hold for some uses. PI is not globally available, and even when it is the justification is based on need to route that much space. > > i am very confused by all the smoke and am trying to find the core of > this stuff. > Stirring the smoke around is not helping ... There is a very basic policy issue here, can an organization get space without being tied to a service provider? In some areas that is possible, if one is willing to subject themselves to scrutiny. ULA-L allows that organization to get space with a probability of uniqueness, while ULA-C provides their management 'more assurance' that there will not be a cost down the road related to partnerships or m&a. The other issue that is being mixed in is how and where filtering is done. Yes an organization with PI space could firewall off a portion of that and have a similar effect for some purposes. At that point you are trusting that there are no operational errors in the firewall config over time, and that it can keep up with the attacks. Using the ULA approach, -there is no route- so there is less work for the firewall to do, and a very simple filter that implemented by both the organization and the ISP. If the need to firewall off machines does not map to subnets though, the complexity of the firewall rules may exceed the ability of the products on the market. This is a trade-off issue where use of ULA space alongside either PA or PI allows the complexity to be spread out over device management, where those that don't need external access are only accessible using the ULA prefix. Jeroen Massar wrote: > > ULA space should be !A'ed out by routers per default and have a > > special switch to enable forwarding for them. Randy Bush wrote: > you are asking that routers hard code the association between > routability and address space. and next you only want this at site > border routers and not 'internal' routers. this was called site-local, > and was soundly rejected as > a disaster in the making. There is a big difference between hard-coding and default configurations. Strict RPF is another thing that should be 'on by default'; because in both cases the people that need it turned on are not aware they need it, while those that need it turned off are smart enough to turn the knob (and if they are not smart enough they probably really need it turned on). SL was killed off due to fear mongering, not because it was it was a disaster. There were no rational arguments, just a mob of chicken-little screaming. There was nothing in the spec that said the bits had to be zero, but there was also nothing in the spec that said they should not be. Rather than fixing it by telling people to use non-zero values, the mob said 'kill the monster because we are afraid...'. Iljitsch van Beijnum > It troubles me that so many people are willing to deprive others of > something that those others consider useful just because they > themselves don't find that thing useful. Get used to it because some of the people on these lists are control freaks that just want to deprive others. Shane Kerr wrote: > But I do not think ULA central is useful to anyone. You are entitled to your opinion. > > Even if ULA central is useful, I don't think it is something the RIRs > need to be involved in. To avoid the perpetual arguments about ULA-C vs. PI, it would be best if both were handled by the same organization to avoid the additional nonsense about an end run around the process. There is also the case that only organizations that really care would even be asking for ULA-C, and if they care enough they would be willing to become RIR members if need be. Additional recurring revenue for what is essentially a one-time effort should be enough of a reason for the RIR's to be involved. Rich Emmings wrote: > As I mentioned earlier, one of the barriers to getting management buy in > on > IPv6 is the fact that the standards keep changing, and this is a good > example. To use an analogy, the financial boys won't sign off on > starting > the building until they get a final floor plan. Keep rewriting the spec > to > try and get it 'perfect' instead of 'good enough' and it'll still be in > redesign as the last IPv4 address goes out the door? > > What problem are we trying to solve here? Is it a valid concern, or are > we > fighting the last war and blithly ignoring what will be the real > problems > with IPv6. (Hint, you don't know what it is either. If it's the same > problem, it's solved. If it's something you can think of, it's probably > being solved. It's novel.) The standards are not being changed here, it is policy, and policy changes all the time. The problem in this thread is that people keep mixing various policy arguments to justify their position on why this space is needed or not. There are several problems at hand, and various people don't want some of them solved. This results in the confused discussion that keeps happening, and will keep happening until the lack of IPv4 space forces a resolution. Unfortunately crisis based resolutions are not well thought out, and frequently have unintended long term consequences. Stephen Sprunk wrote: > You have the flawed assumption that everyone who uses RFC1918 space > today will want/need ULA-C in the future. The vast majority of folks > will be fine with ULA-L (or PA) space, and the target market for ULA-C > is identical to the target market for PIv6. It will be the same number > of orgs regardless of which type of space they request, so the debate > comes down to why we want to put orgs on ULA-C space instead of just > giving them PI space. If they're truly going to use it privately, > they won't consume routing slots in the DFZ, and if they aren't they'll > be using PIv6 anyways and won't have a need for ULA-C. I agree that the ULA-C need will map to the PI need, though ULA-C may be a subset. The last line though is IPv4-thinking, in that it assumes people will only use one address range at a time. People may well use PI for their nodes that have public access, at the same time using ULA-C for the ones that don't to minimize the firewall rules. The only 'value' to ULA-C over ULA-L is the assurance to management that 'this has been registered so the risk of a required renumbering event down the road is reduced'. It really doesn't matter if human error is greater than the probability of collision in ULA-L, this is not a technical issue, it is strictly a feel-good that people are willing to pay for. The RIRs should be all over customers like this, because their demands are low and their willingness to pay is high. Leo Bicknell wrote: > - IPv6 space is not infinite. It's a 64-72 bit address space. That's > right, subnets with > 256 hosts are very uncommon today, so we've > wasted 64 bits to number 256 things. That makes the space effectively > on the long end 72 bits. This goes back to Iljitsch's comment: just because you don't see the need, don't deny others the opportunity to innovate... The original proposal for 64 bits met the design goals for IPv6 by 3 orders of magnitude, but the routing world was concerned that there would not be enough space for the hierarchy of providers, so the entire 64 bits was given to them and the debate raged about how many more bits to add for the hosts. For operational simplicity in auto-configuring hosts it was decided that EUI-64 would be the best choice because the IEEE would run out of EUI-48's within the life expectancy of IPv6. Now we find the routing world arguing about 'waste' because they are just a greedy bunch that really don't want others to have something that they think they control, even if the can't use them. To prove the point, line this up with the FUD about not being able to route /48's as PI space because there are just too many of them. If there are too many /48's, what in the world would the routing system do with more bits? This occurs in the /48-/56 discussion as well because again if there are too many /48's why do we need to make sure end sites only get /56's. This is not about 'waste', it is all about 'control'. The policy realm is dominated by routing types, and they want to make sure they have control over the use of the bit space, even when they know they couldn't possibly use it. If you really want to see waste, allocate all the bits to routing. The world will move on to some other technology long before we run out of even /48's, because this is not the be-all-end-all of protocols. If the allocations allow innovation, there will be new approaches that might even minimize the workload of the routing world. Paul_Vixie wrote: > the real problems with IPv6 are those it shares with IPv4, so let's just > call it "the real problems with IP". they've been argued forever and > go by many names. from ppml's point of view, the right name of the > biggest problem is "lack of EID/RID split". since we're using one > address for both identity and location, it actually matters whether that > address is universal or private,PI or PA, etc. as tli pointed out fairly > early on, a solution to this problem would have added a lot more to the > IP address system lifetime than adding more bits has added or will add. > so, the problem isn't novel, but general recognition of the problem would > certainly be novel. The EID/RID split is a red-herring used to confuse those that don't understand that ISP's operate private networks, and they want absolute control over their networks. That is fine, they should have control over their infrastructure. The point is that IP is an inter-network technology, something the telco world doesn't really get (and the traditional ISPs have forgotten during the assimilation). It has been argued that the reason the Internet won out over the traditional telco world is exactly due to the identity and locator being merged. This allowed a chain of organizations to have a clean-slate view of what this packet is about; where header rewriting techniques only provide the upstream organization's interpretation. We have the solution to the perceived problem of each ISP wanting to write its own interpretation of what to do with this packet. It is called MPLS. No matter what you call it, every attempt to overwrite the end-to-end semantics of the IPv6 header with local semantics is nothing more than a label operation. Since it is being done just for the local network, it doesn't belong in the inter-network header, it belongs in a lower layer that already carries local-only network semantics. The problem is not that the EID/RID are merged, it is that the destination network is trying to effect policy over network providers, and the network providers are trying to prevent them from doing that so they can control their own network. Again, I have no problem with ISPs wanting to control their own network, but they should be using the tool that was designed for that rather than breaking the merged semantics that the entire existing security model is built on. David Williamson wrote: > Uh, neither of those reasons undermines the solution others have > proposed: use PI space. You can always just not announce some part (or > all) of your space. That would make it private. So you have a printer on the same subnet as the laptop, and the laptop needs internet access while the printer does not. Do you explicitly list every device that is to be allowed/blocked in the firewall; or do you overlay two prefix ranges from the public space and try to keep straight which one has public access to make sure the printer is in the right one? It would be much simpler operationally to have a very different range for the local-only devices. ULA provides that. ULA-C provides an assurance to management that there is a human maintaining a list that says 'this space is ours so we will not have to renumber for partnerships or m&a'. Owen DeLong wrote: > Um, no. It's like saying that counterfeit money is bad and we'd rather > not create a sponsored system for printing it. The thing that distinguishes counterfeit from 'real' is who prints it. If the same organization does the printing it is all 'real', unless they intentionally create bogus records (errors happen even in real things). ULA-C has value to some organizations. If you really don't want that to be 'counterfeit' space, then take it, manage it, and make it real. Otherwise don't be surprised when addresses that are not managed by the RIRs start showing up in real networks. David Williamson wrote: > My argument, however, is that > there's no problem solved by ULA-C that can't be solved by PI space, > and the creation of ULA-C would entirely undermine the RIR-based PI > system. Exactly how does ULA-C undermine RIR-PI? RIR-PI space is managed with the expectation that it would be publicly routable if the recipient wanted to. ULA-C space would be managed with the expectation that it would never be publicly routed. As long as those are managed by the same organization there would be no cross-purpose in the allocation, and as long as being an RIR member was the prerequisite for either, then no organization would be motivated to use one for functions where the other was expected. If the RIRs choose not to manage ULA-C, there will be something created to do that, so the assurances of mixing purposes goes away and it becomes a bidding war for the cheapest registry. The fees are for membership, not address space so every RIR member should be allocated a PI & ULA-C block, even if they never use them. This would take all the FUD about misuse off the table. Edward Lewis wrote: > What I *sense* is happening here is that the RIRs are being used to > do an end-run around the IETF process. This 'sense' is based on > reading the draft (and seeing that this is along the lines of site > local), looking at the mail list archives (which lacks overwhelming > support to promote this), and the hint that the IETF is failing to > promote ULA (perhaps that is just from the choice of words). Despite what the message from the chairs says, the reason it was dropped was that RIRs perceived ULA-C was an end-run around their lack of policy on PI (really an unstated policy of anti-PI at the time). I guess it was politically nice to leave the inter-org dirty laundry out of it .... ULA-C will only ever see the light of day as PI in the routing system if the remaining RIRs refuse to create real PI. PI is required legally in some areas, and will exist despite policy for others. ULA-C will be required by management by many of those same organizations because it offers 'fat finger' protection through no-routing-entry in the public network. The RIRs need to recognize reality and create the policies that manage the space. The IETF could take up the draft and publish an RFC, but if the RIRs don't want to manage the space then an alternate registry gets set up. At that point there will be a bidding war over which registry provided the most space for the least cost and everything about the status quo will end. If the RIRs want to avoid that situation then they need to establish a policy that RIR members get PI & ULA-C space, even if they never intend to use it. Tony From narten at us.ibm.com Wed May 30 04:49:38 2007 From: narten at us.ibm.com (Thomas Narten) Date: Tue, 29 May 2007 22:49:38 -0400 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <465C3FDE.7050708@psg.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <20070529100000.GA16216@borg.c-l-i.net> <465C3FDE.7050708@psg.com> Message-ID: <200705300249.l4U2ndVH019658@cichlid.raleigh.ibm.com> > sounds like a great idea for all of ipv6 allocation. what is the > difference ula or pi/pa? Here's my take. ULAs are not intended to be publically routed by ISPs. While some may attempt to get ISPs to route them, ISPs will have clear documentation saying they are not intended to be used that way, and they are free to filter them. And in fact they SHOULD be filtered. (I'd say MUST, but since that is not enforceable...) We have ULAs already. What is missing is centralized ULAs. I've had enough conversations with people that want to use ULAs - but simply aren't satisfied with probalistic uniqueness. They want something more meaningful, like a signed contract that that can pay some fee for and get some assurance that no one else is going to get that address. This sort of thing makes business people happy. People do worry about collisions and the impact that would have. ULAs are intended to be much more easy to obtain than PI space, because PI space is intended to be publically routed. PI space, on the other hand, is not useful if it is not publically routed (generally speaking). Poeple obtaining PI space are very much assuming it will be publically routed. ULA space is useful even if not publically routed (and is intended for uses that do not require public routability). E.g., it can be used to number infrastructure devices, with assurance those addresses will not need to change the way public addresses might. Is ULA space the same as PI? Only if you want to give everybody and their brother PI space and don't care about what that does to the routing tables. I don't believe we can (or should) do that. And keep in mind, in IPv6 devices can have multiple addresses simultaneously. So it is quite possible to have ULA-C addresses in addition to public addresses. So having ULA-C addresses does not imply that those addresses have to be used for communicating with off-site destinations. Thomas From leo.vegoda at icann.org Wed May 30 08:54:15 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 30 May 2007 08:54:15 +0200 Subject: [address-policy-wg] 2006-01 Discussion Period extended until 19 June 2007 (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: References: Message-ID: Hi Jordi, On 29 May 2007, at 11:18pm, JORDI PALET MARTINEZ wrote: [...] >> The new text has the following statement: >> >> "PI IPv6 Assignment Size to End User Organisations: >> The minimum size of the assignment is /48. However, a larger >> assignment (shorter prefix) can be provided if duly documented >> and justified." >> >> I am not sure what documentation and justification is required to >> qualify for a prefix shorter than a /48. What do I need to show the >> RIPE NCC before they would be able to assign my network a /47? > > I just tried to keep it simple. I expect the Staff will use the same > criteria they use today for providing, for example, a /31 instead > of /32. It would be helpful to put this in the policy text so that anyone considering a request will know whether they are likely to qualify or not. >> It would be helpful to people considering requesting a PI IPv6 prefix >> and the RIPE NCC if the policy gave a clear statement of what is >> required. > > Not sure if that's so easy, and I'm not really sure is really > needed. Do you > have any idea ? We could also apply that "idea", may be, to the > standard > IPv6 allocation policy. > > It will be good to understand if the staff is having problems > there, or it > is just enough the way they are doing and it may be applied then > here the > same. One of the three principles guiding the policy process is that "it is transparent. All discussions and results are documented and freely available to all."[1] If the criteria for a decision are too difficult to define in the policy text then there's something wrong somewhere. >> Also, the proposed text does not define a maximum size for an IPv6 PI >> assignment. When this is combined with a lack of definition for the >> qualification requirements it seems that a /32 of IPv6 PI could be >> assigned. Is that intended? > > Not at all, it is not intended to assign a /32. However, if the > case justify > it, we aren't closing the door. I really think it is difficult to > find a > case that could justify that, in fact probably is very difficult to > justify > cases that justify something shorter than /44, but you never know > how big > can be a data center or content provider, for example. I think it's difficult to define a case justifying it, too. But that doesn't mean that unreasonable requests won't be made. And if you don't have a clearly defined set of criteria you make things needlessly difficult for both the requesters and the registry. Regards, -- Leo Vegoda IANA Numbers Liaison [1] http://www.ripe.net/ripe/docs/pdp.html From lutz at iks-jena.de Tue May 29 15:21:51 2007 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Tue, 29 May 2007 13:21:51 +0000 (UTC) Subject: [address-policy-wg] Those pesky ULAs again References: <6534CF9556E640FFB8565140862C0CFE@tungemaskin> Message-ID: * J?rgen Hovland wrote: > Q: Is it correct that you can get a /26 IPv4 PA block, but you can't get > a /96 IPv6 PA block? Why is that? It's not correct. /48, /56, /64, and /112 are the most common assigments here. From dlw+arin at tellme.com Tue May 29 19:25:58 2007 From: dlw+arin at tellme.com (David Williamson) Date: Tue, 29 May 2007 10:25:58 -0700 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: References: <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <74CDAAB3-9267-43FA-9B8F-E84F91AFFAB0@delong.com> Message-ID: <20070529172557.GS5379@shell01.corp.tellme.com> On Tue, May 29, 2007 at 06:58:47PM +0200, Iljitsch van Beijnum wrote: > > Advantages of ULA-C (even to those who claim there are some): > > Virtually none. > > I'm sure you don't mind the plane renumbering in flight when it > switches from one satellite connection to the next. Myself, I'd like > to see the flight systems to have stable addressing regardless of the > orientation of the satellite antennas. > > > Disadvantages of ULA-C: > > I can't believe you keep pounding on this dead horse. These are > PRIVATE addresses. Period. Uh, neither of those reasons undermines the solution others have proposed: use PI space. You can always just not announce some part (or all) of your space. That would make it private. ULA-C sounds to me like a request to the guys who spin silicon to help people keep from screwing up their router configs. If someone can't manage to filter their BGP such that they keep some (or all) of their space private, I don't see why Cisco, Juniper, et al., need to do that for them. -David From owen at delong.com Tue May 29 19:38:09 2007 From: owen at delong.com (Owen DeLong) Date: Tue, 29 May 2007 10:38:09 -0700 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: References: <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <74CDAAB3-9267-43FA-9B8F-E84F91AFFAB0@delong.com> <20070529172557.GS5379@shell01.corp.tellme.com> Message-ID: <4161A246-5DD7-408B-A873-2E79BF420947@delong.com> On May 29, 2007, at 10:32 AM, Iljitsch van Beijnum wrote: > On 29-mei-2007, at 19:25, David Williamson wrote: > >>>> Disadvantages of ULA-C: > >>> I can't believe you keep pounding on this dead horse. These are >>> PRIVATE addresses. Period. > >> Uh, neither of those reasons undermines the solution others have >> proposed: use PI space. > > That's like saying people can use real money instead of monopoly > money. I really don't get this. Did you guys bet a lot of money > that there would never be ULA-C or something? > Um, no. It's like saying that counterfeit money is bad and we'd rather not create a sponsored system for printing it. Oh, wait, the treasury department (at least in the US, and, I'm betting whoever is the responsible agency in most other governments) feels that way. > If you don't like it, don't use it yourself and filter it, but > PLEASE don't whine about it. That's like saying if you don't like counterfeit currency, don't use it yourself, but, don't complain about the damage it does to your economy. Right. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From dlw+arin at tellme.com Tue May 29 19:39:11 2007 From: dlw+arin at tellme.com (David Williamson) Date: Tue, 29 May 2007 10:39:11 -0700 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: References: <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <74CDAAB3-9267-43FA-9B8F-E84F91AFFAB0@delong.com> <20070529172557.GS5379@shell01.corp.tellme.com> Message-ID: <20070529173911.GW5379@shell01.corp.tellme.com> On Tue, May 29, 2007 at 07:32:27PM +0200, Iljitsch van Beijnum wrote: > That's like saying people can use real money instead of monopoly > money. I really don't get this. Did you guys bet a lot of money that > there would never be ULA-C or something? > > If you don't like it, don't use it yourself and filter it, but PLEASE > don't whine about it. Calling a debate "whining" is a bit rude. My "whining" isn't intended to change your mind - I don't think any argument I make is likely to do that. My argument, however, is that there's no problem solved by ULA-C that can't be solved by PI space, and the creation of ULA-C would entirely undermine the RIR-based PI system. That latter possibility is the thing that worries those of us who are whining. That seems like a "bad idea". If you seriously think that ULA-C is entirely orthogonal to PI space, and will have zero impact on the usage of PI space...well...we'll have to agree to disagree. All of this, of course, distracts from the real underlying problem, as Mr. Vixie points out. Okay, I think that's my quote of posts to ppml for the day. Time to let someone else add their thoughts. -David From sbn at thermeon.com Tue May 29 19:09:29 2007 From: sbn at thermeon.com (Scott Nelson) Date: Tue, 29 May 2007 12:09:29 -0500 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <74CDAAB3-9267-43FA-9B8F-E84F91AFFAB0@delong.com> Message-ID: On May 29, 2007, at 11:58 AM, Iljitsch van Beijnum wrote: > On 29-mei-2007, at 18:40, Owen DeLong wrote: > >> Advantages of ULA-C (even to those who claim there are some): >> Virtually none. > > I'm sure you don't mind the plane renumbering in flight when it > switches from one satellite connection to the next. Myself, I'd like > to see the flight systems to have stable addressing regardless of the > orientation of the satellite antennas. I'm not seeing something here. Wouldn't the plane have an IP address given to it from the airline? If the airline needs to renumber, wouldn't they would do it in stages -- as planes land? From joelja at bogus.com Tue May 29 20:13:35 2007 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 29 May 2007 11:13:35 -0700 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <74CDAAB3-9267-43FA-9B8F-E84F91AFFAB0@delong.com> Message-ID: <465C6D4F.1000403@bogus.com> Iljitsch van Beijnum wrote: > On 29-mei-2007, at 18:40, Owen DeLong wrote: > >> Advantages of ULA-C (even to those who claim there are some): >> Virtually none. > > I'm sure you don't mind the plane renumbering in flight when it > switches from one satellite connection to the next. Myself, I'd like > to see the flight systems to have stable addressing regardless of the > orientation of the satellite antennas. Which is probably an application for ip-mobility agents and not BGP. Boeing's (now) historical implementation should be looked at as a generally bad idea and one can only imagine what it would have looked like if some large fraction of the 20,000 or so commercial aviation aircraft that would have been good candidates for it had been so equipped. >> Disadvantages of ULA-C: > > I can't believe you keep pounding on this dead horse. These are > PRIVATE addresses. Period. > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > From dlw+arin at tellme.com Tue May 29 21:08:02 2007 From: dlw+arin at tellme.com (David Williamson) Date: Tue, 29 May 2007 12:08:02 -0700 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <9D1FCE0E-816C-4AA9-B249-220B9C2EF3C0@muada.com> References: <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <74CDAAB3-9267-43FA-9B8F-E84F91AFFAB0@delong.com> <20070529172557.GS5379@shell01.corp.tellme.com> <4161A246-5DD7-408B-A873-2E79BF420947@delong.com> <9D1FCE0E-816C-4AA9-B249-220B9C2EF3C0@muada.com> Message-ID: <20070529190802.GZ5379@shell01.corp.tellme.com> On Tue, May 29, 2007 at 08:59:15PM +0200, Iljitsch van Beijnum wrote: > But more importantly, ULA-C would be exceedingly easy to get, while > PI is exceedingly hard to get. I wasn't going to post again today to this list, but I cannot let blatantly incorrect statements go by. PI is not hard to get, although your experience may vary by region. My org holds a PI /48, and it took me 2 days of duration and ten minutes of effort to receive it. That's nearly trivial, in my book. -David From owen at delong.com Tue May 29 18:40:19 2007 From: owen at delong.com (Owen DeLong) Date: Tue, 29 May 2007 09:40:19 -0700 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> Message-ID: <74CDAAB3-9267-43FA-9B8F-E84F91AFFAB0@delong.com> On May 29, 2007, at 2:31 AM, Iljitsch van Beijnum wrote: > On 29-mei-2007, at 11:18, Shane Kerr wrote: > >> There are no advantages to ULA (central), as I see it. Which is why I >> oppose it. > > It troubles me that so many people are willing to deprive others of > something that those others consider useful just because they > themselves don't find that thing useful. > > Quote from dr. Phil: "If your kid wakes up at night and says 'daddy > I'm thirsty can I get some water' you don't say 'I'm not thirsty, you > don't need water', you give the kid a glass of water. Everyone has > different needs." Right, but, if your kid wakes up at night and says "Daddy, I've got a hankering to blow stuff up. Can I get a grenade?" You don't just hand the kid a live grenade, whether you like to blow stuff up or not. Most of the opposition to ULA-C is because we see real downsides to it and don't see ANY upsides. Advantages of ULA-C (even to those who claim there are some): Virtually none. Some minor configuration convenience if a number of unsubstantiated assumptions are hard-coded into routers. Disadvantages of ULA-C: Nothing prevents it from becoming another form of provider-independent routed space on the internet. The policies for ULA-C are likely to be different from the policies for PI. If both address spaces function in an equivalent manner and have different policies to obtain/maintain the addresses, then the policy mechanism is undermined. etc. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML at arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml From bicknell at ufp.org Wed May 30 03:01:10 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 29 May 2007 21:01:10 -0400 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <1b7801c7a24e$4c0da560$e428f020$@net> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <1b7801c7a24e$4c0da560$e428f020$@net> Message-ID: <20070530010110.GA90674@ussenterprise.ufp.org> In a message written on Tue, May 29, 2007 at 05:05:56PM -0700, Tony Hain wrote: > > Even if ULA central is useful, I don't think it is something the RIRs > > need to be involved in. > > To avoid the perpetual arguments about ULA-C vs. PI, it would be best if > both were handled by the same organization to avoid the additional nonsense > about an end run around the process. There is also the case that only > organizations that really care would even be asking for ULA-C, and if they > care enough they would be willing to become RIR members if need be. > Additional recurring revenue for what is essentially a one-time effort > should be enough of a reason for the RIR's to be involved. I'm not sure I've seen the argument made this way before, but to me it's a new, a good argument. Specifically "RIR's should administer ULA-C so they can help direct people to ULA-C or PI as appropriate." I think that's an accurate morph of your statement. While I'm still not sure about ULA-C, thinking about it that way makes me think that if it is implemented, the RIR's are the right place. > Now we find the routing world arguing about 'waste' because they are just a > greedy bunch that really don't want others to have something that they think > they control, even if the can't use them. To prove the point, line this up > with the FUD about not being able to route /48's as PI space because there > are just too many of them. If there are too many /48's, what in the world > would the routing system do with more bits? This occurs in the /48-/56 This is distorting a near-term problem. If in 1993 I told you that your AGS+ with 8M of ram would need to route 200,000 prefixes from 200 different BGP sessions you would have laughed me out of the room. Today we think of a 5,000,000 prefix Internet as an impossibility. No hardware could ever do that. However, 20 years on I'm not sure a 5 million route Internet will be surprising to anyone. The fact that we might not be able to route a /48 for everyone who wants PI with today's hardware, or even in 5 years time does not mean we should flush the possibility down the drain by giving those who are worth of of space today so much space there will be none left tomorrow. At the time of the AGS+, giving HP a /8 and DEC a /8 "made sense". Today having one company that doesn't even provide any Internet services directly having a /7 (15/8 and 16/8) seems absolutely absurd. At the time having them consume a single route in your AGS seemed like a great idea. Today having them consume 4 /19's (as an example) might seem like a better tradeoff, 4 routing slots in exchange for using 10 bits less of address space. The thing of it is, as we're seeing with IPv4, taking space back is really hard. Now, some people think that a 25 year lifespan for IPv6 is "doing good". I think if by allocating addresses more prudently we could make it 50 years, that's billions of future dollars and effort saved, and more important to me, perhaps avoiding the next version of this transition in my lifetime! I believe the problem when we get into these arguments though is that it seems like there two options for the pendulum, the far left and the far right. I would hope as a community we could do a better job to find the middle, but no one on either side of the argument seems interested in understanding where the middle might actually be located. "You're a big company, and you have to use Class C subnets, so you should have 65536 of them, here's a Class A." "You're a big company, you have to give out /48 subnets, so you should have 65536 of them, here's a /32." Seems like we could have at least been creative this time around and picked a different number. Why do big companies need 65536 subnets? The number must be magical. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From owen at delong.com Tue May 29 18:40:19 2007 From: owen at delong.com (Owen DeLong) Date: Tue, 29 May 2007 09:40:19 -0700 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> Message-ID: <74CDAAB3-9267-43FA-9B8F-E84F91AFFAB0@delong.com> On May 29, 2007, at 2:31 AM, Iljitsch van Beijnum wrote: > On 29-mei-2007, at 11:18, Shane Kerr wrote: > >> There are no advantages to ULA (central), as I see it. Which is why I >> oppose it. > > It troubles me that so many people are willing to deprive others of > something that those others consider useful just because they > themselves don't find that thing useful. > > Quote from dr. Phil: "If your kid wakes up at night and says 'daddy > I'm thirsty can I get some water' you don't say 'I'm not thirsty, you > don't need water', you give the kid a glass of water. Everyone has > different needs." Right, but, if your kid wakes up at night and says "Daddy, I've got a hankering to blow stuff up. Can I get a grenade?" You don't just hand the kid a live grenade, whether you like to blow stuff up or not. Most of the opposition to ULA-C is because we see real downsides to it and don't see ANY upsides. Advantages of ULA-C (even to those who claim there are some): Virtually none. Some minor configuration convenience if a number of unsubstantiated assumptions are hard-coded into routers. Disadvantages of ULA-C: Nothing prevents it from becoming another form of provider-independent routed space on the internet. The policies for ULA-C are likely to be different from the policies for PI. If both address spaces function in an equivalent manner and have different policies to obtain/maintain the addresses, then the policy mechanism is undermined. etc. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From heldal at eml.cc Wed May 30 10:19:48 2007 From: heldal at eml.cc (Per Heldal) Date: Wed, 30 May 2007 10:19:48 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <20070529172557.GS5379@shell01.corp.tellme.com> References: <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <74CDAAB3-9267-43FA-9B8F-E84F91AFFAB0@delong.com> <20070529172557.GS5379@shell01.corp.tellme.com> Message-ID: <1180513188.25300.24.camel@localhost.localdomain> On Tue, 2007-05-29 at 10:25 -0700, David Williamson wrote: > Uh, neither of those reasons undermines the solution others have > proposed: use PI space. You can always just not announce some part (or > all) of your space. That would make it private. Until there's a magic solution for scalable IDR you'll hit the filter-wall. For ARIN's PI-block (/48 as defined by ARIN), expect networks to filter anything that is more specific. Hence you won't be able to keep a chunk "private" by making it "invisible" to the outside world. > ULA-C sounds to me like a request to the guys who spin silicon to help > people keep from screwing up their router configs. If someone can't > manage to filter their BGP such that they keep some (or all) of their > space private, I don't see why Cisco, Juniper, et al., need to do > that for them. ULA-C is a questionable workaround for the IT-industry's failure to solve basic problems. E.g; why, in 2007, is renumbering even an issue anymore? It shouldn't be a problem when changing upstream provider, nor should it be an issue when different private networks are joined. //per From iljitsch at muada.com Wed May 30 10:20:48 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 30 May 2007 10:20:48 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <20070529172557.GS5379@shell01.corp.tellme.com> References: <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <74CDAAB3-9267-43FA-9B8F-E84F91AFFAB0@delong.com> <20070529172557.GS5379@shell01.corp.tellme.com> Message-ID: <5A2786C0-4D5D-48B3-8C61-C54CD421A82E@muada.com> On 29-mei-2007, at 19:25, David Williamson wrote: > Uh, neither of those reasons undermines the solution others have > proposed: use PI space. Well, give me a couple of PI blocks and I'll think about it. Did I mention that I'm in the RIPE region but not a RIPE member/LIR? And that my IPv4 space is a /29 plus a /32? From iljitsch at muada.com Wed May 30 10:27:25 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 30 May 2007 10:27:25 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <74CDAAB3-9267-43FA-9B8F-E84F91AFFAB0@delong.com> Message-ID: <37A78B44-458F-45DF-B986-4E24B48A6B69@muada.com> On 29-mei-2007, at 19:09, Scott Nelson wrote: >>> Advantages of ULA-C (even to those who claim there are some): >>> Virtually none. >> I'm sure you don't mind the plane renumbering in flight when it >> switches from one satellite connection to the next. Myself, I'd like >> to see the flight systems to have stable addressing regardless of the >> orientation of the satellite antennas. > I'm not seeing something here. Wouldn't the plane have an IP > address given to it from the airline? If the airline needs to > renumber, wouldn't they would do it in stages -- as planes land? If you number the planes from the airline's address space, you need to keep rerouting those address blocks for the planes continuously as the plane flies around. It's really hard to make that work well, and the airline probably needs some kind of world-wide private network to do it. It makes much more sense to give the parts of the plane that need connectivity addresses that are tied to the connection they happen to have at any point in time. I.e., when it's in the air the passengers can email through a satellite link, when it's on the ground the service people can access the plane's systems for maintenance. But you really want the different systems in the plane to be able to talk to each other regardless of what external connectivity there is and regardless of any addressing such connectivity brings with it. From heldal at eml.cc Wed May 30 10:33:49 2007 From: heldal at eml.cc (Per Heldal) Date: Wed, 30 May 2007 10:33:49 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <20070529190802.GZ5379@shell01.corp.tellme.com> References: <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <74CDAAB3-9267-43FA-9B8F-E84F91AFFAB0@delong.com> <20070529172557.GS5379@shell01.corp.tellme.com> <4161A246-5DD7-408B-A873-2E79BF420947@delong.com> <9D1FCE0E-816C-4AA9-B249-220B9C2EF3C0@muada.com> <20070529190802.GZ5379@shell01.corp.tellme.com> Message-ID: <1180514029.25300.34.camel@localhost.localdomain> On Tue, 2007-05-29 at 12:08 -0700, David Williamson wrote: > I wasn't going to post again today to this list, but I cannot let > blatantly incorrect statements go by. PI is not hard to get, although > your experience may vary by region. My org holds a PI /48, and it > took me 2 days of duration and ten minutes of effort to receive it. > That's nearly trivial, in my book. If you want to endorse PI for "private" use please also consider that it leaves blocks wide open to abuse. Separate ULA-C space can easily be filtered, but how do you easily prevent hijacking of unannounced PI-prefixes should such private blocks become as commonplace as rfc1918-space? //per From jorgen at hovland.cx Wed May 30 11:02:05 2007 From: jorgen at hovland.cx (=?UTF-8?Q?J=C3=B8rgen_Hovland?=) Date: Wed, 30 May 2007 11:02:05 +0200 Subject: [address-policy-wg] Those pesky ULAs again In-Reply-To: References: <6534CF9556E640FFB8565140862C0CFE@tungemaskin> Message-ID: <148C41CAD7524E3C9FB866DA0E8115B9@tungemaskin> Hi Lutz, Which RIR is that? According to RIPEs IPv6 policy, the minimum PA block is /32 so I was kinda wondering. I need a /96. I can even manage with a /112. (Please let's not start a useless discussion of why you think I need it). Cheers, J -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Lutz Donnerhacke Sent: 29. mai 2007 15:22 To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] Those pesky ULAs again * J?rgen Hovland wrote: > Q: Is it correct that you can get a /26 IPv4 PA block, but you can't get > a /96 IPv6 PA block? Why is that? It's not correct. /48, /56, /64, and /112 are the most common assigments here. From michael.dillon at bt.com Wed May 30 11:21:35 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 30 May 2007 10:21:35 +0100 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: References: Message-ID: > That's broken. As it has been stated in previous messages > some days ago, RIR communities can do whatever they want, > especially if IETF fails. That may be true but since the IETF is not failing, there is no reason for the RIRs to take over any IETF functions. > I'm doing IETF work, but it is > clear that some times, for whatever reasons is too slow, or > even fails. This community has the right to bypass that if required. What community? So far I see only you suggesting that the RIRs should usurp the IETF role in defining Internet numbers. > And one more demonstration that this is broken: All the RIRs > did 4-byte-ASN policies when no RFCs where available. As you > can see the RIR system is still working. Jordi, you are twisting the truth. When the RIRs passed the 4-byte ASN policies, there were already Internet drafts working their way through the IETF process. 4-byte ASN work was part of the charter of the IETF's IDR working group. According to the IDR records here http://www3.ietf.org/proceedings/05nov/idr.html They had a goal to submit an RFC candidate document to the IESG in October 2005 which was more than a year before ARIN passed its 4-byte ASN policy. This is an example of the RIRs working in concert with the IETF. What you are proposing is for the RIRs to completely bypass the IETF process entirely. > So yes, I will much prefer to have an RFC, and this is the > way we are going, but nothing precludes to go in parallel, as > it has been done in the 4-byte-ASN, and probably some other > times I guess. Your guess is not good enough. In fact, even if you manage to get an RIR to pass some sort of ULA-C policy, it will not be good enough for most companies who want a centrally registered address block. These companies want some security of ownership in those addresses. They want strong assurances that their registered allocation will stay with them for the life of the company or the life of IPv6 whichever comes first. If ULA-C comes about through the dubious process that you propose, then there is no guarantee that the RIRs won't revoke ULA-C 6 months later. I would recommend that anyone needing the guarantee of uniqueness from a central registry should apply for PI address blocks. And if your local RIR does not offer PI IPv6 blocks, then work to get a policy passed to do this, such as was done in the ARIN region. > And, in the worst case, if the IETF fails again on this (I'm > sure will not be the case this time), we could always go for > a global policy to instruct IANA to delegate that resource to > the RIRs. > > Regards, > Jordi > > > > > > De: > > Responder a: > > Fecha: Tue, 29 May 2007 22:13:47 +0100 > > Para: , > > Conversaci?n: [ppml] [address-policy-wg] Those pesky ULAs again > > Asunto: Re: [ppml] [address-policy-wg] Those pesky ULAs again > > > >> The policies for ULA-C are likely to be different from the > policies > >> for PI. > > > > ULA-C doesn't exist. There is not even a current Internet draft to > > define what the acronym stands for. If any RIRs create a policy on > > that basis, then it will be the beginning of the end of the > RIR system. > > > > The RIRs are supposed to be stewards, prudently managing a shared > > resource. > > > > --Michael Dillon > > > > _______________________________________________ > > This message sent to you through the ARIN Public Policy > Mailing List > > (PPML at arin.net). > > Manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/ppml > > > > > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org > > Bye 6Bone. Hi, IPv6 ! > http://www.ipv6day.org > > This electronic message contains information which may be > privileged or confidential. The information is intended to be > for the use of the individual(s) named above. If you are not > the intended recipient be aware that any disclosure, copying, > distribution or use of the contents of this information, > including attached files, is prohibited. > > > > _______________________________________________ > This message sent to you through the ARIN Public Policy > Mailing List (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > From lutz at iks-jena.de Wed May 30 11:26:19 2007 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Wed, 30 May 2007 09:26:19 +0000 (UTC) Subject: [address-policy-wg] Those pesky ULAs again References: <148C41CAD7524E3C9FB866DA0E8115B9@tungemaskin> Message-ID: * J?rgen Hovland wrote: >> * J?rgen Hovland wrote: >>> Q: Is it correct that you can get a /26 IPv4 PA block, but you can't get >>> a /96 IPv6 PA block? Why is that? >> >> It's not correct. /48, /56, /64, and /112 are the most common >> assigments here. > > Which RIR is that? According to RIPEs IPv6 policy, the minimum PA block > is /32 so I was kinda wondering. I need a /96. I can even manage with a > /112. (Please let's not start a useless discussion of why you think I > need it). I talk about assignments, not about allocations. If you try to get a IPv4 PA allocation from RIPE, I wonder how you will get a /26. All you can get is an IPv4 PA assignment from your LIR with a size of /26. From sander at computel.nl Wed May 30 11:45:48 2007 From: sander at computel.nl (Sander Steffann) Date: Wed, 30 May 2007 11:45:48 +0200 (CEST) Subject: [address-policy-wg] ULA discussion Message-ID: <49371.192.16.186.26.1180518348.squirrel@webmail.nederland.net> Hello all, The ULA discussion has been going on for some time now, and I'd like to summarize it a bit. The differences between ULA address space and PI (or PA) address space: - ULA space should be easier/cheaper to get than PI space - PI space is meant for routing outside your organization and associated networks - ULA space is meant for inside your organization and associated networks Usefulness of ULA space: - I see some people/organizations who would realy like it - I see some people/organizations who don't like it As people who don't ULA don't have to use it (and filter fc00::/7), I would like to see other (preferably objective/technical) reasons why ULA space is a bad idea. Why should we deny ULA space to those who want it and think it is useful to them? Usefulness of ULA-Central space: - Some people think that the possibility of a conflict between two ULA-Local prefixes is so small that it does not really matter - Other people think even that very small chance does matter, and they would like a ULA-Central registry If the people/organizations who want an ULA-Central registry also pay for it, are there any other problems with providing such a registry? The question remains about who should operate and maintain that registry. Because RIPE NCC has a lot of experience with maintaining an IP address registry, they are a likely candidate for this. What arguments are there for and against letting RIPE NCC maintain this registry? What are possible alternatives? I hope I summarized everything correctly, and that I covered all remaining questions. If I missed anything, please let me know. If you have any input about any of the remaining questions, let's discuss it! Thank you, Sander Steffann From jeroen at unfix.org Wed May 30 16:40:25 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 30 May 2007 15:40:25 +0100 Subject: [address-policy-wg] ULA discussion In-Reply-To: <49371.192.16.186.26.1180518348.squirrel@webmail.nederland.net> References: <49371.192.16.186.26.1180518348.squirrel@webmail.nederland.net> Message-ID: <465D8CD9.9000701@spaghetti.zurich.ibm.com> Sander Steffann wrote: [..] Please note that the discussions here where about "ULA Central" space, which has a reserved slot at fc00::/8. > As people who don't ULA don't have to use it (and filter fc00::/7), ULA (RFC4139) is fd00::/8. These are already standardized and accepted and can be automatically generated by anyone. RIR's have no involvement in ULA's at all. Tool for generating ULA's can now be easily found at: http://www.sixxs.net/tools/grh/ula/ Which also contains a 'registry', to 'register' the ULA one is using. This is an intermediate step to ULA-Central. Anybody can generate a prefix and register them in that list. Of course people can simply ignore that list if they want/do not know about it as it is not official in anyway. In that respect, there are some newly started discussions in the IAB about this and on how to move forward with a possible ULA-C scheme. If somebody wants ULA-Central, then, as Fred Baker indicated, use the IETF IPv6 Working Group mailinglist and raise your voice there. When there is again a ULA-Central draft, and then an RFC, then this can be brought forward to the RIR's and am fairly sure that they can then apply a proper policy for it. When there is no such RFC though all of that is useless. My personal stance on all the ULA/PI/PA stuff: RIR's should provide a means to let an organization get a block of size X, where X depends on the size they can justify to the RIR. Greets, Jeroen PS: I heared another rumor that IANA might at one point have a similar "Registered" ULA list, when that happens, the one at SixXS will cease to exist and a redirect will be made to IANA. The list will of course be passed to IANA so that they can build further upon that. The generation function of course will always stay there so that it will be easy to find. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From narten at us.ibm.com Wed May 30 17:03:52 2007 From: narten at us.ibm.com (Thomas Narten) Date: Wed, 30 May 2007 11:03:52 -0400 Subject: 5M prefixes in the core [was: Re: [ppml] [address-policy-wg] Those pesky ULAs again ] In-Reply-To: <20070530010110.GA90674@ussenterprise.ufp.org> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <1b7801c7a24e$4c0da560$e428f020$@net> <20070530010110.GA90674@ussenterprise.ufp.org> Message-ID: <200705301503.l4UF3qrF013086@cichlid.raleigh.ibm.com> Leo Bicknell writes: > Today we think of a 5,000,000 prefix Internet as an impossibility. > No hardware could ever do that. However, 20 years on I'm not sure > a 5 million route Internet will be surprising to anyone. Who is the "we" you refer to above/ Actually, quite a few people are worried that a 5M prefix Internet is a possibility. There are also debates (i.e., no consensus) that when that happens, routers will actually be able to cope with the load in practice. I.e., see draft-iab-raws-report-02.txt and the efforts going on in the IETF, e.g.: http://www1.ietf.org/mail-archive/web/int-area/current/msg00763.html http://www1.ietf.org/mail-archive/web/int-area/current/msg00783.html Just to give one data point, router vendors are saying that today, they have routers that can support 1M routers. Operators (at least some of them), are skeptical, because that hasn't been proven operationaly in the field. So, there is at least some uncertainty as to what can be supported in practice. > The thing of it is, as we're seeing with IPv4, taking space back > is really hard. Now, some people think that a 25 year lifespan for > IPv6 is "doing good". I think if by allocating addresses more > prudently we could make it 50 years, that's billions of future > dollars and effort saved, and more important to me, perhaps avoiding > the next version of this transition in my lifetime! Glad to see you are thinking of an lifespan of more than just a few years. Indeed, I think many are thinking of even longer time frames. For example, policy proposal "2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement" (http://www.arin.net/policy/proposals/2005_8.html), which ARIN has adopted, was motivated very much by looking at time lines 100 years and longer... Thomas From filiz at ripe.net Wed May 30 17:09:47 2007 From: filiz at ripe.net (Filiz Yilmaz) Date: Wed, 30 May 2007 17:09:47 +0200 Subject: [address-policy-wg] 2007-01 Draft Document will be produced (Direct Internet Resource Assignments to End Users from the RIPE NCC) Message-ID: <20070530150947.E69FA2F593@herring.ripe.net> PDP Number: 2007-01 Direct Internet Resource Assignments to End Users from the RIPE NCC Dear Colleagues, The discussion period for the proposal described in 2007-01 has ended. This proposal states that a contractual relationship between an End User and the RIPE NCC must be established before the End User receives Internet number resources directly from the RIPE NCC. A draft document will now be prepared for review. We will publish the document in about four weeks. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2007-01.html Regards Filiz Yilmaz RIPE NCC Policy Development Officer From tme at multicasttech.com Wed May 30 16:48:16 2007 From: tme at multicasttech.com (Marshall Eubanks) Date: Wed, 30 May 2007 10:48:16 -0400 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <1180514029.25300.34.camel@localhost.localdomain> References: <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <74CDAAB3-9267-43FA-9B8F-E84F91AFFAB0@delong.com> <20070529172557.GS5379@shell01.corp.tellme.com> <4161A246-5DD7-408B-A873-2E79BF420947@delong.com> <9D1FCE0E-816C-4AA9-B249-220B9C2EF3C0@muada.com> <20070529190802.GZ5379@shell01.corp.tellme.com> <1180514029.25300.34.camel@localhost.localdomain> Message-ID: On May 30, 2007, at 4:33 AM, Per Heldal wrote: > On Tue, 2007-05-29 at 12:08 -0700, David Williamson wrote: >> I wasn't going to post again today to this list, but I cannot let >> blatantly incorrect statements go by. PI is not hard to get, >> although >> your experience may vary by region. My org holds a PI /48, and it >> took me 2 days of duration and ten minutes of effort to receive it. >> That's nearly trivial, in my book. > > If you want to endorse PI for "private" use please also consider > that it > leaves blocks wide open to abuse. Separate ULA-C space can easily be > filtered, but how do you easily prevent hijacking of unannounced > PI-prefixes should such private blocks become as commonplace as > rfc1918-space? How do you prevent it now, in IPv4 ? (I know several companies with addressable blocks for internal use, and so I suspect that this is not that rare.) Regards Marshall > > //per > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml From bmanning at karoshi.com Wed May 30 18:01:32 2007 From: bmanning at karoshi.com (bmanning at karoshi.com) Date: Wed, 30 May 2007 16:01:32 +0000 Subject: 5M prefixes in the core [was: Re: [ppml] [address-policy-wg] Those pesky ULAs again ] In-Reply-To: <200705301503.l4UF3qrF013086@cichlid.raleigh.ibm.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <1b7801c7a24e$4c0da560$e428f020$@net> <20070530010110.GA90674@ussenterprise.ufp.org> <200705301503.l4UF3qrF013086@cichlid.raleigh.ibm.com> Message-ID: <20070530160132.GA5364@vacation.karoshi.com.> On Wed, May 30, 2007 at 11:03:52AM -0400, Thomas Narten wrote: > Leo Bicknell writes: > > > Today we think of a 5,000,000 prefix Internet as an impossibility. > > No hardware could ever do that. However, 20 years on I'm not sure > > a 5 million route Internet will be surprising to anyone. > > Who is the "we" you refer to above/ > > Actually, quite a few people are worried that a 5M prefix Internet is > a possibility. There are also debates (i.e., no consensus) that when > that happens, routers will actually be able to cope with the load in > practice. > hum... given that w/ a /32 "boundary" - there exists the possibility of 2x32 routing table entries... clearly the /32 boundary is not to preserve routing table slots. if one is seriously considering a 1-5m entry routing table then it becomes important to (proxy) aggregate to the /8 or /9 level to keep within the 1 to 5m entries. --bill From Woeber at CC.UniVie.ac.at Wed May 30 18:36:56 2007 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 30 May 2007 16:36:56 +0000 Subject: [address-policy-wg] Those pesky ULAs again In-Reply-To: References: <148C41CAD7524E3C9FB866DA0E8115B9@tungemaskin> Message-ID: <465DA828.3070409@CC.UniVie.ac.at> Lutz Donnerhacke wrote: > * J?rgen Hovland wrote: > >>>* J?rgen Hovland wrote: >>> >>>>Q: Is it correct that you can get a /26 IPv4 PA block, but you can't get >>>>a /96 IPv6 PA block? Why is that? >>> >>>It's not correct. /48, /56, /64, and /112 are the most common >>>assigments here. >> >>Which RIR is that? According to RIPEs IPv6 policy, the minimum PA block >>is /32 so I was kinda wondering. I need a /96. I can even manage with a >>/112. (Please let's not start a useless discussion of why you think I >>need it). > > > I talk about assignments, not about allocations. If you try to get a IPv4 PA > allocation from RIPE, I wonder how you will get a /26. All you can get is an > IPv4 PA assignment from your LIR with a size of /26. > > And now I am feeling royally mixed up... I thought we were discussing IPv6? Wilfried From randy at psg.com Wed May 30 18:42:32 2007 From: randy at psg.com (Randy Bush) Date: Wed, 30 May 2007 09:42:32 -0700 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <200705300249.l4U2ndVH019658@cichlid.raleigh.ibm.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <20070529100000.GA16216@borg.c-l-i.net> <465C3FDE.7050708@psg.com> <200705300249.l4U2ndVH019658@cichlid.raleigh.ibm.com> Message-ID: <465DA978.3020502@psg.com> thomas, that's all nice. but please explain why this is technically any different and better than pi space. i keep remembering It's perfectly appropriate to be upset. I thought of it in a slightly different way--like a space that we were exploring and, in the early days, we figured out this consistent path through the space: IP, TCP, and so on. What's been happening over the last few years is that the IETF is filling the rest of the space with every alternative approach, not necessarily any better. Every possible alternative is now being written down. And it's not useful. -- Jon Postel From heldal at eml.cc Wed May 30 18:43:44 2007 From: heldal at eml.cc (Per Heldal) Date: Wed, 30 May 2007 18:43:44 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: References: <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <74CDAAB3-9267-43FA-9B8F-E84F91AFFAB0@delong.com> <20070529172557.GS5379@shell01.corp.tellme.com> <4161A246-5DD7-408B-A873-2E79BF420947@delong.com> <9D1FCE0E-816C-4AA9-B249-220B9C2EF3C0@muada.com> <20070529190802.GZ5379@shell01.corp.tellme.com> <1180514029.25300.34.camel@localhost.localdomain> Message-ID: <1180543424.25300.57.camel@localhost.localdomain> On Wed, 2007-05-30 at 10:48 -0400, Marshall Eubanks wrote: > On May 30, 2007, at 4:33 AM, Per Heldal wrote: > > > If you want to endorse PI for "private" use please also consider > > that it > > leaves blocks wide open to abuse. Separate ULA-C space can easily be > > filtered, but how do you easily prevent hijacking of unannounced > > PI-prefixes should such private blocks become as commonplace as > > rfc1918-space? > > How do you prevent it now, in IPv4 ? I filter private addresses ;) (rfc1918). > (I know several companies with > addressable blocks for > internal use, and so I suspect that this is not that rare.) I expect those relatively few with "hidden" V4 PI to be elegible for V6 PI and that they will continue a similar practise with V6. My concern is directed at those who promote unannounced public V6 blocks as a mass-replacement for rfc1918 when efforts imho are better spent on solutions to eliminate the use of NAT and private space. Btw, holding back part of a PI block is also going to create problems. >From a transit-provider perspective I find it reasonable to filter anything smaller than RIR-allocated blocks . I.e. anything longer than a /48 from PI-land is filtered. A couple extra bits may be accepted if the as-path-length is 2 or less (for TE purposes). Similar goes for PA-land. Where does that leave a /48 split split up to keep parts of it "secret"? //per From randy at psg.com Wed May 30 18:49:08 2007 From: randy at psg.com (Randy Bush) Date: Wed, 30 May 2007 09:49:08 -0700 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <027601c7a2c9$5af8f5e0$423816ac@atlanta.polycom.com> References: <027601c7a2c9$5af8f5e0$423816ac@atlanta.polycom.com> Message-ID: <465DAB04.30607@psg.com> > Creating a new type of address space for "private" use just because some > companies are too lazy to figure out how to configure their firewalls (which > don't even exist yet) is not good engineering. "Some people want it." and i want cash to fall from the sky. if we do everything anybody wants, we will have even less reliable code, more net breakage, ... randy From stephen at sprunk.org Wed May 30 16:20:59 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 30 May 2007 09:20:59 -0500 Subject: [ppml] [address-policy-wg] Those pesky ULAs again References: Message-ID: <027601c7a2c9$5af8f5e0$423816ac@atlanta.polycom.com> Thus spake "JORDI PALET MARTINEZ" > Agree, in ARIN region is not difficult to get, but in other two regions > (LACNIC and RIPE NCC) is still impossible. > > However more difference to point to is that using PI for a function > such as the one covered by ULA-Central is wasting space. How is using a PI /48 any more or less wasteful than a ULA-C /48? If anything, there is less ULA space (currently /7) available than PI space (currently /3) so we should be more concerned about waste in ULA land. Creating a new type of address space for "private" use just because some companies are too lazy to figure out how to configure their firewalls (which don't even exist yet) is not good engineering. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From marla.azinger at frontiercorp.com Wed May 30 17:28:08 2007 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Wed, 30 May 2007 11:28:08 -0400 Subject: [address-policy-wg] RE: [ppml] A registered ULA policy proposal outline Message-ID: <454810F09B5AA04E9D78D13A5C39028A0272F8F4@nyrofcs2ke2k01.corp.pvt> Hello I have been reading all the ULA emails and decided some of you might be interested to know the following: A small group of people (including Jason Schiller, Thomas Narten, Marla Azinger, Bob Hinden, Geoff Huston) have been discussing this very subject and what actions we need to pursue in order to evolve from circular conversations. Here is what action we are taking: Bob Hinden is going to revise the expired Centralized ULA Internet Draft, updating it based on input received from various forum discussions. We plan to submit this draft to the v6ops WG in time for the Chicago IETF with a goal of having it published as an RFC. Part of the new wording will be to clarify the ULA ID properties needed to make it work but leave out the details of how to achieve this to the RIR's. So yes, this document will "request" RIR involvment. And if/when approved, the document would task IANA with disseminating the ULA Addresses to the RIR's for assignment. We believe significant changes have occured in the last two years that make ULA a reasonable and acceptable requirement and that to make it work it needs the cooperation of IANA, IETF and RIR's. We are working to bridge this gap with a revised proposal that will (hopefully!) get us out of the circular discussions. Thank you for your time Marla Azinger Frontier Communications -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Scott Leibrand Sent: Tuesday, May 29, 2007 9:52 PM To: ppml at arin.net Subject: [ppml] A registered ULA policy proposal outline So after spending way too much time reading way too many messages about ULA-central, I think an actual policy proposal is needed to blow away the smoke and see whether the wood is actually dry enough to be useful for cooking marshmallows. My reading of the PPML discussion to date leads me to the following conclusions: * There are a number of organizations who would prefer to be able to acquire some form of registered unique local IPv6 addresses. * There are a number of arguments against a single central ULA registry centering around the desire to avoid "registry shopping." * For organizations in the ARIN region, there is consensus that organizations desiring to announce directly assigned space to transit providers should acquire space under ARIN's PI policy. * There are a number of organizations in the ARIN region who wish to acquire some form of registered ULAs for private, not-publicly-routed use (in addition to either PI or PA space). * Some people participating in the ARIN public policy process are uncomfortable asking ARIN to create a ULA registry without an RFC defining their various aspects, such as how registered ULAs should be allocated from IANA to the RIRs, how registered ULAs are intended to be used, etc. * Some people participating in the IETF process are (or have been) uncomfortable moving forward the existing ULA-central draft due to a perception of opposition at the RIRs. It is unclear to me whether this is largely historical (from before ARIN passed its PI policy) or whether it persists. If people who believe registered ULAs would meet a currently unmet need would like to move toward an ARIN ULA registry, I believe they should draft a policy something along the following lines, and then work to determine whether the particulars of the policy, and the idea as a whole, enjoy support among interested participants of the public policy process. (As before, I think a poll along the lines of Andrew Dul's 2005-1 IPv6 PI poll would be helpful.) So without further ado, here's a draft outline of a possible registered ULA policy proposal: * ARIN representatives should work with the IETF to help adopt an RFC defining the particulars of a registration function for Unique Local IPv6 Addresses (ULAs). A suitable RFC might define a range of IPv6 space for IANA to allocate to participating RIRs, which would then assign blocks to organizations. The RFC might also recommend that ULAs SHOULD NOT be announced to or accepted by Internet transit providers. * Upon adoption of such an RFC, ARIN should create a registry to assign registered Unique Local IPv6 Addresses (registered ULAs). The registry should assign a unique netblock to each registrant, should track and provide public information about such registrations through directory services like whois, and should provide reverse DNS delegation (ip6.arpa). * Upon creation of a registered ULA registry, ARIN should begin accepting applications for registered ULA netblocks. Such netblocks should be assigned to any organization in the ARIN region requiring registered ULAs for internal addressing purposes. ARIN should help ensure applicants are aware that ULAs are not intended to be routable (referencing the RFC), and should direct applicants to apply under the IPv6 PI policy or acquire space from their ISP(s) if they desire routable space. As I have no personal interest in registered ULAs (just a general interest in the good of the Internet community, and a desire to improve the signal to noise ratio of my ppml folder), I'm probably not the right person to actually write a registered ULA policy proposal. If there's support for the idea, I hope someone with an interested in registered ULAs can take the outline above, and the feedback it will inevitably generate, and draft a policy proposal. -Scott _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML at arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml From Paul_Vixie at isc.org Wed May 30 18:22:09 2007 From: Paul_Vixie at isc.org (Paul_Vixie at isc.org) Date: Wed, 30 May 2007 16:22:09 +0000 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: Your message of "Wed, 30 May 2007 09:20:59 EST." <027601c7a2c9$5af8f5e0$423816ac@atlanta.polycom.com> References: <027601c7a2c9$5af8f5e0$423816ac@atlanta.polycom.com> Message-ID: <78600.1180542129@sa.vix.com> aside from the difficulties pointed out during this thread regarding enforcement of ULA terms vs. PI terms, there are two other things that prevent me from thinking well of ULA. first, ARIN does not currently consider routability when allocating address space. non-routable space comes from ietf/iana, not the RIRs. so, for ARIN to start allocating nonroutable space is a big change. we would have to define "routable", we could face implied liability for routability on "normal address space" (even if we continue to disclaim it in the NRPM as we do now), and we would then walk the slippery slope of the changing definition "largest" with respect to breidbart's maxim: >> But what *IS* the internet? > It's the largest equivalence class in the reflexive transitive > symmetric closure of the relationship "can be reached by an IP > packet from". --Seth Breidbart second, even with the rampant EUI64 wastage of the bottom 64 bits of the IPv6 address space, there's still a lot of space, and it's not hard to get. it's perfectly reasonable for all addresses to be unique even if some are never expected to be "routed" or are only "privately routed" or whatever. so while i think that ietf/iana ought to allocate a "private" block of space for IPv6 since a lot of the world loves their IPv4 NAT and wants to be able to do the same thing with IPv6, one block ought to be enough. (heck, maybe the old site-local prefix is still available.) From bicknell at ufp.org Wed May 30 18:40:39 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 30 May 2007 12:40:39 -0400 Subject: 5M prefixes in the core [was: Re: [ppml] [address-policy-wg] Those pesky ULAs again ] In-Reply-To: <200705301503.l4UF3qrF013086@cichlid.raleigh.ibm.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <1b7801c7a24e$4c0da560$e428f020$@net> <20070530010110.GA90674@ussenterprise.ufp.org> <200705301503.l4UF3qrF013086@cichlid.raleigh.ibm.com> Message-ID: <20070530164039.GA37412@ussenterprise.ufp.org> In a message written on Wed, May 30, 2007 at 11:03:52AM -0400, Thomas Narten wrote: > > Today we think of a 5,000,000 prefix Internet as an impossibility. > > No hardware could ever do that. However, 20 years on I'm not sure > > a 5 million route Internet will be surprising to anyone. > > Who is the "we" you refer to above/ A number of operators keep standing up at ARIN meetings and telling us that if the IPv6 Internet had the same number of routes as the IPv4 Internet (e.g. ~200k) that the world would end. While I'm making a bit of an assumption, if we can't support that rate, how would we ever get to 5M in 20 years? > Actually, quite a few people are worried that a 5M prefix Internet is > a possibility. There are also debates (i.e., no consensus) that when > that happens, routers will actually be able to cope with the load in > practice. I have no worry. 1 order of magnitude growth in 20 years is way below the rate computing power and bandwidth are increasing. Heck, I think a 50 million entry table in 20 years is well within the advances in hardware we will see in that time. > Glad to see you are thinking of an lifespan of more than just a few > years. Indeed, I think many are thinking of even longer time frames. Which is excellent. I think a 50-100 year planning window may be pushing the limits of what we can achieve, but I'm all for trying! -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From kkargel at polartel.com Wed May 30 20:43:19 2007 From: kkargel at polartel.com (Kevin Kargel) Date: Wed, 30 May 2007 13:43:19 -0500 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <027601c7a2c9$5af8f5e0$423816ac@atlanta.polycom.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066706F72@mail> I will agree with this.. though I might have phrased it differently. Rather than mandate how organizations must use portions of their allocations, why not just let the whole thing be publicly routable? Then if an organization decides to use part of their allocation for private routing they can choose a block and quantity appropriate for their needs. Just as today we block private addresses at the network edge, we can continue to do so for IPv6. IPv6 is bigger, but it's not magic.. I have access lists in place on my routers to prevent private IP routing and IP spoofing.. I assume (yeah, I know) that most responsible sysadmin's do the same. I really don't understand the controversy over or need for ULA-C. Feel free to honestly educate me. I like feeling educated. Kevin :$s/worry/happy/g > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Stephen Sprunk > Sent: Wednesday, May 30, 2007 9:21 AM > To: jordi.palet at consulintel.es; ARIN PPML; address-policy-wg at ripe.net > Subject: Re: [ppml] [address-policy-wg] Those pesky ULAs again > > Thus spake "JORDI PALET MARTINEZ" > > Agree, in ARIN region is not difficult to get, but in other two > > regions (LACNIC and RIPE NCC) is still impossible. > > > > However more difference to point to is that using PI for a function > > such as the one covered by ULA-Central is wasting space. > > How is using a PI /48 any more or less wasteful than a ULA-C > /48? If anything, there is less ULA space (currently /7) > available than PI space (currently /3) so we should be more > concerned about waste in ULA land. > > Creating a new type of address space for "private" use just > because some companies are too lazy to figure out how to > configure their firewalls (which don't even exist yet) is not > good engineering. > > S > > Stephen Sprunk "Those people who think they know everything > CCIE #3723 are a great annoyance to those of us who do." > K5SSS --Isaac Asimov > > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > From dean at av8.com Thu May 31 02:09:59 2007 From: dean at av8.com (Dean Anderson) Date: Wed, 30 May 2007 20:09:59 -0400 (EDT) Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: Message-ID: On Wed, 30 May 2007 michael.dillon at bt.com wrote: > > That's broken. As it has been stated in previous messages > > some days ago, RIR communities can do whatever they want, > > especially if IETF fails. > > That may be true but since the IETF is not failing, there is no reason > for the RIRs to take over any IETF functions. I think there is evidence that the IETF is failing. Rather than a complete list of every failure, I'll just point out that the IETF (that is, the IESG and IAB), have a number of now well documented problems with: corruption conflicts of interest bad faith false statements silencing critics various kinds of deception Millions of dollars are involved in these deceptions. A recent egregious example of corruption, that is, officials profiting from deception, is the Housley authz-extns scandal. Russ Housley and Mark Brown submitted a draft to the IETF standardizing a patented TLS authorization protocol in February 2006. The patent was submitted in January 2005. The problem: They didn't tell the IETF about the patent, in violation of the IETF Policy. Their draft (seven revisions), stated that By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. What is even more egregious about this is that Housley was an IESG member during this time, and knew the policy of the IETF on patent disclosure. The draft was approved by the IESG as a standard in June 2006. Housley still kept mum on the patent. Brown (the other author) finally made a disclosure on November 26, 2006 (right over Thanksgiving). A good eye by Sam Hartman caught the emailed disclosure notice, and thereby discovered the deception. It was discussed by the IESG on the next telechat on 11/30/2006. The IESG announced withdrawal of the approval in February, 2007. It turns out the Housley was paid to write and promote the draft. Housley knew the IETF policy, and didn't disclose the patent, and repeatedly made material false statements. The IETF/ISOC membership and the public lost a legal right by unknowingly using the patented standards. Software patents are usually worth millions of dollars, and patented standards are many time more valuable. I refer one to the definition of "Actionable Fraud". [I used Black's Law Dictionary.] In spite of this, the IESG still (and subsequently!) made Housley Chairman of the IETF and IESG. It is an understatement to say that this is very bad judgment. And after the full extent of the scandal is known, Housley has not even been made to resign. So, I think it is becoming clear that the IETF is an organization that is failing: There is not a majority of honest people on its managing boards to avoid involving the IETF in serious scandal, nor even enough to object to promoting people known to be involved in serious scandal, nor even enough to force a scandalized Chairman to resign after the seriousness of the scandal is known. I think that's pretty bad, and it will only get worse. [Enron and Worldcom come to mind] --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From stephen at sprunk.org Thu May 31 00:56:38 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 30 May 2007 17:56:38 -0500 Subject: [ppml] [address-policy-wg] Those pesky ULAs again References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com><000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com><00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com><28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no><007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com><465BA1B9.1060003@psg.com><031b01c7a1ca$64904270$dc128953@kantoor.computel.nl><465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net><20070529100000.GA16216@borg.c-l-i.net> <465C3FDE.7050708@psg.com> <200705300249.l4U2ndVH019658@cichlid.raleigh.ibm.com> Message-ID: <060d01c7a31a$3aa641c0$423816ac@atlanta.polycom.com> Thus spake "Thomas Narten" >> sounds like a great idea for all of ipv6 allocation. what is the >> difference ula or pi/pa? > > Here's my take. > > ULAs are not intended to be publically routed by ISPs. While > some may attempt to get ISPs to route them, ISPs will have > clear documentation saying they are not intended to be used > that way, and they are free to filter them. And in fact they > SHOULD be filtered. (I'd say MUST, but since that is not > enforceable...) ISPs SHOULD filter RFC 1918 space, but many don't. If it weren't for the collision issue, you'd be able to get to a heck of a lot of "private" networks. > We have ULAs already. What is missing is centralized ULAs. > I've had enough conversations with people that want to use ULAs > - but simply aren't satisfied with probalistic uniqueness. They > want something more meaningful, like a signed contract that > that can pay some fee for and get some assurance that no one > else is going to get that address. This sort of thing makes > business people happy. People do worry about collisions and > the impact that would have. The RIRs are happy to sign a contract and take a fee to issue unique address space -- it's called PI. All you're going to do is make the RIRs allocate single-sized blocks out of fc00::/8 instead of 2000::/3, creating a v6 swamp that will inherit all of the problems of the v4 swamp. There is absolutely nothing else different about the addresses you propose handing out, except you _hope_ that ISPs won't route them (much) and you _hole_ that the RIRs will set the requirements and fees lower. The policy process can't guarantee the former and may not deliver the latter; OTOH, it could just as easily deliver the latter for PI if desired. > ULAs are intended to be much more easy to obtain than PI > space, because PI space is intended to be publically routed. If PI is tough to get from your RIR, change the policy. ARIN makes getting PIv6 space trivial for a minimum-sized request (the same size you'd get with ULA) and even has explicit policy stating that requests for private use are valid (though, for v4, RFC1918 is encouraged). We have no shortage of address space in v6; policies that discourage PI are _only_ justified to the extent they are needed to keep routing table growth under control. In the case of private use, that limitation doesn't apply since anyone who _really_ intends their block to be for private use won't consume a global routing slot. > PI space, on the other hand, is not useful if it is not publically > routed (generally speaking). Poeple obtaining PI space are > very much assuming it will be publically routed. PI space is useful for anything that needs a globally-unique address that isn't tied to a provider. Whether you advertize it (or portions of it) publicly is up to you. The same would be true for ULA-C, except there's an upproven theory that many people won't accept the route. > ULA space is useful even if not publically routed (and is > intended for uses that do not require public routability). E.g., it > can be used to number infrastructure devices, with assurance > those addresses will not need to change the way public > addresses might. Ditto for PI. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From rogerj at jorgensen.no Thu May 31 09:57:08 2007 From: rogerj at jorgensen.no (Roger Jorgensen) Date: Thu, 31 May 2007 09:57:08 +0200 (CEST) Subject: [address-policy-wg] ULA discussion In-Reply-To: <49371.192.16.186.26.1180518348.squirrel@webmail.nederland.net> References: <49371.192.16.186.26.1180518348.squirrel@webmail.nederland.net> Message-ID: you forgot the DNS part of that... without ULA-C there is no global DNS possibilities. That means split DNS for larger closed network/corporation network. ref RFC4193 - section 4.4... On Wed, 30 May 2007, Sander Steffann wrote: > Hello all, > > The ULA discussion has been going on for some time now, and I'd like to > summarize it a bit. > > The differences between ULA address space and PI (or PA) address space: > - ULA space should be easier/cheaper to get than PI space > - PI space is meant for routing outside your organization and associated > networks > - ULA space is meant for inside your organization and associated networks > > Usefulness of ULA space: > - I see some people/organizations who would realy like it > - I see some people/organizations who don't like it > > As people who don't ULA don't have to use it (and filter fc00::/7), I would > like to see other (preferably objective/technical) reasons why ULA space is > a bad idea. Why should we deny ULA space to those who want it and think it > is useful to them? > > Usefulness of ULA-Central space: > - Some people think that the possibility of a conflict between two > ULA-Local prefixes is so small that it does not really matter > - Other people think even that very small chance does matter, and they > would like a ULA-Central registry > > If the people/organizations who want an ULA-Central registry also pay for > it, are there any other problems with providing such a registry? > > The question remains about who should operate and maintain that registry. > Because RIPE NCC has a lot of experience with maintaining an IP address > registry, they are a likely candidate for this. What arguments are there > for and against letting RIPE NCC maintain this registry? What are possible > alternatives? > > I hope I summarized everything correctly, and that I covered all remaining > questions. If I missed anything, please let me know. If you have any input > about any of the remaining questions, let's discuss it! > > Thank you, > Sander Steffann > > > -- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger at jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- From s.steffann at computel.nl Thu May 31 10:25:14 2007 From: s.steffann at computel.nl (Sander Steffann) Date: Thu, 31 May 2007 10:25:14 +0200 Subject: [address-policy-wg] ULA discussion In-Reply-To: References: <49371.192.16.186.26.1180518348.squirrel@webmail.nederland.net> Message-ID: <053b01c7a35d$36bb2970$dc128953@kantoor.computel.nl> Hi, > you forgot the DNS part of that... without ULA-C there is no > global DNS possibilities. That means split DNS for larger > closed network/corporation network. > > ref RFC4193 - section 4.4... Thanks for pointing that out. Sander From rw at firstpr.com.au Thu May 31 10:29:59 2007 From: rw at firstpr.com.au (Robin Whittle) Date: Thu, 31 May 2007 18:29:59 +1000 Subject: [address-policy-wg] Re: 5M prefixes in the core [was: Re: [ppml] [address-policy-wg] Those pesky ULAs again ] In-Reply-To: <20070530164039.GA37412@ussenterprise.ufp.org> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <1b7801c7a24e$4c0da560$e428f020$@net> <20070530010110.GA90674@ussenterprise.ufp.org> <200705301503.l4UF3qrF013086@cichlid.raleigh.ibm.com> <20070530164039.GA37412@ussenterprise.ufp.org> Message-ID: <465E8787.7090909@firstpr.com.au> People either trying to achieve massive expansion of the IPv4 and IPv6 "global routing tables" - or trying to figure out a way of limiting their growth and devising new protocols to achieve multihoming and traffic engineering without relying on BGP - may wish to become involved in two lists: The RAM list, arising from the IAB's RAW workshop last year: http://www1.ietf.org/mailman/listinfo/ram http://tools.ietf.org/html/draft-iab-raws-report http://www.iab.org/about/workshops/routingandaddressing/ RRG - the IRTF's Routing and Research Group: http://www.irtf.org/charter?gtype=rg&group=rrg http://psg.com/lists/rrg/2007/ There is also a closed list which is worth watching: IETF Routing and Addressing Directorate http://www.ietf.org/IESG/content/radir.html http://www1.ietf.org/mail-archive/web/radir/current/ Guidance on which list is best for which topic is: http://www1.ietf.org/mail-archive/web/ram/current/msg01428.html RADIR is working on a Problem Statement I-D and the RRG is working on a Design Goals I-D. With IPv4 with a /24 limit on BGP advertisements it is relatively easy and very fast to do the FIB with a single lookup into RAM - provided you have enough fast RAM. Some high-end routers such as the CRS-1, M120 and MX960 probably have enough RAM to do it already. Beyond some number of prefixes (wild guess 500,000) it would be more memory- efficient to do a direct lookup into RAM with 24 bits of address than with Tree-Bitmap or similar ASIC + RAM based algorithms which use a single memory access for every 3 or 4 bits of address which needs to be classified. My proposal for direct RAM lookups is: http://www.firstpr.com.au/ip/sram-ip-forwarding/ but Reduced Latency DRAM would be fine too. The idea was first proposed in 1998 by Nick McKeown, Pankaj Gupta and Steven Lin: Routing Lookups in Hardware at Memory Access Speeds. (IEEE INFOCOM April 1998, Vol 3, pp. 1240-1247.) http://tiny-tera.stanford.edu/%7Enickm/papers/Infocom98_lookup.pdf My proposal extends the idea to IPv6, but with a significant restriction in the address range. There would still be plenty of space. >From the point of view of the FIB, this direct lookup proposal would enable IPv4 or IPv6 space to be assigned without any concern about route aggregation. This would mean that address space could be assigned in smaller chunks for shorter-term demand, which means it could be used much more efficiently. An optimised FIB proposal such as mine doesn't make much sense unless BGP can cope with millions of prefixes. On the RAM list earlier this year, it seems no-one had much hope of achieving this - so most of the discussion was about LISP, a proposal for "Locator/ID Separation Protocol" to achieve TE and multihoming without BGP and without changing host software. But LISP has its difficulties and is at a very early stage of development. Now there is some discussion on the RRG list about significant improvements to BGP. Here are some URLs relating to improving BGP: http://tools.ietf.org/html/draft-li-bgp-stability http://www.sigcomm.org/sigcomm2005/paper-SubCae.pdf http://www.ieee-icnp.org/2006/papers/s4a4.pdf http://www.ieee-icnp.org/2006/papers/s8a2.pdf http://www.beyondbgp.net/pubs/2005/bbgp_comnet05.pdf I have a list of such documents at: http://www.firstpr.com.au/ip/sram-ip-forwarding/#BGP_improvements Please suggest additions to this list. - Robin From jordi.palet at consulintel.es Thu May 31 11:12:51 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 31 May 2007 11:12:51 +0200 Subject: [address-policy-wg] 2006-01 Discussion Period extended until 19 June 2007 (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: Message-ID: Hi Leo, See below. Regards, Jordi > De: Leo Vegoda > Responder a: > Fecha: Wed, 30 May 2007 08:54:15 +0200 > Para: > CC: "address-policy-wg at ripe.net" > Asunto: Re: [address-policy-wg] 2006-01 Discussion Period extended until 19 > June 2007 (Provider Independent (PI) IPv6 Assignments for End User > Organisations) > > Hi Jordi, > > On 29 May 2007, at 11:18pm, JORDI PALET MARTINEZ wrote: > > [...] > >>> The new text has the following statement: >>> >>> "PI IPv6 Assignment Size to End User Organisations: >>> The minimum size of the assignment is /48. However, a larger >>> assignment (shorter prefix) can be provided if duly documented >>> and justified." >>> >>> I am not sure what documentation and justification is required to >>> qualify for a prefix shorter than a /48. What do I need to show the >>> RIPE NCC before they would be able to assign my network a /47? >> >> I just tried to keep it simple. I expect the Staff will use the same >> criteria they use today for providing, for example, a /31 instead >> of /32. > > It would be helpful to put this in the policy text so that anyone > considering a request will know whether they are likely to qualify or > not. Will do, thanks ! > >>> It would be helpful to people considering requesting a PI IPv6 prefix >>> and the RIPE NCC if the policy gave a clear statement of what is >>> required. >> >> Not sure if that's so easy, and I'm not really sure is really >> needed. Do you >> have any idea ? We could also apply that "idea", may be, to the >> standard >> IPv6 allocation policy. >> >> It will be good to understand if the staff is having problems >> there, or it >> is just enough the way they are doing and it may be applied then >> here the >> same. > > One of the three principles guiding the policy process is that "it is > transparent. All discussions and results are documented and freely > available to all."[1] If the criteria for a decision are too > difficult to define in the policy text then there's something wrong > somewhere. I think in some situations, the staff needs to have some flexibility. Is not a matter of wrong policy, is a matter of avoiding a complex one with too many cases, because every ISP may be one, and we have already guidelines such as RFC3177 and utilization, which the staff, I guess, uses to understand if the right prefix is a /32 or a /30 or whatever. May be having a reference to that is enough ? > >>> Also, the proposed text does not define a maximum size for an IPv6 PI >>> assignment. When this is combined with a lack of definition for the >>> qualification requirements it seems that a /32 of IPv6 PI could be >>> assigned. Is that intended? >> >> Not at all, it is not intended to assign a /32. However, if the >> case justify >> it, we aren't closing the door. I really think it is difficult to >> find a >> case that could justify that, in fact probably is very difficult to >> justify >> cases that justify something shorter than /44, but you never know >> how big >> can be a data center or content provider, for example. > > I think it's difficult to define a case justifying it, too. But that > doesn't mean that unreasonable requests won't be made. And if you > don't have a clearly defined set of criteria you make things > needlessly difficult for both the requesters and the registry. Same as above, if the utilization based on RFC3177 recommendations is a good parameter, then the criteria can be defined in a simple way that accommodate all the cases while hostmasters have a good point to check. > > Regards, > > -- > Leo Vegoda > IANA Numbers Liaison > > [1] http://www.ripe.net/ripe/docs/pdp.html > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From gert at space.net Thu May 31 12:41:31 2007 From: gert at space.net (Gert Doering) Date: Thu, 31 May 2007 12:41:31 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <20070530010110.GA90674@ussenterprise.ufp.org> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <1b7801c7a24e$4c0da560$e428f020$@net> <20070530010110.GA90674@ussenterprise.ufp.org> Message-ID: <20070531104130.GK69215@Space.Net> Hi, On Tue, May 29, 2007 at 09:01:10PM -0400, Leo Bicknell wrote: > "You're a big company, you have to give out /48 subnets, so you > should have 65536 of them, here's a /32." > > Seems like we could have at least been creative this time around > and picked a different number. Why do big companies need 65536 > subnets? The number must be magical. It nicely fits on a nibble (even octet) boundary, which is good for DNS :) ... and it's a workable compromise between ISPs that want "more space" to handle numbering their customers, and others that want(ed) to be ultra-conservative about IPv6 distribution... Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 113403 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 lutz at iks-jena.de Thu May 31 11:52:05 2007 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Thu, 31 May 2007 11:52:05 +0200 Subject: [address-policy-wg] Those pesky ULAs again In-Reply-To: <465DA828.3070409@CC.UniVie.ac.at> References: <148C41CAD7524E3C9FB866DA0E8115B9@tungemaskin> <465DA828.3070409@CC.UniVie.ac.at> Message-ID: <20070531095205.GA8994@belenus.iks-jena.de> On Wed, May 30, 2007 at 04:36:56PM +0000, Wilfried Woeber, UniVie/ACOnet wrote: > Lutz Donnerhacke wrote: > > * J?rgen Hovland wrote: >>>>* J?rgen Hovland wrote: >>>>>Q: Is it correct that you can get a /26 IPv4 PA block, but you can't get >>>>>a /96 IPv6 PA block? Why is that? >>>> >>>>It's not correct. /48, /56, /64, and /112 are the most common >>>>assigments here. >>> >>>Which RIR is that? According to RIPEs IPv6 policy, the minimum PA block >>>is /32 so I was kinda wondering. I need a /96. I can even manage with a >>>/112. (Please let's not start a useless discussion of why you think I >>>need it). >> >>I talk about assignments, not about allocations. If you try to get a >>IPv4 PA allocation from RIPE, I wonder how you will get a /26. All you >>can get is an IPv4 PA assignment from your LIR with a size of /26. >> >And now I am feeling royally mixed up... >I thought we were discussing IPv6? Of course. The original question was how to get a /96 IPv6-PA, because it is possible to get a /26 IPv4-PA. This question was motivated by finding an argument for IPv6-PI. The answer is very simple: When talking about PA, we have the following scheme: There are allocations given from RIR to LIR. And there are assignments given vom LIR to Users. When talking about PI, we have a different scheme: There is no allocation. The assignments are given from the RIR to Users. Breaking it down to the question: A /26 IPv4-PA is an assignment. A /96 IPv6-PA is an assignment, too. Allocations of PA does not exists with this network sizes. Rolling it back to the motivation, there is no relationship between the existence of PA and PI. We can't argument with PA assigments in order to find a reason for or against PI. From randy at psg.com Thu May 31 16:33:34 2007 From: randy at psg.com (Randy Bush) Date: Thu, 31 May 2007 07:33:34 -0700 Subject: [address-policy-wg] ULA discussion In-Reply-To: References: <49371.192.16.186.26.1180518348.squirrel@webmail.nederland.net> Message-ID: <465EDCBE.8000104@psg.com> Roger Jorgensen wrote: > you forgot the DNS part of that... without ULA-C there is no global DNS > possibilities. That means split DNS for larger closed > network/corporation network. huh? PI space does not support global dns? randy