- ipv6-wg - mailman.ripe.net

RE: [ipv6-wg@ripe.net] Re: [ipv6-wg@localhost] Re: What is a site ?
by Patrick Arkley 10 May '05

10 May '05

That was indeed the original question. In my scenario, the same as yours, I would assign a /48 to each branch office. Too many subnets I would say. However, if the customer from a central point asked for a range for all his branch offices I wouldn't hesitate in assigning one /48 for him/her to use wherever appropriate. The problem from an adminitrative side is that we rarely get the customer to fill out a network request for all sites but rather request ranges per site as they are up for installation. Rgds Patrick Arkley Supervisor IP/DNS SKSC/SKRC Phone direct: +46 (0)8 5661 7075 Fax: +46 (0)8 5661 7236 Mobile: +46 (0)733 11 20 75 VNET: 915-7075 E-mail: patrick.arkley(a)se.mci.com Initial Call team [VPN]: +46 (0)8 5661 7899 or emea-ip-vpn-inital-call(a)se.mci.com Registry: +46 (0)8 5661 7454 or registry(a)se.uu.net IP-team: +46 (0)8 5661 7629 or ip(a)se.uu.net -----Original Message----- From: Erics [mailto:EricS@t-com.net] Sent: den 10 maj 2005 11:37 To: ipv6-wg(a)ripe.net Subject: [ipv6-wg(a)ripe.net] Re: [ipv6-wg@localhost] Re: What is a site? Hi all, please, let´s get back to the main question - what is a site ? I think we need a definition for this, because we find a lot of different means (eg. endsite, single network, customer, subscriber) in the IPv6 allocation and assignment policy and the RFC3177. Lets view a concrete example : A customer of us, a shipping company has ten brances at ten different locations. And he is running a seperated network behind our acces router on each loctaion. >From our point of view and understanding the RFC3177 each location is a site and we assign a /XX to each branch. Do you agree on this, or are there different opinions ? Kind regards Eric Schmidt LIR de.telekom

1 0

[ipv6-wg@ripe.net] HD ratio issues and revisiting /48
by Iljitsch van Beijnum 05 May '05

05 May '05

