- ipv6-wg - mailman.ripe.net

[ipv6-wg@ripe.net] Minutes from IPv6 WG - RIPE 49
by David Kessens 01 Jun '05

01 Jun '05

Please see below for the final minutes of our session during RIPE 49. The minutes are mostly the same as the v1 draft minutes that were posted earlier. Only differences are a typo fix and an improved summary of Jordi's presentation on 'Guidelines for ISPs on IPv6 Assignments to Customers'. I will sent out the draft minutes for our meeting during RIPE 50 in a couple of minutes. David Kessens --- Minutes from IPv6 WG - RIPE 49 RIPE 49 Manchester IPv6 Working Group Wednesday 22 September 2004 WG Chair David Kessens Scribe Adrian Bedford (RIPE NCC) Attendees: 121 Administration and Agenda Presented by David Kessens Adrian Bedford of the RIPE NCC was appointed scribe. Agenda was agreed Minutes from both RIPE 47 and 48 were approved. Update from the RIPE NCC Presented by Andrei Robachevsky, RIPE NCC As of August, k-root is IPv6 enabled The new version of the RIPE website (to be launched shortly) will also be IPv6 enabled. An Overview of the Global IPv6 Routing Table Presented by Gert Doering (Spacenet) A number of anomalies have been observed in the Global IPv6 Routing table, though in most cases these could be explained by traffic engineering, internal transitions and in one case a prefix leak. One person used the Jabber Remote Feedback system to ask why IXPs are announcing /48s with no export. It was explained that, for example, AMSIX doesn't want it's neighbors to make it's prefix globally visible. It remains a contentious issue as to whether something should be globally visible. What are the Deployment Plans Behind the Larger IPv6 Allocations? Presented by: Mikael Lind (TeliaSonera) David Kessens asked whether there were plans to allocate /64s for mobile use. Mikael confirmed that this was likely and that TeliaSonera was also looking at /48s for this use. Kurtis Lindqvist asked whether TeliaSonera has been talking with vendors to co-ordinate hardware and equipment. Mikael explained that this has not yet happened, as they feel right now there is little incentive to do so. David asked if Mikael would consider returning to a future RIPE Meeting to provide an update when TeliaSonera is further along in the development and deployment process, Mikael indicated that he would be happy to do so. Deployment Plans Behind Larger IPv6 Allocations Presented by Jordi Palet (Consulintel) Jordi will continue to keep the Working Group posted on feedback. He will also encourage non-respondents to contribute. Geant IPv6 Presented by Jordi Palet (Consulintel) Guidelines for ISPs on IPv6 Assignments to Customers Presented by Jordi Palet (Consulintel) This presentation provided an initial attempt on creating guidelines on how to interpret the official ipv6 assignment policy in practical terms. < BREAK > IPv6 Glue for the Root Nameservers Presented by Johan Ihrén (Autonomica) Iljitsch van Beijnum asked how long the process is likely to take. Johan commented that it would depend on who was prepared to take on the task, Johan is willing to do this, though added that nothing is root server specific, if people argue that we need v6 glue now, then they should step up and offer to help out. There is no specific target date for this to happen, since testing needs to be completed. Randy Bush asked that since we tend to assume that we should upgrade when something breaks, how is he to know when something has in fact broken. How, as an operator will he actually know there is something wrong? Johan agreed with Randy, there needs to be an agreed process. This could mean that things may not happen universally at the same time. Much will depend on the level of ambition of those involved - the tasks could be more or less complex. Gert Doering commented that as we see ccTLDs adding v6 glue, they might already know some of the issues that could arise. He suggested that someone speak to the ccTLD Operators and find someone who is willing to help with testing. It was also suggested that prudence might be a good idea. If a ccTLD Operator decides to deploy v6 transitions to their nameservers, in the end it will be their own decision. A question was asked about whether anything could be done to improve I-root connectivity to Europe. Johan commented that this would fall into his domain and promised to provide more feedback on this by RIPE 50. Bill Manning commented that the group appeared to be talking as if testing had not in fact started, whereas people are doing tests, ccTLD Operators at already looking at the impacts of these tests. A timeframe was agreed at the last ISOC meeting to finish testing before their next report at the end of the year, enabling a report to made to ICANN. One obstacle here is that the last report to the ICANN board took six months to have approved. Doug Barton of ICANN commented that the process has been streamlined and lessons learned, it is felt that any such future report would receive a far quicker response. David Kessens asked if all root servers planned to have IPv6 connectivity at the same time. Johan replied that he thought it unlikely that everyone would approach this in the same way, adding that he felt diversity was not a bad thing. It would, he said, be likely that we would see some TLDs using basic glue with others holding off during the early phases. The day when we will see the v6 glue globally is still somewhere in the distant future as there are no specific plans at this point to co-ordinate such a deployment. To date eight have basic glue in place. David asked if this community could help and Johan said he felt it certainly could. There was discussion about asking the RIPE NCC for help, though Johan this was not necessary at this stage. From his point of view he did not feel the issue was who did this, rather thought needed to be given to identifying which tests are relevant. Time would need to be taken over inventory to find out what code is already out there. David rounded up the discussion by saying that volunteers would be welcomed, though this was not be taken as a specific action point. An Update on Multihoming in IPv6 Presented by Geoff Huston (APNIC) A comment was made that the slide detailing issues appeared to not consider the update rates for bindings and third party referrals. Geoff said that design decisions should avoid relying on DNS. Randy Bush commented that there had been some mission drift from multi-homing to mobility. A comment was made that if an opportunistic solution does not meet all the needs in the architecture, you are forced to use a structured identifier. Such an identifier would have to be unique to avoid collisions. This could give rise to a very complex registration infrastructure, which might be painful to administer. Geoff replied that uniqueness never comes cheap and needs enormous effort at a global level. This lead to a suggestion that it may be preferable to choose opportunistic styles. Geoff felt that this was down to personal taste; there were certainly benefits in avoiding global costs if set up problems could be avoided. A suggestion was made that we should consider developing a whole new protocol that could handle routing table growth, Geoff replied that it would be ideal to think that we could do both, groups do exist with experience in both fields. The IETF have working groups that work together to engineer solutions and ensure routing tables do not become too complex. Geoff agreed that many people do feel routing could provide a better answer Kuris Lindqvist pointed to work that had been done during an interim meeting in Santa Monica in June 2004, this looked at the architectural work done by Geoff and the 30-40 drafts submitted. The drafts were split into four or five categories and based upon these; a simple poll was carried out. In some categories, the authors withdrew their proposals and in others, there was little support. The consensus was that the architecture proposed by Geoff was the way the group wished to move forward at the moment. A speaker announced that he had prepared a draft on the use of PI to reduce pressures on routing tables, intended as a compromise and is accepting comments on this. A speaker added that during his presentation Geoff dismissed mobile IP for security and state management reasons. The IETF has already addressed security and state management could throw up more problems. He felt that having two solutions for these issues problem was unwise and we need to work towards a single solution for what seem like related problems. He felt that using security, as a reason to reject the architecture draft was a red herring. Geoff pointed out that this is not yet in the draft, though will be in the next version. Geoff agreed that some of the assumptions we made previously in mobile IPv6 now seem less secure. Security locators assume a stable home base - if it fails, everything else fails. Multi6 looks at the ‘homeless vagrants’ of the world that do not have a home all of the time and the home is not reachable. It then assumes that there is not a home locator that can always be contacted. The Multi6 team looked at the other approaches and aimed to learn from them. He remains unsure if this kind of binding works in mobile environments, it is far too early to make this assessment. David Kessens asked whether the group found updates from Multi6 useful, Kurtis suggested that it would be nice to have Geoff make a similar presentation in future Address Policy Working Group Sessions too. Gert Doering suggested that as co-chair of the Address Policy Working Group, he would like to see the drafts on PI Addressing discussed through the Address Policy Mailing List. Moonv6 Update Presented by Jim Bound Kurtis Lindqvist asked whether security testing had been carried out in an isolated test environment. Jim clarified that filters had only been tested on IPv6 ports, addresses and protocols. He added that it showed there was confusion. Just because dual stack is not a security problem, IPv6 in itself is not an insecure protocol. Intrusion detection needs to be included into work. Kurtis asked what stage of the evolution process the project had reached. Jim replied that in this respect, research was still quite basic. Deploying 5,000 IPv6 Sites - XTEC Presented by Jordi Palet (Consulintel) Input to RIPE NCC Activity Plan Presented by David Kessens David asked if the group had any items to include in the 2005 RIPE NCC Activity Plan. There was no response.

