- ipv6-wg - mailman.ripe.net

RE: IPv6 assignments to DNS root servers in the RIPE region
by matthew.ford＠bt.com 24 Apr '02

24 Apr '02

I couldn't agree more. The only conceivable objection to the proposal is that it potentially sets a precedent that will be used to trash the IPv6 routing heirarchy. Given carefully worded policy, that precedent need not be set. Mat. > -----Original Message----- > From: Gert Doering [mailto:gert@space.net] > Sent: 24 April 2002 13:55 > To: Randy Bush > Cc: Joao Luis Silva Damas; lir-wg(a)ripe.net; ipv6-wg(a)ripe.net > Subject: Re: IPv6 assignments to DNS root servers in the RIPE region > > > Hi, > > On Wed, Apr 24, 2002 at 08:44:44AM -0400, Randy Bush wrote: > > > Seriously now. I strongly believe that if a root server > were to stop > > > operations, it would be in everyone's benefit that either > the address > > > space where it is hosted moves with it OR **the address > space which > > > it was using is returned** > > > > nope. should nasa return 128.8 just because the server is > moved from > > 128.8.10.90? i don't think so. but, if it is moved, they > should not > > put anything else at 128.8.10.90 for a decade or two. > > Which makes you agree with Joao, doesn't it? The way it was done with > 128.8 obviously created problems, which would mean that > "special networks > for root name servers" might be a good thing after all... > > Lacking experience with root name server operations, I didn't comment > the whole proposal yet, and I'm still not sure what is "the > right thing > to do". > > Let's turn it around - which of both approaches would be "the > wrong thing > to do", and why? > > Having special-case networks for every other purpose is clearly a bad > thing, but I think most would agree that root name server > *are* special > because that's the only thing you cannot (completely) put into DNS... > > With the number of root name servers, I don't see any major issues due > to address wastage or enormous numbers of additional routes. > > Just my $0.2... > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: 44543 > > SpaceNet AG Mail: netmaster(a)Space.Net > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > 80807 Muenchen Fax : +49-89-32356-299 >

1 0

Good morning
by Pim van Pelt 22 Apr '02

22 Apr '02

Dear wg members, This is Pim van Pelt with Business Internet Trends in the Netherlands. I have been active in the IPv6 scene since 1996 and am currently in the process of helping Dutch ISP companies take their first steps onto the IPv6 Internet at AMS-(v6)-IX. I'll be attending the RIPE42 meeting due to its sequencenumber and would very much like to introduce myself to the current members and in the process bring to your attention two topics. The first is a request from David. He's asked me to explain a bit about one of my IPv6 related projects called IPng.nl - a tunnelbroker which is open to the public. I hear that many individuals and companies wishing to hook up to the 6bone (only) know of the FreeNet tunnelbroker. Somehow it is a 'preferred' access point for many, but there are alternatives for Europe and the RIPE region. I'd like to discuss some tunnelbroker activity on a larger-than-IPng.nl scale with some other IPv6 operators. Second, I'm going to write a document describing a step by step 'howto' for (dutch) ISPs wanting to hook up with 6bone or request an sTLA but who might be in need of a jumpstart and practical pointers. The ultimate goal of this project is to send a mailing to all of the ams-ix members inviting their engineers to a handson course, held at the Kruislaan. I would like to do this in collaboration with the RIPE-NCC and the AMS-IX o NOC, and have found Ted Lindgren from NLNet Labs, Hans Leemans from the NLIP and Michiel Leenaars from the ISOC willing to help me with this project. I will present my ideas on both topics during the WG session and hope to meet you there. groet, Pim van Pelt -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim(a)ipng.nl http://www.ipng.nl/ IPv6 Deployment -----------------------------------------------

3 2

Re: Draft minutes of the IPv6 wg session at RIPE41
by Mohsen Souissi 15 Apr '02

15 Apr '02

