From alain.bidron at francetelecom.com Wed Feb 2 14:39:00 2005 From: alain.bidron at francetelecom.com (BIDRON Alain ROSI/DAS) Date: Wed, 2 Feb 2005 14:39:00 +0100 Subject: [address-policy-wg] HD ratio policy proposal Message-ID: <89E8CBF169FE82408CBC2892EF204394322469@PUEXCBA0.nanterre.francetelecom.fr> Dear Colleagues Referring to the minutes of the last RIPE Policy Working Group meeting and to the action list as updated during that meeting, I have to make a formal proposal on use of HD ratio for IPV4. Here is this policy proposal. In order to be consistent with the PDP Draft proposal coming from Rob Blokzijl I have used the template provided in the new PDP proposal. Best regards. Alain _________________________________________________________ 1. Policy Proposal Name: IPv4-HD-Ratio 2. Author a. name: Alain Bidron b. e-mail: alain.bidron at francetelecom.com c. telephone: +33 1 44 44 27 75 d. organisation: France Telecom 3. Proposal Version: V0 4. Submission Date: 02/02/2005 5. Suggested WG for discussion and publication: Address Policy WG 6. Proposal type: modify 7. Policy term: permanent 8. Summary of proposal: Internet address space is managed hierarchically: - IANA allocates space to Regional Internet Registries (RIRs). - RIRs allocate space to Local Internet Registries (LIRs). - LIRs assign space to End Users. At each level, some address space may be reserved for future expansion and/or efficient aggregation. As more hierarchical levels are introduced, the overall efficiency of the address space usage decreases. The HD ratio (Host-Density ratio) is a way to measure address space usage [RFC 3194]. The HD ratio value can relate to a percentage of usage, which decreases as the amount of address space grows. This allows for the decreasing efficiency that occurs with more hierarchical levels. The HD ratio is currently used to measure IPv6 address space usage [ipv6-address-policy]. The IPv6 Address Allocation and Assignment Policy considers a block of IPv6 address space to be ?used? when its HD ratio reaches 0.80. This is a manageable figure ("values of 80% or less correspond to comfortable trade-offs between pain and efficiency" [RFC 3194]). This document proposes using the HD ratio to measure IPv4 usage. The proposed value of the HD ratio for IPv4 is 0.96. 9. Policy text: a. Current: "An LIR may receive an additional allocation when about eighty percent (80%) of all the address space currently allocated to it is used in valid assignments or sub-allocations." b. New: "An LIR may receive an additional allocation when its total allocated address space usage meets the HD-Ratio value of 0.96." 10. Rationale: a. Background The current document, ?IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region? [ipv4-address-policy], considers a block of IPv4 addresses to be ?used? when 80% of the addresses within the block have been sub-allocated or assigned. This is applied to all address blocks, regardless of size. Current policies assume a hierarchical system of address space delegation. However, they do not make any allowance for hierarchical management within allocated address space. For LIRs in particular, a hierarchical approach is often required for assignment of address space to service elements such as customer networks, individual Points of Presence (PoPs), regionalised topologies, and even distinct ISP products. Small network infrastructures may require simple hierarchies, but large infrastructures can require several levels of address space subdivision. These levels of hierarchy are not recognised by the current policy framework and are highly restricted by the "80% rule". As a result, managing large blocks is often difficult, requiring large internal routing tables and/or frequent renumbering of internal address blocks. One of the goals of the RIR system is to avoid unnecessary depletion of IPv4 address space. However, address management policies must also be practical in terms of how much management overhead they cause. When large amounts of address space are involved, the "80% rule" can result in more work for an LIR. Basing usage on the HD ratio should lead to equal levels of management overhead across the board, rather than penalising the holders of large address blocks. b.Impact To see a rough estimation of the immediate impact of this proposal, an HD Ratio value of 0.96 was applied to the average amount of address space held by an LIR in the RIPE NCC Service Region. This showed that on average, LIRs would qualify for an additional allocation block when they have assigned or sub-allocated about 59% of their allocated address space. c.Arguments supporting the proposal. This proposal fairly takes into account addressing hierarchies used in large and extra-large registries and introduces a useful level of flexibility for those registries The local Internet registries using the 80% criteria may continue to do so and will not be impacted by the new policy. The RIPE NCC will provide support to minimise complicated calculations or administrative burden to LIRs. d. Arguments opposing the proposal. This proposal will have some limited impact on IPV4 address consumption. Appendix A. The HD ratio The HD ratio is calculated as follows [RFC 3194]: HD = log(U)/log(S) Where: S is the size of the address block concerned, and U is the number of addresses used. Note: The current IPv4 policy considers addresses to be ?used? once they are assigned or sub-allocated by the LIR. Appendix B. Selection of HD ratio value We should decide an appropriate HD ratio value on a rational basis. To do this, we make certain assumptions about the number of "hidden" hierarchical levels involved in managing address blocks of various sizes. If we assume there is 80% usage at each level, we can easily calculate the overall usage. The following table proposes a set of hierarchical levels which we can reasonably expect within different amounts of address space. If a usage of 80% is achieved at each hierarchical level, then the overall usage will be (0.80 to the power of "n"). It is then possible to calculate HD ratio values from this value. Size range Level Utilisation HD ratio (prefix) (n) (0.80**n) (calculated) /24 to /20 1 80% .960 to .973 /20 to /16 1.5 72% .961 to .970 /16 to /12 2 64% .960 to .968 /12 to /8 2.5 57.2% .960 to .966 /8 to /4 3 51.20% .960 to .966 The levels of hierarchy listed above are based on assumptions about the likely size and structure of LIRs holding address blocks of these sizes. A reasonable HD ratio value may be 0.96 (a round figure which occurs within most of these ranges) from the table above. The following table gives the usage requirements for IPv4 address blocks from /24 to /8 for this value. IPv4 Addresses Addresses Util% prefix total used 24 256 205 80.11% 23 512 399 77.92% 22 1024 776 75.79% 21 2048 1510 73.71% 20 4096 2937 71.70% 19 8192 5713 69.74% 18 16384 11113 67.83% 17 32768 21619 65.98% 16 65536 42055 64.17% 15 131072 81811 62.42% 14 262144 159147 60.71% 13 524288 309590 59.05% 12 1048576 602249 57.43% 11 2097152 1171560 55.86% 10 4194304 2279048 54.34% 9 8388608 4433455 52.85% 8 16777216 8624444 51.41% Note: This table provides values for CIDR blocks, but the same calculations can be made for non-CIDR blocks. As an example, an LIR holding a total amount of address space equal to a /16 would be able to receive more address space when they had sub-allocated or assigned 64.17% of that space; while an LIR holding a /9 would be able to receive more space when they had sub-allocated or assigned 52.85% of their address space. Appendix C. References [RFC 3194] "The Host-Density ratio for address assignment efficiency: An update on the H ratio", A. Durand, C.Huitema, November 2001. [ipv6-address-policy] RIPE NCC document: "IPv6 Address Allocation and Assignment Policy" http://www.ripe.net/ripe/docs/ipv6policy.html [ipv4-address-policy] RIPE NCC document: "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" http://www.ripe.net/ripe/docs/ipv4-policies.html From ncc at ripe.net Fri Feb 4 15:23:48 2005 From: ncc at ripe.net (Axel Pawlik) Date: Fri, 04 Feb 2005 15:23:48 +0100 Subject: [address-policy-wg] Call for Comments on the WGIG Draft Working Papers Message-ID: <5.2.1.1.2.20050204152058.07e509e8@mailhost.ripe.net> >Dear Colleagues, > >As you may be aware the World Summit on the >Information Society (WSIS) requested the United Nations Secretary-General >to establish a Working Group on Internet Governance (WGIG). > >A series of 'draft working papers' prepared by WGIG members can be found at: > >http://www.wgig.org/working-papers.html > >A template to submit comments on the draft papers can be found at: > >http://www.wgig.org/docs/comment-template.doc > >As stated on the WGIG website: > >"Governments and all stakeholders are invited to comment on these papers, >preferably by making use of this template. Due consideration will be given >to all comments, but use of the template will facilitate processing >feedback. All comments received from governments and WSIS accredited >entities by 11 February 1200 hours GMT will be posted on this website. >Comments by other entities or individuals will also be posted, provided >they are relevant to the issues under discussion." > >Regards, > >Axel Pawlik >Managing Director >RIPE NCC From jaka.erjavec at gmail.com Mon Feb 7 09:56:51 2005 From: jaka.erjavec at gmail.com (Jaka Erjavec) Date: Mon, 7 Feb 2005 09:56:51 +0100 Subject: [address-policy-wg] IPv4 assignment to resident user Message-ID: Dear colleagues, I was searching www.ripe.net website for a document where it says that IPv4 block can NOT be allocated to resident user (not company). Can you, guys, please point me to appropriate url? Thank you! Jaka From jeroen at unfix.org Mon Feb 7 10:02:00 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 07 Feb 2005 10:02:00 +0100 Subject: [address-policy-wg] IPv4 assignment to resident user In-Reply-To: References: Message-ID: <1107766920.27997.4.camel@firenze.zurich.ibm.com> On Mon, 2005-02-07 at 09:56 +0100, Jaka Erjavec wrote: > Dear colleagues, > > I was searching www.ripe.net website for a document where it says that > IPv4 block can NOT be allocated to resident user (not company). RIR's (RIPE/ARIN/APNIC/LACNIC/AFNIC) allocate to a LIR, which allocates the block to an ISP who could _assign_ it to an endsite. An endsite can be a company but also an residence/enduser. Allocations to endsites are afaik not possible, but assignments for sure are. 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 marcoh at marcoh.net Mon Feb 7 10:06:14 2005 From: marcoh at marcoh.net (MarcoH) Date: Mon, 7 Feb 2005 10:06:14 +0100 Subject: [address-policy-wg] IPv4 assignment to resident user In-Reply-To: References: Message-ID: <20050207090614.GA8090@marcoh.net> On Mon, Feb 07, 2005 at 09:56:51AM +0100, Jaka Erjavec wrote: > Dear colleagues, > > I was searching www.ripe.net website for a document where it says that > IPv4 block can NOT be allocated to resident user (not company). > > Can you, guys, please point me to appropriate url? Hi, Afaik your looking for something which doesn't exist, as long as the LIR agrees to it and the forms are filled in correctly a residential customer can get IP space. See RIPE-324 for more details on what's considered valid. Grtx, MarcoH From marcoh at marcoh.net Mon Feb 7 10:12:17 2005 From: marcoh at marcoh.net (MarcoH) Date: Mon, 7 Feb 2005 10:12:17 +0100 Subject: [address-policy-wg] IPv4 assignment to resident user In-Reply-To: <1107766920.27997.4.camel@firenze.zurich.ibm.com> References: <1107766920.27997.4.camel@firenze.zurich.ibm.com> Message-ID: <20050207091217.GB8090@marcoh.net> On Mon, Feb 07, 2005 at 10:02:00AM +0100, Jeroen Massar wrote: > On Mon, 2005-02-07 at 09:56 +0100, Jaka Erjavec wrote: > > Dear colleagues, > > > > I was searching www.ripe.net website for a document where it says that > > IPv4 block can NOT be allocated to resident user (not company). > > Allocations to endsites are afaik not possible, but assignments for sure > are. All the legal docs also talk about natural persons, so If you can buy enough PC's to justify the initial allocation and have the money and time to become an LIR I don't see big problems on getting your very own PA-allocation :) MarcoH From jaka.erjavec at gmail.com Mon Feb 7 10:31:07 2005 From: jaka.erjavec at gmail.com (Jaka Erjavec) Date: Mon, 7 Feb 2005 10:31:07 +0100 Subject: [address-policy-wg] IPv4 assignment to resident user In-Reply-To: <20050207091217.GB8090@marcoh.net> References: <1107766920.27997.4.camel@firenze.zurich.ibm.com> <20050207091217.GB8090@marcoh.net> Message-ID: On Mon, 7 Feb 2005 10:12:17 +0100, MarcoH wrote: > On Mon, Feb 07, 2005 at 10:02:00AM +0100, Jeroen Massar wrote: > > On Mon, 2005-02-07 at 09:56 +0100, Jaka Erjavec wrote: > > > Dear colleagues, > > > > > > I was searching www.ripe.net website for a document where it says that > > > IPv4 block can NOT be allocated to resident user (not company). > > > > Allocations to endsites are afaik not possible, but assignments for sure > > are. > > All the legal docs also talk about natural persons, so If you can buy > enough PC's to justify the initial allocation and have the money and time > to become an LIR I don't see big problems on getting your very own > PA-allocation :) Thank you all for these quick replys. I used wrong term (allocation), when I meant assignment. Jaka From jon at lawrence.org.uk Mon Feb 7 10:34:41 2005 From: jon at lawrence.org.uk (Jon Lawrence) Date: Mon, 7 Feb 2005 09:34:41 +0000 Subject: [address-policy-wg] IPv4 assignment to resident user In-Reply-To: References: Message-ID: <200502070934.41843.jon@lawrence.org.uk> On Monday 07 February 2005 08:56, Jaka Erjavec wrote: > Dear colleagues, > > I was searching www.ripe.net website for a document where it says that > IPv4 block can NOT be allocated to resident user (not company). > > Can you, guys, please point me to appropriate url? > Residential users certainly could get an allocation - would be a bit unusual though. All they'd have to do is fill in the necessary justification and pay the RIPE fees. It would be more likely for a residential user to get an assignment from an upstream ISP. Jon From leo at ripe.net Mon Feb 7 11:52:22 2005 From: leo at ripe.net (leo vegoda) Date: Mon, 07 Feb 2005 11:52:22 +0100 Subject: [address-policy-wg] [Fwd: [apops] APNIC new IPv4 addresses] Message-ID: <42074866.7030206@ripe.net> Dear Colleagues, I'm forwarding this announcement, on request. Kind regards, -- leo vegoda RIPE NCC Registration Services Manager -------------- next part -------------- An embedded message was scrubbed... From: John Tran Subject: [apops] APNIC new IPv4 addresses Date: Fri, 4 Feb 2005 16:28:07 +1000 (EST) Size: 4101 URL: From gert at space.net Mon Feb 7 14:24:54 2005 From: gert at space.net (Gert Doering) Date: Mon, 7 Feb 2005 14:24:54 +0100 Subject: [address-policy-wg] IPv4 assignment to resident user In-Reply-To: References: Message-ID: <20050207132454.GU84850@Space.Net> Hi, On Mon, Feb 07, 2005 at 09:56:51AM +0100, Jaka Erjavec wrote: > I was searching www.ripe.net website for a document where it says that > IPv4 block can NOT be allocated to resident user (not company). > > Can you, guys, please point me to appropriate url? First of all, a clarification: * "allocated" means "given to a registry". An "allocation" is never given to an end user (be it a company or a resident user). What a local registry (LIR) gets from RIPE is an "allocation". * Address blocks given to "end users" (of all sorts) are "assignments". Then, to answer your question: there is no document that says "resident users must not receive an IP address assignment". The reason for that is: it is perfectly *valid* to give static IP address assignments to end users - provided they provide appropriate documentation that they will use it. If a residential customer has 10 devices at home that all can speak IP, it is *perfectly fine* (!!) to assign a /28 network to this customer. RIPE does *not* mandate dynamic addressing or NAT. (But it is expected that you think about it, before making a decision pro or contra NAT). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) 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 Mon Feb 7 14:26:18 2005 From: gert at space.net (Gert Doering) Date: Mon, 7 Feb 2005 14:26:18 +0100 Subject: [address-policy-wg] IPv4 assignment to resident user In-Reply-To: <20050207091217.GB8090@marcoh.net> References: <1107766920.27997.4.camel@firenze.zurich.ibm.com> <20050207091217.GB8090@marcoh.net> Message-ID: <20050207132618.GV84850@Space.Net> Hi, On Mon, Feb 07, 2005 at 10:12:17AM +0100, MarcoH wrote: > All the legal docs also talk about natural persons, so If you can buy > enough PC's to justify the initial allocation and have the money and time > to become an LIR I don't see big problems on getting your very own > PA-allocation :) Actually, there is no initial "size" criteria anymore. So in theory, a private person might be able to be come a LIR, provided that you get a second person to stand up as tech-c: (AFAIR you need two persons that state "yes, we will follow the RIPE guidelines!"). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From leo at ripe.net Mon Feb 7 16:13:29 2005 From: leo at ripe.net (leo vegoda) Date: Mon, 07 Feb 2005 16:13:29 +0100 Subject: [address-policy-wg] IPv4 assignment to resident user In-Reply-To: <20050207132618.GV84850@Space.Net> References: <1107766920.27997.4.camel@firenze.zurich.ibm.com> <20050207091217.GB8090@marcoh.net> <20050207132618.GV84850@Space.Net> Message-ID: <42078599.2040206@ripe.net> Gert Doering wrote: >>All the legal docs also talk about natural persons, so If you can buy >>enough PC's to justify the initial allocation and have the money and time >>to become an LIR I don't see big problems on getting your very own >>PA-allocation :) > > Actually, there is no initial "size" criteria anymore. Indeed, we now allocate IPv4 address space after the LIR's first assignment request has been evaluated and approved. Regards, -- leo vegoda RIPE NCC Registration Services Manager From webmaster at ripe.net Tue Feb 22 13:06:09 2005 From: webmaster at ripe.net (RIPE NCC Document Announcement Service) Date: Tue, 22 Feb 2005 13:06:09 +0100 Subject: [address-policy-wg] New Document available: RIPE-343 Message-ID: <200502221206.j1MC69et008690@birch.ripe.net> [apologies for duplicate e-mails] New RIPE Document Announcement -------------------------------------- A revised document is available from the RIPE document store. Ref: ripe-343 Title: IPv6 Address Space Management Author: Paul Wilson, Raymond Plzak, Axel Pawlik Date: 22 February 2005 Format: PS=53986 TXT=13567 Obsoletes: ripe-261 Short content description ------------------------- This document provides the management process for IPv6 global unicast address space whereby address allocations are made from a single global pool according to a "sparse allocation" algorithm. In this version, previously published as ripe-261, we fixed an error in the 6-bit address space table. Accessing the RIPE document store --------------------------------- You can access the RIPE documents in HTML format via our website at the following URL:. http://www.ripe.net/docs/ipv6-sparse.html The RIPE Document Store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-343.pdf PDF version ftp://ftp.ripe.net/ripe/docs/ripe-343.txt plain text version Kind Regards, RIPE NCC Document Announcement Service From randy at psg.com Wed Feb 23 08:44:08 2005 From: randy at psg.com (Randy Bush) Date: Wed, 23 Feb 2005 16:44:08 +0900 Subject: [address-policy-wg] New Document available: RIPE-343 References: <200502221206.j1MC69et008690@birch.ripe.net> Message-ID: <16924.13384.108052.348961@roam.psg.com> > [apologies for duplicate e-mails] > > New RIPE Document Announcement > -------------------------------------- > A revised document is available from the RIPE document store. > > Ref: ripe-343 > Title: IPv6 Address Space Management > Author: Paul Wilson, Raymond Plzak, Axel Pawlik > Date: 22 February 2005 > Format: PS=53986 TXT=13567 > Obsoletes: ripe-261 as this document is far from new, and did not fly well the last time it tried to take off, is there something i am missing about why it is being republished now? randy From gert at space.net Wed Feb 23 14:19:02 2005 From: gert at space.net (Gert Doering) Date: Wed, 23 Feb 2005 14:19:02 +0100 Subject: [address-policy-wg] Re: [ipv6-wg@ripe.net] New Document available: RIPE-343 In-Reply-To: <200502221206.j1MC69et008690@birch.ripe.net> References: <200502221206.j1MC69et008690@birch.ripe.net> Message-ID: <20050223131902.GW84850@Space.Net> Hi, On Tue, Feb 22, 2005 at 01:06:09PM +0100, RIPE NCC Document Announcement Service wrote: > New RIPE Document Announcement > -------------------------------------- > A revised document is available from the RIPE document store. > > Ref: ripe-343 > Title: IPv6 Address Space Management > Author: Paul Wilson, Raymond Plzak, Axel Pawlik > Date: 22 February 2005 > Format: PS=53986 TXT=13567 > Obsoletes: ripe-261 I am with Randy in this - why on earth is the NCC bothering in re-releasing this document, if only a single line has changed, and people do not *want* this document anyway? It will create quite some confusion, and create the illusion that this is something "new", something people will need to read, think about, comment about, and so on - which just wastes precious brain cycles. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) 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 iljitsch at muada.com Thu Feb 24 19:28:43 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 24 Feb 2005 19:28:43 +0100 Subject: [address-policy-wg] Re: [ipv6-wg@ripe.net] IPv6 access to K-root In-Reply-To: <410E7D22.70904@ripe.net> References: <410E7D22.70904@ripe.net> Message-ID: <9bba11348129f99d6a700921cc6e89c1@muada.com> On 2-aug-04, at 19:42, Andrei Robachevsky wrote: > 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. Since the ARIN micro allocation policy creates some problems, I was curious what kind of address space RIPE uses for k-root. A /32 "macro allocation", it turns out: inet6num: 2001:07FD::/32 netname: K-rootserver-net-20030829 descr: This assignment given to k-root.server.net I believe this ASSIGNment is in violation of existing IPv6 ALLOCATION policies. I would be very interested in learning any information to the contrary. Iljitsch van Beijnum From elmi at 4ever.de Thu Feb 24 20:02:55 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Thu, 24 Feb 2005 20:02:55 +0100 Subject: [address-policy-wg] Re: [ipv6-wg@ripe.net] IPv6 access to K-root In-Reply-To: <9bba11348129f99d6a700921cc6e89c1@muada.com> References: <410E7D22.70904@ripe.net> <9bba11348129f99d6a700921cc6e89c1@muada.com> Message-ID: <20050224190254.GY14099@new.detebe.org> iljitsch at muada.com (Iljitsch van Beijnum) wrote: > >This information is also available from www.root-servers.org webiste. > > Since the ARIN micro allocation policy creates some problems, I was > curious what kind of address space RIPE uses for k-root. A /32 "macro > allocation", it turns out: > > inet6num: 2001:07FD::/32 > netname: K-rootserver-net-20030829 > descr: This assignment given to k-root.server.net > > I believe this ASSIGNment is in violation of existing IPv6 ALLOCATION > policies. I would be very interested in learning any information to the > contrary. So do I, since I have a ccTLD service to provision with IPv6. Elmar. (And yes, ARIN sent me to RIPE, and they sent me home...) -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, ) --------------------------------------------------------------[ ELMI-RIPE ]--- From dr at cluenet.de Thu Feb 24 20:04:20 2005 From: dr at cluenet.de (Daniel Roesen) Date: Thu, 24 Feb 2005 20:04:20 +0100 Subject: [address-policy-wg] Re: [ipv6-wg@ripe.net] IPv6 access to K-root In-Reply-To: <9bba11348129f99d6a700921cc6e89c1@muada.com> References: <410E7D22.70904@ripe.net> <9bba11348129f99d6a700921cc6e89c1@muada.com> Message-ID: <20050224190420.GA30975@srv01.cluenet.de> On Thu, Feb 24, 2005 at 07:28:43PM +0100, Iljitsch van Beijnum wrote: > Since the ARIN micro allocation policy creates some problems, I was > curious what kind of address space RIPE uses for k-root. A /32 "macro > allocation", it turns out: > > inet6num: 2001:07FD::/32 > netname: K-rootserver-net-20030829 > descr: This assignment given to k-root.server.net > > I believe this ASSIGNment is in violation of existing IPv6 ALLOCATION > policies. I would be very interested in learning any information to the > contrary. http://www.ripe.net/ripe/docs/ipv6-rootservers.html "Under this policy, each (current or future) Internet DNS root server (as listed in the root-servers.net zone) in the RIPE region will be assigned a block of IPv6 address space for purposes of root server operations. The size of the block shall be the same as the size of the minimum allocation to Local Internet Registries (LIRs) valid at the time of the root server assignment." An ALLOCATION makes no sense as no assignments would be done. The root server operator IS the end user of the address space. Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From iljitsch at muada.com Thu Feb 24 20:55:10 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 24 Feb 2005 20:55:10 +0100 Subject: [address-policy-wg] Re: [ipv6-wg@ripe.net] IPv6 access to K-root In-Reply-To: <20050224190420.GA30975@srv01.cluenet.de> References: <410E7D22.70904@ripe.net> <9bba11348129f99d6a700921cc6e89c1@muada.com> <20050224190420.GA30975@srv01.cluenet.de> Message-ID: <07654d4cae5d49d87b554658b46696a1@muada.com> On 24-feb-05, at 20:04, Daniel Roesen wrote: > http://www.ripe.net/ripe/docs/ipv6-rootservers.html > "Under this policy, each (current or future) Internet DNS root server > (as listed in the root-servers.net zone) in the RIPE region will be > assigned a block of IPv6 address space for purposes of root server > operations. The size of the block shall be the same as the size of the > minimum allocation to Local Internet Registries (LIRs) valid at the > time > of the root server assignment." So who authorized this? It looks a lot like the RIPE NCC doesn't have to stick to its own rules when it doesn't feel like it. And it's extremely wasteful to use 2^96 addresses when only 1 is needed. From dr at cluenet.de Thu Feb 24 21:23:23 2005 From: dr at cluenet.de (Daniel Roesen) Date: Thu, 24 Feb 2005 21:23:23 +0100 Subject: [address-policy-wg] Re: [ipv6-wg@ripe.net] IPv6 access to K-root In-Reply-To: <07654d4cae5d49d87b554658b46696a1@muada.com> References: <410E7D22.70904@ripe.net> <9bba11348129f99d6a700921cc6e89c1@muada.com> <20050224190420.GA30975@srv01.cluenet.de> <07654d4cae5d49d87b554658b46696a1@muada.com> Message-ID: <20050224202323.GA31925@srv01.cluenet.de> On Thu, Feb 24, 2005 at 08:55:10PM +0100, Iljitsch van Beijnum wrote: > And it's extremely wasteful to use 2^96 addresses when only 1 is needed. That's because of people's lazy and stupid habit of derriving policy from prefix length (exceeding the valid conclusions from the IPv6 architecture documents). I would have preferred the ARIN way of using /48s (end site size). Unfortunately still many people think (or just copied some random filter recommendation) that filtering ANY /48 is a good thing, and don't update filters. Regards, Dan'overly aggressive filtering considered harmful'iel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From iljitsch at muada.com Thu Feb 24 22:09:08 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 24 Feb 2005 22:09:08 +0100 Subject: [address-policy-wg] Re: [ipv6-wg@ripe.net] IPv6 access to K-root In-Reply-To: <20050224202323.GA31925@srv01.cluenet.de> References: <410E7D22.70904@ripe.net> <9bba11348129f99d6a700921cc6e89c1@muada.com> <20050224190420.GA30975@srv01.cluenet.de> <07654d4cae5d49d87b554658b46696a1@muada.com> <20050224202323.GA31925@srv01.cluenet.de> Message-ID: <6b4b4a538e32df2d072537e30c8b090c@muada.com> On 24-feb-05, at 21:23, Daniel Roesen wrote: >> And it's extremely wasteful to use 2^96 addresses when only 1 is >> needed. > That's because of people's lazy and stupid habit of derriving policy > from prefix length In IPv4 it's a reasonable thing to do because enumerating all valid prefixes just isn't feasible. > Unfortunately still many people think (or just > copied some random filter recommendation) that filtering ANY /48 is a > good thing, and don't update filters. Hm, maybe the read http://www.ripe.net/ripe/docs/ipv6-policies.html and saw: 4.3. Minimum allocation RIRs will apply a minimum size for IPv6 allocations to facilitate prefix-based filtering. The minimum allocation size for IPv6 address space is /32. From gert at space.net Thu Feb 24 22:20:11 2005 From: gert at space.net (Gert Doering) Date: Thu, 24 Feb 2005 22:20:11 +0100 Subject: [address-policy-wg] Re: [ipv6-wg@ripe.net] IPv6 access to K-root In-Reply-To: <07654d4cae5d49d87b554658b46696a1@muada.com> References: <410E7D22.70904@ripe.net> <9bba11348129f99d6a700921cc6e89c1@muada.com> <20050224190420.GA30975@srv01.cluenet.de> <07654d4cae5d49d87b554658b46696a1@muada.com> Message-ID: <20050224212011.GX84850@Space.Net> Hi, On Thu, Feb 24, 2005 at 08:55:10PM +0100, Iljitsch van Beijnum wrote: > So who authorized this? The normal RIPE policy process. People discussed it, and decided it's a useful idea to have a way to get well-known IPv6 addresses to root servers. The resulting document is ripe-233: --------------------- snip --------------------- IPv6 Addresses for Internet Root Servers in the RIPE Region Joao Luis Silva Damas Document ID: ripe-233 Date: 24 May 2002 Abstract This document describes the special case assignment policy for Internet DNS root servers in the RIPE region. --------------------- snip --------------------- The progress that led to this policy is documented in the archives. > It looks a lot like the RIPE NCC doesn't have to stick to its own rules > when it doesn't feel like it. Please try to get your facts straigth *before* making such statements. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) 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 gert at space.net Thu Feb 24 22:26:05 2005 From: gert at space.net (Gert Doering) Date: Thu, 24 Feb 2005 22:26:05 +0100 Subject: [address-policy-wg] Re: [ipv6-wg@ripe.net] IPv6 access to K-root In-Reply-To: <20050224190254.GY14099@new.detebe.org> References: <410E7D22.70904@ripe.net> <9bba11348129f99d6a700921cc6e89c1@muada.com> <20050224190254.GY14099@new.detebe.org> Message-ID: <20050224212605.GY84850@Space.Net> Hi, On Thu, Feb 24, 2005 at 08:02:55PM +0100, Elmar K. Bins wrote: > So do I, since I have a ccTLD service to provision with IPv6. As you know, everybody is special, but the *only* thing that cannot be resolved by DNS is the IPv4/IPv6 address of root name servers. There is no special case policy for (unicast) ccTLD name servers, for major search engines, big software vendor download sites, etc. -> find an upstream provider, get an IPv6 address block, and enter that in the relevant DNS zones. Of course the underlying question returns to "how to do IPv6 multihoming for A Special End Site". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) 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 jon at lawrence.org.uk Thu Feb 24 22:27:01 2005 From: jon at lawrence.org.uk (Jon Lawrence) Date: Thu, 24 Feb 2005 21:27:01 +0000 Subject: [address-policy-wg] Re: [ipv6-wg@ripe.net] IPv6 access to K-root In-Reply-To: <20050224190420.GA30975@srv01.cluenet.de> References: <410E7D22.70904@ripe.net> <9bba11348129f99d6a700921cc6e89c1@muada.com> <20050224190420.GA30975@srv01.cluenet.de> Message-ID: <200502242127.01825.jon@lawrence.org.uk> On Thursday 24 February 2005 19:04, Daniel Roesen wrote: > On Thu, Feb 24, 2005 at 07:28:43PM +0100, Iljitsch van Beijnum wrote: > > Since the ARIN micro allocation policy creates some problems, I was > > curious what kind of address space RIPE uses for k-root. A /32 "macro > > allocation", it turns out: > > > > inet6num: 2001:07FD::/32 > > netname: K-rootserver-net-20030829 > > descr: This assignment given to k-root.server.net > > > > I believe this ASSIGNment is in violation of existing IPv6 ALLOCATION > > policies. I would be very interested in learning any information to the > > contrary. > > http://www.ripe.net/ripe/docs/ipv6-rootservers.html > > "Under this policy, each (current or future) Internet DNS root server > (as listed in the root-servers.net zone) in the RIPE region will be > assigned a block of IPv6 address space for purposes of root server > operations. The size of the block shall be the same as the size of the > minimum allocation to Local Internet Registries (LIRs) valid at the time > of the root server assignment." > > An ALLOCATION makes no sense as no assignments would be done. The root > server operator IS the end user of the address space. > Yep, that makes sense. A root server operator would be an end user - can't imagine why they'd need more than a /48 though. It would make sense to me if root servers were assigned directly from RIPE (possibly from a special allocation set as side for the root servers' use). It seems completely pointless to allocate/assign a /32 to a root server. If the root server operator gets an assignment (directly from RIPE) why does it need to be the same size as a normal minimum allocation. Regardless of min allocation size - which ISP isn't going to allow an known root server IP through. If people want to filter then let them, if they don't know what they're doing then that's their look out. Root servers should be allocated/assigned (whatever) from a known block - that way everyone knows not to filter that block. Jon From gert at space.net Thu Feb 24 22:41:07 2005 From: gert at space.net (Gert Doering) Date: Thu, 24 Feb 2005 22:41:07 +0100 Subject: [address-policy-wg] Re: [ipv6-wg@ripe.net] IPv6 access to K-root In-Reply-To: <200502242127.01825.jon@lawrence.org.uk> References: <410E7D22.70904@ripe.net> <9bba11348129f99d6a700921cc6e89c1@muada.com> <20050224190420.GA30975@srv01.cluenet.de> <200502242127.01825.jon@lawrence.org.uk> Message-ID: <20050224214107.GC84850@Space.Net> Hi, On Thu, Feb 24, 2005 at 09:27:01PM +0000, Jon Lawrence wrote: > > An ALLOCATION makes no sense as no assignments would be done. The root > > server operator IS the end user of the address space. > > > Yep, that makes sense. A root server operator would be an end user - can't > imagine why they'd need more than a /48 though. They need a /128. But experience has shown that BGP participants *do* filter, and as such, it was decided to go for a /32 in RIPE land. ARIN does /48s. > It would make sense to me if root servers were assigned directly from RIPE > (possibly from a special allocation set as side for the root servers' use). This is the way it is done. > It seems completely pointless to allocate/assign a /32 to a root server. > If the root server operator gets an assignment (directly from RIPE) why does > it need to be the same size as a normal minimum allocation. BGP filters. But hey, so what. There are roughly 4 billion /32s - what do you gain by saving 10 /32s? The number of routing table entries (which are a larger problem than "exhaustion of the available /32s") doesn't change. > Regardless of min allocation size - which ISP isn't going to allow an known > root server IP through. If people want to filter then let them, if they don't > know what they're doing then that's their look out. > > Root servers should be allocated/assigned (whatever) from a known block - that > way everyone knows not to filter that block. At the time the policy was written, people thought that this way would be better. On the subject of root servers, people tend to be conservative. OTOH, no policy that can't be changed if people think otherwise today. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) 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 jon at lawrence.org.uk Thu Feb 24 22:47:37 2005 From: jon at lawrence.org.uk (Jon Lawrence) Date: Thu, 24 Feb 2005 21:47:37 +0000 Subject: [address-policy-wg] Re: [ipv6-wg@ripe.net] IPv6 access to K-root In-Reply-To: <20050224212011.GX84850@Space.Net> References: <410E7D22.70904@ripe.net> <07654d4cae5d49d87b554658b46696a1@muada.com> <20050224212011.GX84850@Space.Net> Message-ID: <200502242147.37712.jon@lawrence.org.uk> On Thursday 24 February 2005 21:20, Gert Doering wrote: > Hi, > > On Thu, Feb 24, 2005 at 08:55:10PM +0100, Iljitsch van Beijnum wrote: > > So who authorized this? > > The normal RIPE policy process. People discussed it, and decided it's > a useful idea to have a way to get well-known IPv6 addresses to root > servers. > Gert, I don't want to open an old discussion, but there's a difference between 'well known' addresses and a full /32. Jon From elmi at 4ever.de Fri Feb 25 00:02:41 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Fri, 25 Feb 2005 00:02:41 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <20050224212605.GY84850@Space.Net> References: <410E7D22.70904@ripe.net> <9bba11348129f99d6a700921cc6e89c1@muada.com> <20050224190254.GY14099@new.detebe.org> <20050224212605.GY84850@Space.Net> Message-ID: <20050224230241.GZ14099@new.detebe.org> gert at space.net (Gert Doering) wrote: > There is no special case policy for (unicast) ccTLD name servers, for > major search engines, big software vendor download sites, etc. -> find > an upstream provider, get an IPv6 address block, and enter that in the > relevant DNS zones. I'm not talking unicast, I'm talking of not having a chance to get an assignment for ccTLD DNS servers. And yes, they would be anycast, for packet size reasons (even if that isn't the issue here; count the Verisign special assignments). Our home v6 network is a PA /48 (you of all should know) which I cannot properly multihome. Fortunately, that's not a problem, even if some people are filtering it. The real problem is DNS deployment in v6. v4 has 11 (14 by June) of our servers, spread world-wide; I'd like to do the same with v6 servers, but I simply can't. Every f***ing registry on the planet has the special assignment policy (with very strict rules, mind you), except for the one they always send me back to ("sorry, not our business, you're in the RIPE region"). > Of course the underlying question returns to "how to do IPv6 multihoming > for A Special End Site". I know, and I am getting sick of the process not getting one step further. I don't know where the problem really is, but the only way to get one or a couple /48s for anycasting seems to open business in the USA. Or Zaire. Or New Zealand. So one of the registries that long have this kind of policy consider me their business. I don't know why the RIPE community doesn't even publish the papers that are being circulated and have been for over a year now. Is everybody busy waiting for the IETF v6-multihoming group to come to a conclusion? Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, ) --------------------------------------------------------------[ ELMI-RIPE ]--- From iljitsch at muada.com Fri Feb 25 00:36:06 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 25 Feb 2005 00:36:06 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <20050224230241.GZ14099@new.detebe.org> References: <410E7D22.70904@ripe.net> <9bba11348129f99d6a700921cc6e89c1@muada.com> <20050224190254.GY14099@new.detebe.org> <20050224212605.GY84850@Space.Net> <20050224230241.GZ14099@new.detebe.org> Message-ID: <774d66623248c0bf50184883cee188ed@muada.com> On 25-feb-05, at 0:02, Elmar K. Bins wrote: > The real problem is DNS deployment > in v6. v4 has 11 (14 by June) of our servers, spread world-wide; I'd > like to do the same with v6 servers, but I simply can't. > Every f***ing registry on the planet has the special assignment policy > (with very strict rules, mind you), except for the one they always > send me back to ("sorry, not our business, you're in the RIPE region"). Well, there are more than a hundred TLDs and if they all want 11 IPv6 prefixes that would inflate the v6 table by more than 150%. I think a reasonable proposal from a good portion of the TLD community would go a long way, though. >> Of course the underlying question returns to "how to do IPv6 >> multihoming >> for A Special End Site". Everyone thinks they're special. That's how you get large routing tables. (It's not _that_ long ago that the root servers got their addresses from the organizations that hosted them.) > Is everybody busy waiting for the IETF v6-multihoming group to come > to a conclusion? In that case you won't have to wait much longer as this is going to happen within a few weeks. However, the multi6 mechanisms (that still have to be developed) aren't very suitable for multihoming DNS service. From elmi at 4ever.de Fri Feb 25 01:02:00 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Fri, 25 Feb 2005 01:02:00 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <774d66623248c0bf50184883cee188ed@muada.com> References: <410E7D22.70904@ripe.net> <9bba11348129f99d6a700921cc6e89c1@muada.com> <20050224190254.GY14099@new.detebe.org> <20050224212605.GY84850@Space.Net> <20050224230241.GZ14099@new.detebe.org> <774d66623248c0bf50184883cee188ed@muada.com> Message-ID: <20050225000159.GA14099@new.detebe.org> iljitsch at muada.com (Iljitsch van Beijnum) wrote: > Well, there are more than a hundred TLDs and if they all want 11 IPv6 > prefixes that would inflate the v6 table by more than 150%. There are ways around this, and people are pretty reasonable. I believe in other ccTLDs as well as in ours people know pretty well what they are doing and what they should demand. Actually, what would keep them from doing things together again for a try? Anyway, v6 space is organized quite different from v4 space (let's hope it's not becoming overorganized in the near future), and, while you're right and the prefix tables will grow, they will not hit the same technological boundaries v4 hit all the while. Even if the table grows from the handful of prefixes (who sees more than 2000?) to half a million, the then-current routers will easily cope with that. And will 1100 prefixes (I'd expect around 300, mind) make any difference? > Everyone thinks they're special. That's how you get large routing > tables. Who gets to decide? We're talking infrastructure here. ARIN seems to have a picture of specialness quite different from RIPE's view. If you ask me, it's closer to what's needed. And I cannot see the v6 train pulling out of the yard before the infrastructure all people are accustomed to does speak IPv6. And I mean: In the way it speaks v4, not in a lab environment or in mini- scale. In real life some things are more special than others. > >Is everybody busy waiting for the IETF v6-multihoming group to come > >to a conclusion? > > In that case you won't have to wait much longer as this is going to > happen within a few weeks. However, the multi6 mechanisms (that still > have to be developed) aren't very suitable for multihoming DNS service. I'm following the list, and, as well as a lot of people have worked on proposals and design papers, I believe the whole thing is far from deployment. But that's my $0.02. I have to find solutions now. I could long ago have convinced my superiors to open a branch office in $ELSEWHERE and go to the appropriate RIR, but I have always been a friend and promoter of the "RIPE way of doing things", and I would rather see the RIPE community get out of the ivory tower and into the real world, where some things _are_ special. Alright, I'm repeating myself. Maybe we can restart the discussion that faded away after 2003, and get things on the right track. Which of course means, afterwards all people share my opinion. :-) Elmar. From jon at lawrence.org.uk Fri Feb 25 01:23:40 2005 From: jon at lawrence.org.uk (Jon Lawrence) Date: Fri, 25 Feb 2005 00:23:40 +0000 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <774d66623248c0bf50184883cee188ed@muada.com> References: <410E7D22.70904@ripe.net> <20050224230241.GZ14099@new.detebe.org> <774d66623248c0bf50184883cee188ed@muada.com> Message-ID: <200502250023.40458.jon@lawrence.org.uk> On Thursday 24 February 2005 23:36, Iljitsch van Beijnum wrote: > On 25-feb-05, at 0:02, Elmar K. Bins wrote: > > The real problem is DNS deployment > > in v6. v4 has 11 (14 by June) of our servers, spread world-wide; I'd > > like to do the same with v6 servers, but I simply can't. > > > > Every f***ing registry on the planet has the special assignment policy > > (with very strict rules, mind you), except for the one they always > > send me back to ("sorry, not our business, you're in the RIPE region"). > > Well, there are more than a hundred TLDs and if they all want 11 IPv6 > prefixes that would inflate the v6 table by more than 150%. > > I think a reasonable proposal from a good portion of the TLD community > would go a long way, though. > > >> Of course the underlying question returns to "how to do IPv6 > >> multihoming > >> for A Special End Site". > > Everyone thinks they're special. That's how you get large routing > tables. yep - I'm special :). But the roots are more special. I want multihoming, until then v6 will NOT go mainstream. However, the roots really are a special case - There's no reason (at least none I can think of) why all the root's in the world couldn't be hosted out of a single /48, or rather a /48 for each region - which would avoid my nightmare of a single entity being able to control major internet resources. > (It's not _that_ long ago that the root servers got their addresses > from the organizations that hosted them.) and it's not that long ago that my laptop would have taken up your entire house - you point is ? > > Is everybody busy waiting for the IETF v6-multihoming group to come > > to a conclusion? > > In that case you won't have to wait much longer as this is going to > happen within a few weeks. However, the multi6 mechanisms (that still > have to be developed) aren't very suitable for multihoming DNS service. Be interesting to see what they come back with. How can multihoming be suitable to one kind of service and not another - I'll wait 'til they publish they're docs, you can explain then Iljitsch :) (unless we're talking locators again). As I said above, the roots are a special case - end of story - we cannot live without them (slight exaggeration). Why can't a /48 be set a side for the root servers in each region (or even a global /32). Jon From rogerj at jorgensen.no Thu Feb 24 22:42:44 2005 From: rogerj at jorgensen.no (Roger Jorgensen) Date: Thu, 24 Feb 2005 22:42:44 +0100 (CET) Subject: [address-policy-wg] Re: [ipv6-wg@ripe.net] IPv6 access to K-root In-Reply-To: <9bba11348129f99d6a700921cc6e89c1@muada.com> References: <410E7D22.70904@ripe.net> <9bba11348129f99d6a700921cc6e89c1@muada.com> Message-ID: sorry for replying to this to all of the mailinglist. On Thu, 24 Feb 2005, Iljitsch van Beijnum wrote: > inet6num: 2001:07FD::/32 > netname: K-rootserver-net-20030829 > descr: This assignment given to k-root.server.net > > I believe this ASSIGNment is in violation of existing IPv6 ALLOCATION > policies. I would be very interested in learning any information to the > contrary. This is pointless discussion, only point of it would maybe be to making it clear that the VERY few DNS _root-servers_ there are out there, are the ONLY thing important enough to get it's own /32. -- ------------------------------ Roger Jorgensen | rogerj at stud.cs.uit.no | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no ------------------------------------------------------- From woeber at cc.univie.ac.at Fri Feb 25 09:22:27 2005 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 25 Feb 2005 10:22:27 +0200 Subject: [address-policy-wg] IPv6 access to K-root Message-ID: <00A3FEAC.5E69931E.3@cc.univie.ac.at> >As I said above, the roots are a special case - end of story - we cannot live >without them (slight exaggeration). Why can't a /48 be set a side for the >root servers in each region (or even a global /32). 1st answer that springs to my mind: SPOF. >Jon DoSing the whole gang would only require me to break or target 1 prefix... Wilfried. From woeber at cc.univie.ac.at Fri Feb 25 09:32:06 2005 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 25 Feb 2005 10:32:06 +0200 Subject: [address-policy-wg] Re: [ipv6-wg@ripe.net] IPv6 access to K-root Message-ID: <00A3FEAD.B7C3C2EE.5@cc.univie.ac.at> >At the time the policy was written, people thought that this way would >be better. On the subject of root servers, people tend to be conservative. ...and I think this is a very reasonable approch. >OTOH, no policy that can't be changed if people think otherwise today. Yes, this is what we have this forum for. Otoh, I think we (the community, not the registry) should take care of providing some stability in address distribution policy. Starting to play "channel hopping" on the management plane is not going to be funny for those who provide these services for us. Let me add that I think the same holds true by and large for ccTLD operators... >Gert Doering > -- NetMaster Wilfried. From kurtis at kurtis.pp.se Fri Feb 25 17:53:42 2005 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Fri, 25 Feb 2005 17:53:42 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <200502250023.40458.jon@lawrence.org.uk> References: <410E7D22.70904@ripe.net> <20050224230241.GZ14099@new.detebe.org> <774d66623248c0bf50184883cee188ed@muada.com> <200502250023.40458.jon@lawrence.org.uk> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 25, 2005, at 1:23 AM, Jon Lawrence wrote: > On Thursday 24 February 2005 23:36, Iljitsch van Beijnum wrote: >> On 25-feb-05, at 0:02, Elmar K. Bins wrote: >> Everyone thinks they're special. That's how you get large routing >> tables. > > yep - I'm special :). But the roots are more special. > I want multihoming, until then v6 will NOT go mainstream. > However, the roots really are a special case - There's no reason (at > least > none I can think of) why all the root's in the world couldn't be > hosted out > of a single /48, or rather a /48 for each region - which would avoid my > nightmare of a single entity being able to control major internet > resources. Which single entity? And what would a single /48 give you? The above makes no sense to me. I think you need to add more text. >>> Is everybody busy waiting for the IETF v6-multihoming group to come >>> to a conclusion? >> >> In that case you won't have to wait much longer as this is going to >> happen within a few weeks. However, the multi6 mechanisms (that still >> have to be developed) aren't very suitable for multihoming DNS >> service. > > Be interesting to see what they come back with. > How can multihoming be suitable to one kind of service and not another > - I'll > wait 'til they publish they're docs, you can explain then Iljitsch :) > (unless > we're talking locators again). Documents are published. Protocol work will be done in new WG. Architecture published. Multi6 is closing in two weeks. Yes, there will be identifiers and locators. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQh9YGaarNKXTPFCVEQJzPgCg9oSbuFpfBsoxA4h/gWsNbN1vSVwAnR7j VipmsHiLNT0xpitAnghf7X0K =Sjhv -----END PGP SIGNATURE----- From jeroen at unfix.org Fri Feb 25 19:00:27 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 25 Feb 2005 19:00:27 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: References: <410E7D22.70904@ripe.net> <20050224230241.GZ14099@new.detebe.org> <774d66623248c0bf50184883cee188ed@muada.com> <200502250023.40458.jon@lawrence.org.uk> Message-ID: <1109354427.15464.61.camel@firenze.zurich.ibm.com> On Fri, 2005-02-25 at 17:53 +0100, Kurt Erik Lindqvist wrote: >On Feb 25, 2005, at 1:23 AM, Jon Lawrence wrote: >> >> Be interesting to see what they come back with. >> How can multihoming be suitable to one kind of service and not another >> - I'll >> wait 'til they publish they're docs, you can explain then Iljitsch :) >> (unless >> we're talking locators again). > >Documents are published. Protocol work will be done in new WG. >Architecture published. Multi6 is closing in two weeks. Yes, there will >be identifiers and locators. Shibby... eehmm Shim6 that is ;) Also for the folks complaining about rootservers getting a /32 and those not being available to ccTLD servers, why don't you move to the APNIC region, there even the .jp root has a /32.... 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 nils at druecke.strg-alt-entf.org Fri Feb 25 19:12:26 2005 From: nils at druecke.strg-alt-entf.org (Nils Ketelsen) Date: Fri, 25 Feb 2005 13:12:26 -0500 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <1109354427.15464.61.camel@firenze.zurich.ibm.com> References: <410E7D22.70904@ripe.net> <20050224230241.GZ14099@new.detebe.org> <774d66623248c0bf50184883cee188ed@muada.com> <200502250023.40458.jon@lawrence.org.uk> <1109354427.15464.61.camel@firenze.zurich.ibm.com> Message-ID: <20050225181226.GB13399@h8000.serverkompetenz.net> On Fri, Feb 25, 2005 at 07:00:27PM +0100, Jeroen Massar wrote: > Also for the folks complaining about rootservers getting a /32 and those > not being available to ccTLD servers, why don't you move to the APNIC > region, there even the .jp root has a /32.... And now the next question: If a ccTLD NS gets a /32, why shouldn't a Authoratitative NS for a real big number of Domains (of a domain hoster, for example) get a /32? What is the difference between a ccTLD Nameserver and any other authoritative NS? I think the problem is not, that ccTLD Nameservers do not get a assignment, the problem is much more general: Addresses are assigned in the way that suits ISPs quite nicely but for sites is a major pain in the rear end. As long as this does not change IPv6 will stay what it is today: A nice platform for testing and playing without any business relevance. Nils -- Der Minister nimmt fl?sternd den Bischof beim Arm: "Halt Du sie dumm - ich halt sie Arm" [Reinhard Mey, 'Sei Wachsam'] From kurtis at kurtis.pp.se Fri Feb 25 18:39:36 2005 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Fri, 25 Feb 2005 18:39:36 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <20050225000159.GA14099@new.detebe.org> References: <410E7D22.70904@ripe.net> <9bba11348129f99d6a700921cc6e89c1@muada.com> <20050224190254.GY14099@new.detebe.org> <20050224212605.GY84850@Space.Net> <20050224230241.GZ14099@new.detebe.org> <774d66623248c0bf50184883cee188ed@muada.com> <20050225000159.GA14099@new.detebe.org> Message-ID: <37EC6E40-8754-11D9-AC0B-000A95928574@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Elmar, On Feb 25, 2005, at 1:02 AM, Elmar K. Bins wrote: > >> Everyone thinks they're special. That's how you get large routing >> tables. > > Who gets to decide? We're talking infrastructure here. > > ARIN seems to have a picture of specialness quite different from RIPE's > view. If you ask me, it's closer to what's needed. > > And I cannot see the v6 train pulling out of the yard before the > infrastructure all people are accustomed to does speak IPv6. And I > mean: In the way it speaks v4, not in a lab environment or in mini- > scale. In real life some things are more special than others. At the same time there are ccTLDs who are already running their slaves on IPv6.... -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQh9i3aarNKXTPFCVEQI1SgCgu62f9KGM533PZe21vN4mFU0AqcUAoOm8 uesgJeVD4WOeKagJ70W67Z7v =JRIm -----END PGP SIGNATURE----- From kurtis at kurtis.pp.se Fri Feb 25 19:14:59 2005 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Fri, 25 Feb 2005 19:14:59 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <1109354427.15464.61.camel@firenze.zurich.ibm.com> References: <410E7D22.70904@ripe.net> <20050224230241.GZ14099@new.detebe.org> <774d66623248c0bf50184883cee188ed@muada.com> <200502250023.40458.jon@lawrence.org.uk> <1109354427.15464.61.camel@firenze.zurich.ibm.com> Message-ID: <28E94030-8759-11D9-AC0B-000A95928574@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 25, 2005, at 7:00 PM, Jeroen Massar wrote: > Also for the folks complaining about rootservers getting a /32 and > those > not being available to ccTLD servers, why don't you move to the APNIC > region, there even the .jp root has a /32.... Well, in JP you also have to get your addresses from a NIR and you will have a local whoisdb in Japaneese...etc...it's a different model entirely. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQh9rKKarNKXTPFCVEQLYiQCfUxRhS0Ueb9o7KXiY1eb6WfPHvhsAoOHg xtDIMvMtAEUId01dRZHIBCj8 =pU8e -----END PGP SIGNATURE----- From iljitsch at muada.com Fri Feb 25 19:25:25 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 25 Feb 2005 19:25:25 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <20050225181226.GB13399@h8000.serverkompetenz.net> References: <410E7D22.70904@ripe.net> <20050224230241.GZ14099@new.detebe.org> <774d66623248c0bf50184883cee188ed@muada.com> <200502250023.40458.jon@lawrence.org.uk> <1109354427.15464.61.camel@firenze.zurich.ibm.com> <20050225181226.GB13399@h8000.serverkompetenz.net> Message-ID: <5802b31ad61a8e87d7d99f20c8bd3a10@muada.com> On 25-feb-05, at 19:12, Nils Ketelsen wrote: > And now the next question: If a ccTLD NS gets a /32, why shouldn't a > Authoratitative NS for a real big number of Domains (of a domain > hoster, for > example) get a /32? What is the difference between a ccTLD Nameserver > and > any other authoritative NS? And if a big nameserver gets a /32, why doesn't a bank? I mean, most people value getting at their money more than getting at their homepage. But if the bank gets to multihome, then why not large etailers? And if the large ones get to, what about the medium-sized ones? > I think the problem is not, that ccTLD Nameservers do not get a > assignment, > the problem is much more general: Addresses are assigned in the way > that > suits ISPs quite nicely but for sites is a major pain in the rear end. ISPs know that keeping the routing infrastructure working is very important. End-users generally don't. > As long as this does not change IPv6 will stay what it is today: A nice > platform for testing and playing without any business relevance. And if we give everyone PI IPv6 will probably blow up even sooner than IPv4 so we can start again from scratch. From iljitsch at muada.com Fri Feb 25 19:28:06 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 25 Feb 2005 19:28:06 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <28E94030-8759-11D9-AC0B-000A95928574@kurtis.pp.se> References: <410E7D22.70904@ripe.net> <20050224230241.GZ14099@new.detebe.org> <774d66623248c0bf50184883cee188ed@muada.com> <200502250023.40458.jon@lawrence.org.uk> <1109354427.15464.61.camel@firenze.zurich.ibm.com> <28E94030-8759-11D9-AC0B-000A95928574@kurtis.pp.se> Message-ID: On 25-feb-05, at 19:14, Kurt Erik Lindqvist wrote: >> Also for the folks complaining about rootservers getting a /32 and >> those not being available to ccTLD servers, why don't you move to the >> APNIC >> region, there even the .jp root has a /32.... > Well, in JP you also have to get your addresses from a NIR and you will > have a local whoisdb in Japaneese...etc...it's a different model > entirely. How is it different if this japanese /32 is in my routing tables? I'm getting pretty tired of this IP business. Maybe I should do something easy for a living, like breeding flying pigs. From jeroen at unfix.org Fri Feb 25 19:38:43 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 25 Feb 2005 19:38:43 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: References: <410E7D22.70904@ripe.net> <20050224230241.GZ14099@new.detebe.org> <774d66623248c0bf50184883cee188ed@muada.com> <200502250023.40458.jon@lawrence.org.uk> <1109354427.15464.61.camel@firenze.zurich.ibm.com> <28E94030-8759-11D9-AC0B-000A95928574@kurtis.pp.se> Message-ID: <1109356723.18851.7.camel@firenze.zurich.ibm.com> On Fri, 2005-02-25 at 19:28 +0100, Iljitsch van Beijnum wrote: >On 25-feb-05, at 19:14, Kurt Erik Lindqvist wrote: > >>> Also for the folks complaining about rootservers getting a /32 and >>> those not being available to ccTLD servers, why don't you move to the >>> APNIC >>> region, there even the .jp root has a /32.... > >> Well, in JP you also have to get your addresses from a NIR and you will >> have a local whoisdb in Japaneese...etc...it's a different model >> entirely. > >How is it different if this japanese /32 is in my routing tables? Just setup shop in Japan and experience it yourself ;) >I'm getting pretty tired of this IP business. Maybe I should do >something easy for a living, like breeding flying pigs. Oeh neat, as long as you attach them to a strong enough wire and don't let them drop their droplets in my backyard ;) On Fri, 2005-02-25 at 13:12 -0500, Nils Ketelsen wrote: >On Fri, Feb 25, 2005 at 07:00:27PM +0100, Jeroen Massar wrote: > >> Also for the folks complaining about rootservers getting a /32 and those >> not being available to ccTLD servers, why don't you move to the APNIC >> region, there even the .jp root has a /32.... > >And now the next question: If a ccTLD NS gets a /32, why shouldn't a >Authoratitative NS for a real big number of Domains (of a domain hoster, for >example) get a /32? What is the difference between a ccTLD Nameserver and >any other authoritative NS? Let me see, in the current RIPE allocation list*, there is a school at 2001:4b20::/32 consisting of basically two buildings, there is a registrar at 2001:4b98::/32, who do not do hosting I guess. And there are a really large number of "ISP's" who really do not have more than 2 19" racks worth of equipment. I really wonder why people are complaining that they can't get a prefix. Really, if you are not able to become LIR, and get a prefix, while they quite apparently can, then you should simply quit change your job IMHO. Greets, Jeroen *, see http://www.sixxs.net/tools/grh/tla/ripe/ -------------- 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 elmi at 4ever.de Fri Feb 25 20:03:57 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Fri, 25 Feb 2005 20:03:57 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <37EC6E40-8754-11D9-AC0B-000A95928574@kurtis.pp.se> References: <410E7D22.70904@ripe.net> <9bba11348129f99d6a700921cc6e89c1@muada.com> <20050224190254.GY14099@new.detebe.org> <20050224212605.GY84850@Space.Net> <20050224230241.GZ14099@new.detebe.org> <774d66623248c0bf50184883cee188ed@muada.com> <20050225000159.GA14099@new.detebe.org> <37EC6E40-8754-11D9-AC0B-000A95928574@kurtis.pp.se> Message-ID: <20050225190357.GL14099@new.detebe.org> kurtis at kurtis.pp.se (Kurt Erik Lindqvist) wrote: > > And I cannot see the v6 train pulling out of the yard before the > > infrastructure all people are accustomed to does speak IPv6. And I > > mean: In the way it speaks v4, not in a lab environment or in mini- > > scale. In real life some things are more special than others. > > At the same time there are ccTLDs who are already running their slaves > on IPv6.... Oh, we certainly are. Two sets on two v6 addresses I cannot anycast, since they are somebody else's PA. Contrast this with eleven/fifteen v4 sets on five unicast (provider PA) and one anycast v4 (PI) address. Like Nils said, that's not real business, it's not even a start. Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, ) --------------------------------------------------------------[ ELMI-RIPE ]--- From elmi at 4ever.de Fri Feb 25 20:04:31 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Fri, 25 Feb 2005 20:04:31 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <28E94030-8759-11D9-AC0B-000A95928574@kurtis.pp.se> References: <410E7D22.70904@ripe.net> <20050224230241.GZ14099@new.detebe.org> <774d66623248c0bf50184883cee188ed@muada.com> <200502250023.40458.jon@lawrence.org.uk> <1109354427.15464.61.camel@firenze.zurich.ibm.com> <28E94030-8759-11D9-AC0B-000A95928574@kurtis.pp.se> Message-ID: <20050225190431.GM14099@new.detebe.org> kurtis at kurtis.pp.se (Kurt Erik Lindqvist) wrote: > Well, in JP you also have to get your addresses from a NIR and you will > have a local whoisdb in Japaneese...etc...it's a different model > entirely. Which, as the ITU proposes, we'll face with v6 anyway. Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, ) --------------------------------------------------------------[ ELMI-RIPE ]--- From nils at druecke.strg-alt-entf.org Fri Feb 25 20:42:54 2005 From: nils at druecke.strg-alt-entf.org (Nils Ketelsen) Date: Fri, 25 Feb 2005 14:42:54 -0500 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <1109356723.18851.7.camel@firenze.zurich.ibm.com> References: <410E7D22.70904@ripe.net> <20050224230241.GZ14099@new.detebe.org> <774d66623248c0bf50184883cee188ed@muada.com> <200502250023.40458.jon@lawrence.org.uk> <1109354427.15464.61.camel@firenze.zurich.ibm.com> <28E94030-8759-11D9-AC0B-000A95928574@kurtis.pp.se> <1109356723.18851.7.camel@firenze.zurich.ibm.com> Message-ID: <20050225194254.GB14050@h8000.serverkompetenz.net> On Fri, Feb 25, 2005 at 07:38:43PM +0100, Jeroen Massar wrote: > Let me see, in the current RIPE allocation list*, there is a school > at 2001:4b20::/32 consisting of basically two buildings, there is a registrar > at 2001:4b98::/32, who do not do hosting I guess. And there are a really large > number of "ISP's" who really do not have more than 2 19" racks worth of equipment. > > I really wonder why people are complaining that they can't get a prefix. > Really, if you are not able to become LIR, and get a prefix, while they quite > apparently can, then you should simply quit change your job IMHO. So, what you are saying is, that the current policy is good, because it can be bypassed by just lying? Call me old fashioned, but I think lying is a bad thing, that you do not do just because you have an advantage of it. I'd rather go the rough way and try to fix the policy that encourages this kind of behaviour instead of the easy way. Nils -- Newsreaders still feel it is worth a special and rather worrying mention if, for instance, a crime was planned by people over the Internet. They don't bother to mention when criminals use the telephone or the M4, or discuss their dastardly plans over a cup of tea. -- Douglas Adams -- From jeroen at unfix.org Fri Feb 25 21:00:05 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 25 Feb 2005 21:00:05 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <20050225194254.GB14050@h8000.serverkompetenz.net> References: <410E7D22.70904@ripe.net> <20050224230241.GZ14099@new.detebe.org> <774d66623248c0bf50184883cee188ed@muada.com> <200502250023.40458.jon@lawrence.org.uk> <1109354427.15464.61.camel@firenze.zurich.ibm.com> <28E94030-8759-11D9-AC0B-000A95928574@kurtis.pp.se> <1109356723.18851.7.camel@firenze.zurich.ibm.com> <20050225194254.GB14050@h8000.serverkompetenz.net> Message-ID: <1109361605.20338.8.camel@firenze.zurich.ibm.com> On Fri, 2005-02-25 at 14:42 -0500, Nils Ketelsen wrote: >On Fri, Feb 25, 2005 at 07:38:43PM +0100, Jeroen Massar wrote: > >> Let me see, in the current RIPE allocation list*, there is a school >> at 2001:4b20::/32 consisting of basically two buildings, there is a registrar >> at 2001:4b98::/32, who do not do hosting I guess. And there are a really large >> number of "ISP's" who really do not have more than 2 19" racks worth of equipment. >> >> I really wonder why people are complaining that they can't get a prefix. >> Really, if you are not able to become LIR, and get a prefix, while they quite >> apparently can, then you should simply quit change your job IMHO. > > >So, what you are saying is, that the current policy is good, because it can >be bypassed by just lying? If you say they are lying, then complain to RIPE NCC that they are doing their jobs wrongly. Apparently everybody who has gotten an allocation up to now have been able to reason that they need the allocation under the current policies. If you are not able to do so, though luck, you most likely don't need it in the first place then. 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 kurtis at kurtis.pp.se Sat Feb 26 20:19:02 2005 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Sat, 26 Feb 2005 20:19:02 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: References: <410E7D22.70904@ripe.net> <20050224230241.GZ14099@new.detebe.org> <774d66623248c0bf50184883cee188ed@muada.com> <200502250023.40458.jon@lawrence.org.uk> <1109354427.15464.61.camel@firenze.zurich.ibm.com> <28E94030-8759-11D9-AC0B-000A95928574@kurtis.pp.se> Message-ID: <45E001C2-882B-11D9-AC0B-000A95928574@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 25, 2005, at 19:28, Iljitsch van Beijnum wrote: > On 25-feb-05, at 19:14, Kurt Erik Lindqvist wrote: > >>> Also for the folks complaining about rootservers getting a /32 and >>> those not being available to ccTLD servers, why don't you move to >>> the APNIC >>> region, there even the .jp root has a /32.... > >> Well, in JP you also have to get your addresses from a NIR and you >> will >> have a local whoisdb in Japaneese...etc...it's a different model >> entirely. > > How is it different if this japanese /32 is in my routing tables? > > I'm getting pretty tired of this IP business. Maybe I should do > something easy for a living, like breeding flying pigs. I was referring to the fact that we don't have NIRs under RIPE. That is different. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQiDLqKarNKXTPFCVEQJT5gCfWLZiIZD6FHjJ5nmnq7L6LppLbwMAoICe xle15MbmI+STqX6Vww91q21d =m6EI -----END PGP SIGNATURE----- From kurtis at kurtis.pp.se Sat Feb 26 20:21:47 2005 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Sat, 26 Feb 2005 20:21:47 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <20050225190357.GL14099@new.detebe.org> References: <410E7D22.70904@ripe.net> <9bba11348129f99d6a700921cc6e89c1@muada.com> <20050224190254.GY14099@new.detebe.org> <20050224212605.GY84850@Space.Net> <20050224230241.GZ14099@new.detebe.org> <774d66623248c0bf50184883cee188ed@muada.com> <20050225000159.GA14099@new.detebe.org> <37EC6E40-8754-11D9-AC0B-000A95928574@kurtis.pp.se> <20050225190357.GL14099@new.detebe.org> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 25, 2005, at 20:03, Elmar K. Bins wrote: > Contrast this with eleven/fifteen v4 sets on five unicast (provider PA) > and one anycast v4 (PI) address. So what you are _really_ arguing (or should be) is that you can get PA IPv4 but does not qualify for PA IPv6. That is something completely different, and I think we more or less have agreed in the RIPE region that this difference needs to be fixed... - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQiDMTaarNKXTPFCVEQKV3ACgrjygZtuNmsMEvmkKr3C5tBDI/AUAnjAc eiqoDFUmFetqUbcu3+mwMInk =DEFZ -----END PGP SIGNATURE----- From kurtis at kurtis.pp.se Sat Feb 26 20:22:37 2005 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Sat, 26 Feb 2005 20:22:37 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <20050225190431.GM14099@new.detebe.org> References: <410E7D22.70904@ripe.net> <20050224230241.GZ14099@new.detebe.org> <774d66623248c0bf50184883cee188ed@muada.com> <200502250023.40458.jon@lawrence.org.uk> <1109354427.15464.61.camel@firenze.zurich.ibm.com> <28E94030-8759-11D9-AC0B-000A95928574@kurtis.pp.se> <20050225190431.GM14099@new.detebe.org> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 25, 2005, at 20:04, Elmar K. Bins wrote: > kurtis at kurtis.pp.se (Kurt Erik Lindqvist) wrote: > >> Well, in JP you also have to get your addresses from a NIR and you >> will >> have a local whoisdb in Japaneese...etc...it's a different model >> entirely. > > Which, as the ITU proposes, we'll face with v6 anyway. > Well, instead of RIPE dinners we will just have to used to do coctail-parties in Geneva in suits. At least the skiing is good :-) - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQiDMf6arNKXTPFCVEQIwFgCfZAfGZlOc2dPRTZnLVPr8EeJCBH8Anj/I FVs/JQVWpkP7jbuYQ0GKAKa8 =gTiA -----END PGP SIGNATURE----- From pk at DENIC.DE Sun Feb 27 11:33:37 2005 From: pk at DENIC.DE (Peter Koch) Date: Sun, 27 Feb 2005 11:33:37 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <20050225181226.GB13399@h8000.serverkompetenz.net> References: <410E7D22.70904@ripe.net> <20050224230241.GZ14099@new.detebe.org> <774d66623248c0bf50184883cee188ed@muada.com> <200502250023.40458.jon@lawrence.org.uk> <1109354427.15464.61.camel@firenze.zurich.ibm.com> <20050225181226.GB13399@h8000.serverkompetenz.net> Message-ID: <20050227103337.GA2319@denics7.denic.de> Nils Ketelsen wrote: > And now the next question: If a ccTLD NS gets a /32, why shouldn't a > Authoratitative NS for a real big number of Domains (of a domain hoster, for > example) get a /32? What is the difference between a ccTLD Nameserver and > any other authoritative NS? just as a side note: it's not the number of domains/zones that matters here. In the case of a multi-zone server they are not forced to serve all zones from a single name or IP address, i.e. they can achieve resilience and load distribution by other means. Some problems may still be similar, though. -Peter From nils at steering-group.net Fri Feb 25 20:37:46 2005 From: nils at steering-group.net (Nils Ketelsen) Date: Fri, 25 Feb 2005 14:37:46 -0500 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <5802b31ad61a8e87d7d99f20c8bd3a10@muada.com> References: <410E7D22.70904@ripe.net> <20050224230241.GZ14099@new.detebe.org> <774d66623248c0bf50184883cee188ed@muada.com> <200502250023.40458.jon@lawrence.org.uk> <1109354427.15464.61.camel@firenze.zurich.ibm.com> <20050225181226.GB13399@h8000.serverkompetenz.net> <5802b31ad61a8e87d7d99f20c8bd3a10@muada.com> Message-ID: <20050225193746.GA14050@h8000.serverkompetenz.net> On Fri, Feb 25, 2005 at 07:25:25PM +0100, Iljitsch van Beijnum wrote: > On 25-feb-05, at 19:12, Nils Ketelsen wrote: > >And now the next question: If a ccTLD NS gets a /32, why shouldn't a > >Authoratitative NS for a real big number of Domains (of a domain > >hoster, for > >example) get a /32? What is the difference between a ccTLD Nameserver > >and > >any other authoritative NS? > > And if a big nameserver gets a /32, why doesn't a bank? I mean, most > people value getting at their money more than getting at their > homepage. > > But if the bank gets to multihome, then why not large etailers? > > And if the large ones get to, what about the medium-sized ones? That is exactly my point, yes. > >I think the problem is not, that ccTLD Nameservers do not get a > >assignment, > >the problem is much more general: Addresses are assigned in the way > >that > >suits ISPs quite nicely but for sites is a major pain in the rear end. > > ISPs know that keeping the routing infrastructure working is very > important. End-users generally don't. This approach has two major flaws: 1. If a Service Provider starts to decide what is good for his customers and what they should not get, their business is usually at their end of life. As long as ISPs do whats good for them, instead of what their customers want, in the IPv6 world, IPv6 stays a provider toy. 2. You try to solve a technical problem with policies, which works as well as trying to fix politics with technical solutions. I have said it more then once and I still believe it: Routers will be able to handle Billions of routing table entries long before anyone will invest huge amounts of money to migrate his current infrastructure to a new one that provides far less features. > >As long as this does not change IPv6 will stay what it is today: A nice > >platform for testing and playing without any business relevance. > And if we give everyone PI IPv6 will probably blow up even sooner than > IPv4 so we can start again from scratch. If you don't, you will have a small routing table and no customers sending any packets you can route. Nils -- Would you like to play a game? From iljitsch at muada.com Mon Feb 28 09:58:07 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 28 Feb 2005 09:58:07 +0100 Subject: [address-policy-wg] Re: [ipv6-wg@ripe.net] IPv6 access to K-root In-Reply-To: <4222DA29.7080208@sara.nl> References: <410E7D22.70904@ripe.net> <9bba11348129f99d6a700921cc6e89c1@muada.com> <20050224190254.GY14099@new.detebe.org> <20050224212605.GY84850@Space.Net> <4222DA29.7080208@sara.nl> Message-ID: On 28-feb-05, at 9:45, Marco Davids (SARA) wrote: >> There is no special case policy for (unicast) ccTLD name servers, for >> major search engines, big software vendor download sites, etc. -> find >> an upstream provider, get an IPv6 address block, and enter that in the >> relevant DNS zones. >> Of course the underlying question returns to "how to do IPv6 >> multihoming >> for A Special End Site". > I think gTLD's and ccTLD's would certainly qualify for their own IPv6 > space (for the purpose of being able to do proper multihoming). I strongly disagree. The DNS protocol has its own built-in redundancy, and changing addresses for TLD servers is not prohibitively difficult. So I see no reason why they should have PI addresses, especially since there is a significant number of TLDs and they all use several addresses. If those addresses would all become PI this would probably double the IPv6 routing table size at this point. (Granted, it's very small now, but still.) If TLD servers are anycast that _could_ be a reason for giving them PI space, but I think the TLD community first has to come up with coordinated plan for this, rather than just start giving out PI blocks and play "voldongen feit" game. (Sorry, it's monday morning, can't think of the English translation. In French it's "fait accompli".) From iljitsch at muada.com Mon Feb 28 10:02:21 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 28 Feb 2005 10:02:21 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <20050225193746.GA14050@h8000.serverkompetenz.net> References: <410E7D22.70904@ripe.net> <20050224230241.GZ14099@new.detebe.org> <774d66623248c0bf50184883cee188ed@muada.com> <200502250023.40458.jon@lawrence.org.uk> <1109354427.15464.61.camel@firenze.zurich.ibm.com> <20050225181226.GB13399@h8000.serverkompetenz.net> <5802b31ad61a8e87d7d99f20c8bd3a10@muada.com> <20050225193746.GA14050@h8000.serverkompetenz.net> Message-ID: On 25-feb-05, at 20:37, Nils Ketelsen wrote: >>> As long as this does not change IPv6 will stay what it is today: A >>> nice >>> platform for testing and playing without any business relevance. >> And if we give everyone PI IPv6 will probably blow up even sooner than >> IPv4 so we can start again from scratch. > If you don't, you will have a small routing table and no customers > sending > any packets you can route. Fortunately we don't have to give everyone PI to make IPv6 a good place to be. Less than 20000 people have an AS in the IPv4 table currently, and somehow the rest of us manage to get by. So let's give the multi6/shim6 stuff a chance to work rather than start messing up IPv6 now. There will still be plenty of time to do that later. From elmi at 4ever.de Mon Feb 28 10:11:27 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Mon, 28 Feb 2005 10:11:27 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: References: <410E7D22.70904@ripe.net> <9bba11348129f99d6a700921cc6e89c1@muada.com> <20050224190254.GY14099@new.detebe.org> <20050224212605.GY84850@Space.Net> <20050224230241.GZ14099@new.detebe.org> <774d66623248c0bf50184883cee188ed@muada.com> <20050225000159.GA14099@new.detebe.org> <37EC6E40-8754-11D9-AC0B-000A95928574@kurtis.pp.se> <20050225190357.GL14099@new.detebe.org> Message-ID: <20050228091127.GA51702@new.detebe.org> kurtis at kurtis.pp.se (Kurt Erik Lindqvist) wrote: > > Contrast this with eleven/fifteen v4 sets on five unicast (provider PA) > > and one anycast v4 (PI) address. > > So what you are _really_ arguing (or should be) is that you can get PA > IPv4 but does not qualify for PA IPv6. That is something completely We're a LIR, so naturally (!) we have our v4 PA. Funny enough, a v6 PA seems out of the question. Were this an ordinary end-site, I'd have no problem with it; unfortunately, I have to overcome a few things which includes rolling out a heap of name servers. As Iljitsch said, DNS has built-in redundancy. Unfortunately, it's still limited. The biggest obstacle is the 510-byte answer packet that can only be circumvented by anycasting the stuff (which of course is impossible with a PA assignment). The next biggest obstacle, of course, is that some people simply refuse to listen. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, ) --------------------------------------------------------------[ ELMI-RIPE ]--- From jeroen at unfix.org Mon Feb 28 10:34:59 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 28 Feb 2005 10:34:59 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: References: <410E7D22.70904@ripe.net> <20050224230241.GZ14099@new.detebe.org> <774d66623248c0bf50184883cee188ed@muada.com> <200502250023.40458.jon@lawrence.org.uk> <1109354427.15464.61.camel@firenze.zurich.ibm.com> <28E94030-8759-11D9-AC0B-000A95928574@kurtis.pp.se> <20050225190431.GM14099@new.detebe.org> Message-ID: <1109583299.9918.16.camel@firenze.zurich.ibm.com> On Sat, 2005-02-26 at 20:22 +0100, Kurt Erik Lindqvist wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > >On Feb 25, 2005, at 20:04, Elmar K. Bins wrote: > >> kurtis at kurtis.pp.se (Kurt Erik Lindqvist) wrote: >> >>> Well, in JP you also have to get your addresses from a NIR and you >>> will >>> have a local whoisdb in Japaneese...etc...it's a different model >>> entirely. On the whois front I am actually extremely happy that AFRINIC got raised by RIPE as they will get the goody neato RIPE whoisdb software that at least is consistent, parsable and best of all supports CIDR. (ARIN doesn't support CIDR, though some queries they seem to strip off the /32 etc., they should simply upgrade to the RIPE version, which APNIC also uses, and then kick LACNIC to do the same) >> Which, as the ITU proposes, we'll face with v6 anyway. >> >Well, instead of RIPE dinners we will just have to used to do >coctail-parties in Geneva in suits. At least the skiing is good :-) /me raises hand for the skiing! Though I do hope you mean a ski-suite, I don't wear ties and with the current tendency of -15 on the slopes, a normal suit will be quite chilly :) As for the IETF, shim6 WG, yes indeed give this a chance, I am quite sure this is going to work out for most people, except for the ones who really have only one thing on their minds: an entry in the routing table to be really cool and interresting. But that part should simply be like the IPv6 allocations are supposed to be: if you are a large ISP, providing for a lot (200+ seems a nice limit) customers, you are entitled a place in the routing entry, the rest can shim6, they usually don't have their own infrastructure anyways... (no your home network does not count ;) 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 gert at space.net Mon Feb 28 10:51:41 2005 From: gert at space.net (Gert Doering) Date: Mon, 28 Feb 2005 10:51:41 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <20050228091127.GA51702@new.detebe.org> References: <9bba11348129f99d6a700921cc6e89c1@muada.com> <20050224190254.GY14099@new.detebe.org> <20050224212605.GY84850@Space.Net> <20050224230241.GZ14099@new.detebe.org> <774d66623248c0bf50184883cee188ed@muada.com> <20050225000159.GA14099@new.detebe.org> <37EC6E40-8754-11D9-AC0B-000A95928574@kurtis.pp.se> <20050225190357.GL14099@new.detebe.org> <20050228091127.GA51702@new.detebe.org> Message-ID: <20050228095141.GZ84850@Space.Net> Hi, On Mon, Feb 28, 2005 at 10:11:27AM +0100, Elmar K. Bins wrote: > Were this an ordinary end-site, I'd have no problem with it; unfortunately, > I have to overcome a few things which includes rolling out a heap of name > servers. As Iljitsch said, DNS has built-in redundancy. Unfortunately, it's > still limited. The biggest obstacle is the 510-byte answer packet that can > only be circumvented by anycasting the stuff (which of course is impossible > with a PA assignment). This is supposed to be fixed by the "anycast policy proposal", which is in the works (proposed by Andreas Baess, and being delayed since months because Andreas was distracted by things like IDN domains). Please don't intermix "generic PI to end-users", "IPv6 multihoming", "critical infrastructure" and "ancast address space" issues - it will just create a very blurred picture, where everybody is argueing about something else. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) 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 elmi at 4ever.de Mon Feb 28 11:37:49 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Mon, 28 Feb 2005 11:37:49 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <20050228095141.GZ84850@Space.Net> References: <20050224190254.GY14099@new.detebe.org> <20050224212605.GY84850@Space.Net> <20050224230241.GZ14099@new.detebe.org> <774d66623248c0bf50184883cee188ed@muada.com> <20050225000159.GA14099@new.detebe.org> <37EC6E40-8754-11D9-AC0B-000A95928574@kurtis.pp.se> <20050225190357.GL14099@new.detebe.org> <20050228091127.GA51702@new.detebe.org> <20050228095141.GZ84850@Space.Net> Message-ID: <20050228103749.GE51702@new.detebe.org> gert at space.net (Gert Doering) wrote: > This is supposed to be fixed by the "anycast policy proposal", which is in > the works (proposed by Andreas Baess, and being delayed since months > because Andreas was distracted by things like IDN domains). So it's inhouse. Unfortunately, Andreas is on holiday, but I am confident he'll push this forward as soon as he's back. I was under the wrong assumption, the paper had already been submitted... > Please don't intermix "generic PI to end-users", "IPv6 multihoming", > "critical infrastructure" and "ancast address space" issues - it will > just create a very blurred picture, where everybody is argueing about > something else. Well, this is a v6 multihoming, critical (isn't everybody?), anycasting end-user... it actually _is_ intermixed and blurry. Oh, and regarding Iljitsch: The root/*tld server operators unfortunately can't force anyone to use EDNS0 compatible software. In theory, everything's simple. Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, ) --------------------------------------------------------------[ ELMI-RIPE ]--- From elmi at 4ever.de Mon Feb 28 11:41:11 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Mon, 28 Feb 2005 11:41:11 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <1109356723.18851.7.camel@firenze.zurich.ibm.com> References: <410E7D22.70904@ripe.net> <20050224230241.GZ14099@new.detebe.org> <774d66623248c0bf50184883cee188ed@muada.com> <200502250023.40458.jon@lawrence.org.uk> <1109354427.15464.61.camel@firenze.zurich.ibm.com> <28E94030-8759-11D9-AC0B-000A95928574@kurtis.pp.se> <1109356723.18851.7.camel@firenze.zurich.ibm.com> Message-ID: <20050228104111.GG51702@new.detebe.org> Jftr, > Let me see, in the current RIPE allocation list*, there is a school > at 2001:4b20::/32 consisting of basically two buildings, there is a registrar > at 2001:4b98::/32, who do not do hosting I guess. And there are a really large > number of "ISP's" who really do not have more than 2 19" racks worth of equipment. > > I really wonder why people are complaining that they can't get a prefix. > Really, if you are not able to become LIR, and get a prefix, while they quite > apparently can, then you should simply quit change your job IMHO. I've asked the school; they are no end-site, they provide ISP services for swiss schools. So, maybe you should rethink what you wrote above. Yours, Elmi. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, ) --------------------------------------------------------------[ ELMI-RIPE ]--- From iljitsch at muada.com Mon Feb 28 11:49:45 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 28 Feb 2005 11:49:45 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <20050228103749.GE51702@new.detebe.org> References: <20050224190254.GY14099@new.detebe.org> <20050224212605.GY84850@Space.Net> <20050224230241.GZ14099@new.detebe.org> <774d66623248c0bf50184883cee188ed@muada.com> <20050225000159.GA14099@new.detebe.org> <37EC6E40-8754-11D9-AC0B-000A95928574@kurtis.pp.se> <20050225190357.GL14099@new.detebe.org> <20050228091127.GA51702@new.detebe.org> <20050228095141.GZ84850@Space.Net> <20050228103749.GE51702@new.detebe.org> Message-ID: On 28-feb-05, at 11:37, Elmar K. Bins wrote: > Oh, and regarding Iljitsch: The root/*tld server operators > unfortunately > can't force anyone to use EDNS0 compatible software. In theory, > everything's simple. I think the intersection between the group that doesn't use EDNS0 and the group that supports IPv6 is negligible. And it any event, dropping IPv6 glue addresses from the response is hardly deadly. I can understand why the root people are somewhat concerned about the boot strapping thing, but for TLDs this isn't an issue. From elmi at 4ever.de Mon Feb 28 11:53:06 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Mon, 28 Feb 2005 11:53:06 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: References: <20050224230241.GZ14099@new.detebe.org> <774d66623248c0bf50184883cee188ed@muada.com> <20050225000159.GA14099@new.detebe.org> <37EC6E40-8754-11D9-AC0B-000A95928574@kurtis.pp.se> <20050225190357.GL14099@new.detebe.org> <20050228091127.GA51702@new.detebe.org> <20050228095141.GZ84850@Space.Net> <20050228103749.GE51702@new.detebe.org> Message-ID: <20050228105306.GB92550@new.detebe.org> iljitsch at muada.com (Iljitsch van Beijnum) wrote: > >Oh, and regarding Iljitsch: The root/*tld server operators > >unfortunately > >can't force anyone to use EDNS0 compatible software. In theory, > >everything's simple. > > I think the intersection between the group that doesn't use EDNS0 and > the group that supports IPv6 is negligible. And it any event, dropping > IPv6 glue addresses from the response is hardly deadly. I can > understand why the root people are somewhat concerned about the boot > strapping thing, but for TLDs this isn't an issue. I'll leave this part to Peter, since I'm not sure how to care for dropping the "correct" parts - I still believe we'll have to make sure the full set gets through to the requestor, and the dropping occurs there. And then you're again stuck with your 510 Byte limit. Unless...unless of course you can influence the order in which your $DNS_SOFTWARE outputs the records. Alas, I'm not comfortable with dropped content, so I favour the "smaller packet" approach. Anyway, Peter's turn :-) Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, ) --------------------------------------------------------------[ ELMI-RIPE ]--- From jeroen at unfix.org Mon Feb 28 11:55:10 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 28 Feb 2005 11:55:10 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <20050228104111.GG51702@new.detebe.org> References: <410E7D22.70904@ripe.net> <20050224230241.GZ14099@new.detebe.org> <774d66623248c0bf50184883cee188ed@muada.com> <200502250023.40458.jon@lawrence.org.uk> <1109354427.15464.61.camel@firenze.zurich.ibm.com> <28E94030-8759-11D9-AC0B-000A95928574@kurtis.pp.se> <1109356723.18851.7.camel@firenze.zurich.ibm.com> <20050228104111.GG51702@new.detebe.org> Message-ID: <1109588110.9918.74.camel@firenze.zurich.ibm.com> On Mon, 2005-02-28 at 11:41 +0100, Elmar K. Bins wrote: >Jftr, > >> Let me see, in the current RIPE allocation list*, there is a school >> at 2001:4b20::/32 consisting of basically two buildings, there is a registrar >> at 2001:4b98::/32, who do not do hosting I guess. And there are a really large >> number of "ISP's" who really do not have more than 2 19" racks worth of equipment. >> >> I really wonder why people are complaining that they can't get a prefix. >> Really, if you are not able to become LIR, and get a prefix, while they quite >> apparently can, then you should simply quit change your job IMHO. > >I've asked the school; they are no end-site, they provide ISP services for >swiss schools. I wonder why I could then only find two buildings in that place and why SWITCH (www.switch.ch) is already doing it for the rest of the universities and schools in Switzerland ;) 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 elmi at 4ever.de Mon Feb 28 11:57:07 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Mon, 28 Feb 2005 11:57:07 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <1109588110.9918.74.camel@firenze.zurich.ibm.com> References: <20050224230241.GZ14099@new.detebe.org> <774d66623248c0bf50184883cee188ed@muada.com> <200502250023.40458.jon@lawrence.org.uk> <1109354427.15464.61.camel@firenze.zurich.ibm.com> <28E94030-8759-11D9-AC0B-000A95928574@kurtis.pp.se> <1109356723.18851.7.camel@firenze.zurich.ibm.com> <20050228104111.GG51702@new.detebe.org> <1109588110.9918.74.camel@firenze.zurich.ibm.com> Message-ID: <20050228105707.GD92550@new.detebe.org> jeroen at unfix.org (Jeroen Massar) wrote: > >I've asked the school; they are no end-site, they provide ISP services for > >swiss schools. > > I wonder why I could then only find two buildings in that place and why > SWITCH (www.switch.ch) is already doing it for the rest of the > universities and schools in Switzerland ;) That you and I cannot find more information might be subject to us not having an employment contract with them... Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, ) --------------------------------------------------------------[ ELMI-RIPE ]--- From jeroen at unfix.org Mon Feb 28 14:22:14 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 28 Feb 2005 14:22:14 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <20050228105707.GD92550@new.detebe.org> References: <20050224230241.GZ14099@new.detebe.org> <774d66623248c0bf50184883cee188ed@muada.com> <200502250023.40458.jon@lawrence.org.uk> <1109354427.15464.61.camel@firenze.zurich.ibm.com> <28E94030-8759-11D9-AC0B-000A95928574@kurtis.pp.se> <1109356723.18851.7.camel@firenze.zurich.ibm.com> <20050228104111.GG51702@new.detebe.org> <1109588110.9918.74.camel@firenze.zurich.ibm.com> <20050228105707.GD92550@new.detebe.org> Message-ID: <1109596934.9918.87.camel@firenze.zurich.ibm.com> On Mon, 2005-02-28 at 11:57 +0100, Elmar K. Bins wrote: >jeroen at unfix.org (Jeroen Massar) wrote: > >> >I've asked the school; they are no end-site, they provide ISP services for >> >swiss schools. >> >> I wonder why I could then only find two buildings in that place and why >> SWITCH (www.switch.ch) is already doing it for the rest of the >> universities and schools in Switzerland ;) > >That you and I cannot find more information might be subject to us not >having an employment contract with them... It does not matter if there is more information of not, they have qualified for the space and that is it. The point was that if others are not capable then that is really their problem, they demonstrated that it is possible, like many others. 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 elmi at 4ever.de Mon Feb 28 14:54:15 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Mon, 28 Feb 2005 14:54:15 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <1109596934.9918.87.camel@firenze.zurich.ibm.com> References: <200502250023.40458.jon@lawrence.org.uk> <1109354427.15464.61.camel@firenze.zurich.ibm.com> <28E94030-8759-11D9-AC0B-000A95928574@kurtis.pp.se> <1109356723.18851.7.camel@firenze.zurich.ibm.com> <20050228104111.GG51702@new.detebe.org> <1109588110.9918.74.camel@firenze.zurich.ibm.com> <20050228105707.GD92550@new.detebe.org> <1109596934.9918.87.camel@firenze.zurich.ibm.com> Message-ID: <20050228135414.GK92550@new.detebe.org> jeroen at unfix.org (Jeroen Massar) wrote: > >That you and I cannot find more information might be subject to us not > >having an employment contract with them... > > It does not matter if there is more information of not, they have > qualified for the space and that is it. The point was that if others are > not capable then that is really their problem, they demonstrated that it > is possible, like many others. No. They are no end site (like you implicitly suspected), full stop. The end site problem still persists. Polemics doesn't help. Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, ) --------------------------------------------------------------[ ELMI-RIPE ]--- From jeroen at unfix.org Mon Feb 28 15:00:33 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 28 Feb 2005 15:00:33 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <20050228135414.GK92550@new.detebe.org> References: <200502250023.40458.jon@lawrence.org.uk> <1109354427.15464.61.camel@firenze.zurich.ibm.com> <28E94030-8759-11D9-AC0B-000A95928574@kurtis.pp.se> <1109356723.18851.7.camel@firenze.zurich.ibm.com> <20050228104111.GG51702@new.detebe.org> <1109588110.9918.74.camel@firenze.zurich.ibm.com> <20050228105707.GD92550@new.detebe.org> <1109596934.9918.87.camel@firenze.zurich.ibm.com> <20050228135414.GK92550@new.detebe.org> Message-ID: <1109599233.9918.106.camel@firenze.zurich.ibm.com> On Mon, 2005-02-28 at 14:54 +0100, Elmar K. Bins wrote: >jeroen at unfix.org (Jeroen Massar) wrote: > >> >That you and I cannot find more information might be subject to us not >> >having an employment contract with them... >> >> It does not matter if there is more information of not, they have >> qualified for the space and that is it. The point was that if others are >> not capable then that is really their problem, they demonstrated that it >> is possible, like many others. > >No. They are no end site (like you implicitly suspected), full stop. >The end site problem still persists. End sites should not get a entry in the global routing table. Full Stop ;) This is because end-sites are provided with IP by their upstreams. Full Stop. 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 dr at cluenet.de Mon Feb 28 15:06:56 2005 From: dr at cluenet.de (Daniel Roesen) Date: Mon, 28 Feb 2005 15:06:56 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <1109599233.9918.106.camel@firenze.zurich.ibm.com> References: <1109354427.15464.61.camel@firenze.zurich.ibm.com> <28E94030-8759-11D9-AC0B-000A95928574@kurtis.pp.se> <1109356723.18851.7.camel@firenze.zurich.ibm.com> <20050228104111.GG51702@new.detebe.org> <1109588110.9918.74.camel@firenze.zurich.ibm.com> <20050228105707.GD92550@new.detebe.org> <1109596934.9918.87.camel@firenze.zurich.ibm.com> <20050228135414.GK92550@new.detebe.org> <1109599233.9918.106.camel@firenze.zurich.ibm.com> Message-ID: <20050228140656.GA19221@srv01.cluenet.de> On Mon, Feb 28, 2005 at 03:00:33PM +0100, Jeroen Massar wrote: > End sites should not get a entry in the global routing table. Full > Stop ;) > > This is because end-sites are provided with IP by their upstreams. Full > Stop. ==> Large scale IPv6 adoption: Full Stop. Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From elmi at 4ever.de Mon Feb 28 15:52:33 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Mon, 28 Feb 2005 15:52:33 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <1109599233.9918.106.camel@firenze.zurich.ibm.com> References: <1109354427.15464.61.camel@firenze.zurich.ibm.com> <28E94030-8759-11D9-AC0B-000A95928574@kurtis.pp.se> <1109356723.18851.7.camel@firenze.zurich.ibm.com> <20050228104111.GG51702@new.detebe.org> <1109588110.9918.74.camel@firenze.zurich.ibm.com> <20050228105707.GD92550@new.detebe.org> <1109596934.9918.87.camel@firenze.zurich.ibm.com> <20050228135414.GK92550@new.detebe.org> <1109599233.9918.106.camel@firenze.zurich.ibm.com> Message-ID: <20050228145232.GN92550@new.detebe.org> jeroen at unfix.org (Jeroen Massar) wrote: > End sites should not get a entry in the global routing table. Full > Stop ;) This obviously doesn't conform to current RIPE v4 policies. Discrepancy to be solved. Apart from this I can't see a way to get you out of your ivory tower... Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, ) --------------------------------------------------------------[ ELMI-RIPE ]--- From jeroen at unfix.org Mon Feb 28 15:59:55 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 28 Feb 2005 15:59:55 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <20050228145232.GN92550@new.detebe.org> References: <1109354427.15464.61.camel@firenze.zurich.ibm.com> <28E94030-8759-11D9-AC0B-000A95928574@kurtis.pp.se> <1109356723.18851.7.camel@firenze.zurich.ibm.com> <20050228104111.GG51702@new.detebe.org> <1109588110.9918.74.camel@firenze.zurich.ibm.com> <20050228105707.GD92550@new.detebe.org> <1109596934.9918.87.camel@firenze.zurich.ibm.com> <20050228135414.GK92550@new.detebe.org> <1109599233.9918.106.camel@firenze.zurich.ibm.com> <20050228145232.GN92550@new.detebe.org> Message-ID: <1109602795.9918.131.camel@firenze.zurich.ibm.com> On Mon, 2005-02-28 at 15:52 +0100, Elmar K. Bins wrote: >jeroen at unfix.org (Jeroen Massar) wrote: > >> End sites should not get a entry in the global routing table. Full >> Stop ;) > >This obviously doesn't conform to current RIPE v4 policies. >Discrepancy to be solved. > >Apart from this I can't see a way to get you out of your ivory tower... Which ivory tower? The one with the big banner to the other big ivory tower containing the words that IPv4 routing policies do not equal the ones for IPv6? 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 elmi at 4ever.de Mon Feb 28 16:21:33 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Mon, 28 Feb 2005 16:21:33 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <1109602795.9918.131.camel@firenze.zurich.ibm.com> References: <1109356723.18851.7.camel@firenze.zurich.ibm.com> <20050228104111.GG51702@new.detebe.org> <1109588110.9918.74.camel@firenze.zurich.ibm.com> <20050228105707.GD92550@new.detebe.org> <1109596934.9918.87.camel@firenze.zurich.ibm.com> <20050228135414.GK92550@new.detebe.org> <1109599233.9918.106.camel@firenze.zurich.ibm.com> <20050228145232.GN92550@new.detebe.org> <1109602795.9918.131.camel@firenze.zurich.ibm.com> Message-ID: <20050228152133.GP92550@new.detebe.org> jeroen at unfix.org (Jeroen Massar) wrote: > >This obviously doesn't conform to current RIPE v4 policies. > >Discrepancy to be solved. > > > >Apart from this I can't see a way to get you out of your ivory tower... > > Which ivory tower? The one with the big banner to the other big ivory > tower containing the words that IPv4 routing policies do not equal the > ones for IPv6? More the like of that which Daniel referred to. Real-Life v6 will not happen unless certain infrastructure, often provided by end sites, is online. Maybe end sites need to be classified further. But then...let's await future discussions on the matter; I don't like preaching to walls, so maybe somebody else can turn the walls into something softer :-) Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, ) --------------------------------------------------------------[ ELMI-RIPE ]--- From gert at space.net Mon Feb 28 16:39:19 2005 From: gert at space.net (Gert Doering) Date: Mon, 28 Feb 2005 16:39:19 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <20050228152133.GP92550@new.detebe.org> References: <1109356723.18851.7.camel@firenze.zurich.ibm.com> <20050228104111.GG51702@new.detebe.org> <1109588110.9918.74.camel@firenze.zurich.ibm.com> <20050228105707.GD92550@new.detebe.org> <1109596934.9918.87.camel@firenze.zurich.ibm.com> <20050228135414.GK92550@new.detebe.org> <1109599233.9918.106.camel@firenze.zurich.ibm.com> <20050228145232.GN92550@new.detebe.org> <1109602795.9918.131.camel@firenze.zurich.ibm.com> <20050228152133.GP92550@new.detebe.org> Message-ID: <20050228153919.GS84850@Space.Net> Hi, On Mon, Feb 28, 2005 at 04:21:33PM +0100, Elmar K. Bins wrote: > Maybe end sites need to be classified further. But then...let's > await future discussions on the matter; I don't like preaching > to walls, so maybe somebody else can turn the walls into something > softer :-) So far, nobody has proposed a "globally visible v6 to " policy yet. People are clearly unhappy, and blaiming policies, but are not making specific proposals. One could start with the "critical infrastructure" policy from ARIN, but I keep saying that Google is much more critical to the average network user than one specific nameserver out of the NS set of a random ccTLD registry... Most large enterprises will think of themselves as much more important than anybody else. So it's not easy to come up with a set of rules "who is permitted to announce a globally visible prefix and who isn't". Nils seems to aim for "everybody is", which is something I'm afraid of... (and I don't see that "vendors will deliver routers that can handle $Billions of routes" anytime soon, seeing that vendors are still shipping "top of the line" products that can't do more than 256k IPv4 prefixes). OTOH, one might see this "IPv6 deployment isn't happening because we can't get addresses!!!" as a pretty lame excuse - /48 multihoming has serious problems, but if you really *want* to get started with IPv6, it works, for the time being. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) 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 elmi at 4ever.de Mon Feb 28 16:43:07 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Mon, 28 Feb 2005 16:43:07 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <20050228153919.GS84850@Space.Net> References: <20050228104111.GG51702@new.detebe.org> <1109588110.9918.74.camel@firenze.zurich.ibm.com> <20050228105707.GD92550@new.detebe.org> <1109596934.9918.87.camel@firenze.zurich.ibm.com> <20050228135414.GK92550@new.detebe.org> <1109599233.9918.106.camel@firenze.zurich.ibm.com> <20050228145232.GN92550@new.detebe.org> <1109602795.9918.131.camel@firenze.zurich.ibm.com> <20050228152133.GP92550@new.detebe.org> <20050228153919.GS84850@Space.Net> Message-ID: <20050228154306.GQ92550@new.detebe.org> gert at space.net (Gert Doering) wrote: > So far, nobody has proposed a > > "globally visible v6 to " > > policy yet. People are clearly unhappy, and blaiming policies, but are > not making specific proposals. Like said - it should have been underway already... > One could start with the "critical infrastructure" policy from ARIN, but > I keep saying that Google is much more critical to the average network > user than one specific nameserver out of the NS set of a random ccTLD > registry... Pah! (And yes, you're right) > still shipping "top of the line" products that can't do more than > 256k IPv4 prefixes). In the forwarding table, not in the BGP table. Or did I understand that wrongly? > OTOH, one might see this "IPv6 deployment isn't happening because > we can't get addresses!!!" as a pretty lame excuse - /48 multihoming > has serious problems, but if you really *want* to get started with IPv6, > it works, for the time being. ... as long as your transit providers know each other, agree not to filter, and you're happy with the fallback connectivity through the block owner. We're in a lucky position, not everybody is. But: I wouldn't dream of trying PI (v4 or v6) for our home location, my concern, as you know, is different. Yours, Elmi. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, ) --------------------------------------------------------------[ ELMI-RIPE ]--- From jeroen at unfix.org Mon Feb 28 17:08:29 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 28 Feb 2005 17:08:29 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <20050228154306.GQ92550@new.detebe.org> References: <20050228104111.GG51702@new.detebe.org> <1109588110.9918.74.camel@firenze.zurich.ibm.com> <20050228105707.GD92550@new.detebe.org> <1109596934.9918.87.camel@firenze.zurich.ibm.com> <20050228135414.GK92550@new.detebe.org> <1109599233.9918.106.camel@firenze.zurich.ibm.com> <20050228145232.GN92550@new.detebe.org> <1109602795.9918.131.camel@firenze.zurich.ibm.com> <20050228152133.GP92550@new.detebe.org> <20050228153919.GS84850@Space.Net> <20050228154306.GQ92550@new.detebe.org> Message-ID: <1109606909.9918.144.camel@firenze.zurich.ibm.com> On Mon, 2005-02-28 at 16:43 +0100, Elmar K. Bins wrote: >gert at space.net (Gert Doering) wrote: > >> So far, nobody has proposed a >> >> "globally visible v6 to " >> >> policy yet. People are clearly unhappy, and blaiming policies, but are >> not making specific proposals. > >Like said - it should have been underway already... As you so 'badly' want one, write something up and describe exactly what you want, now you are just running up to the walls. > >> still shipping "top of the line" products that can't do more than >> 256k IPv4 prefixes). > >In the forwarding table, not in the BGP table. Or did I understand >that wrongly? BGP is only 'limited' in the number of updates that can be handled. The likelyhood that more entries cause more updates will rise, next to that, we only have max ~60k ASN's anyway at this moment, thus even if every ASN would announce 1 IPv6 prefix it would stop at max ~60k entries... > >> OTOH, one might see this "IPv6 deployment isn't happening because >> we can't get addresses!!!" as a pretty lame excuse - /48 multihoming >> has serious problems, but if you really *want* to get started with IPv6, >> it works, for the time being. > >... as long as your transit providers know each other, agree not to >filter, and you're happy with the fallback connectivity through the >block owner. We're in a lucky position, not everybody is. You can also ask the other transit upstream to announce your /48 for you. Nevertheless, for real end-sites, like my house, most websites and other 'endsites', if you want to multihome, have some patience shim6 to be done or as Gert said, make a really neat proposal. Multihoming on IP is silly in most cases anyway, because most of the time the cable-path is the same, thus one single silly fiber cut would take you out anyhow... and if you can pay for multiple differentiated uplinks you are most likely also big enough to claim you (will) have 200 endsites. And indeed, this ivory wall says: endsites should use the upcoming shim6 mechanism for multihoming. 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 elmi at 4ever.de Mon Feb 28 17:14:56 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Mon, 28 Feb 2005 17:14:56 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <1109606909.9918.144.camel@firenze.zurich.ibm.com> References: <20050228105707.GD92550@new.detebe.org> <1109596934.9918.87.camel@firenze.zurich.ibm.com> <20050228135414.GK92550@new.detebe.org> <1109599233.9918.106.camel@firenze.zurich.ibm.com> <20050228145232.GN92550@new.detebe.org> <1109602795.9918.131.camel@firenze.zurich.ibm.com> <20050228152133.GP92550@new.detebe.org> <20050228153919.GS84850@Space.Net> <20050228154306.GQ92550@new.detebe.org> <1109606909.9918.144.camel@firenze.zurich.ibm.com> Message-ID: <20050228161456.GR92550@new.detebe.org> jeroen at unfix.org (Jeroen Massar) wrote: > >Like said - it should have been underway already... > > As you so 'badly' want one, write something up and describe exactly what > you want, now you are just running up to the walls. Maybe my english didn't make that clear: I have seen this proposal, and I've just been told it hadn't been submitted yet. > BGP is only 'limited' in the number of updates that can be handled. The > likelyhood that more entries cause more updates will rise, next to that, > we only have max ~60k ASN's anyway at this moment, thus even if every > ASN would announce 1 IPv6 prefix it would stop at max ~60k entries... The Sup720++ CAM tables are limited to 256K v4 entries, unless I've gotten that wrong and the boards also limit BGP paths (which I don't believe. > >... as long as your transit providers know each other, agree not to > >filter, and you're happy with the fallback connectivity through the > >block owner. We're in a lucky position, not everybody is. > > You can also ask the other transit upstream to announce your /48 for > you. Mind you, I prefer to advertise myself, and, as discussed, am in the lucky position that my transit ISPs are reasonable. > Nevertheless, for real end-sites, like my house, most websites and > other 'endsites', if you want to multihome, have some patience shim6 to > be done or as Gert said, make a really neat proposal. See above. I consider this "house" an end site that unfortunately needs real multihoming nonetheless. But I can live with a /48 PA multihoming solution. It works well. I do need a solution for the anycast thing and shim6 will not do it. > Multihoming on IP is silly in most cases anyway, because most of the > time the cable-path is the same, thus one single silly fiber cut would > take you out anyhow... We have taken great care that exactly this is untrue. > and if you can pay for multiple differentiated > uplinks you are most likely also big enough to claim you (will) have 200 > endsites. End sites are no ISPs. Try as I might, I will not have different companies as my customers. There seem to be different kinds of end-sites, maybe we are one type and you're the other. ;-) Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, ) --------------------------------------------------------------[ ELMI-RIPE ]--- From gert at space.net Mon Feb 28 17:45:24 2005 From: gert at space.net (Gert Doering) Date: Mon, 28 Feb 2005 17:45:24 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <20050228153919.GS84850@Space.Net> References: <20050228104111.GG51702@new.detebe.org> <1109588110.9918.74.camel@firenze.zurich.ibm.com> <20050228105707.GD92550@new.detebe.org> <1109596934.9918.87.camel@firenze.zurich.ibm.com> <20050228135414.GK92550@new.detebe.org> <1109599233.9918.106.camel@firenze.zurich.ibm.com> <20050228145232.GN92550@new.detebe.org> <1109602795.9918.131.camel@firenze.zurich.ibm.com> <20050228152133.GP92550@new.detebe.org> <20050228153919.GS84850@Space.Net> Message-ID: <20050228164524.GA41131@Space.Net> Hi, On Mon, Feb 28, 2005 at 04:39:19PM +0100, Gert Doering wrote: > So far, nobody has proposed a > > "globally visible v6 to " > > policy yet. People are clearly unhappy, and blaiming policies, but are > not making specific proposals. Just to stir discussion a bit... there's a policy proposal in the ARIN region to give a v6 network block to "every end site that qualifies for an AS number". http://www.arin.net/mailing_lists/ppml/3151.html (I'm purposely not commenting this at this time). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) 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 dr at cluenet.de Mon Feb 28 17:49:24 2005 From: dr at cluenet.de (Daniel Roesen) Date: Mon, 28 Feb 2005 17:49:24 +0100 Subject: [address-policy-wg] IPv6 access to K-root In-Reply-To: <20050228161456.GR92550@new.detebe.org> References: <1109596934.9918.87.camel@firenze.zurich.ibm.com> <20050228135414.GK92550@new.detebe.org> <1109599233.9918.106.camel@firenze.zurich.ibm.com> <20050228145232.GN92550@new.detebe.org> <1109602795.9918.131.camel@firenze.zurich.ibm.com> <20050228152133.GP92550@new.detebe.org> <20050228153919.GS84850@Space.Net> <20050228154306.GQ92550@new.detebe.org> <1109606909.9918.144.camel@firenze.zurich.ibm.com> <20050228161456.GR92550@new.detebe.org> Message-ID: <20050228164924.GA20369@srv01.cluenet.de> On Mon, Feb 28, 2005 at 05:14:56PM +0100, Elmar K. Bins wrote: > > You can also ask the other transit upstream to announce your /48 for > > you. > > Mind you, I prefer to advertise myself, and, as discussed, am in the > lucky position that my transit ISPs are reasonable. Unfortunately this mainly leads to bad connectivity as half of the IPv6 world filters /48. Results are overly long AS_PATHs and really ugly transit connections upteen times over the big ponds. Not in your case as you can peer directly at DECIX and Space.Net's quite well connected upstream Tiscali doesn't filter, but for other /48 wannabe-multihomers this looks MUCH worse. Random example: http://www.sixxs.net/tools/grh/lg/?find=2001:418::/32 PA more-specific "multihoming" is _not_ a solution. If your link to the PA-space providing ISP is down, you're unreachable from a lot of sites. And routing problem debugging becomes a major pain. Anyway, this isn't about DNS nameserver anycasting anymore, so... :-) Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0