1 0

[ipv6-wg@ripe.net] Re: [ncc-services-wg] RIPE 50 Report
by Daniel Roesen 25 May '05

25 May '05

On Tue, May 24, 2005 at 02:09:07PM +0200, Nick Hyrka wrote: > IPV6 WORKING GROUP > > - It was decided that the RIPE Whois Database will continue to include more > services that run in native IPv6. Hm? > - It was noted that the IPv6 Working Group needs to decide where it wishes > to house the new, operational IPv6 mailing list. What are you talking about here? What "new, operational IPv6 mailing list" are you referring to? What has the RIPE IPv6 Working Group to do with it? I have some suspicion that this is a reference to Ulrich Kiermayr's comment? Please clarify. Regards, Daniel -- CLUE-RIPE -- Jabber: dr(a)cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

4 5

[ipv6-wg@ripe.net] Fwd: [apops] APNIC New IPv6 address block(s)
by leo vegoda 24 May '05

24 May '05

Begin forwarded message: > From: John Tran <john(a)apnic.net> > Date: May 24, 2005 9:29:05 am GMT+02:00 > To: apnic-announce(a)lists.apnic.net > Cc: apops(a)apops.net > Subject: [apops] APNIC New IPv6 address block(s) > Message-Id: <Pine.LNX.4.61.0505231059340.10511(a)durian.apnic.net> > > > > Dear colleagues > > APNIC received the following IPv6 address block from IANA recently > and will be making allocations from this range in the near future. > > 2400:0000::/19 > > This announcement is being made for the information of the Internet > community, and so that network configurations such as routing filters > may be updated as appropriate. > > For more information on the resources administered by APNIC, see: > > http://www.apnic.net/db/ranges.html > > For information on the minimum allocation sizes within address ranges > administered by APNIC, see: > > http://www.apnic.net/db/min-alloc.html > > > Kind regards > > Son > > ____________________________________________________________________ > Resources Services Manager <Son(a)apnic.net> > Asia Pacific Network Information Centre phone: +61 7 3858 3100 > http://www.apnic.net fax: +61 7 3858 3199 > Helpdesk phone: +61 7 3858 3188 > email: > helpdesk(a)apnic.net > Please send Internet Resource Requests to <hostmaster(a)apnic.net> > _____________________________________________________________________ > > _______________________________________________ > apops mailing list > apops(a)apops.net > http://mailman.apnic.net/mailman/listinfo/apops > Website: www.apops.net > -- leo vegoda Registration Services Manager RIPE NCC