Oops ! Sorry David, I react a bit late but please let me do it anyway even if my comments may not be taken into account. These comments which will be placed below in their context are related to what I am supposed to have said at RIPE Meeting 41 :-) On 28 Mar, David Kessens wrote: | | Please see below for the first draft version of the minutes of | the IPv6 wg session during RIPE41. | | Please take a look at it and report typos, errors and omissions. | | The minutes (with possible minor corrections) will be declared final | if I receive no comments and/or only minor typographical errors by | Friday April 12th, 2002. | | Thanks, | | David K. | --- | | ----------------------------- | | RIPE 41 | Amsterdam | Ipv6 Working Group | Wednesday 16th January 2002 16:00 - 17:30 | Chair - David Kessens | 117 attendees present | | [...] | | D Developments/initiatives regarding IPv6 in the RIPE region and beyond | (input from the audience requested) | | Comment: DNS deployment in IPv6 and support of v6 in DNS, we have a | secondary server in Spain, if other European countries | (outside Spain) are interested in supporting DNS/IPv6 maybe | we could arrange some collaboration. | ==> I said (meant) : "We (French NIC) have a secondary DNS IPv6-capable server which already hosts .fr zone and other TLD zones such as .re, .es, .br and .dz. We are looking forward to do some collaboration in DNSv6 field with other European TLDs. | A: Can I volunteer you to discuss this at the next meeting? | A: Yep! | | [...] | | Z AOB | | Reverse Delegation in v6 | | I would like to talk about the slow down of services offered. There | is a plan of migration, rir's asked for reverse delegation which was | done. We can see that v6 arpa have none of them! In November we sent | a mail to Iana hostmasters to tell them, we can also be a secondary | for arpa, so far we have had no response! I am therefore concerned | of willingness for v6, things are going well but people are not | encouraged! ==> This paragraph which attempted to translate what I said should be read this way : I would like to talk about the slow down of DNSv6 service deployment. There is a plan of migration from ip6.int to ip6.arpa for the IPv6 revese tree. RIRs have already asked for reverse delegation of their blocs and that has already been done. But no name server among the authoritative ones for ip6.arpa talks IPv6 ! In November we sent a mail to IANA hostmaster to tell them, we can also be a secondary for ip6.arpa. So far we have had no response! I am therefore concerned of willingness for deploying IPv6. Things are going well from a standardization point of view but from a practicle point of view people are not encouraged! | [...] | | Q: is there anything we can do as a community, i.e. make it clear to | the ripe community that we want this? | A: yes | A: we can then approach Icann about this. You should be asking the | RIPE NCC when we can use v6 in the name server. | | Conclusion | | Hopefully the agenda will be fuller next time, if you have any | suggestions please let David know so that we can have more agenda | points. | | It could be interesting to see a road map plan, I see we have Cisco | and Juniper here so can you help me do this for next time? | A: Yep! | Regards, Mohsen. -- Mohsen Souissi *********************************************************************** * AFNIC - http://www.nic.fr * ***************************************+******************************* * Tel. : +33 1 39 30 83 40 | Fax : +33 1 39 30 83 01 * *--------------------------------+------------------------------------* * Immeuble International - 2, rue Stephenson - Montigny le Bretonneux * * 78181 Saint Quentin en Yvelines Cedex, France * ***********************************************************************

1 0

raw ipv6 sockets - sin6_scope_id field
by user user 08 Apr '02

08 Apr '02

hello, what should be filled in the sin6_scope_id field of the sockaddr_in6 structure ? Is it the interface index ? If yes, how do I determine the interface index of my ethernet card ? ifconfig says: Scope:Link ------ I need it bcoz I'm trying to send a msg over raw ipv6 sockets and the sendto() function gives the following error at run-time: invalid argument ------- Does anyone know of pointers to example programs for ipv6 raw sockets ? waiting for QUICK responses, thanks in advance. --------------------------------- Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax

2 1

Summary of IPv6 Policy Discussions at RIPE41
by James Aldridge 27 Feb '02

27 Feb '02

With apologies for the time that it's taken me to get this posted to the list, here is an attempt to summarise the discussions which took place among the approx. 180 people attending the Local IR working group at RIPE41 on 16th January 2002. Although many of those attending the working group had read the published draft, | IPv6 Address Allocation and Assignment Global Policy | Draft of December, 22 2001 | Version 2001-12-22 | APNIC | ARIN | RIPE - NCC we started this session with a presentation by Mirjam Kuehne from the RIPE NCC (http://www.ripe.net/ripe/meetings/archive/ripe-41/presentations/ipv6-mir/) which summarised the main points of the current document. Most of the discussion centered on section 5.2 of the draft related to the Initial Allocation Criteria and Initial Allocation Size | 5.2.1. Initial allocation criteria | | A requesting organization can receive an initial allocation by | demonstrating that it has an immediate (i.e., within next three | months) requirement for at least a /36 prefix. That is, immediately | after the allocation, the organization will have 776 or more sites in | need of address assignments. 776 is the number of /48 address blocks | that can be assigned out of a /36 address block to achieve an HD- | Ratio of 0.8. The HD-Ratio is an address allocation utilization | metric proposed in RFC 3194 as an adaptation of the H-Ratio | originally defined in [RFC1715]. (See also Section 5.3.3.) | | [Note: discussion is needed as to whether justification for need of a | /36 is reasonable initial starting point, or whether the criteria of | an immediate need to address 776 sites is too high. Note also, that | once a request for an initial allocation has been granted, the | minimum allocation (i.e., /32) is provided, even though the requestor | has not justified a need for such a large amount of space.] The general consensus at the meeting was that this placed too high a barrier to registries at a time when getting real IPv6 deployment underway was seen as becoming more urgent. Several alternatives were discussed, but the one which seemed to achieve almost complete consensus from those at the meeting involved dropping the "776 or more sites" and HD-Ratio requirements completely. The proposal can be summarised as: "For a limited period (no more than the first 2000 allocations in each RIR area was suggested), a requesting registry (either a LIR or NIR in the draft's terminology) would receive a /32 minimum allocation from the appropriate RIR on the documentation of at least one /48 assignment." This is just one way of removing the barrier imposed in the current draft... there are, of course, other possibilities which weren't discussed at the meeting. This lowers the barrier to whatever policies the RIRs have in place for the establishment of new local or national registries. The aim was seen as being to obtain global consensus based on the current draft as an *interim* policy, with final policy being worked on as experience was gained during the "2000*3 allocations" period. Time was such that discussion of other sections of the draft were only covered briefly, if at all. James Aldridge (Co-chair, RIPE LIR WG)

1 0

up a few thousand meters
by Randy Bush 15 Feb '02

15 Feb '02

the rirs, as the meeting place of those responsible for prudent operation of the network, have traditionally been where the compromise between the three *competing* and *conflicting* vectors of o address space conservation, o routing table growth, and o ease of allocation for isps have responsibly reached compromise. this has not been an easy balance because the three really are in conflict with each-other. but, as prudent operators, and as shepherds of a public good, we have struggled along to manage in a really pretty responsible fashion. witness that one can get and use the ip space one needs, the routing table has not gotten completely unmanageable (especially if you filter prudently <g>), and there is a fair amount of v4 space left. as we move into the v6 world, prudent folk find it hard not to assume that the same or similar forces will be at work. v6 gives us zero leverage on the routing table expansion problem. there is no reason to believe that the seemingly enormous 128 bit address space of v6 will turn out to be any more infinite than the seemingly enormous 32 bit address space did some decades ago. and, as operators, we still have the annoying problems and responsibilities of acquiring, tracking, allocating, ... the address space which is vital to our businesses. in moving forward, it would seem irresponsible to let one consideration obviate all others. e.g. some once thought tlas would solve the routing table growth issue by limiting the global universe to 8k isps. this month, others think ease of allocation is most important, and the problems of address consumption and routing table growth are old-fashioned fears. sadly, as we have discovered in exploring the issues of multi-homing and routing table growth, and as we learned that frequent and rapid renumbering may not be the realities, we seem to need to be a bit cautious about the new world, and not leap to bold conclusions and make radical changes based on yet to be proven assumptions. as isps, in our rush to make life easy for ourselves at the possible expense of other considerations, let us not again demonstrate george santayana's wisdom by repeating history, again creating a swamp, losing track of detailed allocation data, ... as far as i can tell, v6 deployment is not being inhibited by issues surrounding address space allocation. randy

6 10

Re: [GLOBAL-V6] Re: up a few thousand meters
by Randy Bush 14 Feb '02

14 Feb '02

> Agreed. As some of us think it would be a good thing to push IPv6 > onwards, we de-emphasize conservation right now, and emphasize > easy access to address space. this seems to be based on some idea that it is address space policy, as opposed to continuingly changing the policy, which is inhibiting the deployment of v6. this does not seem to be the case. > But let's rethink whether all of our experience is fully appropriate > in changed circumstances. re-thinking is always good. acting before thinking is generally not. randy

2 3

RE: up a few thousand meters
by Lelieveld, Sander 12 Feb '02

12 Feb '02

Hi all, Please can you put "[GLOBAL-V6]" or something in Subject field. Regards, Sander Lelieveld Alcatel Netherlands. -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi] Sent: dinsdag 12 februari 2002 13:13 To: Daniel Karrenberg Cc: global-v6(a)lists.apnic.net; ipv6-wg(a)ripe.net; Randy Bush Subject: Re: up a few thousand meters On Tue, 12 Feb 2002, Daniel Karrenberg wrote: > - V6 per-se does *not at all* solve the routing (table) problem > That's true in a technical sense. However, there are a few reasons why we, even though IPv6 does not solve the problem, _can_ solve it: 1) organizations, however large, can be represented by one "dot", a /48. This enables us, at worst, to have O(organizations) routing table entries, not O(organizations * average number of nodes per organization). The former is too big still, but it is still good news and makes aggregation and address space estimations easier. 2) it's all new protocol -- not a win as such, but due to this, we can _reinvent_ the routing system (within some restrictions) the way we see fit, based on earlier experience. Let's not pretend 2) does not exist. There are 6bone routing guidelines, which have been happily adapted by production operators (sTLA) also; they prevent most of the problems we're now facing with IPv4 global routing table growth. Why toss all of that aboard, pretending we cannot work around the routing problem for now when moving to IPv6 (note: I didn't say IPv6 would magically solve the problem!)? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords

1 0

Re: [GLOBAL-V6] up a few thousand meters
by Randy Bush 12 Feb '02

12 Feb '02

apocrypha can be misleading > As far as I can tell, v6 deployment in the ARIN region is not taking > place due to desinterest. > > The APNIC people have very clearly stated at R40 (at least) their need > for a workable interim policy, and there is still none. They are > building production IPv6 networks today. come to ietf in minneapolis, which is still in the arin region as far as i know, where c&w will be the upstream running native v6 on their backbone. [ this is not a side prototype atm network running on bsd/kame or cisco's slow path marketecture, but a full bore, line rate, native v6 enabled backbone ] randy

1 0

Válasz: [GLOBAL-V6] Re: Válasz: [GLOBAL-V6] RE: How to reduce the junk applications?
by turchanyi.geza＠ln.matav.hu 12 Feb '02

12 Feb '02

Gert, I agree, ONE DAY setting up IPv6 only services MUST be possible. However, I do not think that we can apply this assumption today. Most probably not in the next two years to come. The question here is how to enable the transition period for most of the ISPs as soon as possible, without creating too big mess. If you end up with a heavily scattered address space, then the IPv6 transition is killed before it has been completed. Everybody will have addresses, just the routing will be missing. I do not know how to solve all aspects of this problem, but keeping the number of IPv6 LIRs under control is a MUST, I think. Best, Geza Gert Doering <gert(a)space.net> dátum: 2002.02.08 14:46:46 Címzett: Turchányi Géza/PKI/HTC2@HTC2 Másolat: "Wilfried Woeber, UniVie/ACOnet" <woeber(a)cc.univie.ac.at>, denesh(a)cyberstrider.net, global-v6(a)lists.apnic.net, ipv6-wg(a)ripe.net Tárgy: [GLOBAL-V6] Re: Válasz: [GLOBAL-V6] RE: How to reduce the junk applications? Hi, On Fri, Feb 08, 2002 at 02:17:29PM +0100, turchanyi.geza(a)ln.matav.hu wrote: > 1, I do not think that it is possible to create a brand new ISP without IPv4 > experience, therefore my suggestion is not a restriction for a real ISP, just > for the virtual ones. It MUST be possible if we want IPv6 to be a success. It's to be assumed that the employees of this company will have IPv4 experience (of course), but that doesn't mean the company has a track record of "having been IPv4 LIR for xx years". > 2, It is not mandatory to create a LIR In order to provide an IP service. An > other LIR can provide a service for you. But for those cases, this whole discussion does not apply. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71770 (72395) SpaceNet AG Mail: netmaster(a)Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 - - This list (global-v6) is handled by majordomo(a)lists.apnic.net

2 1