May 2003 - lir-wg - mailman.ripe.net

RE: [lir-wg] Discussion about RIPE-261
by Hank Nussbacher 25 Jun '03

25 Jun '03

At 01:29 AM 26-05-03 -0700, Michel Py wrote: > > Needless to say, your numbers do not seem to take in any > > socio-economic factors. Assigning a /12 to North America > > as well as to Northern Africa and India might make > > socialistic sense as well as being "politically correct", > > but from a reality standpoint, it just don't fly. > >It's politically impossible to assign socio-economic factors such as >wealth. Who am I to pick a number and decide that Ethiopia gets 16 times >less addresses that the US? If it is true that in the short term it >would work, this would generate endless debates, which is why I picked >that an Ethiopian gets the same number of IP addresses than an American. So don't assign wealth. Use some number that has direct influence on IPv6 usage. Among the possibilities: - # of computer per capita - # of cellphones per capita - % of homes with electricity - % of homes with phone/cable - % of of homes with more than 5 electrical appliances Each would have a direct bearing on IPv6 usage. Pick any of the above or all of the above. -Hank

9 21

RE: [lir-wg] Discussion about RIPE-261
by Michel Py 05 Jun '03

05 Jun '03

> Kurt Erik Lindqvist wrote: > Agreed. The flaws of IPv6 comes down to not solving the > multihomign/routing scaling/world starvation problem. > That is an IETF problem, and there is a WG for it. For the record, and the following are verifiable _facts_: the IRTF and the IETF have been working on this problem for the last ten years. One of the Area Directors responsible for the multi6 WG has called it the "Titanic". By Kurtis' own account it is going to be 5 to 10 more years before they find a solution, if they do. The WG that Kurtis co-chairs has not even agreed to _requirements_ that were due two years ago; they are calling it recommendations now with zero proposals on the table. Anyone that wants to have a glimpse of what the IETF is going to do for them is encouraged to read Kurtis' own draft: http://www.ietf.org/internet-drafts/draft-kurtis-multihoming-longprefix- 00.txt Which basically says that we should allow /48 prefixes punched from PA space in the Global Routing Table. I am sure the educated reader that subscribes to this list will appreciate, especially smaller LIRs that can't afford a c12416 or M160 to hold a huge routing table. Michel.

6 17

RE: [lir-wg] Discussion about RIPE-261
by Michel Py 01 Jun '03

01 Jun '03

Gert, > Gert Doering wrote: > The *benefit* of "/48 multihoming" is that you can filter those > routes if you don't want to see them - then your routers will > send packets down the /32 road, and eventually hit a router > that knows about the /48 (which is why I consider this approach > superior to "everybody gets a independent prefix", which I can't > properly aggregate). This does _not_ work in at least two cases: - If someone implements RPF checks and someone else filters. - If the primary ISP (the one that announces the /32) dies. The site is dead as well. This is the #1 reason why organizations do multihome: they want to be up even if their primary ISP tanks. Please look at the following (4 slides, very short) http://arneill-py.sacramento.ca.us/ipv6mh/pa_holes.ppt Then come back to me and tell me that PA holes and filtering work together. The slides should be self-explanatory but they were designed for live presentation. I do welcome questions. Michel.

4 5

Correction of previous Notice
by Paul Rendek 30 May '03

30 May '03

CORRECTION TO PREVIOUS NOTICE Call for Nominations: RIPE Representative to the ASO Address Council Dear Colleagues, On 30 May 2003, an announcement from our office regarding the ASO Address Council elections incorrectly stated that the deadline for nominations was 3 June 2003. Please note that the deadline for nominations is 2 August 2003. * Deadline for nominations: 2 August 2003 * Election scheduled for: 4 September 2003 The selection process will involve an open election to be held during the RIPE 46 Meeting in Amsterdam, the Netherlands, being held from 1 - 5 September 2003. For full details on the position and how to make a nomination, please refer to: http://www.ripe.net/ripencc/about/regional/aso2003/ and http://www.ripe.net/ripe/wg/lir/adress_council-election.html We appreciate your understanding and apologise for any confusion caused by the previous notice. Best regards, Paul Rendek RIPE NCC

1 0

ASO AC - Call for Nominations 2003 - RIPE Region
by Paul Rendek 30 May '03

30 May '03