1 0

[ipv6-wg@ripe.net] Who provides v6 uplink via tunnel ?
by Kurt Jaeger 22 May '05

22 May '05

Hello, As none of our uplinks currently provides v6 support, I'm looking for some site that would be willing to route our /32 and tunnel it to some endpoint via v4. We're located in southern germany (Stuttgart). -- MfG/Best regards, Kurt Jaeger 15 years to go ! LF.net GmbH fon +49 711 90074-23 pi(a)LF.net Ruppmannstr. 27 fax +49 711 90074-33 D-70565 Stuttgart mob +49 171 3101372

5 8

[ipv6-wg@ripe.net] What is a site?
by ＠UUNET SE Ip 11 May '05

11 May '05

Hi. Following the discussion about /48 boundaries I'd like a better definition of what a site is. My definition of an end-user site is the office where we (MCI/UUNET) install a circuit. This could be a large office or a small bransch office or anything in between. Each office is handled separately and they request IPv4 addresses per office. Adopting this to IPv6 it would mean that each office would get a /48. This is too much for many of them. Approx. 80-90% of our sites request 32 IP-addresses or less and most likely only subnet it 2 or 4 times if they ever subnet it. Furthermore we never get a complete network design for all branch offices if the customer is transnational or even national so we can't really assign a /48 to the customer for him to subnet among his offices. We can of course change our procedures to accomomodate thisbut this will make things a lot more difficult for us as a LIR and also the customer. We can't decide how many addresses to assign to a customer based on size or revenue. What I want is a clear definition of what a site is by having more catagories. but I don't want a floating boundary as catagories do simplyfies things. I also include my suggestions based on where I'm coming from :-) /60 for home networks (16 networks) /56 for enterprises (small/medium) (256 networks) /48 for large enterprises (65000 networks) /47 or more for "very large subscribers" /64 for mobile phones (w/ bluetooth or 802.11b) /128 for dialup PC Please note that I'm not a routing expert nor am I a experienced in the complete IPv6 concept with mobil users and consumers goods etc. My main area is IP-address administration. I administrate IP-networks for MCI/UUNET in almost all of Europe except DE, AT and CH. I haven't read the RFC's related to this so my mind is wide open ;-) Best regards Patrick Arkley Supervisor IP/DNS-team SKSC/SKRC MCI - Powered by UUNET Armégatan 38 S-171 04 Solna, Sweden Web: www.se.mci.com <http://www.se.mci.com/> 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 <mailto:patrick.arkley@se.mci.com> Initial Call team [VPN]: +46 (0)8 5661 7899 or emea-ip-vpn-initial-call(a)se.mci.com <mailto:emea-ip-vpn-initial-call@se.mci.com> Registry: +46 (0)8 5661 7454 or registry(a)se.uu.net <mailto:registry@se.uu.net> <mailto:registry@se.uu.net> IP-team: +46 (0)8 5661 7629 or ip(a)se.uu.net <mailto:ip@se.uu.net>

13 44

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

10 May '05

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

2 1

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