From jeroen at unfix.org Mon Oct 3 19:14:32 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 03 Oct 2005 19:14:32 +0200 Subject: [ipv6-wg] Draft Agenda (v1) for ipv6 wg RIPE51 In-Reply-To: <8C85E76AEF28F048ADAAE13FAD59A4D7A9200A@SEHAN012MB.tcad.telia.se> References: <8C85E76AEF28F048ADAAE13FAD59A4D7A9200A@SEHAN012MB.tcad.telia.se> Message-ID: <1128359672.3183.9.camel@firenze.zurich.ibm.com> On Mon, 2005-10-03 at 18:59 +0200, Mattias.Lignell at teliasonera.com wrote: > Hello all, > > About the /32's; they are announced on purpose. The reason is that we > have had problems with some ISP's BGP filters that are set to a maximum > size of /32. As a result did not our IPv6 customers get connectivity via > ISP's using the /32 size filters. Maybe this is a problem only we run in > to being one of the first using a very large prefix. However, the BGP > filters may be updated by now so we can stop announcing the /32's. Thanks for the response, the prefix filtering is not too good to hear and has been seen before; I know that Daniel Roesen has been very busy trying to get C&W's /20 available to ISP's using, amongst others, the output from: http://www.sixxs.net/tools/grh/compare/?a=2001:5000::/21&b=2001:650::/32 At the moment apparently Cisco doesn't see the /21... This can be easily applied to Telia's /20: http://www.sixxs.net/tools/grh/compare/?a=2001:2000::/20&b=2001:2040::/32 This compares 2001:2000::/20 with 2001:2040::/32. Taking a quick look it looks quite good, ignoring the light orange which is there because of the added ASN. There are only few ISP's who report different paths: AS 6435 - LavaNet (us / Hawaii) AS 9264 - Academic Services Network (tw) AS21155 - Proserve (nl) AS28788 - Unilogic (nl) {using same upstreams as AS21155) You might want to contact these ISP's to ask them + upstreams to fix their filtering, clearly something is being filtered, otherwise the paths where the same. 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 Mattias.Lignell at teliasonera.com Mon Oct 3 18:59:35 2005 From: Mattias.Lignell at teliasonera.com (Mattias.Lignell at teliasonera.com) Date: Mon, 3 Oct 2005 18:59:35 +0200 Subject: [ipv6-wg] Draft Agenda (v1) for ipv6 wg RIPE51 Message-ID: <8C85E76AEF28F048ADAAE13FAD59A4D7A9200A@SEHAN012MB.tcad.telia.se> Hello all, About the /32's; they are announced on purpose. The reason is that we have had problems with some ISP's BGP filters that are set to a maximum size of /32. As a result did not our IPv6 customers get connectivity via ISP's using the /32 size filters. Maybe this is a problem only we run in to being one of the first using a very large prefix. However, the BGP filters may be updated by now so we can stop announcing the /32's. Please note that this has been a temporary work around to maintain connectivity for our customers. We also have old prefixes that we are about to return to RIPE (2001:06C0::/35), but not yet had time to shout down (affects many customers and links). It is of-cause the policy of the TeliaSonera group to normally only announce one prefix. Any comments to this are most welcome. Best regards /// Mattias Lignell -------------------------------------------------------------- Mattias Lignell TeliaSonera Sweden, IP-Networks Phone: +46 8 713 3706 Mobile: +46 70 595 9068 Fax: +46 70 615 6245 Email: mattias.lignell at teliasonera.com Address: Vitsandsgatan 9, House-D, 123 86 Farsta, SWEDEN ICQ UIN: 18690075 -------------------------------------------------------------- > ------------------------------------------------------------- > ----- Original Message ----- > From: "Jeroen Massar" > To: "Gert Doering" ; "David Kessens" > > Cc: "Amar Andersson" ; > Sent: Friday, September 30, 2005 3:06 PM > Subject: Re: [ipv6-wg] Draft Agenda (v1) for ipv6 wg RIPE51 > > On Thu, 2005-09-29 at 20:46 -0700, David Kessens wrote: One discussion point you might want to raise: - what are people going to do with 6bone address space as per 6/6/6 ? - filter it? - keep it going? - warn people? In january I will send out a note to all the folks still announcing 6bone prefixes to remind them that they should be shutting it down per 6/6/6. There doesn't seem to be a large movement in doing so yet... > C. Discussion on: > Global IPv6 routing table status > (Gert Doering) Maybe something related might be noted here, in the global routing tables I've seen for instance, just a 'random' targetted pick. http://www.sixxs.net/tools/grh/lg/?find=2001:2000::/20 [Notez bien: the question here is about what is going to become the common policy and what is going to happen to the ipv6 routing, it is not to 'attack' or critize an ISP on what they are doing] 2001:2000::/20 announced by AS1299 (TELIANET) 2001:2040::/32 AS3301 (TELIA-SWEDEN) 2001:2060::/32 AS1759 (SONERA-TRANSIT-AS) No route6 for these 3 prefixes and no inet6nums exist for the the two /32's. Which leads me to a couple of questions: - is it mandatory to register route6's and inet6num's or is it just 'being nice' - is the trend going to be that >/32's will be announced as separate /32's? This of course means that the ISP can be found under one block but still affects the number of routes in the routing table. One could filter the smaller ones if the parent route is present. The idea of minimizing routing table size (yes that is not an issue now, but behold the future) is totally gone when ISP's will do this. I do understand why: to make the branches independant and attract the traffic as local as possible. On the otherside there are also ISP's simply requesting multiple separate /32's from the various RIR's. eg UUNet: 2001:0600::/32 - Europe 2001:4440::/32 - Hongkong 2001:4441::/32 - Australia 2001:4442::/32 - Japan 2001:0588::/32 - South Africa (I am ignoring the 6bone block they still have, with 1 other already returned, as that one will disappear anyway) The question in case of this setup is, why didn't they get 1 block? The generic question: what is the correct plan for these setups? > D. Report(s) about *actual* v6 traffic volume as compared to v4? > *what's real* out there, not what's on powerpoint? > (input from the audience) http://www.sixxs.net/misc/traffic/ :) Not much, but it is a bit and for the moment declining a bit weirdly enough. > For example, address fragmentation, a key problem in IPv4, degrades > address lookup performance in routers. Thus, a well-designed > address allocation policy needs to minimise fragmentation while > using the address space efficiently. See my related note above. Greets, Jeroen From Mattias.Lignell at teliasonera.com Mon Oct 3 19:26:39 2005 From: Mattias.Lignell at teliasonera.com (Mattias.Lignell at teliasonera.com) Date: Mon, 3 Oct 2005 19:26:39 +0200 Subject: [ipv6-wg] Draft Agenda (v1) for ipv6 wg RIPE51 Message-ID: <8C85E76AEF28F048ADAAE13FAD59A4D7A9200B@SEHAN012MB.tcad.telia.se> Hello again, I will have a second look at this and discuss the issue internally. I sure hope we can remove the /32's. /// Mattias > -----Original Message----- > From: Jeroen Massar [mailto:jeroen at unfix.org] > Sent: Monday, October 03, 2005 7:15 PM > To: Lignell, Mattias E. > Cc: gert at space.net; david.kessens at nokia.com; eva at telia.net; > Lind, Mikael E.; amar at telia.net; ipv6-wg at ripe.net > Subject: RE: [ipv6-wg] Draft Agenda (v1) for ipv6 wg RIPE51 > > On Mon, 2005-10-03 at 18:59 +0200, Mattias.Lignell at teliasonera.com > wrote: > > Hello all, > > > > About the /32's; they are announced on purpose. The reason > is that we > > have had problems with some ISP's BGP filters that are set to a > > maximum size of /32. As a result did not our IPv6 customers get > > connectivity via ISP's using the /32 size filters. Maybe this is a > > problem only we run in to being one of the first using a very large > > prefix. However, the BGP filters may be updated by now so > we can stop announcing the /32's. > > Thanks for the response, the prefix filtering is not too good > to hear and has been seen before; I know that Daniel Roesen > has been very busy trying to get C&W's /20 available to ISP's > using, amongst others, the output from: > http://www.sixxs.net/tools/grh/compare/?a=2001:5000::/21&b=200 > 1:650::/32 > At the moment apparently Cisco doesn't see the /21... > > This can be easily applied to Telia's /20: > http://www.sixxs.net/tools/grh/compare/?a=2001:2000::/20&b=200 > 1:2040::/32 > > This compares 2001:2000::/20 with 2001:2040::/32. > Taking a quick look it looks quite good, ignoring the light > orange which is there because of the added ASN. There are > only few ISP's who report different paths: > AS 6435 - LavaNet (us / Hawaii) > AS 9264 - Academic Services Network (tw) > AS21155 - Proserve (nl) > AS28788 - Unilogic (nl) {using same upstreams as AS21155) > > You might want to contact these ISP's to ask them + upstreams > to fix their filtering, clearly something is being filtered, > otherwise the paths where the same. > > Greets, > Jeroen > > From david.kessens at nokia.com Wed Oct 5 06:56:08 2005 From: david.kessens at nokia.com (David Kessens) Date: Tue, 4 Oct 2005 21:56:08 -0700 Subject: [ipv6-wg] Draft Agenda (v2) for ipv6 wg RIPE51 Message-ID: <20051005045608.GA7500@nokia.com> Please see below for the draft agenda (v2) of the ipv6 working group. We still have some room in the agenda so let me know if there is anything that you would like to discuss. As mentioned before, I would also like to draw your attention to the plenary part of the meeting that has various interesting ipv6 presentations on the agenda (see below). David Kessens --- Draft Agenda (v2) for the IPv6 Working Group Meeting RIPE51 When: Wednesday, October 12, 2005, 17:00-18:00 Where: Grand Ballroom, Hotel Krasnapolsky, Amsterdam A. Administrative stuff - appointment of scribe - agenda bashing (David Kessens) B. Quick update from the RIPE NCC regarding ipv6 services (RIPE NCC) C. IPv6 events calendar on the ipv6 working group page (proposed by Timothy Lowe) D. Discussion on: Global IPv6 routing table status (Gert Doering) routing policy: - is it mandatory to register route6's and inet6num's or is it just 'being nice' ? - is the trend going to be that >/32's will be announced as separate /32's? what is the correct plan for shorter than /32 prefixes ? E. Report(s) about *actual* v6 traffic volume as compared to v4? *what's real* out there, not what's on powerpoint? - http://www.sixxs.net/misc/traffic/ (Jeroen Massar) - ... (input from the audience) F. The end of the 6bone address space is in sight (Jeroen Massar) Discussion: - what are people going to do with 6bone address space as per 6/6/6 ? - filter it? - keep it going? - warn people? - what to do with the 6bone registry ? G. Developments/initiatives regarding IPv6 in the RIPE region and beyond - 6DISS (Bernard Tuy) - ... (input from the audience) H. Input for the RIPE NCC Activity Plan (input from the audience) Z. AOB --- Interesting topics in the plenary section: TUESDAY 09:00 - 10:30 6. IPv6 Routing Update. Gert Doering. Spacenet (20 min) Update on observations on the state of the IPv6 default free routing table. 7. IPv6 Multihoming Status. Kurtis Lindqvist. Netnod (30 min) An up-to-date status report on the progress towards scalable IPv6 multihoming. 8. IPv6 Address Allocation --An Alternative Algorithm for the Sparse Allocation Process. Mae Wang (30 min) IP address allocation policies significantly impact the Internet infrastructure, affecting many parties such as router manufacturers, ISPs, and end users. An address allocation policy can also directly affect the performance of the Internet. For example, address fragmentation, a key problem in IPv4, degrades address lookup performance in routers. Thus, a well-designed address allocation policy needs to minimise fragmentation while using the address space efficiently. This paper attempts to quantify the performance of address allocation policies by modelling key features that lead to fragmentation and inefficient address space usage. Our main contributions are: (i) we identify a drawback of the current IPv6 address allocation policy, which treats all entities uniformly, (ii) we propose a scheme that takes future growth rate into account for allocations, and (iii) an analytical model for measuring the efficiency of allocation schemes, allowing us to quantify the improvement our proposal offers over the current scheme. We believe that a quantitative study of allocation policies is timely since IPv6 address allocation is just beginning in earnest. From mare.ramljak at gmail.com Thu Oct 6 21:33:20 2005 From: mare.ramljak at gmail.com (marko ramljak) Date: Thu, 6 Oct 2005 21:33:20 +0200 Subject: [ipv6-wg] Re: [6bone] RIPE and IPv6 ASN Message-ID: <3aab1e500510061233l147c65f2y@mail.gmail.com> On Tue, 15 Oct 2002, Arien Vijn wrote: > On 15-10-2002 17:00PM, "Nicolas DEFFAYET" wrote: > > > On Tue, 2002-10-15 at 16:33, Bill Manning wrote: > >> % My company created the first french > >> % IPv6 Internet Exchange, FNIX6 (http://www.fnix6.net) but my company > >> % can't peer on FNIX6 becase we don't have public ASN. > >> > >> this is not the first v6 enabled exchange in France. > >> there are three other exchanges which are v6 enabled. > >> > > > > This other Internet Exchange in France are IPv4 and IPv6 Internet > > Exchange (dualstack). > > IPv6 Internet Exchange = IPv6 only > > Why? Is what we are doing not IPv6? > > Arien IPv6 only = Purely IPv6 (no IPv4 legacy stuff!) I've understood it as a marketing issue... :-) Nicolas, about the problem: If you get LIR Status you'll probably get your ASN quickly. Regards, ./Carlos "Networking is fun!" From gert at space.net Fri Oct 7 09:16:22 2005 From: gert at space.net (Gert Doering) Date: Fri, 7 Oct 2005 09:16:22 +0200 Subject: [ipv6-wg] Re: [6bone] RIPE and IPv6 ASN In-Reply-To: <3aab1e500510061233l147c65f2y@mail.gmail.com> References: <3aab1e500510061233l147c65f2y@mail.gmail.com> Message-ID: <20051007071622.GH5931@Space.Net> Hi, On Thu, Oct 06, 2005 at 09:33:20PM +0200, marko ramljak wrote: > Nicolas, about the problem: > If you get LIR Status you'll probably get your ASN quickly. Getting an AS number does not really have anything to do with being a LIR - the key is "qualifying for the criteria for ASN assignments" (and finding a LIR that pays the bill). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From mohacsi at niif.hu Mon Oct 10 13:02:45 2005 From: mohacsi at niif.hu (Mohacsi Janos) Date: Mon, 10 Oct 2005 13:02:45 +0200 (CEST) Subject: [ipv6-wg] IPv6 micro allocation or something else? Message-ID: <20051010124501.S40670@mignon.ki.iif.hu> Dear All, I have a question regarding the IPv6 address assignment to cc level DNS server. If you don't have answer to this question please forward it to an appropriate working group - sorry for cross-posting this mail to two wg. We have here in Hungary a dilemma: - Traditionally, the IPv4 address of the primary cc level DNS server in of belonged to NIIF/HUNGARNET. - The DNS registration service a while ago was delegated to Council of Hungarian Internet Providers (ISZT) who is also operating the biggest Internet Exchange of Hungary (BIX). All big ISPs in Hungary (including NIIF/HUNGARNET) has right to do the registration via a special interface. - The IPv4 address of the primary cc level DNS server announced by NIIF/HUNGARNET. But ISZT is reorganizing its infrastructure to allocate address from a new PI type IPv4 address space to DNS servers. - The primary hu DNS server is connected to BIX - to be well connected. What IPv6 address space should we allocate to hu primary DNS server? 1. Assign IPv6 address from /32 address space of NIIF/HUNGARNET? - not very optimal since the only transit to hu primary will be NIIF/HUNGARNET - not ISP neutral - easy, no problem from point of view of NIIF/HUNGARNET 2. Assign IPv6 address space from /48 allocated to BIX (based on ripe-256 and ripe-310)? - According to the RIPE documents: "Networks assigned under this policy may not be globally routable" - which problematical since primary DNS servers should be globally reachable. 3. Allocate multiple /48 from IPv6 providers in HUNGARY to primary hu DNS server? - This can be problematical since the answers to DNS queries might be quite big. 4. Allocate /48 to primary hu DNS server that is globally routable? Are there similar to /48 from 2001:0500::/30 in RIPE region? - I think this is the cleanest solution. Can we discuss this issue on the working group or mailing lists? I saw a proposal: http://www.ripe.net/ripe/policies/proposals/2005-2.html In my opinion this can solve the problem.... Best Regards, Janos Mohacsi Network Engineer, Research Associate NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 From mohacsi at niif.hu Fri Oct 14 12:32:54 2005 From: mohacsi at niif.hu (Mohacsi Janos) Date: Fri, 14 Oct 2005 12:32:54 +0200 (CEST) Subject: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <20051010124501.S40670@mignon.ki.iif.hu> References: <20051010124501.S40670@mignon.ki.iif.hu> Message-ID: <20051014122508.G77157@mignon.ki.iif.hu> Dear All, I did not see any answers except one from Bill Manning - who was supporting the 4. options. So this means this is the accepted and RIPE reccomended method. Basically allow allocating portable IPv6 address: * root domain name system (DNS) server; * global top level domain (gTLD) nameservers; * country code TLD (ccTLDs) nameservers; When the RIPE policy will reflect this changes? Thanks Regards, Janos Mohacsi Network Engineer, Research Associate NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 On Mon, 10 Oct 2005, Mohacsi Janos wrote: > Dear All, > I have a question regarding the IPv6 address assignment to > cc level DNS server. > > If you don't have answer to this question please forward it to an appropriate > working group - sorry for cross-posting this mail to two wg. > > We have here in Hungary a dilemma: > > - Traditionally, the IPv4 address of the primary cc level DNS server in of > belonged to NIIF/HUNGARNET. > > - The DNS registration service a while ago was delegated to Council of > Hungarian Internet Providers (ISZT) who is also operating the biggest > Internet Exchange of Hungary (BIX). All big ISPs in Hungary (including > NIIF/HUNGARNET) has right to do the registration via a special interface. > > - The IPv4 address of the primary cc level DNS server announced by > NIIF/HUNGARNET. But ISZT is reorganizing its infrastructure to allocate > address from a new PI type IPv4 address space to DNS servers. > > - The primary hu DNS server is connected to BIX - to be well connected. > > > What IPv6 address space should we allocate to hu primary DNS server? > > 1. Assign IPv6 address from /32 address space of NIIF/HUNGARNET? > - not very optimal since the only transit to hu primary will be > NIIF/HUNGARNET > - not ISP neutral - easy, no problem from point of view of NIIF/HUNGARNET > > > 2. Assign IPv6 address space from /48 allocated to BIX (based on ripe-256 and > ripe-310)? > - According to the RIPE documents: "Networks assigned under this policy may > not be globally routable" - which problematical since primary DNS servers > should be globally reachable. > > 3. Allocate multiple /48 from IPv6 providers in HUNGARY to primary hu DNS > server? > - This can be problematical since the answers to DNS queries might be quite > big. > > 4. Allocate /48 to primary hu DNS server that is globally routable? > Are there similar to /48 from 2001:0500::/30 in RIPE region? > > - I think this is the cleanest solution. > > Can we discuss this issue on the working group or mailing lists? > > I saw a proposal: http://www.ripe.net/ripe/policies/proposals/2005-2.html > > In my opinion this can solve the problem.... > > Best Regards, > > > Janos Mohacsi > Network Engineer, Research Associate > NIIF/HUNGARNET, HUNGARY > Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 > > From david.kessens at nokia.com Fri Oct 21 15:01:16 2005 From: david.kessens at nokia.com (David Kessens) Date: Fri, 21 Oct 2005 06:01:16 -0700 Subject: [ipv6-wg] Draft Minutes (v1) of IPv6 WG session RIPE51 Message-ID: <20051021130116.GA3635@nokia.com> Please see enclosed the first version of the minutes of our session at RIPE51. I plan to declare the minutes final if I don't receive any comments for significant changes by November 4th 2005. I would like to thank Timothy Lowe from the RIPE NCC for taking the minutes. David Kessens --- Minutes IPv6 Working Group session Amsterdam, 12 Oct, 2005 Chair: David Kessens Scribe: Timothy Lowe # of attendees: 95 ACTION 51.1 - Ask the RIPE NCC to revise the acronym list in the registration package to remove obsolete terms as TLA & NLA (David Kessens) Status: Completed ACTION 51.2 - Create a link from the IPv6 WG page to the APNIC events page: http://apnic.net/info/calendar/index.html (RIPE NCC) Status: To be done ACTION 51.3 - Provide traffic reports on ipv6 usage during the RIPE meetings. If available, data from earlier meetings will be made available as well. (RIPE NCC) A. Administrative stuff Appointment of scribe: Timothy Lowe Agenda bashing: No additions to agenda Action point 51.1 was decided. B. Quick update from the RIPE NCC regarding ipv6 services (RIPE NCC) No news from the RIPE NCC C. IPv6 events calendar on the ipv6 working group page (proposed by Timothy Lowe) It was decided that similar event pages already exist and that we can simply provide a link to the APNIC event pages. (See action point D. Discussion on: Global IPv6 routing table status (Gert Doering, Spacenet) Discussion on filtering: Gert Doering: The RIPE Whois database is the only one allowing route6 object creation. Iljitsch Van Beijnum: What is the gain of filtering less specific ? Geoff Huston: What problem are you trying to solve ? Gert Doering: Trying to prevent accident, less maintenance if the documentation is in the database then it will be more stable. Conclusion: as we cannot force people to filter, we will see more specifics anyways (David Kessens) E. Report(s) about *actual* v6 traffic volume as compared to v4? *what's real* out there, not what's on powerpoint? - http://www.sixxs.net/misc/traffic/ (Jeroen Massar) Pointer to Jeroen's website was provided, but content was not discussed. Pim van Pelt offered to do some work to provide more data on his Sixxs ipv6 service but it was decided that the amount of work was probably not worth the effort. Discussed whether any ipv6 usage data from the RIPE meetings itself was available. This discussion resulted in a request and an action point for the RIPE NCC to provide us such data in the future (Action point 51.3) F. The end of the 6bone address space is in sight (Jeroen Massar) Discussion: - what are people going to do with 6bone address space as - per 6/6/6 ? - filter it? - keep it going? - warn people? - what to do with the 6bone registry ? Iljisch v B.: DNS is not auto-configurable in IPv6 like it is in IPv4 so I would like to use 6bone to get an ipv6 assignment for an experiment for well-known ipv6 DNS resolver addresses. Geoff H. : IANA has released a statment that 6bone dies on 06/06/2006. Gerd D.: exactly, what will people do when this happens? No uniform policy on what to do with 6bone prefixes. Some people will start filtering while others won't bother. In general, people advised David Kessens who maintains the 6bone registry to stop accepting registry changes by the close date but to keep the data online for some time to come with proper warning message when information is accessed. G. Developments/initiatives regarding IPv6 in the RIPE region and beyond - 6DISS (Bernard Tuy) Presentation will be available on the RIPE website as soon as Bernard Tuy provides the slides No questions. H. Input for the RIPE NCC Activity Plan (no input from the audience) Z. AOB Peter Koch drew attention to a presentation in the DNS working group regarding the deprecation of IP6.int. ---- From jeroen at unfix.org Sat Oct 22 16:35:04 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Sat, 22 Oct 2005 16:35:04 +0200 Subject: [ipv6-wg] Draft Minutes (v1) of IPv6 WG session RIPE51 In-Reply-To: <20051021130116.GA3635@nokia.com> References: <20051021130116.GA3635@nokia.com> Message-ID: <1129991704.13168.35.camel@firenze.zurich.ibm.com> [Microsoft/OpenTransit folks, look for '3ffe:8310::/28' for the Teredo prefix question] On Fri, 2005-10-21 at 06:01 -0700, David Kessens wrote: > Please see enclosed the first version of the minutes of our session at RIPE51. > > I plan to declare the minutes final if I don't receive any comments > for significant changes by November 4th 2005. Just a couple of notes, thus no comments on the minutes themselves, as I was not present, thus I might repeat some obvious things that where already said during the meeting. {There are at least two typo's look for the braces} > Conclusion: as we cannot force people to filter, we will see more > specifics anyways (David Kessens) What I have seen is that a number of times, when more specifics are announced, eg /48's that the 'better quality' networks filter them out, the prefix will then be carried only by 'less qualitity' networks or more politically correct, the route goes a couple of times around the world. Notorious are mostly Korean 'transit providers' who seem to accept anything. {NOTE: the typo in IljiTsch's name on the next line} > Iljisch v B.: DNS is not auto-configurable in IPv6 like it is in > IPv4 so I would like to use 6bone to get an ipv6 assignment for an > experiment for well-known ipv6 DNS resolver addresses. Iljitsch, for this there is of course: http://www.ripe.net/ripe/docs/ipv6policy.html#experiment-assignments No need for 6bone space :) Next to that, dhcpv6 of course works eg using dibbler, which provides the same mechanism. I am also in favor of the idea that Iljitsch has and to have a single IP address (which has to be part of a /32 or so to be not filtered...) which is the 'closest' dns service. I tried this in sort of a way at the last IETF though, but the word 'anycast' freaks out quite some people, see section 4 of the following for the relevant part: http://unfix.org/~jeroen/archive/drafts/draft-massar-dnsop-service-00.txt Though I understood that that doc hit on about 5 holy wars or so :) > Geoff H. : IANA has released a statment that 6bone dies on > 06/06/2006. > {NOTE: GerT with a T} > Gerd D.: exactly, what will people do when this happens? > > No uniform policy on what to do with 6bone prefixes. Some people > will start filtering while others won't bother. From RFC3701: 8<--------------- Thus after the 6bone phaseout date June 6, 2006, it is the intent that no 6bone 3FFE prefixes, of any size/length, be used on the Internet in any form. Network operators may filter 3FFE prefixes on their borders to ensure these prefixes are not misused. --------------->8 Nothing states though how to handle the case where people are announcing these prefixes, my intention is to start contacting people who are currently still using their prefix and reminding them that they need to drop it. This is the same situation when some ISP simply starts announcing eg 2005:1234:/32, what happens? People accept it or? Provided one has enough resources (read: cash) I actually guess most ISP's can be convinced/bribed that they will be accepted and IANA/RIR's are out of the loop. Then again remembering the 2003::/16 prefix from Microsoft, that got filtered quite hard by many, though I guess also because of some 'anti-m$' thoughts there ;) Which leads to another nice question, Teredo's are per default using a 6bone prefix (3ffe:8310::/28).... what is happening with that one because I assume that won't disappear from this planet 1,2,3!? At the moment that prefix is being announced by Microsoft (AS8070) The 3ffe:831f::/32 is also announced by OpenTransit (AS5511): inet6num: 3FFE:831F::/32 netname: WANADOO-EXP-IPV6-6BONE descr: France Telecom Wanadoo IPV6 experimentations country: FR admin-c: ML50-6BONE tech-c: ML50-6BONE mnt-by: FT-BRX changed: gestionip.ft at francetelecom.com 20050721 source: 6BONE That date is pretty new btw, clearly from GRH most ISP's also accept it. When folks got 6bone pTLA's they also agreed to read the 6bone mailinglist, but it has been seen already quite some times that many don't, directly contacting is thus going to be required. http://www.sixxs.net/tools/grh/dfp/6bone/ 8<---------------------- The database currently holds 144 IPv6 DFP's. Of which 31 (21.53%) are returned to the pool, 29 (20.14%) IPv6 DFP's didn't have a routing entry. Thus 84 (58.33%) networks are currently announced. ---------------------->8 about 60% left... Another related note on this subject; what is going to happen to www.6bone.net ? Is it going to be updated to something nice referring to information about IPv6 or? There are also quite a number of broken links on that page and most of the information is outdated or has been revised. > In general, people advised David Kessens who maintains the 6bone > registry to stop accepting registry changes by the close date but to > keep the data online for some time to come with proper warning > message when information is accessed. The registry is a good thing to keep, it is like having an old phone book around and your phonebills from that era, one can lookup the 'historical' data in there. So I agree with the above. Greets, Jeroen PS: I did a presentation about SixXS / Deploying IPv6 at SwiNOG #11, for interrested people, see: http://www.swinog.ch/meetings/swinog11/ Misses the words and it is indeed quite big but pictures tell quite a bit. -------------- 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: