- ipv6-wg - mailman.ripe.net

RE: IPv6 assignments to DNS root servers in the RIPE region
by Guy Davies 24 Apr '02

24 Apr '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Gert, I think what Joao was suggesting was that if the nameserver had been in NASA's v6 block, then rapid renumbering would have made it viable to demand the whole block back from NASA when the nameserver was shutdown. While this is nice in theory, I tend to agree with Randy that it is not very likely in reality for a huge organisation like NASA. Regards, Guy > -----Original Message----- > From: Gert Doering [mailto:gert@space.net] > Sent: Wednesday, April 24, 2002 1:56 PM > 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:50:05AM -0400, Randy Bush wrote: > > > No, NASA should probably not return their IPv4 space. > With IPv6 you > > > can do it right, so why not do it right? > > > > oh, i forgot ipv6's rapid renumbering. i also forgot santa > claus and > > the tooth fairy. > > Huh? What does this have to do with anything? > > This proposal is about NOT changing IPv6 root name server > addresses, and > NOT about "easy renumbering". > > 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 > -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.1 iQA/AwUBPMauCY3dwu/Ss2PCEQLfkwCg7upE2tAaEQ2GoHjIlRwwIEkLez8AoMjD X24zM7WSw2QARZm0DFdvnnCx =WbDK -----END PGP SIGNATURE----- This e-mail is private and may be confidential and is for the intended recipient only. If misdirected, please notify us by telephone and confirm that it has been deleted from your system and any copies destroyed. If you are not the intended recipient you are strictly prohibited from using, printing, copying, distributing or disseminating this e-mail or any information contained in it. We use reasonable endeavors to virus scan all e-mails leaving the Company but no warranty is given that this e-mail and any attachments are virus free. You should undertake your own virus checking. The right to monitor e-mail communications through our network is reserved by us.

4 3

RE: IPv6 assignments to DNS root servers in the RIPE region
by Guy Davies 24 Apr '02

24 Apr '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > In message > <C653AC166708D51195D600034723D865075BBB(a)cain.telindus.co.uk>, Guy > Da vies writes: > > >Hi Gert, > > > >I think what Joao was suggesting was that if the nameserver had > >been in NASA's v6 block, then rapid renumbering would have made it > >viable to demand the whole block back from NASA when the > >nameserver was shutdown. While this is nice in theory, I tend to > >agree with Randy that it is not very likely in reality for a huge > >organisation like NASA. > > As I read it, it means that the root-server will get its own > allocation, and that allocation follows the rootserver around. That's the original discussion point. However, there's a little throwaway comment in one of Joao's subsequent emails in which he says... "No, NASA should probably not return their IPv4 space. With IPv6 you can do it right, so why not do it right?". To me, that implies that you can force an organisation like NASA to return *all* their v6 space and renumber in this kind of situation. > Sounds surprisingly reasonable to me. For the initial discussion point, yes. For the subsequent point, above, absolutely not. Guy -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.1 iQA/AwUBPMavqo3dwu/Ss2PCEQJL/wCfRGx6hetMOJqPCh/+d/thPLA9dssAn0y3 1KYq6bIEy0YhVED7SbjmdxTV =0hrB -----END PGP SIGNATURE----- This e-mail is private and may be confidential and is for the intended recipient only. If misdirected, please notify us by telephone and confirm that it has been deleted from your system and any copies destroyed. If you are not the intended recipient you are strictly prohibited from using, printing, copying, distributing or disseminating this e-mail or any information contained in it. We use reasonable endeavors to virus scan all e-mails leaving the Company but no warranty is given that this e-mail and any attachments are virus free. You should undertake your own virus checking. The right to monitor e-mail communications through our network is reserved by us.

1 0

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