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

New AS Number Block allocated to the RIPE NCC
by Alex Le Heux 18 Sep '07

18 Sep '07

Dear Colleagues, The RIPE NCC received the AS Number Block 44032 - 45055 from the IANA in September 2007. You may want to update your records accordingly. Best regards, Alex Le Heux RIPE NCC

1 0

Fwd: Re: Re: NCC#2007083003 Fwd: DELIVERY FAILURE:
by BabyMatthew253 13 Sep '07

13 Sep '07

To whoever may read these: I Matthew Brown, would like to request that there be some sort of action, to allow the ripe database managers to contact ISP(s) when someone reports incorrect or outdated information. This would be very helpful in the process of fighting spam and abuse, and when you rely on the whois servers around the world to get the correct email address(es) so you may forward the abuse/spam to the correct department, but only to have if fail because of outdated data, is not useful in the process of reporting it. As an internet user myself, it is a pain to get so much spam and abusive emails. I'm tired of opening my mailbox on a daily basis, to see I've gotten not one, or two, but on average 75 spam messages a day. And simply telling my email provider, in this case it is Yahoo, that an email is spam/abuse, is not enough to stop it from coming into my mailbox. I now take the time to report it to the proper ISP that holds the IP address where the spam/abuse comes from, or sometimes its a potential virus that comes in the form of a URL/Web pages to visit. So, I rely on having correct data. Please look into developing a policy that will allow the ripe database managers the resources to contact ISP(s) when someone reports incorrect information, so that those of us, like me, who are tired of the amount of spam they get can have correct information when they go to look for it, instead of having to make phone contact with each individual ISP who happens to be international for me. I know that the whois database at www.arin.net has the resources to make contact when someone reports incorrect data, so why not follow suit and have the same resources to do the same thing. Sincerely, Matthew Brown RIPE Database Manager <ripe-dbm(a)ripe.net> wrote: To: BabyMatthew253 <babymattb253(a)yahoo.com> Subject: Re: Re: NCC#2007083003 Fwd: DELIVERY FAILURE: From: RIPE Database Manager <ripe-dbm(a)ripe.net> Date: Fri, 24 Aug 2007 10:25:14 +0200 Dear BabyMatthew253, Thank you for your email regarding out of date contact data in the RIPE database. There may be options we could pursue to check the validity of the contact data in the objects in the RIPE Database. Where we have a direct relationship with the owners of these objects we could request that they update this information. But we do not have a mandate from the RIPE community to allocate any resources to this activity. If you feel this should have a higher priority then you may raise the issue on the Database Working Group or Antispam Working Group or Address Policy Working Group mailing lists. You can find information about the mailing lists here http://www.ripe.net/ripe/wg/index.html These are open working groups and views are welcomed from anyone who wishes to discuss relevant issues. Regards, Milena Rakin ____________________________ RIPE Database Administration. --------------------------------- Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV.

4 3

New Document available: ripe-416
by Filiz Yilmaz 12 Sep '07

12 Sep '07

Dear Colleagues, We previously announced that the policy proposal 2007-04, "IANA Policy for Allocation of ASN Blocks to RIRs" had been accepted by the RIPE community. This policy has now been published as a RIPE Document: ripe-416, "Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks to Regional Internet Registries" You can find this document at: http://www.ripe.net/ripe/docs/ripe-416.html Please note that this is a global policy and will therefore come into effect only after it has been accepted as a policy in all other RIR regions and then ratified by ICANN. Kind regards, Filiz Yilmaz RIPE NCC Policy Development Officer

1 0

2007-04 Proposal Accepted (IANA Policy for Allocation of ASN Blocks to RIRs)
by Filiz Yilmaz 05 Sep '07

05 Sep '07

PDP Number: 2007-04 IANA Policy for Allocation of ASN Blocks to RIRs Dear Colleagues Consensus has been reached, and the proposal described in 2007-04 has been accepted by the RIPE community. 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 Thank you for your input. Regards Filiz Yilmaz RIPE NCC Policy Development Officer

1 0

Re: IPv6 addresses really are scarce after all
by Iljitsch van Beijnum 01 Sep '07

01 Sep '07

[CCing this to ARIN PPML and RIPE address-policy, but Reply-To: ietf(a)ietf.org, when replying, please pick just one list. Also, please read Thomas' entire original message at http://www1.ietf.org/mail- archive/web/ietf/current/msg47431.html ] [You may want to skip ahead to my point about the HD ratio at the end.] On 24-aug-2007, at 23:34, Thomas Narten wrote: > The fact is, the /48 boundary is _NOT_ architectural, True. However, this doesn't mean that /48 is completely arbitrary, either. /64 for subnets is based on the availability of 64-bit unique numbers in the form of MAC addresses that make it possible to have stateless autoconfiguration where a system always has the same address without the need for explicit coordination or configuration. People often attribute the fact that IPv4 addresses didn't run out in 2005 as predicted in the early 1990s to NAT, but there is another technique that is even more popular than NAT that also played in important rule: ethernet switching. Back when IPv6 was designed, it was common to have a substantial number of different subnets for different purposes to avoid having unnecessary large "collision domains". These days, you can easily throw hundreds, if not thousands of systems in a single subnet without performance penalties so most networks don't need all that many subnets. So the original goal of providing something a number of subnets that is large enough for 99.9% of all IPv6 users arguably required a /48 (65536 subnets). With 2000::/3 given out for global unicast purposes, that allows 2^45 / 48s, which should be more than enough to give all inhabitants of the planet their own /48 with a few to spare. So a /48 is both big enough for pretty much everyone, and small enough that we can give one to pretty much everyone. Last but not least, it's very useful to have a standard size, because then, if you go from one ISP to another, you're never in the situation where you need to renumber into a smaller block of address space, which is much, much harder than just replacing the first X bits of the address (where X is presumably 48). This was especially true in the presence of DNAME and bitlabels in the DNS. For those of you that don't know about this, it's rather complex and now obsolete, but around the turn of the century, this was a hot new mechanism to support easy renumbering in the DNS. (Read about it here http://www.apress.com/ book/supplementDownload.html?bID=10026&sID=3120 but don't say I didn't warn you.) So /48 was certainly "a good idea at the time". If we were doing all of this today, we could probably go a bit lower than 65536 subnets, such as 4096, but not THAT much lower. For instance, 256 subnets (/ 56) is still a very large number, so it assumes that people will be subnetting, but I'm not confident that it's enough for 99.9% of all future IPv6 users. Another issue is what we give to people who aren't going to build a network with subnets. The old recommendation was a /64 (= 1 subnet) for users who don't need to subnet. But unlike with IPv4, where end- users often get a single IP address and turn that into a subnet with NAT, with IPv6 you pretty much always need TWO subnets, although one of them can be shared. For instance, if I want to connect a bunch of computers in my home to my DSL line with IPv6, I need a /64 on my wifi network at home, but it's not really possible to use addresses from that same /64 between my ADSL modem and the DSL concentrator at the central office. As an ISP, I could set up one /64 to talk to all the DSL modems connected to a central office and then delegate a /64 to each user, but this is problematic for technical reasons (broadcasts/mulsticast vs NBMA) and control issues (which user does traffic from an address in that shared /64 come from). So if I were designing an ISP network, I would want to give at least two /64s or a /63 to every customer. In practice, it's much easier to go up a few bits and make it a /60, where I use one /64 for the SIP- customer link and the customer gets to use the other 15 subnets however they want. This way, I avoid getting support calls from people who want to have an extra DMZ subnet or different subnets for their wired and wireless networks. Again, as an ISP, I wouldn't want to think about how many subnets customers are going to use when they need more than that /60. Much easier to simply sell them a business account and give them a /48. Remember, every time a simple residential customer calls the support number, that costs an ISP the entire profit for that customer for a year. Avoiding support calls is one of the highest priorities for ISPs. > What the appropriate size of an assignment for an end site should be > is really more of an operational issue than architectural one. If a > site gets too little, and needs to get more later (maybe at the cost > of renumbering) that is an operational issue. And the idea that we can > give out "enough" address space to a site so that it doesn't have to > renumber (ever) is pretty silly. That doesn't mean it's impossible to pick sizes that are worse than others. And even though we have reverted back to simple use of the DNS with IPv6 where having the same address block size when going from ISP to ISP is less important, it's still beneficial to have as few block sizes as possible to that people don't have to go from big to small. > The RIRs adopted the "/48 to everyone" in its initial stab at IPv6 > policy back in 2002. Even at that time, there was much screaming and > gnashing of teeth from the operator community saying "wasteful", > "excessive", "really stupid", etc. The wastefulness occurred when the IPv6 address size was set to 128 bits. This means that every IPv6 packet has to carry 32 bytes of address information. Now that we've eaten that cost, there is little use in trying to _use_ fewer of those bits that we're paying for with every packet. I can see how "/48 for everyone" could be considered too much (although 35184 billion of those aren't going to be used up any time soon) but can we at least retain "/48 for everyone who asks for one"? > If I assign 4M /48's of IPv6 (one to each cable modem on my > network), according to the HD-ratio I am justified to obtain > something around a /20 of IPv6 addresses. In other words, I am > justified in getting 268M /48's even though I am only using > 4M of > them. That would be enough for me to assign at least two for > every household in the US (not just the 19M on my network). Yes, this is a problem that the current policies, including the unofficial ones (for instance that ARIN reserves a /29 when an ISP gets a /32) don't address. Suppose a large ISP that operates across the US or Europe gets that / 20. So how are they going to announce that, as a single /20? I don't think so. They're going to deaggregate. And they can easily do that, because their block is much larger than the minimum /32 block that people are presumably going to be filtering on. In the degenerative case, which we can already see in IPv4, ISPs simply announce whatever they have as the smallest possible announcement. So that ISP that needs 4 million /48s = 64 /32s but gets a /20 = 4096 /32s COULD advertise 4096 prefixes because the RIRs thought they would need to aggregate, while if the RIRs assumed that they wouldn't aggregate, they would have gotten the space in the form of a number of much smaller blocks and they would only have been able to announce 100 or so /32s. A much more appropriate policy would be to start with a certain minimum allocation, and then whenever someone comes back for more, give them a new block that is 2, 4 or 8 times as big as the previous block until a certain maximum block size is reached. For aggregation purposes, there is no benefit in having blocks larger than a /24, because by the time that a significant portion of the the IPv6 space ends up in the routing tables, having 2^24 routes won't be a problem. > The > community feedback was that LIRs were smart enough to make reasonable > assignments based on actual customer need. The trouble is that even more so than at the IETF, the RIR community as seen from the policy development process is whoever happens to show up. This means only a small part of all stakeholders provide input. > Surely, everyone will agree that > giving a /56 to home sites is more than enough space for the foresable > future! If /48 is too much for home sites then /56 is too much as well.

6 6

New E-Learning Module: The RIPE Policy Development Process
by Rumy Kanis 28 Aug '07

28 Aug '07

Dear Colleagues, We are pleased to announce the launch of the latest module on the RIPE NCC E-Learning Centre: - The RIPE Policy Development Process This module explains how the process works and how you can take part in it. Once you have completed the module you will know how to: - Propose a new policy - Propose a change to an existing policy - Monitor policy discussions - Participate in policy discussions The RIPE NCC E-Learning Centre is a free-of-charge service available to everyone, and it 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 RIPE NCC

1 1

RE: IPv6 addresses really are scarce after all
by jnc＠mercury.lcs.mit.edu 27 Aug '07

27 Aug '07

> From: "Hallam-Baker, Phillip" <pbaker(a)verisign.com> > Perhaps you could define the term subnet? "IP subnet", or "subnet" in the more general networking (outside-the-IP-community - the null set these days, I know) sense? For the first, originally, back in the days of class A/B/C "network numbers", it was a chunk of address space smaller than the "network" it was assigned from; it was used to provide addresses for a particular physical network. Now that we have CIDR, it seems to basically just means a chunk of address space assigned to a particular hardware network (the second meaning of "subnet"). For the second, it meant a particular physical network, i.e. the collection of end-stations which could send packets directly to each other without going through a router. This was before bridges, hubs, etc. Goodness knows what it means now! I'd suggest "multicast broadcast domain" as a good modern functional definition. Noel

1 0

2007-02 Policy Proposal Withdrawn (Change in IP Assignments for Anycasting DNS Policy)
by Filiz Yilmaz 27 Aug '07

27 Aug '07

PDP Number: 2007-02 Change in IP Assignments for Anycasting DNS Policy Dear Colleagues, Policy proposal 2007-02, "Change in IP Assignments for Anycasting DNS Policy" has been withdrawn. The proposer decided that there was insufficient support for the proposal. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/archive/ Regards Filiz Yilmaz RIPE NCC Policy Development Officer

2 1

RE: [address-policy-wg] PI for Not-DNS Anycast.
by Greg L. 13 Aug '07

13 Aug '07

I think that the PI /24 block should be assigned only to UDP related services as RFC suggests, however, I have yet to see the successful implementation of TCP data, state... replication in case one router withdraws BGP announcement of the /24 prefix. IPv4 anycast is a perfect way to distribute load and hopefully with lowest latency (not always true) for the following UDP related services: -syslog -dns -ddos mitigation The PI /24 anycast block should be assigned only when the applicant can demonstrate: at least 5 physically disperse locations (verification done by traceroute and checking the hop before the last hop in the traceroute). Traceroute's can be performed from open traceroute gateways (over the web etc - there are hundreds) or public ISP BGP route servers. to manage the server you will need a non anycast address(es), however, customers may keep this info secret if they do not want it to be public.... all anycast nodes must speak BGP to the upstream and in case the server goes down, the BGP router withdraws the BGP anycast /24 route Ps. If Ripe will allow anycast /24 PI allocation for syslog and ddos, and other UDP based services, then expect all free /24 blocks taken in a year or less for sure ;) My $0.02 cents... Greg http://www.LinuxAdmin.org

12 22

PI for Not-DNS Anycast.
by Andy Davidson 11 Aug '07

11 Aug '07

Hi, Can I get the community's thoughts on this, please .. I think we have a well defined policy on what to do when someone needs some PI in order to run an Anycasted DNS service. We set out a family of requirements based on geographic diversity, for instance, that clearly states what should be in place when a request for PI for DNS use is made. What if a company wants to try to deploy an anycasted production service for something which is not DNS ? It could be a proprietary protocol, or something standard like http. Is the community view that they should just deaggregate some of their PA - which I don't like the sound of - or apply for PI in the normal way, and pretend anycast isn't necessarily involved ? Many thanks Andy

13 25