Consider this my input for tomorrow's discussion. I'm far away but I'll be with you guys in spirit. (And watching!) Ok, this message is becoming rather long. Skip to the end for the practical stuff if necessary. I believe Geoff's point with the presentation yesterday was "with only 45 bits to play with and considering the HD ratio IPv6 address space isn't as unlimited as it once seemed". The whole idea behind the HD ratio is that the more you have, the more you waste. And "more" isn't just more in absolute terms, but also in relative terms. Essentially an HD ratio of X percent says you'll waste X percent of your address bits. To some degree, this makes sense. If you have a flat numbering plan you need N numbers plus some wiggle room. But if you introduce a strictly hierarchical addressing plan, you need more wiggle room. For instance phone numbers we have in most European countries have area codes for cities and then subscriber numbers within each city. When phone numbers in Amsterdam run out, they can't borrow numbers from The Hague. So not only do we need wiggle room for both aggregation levels (national and city), but in phone numbers we also lose some serious number capacity because the boundary isn't very flexible. In the Netherlands even the smallest area codes hold 6 digit subscriber numbers. This eats up more numbers than when you can give the smallest area codes 5 digit numbers, or better yet, use 4.5 - 7 digit as needed. Now the interesting thing is that the HD ratio RFC (RFC 3194) is for a large part based on experiences with French phone numbers. It's easy to see that even though Alain Durand and Christian Huitema are obviously on to something, there must be a problem somewhere, as they write that the practical maximum (= HD ratio of 87%) utilization for IPv4 is 240 million addresses. (Actually that would be 211 million, they didn't compensate for class D and E and other unusable address space.) However, according to the most recent ISC host count were now at 317 million (= hosts present in the reverse DNS) while only 2.5 billion out of 3.7 billion usable IPv4 addresses have been allocated by IANA. So the current HD ratio for usable non-reserved IPv4 space is 90.5%, and this includes legacy space, so if we were to look at RIR space only, this would certainly be even higher. If we apply the same HD ratio to the remaining 1.2 billion addresses, we should be able to grow to 480 million IPv4 addresses in use without even taking legacy space issues into account. The HD ratio also doesn't account for the nature of the number hierarchy. In phone numbers or classful IPv4, you can't move the aggregation boundaries around. But with CIDR and VLSM (variable length subnet masks, at one point a great innovation), this is not a problem. So if you have 8 locations that need 100 - 800 addresses respectively, you don't need 8 x 1024 = 8192 addresses, but 128 + 256 + 3 x 512 + 3 x 1024 = 4992 addresses, or even 1, 2, 3, 4, 4, 5, 6, 7 * 128 = 4096 addresses. This will of course push some of the pain up the next aggregation level, as rather than a single route there will be 8 to 32 individual routes. When we cross over to inter-domain routing, this is clearly harmful since we are currently unable to aggregate in the interdomain routing space unless aggregation was already done (or at least possible) at the source AS. But for interior routing, this really isn't much of a problem. Even when routing a billion (2^30) /48s, that would boil down to: 2 levels, strict hierarchy: 2 * 2^15 routes 3 levels, strict hierarchy: 3 * 2^10 routes This is all very doable with today's hardware. Even if we assume a size difference of a factor 64 between the largest and the smallest entities in a loose hierarchy (ie. if Mexico City is your largest entity, the smallest would be a city with less than half a million people) that's 2^15 + 2^21 with two levels and 2^10 + 2^16 with three levels. Conclusion: you don't _have_ to lose one bit out of five as the allocated address space gets bigger. This also applies to interdomain routing. If you want to number 4 billion end-sites, Geoff's presentation lists a /8 as the prefix length of choice. But 4 billion also happens to be 256 * 16 million, and for 16 million we only need a /18. So 256 of those would be a / 10. We just saved 2 bits but now we have 256 /18s in the global routing table rather than one /8. But even someone who gets as much flack for not trusting the router vendors to come up with bigger boxes as me can appreciate that routing a larger number of /18s isn't going to kill BGP (there can only be 32 - 256 thousand /18 routes anyway). (With apologies for the thousand = 2^10 and million = 2^20.) !-!-!-! So where does this land us in the "create more wiggle room" debate? I think it's pretty clear that there is no immediate danger if we don't. On the other hand, if we can save some bits without real pain, why not do it? Going from /48 to /56 as a general recommendation would be one way to do that. Another way would be to keep the /48 for people who want it, but move the /64 to /60. It's practically impossible to utilize /128s in IPv6 (it can be done but it's just too painful and awkward). So: Now: /64 or /48 /56 idea: /64 or /56 /60 idea: /60 or /48 Giving everyone who needs address space a /60 rather than a /64 has the advantage that there is always room for a router. If my cell phone gets a /64, that's nice, but it means the phone has to bridge or proxy ND or some such. With a /60 I can have a subnet of my own for the bluetooth link, and another for the GPRS/UMTS link. Obviously this will increase the address consumption for people who would otherwise have gotten a /64, but even if there are many of those, that doesn't add up too badly. However, 95% of the people who would have gotten a /48 and 99% of the people who would have taken a / 56 would also be happy with a /60, and this would save a lot of address space. I also believe /60 vs /48 will make ISPs happier, as they're used to making SOHO/BigCu$tomer distinctions today and /60 vs /48 would pretty naturally fall into this. However, I stronly believe that EVERYONE who wants one and has an ISP who is reasonable should get a /48 no questions asked for the exact reasons that we have the "let them eat /48s" rule today. I would also suggest that all individual /48s would be registered in RIR databases.

1 0

[ipv6-wg@ripe.net] Glueing to the "."...
by Carlos Friacas 04 May '05

04 May '05

Hi, As far as i know, the possibility of having AAAA glue records on the root zone was a long and hard quest... Now that we have it for some time, is it important to ask what is being done with this possibility??? Well, i do think YES... and by reading the DNS root zone what i can see is: - 42 ccTLDs glued - 4 gTLDs glued (.com, .int, .aeros, .net) - only 35 different servers/names with AAAAs on the root zone (NS0.JA.NET has 2!) - most of the TLDs supported by nameservers with AAAAs has only one or two. Should we expect an improvement in these numbers soon? :-) Comments...? ./Carlos -------------- http://www.ip6.fccn.pt/nativeRCTS2.html Wide Area Network (WAN) Workgroup, CMF8-RIPE, CF596-ARIN FCCN - Fundacao para a Computacao Cientifica Nacional http://www.fccn.pt "Internet is just routes (150665/657), naming (millions) and... people!"

