From andrei at ripe.net Mon Aug 2 19:42:58 2004 From: andrei at ripe.net (Andrei Robachevsky) Date: Mon, 02 Aug 2004 19:42:58 +0200 Subject: [ipv6-wg@ripe.net] IPv6 access to K-root Message-ID: <410E7D22.70904@ripe.net> 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 From iljitsch at muada.com Mon Aug 2 20:23:27 2004 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 2 Aug 2004 20:23:27 +0200 Subject: [ipv6-wg@ripe.net] IPv6 access to K-root In-Reply-To: <410E7D22.70904@ripe.net> References: <410E7D22.70904@ripe.net> Message-ID: <0C757F5E-E4B1-11D8-805E-000A95CD987A@muada.com> On 2-aug-04, at 19:42, Andrei Robachevsky wrote: > K-root server has now IPv6 transport enabled. That's nice, but the first thing any DNS server does on startup is: > host -t ns -v . 2001:7fd::1 Using domain server 2001:7fd::1: rcode = 0 (Success), ancount=13 The following answer is not verified as authentic by the server: . 518400 IN NS a.root-servers.net . 518400 IN NS h.root-servers.net . 518400 IN NS c.root-servers.net . 518400 IN NS g.root-servers.net . 518400 IN NS f.root-servers.net . 518400 IN NS b.root-servers.net . 518400 IN NS j.root-servers.net . 518400 IN NS k.root-servers.net . 518400 IN NS l.root-servers.net . 518400 IN NS m.root-servers.net . 518400 IN NS i.root-servers.net . 518400 IN NS e.root-servers.net . 518400 IN NS d.root-servers.net Additional information: a.root-servers.net 3600000 IN A 198.41.0.4 h.root-servers.net 3600000 IN A 128.63.2.53 c.root-servers.net 3600000 IN A 192.33.4.12 g.root-servers.net 3600000 IN A 192.112.36.4 f.root-servers.net 3600000 IN A 192.5.5.241 b.root-servers.net 3600000 IN A 192.228.79.201 j.root-servers.net 3600000 IN A 192.58.128.30 k.root-servers.net 3600000 IN A 193.0.14.129 l.root-servers.net 3600000 IN A 198.32.64.12 m.root-servers.net 3600000 IN A 202.12.27.33 i.root-servers.net 3600000 IN A 192.36.148.17 e.root-servers.net 3600000 IN A 192.203.230.10 d.root-servers.net 3600000 IN A 128.8.10.90 ...and then we're back in v4 land again. From andrius at andrius.org Mon Aug 2 20:33:49 2004 From: andrius at andrius.org (Andrius Kazimieras =?utf-8?Q?Kasparavi=C4=8Dius?=) Date: Mon, 2 Aug 2004 21:33:49 +0300 Subject: [ipv6-wg@ripe.net] IPv6 access to K-root In-Reply-To: <0C757F5E-E4B1-11D8-805E-000A95CD987A@muada.com> References: <410E7D22.70904@ripe.net> <0C757F5E-E4B1-11D8-805E-000A95CD987A@muada.com> Message-ID: <20040802183349.GA13599@diedas.soften.ktu.lt> it was discussed already, that it depends not on RIR, but on ICANN. When these guys will finish tests&checks, we will get that game to our painful collection. AKK * Iljitsch van Beijnum [2004-08-02 21:24]: > On 2-aug-04, at 19:42, Andrei Robachevsky wrote: > > >K-root server has now IPv6 transport enabled. > > That's nice, but the first thing any DNS server does on startup is: > > > host -t ns -v . 2001:7fd::1 > Using domain server 2001:7fd::1: > > rcode = 0 (Success), ancount=13 > The following answer is not verified as authentic by the server: > . 518400 IN NS a.root-servers.net > . 518400 IN NS h.root-servers.net > . 518400 IN NS c.root-servers.net > . 518400 IN NS g.root-servers.net > . 518400 IN NS f.root-servers.net > . 518400 IN NS b.root-servers.net > . 518400 IN NS j.root-servers.net > . 518400 IN NS k.root-servers.net > . 518400 IN NS l.root-servers.net > . 518400 IN NS m.root-servers.net > . 518400 IN NS i.root-servers.net > . 518400 IN NS e.root-servers.net > . 518400 IN NS d.root-servers.net > Additional information: > a.root-servers.net 3600000 IN A 198.41.0.4 > h.root-servers.net 3600000 IN A 128.63.2.53 > c.root-servers.net 3600000 IN A 192.33.4.12 > g.root-servers.net 3600000 IN A 192.112.36.4 > f.root-servers.net 3600000 IN A 192.5.5.241 > b.root-servers.net 3600000 IN A 192.228.79.201 > j.root-servers.net 3600000 IN A 192.58.128.30 > k.root-servers.net 3600000 IN A 193.0.14.129 > l.root-servers.net 3600000 IN A 198.32.64.12 > m.root-servers.net 3600000 IN A 202.12.27.33 > i.root-servers.net 3600000 IN A 192.36.148.17 > e.root-servers.net 3600000 IN A 192.203.230.10 > d.root-servers.net 3600000 IN A 128.8.10.90 > > ...and then we're back in v4 land again. From jon at lawrence.org.uk Mon Aug 2 21:50:46 2004 From: jon at lawrence.org.uk (Jon Lawrence) Date: Mon, 2 Aug 2004 20:50:46 +0100 Subject: [ipv6-wg@ripe.net] IPv6 access to K-root In-Reply-To: <20040802183349.GA13599@diedas.soften.ktu.lt> References: <410E7D22.70904@ripe.net> <0C757F5E-E4B1-11D8-805E-000A95CD987A@muada.com> <20040802183349.GA13599@diedas.soften.ktu.lt> Message-ID: <200408022050.46864.jon@lawrence.org.uk> On Monday 02 August 2004 19:33, Andrius Kazimieras Kasparavi?ius wrote: > it was discussed already, that it depends not on RIR, but on ICANN. When > these guys will finish tests&checks, we will get that game to our painful > collection. > > AKK > > * Iljitsch van Beijnum [2004-08-02 21:24]: > > On 2-aug-04, at 19:42, Andrei Robachevsky wrote: > > >K-root server has now IPv6 transport enabled. > > > > > > ...and then we're back in v4 land again. and I suppose the question is when are ICANN actually going to get around to it. They seem to have waited long enough to add some ccTLD AAAA records, but to me that seems kind of pointless without the root containing AAAA's. Jon From iljitsch at muada.com Mon Aug 2 22:19:42 2004 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 2 Aug 2004 22:19:42 +0200 Subject: [ipv6-wg@ripe.net] IPv6 access to K-root In-Reply-To: <200408022050.46864.jon@lawrence.org.uk> References: <410E7D22.70904@ripe.net> <0C757F5E-E4B1-11D8-805E-000A95CD987A@muada.com> <20040802183349.GA13599@diedas.soften.ktu.lt> <200408022050.46864.jon@lawrence.org.uk> Message-ID: <4A02B5A5-E4C1-11D8-805E-000A95CD987A@muada.com> On 2-aug-04, at 21:50, Jon Lawrence wrote: >> it was discussed already, that it depends not on RIR, but on ICANN. >> When >> these guys will finish tests&checks, we will get that game to our >> painful >> collection. > and I suppose the question is when are ICANN actually going to get > around to > it. They seem to have waited long enough to add some ccTLD AAAA > records, but to me that seems kind of pointless without the root > containing AAAA's. I'm not so much concerned about how long this step took for exactly the reason you mention: there is little advantage in having TLD AAAA glue records (you say ccTLDs, what about the gTLDs then??) without the same for the root itself. What I _am_ worried about is the way they presented this fairly small step as a huge deal. As I wrote on my website: "One small step for mankind... but a huge step for ICANN." (With the announcement pretty much on the 35th anniversary of the moon landing and all.) -- Iljitsch van Beijnum - http://www.bgpexpert.com/ (updated: Jul 22, 1:28:10) From andrei at ripe.net Tue Aug 3 06:06:55 2004 From: andrei at ripe.net (Andrei Robachevsky) Date: Tue, 03 Aug 2004 06:06:55 +0200 Subject: [ipv6-wg@ripe.net] IPv6 access to K-root In-Reply-To: <20040803032147.GA40146@kb.pinguino.dk> References: <410E7D22.70904@ripe.net> <20040803032147.GA40146@kb.pinguino.dk> Message-ID: <410F0F5F.40503@ripe.net> Hi Robert, Robert Martin-Leg?ne wrote: [...] > And.. do you consider to get this into the root-servers.net zone itself? > I suppose it would then actually get picked up as a glue and upset > conservative parties? (but it might make the root v6-reachable - except > at bootstrap). > Definitely. And not only in the root-servers.net but also in the hints file and in the root zone itself. And not only for K, but for all other root servers that have IPv6 transport enabled. But as we know it's more complex than just updating relevant files. This requires careful consideration of possible technical issues, so that RSSAC can provide clear recommendations to IANA. As far as I know this work in underway. > And finally, why is it that k.root-servers.net and k.root-servers.org > has different IPv4-addresses? > The first one is the server itself, the second is the website containing information about K. > -- Robert Martin-Legene > DK Hostmaster Regards, Andrei -- Andrei Robachevsky RIPE NCC From robert at dk-hostmaster.dk Tue Aug 3 05:21:48 2004 From: robert at dk-hostmaster.dk (Robert =?iso-8859-1?Q?Martin-Leg=E8ne?=) Date: Tue, 3 Aug 2004 05:21:48 +0200 Subject: [ipv6-wg@ripe.net] IPv6 access to K-root In-Reply-To: <410E7D22.70904@ripe.net> References: <410E7D22.70904@ripe.net> Message-ID: <20040803032147.GA40146@kb.pinguino.dk> On Mon, Aug 02, 2004 at 07:42:58PM +0200, Andrei Robachevsky wrote: > k.root-servers.net. AAAA 2001:7fd::1 > A 193.0.14.129 Hi Andrei. This is good news. Just out of curiousity.. what is at 2001:7fd::0 ? ^ And.. do you consider to get this into the root-servers.net zone itself? I suppose it would then actually get picked up as a glue and upset conservative parties? (but it might make the root v6-reachable - except at bootstrap). And finally, why is it that k.root-servers.net and k.root-servers.org has different IPv4-addresses? -- Robert Martin-Legene DK Hostmaster From pim at ipng.nl Tue Aug 3 09:00:31 2004 From: pim at ipng.nl (Pim van Pelt) Date: Tue, 3 Aug 2004 09:00:31 +0200 Subject: [ipv6-wg@ripe.net] IPv6 access to K-root In-Reply-To: <20040803032147.GA40146@kb.pinguino.dk> References: <410E7D22.70904@ripe.net> <20040803032147.GA40146@kb.pinguino.dk> Message-ID: <20040803070031.GA19672@bfib.colo.bit.nl> Hi, | Just out of curiousity.. what is at 2001:7fd::0 ? It's most probably a router anycast, which is the lowest possible IPv6 address in a given segment. I've forgotten the document that specifies this, but afaik most operating systems today use it when forwarding is turned on. -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim at ipng.nl http://www.ipng.nl/ IPv6 Deployment ----------------------------------------------- From iljitsch at muada.com Tue Aug 3 11:28:05 2004 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 3 Aug 2004 11:28:05 +0200 Subject: [ipv6-wg@ripe.net] IPv6 access to K-root In-Reply-To: <20040803070031.GA19672@bfib.colo.bit.nl> References: <410E7D22.70904@ripe.net> <20040803032147.GA40146@kb.pinguino.dk> <20040803070031.GA19672@bfib.colo.bit.nl> Message-ID: <6C6BEF3E-E52F-11D8-805E-000A95CD987A@muada.com> On 3-aug-04, at 9:00, Pim van Pelt wrote: > | Just out of curiousity.. what is at 2001:7fd::0 ? > It's most probably a router anycast, which is the lowest possible IPv6 > address in a given segment. I've forgotten the document that specifies > this, RFC 3513 section 2.6.1. > but afaik most operating systems today use it when forwarding is > turned on. But Real Routers (tm) don't. :-) From dr at cluenet.de Wed Aug 4 20:30:53 2004 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 4 Aug 2004 20:30:53 +0200 Subject: [ipv6-wg@ripe.net] inet6num missing for allocation - more? Message-ID: <20040804203053.B3676@homebase.cluenet.de> Hi, I've just noticed, that the allocation 2001:478::/32 is not registered in the RIPE DB: $ whois -h whois.ripe.net -r 2001:478::/32 | fgrep inet6num: inet6num: 0::/0 Could RIPE check wether this problem does exist for other allocations too? Or is EP.NET "special"? :-) Best regards, Daniel From leo at ripe.net Wed Aug 4 20:40:16 2004 From: leo at ripe.net (leo vegoda) Date: Wed, 4 Aug 2004 20:40:16 +0200 Subject: [ipv6-wg@ripe.net] inet6num missing for allocation - more? In-Reply-To: <20040804203053.B3676@homebase.cluenet.de> References: <20040804203053.B3676@homebase.cluenet.de> Message-ID: Hi Daniel, On Aug 4, 2004, at 8:30 pm, Daniel Roesen wrote: > I've just noticed, that the allocation 2001:478::/32 is not registered > in the RIPE DB: > > $ whois -h whois.ripe.net -r 2001:478::/32 | fgrep inet6num: > inet6num: 0::/0 > > Could RIPE check wether this problem does exist for other allocations > too? Or is EP.NET "special"? :-) This /32 appears to come from 2001:0400::/23 which is allocated to ARIN. You can query the ARIN database directly to see contact information for EP.NET. However, you can also find basic contact information (and the fact that the block is allocated) by querying the RIPE database using the -a flag: $ whois -h whois.ripe.net -a 2001:478::/32 This gives you information from all the databases mirrored by whois.ripe.net. Kind regards, -- leo vegoda Registration Services Manager RIPE NCC From dr at cluenet.de Wed Aug 4 20:53:56 2004 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 4 Aug 2004 20:53:56 +0200 Subject: [ipv6-wg@ripe.net] inet6num missing for allocation - more? In-Reply-To: ; from leo@ripe.net on Wed, Aug 04, 2004 at 08:40:16PM +0200 References: <20040804203053.B3676@homebase.cluenet.de> Message-ID: <20040804205356.C3676@homebase.cluenet.de> On Wed, Aug 04, 2004 at 08:40:16PM +0200, leo vegoda wrote: > This /32 appears to come from 2001:0400::/23 which is allocated to ARIN. Indeed, I'm wearing the brown paper bag on my head. > You can query the ARIN database directly to see contact information for > EP.NET. However, you can also find basic contact information (and the > fact that the block is allocated) by querying the RIPE database using > the -a flag: > > $ whois -h whois.ripe.net -a 2001:478::/32 Hm, shouldn't there be a inet6nums as placeholder for the ARIN ranges? Like in v4 world? This is why I didn't notice the ARIN ownership in the first place... Thanks for your quick response... I just wanted to write a reply to myself. :-/ Best regards, Daniel From woeber at cc.univie.ac.at Wed Aug 4 20:43:21 2004 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 04 Aug 2004 20:43:21 +0200 Subject: [ipv6-wg@ripe.net] inet6num missing for allocation - more? Message-ID: <00A35DEC.25267BC8.13@cc.univie.ac.at> >I've just noticed, that the allocation 2001:478::/32 is not registered >in the RIPE DB: But it is in ARIN's: > warin 2001:478:: OrgName: EP.NET, LLC. OrgID: V6EP Address: PO 12317 City: Marina del Rey StateProv: CA PostalCode: 90295 Country: US NetRange: 2001:0478:0000:0000:0000:0000:0000:0000 - 2001:0478:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF CIDR: 2001:0478:0000:0000:0000:0000:0000:0000/32 NetName: EP-NET NetHandle: EP-NET-NET Parent: ARIN-001-NET NetType: Direct Allocation NameServer: FLAG.EP.NET NameServer: Z.IP6.INT Comment: RegDate: 2001-05-21 Updated: 2002-08-05 TechHandle: WM110-ARIN TechName: Manning, Bill TechPhone: +1-310-322-8102 TechEmail: bmanning at karoshi.com > ... Or is EP.NET "special"? :-) Who knows :-) >Best regards, >Daniel Wilfried ( https://cert.aco.net/ ) _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber at CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From leo at ripe.net Mon Aug 9 17:38:03 2004 From: leo at ripe.net (leo vegoda) Date: Mon, 9 Aug 2004 17:38:03 +0200 Subject: [ipv6-wg@ripe.net] Policy for allocation of IPv6 address space from IANA to RIRs Message-ID: <1A38A7AC-EA1A-11D8-9320-000A95DAB530@ripe.net> Dear Colleagues, The Number Resource Organisation (NRO) has published a proposal for a policy for the allocation of IPv6 address space from the IANA to the RIRs. It is intended that this proposed policy should be agreed by all RIRs' open policy fora and then approved by the ASO and ICANN as a global policy. The proposal is available on our web site at: http://www.ripe.net/ripe/draft-documents/ipv6.html Comment on the proposal is sought. Kind regards, -- leo vegoda Registration Services Manager RIPE NCC From pekkas at netcore.fi Tue Aug 10 08:15:14 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 10 Aug 2004 09:15:14 +0300 (EEST) Subject: [ipv6-wg@ripe.net] Re: [address-policy-wg] Policy for allocation of IPv6 address space from IANA to RIRs In-Reply-To: <1A38A7AC-EA1A-11D8-9320-000A95DAB530@ripe.net> Message-ID: On Mon, 9 Aug 2004, leo vegoda wrote: > Dear Colleagues, > > The Number Resource Organisation (NRO) has published a proposal for a > policy for the allocation of IPv6 address space from the IANA to the > RIRs. It is intended that this proposed policy should be agreed by all > RIRs' open policy fora and then approved by the ASO and ICANN as a > global policy. > > The proposal is available on our web site at: > > http://www.ripe.net/ripe/draft-documents/ipv6.html Seems like a good idea. We need to get rid of those ridiculous /23 allocations. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From randy at psg.com Mon Aug 9 19:42:50 2004 From: randy at psg.com (Randy Bush) Date: Mon, 9 Aug 2004 07:42:50 -1000 Subject: [ipv6-wg@ripe.net] Re: [address-policy-wg] Policy for allocation of IPv6 address space from IANA to RIRs References: <1A38A7AC-EA1A-11D8-9320-000A95DAB530@ripe.net> Message-ID: <16663.47002.612344.889512@roam.psg.com> leo, can you explain why the rirs need a time window from the iana (36 months) so much larger than lirs need from the rirs? randy From iljitsch at muada.com Tue Aug 10 09:32:58 2004 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 10 Aug 2004 09:32:58 +0200 Subject: [ipv6-wg@ripe.net] Policy for allocation of IPv6 address space from IANA to RIRs In-Reply-To: <1A38A7AC-EA1A-11D8-9320-000A95DAB530@ripe.net> References: <1A38A7AC-EA1A-11D8-9320-000A95DAB530@ripe.net> Message-ID: <80B37028-EA9F-11D8-9A02-000A95CD987A@muada.com> On 9-aug-04, at 17:38, leo vegoda wrote: > The Number Resource Organisation (NRO) has published a proposal for a > policy for the allocation of IPv6 address space from the IANA to the > RIRs. It is intended that this proposed policy should be agreed by all > RIRs' open policy fora and then approved by the ASO and ICANN as a > global policy. Reserving a /6 for each RIR seems like the other extreme to me. In IPv4 we have around 220 /8s that have been given out to RIRs pretty much one at a time in the past. In IPv6 we effectively have 8 /6s. This means that as a percentage of total available space, the RIRs get more than 25 times more IPv6 space than they've been given IPv4 space in the past, even though a v4 /8 will accommodate at most 16.8M end-user assignments (less in practice) while a v6 /6 allows for AT LEAST 4.4T (yes, that's 10^12) end-user assignments. Now I can see SOME value in trying to have relatively large RIR blocks, but cutting up all non-reserved space so aggressively really doesn't have any upsides, and we never know whether we're going to need any really large blocks in the future. Also, doubling every time is ok for a while, but it pretty much guarantees that you're going to have way too much space on your hands at some point. A more reasonable policy would be: - reserve a /12 for each RIR now (a 4 bit boundary makes DNS delegations easier, I think a /8 is too much but that might work also) - then, for every delegation, give RIRs enough space to each to last a year comfortably - evaluate whether a new delegation is needed every 3 or 4 months, making the time of new delegations easy to predict From gert at space.net Tue Aug 10 09:55:04 2004 From: gert at space.net (Gert Doering) Date: Tue, 10 Aug 2004 09:55:04 +0200 Subject: [ipv6-wg@ripe.net] Policy for allocation of IPv6 address space from IANA to RIRs In-Reply-To: <80B37028-EA9F-11D8-9A02-000A95CD987A@muada.com> References: <1A38A7AC-EA1A-11D8-9320-000A95DAB530@ripe.net> <80B37028-EA9F-11D8-9A02-000A95CD987A@muada.com> Message-ID: <20040810075504.GU467@Space.Net> Hi, On Tue, Aug 10, 2004 at 09:32:58AM +0200, Iljitsch van Beijnum wrote: > Now I can see SOME value in trying to have relatively large RIR blocks, > but cutting up all non-reserved space so aggressively really doesn't > have any upsides, The *big* upside is that you can apply reasonable address distribution algorithms *inside* the RIR blocks, effectively avoiding having to give LIRs two or more allocations if they are growing slowly over time. [..] > - reserve a /12 for each RIR now (a 4 bit boundary makes DNS > delegations easier, I think a /8 is too much but that might work also) > - then, for every delegation, give RIRs enough space to each to last a > year comfortably > - evaluate whether a new delegation is needed every 3 or 4 months, > making the time of new delegations easy to predict Please don't introduce additional RIR<->ICANN loops that don't serve ANY benefits except pay bureaucrats. If you want to go with /12s, hand out the /12 per RIR *now*. Fully, without any "reservation". /8s would be better. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 65398 (60210) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From gert at space.net Tue Aug 10 10:16:25 2004 From: gert at space.net (Gert Doering) Date: Tue, 10 Aug 2004 10:16:25 +0200 Subject: [ipv6-wg@ripe.net] Policy for allocation of IPv6 address space from IANA to RIRs In-Reply-To: <1A38A7AC-EA1A-11D8-9320-000A95DAB530@ripe.net> References: <1A38A7AC-EA1A-11D8-9320-000A95DAB530@ripe.net> Message-ID: <20040810081625.GV467@Space.Net> Hi, On Mon, Aug 09, 2004 at 05:38:03PM +0200, leo vegoda wrote: > http://www.ripe.net/ripe/draft-documents/ipv6.html Very reasonable draft. - starting with a /12 is "big enough" for the near future (there are a couple of /20 allocation requests in the pipeline, but a /12 can fulfill 128 of them before reaching 50%) - adding individual bits, growing into the /6, ensures that the stuff stays aggregateable-by-region - *if* it should become obvious that a couple of special-case-blocks are required in the future (like 6to4's 2002::/16), this can be taken out of 2000::/6 or 3800::/5. - *if* a new RIR pops up in the not-so-far future, it might become necessary to split up the /6s into /7s or /8s, but this will not do any harm (after all: this is only *reserved*, and filled from the bottom - so until the first RIR fills up a /7, the second half of all /6s will still be completely untouched). Personally, I would tend to start with /8s (instead of /12s), but I know that this is way too radical for the conservative minds out there. Based on that, a /12 is a reasonable compromise. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 65398 (60210) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From pim at ipng.nl Tue Aug 10 11:26:57 2004 From: pim at ipng.nl (Pim van Pelt) Date: Tue, 10 Aug 2004 11:26:57 +0200 Subject: [ipv6-wg@ripe.net] Policy for allocation of IPv6 address space from IANA to RIRs In-Reply-To: <20040810081625.GV467@Space.Net> References: <1A38A7AC-EA1A-11D8-9320-000A95DAB530@ripe.net> <20040810081625.GV467@Space.Net> Message-ID: <20040810092657.GA22124@bfib.ipng.nl> On Tue, Aug 10, 2004 at 10:16:25AM +0200, Gert Doering wrote: | Hi, | | On Mon, Aug 09, 2004 at 05:38:03PM +0200, leo vegoda wrote: | > http://www.ripe.net/ripe/draft-documents/ipv6.html | | Very reasonable draft. I agree. I have two questions though; 1. Are there no expectations on having more RIRs in the lifespan of the 001 segment of IPv6 space ? ie, will we run out of reserved blocks ? I am very worried we may indeed run out. 2. What's the purpose of "various". Please give some detail about what can and can not fit into this /6. I think that reserving /8s is better than /6s. The DNS issue is one thing, the scalability question in (1) is another. A /8 should be enough for a RIR in the midterm future, if a RIR explodes (IP space wise) they can always be plugged into another /8 in the future. I think this will be a more stable situation than scaling down from /6s to /7s (as Gert suggested). -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim at ipng.nl http://www.ipng.nl/ IPv6 Deployment ----------------------------------------------- From gert at space.net Tue Aug 10 11:31:28 2004 From: gert at space.net (Gert Doering) Date: Tue, 10 Aug 2004 11:31:28 +0200 Subject: [ipv6-wg@ripe.net] Policy for allocation of IPv6 address space from IANA to RIRs In-Reply-To: <20040810092657.GA22124@bfib.ipng.nl> References: <1A38A7AC-EA1A-11D8-9320-000A95DAB530@ripe.net> <20040810081625.GV467@Space.Net> <20040810092657.GA22124@bfib.ipng.nl> Message-ID: <20040810093128.GF467@Space.Net> Hi, On Tue, Aug 10, 2004 at 11:26:57AM +0200, Pim van Pelt wrote: > I think that reserving /8s is better than /6s. The DNS issue is one > thing, the scalability question in (1) is another. A /8 should be enough > for a RIR in the midterm future, if a RIR explodes (IP space wise) they > can always be plugged into another /8 in the future. I think this will > be a more stable situation than scaling down from /6s to /7s (as Gert > suggested). However you label it (/8s that can grow into a /6, or /6s that can be shrunk into /7s, if needed) doesn't make a real difference. The important thing about the "/6 approach" is that the initial /12s (growing to /8s) are allocated with so much room in between that you *can* grow to a /7 or /6, if necessary, and don't have to start a second (or even more) block per RIR. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 65398 (60210) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From iljitsch at muada.com Tue Aug 10 12:03:08 2004 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 10 Aug 2004 12:03:08 +0200 Subject: [ipv6-wg@ripe.net] Policy for allocation of IPv6 address space from IANA to RIRs In-Reply-To: <20040810093128.GF467@Space.Net> References: <1A38A7AC-EA1A-11D8-9320-000A95DAB530@ripe.net> <20040810081625.GV467@Space.Net> <20040810092657.GA22124@bfib.ipng.nl> <20040810093128.GF467@Space.Net> Message-ID: <7AAC81D8-EAB4-11D8-9A02-000A95CD987A@muada.com> On 10-aug-04, at 11:31, Gert Doering wrote: > The important thing about the "/6 approach" is that the initial /12s > (growing to /8s) are allocated with so much room in between that you > *can* grow to a /7 or /6, if necessary, and don't have to start a > second (or even more) block per RIR. Why is that important? From gert at space.net Tue Aug 10 13:19:51 2004 From: gert at space.net (Gert Doering) Date: Tue, 10 Aug 2004 13:19:51 +0200 Subject: [ipv6-wg@ripe.net] Policy for allocation of IPv6 address space from IANA to RIRs In-Reply-To: <7AAC81D8-EAB4-11D8-9A02-000A95CD987A@muada.com> References: <1A38A7AC-EA1A-11D8-9320-000A95DAB530@ripe.net> <20040810081625.GV467@Space.Net> <20040810092657.GA22124@bfib.ipng.nl> <20040810093128.GF467@Space.Net> <7AAC81D8-EAB4-11D8-9A02-000A95CD987A@muada.com> Message-ID: <20040810111951.GH467@Space.Net> Hi, On Tue, Aug 10, 2004 at 12:03:08PM +0200, Iljitsch van Beijnum wrote: > On 10-aug-04, at 11:31, Gert Doering wrote: > > >The important thing about the "/6 approach" is that the initial /12s > >(growing to /8s) are allocated with so much room in between that you > >*can* grow to a /7 or /6, if necessary, and don't have to start a > >second (or even more) block per RIR. > > Why is that important? Because you want to avoid fragmentation. Please read up the RIPE-161 thread in the mailing list archives. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 65398 (60210) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From iljitsch at muada.com Tue Aug 10 13:48:12 2004 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 10 Aug 2004 13:48:12 +0200 Subject: [ipv6-wg@ripe.net] Policy for allocation of IPv6 address space from IANA to RIRs In-Reply-To: <20040810111951.GH467@Space.Net> References: <1A38A7AC-EA1A-11D8-9320-000A95DAB530@ripe.net> <20040810081625.GV467@Space.Net> <20040810092657.GA22124@bfib.ipng.nl> <20040810093128.GF467@Space.Net> <7AAC81D8-EAB4-11D8-9A02-000A95CD987A@muada.com> <20040810111951.GH467@Space.Net> Message-ID: <285FBBD9-EAC3-11D8-B7FC-000A95CD987A@muada.com> On 10-aug-04, at 13:19, Gert Doering wrote: >> Why is that important? > Because you want to avoid fragmentation. Please read up the RIPE-161 > thread in the mailing list archives. There is this new thing now. It's called hypertext. It's really cool. (In other words: please supply a link, as this is impossible to find.) From chbm at cprm.net Tue Aug 10 14:17:33 2004 From: chbm at cprm.net (Carlos Morgado) Date: Tue, 10 Aug 2004 13:17:33 +0100 Subject: [address-policy-wg] Re: [ipv6-wg@ripe.net] Policy for allocation of IPv6 address space from IANA to RIRs In-Reply-To: <285FBBD9-EAC3-11D8-B7FC-000A95CD987A@muada.com> References: <1A38A7AC-EA1A-11D8-9320-000A95DAB530@ripe.net> <20040810081625.GV467@Space.Net> <20040810092657.GA22124@bfib.ipng.nl> <20040810093128.GF467@Space.Net> <7AAC81D8-EAB4-11D8-9A02-000A95CD987A@muada.com> <20040810111951.GH467@Space.Net> <285FBBD9-EAC3-11D8-B7FC-000A95CD987A@muada.com> Message-ID: <20040810121733.GA8581@cprm.net> On Tue, Aug 10, 2004 at 01:48:12PM +0200, Iljitsch van Beijnum wrote: > On 10-aug-04, at 13:19, Gert Doering wrote: > > >>Why is that important? > > >Because you want to avoid fragmentation. Please read up the RIPE-161 > >thread in the mailing list archives. > > There is this new thing now. It's called hypertext. It's really cool. > > (In other words: please supply a link, as this is impossible to find.) There is this new thing now. It's called Google. It's really cool. -- Carlos Morgado - Internet Engineering - Phone +351 214146594 GPG key: 0x75E451E2 FP: B98B 222B F276 18C0 266B 599D 93A1 A3FB 75E4 51E2 The views expressed above do not bind my employer. From iljitsch at muada.com Tue Aug 10 15:22:31 2004 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 10 Aug 2004 15:22:31 +0200 Subject: [address-policy-wg] Re: [ipv6-wg@ripe.net] Policy for allocation of IPv6 address space from IANA to RIRs In-Reply-To: <20040810121733.GA8581@cprm.net> References: <1A38A7AC-EA1A-11D8-9320-000A95DAB530@ripe.net> <20040810081625.GV467@Space.Net> <20040810092657.GA22124@bfib.ipng.nl> <20040810093128.GF467@Space.Net> <7AAC81D8-EAB4-11D8-9A02-000A95CD987A@muada.com> <20040810111951.GH467@Space.Net> <285FBBD9-EAC3-11D8-B7FC-000A95CD987A@muada.com> <20040810121733.GA8581@cprm.net> Message-ID: <553C01C8-EAD0-11D8-A17C-000A95CD987A@muada.com> On 10-aug-04, at 14:17, Carlos Morgado wrote: >> (In other words: please supply a link, as this is impossible to find.) > There is this new thing now. It's called Google. It's really cool. You know what? Don't bother with a link. I'm not wasting my time on old discussions. If you have something to say, say it. Don't say you've said it before, I don't care. From axel.pawlik at ripe.net Tue Aug 10 15:22:51 2004 From: axel.pawlik at ripe.net (Axel Pawlik) Date: Tue, 10 Aug 2004 15:22:51 +0200 Subject: [address-policy-wg] Re: [ipv6-wg@ripe.net] Policy for allocation of IPv6 address space from IANA to RIRs In-Reply-To: <285FBBD9-EAC3-11D8-B7FC-000A95CD987A@muada.com> References: <1A38A7AC-EA1A-11D8-9320-000A95DAB530@ripe.net> <20040810081625.GV467@Space.Net> <20040810092657.GA22124@bfib.ipng.nl> <20040810093128.GF467@Space.Net> <7AAC81D8-EAB4-11D8-9A02-000A95CD987A@muada.com> <20040810111951.GH467@Space.Net> <285FBBD9-EAC3-11D8-B7FC-000A95CD987A@muada.com> Message-ID: <6.1.1.1.2.20040810152049.03500ec0@localhost> At 10/08/2004 13:48, Iljitsch van Beijnum wrote: >On 10-aug-04, at 13:19, Gert Doering wrote: > >>>Why is that important? > >>Because you want to avoid fragmentation. Please read up the RIPE-161 >>thread in the mailing list archives. > >There is this new thing now. It's called hypertext. It's really cool. > >(In other words: please supply a link, as this is impossible to find.) It is ripe-261, actually, see http://www.ripe.net/ripe/docs/ipv6-sparse.html. You can find the indes to the RIPE documents store at http://www.ripe.net/ripe/docs/ipv6-sparse.html. cheers, Axel From kurtis at kurtis.pp.se Tue Aug 10 15:40:48 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Tue, 10 Aug 2004 15:40:48 +0200 Subject: [ipv6-wg@ripe.net] Policy for allocation of IPv6 address space from IANA to RIRs In-Reply-To: <20040810081625.GV467@Space.Net> References: <1A38A7AC-EA1A-11D8-9320-000A95DAB530@ripe.net> <20040810081625.GV467@Space.Net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > On Mon, Aug 09, 2004 at 05:38:03PM +0200, leo vegoda wrote: >> http://www.ripe.net/ripe/draft-documents/ipv6.html > > Very reasonable draft. > > - starting with a /12 is "big enough" for the near future (there are > a couple of /20 allocation requests in the pipeline, but a /12 can > fulfill 128 of them before reaching 50%) > > - adding individual bits, growing into the /6, ensures that the stuff > stays aggregateable-by-region Agree. And this also more or less reflects the discussions we have had at least in the RIPE region. > Personally, I would tend to start with /8s (instead of /12s), but I > know > that this is way too radical for the conservative minds out there. > Based > on that, a /12 is a reasonable compromise. I don't think that starting with /8s would give much more benefit. What is not needed is strict and good assignment algorithms inside the RIRs. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQRjQZKarNKXTPFCVEQLx3ACeLTE839wgtEVLeTcpe66mTDUTx/wAn1ym upsVmawRGsPvRgQTHNQ5Myd/ =DG57 -----END PGP SIGNATURE----- From axel.pawlik at ripe.net Tue Aug 10 15:46:24 2004 From: axel.pawlik at ripe.net (Axel Pawlik) Date: Tue, 10 Aug 2004 15:46:24 +0200 Subject: [address-policy-wg] Re: [ipv6-wg@ripe.net] Policy for allocation of IPv6 address space from IANA to RIRs In-Reply-To: <6.1.1.1.2.20040810152049.03500ec0@localhost> References: <1A38A7AC-EA1A-11D8-9320-000A95DAB530@ripe.net> <20040810081625.GV467@Space.Net> <20040810092657.GA22124@bfib.ipng.nl> <20040810093128.GF467@Space.Net> <7AAC81D8-EAB4-11D8-9A02-000A95CD987A@muada.com> <20040810111951.GH467@Space.Net> <285FBBD9-EAC3-11D8-B7FC-000A95CD987A@muada.com> <6.1.1.1.2.20040810152049.03500ec0@localhost> Message-ID: <6.1.1.1.2.20040810154558.03753640@localhost> At 10/08/2004 15:22, Axel Pawlik wrote: >You can find the indes to the RIPE documents store at >http://www.ripe.net/ripe/docs/ipv6-sparse.html. Make that http://www.ripe.net/ripe/docs/index.html. Axel From dr at cluenet.de Wed Aug 11 10:29:02 2004 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 11 Aug 2004 10:29:02 +0200 Subject: [ipv6-wg@ripe.net] Re: [address-policy-wg] Policy for allocation of IPv6 address space from IANA to RIRs In-Reply-To: <200408110904.21749.jon@lawrence.org.uk>; from jon@lawrence.org.uk on Wed, Aug 11, 2004 at 09:04:21AM +0100 References: <1A38A7AC-EA1A-11D8-9320-000A95DAB530@ripe.net> <200408092246.24273.jon@lawrence.org.uk> <16665.23720.926036.641285@roam.psg.com> <200408110904.21749.jon@lawrence.org.uk> Message-ID: <20040811102902.A18246@homebase.cluenet.de> On Wed, Aug 11, 2004 at 09:04:21AM +0100, Jon Lawrence wrote: > Yes, doubling does seem unwise. > It would make sense (to me anyway) that once xx% of a /12 is allocated then > another /12 is issued to the RIR. Indeed. I see no point in unconditional doubling. I'm pretty confident that /12 blocks are large enough to serve a RIR long enough so that ordering a new /12 is not hampering anything. My suggestion would be to set aside a /8 per RIR (perhaps also a DNS reverse delegation for that) and allocate /12s to the RIRs upon their request. A RIR qualifies for a new /12 block as soon as nn% usage of the current /12 block is reached. nn might be 50% or more. As Randy suggests, the percentage should be low enough so that the RIRs can get new space without delaying allocation to LIRs (as it happens nowadays). Best regards, Daniel From rogerj at jorgensen.no Wed Aug 11 16:38:24 2004 From: rogerj at jorgensen.no (Roger Jorgensen) Date: Wed, 11 Aug 2004 16:38:24 +0200 (CEST) Subject: [ipv6-wg@ripe.net] Re: [address-policy-wg] Policy for allocation of IPv6 address space from IANA to RIRs In-Reply-To: <20040811102902.A18246@homebase.cluenet.de> References: <1A38A7AC-EA1A-11D8-9320-000A95DAB530@ripe.net> <200408092246.24273.jon@lawrence.org.uk> <16665.23720.926036.641285@roam.psg.com> <200408110904.21749.jon@lawrence.org.uk> <20040811102902.A18246@homebase.cluenet.de> Message-ID: The issue isn't about allocating a bigger netblock to the RIRs or not, the issue are more how big it should be. Anything bigger than /8 is shooting ourself in the foot and limiting our options when we in 10-20years figure out a much better way to use the address space. Even /12 is overkill but it will last for a while and we don't get more fragmentation of the IPv6 space than we have today with those ridiculous /23 allocation. Allocate maximum one /8 for each RIR and give them a /12 _now_, not in 1 years time! Just stop those /23 allocation... I'm still quite Junior and young compared to most of you, and I have no interest in getting into trouble with IPv6 in some years (20+) similar to what there are today with IPv4 due to we thought we could waste _too_ much of the address space:) ...Not to mention the trouble we for sure will have with regards to how to solve one of the unsolved "problems", multihoming.... just my 2 Euro cents:) (that we in 20+ years will face a situation where IPv6 most likely aren't usable, that's a total different story) On Wed, 11 Aug 2004, Daniel Roesen wrote: > On Wed, Aug 11, 2004 at 09:04:21AM +0100, Jon Lawrence wrote: > > Yes, doubling does seem unwise. > > It would make sense (to me anyway) that once xx% of a /12 is allocated then > > another /12 is issued to the RIR. > > Indeed. I see no point in unconditional doubling. I'm pretty confident > that /12 blocks are large enough to serve a RIR long enough so that > ordering a new /12 is not hampering anything. > > My suggestion would be to set aside a /8 per RIR (perhaps also a DNS > reverse delegation for that) and allocate /12s to the RIRs upon their > request. A RIR qualifies for a new /12 block as soon as nn% usage of > the current /12 block is reached. nn might be 50% or more. As Randy > suggests, the percentage should be low enough so that the RIRs can > get new space without delaying allocation to LIRs (as it happens > nowadays). > > > Best regards, > Daniel > > -- ------------------------------ Roger Jorgensen | rogerj at stud.cs.uit.no | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no ------------------------------------------------------- From ripe-lst at eirconnect.net Fri Aug 13 19:23:22 2004 From: ripe-lst at eirconnect.net (Sascha Luck) Date: Fri, 13 Aug 2004 18:23:22 +0100 Subject: [ipv6-wg@ripe.net] Re: [address-policy-wg] Policy for allocation of IPv6 address space from IANA to RIRs In-Reply-To: References: <1A38A7AC-EA1A-11D8-9320-000A95DAB530@ripe.net> <20040811102902.A18246@homebase.cluenet.de> Message-ID: <200408131823.22553.ripe-lst@eirconnect.net> On Wed 11 Aug 2004 15:38, Roger Jorgensen wrote: > no interest in getting into trouble with IPv6 in some years (20+) > similar to what there are today with IPv4 due to we thought we could > waste _too_ much of the address space:) The trouble with v4 today is not scarcity. This is largely due to the policy, in recent years, of conservation over aggregation but that has resulted in it's own problems, like large routing tables, un-aggregateable prefixes, etc. I somehow find it hard to envision a situation where IPv6 conservation may become an issue, be it in 20 years or 50 - fragmented address space is IMO the far more pressing issue... > ...Not to mention the trouble we for sure will have with regards to > how to solve one of the unsolved "problems", multihoming.... Not getting in on this one... Regards, Sascha Luck -- DoO Eirconnect From dr at cluenet.de Mon Aug 16 12:10:17 2004 From: dr at cluenet.de (Daniel Roesen) Date: Mon, 16 Aug 2004 12:10:17 +0200 Subject: [ipv6-wg@ripe.net] 2.0.0.2.ip6.arpa broken In-Reply-To: <20040814081756.GA15228@walton.maths.tcd.ie> References: <20040728112421.GG8260@vacation.karoshi.com.> <20040728175352.EC9DC13DFB@sa.vix.com> <20040728185237.GD9387@vacation.karoshi.com.> <20040728203508.GA467@Space.Net> <20040729030028.A1507@homebase.cluenet.de> <20040730114918.A17041@homebase.cluenet.de> <20040804035935.GB2517@vacation.karoshi.com.> <20040814081756.GA15228@walton.maths.tcd.ie> Message-ID: <20040816101017.GA15103@srv01.cluenet.de> On Sat, Aug 14, 2004 at 09:17:56AM +0100, David Malone wrote: > 2.0.0.2.ip6.int has become completely unavailable in the last few > days, resulting in delays for people connecting from 6to4 addresses > via ssh and the like. 2.0.0.2.ip6.arpa is also broken in all colors. soa @ns.apnic.net. for ip6.arpa. has serial: 2004071900 soa @ns.icann.org. for ip6.arpa. has serial: 2004071900 soa @ns-sec.ripe.net. for ip6.arpa. has serial: 2004071900 dig @tinnie.arin.net. for SOA of parent (ip6.arpa.) failed ==> tinnie.arin.net IPv6 connectivity is broken: $ dig @69.25.34.195 ip6.arpa. SOA +short dns1.icann.org. hostmaster.icann.org. 2004071900 3600 1800 604800 10800 $ dig @2001:440:2000:1::22 ip6.arpa. SOA ; <<>> DiG 9.2.3 <<>> @2001:440:2000:1::22 ip6.arpa. SOA ;; global options: printcmd ;; connection timed out; no servers could be reached Found 0 NS and 0 glue records for 2.0.0.2.ip6.arpa. @ns.apnic.net. (AUTH) Found 0 NS and 0 glue records for 2.0.0.2.ip6.arpa. @ns.icann.org. (AUTH) Found 4 NS and 4 glue records for 2.0.0.2.ip6.arpa. @ns-sec.ripe.net. (AUTH) DNServers for ip6.arpa. === 3 were also authoritatve for 2.0.0.2.ip6.arpa. === 0 were non-authoritative for 2.0.0.2.ip6.arpa. ERROR: Found 2 diff sets of NS records === from servers authoritative for 2.0.0.2.ip6.arpa. WARNING: ns.apnic.net. claims to be authoritative for 2.0.0.2.ip6.arpa. == but no NS record at parent zone WARNING: ns.icann.org. claims to be authoritative for 2.0.0.2.ip6.arpa. == but no NS record at parent zone WARNING: ns-sec.ripe.net. claims to be authoritative for 2.0.0.2.ip6.arpa. == but no NS record at parent zone ==> so although the three remaining NS for ip6.arpa have the same SOA serial, they obviously have a different view on the NS RRset for 2.0.0.2.ip6.arpa... and all are authoritative for 2.0.0.2.ip6.arpa. Now looking at the NS RRset ns-sec.ripe.net returns for 2.0.0.2.ip6.arpa: == ns-apnic.6to4.nro.net. ns-arin.6to4.nro.net. ns-lacnic.6to4.nro.net. == ns-ripe.6to4.nro.net. soa @ns-apnic.6to4.nro.net. for 2.0.0.2.ip6.arpa. serial: 2004072901 dig @ns-arin.6to4.nro.net. for SOA of 2.0.0.2.ip6.arpa. failed soa @ns-lacnic.6to4.nro.net. for 2.0.0.2.ip6.arpa. serial: 2004072901 soa @ns-ripe.6to4.nro.net. for 2.0.0.2.ip6.arpa. serial: 2004072901 ==> ns-arin.6to4.nro.net == tinnie.arin.net, so we have the same IPv6 reachability problem again What a mess all over... why do ns.apnic.net and ns.icann.org return NXDOMAIN when queried for the NS RRset for 2.0.0.2.ip6.arpa, but ns-sec.ripe.net returning one? It looks like the whole 2.0.0.2.ip6.arpa is missing in the ip6.arpa zone, and ns-sec.ripe.net is only by chance carrying the 2.0.0.2.ip6.arpa zone, thus returning the NS RRset. I wonder where's the right place to report such global (multi-RIR/org) DNS problems to, if not v6ops. I see no "global IPv6 operations" list, can anyone enlighten me? Best regards, Daniel From lee at ripe.net Mon Aug 16 14:12:00 2004 From: lee at ripe.net (Lee Wilmot) Date: Mon, 16 Aug 2004 14:12:00 +0200 Subject: [ipv6-wg@ripe.net] 2.0.0.2.ip6.arpa broken In-Reply-To: Your message of Mon, 16 Aug 2004 12:10:17 +0200. <20040816101017.GA15103@srv01.cluenet.de> References: <20040816101017.GA15103@srv01.cluenet.de> Message-ID: <200408161212.i7GCC0W7011106@birch.ripe.net> Daniel Roesen writes: * 2.0.0.2.ip6.arpa is also broken in all colors. As far as I know, this zone has not yet been inserted in the DNS tree (maybe because setup is incomplete) and the queries you are making will not be relevant to recursive queries starting at the root. But perhaps your mail stems from an announcement made on the v6ops list about setup of 2.0.0.2.ip6.arpa being complete ? In that case I understand your concern! * Now looking at the NS RRset ns-sec.ripe.net returns for 2.0.0.2.ip6.arpa: * * == ns-apnic.6to4.nro.net. ns-arin.6to4.nro.net. ns-lacnic.6to4.nro.net. * == ns-ripe.6to4.nro.net. * * soa @ns-apnic.6to4.nro.net. for 2.0.0.2.ip6.arpa. serial: 2004072901 * dig @ns-arin.6to4.nro.net. for SOA of 2.0.0.2.ip6.arpa. failed * soa @ns-lacnic.6to4.nro.net. for 2.0.0.2.ip6.arpa. serial: 2004072901 * soa @ns-ripe.6to4.nro.net. for 2.0.0.2.ip6.arpa. serial: 2004072901 * * ==> ns-arin.6to4.nro.net == tinnie.arin.net, so we have the same IPv6 * reachability problem again * * What a mess all over... why do ns.apnic.net and ns.icann.org return * NXDOMAIN when queried for the NS RRset for 2.0.0.2.ip6.arpa, but * ns-sec.ripe.net returning one? Where are any of these servers listed for the zone ? Why are you querying them ? The reason for ns-sec.ripe.net returning an answer is an unfortunate curiousity of RIPE NCC's current nameserver rearrangement which is irrelevant since it will never be listed as a nameserver for 2.0.0.2.ip6.arpa. * It looks like the whole 2.0.0.2.ip6.arpa * is missing in the ip6.arpa zone, * and ns-sec.ripe.net is only by chance * carrying the 2.0.0.2.ip6.arpa zone, thus returning the NS RRset. * * I wonder where's the right place to report such global (multi-RIR/org) * DNS problems to, if not v6ops. I see no "global IPv6 operations" list, * can anyone enlighten me? I think the best place to start reporting zone-specific DNS problems is with the SOA record RNAME. Lee Wilmot RIPE NCC From dr at cluenet.de Mon Aug 16 14:41:07 2004 From: dr at cluenet.de (Daniel Roesen) Date: Mon, 16 Aug 2004 14:41:07 +0200 Subject: [ipv6-wg@ripe.net] 2.0.0.2.ip6.arpa broken In-Reply-To: <200408161212.i7GCC0W7011106@birch.ripe.net> References: <20040816101017.GA15103@srv01.cluenet.de> <200408161212.i7GCC0W7011106@birch.ripe.net> Message-ID: <20040816124107.GE15103@srv01.cluenet.de> On Mon, Aug 16, 2004 at 02:12:00PM +0200, Lee Wilmot wrote: > * 2.0.0.2.ip6.arpa is also broken in all colors. > > As far as I know, this zone has not yet been inserted in the DNS tree > (maybe because setup is incomplete) This was my idea as well, as I pointed out. > and the queries you are making will not be relevant to recursive > queries starting at the root. They _are_ relevant. A resolver queries the roots, they delegate to the ip6.arpa nameservers. One of those is ns-sec.ripe.net. If a resolver then goes on asking ns-sec.ripe.net for 2.0.0.2.arpa, the resolver _does_ get an answer. So it _is_ relevant. > But perhaps your mail stems from an announcement made on the v6ops > list about setup of 2.0.0.2.ip6.arpa being complete ? Uhm no idea. I just assumed that things should work, as ns-sec.ripe.net returned some SOA for that. > * What a mess all over... why do ns.apnic.net and ns.icann.org return > * NXDOMAIN when queried for the NS RRset for 2.0.0.2.ip6.arpa, but > * ns-sec.ripe.net returning one? > > Where are any of these servers listed for the zone ? Why are you > querying them ? Those are the servers for ip6.arpa. > The reason for ns-sec.ripe.net returning an answer is an unfortunate > curiousity of RIPE NCC's current nameserver rearrangement which is > irrelevant since it will never be listed as a nameserver for > 2.0.0.2.ip6.arpa. Resolvers start from the root and work their way up. ns-sec.ripe.net is one of the ip6.arpa servers, so it would answer. > * I wonder where's the right place to report such global (multi-RIR/org) > * DNS problems to, if not v6ops. I see no "global IPv6 operations" list, > * can anyone enlighten me? > > I think the best place to start reporting zone-specific DNS problems > is with the SOA record RNAME. Well, as it was not clear which zone/server actually had what problem, to which SOA contact? Well yes, dns-admin at apnic.net would have been an idea, according to the SOA present for 2.0.0.2.ip6.arpa at ns-sec.ripe.net. BTW... I've tried mailing noc at icann.org to have them fix the broken int. TLD delegation, but this went unanswered. Not encouraging. ns.isi.edu is now authoritative again for int., but ns.ripe.net is still not in the delegation NS RRset within the root zone, albeit being listed in the NS RRset of the int. zone. Regards, Daniel From dr at cluenet.de Mon Aug 16 20:51:11 2004 From: dr at cluenet.de (Daniel Roesen) Date: Mon, 16 Aug 2004 20:51:11 +0200 Subject: [ipv6-wg@ripe.net] 2.0.0.2.ip6.arpa broken In-Reply-To: <200408161212.i7GCC0W7011106@birch.ripe.net> References: <20040816101017.GA15103@srv01.cluenet.de> <200408161212.i7GCC0W7011106@birch.ripe.net> Message-ID: <20040816185111.GA19433@srv01.cluenet.de> On Mon, Aug 16, 2004 at 02:12:00PM +0200, Lee Wilmot wrote: > The reason for ns-sec.ripe.net returning an answer is an unfortunate > curiousity of RIPE NCC's current nameserver rearrangement which is > irrelevant since it will never be listed as a nameserver for > 2.0.0.2.ip6.arpa. BTW... $ dig ip6.arpa. NS @a.root-servers.net. +short NS.APNIC.NET. NS.ICANN.ORG. NS.RIPE.NET. TINNIE.ARIN.NET. $ dig ip6.arpa. NS @ns.ripe.net +short ns.apnic.net. ns.icann.org. ns-sec.ripe.net. tinnie.arin.net. NS RRset in zone ip6.arpa is not matching the NS RRset for ip6.arpa in the root zone. ns.ripe.net != ns-sec.ripe.net by IP address, but still both are auth for 2.0.0.2.ip6.arpa: $ dig @ns.ripe.net. 2.0.0.2.ip6.arpa. SOA +norec +short master.apnic.net. dns-admin.apnic.net. 2004072901 7200 1800 604800 172800 $ dig @ns-sec.ripe.net. 2.0.0.2.ip6.arpa. SOA +norec +short master.apnic.net. dns-admin.apnic.net. 2004072901 7200 1800 604800 172800 So the relevance is given, no matter why ns-sec gets involved (because the in-zone NS RRset overwrites the NS RRset from the roots in caches). I think it would be a good idea[tm] to remove the 2.0.0.2.ip6.arpa zone from ns.ripe.net and ns-sec.ripe.net if you don't intend to publish the zone... Best regards, Daniel From lee at ripe.net Tue Aug 17 11:29:19 2004 From: lee at ripe.net (Lee Wilmot) Date: Tue, 17 Aug 2004 11:29:19 +0200 Subject: [ipv6-wg@ripe.net] 2.0.0.2.ip6.arpa broken In-Reply-To: Your message of Mon, 16 Aug 2004 20:51:11 +0200. <20040816185111.GA19433@srv01.cluenet.de> References: <20040816185111.GA19433@srv01.cluenet.de> Message-ID: <200408170929.i7H9TJW7020625@birch.ripe.net> Hi Daniel, * $ dig ip6.arpa. NS @a.root-servers.net. +short * NS.APNIC.NET. * NS.ICANN.ORG. * NS.RIPE.NET. * TINNIE.ARIN.NET. * $ dig ip6.arpa. NS @ns.ripe.net +short * ns.apnic.net. * ns.icann.org. * ns-sec.ripe.net. * tinnie.arin.net. * * NS RRset in zone ip6.arpa is not matching the NS RRset for ip6.arpa in * the root zone. Ah, that's a glaring problem. I wondered where you had seen ns-sec.ripe.net referenced. We asked the primary operator for ip6.arpa to move ns.ripe.net -> ns-sec.ripe.net a while ago, apparently they didn't notify the parent zone primary. We've sent them a reminder. In a previous post you mentioned: * ns.isi.edu is now authoritative again for int., but * ns.ripe.net is still not in the delegation NS RRset within the * root zone, albeit being listed in the NS RRset of the int. zone. Coincidentally, a few days ago we requested that the primary operator for int change the server ns.ripe.net -> ns-sec.ripe.net (and notify their parent...) * ns.ripe.net != ns-sec.ripe.net by IP address, but still both are auth * for 2.0.0.2.ip6.arpa: * * $ dig @ns.ripe.net. 2.0.0.2.ip6.arpa. SOA +norec +short * master.apnic.net. dns-admin.apnic.net. 2004072901 7200 1800 604800 172800 * $ dig @ns-sec.ripe.net. 2.0.0.2.ip6.arpa. SOA +norec +short * master.apnic.net. dns-admin.apnic.net. 2004072901 7200 1800 604800 172800 * * So the relevance is given, no matter why ns-sec gets involved (because * the in-zone NS RRset overwrites the NS RRset from the roots in caches). * * I think it would be a good idea[tm] to remove the 2.0.0.2.ip6.arpa * zone from ns.ripe.net and ns-sec.ripe.net if you don't intend to * publish the zone... We've temporarily moved the zone to a different machine prior to delegation so you should get NXDOMAIN going via the roots. APNIC will update the ns-ripe.6to4.nro.net record as they are running the primary for 6to4.nro.net. Finally, we've notified ARIN that tinnie.arin.net is not reachable over v6 and that it's presenting the 2.0.0.2.ip6.arpa zone due to also running ip6.arpa. Thanks very much for your problem reports! Lee Wilmot RIPE NCC From leo at ripe.net Wed Aug 18 10:53:47 2004 From: leo at ripe.net (leo vegoda) Date: Wed, 18 Aug 2004 10:53:47 +0200 Subject: [ipv6-wg@ripe.net] New IPv6 Address Block Allocated to RIPE NCC Message-ID: <1E5D4C7A-F0F4-11D8-BAEA-000A95DAB530@ripe.net> Dear Colleagues, The RIPE NCC received the IPv6 address range 2001:4600::/23 from the IANA in August 2004. You may want 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: Regards, -- leo vegoda Registration Services Manager RIPE NCC From dr at cluenet.de Thu Aug 19 21:59:51 2004 From: dr at cluenet.de (Daniel Roesen) Date: Thu, 19 Aug 2004 21:59:51 +0200 Subject: [ipv6-wg@ripe.net] Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?) In-Reply-To: <20040804035935.GB2517@vacation.karoshi.com.> References: <20040728112421.GG8260@vacation.karoshi.com.> <20040728175352.EC9DC13DFB@sa.vix.com> <20040728185237.GD9387@vacation.karoshi.com.> <20040728203508.GA467@Space.Net> <20040729030028.A1507@homebase.cluenet.de> <20040730114918.A17041@homebase.cluenet.de> <20040804035935.GB2517@vacation.karoshi.com.> Message-ID: <20040819195951.GA28856@srv01.cluenet.de> On Wed, Aug 04, 2004 at 03:59:35AM +0000, bmanning at vacation.karoshi.com wrote: > > So the whole delegation thing is broken. The int. TLD servers delegate > > ip6.int to imag.imag.fr which feels it self authoritative, but isn't > > in the NS RRset of the ip6.int zone. And ip6.int is delegated to > > munnari.oz.au which doesn't know about this (anymore). > > so... this was apparently enough to get the attention it > deserved. the long postponed migration from imag.imag.fr. > to ns3.nic.fr. is now "done" and imag.imag.fr. has been removed > from the NS list in the INT zone. > and munnari.oz.au has been removed. - more cleanup in the > next week or two. Well, two weeks down the road and things got even worse: NS list summary for ip6.int. from parent (int.) servers == flag.ep.net. ns3.nic.fr. y.ip6.int. == z.ip6.int. $ dig @flag.ep.net. int. SOA +norec | fgrep status: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 9740 $ dig @ns3.nic.fr int. SOA +norec | fgrep status: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 334 $ dig @y.ip6.int int. SOA +norec | fgrep status: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 17872 $ dig @z.ip6.int int. SOA +norec ;; connection timed out; no servers could be reached So we have 3 out of 4 servers totally broken. Looks like the importance of ip6.int is way overstated by some folks. Regards, Daniel From jeroen at unfix.org Fri Aug 20 09:25:59 2004 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 20 Aug 2004 09:25:59 +0200 Subject: [ipv6-wg@ripe.net] FW: [arin-council] IANA to RIR IPv6 Allocation Message-ID: <1092986758.3056.128.camel@segesta.zurich.ibm.com> For people not on the arin-council (not likely ;) or the ppml at arin lists: -----Forwarded Message----- From: "Sweeting, John" To: 'ppml at arin.net' Subject: [ppml] FW: [arin-council] IANA to RIR IPv6 Allocation Date: Thu, 19 Aug 2004 17:36:56 -0400 I am submitting the following proposal IAW ARIN's Internet Resource Policy Evaluation Process. In the interest of all I would like to disclose up front that the information used to prepare this template was provided by ARIN staff. ############################################ Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0 1. Policy Proposal Name: Allocation of IPv6 Address Space by the Internet Assigned Numbers Authority (IANA) Policy to Regional Internet Registries 2. Author a. name: John Sweeting b. email: john.sweeting at teleglobe.com c. telephone: 703-766-3042 d. organization: ARIN Advisory Council 3. Proposal Version: 1 4. Submission Date: 8/17/04 5. Proposal type: new, global 6. Policy term: permanent 7. Policy statement: 1. Minimum Allocation Size. The minimum size of any allocation of IPv6 address space from IANA to an RIR is prefix length /12. If this address space is not sufficient to meet the needs of an RIR for a projected 18 month period, IANA shall allocate to that RIR the address space for which it can provide justification. 2. Reservation of Unicast Address space. 2.1 IANA. By RFC 3513 the IANA has been allocated the range of IPv6 addresses beginning at binary value 001 (prefix length /3) for its allocations of unicast address space. In order to support regional aggregation of IPv6 address space IANA shall establish a reservation of a prefix length of /6 from this space for each established RIR and for each emerging RIR. Allocations to each RIR will be from the appropriate reservation. 2.2. RIRs. Each RIR may apply its own respective chosen allocation and reservation strategy in order to meet the needs of its community and to ensure the efficiency and efficacy of its work. Such reservations made by an RIR will be considered as being allocated by that RIR when that RIR applies for an allocation of address space from the IANA. 3. Initial Allocation. 3.1. Upon implementation of this policy IANA shall allocate to each established RIR a /12 from the reservation established for each particular RIR. 3.2. Upon recognition of an RIR by ICANN that RIR shall receive a /12 from the reservation set aside for that RIR. 4. Subsequent Allocation. An RIR shall be eligible for an allocation of at least a minimal allocation from the IANA when its current holdings are less than 50% of its 18 month requirement or when it has less than 180 days of holdings available. The IANA shall evaluate the requested allocation using a set of administrative procedures that are mutually agreed to by the IANA and the NRO. This set of procedures shall be enacted within 30 days of the implentation of this policy. 5. Announcement of IANA allocations to the RIRs When address space is allocated to a RIR, the IANA will send a detailed announcement to the receiving RIR. The IANA will also make announcements to all other RIRs, informing them of the recent allocation. The IANA will make appropriate modifications to the "Internet Protocol V6 Address Space" page of the IANA website and may make announcements to only its own global announcement lists. The IANA announcements will be limited to which address ranges, the time of allocation and to which Registry they have been allocated. 8. Rationale: The current IANA allocation policy for IPv6 is an interim policy that was promulgated in 1999. Operational experience has demonstrated the current minimum allocation size is too small; that the built in reservation system that must be followed by the RIRs does not allow for efficient and effective management of the resource by the RIR; and does not provide for an well known evaluation criteria. This document does not stipulate performance requirements in the provision of services by IANA to an RIR in accordance with the policy. Such requirements should be specified by appropriate agreements between the NRO and ICANN. 9. Timetable for implementation: Thirty days after ratification by the ICANN Board of Directors in accordance with the global policy development process. 10. Meeting presenter: Elected AC Member or the President of ARIN. END OF TEMPLATE ################################################ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part URL: From jeroen at unfix.org Fri Aug 20 09:32:51 2004 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 20 Aug 2004 09:32:51 +0200 Subject: [ipv6-wg@ripe.net] Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?) In-Reply-To: <20040819195951.GA28856@srv01.cluenet.de> References: <20040728112421.GG8260@vacation.karoshi.com.> <20040728175352.EC9DC13DFB@sa.vix.com> <20040728185237.GD9387@vacation.karoshi.com.> <20040728203508.GA467@Space.Net> <20040729030028.A1507@homebase.cluenet.de> <20040730114918.A17041@homebase.cluenet.de> <20040804035935.GB2517@vacation.karoshi.com.> <20040819195951.GA28856@srv01.cluenet.de> Message-ID: <1092987171.3056.134.camel@segesta.zurich.ibm.com> [itojun copied as he replied on something similar but on the sig-ipv6 list] On Thu, 2004-08-19 at 21:59, Daniel Roesen wrote: > On Wed, Aug 04, 2004 at 03:59:35AM +0000, bmanning at vacation.karoshi.com wrote: > > > So the whole delegation thing is broken. The int. TLD servers delegate > > > ip6.int to imag.imag.fr which feels it self authoritative, but isn't > > > in the NS RRset of the ip6.int zone. And ip6.int is delegated to > > > munnari.oz.au which doesn't know about this (anymore). > > > > so... this was apparently enough to get the attention it > > deserved. the long postponed migration from imag.imag.fr. > > to ns3.nic.fr. is now "done" and imag.imag.fr. has been removed > > from the NS list in the INT zone. > > and munnari.oz.au has been removed. - more cleanup in the > > next week or two. > > Well, two weeks down the road and things got even worse: > > NS list summary for ip6.int. from parent (int.) servers > == flag.ep.net. ns3.nic.fr. y.ip6.int. > == z.ip6.int. > > $ dig @flag.ep.net. int. SOA +norec | fgrep status: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 9740 > $ dig @ns3.nic.fr int. SOA +norec | fgrep status: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 334 > $ dig @y.ip6.int int. SOA +norec | fgrep status: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 17872 > $ dig @z.ip6.int int. SOA +norec > ;; connection timed out; no servers could be reached > > So we have 3 out of 4 servers totally broken. > > Looks like the importance of ip6.int is way overstated by some folks. I guess the people running the servers have found out that ip6.int is not that important and nicely let it rot away, apparently not enough/no people complain thus this is a good thing. It is quite bad to see that these 'important' (ahem) services have been so recklessly managed over the last couple of years. I hope the 'powers that be' see that it is just better to remove the ip6.int servers entirely and officially, that way at least people can know why they are broken: because they have been deprecated 3 years ago. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part URL: From itojun at itojun.org Fri Aug 20 09:18:49 2004 From: itojun at itojun.org (Jun-ichiro itojun Hagino) Date: Fri, 20 Aug 2004 16:18:49 +0900 (JST) Subject: [ipv6-wg@ripe.net] RE: [sig-ipv6] Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 :ip6.int shutdown?) In-Reply-To: Your message of "Mon, 26 Jul 2004 10:13:57 -0400" <9C422444DE99BC46B3AD3C6EAFC9711B06AFF574@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B06AFF574@tayexc13.americas.cpqcorp.net> Message-ID: <20040820071849.9E6121C0C7@coconut.itojun.org> related topic... it looks that there's lame delegation in ip6.int tree. "int" servers have NS glue for "ip6.int" servers, however, two of them does not respond to ip6.int query at all, and the other two responds with SERVFAIL. itojun From robert at martin-legene.dk Fri Aug 20 09:39:40 2004 From: robert at martin-legene.dk (Robert =?iso-8859-1?Q?Martin-Leg=E8ne?=) Date: Fri, 20 Aug 2004 09:39:40 +0200 Subject: [ipv6-wg@ripe.net] Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?) In-Reply-To: <20040819195951.GA28856@srv01.cluenet.de> References: <20040728112421.GG8260@vacation.karoshi.com.> <20040728175352.EC9DC13DFB@sa.vix.com> <20040728185237.GD9387@vacation.karoshi.com.> <20040728203508.GA467@Space.Net> <20040729030028.A1507@homebase.cluenet.de> <20040730114918.A17041@homebase.cluenet.de> <20040804035935.GB2517@vacation.karoshi.com.> <20040819195951.GA28856@srv01.cluenet.de> Message-ID: <20040820073940.GA65077@kb.pinguino.dk> On Thu, Aug 19, 2004 at 09:59:51PM +0200, Daniel Roesen wrote: > Well, two weeks down the road and things got even worse: > > NS list summary for ip6.int. from parent (int.) servers > == flag.ep.net. ns3.nic.fr. y.ip6.int. > == z.ip6.int. > > $ dig @flag.ep.net. int. SOA +norec | fgrep status: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 9740 > $ dig @ns3.nic.fr int. SOA +norec | fgrep status: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 334 > $ dig @y.ip6.int int. SOA +norec | fgrep status: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 17872 > $ dig @z.ip6.int int. SOA +norec > ;; connection timed out; no servers could be reached > > So we have 3 out of 4 servers totally broken. > > Looks like the importance of ip6.int is way overstated by some folks. Shouldn't you be asking these servers for ip6.int instead of asking them for int.? Either way, I seem to be getting the same results. For int. itself, it seems that only ns.isi.edu is not authoritative. -- Robert Martin-Leg?ne From david.kessens at nokia.com Fri Aug 20 10:48:52 2004 From: david.kessens at nokia.com (David Kessens) Date: Fri, 20 Aug 2004 01:48:52 -0700 Subject: [ipv6-wg@ripe.net] FW: [arin-council] IANA to RIR IPv6 Allocation In-Reply-To: <1092986758.3056.128.camel@segesta.zurich.ibm.com> References: <1092986758.3056.128.camel@segesta.zurich.ibm.com> Message-ID: <20040820084852.GC664@nokia.com> Jeroen, On Fri, Aug 20, 2004 at 09:25:59AM +0200, Jeroen Massar wrote: > For people not on the arin-council (not likely ;) or the ppml at arin > lists: All policy discussions for the RIPE region are now conducted at the RIPE policy working group maillist: address-policy-wg at ripe.net David Kessens --- > -----Forwarded Message----- > From: "Sweeting, John" > To: 'ppml at arin.net' > Subject: [ppml] FW: [arin-council] IANA to RIR IPv6 Allocation > Date: Thu, 19 Aug 2004 17:36:56 -0400 > > I am submitting the following proposal IAW ARIN's Internet Resource Policy > Evaluation Process. In the interest of all I would like to disclose up front > that the information used to prepare this template was provided by ARIN > staff. > > > ############################################ > Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0 > > 1. Policy Proposal Name: Allocation of IPv6 Address Space by the Internet > Assigned Numbers Authority (IANA) Policy to Regional Internet Registries > > 2. Author > > a. name: John Sweeting > b. email: john.sweeting at teleglobe.com > c. telephone: 703-766-3042 > d. organization: ARIN Advisory Council > > 3. Proposal Version: 1 > > 4. Submission Date: 8/17/04 > > 5. Proposal type: new, global > > 6. Policy term: permanent > > 7. Policy statement: > > 1. Minimum Allocation Size. > > The minimum size of any allocation of IPv6 address space from IANA to an RIR > is prefix length /12. If this address space is not sufficient to meet the > needs of an RIR for a projected 18 month period, IANA shall allocate to that > RIR the address space for which it can provide justification. > > 2. Reservation of Unicast Address space. > > 2.1 IANA. By RFC 3513 the IANA has been allocated the range of IPv6 > addresses beginning at binary value 001 (prefix length /3) for its > allocations of unicast address space. In order to support regional > aggregation of IPv6 address space IANA shall establish a reservation of a > prefix length of /6 from this space for each established RIR and for each > emerging RIR. Allocations to each RIR will be from the appropriate > reservation. > > 2.2. RIRs. Each RIR may apply its own respective chosen allocation and > reservation strategy in order to meet the needs of its community and to > ensure the efficiency and efficacy of its work. Such reservations made by > an RIR will be considered as being allocated by that RIR when that RIR > applies for an allocation of address space from the IANA. > > 3. Initial Allocation. > > 3.1. Upon implementation of this policy IANA shall allocate to each > established RIR a /12 from the reservation established for each particular > RIR. > > 3.2. Upon recognition of an RIR by ICANN that RIR shall receive a /12 from > the reservation set aside for that RIR. > > > 4. Subsequent Allocation. > > An RIR shall be eligible for an allocation of at least a minimal allocation > from the IANA when its current holdings are less than 50% of its 18 month > requirement or when it has less than 180 days of holdings available. The > IANA shall evaluate the requested allocation using a set of administrative > procedures that are mutually agreed to by the IANA and the NRO. This set of > procedures shall be enacted within 30 days of the implentation of this > policy. > > > 5. Announcement of IANA allocations to the RIRs > > When address space is allocated to a RIR, the IANA will send a detailed > announcement to the receiving RIR. The IANA will also make announcements to > all other RIRs, informing them of the recent allocation. > > The IANA will make appropriate modifications to the "Internet Protocol V6 > Address Space" page of the IANA website and may make announcements to only > its own global announcement lists. The IANA announcements will be limited > to which address ranges, the time of allocation and to which Registry they > have been allocated. > > > 8. Rationale: > > The current IANA allocation policy for IPv6 is an interim policy that was > promulgated in 1999. Operational experience has demonstrated the current > minimum allocation size is too small; that the built in reservation system > that must be followed by the RIRs does not allow for efficient and effective > management of the resource by the RIR; and does not provide for an well > known evaluation criteria. This document does not stipulate performance > requirements in the provision of services by IANA to an RIR in accordance > with the policy. Such requirements should be specified by appropriate > agreements between the NRO and ICANN. > > > 9. Timetable for implementation: Thirty days after ratification by the ICANN > Board of Directors in accordance with the global policy development process From tjc at ecs.soton.ac.uk Fri Aug 20 12:38:06 2004 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Fri, 20 Aug 2004 11:38:06 +0100 Subject: [ipv6-wg@ripe.net] FW: [arin-council] IANA to RIR IPv6 Allocation In-Reply-To: <1092986758.3056.128.camel@segesta.zurich.ibm.com> References: <1092986758.3056.128.camel@segesta.zurich.ibm.com> Message-ID: <20040820103806.GE23520@login.ecs.soton.ac.uk> Hi Jeroen, Was there a discussion of /8 vs /12? Tim On Fri, Aug 20, 2004 at 09:25:59AM +0200, Jeroen Massar wrote: > For people not on the arin-council (not likely ;) or the ppml at arin > lists: > > -----Forwarded Message----- > From: "Sweeting, John" > To: 'ppml at arin.net' > Subject: [ppml] FW: [arin-council] IANA to RIR IPv6 Allocation > Date: Thu, 19 Aug 2004 17:36:56 -0400 > > I am submitting the following proposal IAW ARIN's Internet Resource Policy > Evaluation Process. In the interest of all I would like to disclose up front > that the information used to prepare this template was provided by ARIN > staff. > > > ############################################ > Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0 > > 1. Policy Proposal Name: Allocation of IPv6 Address Space by the Internet > Assigned Numbers Authority (IANA) Policy to Regional Internet Registries > > 2. Author > > a. name: John Sweeting > b. email: john.sweeting at teleglobe.com > c. telephone: 703-766-3042 > d. organization: ARIN Advisory Council > > 3. Proposal Version: 1 > > 4. Submission Date: 8/17/04 > > 5. Proposal type: new, global > > 6. Policy term: permanent > > 7. Policy statement: > > 1. Minimum Allocation Size. > > The minimum size of any allocation of IPv6 address space from IANA to an RIR > is prefix length /12. If this address space is not sufficient to meet the > needs of an RIR for a projected 18 month period, IANA shall allocate to that > RIR the address space for which it can provide justification. > > 2. Reservation of Unicast Address space. > > 2.1 IANA. By RFC 3513 the IANA has been allocated the range of IPv6 > addresses beginning at binary value 001 (prefix length /3) for its > allocations of unicast address space. In order to support regional > aggregation of IPv6 address space IANA shall establish a reservation of a > prefix length of /6 from this space for each established RIR and for each > emerging RIR. Allocations to each RIR will be from the appropriate > reservation. > > 2.2. RIRs. Each RIR may apply its own respective chosen allocation and > reservation strategy in order to meet the needs of its community and to > ensure the efficiency and efficacy of its work. Such reservations made by > an RIR will be considered as being allocated by that RIR when that RIR > applies for an allocation of address space from the IANA. > > 3. Initial Allocation. > > 3.1. Upon implementation of this policy IANA shall allocate to each > established RIR a /12 from the reservation established for each particular > RIR. > > 3.2. Upon recognition of an RIR by ICANN that RIR shall receive a /12 from > the reservation set aside for that RIR. > > > 4. Subsequent Allocation. > > An RIR shall be eligible for an allocation of at least a minimal allocation > from the IANA when its current holdings are less than 50% of its 18 month > requirement or when it has less than 180 days of holdings available. The > IANA shall evaluate the requested allocation using a set of administrative > procedures that are mutually agreed to by the IANA and the NRO. This set of > procedures shall be enacted within 30 days of the implentation of this > policy. > > > 5. Announcement of IANA allocations to the RIRs > > When address space is allocated to a RIR, the IANA will send a detailed > announcement to the receiving RIR. The IANA will also make announcements to > all other RIRs, informing them of the recent allocation. > > The IANA will make appropriate modifications to the "Internet Protocol V6 > Address Space" page of the IANA website and may make announcements to only > its own global announcement lists. The IANA announcements will be limited > to which address ranges, the time of allocation and to which Registry they > have been allocated. > > > 8. Rationale: > > The current IANA allocation policy for IPv6 is an interim policy that was > promulgated in 1999. Operational experience has demonstrated the current > minimum allocation size is too small; that the built in reservation system > that must be followed by the RIRs does not allow for efficient and effective > management of the resource by the RIR; and does not provide for an well > known evaluation criteria. This document does not stipulate performance > requirements in the provision of services by IANA to an RIR in accordance > with the policy. Such requirements should be specified by appropriate > agreements between the NRO and ICANN. > > > 9. Timetable for implementation: Thirty days after ratification by the ICANN > Board of Directors in accordance with the global policy development process. > > 10. Meeting presenter: Elected AC Member or the President of ARIN. > > END OF TEMPLATE > ################################################ From jeroen at unfix.org Fri Aug 20 13:07:12 2004 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 20 Aug 2004 13:07:12 +0200 Subject: [ipv6-wg@ripe.net] FW: [arin-council] IANA to RIR IPv6 Allocation In-Reply-To: <20040820103806.GE23520@login.ecs.soton.ac.uk> References: <1092986758.3056.128.camel@segesta.zurich.ibm.com> <20040820103806.GE23520@login.ecs.soton.ac.uk> Message-ID: <1093000031.3056.145.camel@segesta.zurich.ibm.com> On Fri, 2004-08-20 at 12:38, Tim Chown wrote: > Hi Jeroen, > > Was there a discussion of /8 vs /12? Nope, that was on the address-wg at ripe and partially on the ipv6-wg at ripe lists. This is an announcement out of the of the blue from the arin side, I guess there has been discussion on arin-council, but that is afaik a closed list. ppml is the public policy mailing list, which indicates already that arin does things behind closed doors ;) Btw check the following url for the archives: http://www.arin.net/mailing_lists/ppml/index.html Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part URL: From plzak at arin.net Fri Aug 20 13:41:58 2004 From: plzak at arin.net (Ray Plzak) Date: Fri, 20 Aug 2004 07:41:58 -0400 Subject: [ipv6-wg@ripe.net] FW: [arin-council] IANA to RIR IPv6Allocation In-Reply-To: <1093000031.3056.145.camel@segesta.zurich.ibm.com> Message-ID: <20040820114159.2760CCF39E@mercury.arin.net> Jeroen, Before you comments about the ARIN policy process I suggest you read: http://www.arin.net/policy/ipep.html I think you will find two things that are immediately clear to even the casual observer: 1. This statement on the ppml is just the beginning of the process. It was posted by a member of the ARIN AC as an individual member and does not represent any discussion by the AC in regards to this policy. At this point it is not even a formal policy proposal that will be taken up for discussion at the ARIN meeting in Reston in October. 2. The next step in the process is for this proposal and any others to be discussed by the AC as described in the policy proposal document. I will not go any further in describing the process as it is available for your reading at the url I provided. Again I suggest you read it and I would be glad to know how this process does not promote an open discussion on any policy in the ARIN region. Your specific comments will be most welcome. Lastly, I invite you to participate in the discussion on the ARIN ppml. Your participation and that of anyone, anywhere in the world is most welcome. One does not need to be a member of ARIN to participate. Of course the ARIN meeting is an open meeting. It is open to anyone in the world who wishes to participate in the policy process. Ray > -----Original Message----- > From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of > Jeroen Massar > Sent: Friday, August 20, 2004 7:07 AM > To: Tim Chown > Cc: ipv6-wg at ripe.net > Subject: Re: [ipv6-wg at ripe.net] FW: [arin-council] IANA to RIR > IPv6Allocation > > On Fri, 2004-08-20 at 12:38, Tim Chown wrote: > > Hi Jeroen, > > > > Was there a discussion of /8 vs /12? > > Nope, that was on the address-wg at ripe and partially on the ipv6-wg at ripe > lists. This is an announcement out of the of the blue from the arin > side, I guess there has been discussion on arin-council, but that is > afaik a closed list. ppml is the public policy mailing list, which > indicates already that arin does things behind closed doors ;) > > Btw check the following url for the archives: > http://www.arin.net/mailing_lists/ppml/index.html > > Greets, > Jeroen From gert at space.net Fri Aug 20 13:54:33 2004 From: gert at space.net (Gert Doering) Date: Fri, 20 Aug 2004 13:54:33 +0200 Subject: [ipv6-wg@ripe.net] Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?) In-Reply-To: <20040820194046s-kawamura@mail.jp.nec.com> References: <20040820073940.GA65077@kb.pinguino.dk> <20040820194046s-kawamura@mail.jp.nec.com> Message-ID: <20040820115433.GL467@Space.Net> Hi, On Fri, Aug 20, 2004 at 07:40:46PM +0900, kawamura seiichi wrote: > (First time writing to this Mailing list) > Are there any temporary solutions to this ip6.int. > broken problem? or do we just have to wait until 9/9? > Some applications keep asking for ip6.int. and > servers not responding cause delays to the application services. > Would be very helpful if someone could give me tips. The best way would be to fix these applications as fast as possible. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 65398 (60210) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From plzak at arin.net Fri Aug 20 14:01:27 2004 From: plzak at arin.net (Ray Plzak) Date: Fri, 20 Aug 2004 08:01:27 -0400 Subject: [ipv6-wg@ripe.net] RE: [address-policy-wg] Re: IANA to RIR IPv6 Allocation In-Reply-To: <00A36A45.014A4C38.6@cc.univie.ac.at> Message-ID: <20040820120128.25489CF39E@mercury.arin.net> Wilfried, I've forwarded your comment to the ARIN ppml. Ray > -----Original Message----- > From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg- > admin at ripe.net] On Behalf Of Wilfried Woeber, UniVie/ACOnet > Sent: Friday, August 20, 2004 7:50 AM > To: address-policy-wg at ripe.net > Cc: ipv6-wg at ripe.net; woeber at cc.univie.ac.at > Subject: [address-policy-wg] Re: IANA to RIR IPv6 Allocation > > I've got one comment here on > section 7. paragraph 4. "Subsequent Allocation": > > While the wording might be sufficiently clear for a native speaker by > referring to "set of administrative procedures....", I am missing clear > guidance for the IANA that there should _not_ be any incentive or > responsibilty to consult with other groups, entities or third parties > (irrespective of their, say, credibility for e.g. protocol development > or technical specifications) which would require extending that 30 day > period. > > My proposal would be that IANA would have to perform the subsequent > allocation within this 30 day period, even if they might not be able to > obtain advice or an expertise (for whatever reason) from any other party > they might have decided to ask for advice. > > Wilfried ( https://cert.aco.net/ ) > _________________________________:_____________________________________ > Wilfried Woeber : e-mail: Woeber at CC.UniVie.ac.at > UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 > Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 > A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ...there's no place like 127.0.0.1 (or ::1/128 ?) > > > From: David Kessens > To: Jeroen Massar > Date: Fri, 20 Aug 2004 01:48:52 -0700 > CC: ipv6-wg at ripe.net > Subject: Re: [ipv6-wg at ripe.net] FW: [arin-council] IANA to RIR IPv6 > Allocation > > > Jeroen, > > On Fri, Aug 20, 2004 at 09:25:59AM +0200, Jeroen Massar wrote: > > For people not on the arin-council (not likely ;) or the ppml at arin > > lists: > > All policy discussions for the RIPE region are now conducted at the RIPE > policy working group maillist: > > address-policy-wg at ripe.net > > David Kessens > --- > > > -----Forwarded Message----- > > From: "Sweeting, John" > > To: 'ppml at arin.net' > > Subject: [ppml] FW: [arin-council] IANA to RIR IPv6 Allocation > > Date: Thu, 19 Aug 2004 17:36:56 -0400 > > > > I am submitting the following proposal IAW ARIN's Internet Resource > Policy > > Evaluation Process. In the interest of all I would like to disclose up > front > > that the information used to prepare this template was provided by ARIN > > staff. > > > > > > ############################################ > > Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0 > > > > 1. Policy Proposal Name: Allocation of IPv6 Address Space by the > Internet > > Assigned Numbers Authority (IANA) Policy to Regional Internet Registries > > > > 2. Author > > > > a. name: John Sweeting > > b. email: john.sweeting at teleglobe.com > > c. telephone: 703-766-3042 > > d. organization: ARIN Advisory Council > > > > 3. Proposal Version: 1 > > > > 4. Submission Date: 8/17/04 > > > > 5. Proposal type: new, global > > > > 6. Policy term: permanent > > > > 7. Policy statement: > > > > 1. Minimum Allocation Size. > > > > The minimum size of any allocation of IPv6 address space from IANA to an > RIR > > is prefix length /12. If this address space is not sufficient to meet > the > > needs of an RIR for a projected 18 month period, IANA shall allocate to > that > > RIR the address space for which it can provide justification. > > > > 2. Reservation of Unicast Address space. > > > > 2.1 IANA. By RFC 3513 the IANA has been allocated the range of IPv6 > > addresses beginning at binary value 001 (prefix length /3) for its > > allocations of unicast address space. In order to support regional > > aggregation of IPv6 address space IANA shall establish a reservation of > a > > prefix length of /6 from this space for each established RIR and for > each > > emerging RIR. Allocations to each RIR will be from the appropriate > > reservation. > > > > 2.2. RIRs. Each RIR may apply its own respective chosen allocation and > > reservation strategy in order to meet the needs of its community and to > > ensure the efficiency and efficacy of its work. Such reservations made > by > > an RIR will be considered as being allocated by that RIR when that RIR > > applies for an allocation of address space from the IANA. > > > > 3. Initial Allocation. > > > > 3.1. Upon implementation of this policy IANA shall allocate to each > > established RIR a /12 from the reservation established for each > particular > > RIR. > > > > 3.2. Upon recognition of an RIR by ICANN that RIR shall receive a /12 > from > > the reservation set aside for that RIR. > > > > > > 4. Subsequent Allocation. > > > > An RIR shall be eligible for an allocation of at least a minimal > allocation > > from the IANA when its current holdings are less than 50% of its 18 > month > > requirement or when it has less than 180 days of holdings available. > The > > IANA shall evaluate the requested allocation using a set of > administrative > > procedures that are mutually agreed to by the IANA and the NRO. This > set of > > procedures shall be enacted within 30 days of the implentation of this > > policy. > > > > > > 5. Announcement of IANA allocations to the RIRs > > > > When address space is allocated to a RIR, the IANA will send a detailed > > announcement to the receiving RIR. The IANA will also make announcements > to > > all other RIRs, informing them of the recent allocation. > > > > The IANA will make appropriate modifications to the "Internet Protocol > V6 > > Address Space" page of the IANA website and may make announcements to > only > > its own global announcement lists. The IANA announcements will be > limited > > to which address ranges, the time of allocation and to which Registry > they > > have been allocated. > > > > > > 8. Rationale: > > > > The current IANA allocation policy for IPv6 is an interim policy that > was > > promulgated in 1999. Operational experience has demonstrated the > current > > minimum allocation size is too small; that the built in reservation > system > > that must be followed by the RIRs does not allow for efficient and > effective > > management of the resource by the RIR; and does not provide for an well > > known evaluation criteria. This document does not stipulate performance > > requirements in the provision of services by IANA to an RIR in > accordance > > with the policy. Such requirements should be specified by appropriate > > agreements between the NRO and ICANN. > > > > > > 9. Timetable for implementation: Thirty days after ratification by the > ICANN > > Board of Directors in accordance with the global policy development > process > > _______________________________________________ From gert at space.net Fri Aug 20 14:02:13 2004 From: gert at space.net (Gert Doering) Date: Fri, 20 Aug 2004 14:02:13 +0200 Subject: [ipv6-wg@ripe.net] Re: [address-policy-wg] Re: IANA to RIR IPv6 Allocation In-Reply-To: <00A36A45.014A4C38.6@cc.univie.ac.at> References: <00A36A45.014A4C38.6@cc.univie.ac.at> Message-ID: <20040820120213.GM467@Space.Net> Hi, On Fri, Aug 20, 2004 at 01:49:40PM +0200, Wilfried Woeber, UniVie/ACOnet wrote: > My proposal would be that IANA would have to perform the subsequent > allocation within this 30 day period, even if they might not be able to > obtain advice or an expertise (for whatever reason) from any other party > they might have decided to ask for advice. Seconded. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 65398 (60210) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From s-kawamura at ak.jp.nec.com Fri Aug 20 12:40:46 2004 From: s-kawamura at ak.jp.nec.com (kawamura seiichi) Date: Fri, 20 Aug 2004 19:40:46 +0900 Subject: [ipv6-wg@ripe.net] Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?) In-Reply-To: <20040820073940.GA65077@kb.pinguino.dk> References: <20040820073940.GA65077@kb.pinguino.dk> Message-ID: <20040820194046s-kawamura@mail.jp.nec.com> Greetings, (First time writing to this Mailing list) Are there any temporary solutions to this ip6.int. broken problem? or do we just have to wait until 9/9? Some applications keep asking for ip6.int. and servers not responding cause delays to the application services. Would be very helpful if someone could give me tips. Thank you ----- Seiichi 2004/08/20 09:39:40 +0200?Robert Martin-Leg?e ?????? ?Re: [ipv6-wg at ripe.net] Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?)???????? >On Thu, Aug 19, 2004 at 09:59:51PM +0200, Daniel Roesen wrote: >> Well, two weeks down the road and things got even worse: >> >> NS list summary for ip6.int. from parent (int.) servers >> == flag.ep.net. ns3.nic.fr. y.ip6.int. >> == z.ip6.int. >> >> $ dig @flag.ep.net. int. SOA +norec | fgrep status: >> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 9740 >> $ dig @ns3.nic.fr int. SOA +norec | fgrep status: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 334 >> $ dig @y.ip6.int int. SOA +norec | fgrep status: >> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 17872 >> $ dig @z.ip6.int int. SOA +norec >> ;; connection timed out; no servers could be reached >> >> So we have 3 out of 4 servers totally broken. >> >> Looks like the importance of ip6.int is way overstated by some folks. > >Shouldn't you be asking these servers for ip6.int instead of asking them >for int.? Either way, I seem to be getting the same results. > >For int. itself, it seems that only ns.isi.edu is not authoritative. > >-- Robert Martin-Leg?e > > From dwmalone at maths.tcd.ie Fri Aug 20 13:05:22 2004 From: dwmalone at maths.tcd.ie (David Malone) Date: Fri, 20 Aug 2004 12:05:22 +0100 Subject: [ipv6-wg@ripe.net] Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?) In-Reply-To: <20040820194046s-kawamura@mail.jp.nec.com> References: <20040820073940.GA65077@kb.pinguino.dk> <20040820194046s-kawamura@mail.jp.nec.com> Message-ID: <20040820110522.GA53407@lanczos.maths.tcd.ie> On Fri, Aug 20, 2004 at 07:40:46PM +0900, kawamura seiichi wrote: > (First time writing to this Mailing list) > Are there any temporary solutions to this ip6.int. > broken problem? or do we just have to wait until 9/9? > Some applications keep asking for ip6.int. and > servers not responding cause delays to the application services. If you have access to the C libraries or whatever is generating the lookups, it should be easy enough to edit the source or binary edit the library to look up something else that will fail quickly rather than time out. A cleaner option might be to tell your recursive name server that it is authorititive for ip6.int and give it an empty zone (this is what I do for zones that have problems with AAAA lookups). This prevents it having to time out. David. From s-kawamura at ak.jp.nec.com Fri Aug 20 13:22:40 2004 From: s-kawamura at ak.jp.nec.com (kawamura seiichi) Date: Fri, 20 Aug 2004 20:22:40 +0900 Subject: [ipv6-wg@ripe.net] Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?) In-Reply-To: <20040820110522.GA53407@lanczos.maths.tcd.ie> References: <20040820110522.GA53407@lanczos.maths.tcd.ie> Message-ID: <20040820202240s-kawamura@mail.jp.nec.com> David, Thank you very much! >A cleaner option might be to tell your recursive name server that >it is authorititive for ip6.int and give it an empty zone (this is >what I do for zones that have problems with AAAA lookups). This >prevents it having to time out. I think this is the quickest and the more cleaner answer. I was debating weather to do this or not since it would leave an "odd" record in the nameserver files, but it feels a little bit more warm and fuzzy when I have confirmation :-) thanks again. ------ Seiichi 2004/08/20 12:05:22 +0100?David Malone ?????? ?Re: [ipv6-wg at ripe.net] Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?)???????? >On Fri, Aug 20, 2004 at 07:40:46PM +0900, kawamura seiichi wrote: >> (First time writing to this Mailing list) >> Are there any temporary solutions to this ip6.int. >> broken problem? or do we just have to wait until 9/9? >> Some applications keep asking for ip6.int. and >> servers not responding cause delays to the application services. > >If you have access to the C libraries or whatever is generating the >lookups, it should be easy enough to edit the source or binary edit >the library to look up something else that will fail quickly rather >than time out. > >A cleaner option might be to tell your recursive name server that >it is authorititive for ip6.int and give it an empty zone (this is >what I do for zones that have problems with AAAA lookups). This >prevents it having to time out. > > David. > From woeber at cc.univie.ac.at Fri Aug 20 13:49:40 2004 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 20 Aug 2004 13:49:40 +0200 Subject: [ipv6-wg@ripe.net] Re: IANA to RIR IPv6 Allocation Message-ID: <00A36A45.014A4C38.6@cc.univie.ac.at> I've got one comment here on section 7. paragraph 4. "Subsequent Allocation": While the wording might be sufficiently clear for a native speaker by referring to "set of administrative procedures....", I am missing clear guidance for the IANA that there should _not_ be any incentive or responsibilty to consult with other groups, entities or third parties (irrespective of their, say, credibility for e.g. protocol development or technical specifications) which would require extending that 30 day period. My proposal would be that IANA would have to perform the subsequent allocation within this 30 day period, even if they might not be able to obtain advice or an expertise (for whatever reason) from any other party they might have decided to ask for advice. Wilfried ( https://cert.aco.net/ ) _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber at CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ...there's no place like 127.0.0.1 (or ::1/128 ?) From: David Kessens To: Jeroen Massar Date: Fri, 20 Aug 2004 01:48:52 -0700 CC: ipv6-wg at ripe.net Subject: Re: [ipv6-wg at ripe.net] FW: [arin-council] IANA to RIR IPv6 Allocation Jeroen, On Fri, Aug 20, 2004 at 09:25:59AM +0200, Jeroen Massar wrote: > For people not on the arin-council (not likely ;) or the ppml at arin > lists: All policy discussions for the RIPE region are now conducted at the RIPE policy working group maillist: address-policy-wg at ripe.net David Kessens --- > -----Forwarded Message----- > From: "Sweeting, John" > To: 'ppml at arin.net' > Subject: [ppml] FW: [arin-council] IANA to RIR IPv6 Allocation > Date: Thu, 19 Aug 2004 17:36:56 -0400 > > I am submitting the following proposal IAW ARIN's Internet Resource Policy > Evaluation Process. In the interest of all I would like to disclose up front > that the information used to prepare this template was provided by ARIN > staff. > > > ############################################ > Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0 > > 1. Policy Proposal Name: Allocation of IPv6 Address Space by the Internet > Assigned Numbers Authority (IANA) Policy to Regional Internet Registries > > 2. Author > > a. name: John Sweeting > b. email: john.sweeting at teleglobe.com > c. telephone: 703-766-3042 > d. organization: ARIN Advisory Council > > 3. Proposal Version: 1 > > 4. Submission Date: 8/17/04 > > 5. Proposal type: new, global > > 6. Policy term: permanent > > 7. Policy statement: > > 1. Minimum Allocation Size. > > The minimum size of any allocation of IPv6 address space from IANA to an RIR > is prefix length /12. If this address space is not sufficient to meet the > needs of an RIR for a projected 18 month period, IANA shall allocate to that > RIR the address space for which it can provide justification. > > 2. Reservation of Unicast Address space. > > 2.1 IANA. By RFC 3513 the IANA has been allocated the range of IPv6 > addresses beginning at binary value 001 (prefix length /3) for its > allocations of unicast address space. In order to support regional > aggregation of IPv6 address space IANA shall establish a reservation of a > prefix length of /6 from this space for each established RIR and for each > emerging RIR. Allocations to each RIR will be from the appropriate > reservation. > > 2.2. RIRs. Each RIR may apply its own respective chosen allocation and > reservation strategy in order to meet the needs of its community and to > ensure the efficiency and efficacy of its work. Such reservations made by > an RIR will be considered as being allocated by that RIR when that RIR > applies for an allocation of address space from the IANA. > > 3. Initial Allocation. > > 3.1. Upon implementation of this policy IANA shall allocate to each > established RIR a /12 from the reservation established for each particular > RIR. > > 3.2. Upon recognition of an RIR by ICANN that RIR shall receive a /12 from > the reservation set aside for that RIR. > > > 4. Subsequent Allocation. > > An RIR shall be eligible for an allocation of at least a minimal allocation > from the IANA when its current holdings are less than 50% of its 18 month > requirement or when it has less than 180 days of holdings available. The > IANA shall evaluate the requested allocation using a set of administrative > procedures that are mutually agreed to by the IANA and the NRO. This set of > procedures shall be enacted within 30 days of the implentation of this > policy. > > > 5. Announcement of IANA allocations to the RIRs > > When address space is allocated to a RIR, the IANA will send a detailed > announcement to the receiving RIR. The IANA will also make announcements to > all other RIRs, informing them of the recent allocation. > > The IANA will make appropriate modifications to the "Internet Protocol V6 > Address Space" page of the IANA website and may make announcements to only > its own global announcement lists. The IANA announcements will be limited > to which address ranges, the time of allocation and to which Registry they > have been allocated. > > > 8. Rationale: > > The current IANA allocation policy for IPv6 is an interim policy that was > promulgated in 1999. Operational experience has demonstrated the current > minimum allocation size is too small; that the built in reservation system > that must be followed by the RIRs does not allow for efficient and effective > management of the resource by the RIR; and does not provide for an well > known evaluation criteria. This document does not stipulate performance > requirements in the provision of services by IANA to an RIR in accordance > with the policy. Such requirements should be specified by appropriate > agreements between the NRO and ICANN. > > > 9. Timetable for implementation: Thirty days after ratification by the ICANN > Board of Directors in accordance with the global policy development process _______________________________________________ From iljitsch at muada.com Fri Aug 20 14:38:22 2004 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 20 Aug 2004 14:38:22 +0200 Subject: [ipv6-wg@ripe.net] RE: [address-policy-wg] Re: IANA to RIR IPv6 Allocation In-Reply-To: <20040820120128.25489CF39E@mercury.arin.net> References: <20040820120128.25489CF39E@mercury.arin.net> Message-ID: On 20-aug-04, at 14:01, Ray Plzak wrote: > Wilfried, > I've forwarded your comment to the ARIN ppml. Ray, as long as you're forwarding, maybe you'll find my comment to the RIPE list from a week and a half ago of interest: > The Number Resource Organisation (NRO) has published a proposal for a > policy for the allocation of IPv6 address space from the IANA to the > RIRs. It is intended that this proposed policy should be agreed by all > RIRs' open policy fora and then approved by the ASO and ICANN as a > global policy. Reserving a /6 for each RIR seems like the other extreme to me. In IPv4 we have around 220 /8s that have been given out to RIRs pretty much one at a time in the past. In IPv6 we effectively have 8 /6s. This means that as a percentage of total available space, the RIRs get more than 25 times more IPv6 space than they've been given IPv4 space in the past, even though a v4 /8 will accommodate at most 16.8M end-user assignments (less in practice) while a v6 /6 allows for AT LEAST 4.4T (yes, that's 10^12) end-user assignments. Now I can see SOME value in trying to have relatively large RIR blocks, but cutting up all non-reserved space so aggressively really doesn't have any upsides, and we never know whether we're going to need any really large blocks in the future. Also, doubling every time is ok for a while, but it pretty much guarantees that you're going to have way too much space on your hands at some point. A more reasonable policy would be: - reserve a /12 for each RIR now (a 4 bit boundary makes DNS delegations easier, I think a /8 is too much but that might work also) - then, for every delegation, give RIRs enough space to each to last a year comfortably - evaluate whether a new delegation is needed every 3 or 4 months, making the time of new delegations easy to predict From jeroen at unfix.org Fri Aug 20 14:12:28 2004 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 20 Aug 2004 14:12:28 +0200 Subject: [ipv6-wg@ripe.net] FW: [arin-council] IANA to RIR IPv6 Allocation In-Reply-To: <20040820114159.2760CCF39E@mercury.arin.net> References: <20040820114159.2760CCF39E@mercury.arin.net> Message-ID: <1093003948.3056.156.camel@segesta.zurich.ibm.com> On Fri, 2004-08-20 at 13:41, Ray Plzak wrote: > Jeroen, > > Before you comments about the ARIN policy process I suggest you read: > http://www.arin.net/policy/ipep.html As I mentioned in the mail, I made an assumption based on the fact that the original post was already a forward from a closed list. Everywhere things happen behind closed doors and then come forward. If everything was discussed in public the latency of things would be even bigger. The policy outlined above is fine by me ;) > Lastly, I invite you to participate in the discussion on the ARIN ppml. > Your participation and that of anyone, anywhere in the world is most > welcome. One does not need to be a member of ARIN to participate. Of > course the ARIN meeting is an open meeting. It is open to anyone in the > world who wishes to participate in the policy process. Which is why I forwarded the message to the ipv6-wg at ripe list so that people not following the ppml at arin list know that in the ARIN region action was being taken to get forward with the proposals. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part URL: From plzak at arin.net Fri Aug 20 19:57:39 2004 From: plzak at arin.net (Ray Plzak) Date: Fri, 20 Aug 2004 13:57:39 -0400 Subject: [ipv6-wg@ripe.net] RE: [address-policy-wg] Re: IANA to RIR IPv6 Allocation In-Reply-To: Message-ID: <20040820175740.9E161CF39E@mercury.arin.net> Iljitsch, While your comments do not address the policy proposed on the ARIN list there are some elements in your comments that may be relevant to the discussion on the ppml. I will soon forward it. In regard to your comments I have an observation with regard to the amount of IPv4 address space that has been allocated to the RIRs. It is worth noting that the RIRs have not been allocated "around 220" /8s. In fact, the vast majority of IPv4 address allocations pre-date the formation of the RIRs. These allocations were either made by the Central Registry (94 /8s) or the IETF (32 /8s*. This is the old classful D and E space. Some may choose to consider the old classful E space as an IANA reserve). The RIRs have had 50 /8 blocks allocated to them by the IANA. This is just under 20% of the total IPv4 address space. Ray > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch at muada.com] > Sent: Friday, August 20, 2004 8:38 AM > To: Ray Plzak > Cc: ; > Subject: Re: [ipv6-wg at ripe.net] RE: [address-policy-wg] Re: IANA to RIR > IPv6 Allocation > > On 20-aug-04, at 14:01, Ray Plzak wrote: > > > Wilfried, > > > I've forwarded your comment to the ARIN ppml. > > Ray, as long as you're forwarding, maybe you'll find my comment to the > RIPE list from a week and a half ago of interest: > > > > The Number Resource Organisation (NRO) has published a proposal for a > > policy for the allocation of IPv6 address space from the IANA to the > > RIRs. It is intended that this proposed policy should be agreed by all > > RIRs' open policy fora and then approved by the ASO and ICANN as a > > global policy. > > Reserving a /6 for each RIR seems like the other extreme to me. In IPv4 > we have around 220 /8s that have been given out to RIRs pretty much one > at a time in the past. In IPv6 we effectively have 8 /6s. This means > that as a percentage of total available space, the RIRs get more than > 25 times more IPv6 space than they've been given IPv4 space in the > past, even though a v4 /8 will accommodate at most 16.8M end-user > assignments (less in practice) while a v6 /6 allows for AT LEAST 4.4T > (yes, that's 10^12) end-user assignments. > > Now I can see SOME value in trying to have relatively large RIR blocks, > but cutting up all non-reserved space so aggressively really doesn't > have any upsides, and we never know whether we're going to need any > really large blocks in the future. Also, doubling every time is ok for > a while, but it pretty much guarantees that you're going to have way > too much space on your hands at some point. > > A more reasonable policy would be: > > - reserve a /12 for each RIR now (a 4 bit boundary makes DNS > delegations easier, I think a /8 is too much but that might work also) > - then, for every delegation, give RIRs enough space to each to last a > year comfortably > - evaluate whether a new delegation is needed every 3 or 4 months, > making the time of new delegations easy to predict From iljitsch at muada.com Fri Aug 20 23:15:52 2004 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 20 Aug 2004 23:15:52 +0200 Subject: [ipv6-wg@ripe.net] RE: [address-policy-wg] Re: IANA to RIR IPv6 Allocation In-Reply-To: <20040820175740.9E161CF39E@mercury.arin.net> References: <20040820175740.9E161CF39E@mercury.arin.net> Message-ID: <1DF8EA1E-F2EE-11D8-A5BE-000A95CD987A@muada.com> On 20-aug-04, at 19:57, Ray Plzak wrote: > While your comments do not address the policy proposed on the ARIN list Hm, I thought this was an IANA thing so it must be the same world wide? > In regard to your comments > I have an observation with regard to the amount of IPv4 address space > that > has been allocated to the RIRs. It is worth noting that the RIRs have > not > been allocated "around 220" /8s. Upon rereading it turns out the words didn't come out as I intended. What I meant to say was that there are some 220 /8s in total that may serve as global IPv4 unicast address space, and in the past the RIRs would get one /8 at a time, or about 0.45% of the available address space at a time. The proposed IPv6 policy wants to allocate /6s to the RIRs, which is 12.5% of the currently available global IPv6 unicast space. Now if 0.45% was workable for 10 years in IPv4, I don't see why 12.5% would be necessary in IPv6. Obviously there is some hidden goal that will be met by this policy. I think that before this policy is adopted this goal should be made explicit and there should be consensus that this is indeed an important goal. From randy at psg.com Sat Aug 21 06:04:20 2004 From: randy at psg.com (Randy Bush) Date: Fri, 20 Aug 2004 21:04:20 -0700 Subject: [ipv6-wg@ripe.net] Re: [address-policy-wg] Re: IANA to RIR IPv6 Allocation References: <00A36A45.014A4C38.6@cc.univie.ac.at> Message-ID: <16678.51652.603144.754837@ran.psg.com> > My proposal would be that IANA would have to perform the subsequent > allocation within this 30 day period, even if they might not be able to > obtain advice or an expertise (for whatever reason) from any other party > they might have decided to ask for advice. sure, if we can we do the same for rir to lir From dr at cluenet.de Tue Aug 24 00:42:27 2004 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 24 Aug 2004 00:42:27 +0200 Subject: [ipv6-wg@ripe.net] DNS Weather Report 2004-08-24 Message-ID: <20040823224227.GA10020@srv01.cluenet.de> DNS WEATHER REPORT for selected infrastructure zones ==================================================== Issue 2004-08-24 Zones analyzed and their SOA contacts: - . nstld at verisign-grs.com - arpa. nstld at verisign-grs.com - int. noc at icann.org - in-addr.arpa bind at arin.net - ip6.arpa. hostmaster at icann.org - ip6.int. hostmaster at ep.net Executive summary: not a single zone without any problems, but ip6.int situation improved significantly. The state of the root zone =========================== - m.root-servers.net is lagging behind the others... general SOA serial is 2004082201, m.root has 2004082101 The state of the ARPA zone ========================== - same SOA serial problem as in the root zone, m.root out-of-sync. Interestingly, all the same SOA serial numbers as the root zone (coincidence?) The state of the INT zone ========================= - in-zone NS RRset doesn't match the delegation NS RRset. in-zone RRset: delegation RRset: ns0.ja.net. ns0.ja.net. ns1.cs.ucl.ac.uk. ns1.cs.ucl.ac.uk. ns.icann.org. ns.icann.org. ns.isi.edu. ns.isi.edu. ns.uu.net. ns.uu.net. ns.ripe.net. z.ip6.int. - ns.isi.edu started to be auth again (was lame a few days ago), but is not in sync. current SOA serial of the INT TLD: 2004080300, ns.isi.edu has 2002080104 The state of the IN-ADDR.ARPA zone ================================== - same problem with m.root as with the root zone. m.root seems to lag exactly one day behind, judging from the SOA serial number. The state of the IP6.ARPA zone ============================== - in-zone NS RRset doesn't match the delegation NS RRset. in-zone RRset: delegation RRset: ns.apnic.net. ns.apnic.net. ns.icann.org. ns.icann.org. ns-sec.ripe.net. ns.ripe.net. tinnie.arin.net. tinnie.arin.net. Problem known, RIPE sent a reminder to ip6.arpa operators a week ago, obviously without any outcome. The state of the IP6.INT zone ============================= - ns.isi.edu (one of the INT TLD servers) feels authoritative for the IP6.INT zone, but is neither listed in the delegation NS RRset, nor in the in-zone NS RRset of IP6.INT. Luckily, ns.isi.edu carries ip6.int with the same SOA serial as the official servers, so introduces no operational problems so far. Regards, Daniel From iljitsch at muada.com Tue Aug 24 09:47:09 2004 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 24 Aug 2004 09:47:09 +0200 Subject: [ipv6-wg@ripe.net] RE: [address-policy-wg] Re: IANA to RIR ipv6 Allocation In-Reply-To: <412AAC7E.71BA62F6@ix.netcom.com> References: <20040820120128.25489CF39E@mercury.arin.net> <412AAC7E.71BA62F6@ix.netcom.com> Message-ID: On 24-aug-04, at 4:48, Jeff Williams wrote: > Iljitsch and all, ^^^^^ No kidding... > None of this addresses the outstanding problems with Ipv6 or ipv6 > allocation concerns and existing as well as discussed problems. > They are "at least" the following: I don't think I get what you're talking about. > 1. ) Invalid or incorrect minimal allocation. What is invalid or incorrect here? > 2.) Still existing cost increases for allocations. What cost? > 3.) Still existing security/privacy "holes" in ipv6 What holes? There is no difference with IPv4. > 4.) Routing notification for new allocation practice or method. What on Earth is a "routing notification"? > 5.) Routing table maintenance Best practices and/or policy, Well, there is some of this but since the RIRs seem to have trouble living up to their own policies this is problematic. (See http://www.bgpexpert.com/archive2003q4.php ) > and enforcement of same. Yes, we don't do this in the internet. (And go fix the IPv4 table first if you feel so inclined.) > 6.) Dealing with "Dark" existing and/or future allocated addresses. Again, I have no idea what you're talking about. Now if we could have a mechanism to determine resolving DNS servers automatically in IPv6 and have visible IPv6 addresses for the root DNS servers we'd be well on our way. And of course we still need multihoming in IPv4 and the IETF has to quit rewriting the RFCs all the time. > Iljitsch van Beijnum wrote: I know what I wrote, so P L E A S E don't repeat it in its entirety!!! I'm really getting sick and tired of people who are too lazy to quote in a decent manner. From woeber at cc.univie.ac.at Wed Aug 25 16:50:10 2004 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 25 Aug 2004 16:50:10 +0200 Subject: [ipv6-wg@ripe.net] Re: [address-policy-wg] Re: IANA to RIR IPv6 Allocation Message-ID: <00A36E4C.0C67B938.11@cc.univie.ac.at> >> My proposal would be that IANA would have to perform the subsequent >> allocation within this 30 day period, even if they might not be able to >> obtain advice or an expertise (for whatever reason) from any other party >> they might have decided to ask for advice. > >sure, if we can we do the same for rir to lir No problem with that, although I don't see the need for global coordination here. To me this sounds like a RIR-Customer service-contract aspect. Wilfried. From dr at cluenet.de Tue Aug 31 18:16:39 2004 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 31 Aug 2004 18:16:39 +0200 Subject: [ipv6-wg@ripe.net] DNS Weather Report 2004-08-24 Message-ID: <20040831161639.GA5458@srv01.cluenet.de> DNS WEATHER REPORT for selected infrastructure zones ==================================================== Issue 2004-08-31 Zones analyzed and their SOA contacts: - . - arpa. nstld at verisign-grs.com - int. noc at icann.org - in-addr.arpa bind at arin.net - ip6.arpa. hostmaster at icann.org - ip6.int. hostmaster at ep.net [Operators: please let me know wether you do want a copy when there's no problem with your zone(s) or not. Don't want to annoy anyone unnecessarily!] Executive summary: * m.root out-of-sync problem got fixed within one hour after I've sent out report 2004-08-24. Thanks WIDE! * The INT problem with the non-matching NS RRset (in-zone and delegation) was also fixed. Unfortunately ns.isi.edu is _still_ out of sync. * The IP6.ARPA NS RRset discrepancy got worse over the last week. * ns.isi.edu is _still_ auth for IP6.INT where it shouldn't be. The state of the root zone =========================== fine! The state of the ARPA zone ========================== fine! The state of the INT zone ========================= - ns.isi.edu is not in sync with the other nameservers Current SOA serial of the INT TLD: 2004082300, ns.isi.edu has still 2002080104 and is publishing stale data (e.g. an old NS RRset for the zone). Problem exists since at least 2004-08-24 The state of the IN-ADDR.ARPA zone ================================== fine! The state of the IP6.ARPA zone ============================== - in-zone NS RRset doesn't match the delegation NS RRset. in-zone RRset: delegation RRset: ---------------- ----------------- ns.apnic.net. ns.apnic.net. ns.icann.org. ns.icann.org. ns-sec.ripe.net. ns.ripe.net. tinnie.arin.net. tinnie.arin.net. ns.lacnic.net. Problem known, RIPE sent a reminder to ip6.arpa operators two weeks ago, obviously without any outcome. Since the last DNS weather report last week, ns.lacnic.net. was added. Looks like now at least two change requests for the ip6.arpa delegation are pending. Problem exists since in various degrees since at least 2004-08-24 The state of the IP6.INT zone ============================= - ns.isi.edu (one of the INT TLD servers) feels authoritative for the IP6.INT zone, but is neither listed in the delegation NS RRset, nor in the in-zone NS RRset of IP6.INT. Luckily, ns.isi.edu carries ip6.int with the same SOA serial as the official servers, so induces no operational problems so far. Problem exists since at least 2004-08-24 Regards, Daniel From dr at cluenet.de Tue Aug 31 18:17:33 2004 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 31 Aug 2004 18:17:33 +0200 Subject: [ipv6-wg@ripe.net] DNS Weather Report 2004-08-31 Message-ID: <20040831161733.GA8908@srv01.cluenet.de> [sorry! resent, wrong subject date!] DNS WEATHER REPORT for selected infrastructure zones ==================================================== Issue 2004-08-31 Zones analyzed and their SOA contacts: - . - arpa. nstld at verisign-grs.com - int. noc at icann.org - in-addr.arpa bind at arin.net - ip6.arpa. hostmaster at icann.org - ip6.int. hostmaster at ep.net [Operators: please let me know wether you do want a copy when there's no problem with your zone(s) or not. Don't want to annoy anyone unnecessarily!] Executive summary: * m.root out-of-sync problem got fixed within one hour after I've sent out report 2004-08-24. Thanks WIDE! * The INT problem with the non-matching NS RRset (in-zone and delegation) was also fixed. Unfortunately ns.isi.edu is _still_ out of sync. * The IP6.ARPA NS RRset discrepancy got worse over the last week. * ns.isi.edu is _still_ auth for IP6.INT where it shouldn't be. The state of the root zone =========================== fine! The state of the ARPA zone ========================== fine! The state of the INT zone ========================= - ns.isi.edu is not in sync with the other nameservers Current SOA serial of the INT TLD: 2004082300, ns.isi.edu has still 2002080104 and is publishing stale data (e.g. an old NS RRset for the zone). Problem exists since at least 2004-08-24 The state of the IN-ADDR.ARPA zone ================================== fine! The state of the IP6.ARPA zone ============================== - in-zone NS RRset doesn't match the delegation NS RRset. in-zone RRset: delegation RRset: ---------------- ----------------- ns.apnic.net. ns.apnic.net. ns.icann.org. ns.icann.org. ns-sec.ripe.net. ns.ripe.net. tinnie.arin.net. tinnie.arin.net. ns.lacnic.net. Problem known, RIPE sent a reminder to ip6.arpa operators two weeks ago, obviously without any outcome. Since the last DNS weather report last week, ns.lacnic.net. was added. Looks like now at least two change requests for the ip6.arpa delegation are pending. Problem exists since in various degrees since at least 2004-08-24 The state of the IP6.INT zone ============================= - ns.isi.edu (one of the INT TLD servers) feels authoritative for the IP6.INT zone, but is neither listed in the delegation NS RRset, nor in the in-zone NS RRset of IP6.INT. Luckily, ns.isi.edu carries ip6.int with the same SOA serial as the official servers, so induces no operational problems so far. Problem exists since at least 2004-08-24 Regards, Daniel