Call for Nominations: RIPE Representative to the ASO Address Council ___________________________________________________________ This is a call for nominations of individuals from the RIPE region to serve on the ASO Address Council. On 31 December 2003, one RIPE Address Council seat will become vacant and will be filled for the next three years by an individual nominated through this open call. The selection process will involve an open election to be held during the RIPE 46 Meeting in Amsterdam, the Netherlands, being held from 1 - 5 September 2003. * Deadline for nominations: 3 June 2003 * Election scheduled for: 4 September 2003 For full details on the position and how to make a nomination, please refer to: http://www.ripe.net/ripencc/about/regional/aso2003/ and http://www.ripe.net/ripe/wg/lir/adress_council-election.html Best regards, Paul Rendek RIPE NCC

1 0

Re: [hm-staff] Re: [lir-wg] Discussion about RIPE-261
by Kurt Erik Lindqvist 29 May '03

29 May '03

> Hi! >>>> I guess this would only work with RIPE who have the >>>> concepts of LIRs but anyway. >>> >>> I don't know how to parse this? All RIRs have the concept of LIR? >> >> Well in one way or the other - yes. But every-time I use the term LIR >> in Asia or the US people get confused and I get told that there is no >> such thing as a LIR in APNIC/LACNIC/ARIN. > > Just for the record... > > The term LIR is used in the APNIC region and is documented in the > APNIC IPv4 policy document in Section 4.1.3. I have actually never checked this, but people have repeatedly told me that they didn't know the terminology so I just assumed this. I guess I should have checked. Thanks for telling me though! Best regards, - kurtis -

1 0

RE: [lir-wg] Discussion about RIPE-261
by Michel Py 29 May '03

29 May '03

Carlos, > Carlos Morgado wrote: > Other people have already mentioned on the list memory/cpu isn't > an issue on this day and age. You definitly don't need a c12k to > carry a full routing table today. This is not what vendors are saying. I presented just after Jeff Doyle from Juniper 3 weeks ago and he was very specific about this. I extracted that one slide here: http://arneill-py.sacramento.ca.us/ipv6mh/j.ppt Let's face it: I'm sure that Juniper would love to keep selling big routers. They are telling us they can't guarantee they will keep up increasing memory and CPU, so we do have an issue with memory/cpu. Michel.

4 4

RE: [lir-wg] Discussion about RIPE-261
by Michel Py 28 May '03

28 May '03

Carlos, > Carlos Morgado wrote: > Again, I thought the point was making commercial IPv6 > multihoming work. This is all fine and dandy on 6bone but > my clients will not pay me for a backup link that won't > work when the primary provider goes down. No pay, no > multihoming. No multihoming no commercial offering. No > commercial offering, no happy fun end-to-end IPv6. Game > set and match. (and yes, this is even more true for > hosting than home users) I could not agree more. > No, I'm selling in technical good faith. I currently take steps > to maximize the quality of the transit I sell considering the > current IPv4 framework and current practices. In my opinion > however with the /48 PA method I can't in good faith sell the > same level of service. Absolutely. Total ISP collapses do happen. All the time. When they do: If you're and ISP, there is nothing worse than the customer getting on your behind asking why the backup solution he has been paying you to provide for over a year did not work. Not only you're going to loose the customer but you're lucky if you don't get sued (in the US at least). If you're the network manager for a customer, you look like an idiot in front of senior management when they ask why the backup did not work. What are you going to tell them? The redundancy solution that I bought was crud in the first place? Michel.

1 0

RE: [ipv6-wg@ripe.net] Discussion about RIPE-261
by Michel Py 28 May '03

28 May '03