1 0

[ipv6-wg@ripe.net] Agenda for ipv6 wg RIPE50
by David Kessens 03 May '05

03 May '05

Please see below for the ipv6 working group agenda. David Kessens --- Interesting topics (from an ipv6 perspective) in the presentation sections: Monday, 2 May 2005 14:00-15:30 * Quality of Service Measurement in IPv6, Issues and Solutions (Alessandro Bassi, Hitachi) * How to set an Internet2 Land Speed Record (Anders Magnusson, Lulea Tekniska Universiteit) Tuesday, 3 May 2005 16:00-17:30 * Global IPv6 routing table status (Gert Doering) --- Agenda for the IPv6 Working Group Meeting RIPE50 When: Friday, 6 May 2005, 09:00 - 10:30 Where: C58, Clarion Hotel, Stockholm, SE A. Administrative stuff - appointment of scribe - agenda bashing (David Kessens) B. Quick update from the RIPE NCC regarding ipv6 services (RIPE NCC) C. Discussion on: Global IPv6 routing table status (Gert Doering) D. Revisiting the /48 recommendation (Gert Doering, Thomas Narten, David Kessens) Discussion, read rfc3177 as preparation E. Renumbering ipv6 networks (Stig Venaas, Tim Chown) F. Report(s) about *actual* v6 traffic volume as compared to v4? *what's real* out there, not what's on powerpoint? (input from the audience) G. Developments/initiatives regarding IPv6 in the RIPE region and beyond - IPv6 - Advanced Network Developments's first year (Carlos Friacas) - 9K IPv6 Schools' Network Initiative (Carlos Friacas) - About the IPv6 Steering Commitee: (Carlos Friacas) - Point6 (http://www.point6.net/) (Francis Dupont) - New Operational IPv6 maillist: http://lists.cluenet.de/mailman/listinfo/ipv6-ops/ (Gert Doering) - ... H. Input for the RIPE NCC Activity Plan (input from the audience) Z. AOB ---

4 4

[ipv6-wg@ripe.net] Call for agenda items & Draft Agenda (v1) for ipv6 wg RIPE50
by David Kessens 26 Apr '05

26 Apr '05

Please see below for a draft (v1) of the ipv6 working group agenda. I am interested in your input for agenda items: whether you want to discuss a particular topic, or do a presentation that affects ipv6 deployment in the RIPE region (and beyond), everything *technical* is welcome. As you might have noticed, the meeting format of the RIPE meeting was changed. The intention is to do most of the presentations in the EOF part of the meeting while the practical working group work is done in the actual working group. As of this writing, I have not received final details on how this will work out exactly. At first, I planned to wait with my solicitation for agenda items until the details regarding this new approach were more clear and announced to the community. However, as the actual date of the meeting is getting closer, I have decided not to wait any longer. I hope this helps and see you all in Stockholm, David Kessens --- Draft Agenda (v1) for the IPv6 Working Group Meeting RIPE50 When: ?, May 2005 Where: ?, Clarion Hotel, Stockholm, SE [ Presentation section ] A. Global IPv6 routing table status (Gert Doering) [ Working group section ] B. Administrative stuff - appointment of scribe - agenda bashing (David Kessens) C. Quick update from the RIPE NCC regarding ipv6 services (tentative) D. Discussion on: Global IPv6 routing table status (Gert Doering) E. Renumbering ipv6 networks (Stig Venaas, Tim Chown) F. Report(s) about *actual* v6 traffic volume as compared to v4? *what's real* out there, not what's on powerpoint? (input from the audience) G. Developments/initiatives regarding IPv6 in the RIPE region and beyond (input from the audience) H. Input for the RIPE NCC Activity Plan (input from the audience) Z. AOB ---

2 1

[ipv6-wg@ripe.net] New IPv6 Address Block Allocated to the RIPE NCC
by Filiz Yilmaz 20 Apr '05

20 Apr '05

Dear Colleagues, The RIPE NCC received the IPv6 address range 2A00::/21 from the IANA in April 2005. You may wish to adjust any filters you have in place accordingly. More information on the IP space administered by the RIPE NCC can be found on our web site at: <https://www.ripe.net/ripe/docs/smallest-alloc-sizes.html> Regards, -- Filiz Yilmaz RIPE NCC

1 0

[ipv6-wg@ripe.net] New international IPv6 operators forum
by Daniel Roesen 16 Apr '05

16 Apr '05

Dear RIPE IPv6 WG, people were missing a global mailing list (not regional RIR/NOG) dedicated to _operational_ matters of the global IPv6 (production, not 6BONE) Internet. To fill this void I've created such a mailing list: http://lists.cluenet.de/mailman/listinfo/ipv6-ops/ So if you're taking part in IPv6 BGP or are interested in global IPv6 operational matters, feel more than invited to join the list! We do have IPv6 ops people from all regions on board to foster exchange of experience and resolve problems which require someone non-local coordination as well as discuss problems people face while deploying IPv6. Please also let your collegues/upstreams/peers/downstreams know. Currently, there are ~250 people subscribed (after only 3 days or so of existence), including many vendors. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr(a)cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

1 0

[ipv6-wg@ripe.net] New IPv6 Cluster publication: IPv6 and Broadband
by JORDI PALET MARTINEZ 14 Mar '05

14 Mar '05

http://www.ist-ipv6.org/modules.php?op=modload&name=News&file=article&sid=98 8

2 2

[ipv6-wg@ripe.net] IPv6 access to K-root
by Andrei Robachevsky 28 Feb '05

28 Feb '05

Colleagues, K-root server has now IPv6 transport enabled. k.root-servers.net. AAAA 2001:7fd::1 A 193.0.14.129 This information is also available from www.root-servers.org webiste. Regards, Andrei Robachevsky RIPE NCC

11 21

[ipv6-wg@ripe.net] RV:Call for Papers - Next Global IPv6 Summit in Spain
by JORDI PALET MARTINEZ 27 Feb '05

27 Feb '05

Hi all, Several people requested an extension of the deadline for the submission of the short abstracts for their presentations. So we decided to extend the deadline until midnight of March 4th. Please make sure to not miss it this time. We only require a title for your presentation and 3-4 lines short abstract. The final agenda will be announced at the end of the following week. Regards, Jordi Hi all, As indicated in the email below, the next Global IPv6 Summit in Spain, the bigger IPv6 European event, in its 4th edition (after a very successful organization and broad international attendance in 2001, 2002 and 2003), will be organized this time in Barcelona, next June 2005, with a expected audience over 2.600 key decisions makers from ICT sectors. The main target of the event is business oriented talks, as well as talks oriented to policy makers, information/knowledge society, education and public sectors. This Call for Papers doesn't require that you submit a complete paper (which is welcome also), but instead, a short plain text abstract of your presentation topic, by email. Talks regarding deployment experiences, new services and applications will be of key interest for the expected attendance, and hence highly encouraged. We believe that key topics will be also those regarding: 1) IPv6 and business 2) IPv6 and Broadband 3) New IPv6-based services and applications 4) IPv6 and the Digital Home 5) IPv6 and Multimedia, Voice/Video applications 6) IPv6, Mobility, Wireless and 3G 7) IPv6 and Ambient Intelligence/Ubiquitous Computing/Distributed Systems 8) IPv6 and GRIDs 9) IPv6 and logistics, transport and eSafety 10) IPv6 for eHealth, eGoverment, eLearning and other "e-whatever" 11) IPv6 and gamming 12) IPv6 and peer-to-peer 13) IPv6 and security 14) IPv6 and Open Source 15) IPv6 and marketing/branding Also topics regarding Standards, Research, Development and Innovation experiences are welcome, including R&D projects results. The Agenda will be drafted early in March, so the dead-line for submitting your topic is only until 25th February, but as said only a short abstract is required. If you're interested in participating, or you have any special idea, even if your topic is not in the list above, please don't hesitate to contact me (jordi.palet(a)consulintel.es) ASAP, so we can work out any options. Regards, Jordi PS: Please, feel free to circulate this email among your contacts. ------ Mensaje reenviado De: JORDI PALET MARTINEZ <jordi.palet(a)consulintel.es> Responder a: <jordi.palet(a)consulintel.es> Fecha: Mon, 07 Feb 2005 18:25:42 +0100 Para: "members(a)ipv6forum.com" <members(a)ipv6forum.com>, <tf-sc(a)ipv6tf.org> Asunto: Next Global IPv6 Summit in Spain Hi all, As I already informed a few weeks ago, the next Global IPv6 Summit in Spain will be held this time in Barcelona next June (instead of Madrid in March as previously forecasted). This will happen starting on June 6th, with a tutorial in the morning, the opening ceremony in the afternoon, with some keynotes and then 2-3 days of IPv6 conference, depending on the success of the call for papers. If required we can extend our event up to Friday 10th (total 4 days, plus opening ceremony, plus half day tutorial). In this occasion, we will try a completely new model, integrating the IPv6 conference in a bigger event, more business oriented, even when technical sessions will be still present. The "umbrella" event is Internet Global Congress (IGC), with has been organized in Barcelona already during the 6 previous years. The Internet Global Congress, the leading Internet and New Technologies congress in Spain, is organized by the Fundació Barcelona Digital, a non-profit organization, which also provides space for exhibition and delivers the IGC awards for Digital Innovation (aimed to students and professionals with embryonic Internet projects, aims to be a launch platform for all those people involved in research and innovation in the field of Internet and the New Technologies). IGC provides us all the infrastructure for organizing the Global IPv6 Summit track, and we only need to manage our own agenda, and consequently our own call for papers (see next email). They also they care about all the issues related to registration, proceedings and publicity, at no cost for us. We expect that this will be the bigger IPv6 event in Europe during 2005, with an expected attendance over 2.600 people, which of course, will be able to attend not just to the IPv6 track but also to other IT tracks (already depicted at http://www.igcweb.net, then click at Program). The attendance is mainly CTOs, CEOs and other key decision makers related to ICT, so its a very nice opportunity for IPv6 in Europe to meet a large audience which probably has not been in touch with IPv6 until now. I count with the support from all of you, and please do not hesitate to let me know any ideas that you may have to make an even more successful event that what for sure we will have in a so nice city as Barcelona. More information will be soon available at http://www.ipv6-es.com and http://www.igcweb.net. Regards, Jordi ------ Fin del mensaje reenviado ************************************ Barcelona 2005 Global IPv6 Summit Call for Papers and information available at: http://www.ipv6-es.com 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.

1 0