- address-policy-wg - mailman.ripe.net

2007-05 Discussion Period extended until 9 July 2007 (IPv6 ULA-Central)
by Filiz Yilmaz 11 Jun '07

11 Jun '07

PDP Number: 2007-05 IPv6 ULA-Central Dear Colleagues The Discussion Period for the proposal described in 2007-05 has been extended until 9 July 2007. This policy 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 policy proposal and send your comments to <address-policy-wg(a)ripe.net>. Regards Filiz Yilmaz RIPE NCC Policy Development Officer

6 7

RE: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot)
by Tony Hain 08 Jun '07

08 Jun '07

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(a)arin.net [mailto:ppml-bounces@arin.net] On Behalf Of > vixie(a)vix.com > Sent: Thursday, May 10, 2007 9:59 PM > To: ppml(a)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(a)arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml

39 155

2006-01 Discussion Period extended until 19 June 2007 (Provider Independent (PI) IPv6 Assignments for End User Organisations)
by Filiz Yilmaz 07 Jun '07

07 Jun '07

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 <address-poliy-wg(a)ripe.net>. Regards Filiz Yilmaz RIPE NCC Policy Development Officer

17 28

New RIPE Document available: RIPE-411
by RIPE NCC Document Announcement Service 07 Jun '07

07 Jun '07

A new RIPE Document is available from the RIPE Document store. Ref: ripe-411 Title: IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region Author: RIPE NCC Date: June 2007 Format: PDF=82,541 Obsoletes: ripe-405 This document describes the RIPE community¢s current IPv4 address allocation and assignment policies. They were developed through a bottom-up, consensus driven, open policy development process in the RIPE Address Policy Working Group (AP WG). The RIPE Network Coordination Centre (RIPE NCC) facilitates and supports this process. These policies apply to the RIPE NCC and the Local Internet Registries (LIRs) within the RIPE NCC service region. You can find this document at: http://www.ripe.net/docs/ripe-411.html Regards RIPE NCC Webmaster

1 0

2005-08 Last Call for Comments (Proposal to Amend the IPv6 Assignment and Utilisation Requirement Policy)
by Filiz Yilmaz 05 Jun '07

05 Jun '07

PDP Number: 2005-08 Proposal to Amend the IPv6 Assignment and Utilisation Requirement Policy Dear Colleagues The proposal described in 2005-08 is now at its Concluding Phase. This proposal is to amend the RIPE IPv6 address allocation policies regarding the definition of the default size of End Site allocations, the threshold value for End Site allocation efficiency, and the method of calculation of the End Site allocation efficiency metric. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2005-08.html As you may remember, two draft documents for this proposal were published during its Review Phase. Now that both drafts have been moved to Last Call, we have published a combined draft document for your convenience. You can find this combined document at: http://www.ripe.net/ripe/draft-documents/2005-08.html The two separate draft documents for this proposal can still be found at: Defining allocation efficiency measurement unit as /56: http://www.ripe.net/ripe/draft-documents/2005-08-56s.html Changing the HD ratio value to 0.94: http://www.ripe.net/ripe/draft-documents/2005-08-hd-ratio.html Please e-mail any final comments about this proposal to address-policy-wg(a)ripe.net before 3 July 2007. Regards Filiz Yilmaz RIPE NCC Policy Development Officer

1 0

ULA discussion
by Sander Steffann 31 May '07

31 May '07

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

5 4

RE: [ppml] [address-policy-wg] Those pesky ULAs again
by Tony Hain 31 May '07

31 May '07

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

6 6

RE: [ppml] A registered ULA policy proposal outline
by Azinger, Marla 30 May '07

30 May '07

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(a)arin.net [mailto:ppml-bounces@arin.net]On Behalf Of Scott Leibrand Sent: Tuesday, May 29, 2007 9:52 PM To: ppml(a)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(a)arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml

1 0

2007-01 Draft Document will be produced (Direct Internet Resource Assignments to End Users from the RIPE NCC)
by Filiz Yilmaz 30 May '07

30 May '07

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

1 0

ULA Registry
by Jeroen Massar 29 May '07

29 May '07

[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.

1 0

2006-05 PI Assignment Size
by Knight, Brian 22 May '07

22 May '07

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). #####################################################################################

4 3

ARIN IPv6 resolution
by Shane Kerr 22 May '07

22 May '07

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

1 0

Re: [address-policy-wg] 2006-05 PI Assignment Size
by Brian Knight 18 May '07

18 May '07

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" <Brian.Knight(a)us.mizuho-sc.com> >To: <port27910(a)hotmail.com> >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(a)ripe.net >[mailto:address-policy-wg-admin@ripe.net] On Behalf Of Wilfried Woeber, >UniVie/ACOnet >Sent: Friday, May 18, 2007 3:05 PM >To: Knight, Brian >Cc: address-policy-wg(a)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. > ><quote> >* Please note that I do not speak for my employer - only for myself. ></quote> > >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). > > ###################################################################### > > ############### > > > >

1 0

Re: [ppml] [address-policy-wg] Re: article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot)
by Martin Hannigan 16 May '07

16 May '07

----- Original Message ----- From: Jeroen Massar <jeroen(a)unfix.org> To: Woeber(a)CC.UniVie.ac.at Cc: ppml(a)arin.net, address-policy-wg(a)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<

1 0

Fwd: [address-policy-wg] 2007-02 New Policy Proposal (Change in IP Assignments for Anycasting DNS Policy)
by heather skanks 15 May '07

15 May '07

Sorry meant to send this to the list! --Heather ---------- Forwarded message ---------- From: heather skanks <heather.skanks(a)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(a)space.net> 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 <gert(a)space.net> 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 > >

12 24

AW: [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot)
by Marcus.Gerdon 14 May '07

14 May '07

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(a)versatel.de | www.versatel.de ------------------------------------------------------------------------------------------------ AS8881 / AS8638 / AS15837 | MG3031-RIPE ------------------------------------------------------------------------------------------------ -----Ursprüngliche Nachricht----- Von: address-policy-wg-admin(a)ripe.net [mailto:address-policy-wg-admin@ripe.net] Im Auftrag von Shane Kerr Gesendet: Montag, 14. Mai 2007 09:51 An: bmanning(a)karoshi.com Cc: ppml(a)arin.net; address-policy-wg(a)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(a)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

1 0

2007-03 New Policy Proposal (IPv4 Countdown Policy)
by Filiz Yilmaz 09 May '07

09 May '07

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 <address-policy-wg(a)ripe.net> before 22 May 2007. Regards Filiz Yilmaz RIPE NCC Policy Development Officer

2 1

2007-02 New Policy Proposal (Change in IP Assignments for Anycasting DNS Policy)
by Filiz Yilmaz 09 May '07

09 May '07

PDP Number: 2007-02 Change in IP Assignments for Anycasting DNS Policy Dear Colleagues A new RIPE Policy Proposal has been made and is now available for discussion. This proposal suggests that there should no longer be a requirement to be a ccTLD or a gTLD to receive IPv4 and IPv6 assignments for anycasting DNS. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2007-02.html We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 21 May 2007. Regards Filiz Yilmaz RIPE NCC Policy Development Officer

9 14

2007-05 New Policy Proposal (IPv6 ULA-Central)
by Filiz Yilmaz 09 May '07

09 May '07

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 <address-policy-wg(a)ripe.net> before 30 May 2007. Regards Filiz Yilmaz RIPE NCC Policy Development Officer

11 27

2006-02 New Draft Document Published (IPv6 Address Allocation and Assignment Policy)
by Filiz Yilmaz 04 May '07

04 May '07

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(a)ripe.net before 31 May 2007. Regards Filiz Yilmaz RIPE NCC Policy Development Officer

2 1

New E-Learning Module: Using PGP and X509 to Protect MNTNER Objects
by Rumy Kanis 03 May '07

03 May '07

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(a)ripe.net Happy Learning, Rumy Kanis Training Services Manager

1 0

2007-01 New Policy Proposal (Direct Internet Resource Assignments to End Users from the RIPE NCC)
by Filiz Yilmaz 02 May '07

02 May '07

PDP Number: 2007-01 Direct Internet Resource Assignments to End Users from the RIPE NCC Dear Colleagues A new RIPE Policy Proposal has been made and is now available for discussion. 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 (Autonomous System (AS) Number, Provider Independent (PI) IPv4 and IPv6 Internet Exchange Point (IXP) and anycasting assignments) directly from the RIPE NCC. It also states that the text in the policy should mention more explicitly that PI assignments can't be sub-assigned. You can find the full proposal at: http://ripe.net/ripe/policies/proposals/2007-01.html We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 17 May 2007. Regards Filiz Yilmaz RIPE NCC Policy Development Officer

9 17

Thorsten Toenges/EMD/Merck ist außer Haus.
by Thorsten.Toenges＠merck.de 01 May '07

01 May '07

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.

1 0

2007-04 New Policy Proposal (IANA Policy for Allocation of ASN Blocks to RIRs)
by Filiz Yilmaz 01 May '07

01 May '07

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 <address-policy-wg(a)ripe.net> before 29 May 2007. Regards Filiz Yilmaz RIPE NCC Policy Development Officer

1 0

RIPE 54 WG Agenda -- DRAGT
by Gert Doering 24 Apr '07

24 Apr '07

Hi APWG folks, below you can find a draft for the RIPE address policy WG meeting's agenda, which will take place Wednesday, 11:30-12:30 and 14:00-15:30. If there is anything else you want to see on the agenda, please let me/us know! In the plenary section on wednesday, directly preceding the APWG time slot, we will have a presentation from Filiz Yilmaz on ongoing policy work in the RIPE region (summarizing what's going on) and in other regions (so we know what "they" are doing). (Thanks!) regards, Gert Doering, APWG chair ----------------------- snip ---------------- A. Administrative Matters (selecting a scribe, approving the minutes, etc.) B. selection of a new APWG Co-Chair (Sander Steffann is willing to step up, and Hans-Petter Holen is willing to step down, given that HPH's workload doesn't really give him time to do WG chair work anymore) C. Address Policy Proposals in the RIPE Region C.1 - Concluded Proposals (brief overview): Accepted Proposals: - 2006-06: IPv4 Maximum Allocation Period - 2006-07: First Raise in IPv4 Assignment Window Size Withdrawn Proposals: - 2006-04: Contact e-mail Address Requirements C.2 - Ongoing Proposals (time to be spent on discussion): - 2005-08: Proposal to Amend the IPv6 Assignment and Utilisation Requirement Policy - 2006-01: Provider Independent (PI) IPv6 Assignments for End User Organisations - 2006-02: IPv6 Address Allocation and Assignment Policy - 2006-05: (IPv4) PI Assignment Size C.3 - NEW proposals since RIPE53 (presentation by proposer, if possible, and then some discussion) - 2007-01: Nick Hilliard: Contractual Relationship for Internet Resource Assignments to End User Organisations - 2007-02: Tobias Cremer: amendments to the DNS anycast policy - 2007-03: Maemura Akinori: IPv4 Countdown (preparation) - New Proposal from Piotr Strzyzewski (work in progress) - New Proposal from Jordi Palet for ULA-Central registry/addressing. Z. AOB -- 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

1 0