Gert, > Gert Doering wrote: > - The /23 allocations ICANN -> RIRs are bad, because they lead to > address space fragmentation, and the blocks are too small to do useful > allocation towards the LIRs. Something NEEDS to be changed here. Agree. > So my personal recommendation would be: > - change the /23 allocation boundary ICANN -> RIR to something more > useful, like a /12 or so (a /12 means "512 of them are available, > so we're not yet burning bridges - but a /8 would work as well. > A /16 is already somewhat tight). I don't find this very flexible. If you look at what happened with LACNIC, countries from ARIN were transferred to LACNIC. I expect that when AFRINIC is activated, countries from both RIPE and ARIN will be transferred to AFRINIC. I agree with this goal: > - As a technical reason: people want to be able to filter IPv6 > prefixes by region, like "I only have one uplink that provides me > with US connectivity, so there's no need to carry any US prefixes > in my routing table, I just point a summary down that line". If you want to do this, you might as well do it right in the first place. IMHO, delegating space to a RIR as a single block is a mistake. It would be much more flexible to assign space to countries, and simply say that RIRs have stewardship of the space assigned to countries belonging to them. If a country changes RIRs like we have seen for LACNIC and like we will likely see for AFRINIC, no change in addresses and the geographical summary is preserved. Below is an example interpolated from the work we have done on geographic assignments: http://arneill-py.sacramento.ca.us/ipv6mh/geov6.txt Quick notes: - We are presently talking about PA space; the document mentioned above refers to PI space. However the geographic cutoff collapsed to the country level would not change. - I chose to assign a /8 to the entire world, which can be discussed. This means that after we colonize 255 other planets we have a problem :-) can someone help me with that warp drive please? - What could also be discussed are the details of how this was generated, but I would like to get the _concept_ across then we can talk about the details. Zone Population %G Pop. IANA ---------------- ---------- ------- -------------- China 1284971000 20.91% 2346:0000::/11 Continental Asia 673454413 10.96% 2346:2000::/11 India 1025096000 16.68% 2346:4000::/12 Northern Africa 565854163 9.21% 2346:5000::/12 Asian Islands 488468000 7.95% 2346:6000::/12 Western Europe 423412058 6.89% 2346:7000::/12 North America 318243350 5.18% 2346:8000::/12 South America 350724557 5.71% 2346:9000::/13 Eastern Europe 307858000 5.01% 2346:9800::/13 Middle East 258577000 4.21% 2346:A000::/13 Southern Africa 242566332 3.95% 2346:A800::/13 Central America 175719760 2.86% 2346:B000::/14 Oceania 30568053 0.50% 2346:B400::/16 ---------------- ---------- ------- -------------- World 6145512686 100.00% 2346:0000::/8 Example of one zone: Country Population %Z Pop. %G Pop. IANA ------------------- ---------- ------- ------- -------------- United States 285926000 89.85% 4.65% 2346:8000::/13 Canada 1015000 9.75% 0.50% 2346:8800::/17 Hawaii 1224398 0.38% 0.02% 2346:8880::/21 Bermuda 60000 0.02% 0.00% 2346:8888::/24 Greenland 12483 0.00% 0.00% 2346:8889::/24 -------------------- ---------- ------- ------- -------------- Zone: North America 318243350 100.00% 5.18% 2346:8000::/12 Implementing such a system would change the way large(global) LIRs request space from RIRs. As of today, they would typically request one /32 per RIR. For people the size of Sprint, they would then have to request a /32 per country they service and assign space to customers from the correct prefix. What this means to large LIRs is a large initial number of prefixes, but it's not fundamentally worse than an always-growing number of /32s when IPv6 finally takes off IMHO. For smaller LIRs that service only one country, there would be no change. There would be some impact on the GRT as there would be a "SPRINT-USA" block, an "ATT-USA" block, a "SPRINT-GERMANY" block, an "ATT-GERMANY" block, etc. In other words, what we are looking at is one /32 prefix per country per large LIR, opposed to as many /32s a large LIR would need in the long run anyway. Comments welcome. > - inside that RIR allocation, use the binary chop algorithm > described in RIPE-261 for the RIR->LIR distribution. I'm not familiar with this; would that be something like RFC3531? Michel.

3 2

RE: [lir-wg] Discussion about RIPE-261
by Michel Py 28 May '03

28 May '03

Andre, > Andre Oppermann wrote: > We see a very common occurence here. The moment an open > and very competitive market has matured, the (remaining) > players start (whether implicit or explicit) to hinder > new entrancies into the market. This is either done by > denial of (direct) access or policy barriers. You get it backwards. It is in the best interest of the router cartel to continue riding Moore's law forever and end up with a billion entries in the routing table which would allow them to keep renewing the installed router base every other year because naturally they cap memory and CPU in every model for the sole of being able to sell you a stinkin' new one two years later. And yes I am a stockholder of the router cartel. The reason they say they can't guarantee being able to ride Moore's law is because they see a risk that it happens. The very fact that they are actually looking at alternatives to Moore is worrisome. Michel.

4 3