From jeroen at unfix.org Thu Dec 1 03:37:13 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 01 Dec 2005 03:37:13 +0100 Subject: [ipv6-wg] 2001:4200::/32, 2001:4308::/32, 2001:4310::/32 AFRINIC, ARIN or RIPE? Message-ID: <438E61D9.6090902@unfix.org> According to IANA: http://www.iana.org/assignments/ipv6-unicast-address-assignments They are ARIN space. According to ARIN(*1) it is RIPE space. According to RIPE, it is AFRINIC. What needs to be fixed here? The IANA allocs or something else? Also it would be nice of course if ARIN directly pointed to AFRINIC instead of making AFRINIC the little sister of RIPE. 2001:970::/32 and 2001:4300::/32 are also AFRINIC now, before they where from the RIPE region, but the IANA file doesn't reflect this. The delegated-afrinic-latest indicates AFRINIC now, which is a bit odd. Greets, Jeroen *1 = 8<--------------------------------------------------------- OrgName: RIPE Network Coordination Centre OrgID: RIPE Address: P.O. Box 10096 City: Amsterdam StateProv: PostalCode: 1001EB Country: NL ReferralServer: whois://whois.ripe.net:43 NetRange: 2001:4300:0000:0000:0000:0000:0000:0000 - 2001:430F:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF CIDR: 2001:4300:0000:0000:0000:0000:0000:0000/28 NetName: RIPE1 NetHandle: NET6-2001-4300-1 Parent: NET6-2001-4200-0 NetType: Direct Allocation NameServer: NS-PRI.RIPE.NET NameServer: SEC1.APNIC.NET NameServer: SEC3.APNIC.NET NameServer: TINNIE.ARIN.NET NameServer: NS.LACNIC.NET Comment: RegDate: 2004-08-24 Updated: 2004-08-24 RTechHandle: RIPE-NCC-ARIN RTechName: RIPE NCC Hostmaster RTechPhone: +31 20 535 4444 RTechEmail: search-ripe-ncc-not-arin at ripe.net inet6num: 2001:4300::/25 netname: EU-ZZ-2001-4300 descr: RIPE NCC (AFRINIC) descr: European Regional Registry country: EU --------------------------------------------------------->8 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 238 bytes Desc: OpenPGP digital signature URL: From kurtis at kurtis.pp.se Thu Dec 1 09:11:48 2005 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Thu, 1 Dec 2005 09:11:48 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <20051130161647.GA12947@srv01.cluenet.de> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> Message-ID: <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> On 30 nov 2005, at 17.16, Daniel Roesen wrote: > ISPs do exist for customers, not customers do exist to feed ISPs > in the > most convenient way for the ISPs. Some folks seem to forget that, > looking at all the discussion trying to ignore the demand for real > multihoming (and that includes TE and network-wide routing policy > implementation, neither being delivered by things like shim6). I think you are contradicting yourself here. Shim6 does give the end- user TE capability. It does not give the ISP the possibility to ignore it, as they could today. I am not sure what you mean with "network-wide routing policy implementation".... I have still to figure out what the "real multihoming" thing is, but I am sure it must be beautiful. > HOW the requirements are being delivered is another topic. multi6 has > resulted in the decision to ignore many critical requirements. We're > just asking for something that delivers on the targets. Wasting time > with half-solutions is not productive. Halting any development because > the magic bullet wasn't found yet ain't either. If you have alternative ideas you know how it works - send text. - kurtis - From leo at ripe.net Thu Dec 1 10:22:02 2005 From: leo at ripe.net (leo vegoda) Date: Thu, 1 Dec 2005 10:22:02 +0100 Subject: [ipv6-wg] 2001:4200::/32, 2001:4308::/32, 2001:4310::/32 AFRINIC, ARIN or RIPE? In-Reply-To: <438E61D9.6090902@unfix.org> Message-ID: <002601c5f658$b01ad2b0$1d0200c1@RIPENCCRS5> Hi Jeroen, You wrote: > According to IANA: > http://www.iana.org/assignments/ipv6-unicast-address-assignments > > They are ARIN space. According to ARIN(*1) it is RIPE space. > According to RIPE, it is AFRINIC. > > What needs to be fixed here? The IANA allocs or something else? > Also it would be nice of course if ARIN directly pointed to AFRINIC > instead of making AFRINIC the little sister of RIPE. ARIN, APNIC and RIPE NCC all made IPv6 allocations to networks operating from Africa from 2001:4200::/23. This was to minimise the fragmentation of the authoritative registration data, when AfriNIC was started. I think a couple of records need to be updated. > 2001:970::/32 and ::/32 are also AFRINIC now, before > they where > from the RIPE region, but the IANA file doesn't reflect this. > The delegated-afrinic-latest indicates AFRINIC now, which is > a bit odd. In 2002, we allocated 2001:970::/32 to a network operating out of Tunisia. At that time, the RIPE NCC provided registration services in African countries north of the equator. The registration for this network was transferred to AfriNIC earlier this year, when AfriNIC started operations. Rather than ask network operators to update information in two databases, we transferred the registration data to the AfriNIC Whois Database. The record in the RIPE Whois Database reflects this change. inet6num: 2001:0970::/32 org: ORG-AFNC1-RIPE netname: AFRINIC-NET-TRANSFERRED-20050223 descr: This network has been transferred to AFRINIC remarks: These IP addresses are assigned in the AFRINIC region. remarks: Authoritative registration information for this network remarks: is available for query and modification in remarks: the AFRINIC whois database: whois.afrinic.net or remarks: web site: http://www.afrinic.net remarks: The routing registry information (route(6) objects) remarks: may be published in any Routing Registry, including remarks: RIPE Whois Database country: EU # country is somewhere in African Region admin-c: AFRI-RIPE tech-c: AFRI-RIPE status: ALLOCATED-BY-RIR mnt-by: RIPE-NCC-HM-MNT mnt-routes: RIPE-NCC-RPSL-MNT changed: hostmaster at ripe.net 20050223 source: RIPE I hope this explains the situation. Regards, -- leo vegoda RIPE NCC Registration Services Manager From heldal at eml.cc Thu Dec 1 11:37:20 2005 From: heldal at eml.cc (Per Heldal) Date: Thu, 01 Dec 2005 11:37:20 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> Message-ID: <1133433440.15956.248746502@webmail.messagingengine.com> On Thu, 1 Dec 2005 09:11:48 +0100, "Kurt Erik Lindqvist" said: > > On 30 nov 2005, at 17.16, Daniel Roesen wrote: > > > ISPs do exist for customers, not customers do exist to feed ISPs > > in the > > most convenient way for the ISPs. Some folks seem to forget that, > > looking at all the discussion trying to ignore the demand for real > > multihoming (and that includes TE and network-wide routing policy > > implementation, neither being delivered by things like shim6). > > I think you are contradicting yourself here. Shim6 does give the end- s/does/may ? ;) > user TE capability. It does not give the ISP the possibility to > ignore it, as they could today. Shim6 is work in progress and may be used as an argument to adjust adress-assignment policies sometime in the future. If we want ipv6 deployed today we have to provide a mechanism to support requirements about redundancy and independence from individual providers. > I am not sure what you mean with > "network-wide routing policy implementation".... I guess this relates to supporting infrastructure necessary for shim6 to support or replace current ipv4 technology like load-balancing, filtering etc. If standards are defined today and everyone agree to implement them asap it will still take years before such products are available and a commercially viable alternative. Shim6 has a potential to provide improved "granularity" in traffic management (individual path-selection for each source-destination HBA-pair) but that is irrelevant until the technology is actually there. Bottom line: it's fine to develop technology for the future, but operational procedures and policies must be supported by current technology. //per -- Per Heldal heldal at eml.cc From cgray at netegral.co.uk Thu Dec 1 11:44:50 2005 From: cgray at netegral.co.uk (Cameron C. Gray) Date: Thu, 01 Dec 2005 10:44:50 +0000 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <1133433440.15956.248746502@webmail.messagingengine.com> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> Message-ID: <438ED422.9090904@netegral.co.uk> Per Heldal wrote: > Shim6 is work in progress and may be used as an argument to adjust > adress-assignment policies sometime in the future. If we want ipv6 > deployed today we have to provide a mechanism to support requirements > about redundancy and independence from individual providers. I think this hit the nail on the head. Providers (especially those non-LIR) will not accept something along the lines of SHIM6 or A.N.Other competing idea until it gives them just that -- INBOUND ROUTING INDEPENDENCE. The only way these people see achieving this is if they can announce their prefix (of whatever size or status) to each of their providers and have it form part of everybody's tables. Personally I don't have a view either way as whether it should be PI or Special Assignments or Become-A-LIR to achieve it, although everyones fees will drop with more LIRs (read: members). My view is relatively simple; either give everyone who wants one and has an AS-Number a /32 or allow /48s into the backbone table. This is of course if we actually want to give up using IPv4; without the above most providers will see it as a step backward and a bad thing (tm). I am fast gathering this is an unpopular position so I'll get the asbestos underwear ready, but in the smaller circles (read: Tier 3 and below) this is an absolute requirement. -- Best Regards, Cameron Gray Director, Netegral Limited www.netegral.co.uk | 0871 277 6845 From randy at psg.com Thu Dec 1 12:01:12 2005 From: randy at psg.com (Randy Bush) Date: Thu, 1 Dec 2005 01:01:12 -1000 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> Message-ID: <17294.55288.858722.708230@roam.psg.com> > If you have alternative ideas you know how it works - send text. draft-ietf-ipngwg-gseaddr-00.txt same one the ietf has ignored and lied about for eight years now randy From hph at oslo.net Thu Dec 1 15:57:51 2005 From: hph at oslo.net (Hans Petter Holen) Date: Thu, 01 Dec 2005 15:57:51 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <20051130162129.GB12947@srv01.cluenet.de> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <20051130162129.GB12947@srv01.cluenet.de> Message-ID: <438F0F6F.5050409@oslo.net> Daniel Roesen wrote: > > BTW... in Germany, the phone operators were forced to implement phone > number portability by law. The regulator didn't care about all the > whining from the telcos about that being impossible, uneconomic, the > world will explode etc. If they manage to get that imposed on the > traditional telcos, I wonder how much easier it will be to do that on > the ISPs. > Very easy. In the Internet the equivalent of phone numers, the DNS names are alleady portable - so you can easily switch ISP and keep your email address and URLs without renumbering. Hans Petter From fw at deneb.enyo.de Thu Dec 1 17:34:23 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Thu, 01 Dec 2005 17:34:23 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <438F0F6F.5050409@oslo.net> (Hans Petter Holen's message of "Thu, 01 Dec 2005 15:57:51 +0100") References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <20051130162129.GB12947@srv01.cluenet.de> <438F0F6F.5050409@oslo.net> Message-ID: <87mzjkkc8g.fsf@mid.deneb.enyo.de> * Hans Petter Holen: > Very easy. In the Internet the equivalent of phone numers, the DNS names > are alleady portable - so you can easily switch ISP and keep your email > address and URLs without renumbering. I can't put DNS names on network interfaces. But I can use private address space and NAT, or public address space, DNS rewriting and double NAT. Not pretty, but gets the job done. From jeroen at unfix.org Thu Dec 1 18:30:05 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 01 Dec 2005 18:30:05 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <87mzjkkc8g.fsf@mid.deneb.enyo.de> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <20051130162129.GB12947@srv01.cluenet.de> <438F0F6F.5050409@oslo.net> <87mzjkkc8g.fsf@mid.deneb.enyo.de> Message-ID: <438F331D.3060208@unfix.org> [multiple messages compressed into one] Florian Weimer wrote: > * Hans Petter Holen: > >> Very easy. In the Internet the equivalent of phone numers, the DNS names >> are alleady portable - so you can easily switch ISP and keep your email >> address and URLs without renumbering. > > I can't put DNS names on network interfaces. But I can use private > address space and NAT, or public address space, DNS rewriting and > double NAT. Not pretty, but gets the job done. (psst... 'double NAT' is one of the things shim6 is going to use) As for "DNS rewriting" any example of that? bmanning at vacation.karoshi.com wrote: > On Thu, Dec 01, 2005 at 04:53:44PM +0100, Jeroen Massar wrote: >> As an exercise for the readers try to remember why there are >> filters on >> IPv4 /24 boundaries and the try to figure out why there are quite a >> number of people not wanting IPv6 PI to fill their IPv6 routing >> tables. > > one might also ask why a RIB/FIB entry has more relevance > for one size prefix instead of another. Ease of filtering. Not much more. The 'worthiness' of a prefix depends more on the service provided in that prefix. One for instance would not really want to loose the connectivity to all the DNS root or TLD servers and most ISP's will have a nice red glowing phone when connectivity to google/msn etc is broken. Max Tulyev wrote: >> Last time I was a hosting proivider I signed up as a LIR and built my >> own network infrastructure to the nearest IX points. >> This time I have outrourced the lot and my 300 server serverfarm is >> behind a firewall on a handfull of IP addresses >>> Changing ISP is really easy? >> Yes. > > Stop. You have 10000 domains. You have IP address(es) from ISP A . > You are moving to ISP B with OTHER address(es). And you don't need to > send 10000 modify requests for these 10000 domains to change A (NS, > MX) records. Where is the magic? ;-) The same as the phone number system. One at a time. Or script your setup, you do know what 'management software' means do you? Look up the term ITIL or ASL once ;) With such a setup I suggest you outsource your "ISP" to the real ISP or plan ahead and become real good friends with your current ISP. You need a /28 and want "Provider Independence". I use a /28 at home. Lets say that I want "PI" too, that would mean I am going to get, pay for and maintain: - Multiple Redundant Routers - Multiple Redundant Links - Multiple Redundant Transits - Own 24/7 NOC (things will fail) - and a lot more... You are willing to do and pay for all that, but don't want to become an LIR? Nah, I rather let some real ISP handle all of that, they have the time to fiddle with peering and transit agreements, billing and all kinds of other time consuming things. Elmar K. Bins wrote: > Even to the risk of upsetting you... How can you calling yourself a 'fat-fingered jerk' upset me ? :) > These filters do not exist to blind out small PI assignments, they are > in place to remove accidental leakage of IGP prefixes caused by some > fat-fingered jerk like myself... So you filter on a /24 because of IGP, thus you will leak out a /23? Adding 8 or so prefixes doesn't really get noticed by many people, but adding 10k does. Filtering based on routing-DB information is thus much better than doing it based on some arbitrary limit. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 238 bytes Desc: OpenPGP digital signature URL: From gih at apnic.net Thu Dec 1 19:09:23 2005 From: gih at apnic.net (Geoff Huston) Date: Fri, 02 Dec 2005 05:09:23 +1100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <17294.55288.858722.708230@roam.psg.com> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <17294.55288.858722.708230@roam.psg.com> Message-ID: <6.2.0.14.2.20051202045722.02de10b0@kahuna.telstra.net> At 10:01 PM 1/12/2005, Randy Bush wrote: > > If you have alternative ideas you know how it works - send text. > >draft-ietf-ipngwg-gseaddr-00.txt > >same one the ietf has ignored and lied about for eight years now I was not directly involved here, so when I looked into this a little, then I found the document draft-ietf-ipngwg-esd-analysis-05.txt was the ultimate version of a draft responding to the GSE approach. The observation that neither the GSE document, nor this response, ever made it past drafts could be an indicator that there may be more to this story than can be found in the IETF drafts from the period 1997 - 2000. I certainly found it interesting to review these two documents side by side, and others who may also be wondering what happened to GSE may find it useful to read the ESD analysis Geoff From rogerj at jorgensen.no Thu Dec 1 20:14:44 2005 From: rogerj at jorgensen.no (Roger Jorgensen) Date: Thu, 1 Dec 2005 20:14:44 +0100 (CET) Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide tofix I Pv6 In-Reply-To: <17295.18210.797714.378814@roam.psg.com> References: <87slt m3p3n.fsf@mid.deneb.enyo.de><4386E053.73B661B3@networx.ch><43886509.6060600@unfix.org><87acf r1mjl.fsf@mid.deneb.enyo.de><002f01c5f43a$12631110$44eea2d5@l><6.2.0.14.2.2 0051129101355.02919160@kahuna.telstra.net><87fypfpm1e.fsf@mid.deneb.enyo.de ><6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net><20051130161647.GA1 2947@srv01.cluenet.de><08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se><1 7294.55288.858722.708230@roam.psg.com><6.2.0.14.2.20051202045722.02de10b0@k ahuna.telstra.net> <17295.18210.797714.378814@roam.psg.com> Message-ID: I might totaly missunderstand you, but I get the feeling you want us to go back to the root of the IPv6 discussion when it all was started and use some of the stuff that was done before instead of trying to figure it all out again? On Thu, 1 Dec 2005, Randy Bush wrote: > > and that was the lie. in fact, the gse proposal was not reviewed > for security and found wanting. many of the authors of the second > document have since recanted. > > you also may want to read > > http://www.cs.columbia.edu/~smb/papers/esd-secure.txt -- ------------------------------ Roger Jorgensen | rogerj at stud.cs.uit.no | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no ------------------------------------------------------- From randy at psg.com Thu Dec 1 19:55:30 2005 From: randy at psg.com (Randy Bush) Date: Thu, 1 Dec 2005 08:55:30 -1000 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <17294.55288.858722.708230@roam.psg.com> <6.2.0.14.2.20051202045722.02de10b0@kahuna.telstra.net> Message-ID: <17295.18210.797714.378814@roam.psg.com> > I was not directly involved here, so when I looked into this a little, then > I found the document draft-ietf-ipngwg-esd-analysis-05.txt was the > ultimate version of a draft responding to the GSE approach. The > observation that neither the GSE document, nor this response, > ever made it past drafts could be an indicator that there may be more > to this story than can be found in the IETF drafts from the period > 1997 - 2000. I certainly found it interesting to review these two > documents side by side, and others who may also be wondering > what happened to GSE may find it useful to read the ESD analysis and that was the lie. in fact, the gse proposal was not reviewed for security and found wanting. many of the authors of the second document have since recanted. you also may want to read http://www.cs.columbia.edu/~smb/papers/esd-secure.txt randy From randy at psg.com Thu Dec 1 20:24:58 2005 From: randy at psg.com (Randy Bush) Date: Thu, 1 Dec 2005 09:24:58 -1000 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide tofix IPv6 Message-ID: <17295.19978.955771.823645@roam.psg.com> [ something did some horrifying things to the header of your mail as i received it, in particular the references: line, see appended. so i had to chop the refs off my reply. apologies to those who thread based on it. ] > I might totaly missunderstand you, but I get the feeling you want > us to go back to the root of the IPv6 discussion when it all was > started and use some of the stuff that was done before instead of > trying to figure it all out again? yep. though, since i come from the perspective of living it all these years, the "go back" part is a recent view :-). i.e. sane operational folk have been sining this song for years. there has been an amazing lack of ears listening to it. randy --- line breaks are not from here! References: <87slt m3p3n.fsf at mid.deneb.enyo.de><4386E053.73B661B3 at networx.ch><43886509.6060600 at unfix.org><87acf r1mjl.fsf at mid.deneb.enyo.de><002f01c5f43a$12631110$44eea2d5 at l><6.2.0.14.2.2 0051129101355.02919160 at kahuna.telstra.net><87fypfpm1e.fsf at mid.deneb.enyo.de ><6.2.0.14.2.20051130053430.02d015d0 at kahuna.telstra.net><20051130161647.GA1 2947 at srv01.cluenet.de><08D2E092-8FB3-4C5D-9837-4433C77F0B46 at kurtis.pp.se><1 7294.55288.858722.708230 at roam.psg.com><6.2.0.14.2.20051202045722.02de10b0 at k ahuna.telstra.net> <17295.18210.797714.378814 at roam.psg.com> From elmi at 4ever.de Thu Dec 1 21:03:19 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Thu, 1 Dec 2005 21:03:19 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <438F331D.3060208@unfix.org> References: <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <20051130162129.GB12947@srv01.cluenet.de> <438F0F6F.5050409@oslo.net> <87mzjkkc8g.fsf@mid.deneb.enyo.de> <438F331D.3060208@unfix.org> Message-ID: <20051201200319.GS44731@new.detebe.org> jeroen at unfix.org (Jeroen Massar) wrote: > Elmar K. Bins wrote: > How can you calling yourself a 'fat-fingered jerk' upset me ? :) ;-) > > These filters do not exist to blind out small PI assignments, they are > > in place to remove accidental leakage of IGP prefixes caused by some > > fat-fingered jerk like myself... > > So you filter on a /24 because of IGP, thus you will leak out a /23? Wrong train of thought. I am of course not leaking anything from my network (first, I train my fingers every day, so they don't get fat, second, I do not redistribute IGP prefixes). The /24 filters we are talking about here are filtering other people's longer-than-/24s out. The /24 filter is just a partly brain-damaged, partly geniously simple way of removing a lot of fat-fingering from my routing table (I am not one of the big transit ISPs, so I'm very happy with that). > Adding 8 or so prefixes doesn't really get noticed by many people, but > adding 10k does. There are companies that run a /20 or bigger nicely sliced into small networks (hundreds or thousands), and sometimes their IGP prefixes leak. > Filtering based on routing-DB information is thus much > better than doing it based on some arbitrary limit. The effort of rebuilding an appropriate ACL every day, the length of the ACL and the router processing degradation or - even worse - running into hard limits, alongside the "update how often?" question prohibit that largely. Of course, having an up-to-date ACL in sync with the routing databases would be the ideal solution, or would it? How many people don't register? How many DBs are there to track? Well... But you have distracted me from the matter at hand, so I repeat again that the /24 filters are not in place to filter out small PI blocks. It's not nice, it's not perfect, but it's there. So any authority that gives out networks (hello RIPE!) should consider everything longer than a /24 as "non routable", and not give out such blocks as v4 PI. Cheers, Elmi. From elmi at 4ever.de Thu Dec 1 21:05:57 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Thu, 1 Dec 2005 21:05:57 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <438F331D.3060208@unfix.org> References: <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <20051130162129.GB12947@srv01.cluenet.de> <438F0F6F.5050409@oslo.net> <87mzjkkc8g.fsf@mid.deneb.enyo.de> <438F331D.3060208@unfix.org> Message-ID: <20051201200556.GT44731@new.detebe.org> Oh, I overlooked that part of your email, but it shows part of your misconception... jeroen at unfix.org (Jeroen Massar) wrote: > You need a /28 and want "Provider Independence". I use a /28 at home. > Lets say that I want "PI" too, that would mean I am going to get, pay > for and maintain: > - Multiple Redundant Routers > - Multiple Redundant Links > - Multiple Redundant Transits > - Own 24/7 NOC (things will fail) > - and a lot more... > > You are willing to do and pay for all that, but don't want to become an > LIR? The point to this is, that with v6 it is not sufficient to be a LIR to get an independently routable block. You can have as many AS numbers as you want - you get them, when you need them - but you will simply not get a v6 block if you do not have 200 customers, prospective or not. That's the independently-networking end-user problem we have. PI would solve that. Removal of the 200 customer rule would solve that. One-block- per-LIR would solve that. Elmar. From woeber at cc.univie.ac.at Thu Dec 1 22:54:44 2005 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 01 Dec 2005 21:54:44 +0000 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <20051201200319.GS44731@new.detebe.org> References: <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <20051130162129.GB12947@srv01.cluenet.de> <438F0F6F.5050409@oslo.net> <87mzjkkc8g.fsf@mid.deneb.enyo.de> <438F331D.3060208@unfix.org> <20051201200319.GS44731@new.detebe.org> Message-ID: <438F7124.4020801@cc.univie.ac.at> Elmar K. Bins wrote: [ ... ] > But you have distracted me from the matter at hand, so I repeat again that > the /24 filters are not in place to filter out small PI blocks. It's not > nice, it's not perfect, but it's there. So any authority that gives out > networks (hello RIPE!) should consider everything longer than a /24 as > "non routable", and not give out such blocks as v4 PI. >From ripe-357 ( http://www.ripe.net/ripe/docs/pi-requestsupport.html ), Supporting Notes for the Provider Independent (PI) Assignment Request Form "You must ensure that the End User understands and accepts that PI address space may be more difficult or more expensive to route than PA address space and then confirm this in the "confirmation:" field. You can find more details on the consequences and disadvantages of PI address space in the "IPv4 Address Allocation and Assignment Policy for the RIPE region" (see above for url)." > Cheers, > Elmi. > > From elmi at 4ever.de Thu Dec 1 23:02:36 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Thu, 1 Dec 2005 23:02:36 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <438F7124.4020801@cc.univie.ac.at> References: <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <20051130162129.GB12947@srv01.cluenet.de> <438F0F6F.5050409@oslo.net> <87mzjkkc8g.fsf@mid.deneb.enyo.de> <438F331D.3060208@unfix.org> <20051201200319.GS44731@new.detebe.org> <438F7124.4020801@cc.univie.ac.at> Message-ID: <20051201220236.GY44731@new.detebe.org> woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) wrote: > From ripe-357 ( http://www.ripe.net/ripe/docs/pi-requestsupport.html ), > Supporting Notes for the Provider Independent (PI) Assignment Request Form (which I know quite well) Yes, of course nobody guarantees routeability. That's impossible. But even RIPE has changed PI assignment policy a couple of years ago and doesn't give out longer-than-/24 any more. That's not guaranteeing anything, but it raises the probability. Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, ) --------------------------------------------------------------[ ELMI-RIPE ]--- From president at ukraine.su Fri Dec 2 10:34:10 2005 From: president at ukraine.su (Max Tulyev) Date: Fri, 2 Dec 2005 12:34:10 +0300 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <438F331D.3060208@unfix.org> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <87mzjkkc8g.fsf@mid.deneb.enyo.de> <438F331D.3060208@unfix.org> Message-ID: <200512021234.10472.president@ukraine.su> > You need a /28 and want "Provider Independence". I use a /28 at home. Hope you do not host thousands of websites at home ;) > Lets say that I want "PI" too, that would mean I am going to get, pay > for and maintain: > - Multiple Redundant Routers > - Multiple Redundant Links > - Multiple Redundant Transits > - Own 24/7 NOC (things will fail) > - and a lot more... > > You are willing to do and pay for all that, but don't want to become an > LIR? In this example I'm providing hosting and no more than hosting. No telecoms, no transit channels, no ADSL. May be domain registration. To make that business success I need to be multihomed (no objections at this point, I think?). Also I need to be independent from carriers (especially when hosting grows up and I will ask for money for direct peering with me). But I do NOT need a lot of address space (thanks God and RFC, we have HTTP/1.1 this time). Look more. http://www.ripe.net/membership/benefits.html As a hosting provider, I do NOT want any of that services. So no reasons to be LIR, isn't it? It is only example for PI, but many other exists. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From jeroen at unfix.org Fri Dec 2 10:51:23 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 02 Dec 2005 10:51:23 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <200512021234.10472.president@ukraine.su> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <87mzjkkc8g.fsf@mid.deneb.enyo.de> <438F331D.3060208@unfix.org> <200512021234.10472.president@ukraine.su> Message-ID: <4390191B.60602@unfix.org> Max Tulyev wrote: >> You need a /28 and want "Provider Independence". I use a /28 at home. > > Hope you do not host thousands of websites at home ;) Some hosts have http/https/imaps and other services running. But all it takes to move them away is changing DNS. Nothing more. >> Lets say that I want "PI" too, that would mean I am going to get, pay >> for and maintain: >> - Multiple Redundant Routers >> - Multiple Redundant Links >> - Multiple Redundant Transits >> - Own 24/7 NOC (things will fail) >> - and a lot more... >> >> You are willing to do and pay for all that, but don't want to become an >> LIR? > > In this example I'm providing hosting and no more than hosting. No telecoms, > no transit channels, no ADSL. May be domain registration. > > To make that business success I need to be multihomed (no objections at this > point, I think?). Also I need to be independent from carriers (especially > when hosting grows up and I will ask for money for direct peering with me). > > But I do NOT need a lot of address space (thanks God and RFC, we have HTTP/1.1 > this time). RIR's "business" is about providing LOTS of address space. LIR's provide little address space to endusers and in the above you are an enduser. I suggest you start providing SSL based HTTP. Then you probably need 256 IP's in a sinch. And guess what 256 domains on HTTPS means you have 200 customers. Check the allocations list and see what kind of 'companies' already are LIR and are already > Look more. > http://www.ripe.net/membership/benefits.html > As a hosting provider, I do NOT want any of that services. So no reasons to be > LIR, isn't it? You don't want: 8<------------------- Registration Services As a member, you can request Internet Resources (IP address space, AS Numbers, Reverse Delegation) from the RIPE NCC. ------------------->8 ??? For your case the answer is simple: get your address space from an LIR. Otherwise draft a proposal for an "enduser-LIR" who can only get 1 AS and 1 prefix for themselves. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 238 bytes Desc: OpenPGP digital signature URL: From leo at ripe.net Fri Dec 2 11:58:56 2005 From: leo at ripe.net (leo vegoda) Date: Fri, 2 Dec 2005 11:58:56 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <20051201220236.GY44731@new.detebe.org> Message-ID: <004c01c5f72f$6427a310$1d0200c1@RIPENCCRS5> Hi Elmar, You wrote: > woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) wrote: > > > From ripe-357 ( > http://www.ripe.net/ripe/docs/pi-requestsupport.html ), > > Supporting Notes for the Provider Independent (PI) > Assignment Request Form > > (which I know quite well) > > Yes, of course nobody guarantees routeability. That's impossible. > But even RIPE has changed PI assignment policy a couple of years > ago and doesn't give out longer-than-/24 any more. That's not quite right. There was no policy change introducing a minimum size for IPv4 PI assignments. PI assignments are made on the same basis as PA assignments. It's not unusual for people to request PI assignments longer than a /24 and we have made a couple of dozen so far this year. Regards, -- leo vegoda RIPE NCC Registration Services Manager From heldal at eml.cc Fri Dec 2 13:41:59 2005 From: heldal at eml.cc (Per Heldal) Date: Fri, 02 Dec 2005 13:41:59 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <200512021234.10472.president@ukraine.su> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <87mzjkkc8g.fsf@mid.deneb.enyo.de> <438F331D.3060208@unfix.org> <200512021234.10472.president@ukraine.su> Message-ID: <1133527319.15575.248843990@webmail.messagingengine.com> On Fri, 2 Dec 2005 12:34:10 +0300, "Max Tulyev" said: [snip] > > In this example I'm providing hosting and no more than hosting. No > telecoms, > no transit channels, no ADSL. May be domain registration. > > To make that business success I need to be multihomed (no objections at > this > point, I think?). Try a different angle; assume you can get decent (redundant) connectivity to one provider and thus almost as reliable as if you're sitting in their core network. If you still require multihoming, don't your arguments implicitly disqualify your upstream as a hosting-provider too (regardless of them being multihomed and/or peering at any tier)? Who can then be trusted to run hosting-operations? Only multihomed as'es with no downstreams? (*duck*) //per -- Per Heldal heldal at eml.cc From president at ukraine.su Fri Dec 2 14:01:10 2005 From: president at ukraine.su (Max Tulyev) Date: Fri, 2 Dec 2005 16:01:10 +0300 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <1133527319.15575.248843990@webmail.messagingengine.com> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <200512021234.10472.president@ukraine.su> <1133527319.15575.248843990@webmail.messagingengine.com> Message-ID: <200512021601.10197.president@ukraine.su> > Try a different angle; assume you can get decent (redundant) > connectivity > to one provider and thus almost as reliable as if you're sitting in > their > core network. If you still require multihoming, don't your arguments > implicitly disqualify your upstream as a hosting-provider too > (regardless of > them being multihomed and/or peering at any tier)? Who can then be > trusted to run hosting-operations? Only multihomed as'es with no > downstreams? Ok, 3 meters Ethernet from core of good network is enough to be technically stable. But still there is management questions because of connectivity from only one upstream and can't establish private (commerce) peerings. P.S. About DNS, many clients really want to have own DNS, more of that, domain is not the only hosting, often there is a lot of corporate and/or private subdomains, that's why people don't want to lose their DNS control. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From ripe-lst at eirconnect.net Fri Dec 2 14:03:24 2005 From: ripe-lst at eirconnect.net (Sascha Luck) Date: Fri, 2 Dec 2005 13:03:24 +0000 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <1133527319.15575.248843990@webmail.messagingengine.com> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <200512021234.10472.president@ukraine.su> <1133527319.15575.248843990@webmail.messagingengine.com> Message-ID: <200512021303.24924.ripe-lst@eirconnect.net> On Fri 02 Dec 2005 12:41, Per Heldal wrote: > Who can then be trusted to run hosting-operations? And that, Ladies & Gentlemen, is exactly the point. No ISP/Telco/Hoster can be trusted. Hence, the requirement for multihoming in v4 today, and in v6 tomorrow. No amount of policy fiddling and idle discussion can change that fact. rgds, s. From president at ukraine.su Fri Dec 2 14:11:23 2005 From: president at ukraine.su (Max Tulyev) Date: Fri, 2 Dec 2005 16:11:23 +0300 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <4390191B.60602@unfix.org> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <200512021234.10472.president@ukraine.su> <4390191B.60602@unfix.org> Message-ID: <200512021611.23333.president@ukraine.su> > Some hosts have http/https/imaps and other services running. But all it > takes to move them away is changing DNS. Nothing more. "Who said it is easy to take off a chocolate from baby's hand never tried to do that" ;-) Unfortunally, real users are not ideal case, and they use pure IPs even nobody asks them to do that. > You don't want: > 8<------------------- > Registration Services > As a member, you can request Internet Resources (IP address space, AS > Numbers, Reverse Delegation) from the RIPE NCC. > ------------------->8 > > ??? > > For your case the answer is simple: get your address space from an LIR. > Otherwise draft a proposal for an "enduser-LIR" who can only get 1 AS > and 1 prefix for themselves. Yep. I want IP/AS, not IP/AS registration service. Look, you are really want to be a .com TLD registrar just to register your cooldomain.com? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From fw at deneb.enyo.de Fri Dec 2 14:13:42 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 02 Dec 2005 14:13:42 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <1133527319.15575.248843990@webmail.messagingengine.com> (Per Heldal's message of "Fri, 02 Dec 2005 13:41:59 +0100") References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <87mzjkkc8g.fsf@mid.deneb.enyo.de> <438F331D.3060208@unfix.org> <200512021234.10472.president@ukraine.su> <1133527319.15575.248843990@webmail.messagingengine.com> Message-ID: <87bqzz8wvt.fsf@mid.deneb.enyo.de> * Per Heldal: > If you still require multihoming, don't your arguments implicitly > disqualify your upstream as a hosting-provider too Indeed, large networks may have surprising characteristics. Router vendors apparently still do not provide technical means to confine IGP anomalies. That's part of the reason why a small AS with a few upstream ISPs can beat Tier-1s in terms of network availability. From dr at cluenet.de Fri Dec 2 14:32:36 2005 From: dr at cluenet.de (Daniel Roesen) Date: Fri, 2 Dec 2005 14:32:36 +0100 Subject: [ipv6-wg] Re: Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <20051201200556.GT44731@new.detebe.org> References: <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <20051130162129.GB12947@srv01.cluenet.de> <438F0F6F.5050409@oslo.net> <87mzjkkc8g.fsf@mid.deneb.enyo.de> <438F331D.3060208@unfix.org> <20051201200556.GT44731@new.detebe.org> Message-ID: <20051202133236.GA2489@srv01.cluenet.de> On Thu, Dec 01, 2005 at 09:05:57PM +0100, Elmar K. Bins wrote: > That's the independently-networking end-user problem we have. [...] > Removal of the 200 customer rule would solve that. One-block-per-LIR > would solve that. No, it wouldn't. IPv6 allocation policy excludes end-sites, no matter wether they are LIR or not. DENIC is clearly an end site. At least I'm not aware that it's in the business of providing Internet connectivity to other entities. Currently, it's not even enough to throw money at the problem (pay LIR fees for not being a LIR but getting IP space), you also have to be sufficiently large to claim being an enterprise-internal ISP. Then again, even some school in Switzerland and one/three-man living room consulting companies manage that, surprisingly. Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From elmi at 4ever.de Fri Dec 2 15:01:35 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Fri, 2 Dec 2005 15:01:35 +0100 Subject: [ipv6-wg] Re: Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <20051202133236.GA2489@srv01.cluenet.de> References: <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <20051130162129.GB12947@srv01.cluenet.de> <438F0F6F.5050409@oslo.net> <87mzjkkc8g.fsf@mid.deneb.enyo.de> <438F331D.3060208@unfix.org> <20051201200556.GT44731@new.detebe.org> <20051202133236.GA2489@srv01.cluenet.de> Message-ID: <20051202140134.GE44731@new.detebe.org> dr at cluenet.de (Daniel Roesen) wrote: > No, it wouldn't. IPv6 allocation policy excludes end-sites, no matter > wether they are LIR or not. DENIC is clearly an end site. At least I'm > not aware that it's in the business of providing Internet connectivity > to other entities. Then you have skipped some press releases ;-) But you're right, the "no end user" thing has to go. I just forgot about that. Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, ) --------------------------------------------------------------[ ELMI-RIPE ]--- From heldal at eml.cc Fri Dec 2 15:10:50 2005 From: heldal at eml.cc (Per Heldal) Date: Fri, 02 Dec 2005 15:10:50 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <200512021303.24924.ripe-lst@eirconnect.net> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <200512021234.10472.president@ukraine.su> <1133527319.15575.248843990@webmail.messagingengine.com> <200512021303.24924.ripe-lst@eirconnect.net> Message-ID: <1133532650.23871.248847581@webmail.messagingengine.com> On Fri, 2 Dec 2005 13:03:24 +0000, "Sascha Luck" said: > And that, Ladies & Gentlemen, is exactly the point. No ISP/Telco/Hoster > can be trusted. Hence, the requirement for multihoming in v4 today, > and in v6 tomorrow. No amount of policy fiddling and idle discussion > can change that fact. [thought my last post had sarcasm written all over it ... nevermind] I don't disagree there's a need for (business requirements) multihoming. Allocation policies however have to reflect reality. There's a reason why we don't accept v4 micro-PI-allocations today (which is what this thread diverted to). Despite endless arguments we've managed to define a balanced policy that works for ipv4 (no need to start those arguments again). To those who want ipv6 deployed *now*; What is their relation to the term "business requirements"? Do they understand the difference between fiction and reality? Shim6&friends belong to the future, as does routing technology able to cope with a fragmented v6 addresspace. The only alternative *today* is to define a policy that has a fair balance between what's practically doable (DFZ size) and connectivity needs. Is it the numbers that are confusing policy-makers? With current v4 policies it's fairly easy to justify the need for a certain size address-block, and equally easy to check utilisation of allocated block. Obliously, with V6 nobody is going to fill a /[whatever] and "utilisation" becomes an irrelevant term. Could it be an alternative to require that V6 PI-holders document their use of the allocated block, and apply some form of hostcount that reflect the current V4 policy to justify their V6 allocation. //per -- Per Heldal heldal at eml.cc From chbm at chbm.net Fri Dec 2 19:50:05 2005 From: chbm at chbm.net (Carlos Morgado) Date: Fri, 02 Dec 2005 18:50:05 +0000 Subject: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix IPv6 References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> Message-ID: <1133549405l.4749l.0l@sal.intra.chbm.net> On 28 Nov 2005 16:37:47, J?rgen Hovland wrote: > > 1. No PI. _Only_ network operators get a prefix. > 2. Customers of network operators can at any time change provider and take > their assigned prefix with them. The new provider will announce it as a > more specific overriding the aggregate. If the customer decides to get > multiple providers, then the network operator with the /32 could also > announce a more specific. > There's so wrong there i don't even know where to start. a) space costs money. who pays for hijacked space ? b) if the new ISP goes dark, why does the old ISP get hit with a DDoS destined at the former customer b.1) how does the old ISP protect itself from such a scenario ? c) if a customer multihomes to an ISP B that buys transit from original ISP A how exactly does that work ? d) why should I accept a more specific for a netblock I'm announcing ? e) why do I need to inject the internet into my IGP which is otherwise simple ? > In the country I live in I can change telecom provider and take my phone > number with me to the new provider. Why shouldn't I be able to do that with > internet providers? > Yes, it will somehow create millions/billions of prefixes (atleasat with > todays routing technology/protocols). Network operators should be able to > handle that hence rule #1. > If you compare internet routing and PSTN "routing" seriously you've never worked with at least one of them. PSTN "routing" isn't, number portability takes days to deploy, PSTN doesn't have efective multipath and please do take a look at the portability mechanisms. > > Joergen Hovland -- Carlos Morgado - chbm(a)ma.ssive.net - http://chbm.net/0x1FC57F0A FP:0A27 35D3 C448 3641 0573 6876 2A37 4BB2 1FC5 7F0A From chbm at chbm.net Fri Dec 2 19:52:09 2005 From: chbm at chbm.net (Carlos Morgado) Date: Fri, 02 Dec 2005 18:52:09 +0000 Subject: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix IPv6 References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> Message-ID: <1133549529l.4749l.1l@sal.intra.chbm.net> On 29 Nov 2005 14:26:53, Florian Weimer wrote: > * Geoff Huston: > > > Interesting - it will work for a while, and then you will get to the limit > > > of deployed capability of routing. > > > > Then what? > > You buy new routers. > So we'll just bypass this idiotic discussions, go buy new routers and deploy IPv6 multihoming in the straightforward way. -- Carlos Morgado - chbm(a)ma.ssive.net - http://chbm.net/0x1FC57F0A FP:0A27 35D3 C448 3641 0573 6876 2A37 4BB2 1FC5 7F0A From gert at space.net Fri Dec 2 19:54:41 2005 From: gert at space.net (Gert Doering) Date: Fri, 2 Dec 2005 19:54:41 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <1133549405l.4749l.0l@sal.intra.chbm.net> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> <1133549405l.4749l.0l@sal.intra.chbm.net> Message-ID: <20051202185441.GQ69925@Space.Net> Hi, On Fri, Dec 02, 2005 at 06:50:05PM +0000, Carlos Morgado wrote: > If you compare internet routing and PSTN "routing" seriously you've never > worked with at least one of them. PSTN "routing" isn't, number portability > takes days to deploy, PSTN doesn't have efective multipath and please do > take a look at the portability mechanisms. Indeed - but playing the devil's advocate: if people want PI to avoid renumbering, they don't need millisecond switchover time - they want to move to a new ISP "in the time range it takes to setup a leased line"... A number portability scheme similar to what the Telcos have to do *would* work, but it would not be the "dynamic Internet of today". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From chbm at chbm.net Sat Dec 3 00:15:49 2005 From: chbm at chbm.net (Carlos Morgado) Date: Fri, 02 Dec 2005 23:15:49 +0000 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 PI In-Reply-To: (from rogerj@jorgensen.no on Fri Nov 25 09:55:54 2005) References: <200511241822.jAOIMAfk018658@alpha.bartels.de> Message-ID: <1133565349l.24742l.1l@sal.intra.chbm.net> On 25 Nov 2005 09:55:54, Roger Jorgensen wrote: > > Again, we don't need PI space and multihoming, what we need are a way to > give the users and GOOD connectivity (uptime, speed etc) and make it easy > for them to switch providers as they see fit. > No. We want to peer with whoever we see fit. If that means becoming a LIR and geting PA, so be it. -- Carlos Morgado - chbm(a)ma.ssive.net - http://chbm.net/0x1FC57F0A FP:0A27 35D3 C448 3641 0573 6876 2A37 4BB2 1FC5 7F0A From chbm at chbm.net Sat Dec 3 00:29:05 2005 From: chbm at chbm.net (Carlos Morgado) Date: Fri, 02 Dec 2005 23:29:05 +0000 Subject: [ipv6-wg] Re: IPv6 PI In-Reply-To: <20051121162702.GE96756@new.detebe.org> (from elmi@4ever.de on Mon Nov 21 16:27:02 2005) References: <20051120111903.GI96756@new.detebe.org> <20051121162702.GE96756@new.detebe.org> Message-ID: <1133566146l.24742l.2l@sal.intra.chbm.net> On 21 Nov 2005 16:27:02, Elmar K. Bins wrote: > lea.roberts at stanford.edu (Lea Roberts) wrote: > > > this was the original ARIN proposal 2005-1, which could not reach > > consensus. The last time around it was re-worked to add more > restrictions > > and again failed because other folks felt it was too restrictive. There > > are actually two issues: > > > > 1) the high cost of renumbering in a large organization > > Why should they renumber, if it's their own block? > As in, PI ? > > > 2) multi-homing for network reliability and resiliency > > Where's the problem here? Someone who can afford and establish > a case for _real_ multihoming can get an ASN and thus an assignment. > No. Unless you relax the rules for ASN and then *oh gosh* you have a ASN size problem. > Like was already said - loosening the ASN handout rules needs changes > in assignment rules, too. But that's for years to come. > No. Adress space and routing policy are diferent entities. That's why LIRs don't automagically get an ASN. > Yours, > Elmi. > > -- > > "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." > (PLemken, > ) > > --------------------------------------------------------------[ ELMI-RIPE > ]--- > -- Carlos Morgado - chbm(a)ma.ssive.net - http://chbm.net/0x1FC57F0A FP:0A27 35D3 C448 3641 0573 6876 2A37 4BB2 1FC5 7F0A From chbm at chbm.net Sat Dec 3 00:35:04 2005 From: chbm at chbm.net (Carlos Morgado) Date: Fri, 02 Dec 2005 23:35:04 +0000 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <87hdaavu3v.fsf@mid.deneb.enyo.de> (from fw@deneb.enyo.de on Fri Nov 18 15:44:20 2005) References: <200511112244.jABMiYpQ011727@mail03.hipercom.no> <43767AF1.4000302@oslo.net> <877jb8v3dr.fsf@mid.deneb.enyo.de> <437DF2C7.903@schiefner.de> <87hdaavu3v.fsf@mid.deneb.enyo.de> Message-ID: <1133566504l.24742l.3l@sal.intra.chbm.net> On 18 Nov 2005 15:44:20, Florian Weimer wrote: > * Carsten Schiefner: > > > of course, I can't speak for every DNS operator, but DENIC denying the > > transfer of the .de zone has no other reason than data protection, ie. > > making the harvesting of contact data of some 9 million plus domain name > > holders by just piping the zone through the whois impossible. > > Your claim is absurd. The real privacy issue comes form forced > publication of WHOIS data. As a member of the DENIC executive board, > you certainly know that, so please stop spreading such misinformation. > No, your "get back our stuff on edonkey" plan is absurd. Next time could you please make your idea a little bit funny so we can all have a laugh ? Thank you. -- Carlos Morgado - chbm(a)ma.ssive.net - http://chbm.net/0x1FC57F0A FP:0A27 35D3 C448 3641 0573 6876 2A37 4BB2 1FC5 7F0A From hph at oslo.net Sat Dec 3 13:35:20 2005 From: hph at oslo.net (Hans Petter Holen) Date: Sat, 03 Dec 2005 13:35:20 +0100 Subject: [ipv6-wg] closed network and need for global uniqe IP space In-Reply-To: References: <200511241822.jAOIMAfk018658@alpha.bartels.de> Message-ID: <43919108.5010802@oslo.net> Roger Jorgensen wrote: > > * become LIR and request the needed IP space. > >From a couple projects I have done in the past - this is the path I would follow. The reasoning would be that your network will connect to the Internet or networks connected to the Internet. That you TODAY use firewalls or NATs sould not prevent you from getting address space. -hph From kurtis at kurtis.pp.se Mon Dec 5 14:15:16 2005 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Mon, 5 Dec 2005 14:15:16 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <1133433440.15956.248746502@webmail.messagingengine.com> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> Message-ID: <48A89582-ADA6-4429-8593-9E725B4D6BDC@kurtis.pp.se> On 1 dec 2005, at 11.37, Per Heldal wrote: >> user TE capability. It does not give the ISP the possibility to >> ignore it, as they could today. > > Shim6 is work in progress and may be used as an argument to adjust > adress-assignment policies sometime in the future. If we want ipv6 > deployed today we have to provide a mechanism to support requirements > about redundancy and independence from individual providers. Ok, that I agree with. - kurtis - From kurtis at kurtis.pp.se Mon Dec 5 14:17:25 2005 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Mon, 5 Dec 2005 14:17:25 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <438ED422.9090904@netegral.co.uk> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> Message-ID: <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> On 1 dec 2005, at 11.44, Cameron C. Gray wrote: > Per Heldal wrote: >> Shim6 is work in progress and may be used as an argument to adjust >> adress-assignment policies sometime in the future. If we want ipv6 >> deployed today we have to provide a mechanism to support requirements >> about redundancy and independence from individual providers. > > I think this hit the nail on the head. Providers (especially those > non-LIR) will not accept something along the lines of SHIM6 or > A.N.Other > competing idea until it gives them just that -- INBOUND ROUTING > INDEPENDENCE. Now you are mixing two issues that Per separated though. Per pointed out that shim6 is work in progress while we need a policy now. > My view is relatively simple; either give everyone who wants one > and has > an AS-Number a /32 or allow /48s into the backbone table. This is of > course if we actually want to give up using IPv4; without the above > most > providers will see it as a step backward and a bad thing (tm). I think each LIR should get a /32 and we should drop the 200 "customer" rule. But that is just me... - kurtis - From kurtis at kurtis.pp.se Mon Dec 5 14:18:07 2005 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Mon, 5 Dec 2005 14:18:07 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <17294.55288.858722.708230@roam.psg.com> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <17294.55288.858722.708230@roam.psg.com> Message-ID: <24AF46D5-7C8F-4AB7-B584-A6FAA7F1B727@kurtis.pp.se> On 1 dec 2005, at 12.01, Randy Bush wrote: >> If you have alternative ideas you know how it works - send text. > > draft-ietf-ipngwg-gseaddr-00.txt > > same one the ietf has ignored and lied about for eight years now I am looking forward to the BOF....:-) - kurtis - From jeroen at unfix.org Mon Dec 5 14:38:06 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 05 Dec 2005 14:38:06 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> Message-ID: <439442BE.2010509@unfix.org> Kurt Erik Lindqvist wrote: > I think each LIR should get a /32 and we should drop the 200 "customer" > rule. But that is just me... A question which most likely only RIPE NCC can answer: has there ever been a LIR who requested an IPv6 allocation and got rejected? LIR's are usually already have 200+ customers, let alone in planning. The people who are complaining (and not proposing what could be done) on this list don't want to be an LIR in the first place. Removing the 200 rule thus would not have much effect in all those cases. Also, they are usually end-sites (eg companies) thus would not pass that rule of the current policy. ISP's with less than 200 customers would indeed. But does it make sense to assign a complete /32 to a company that would not even allocate 200 /48's out of 65k in that /32? Looks a lot like address waste to me. Indeed a /48 to a dailup is also exactly that, for that matter out of my /48 I also only use one single /64, as bridging is more convenient than routing, though I could make my network using a couple of /64's if I wanted, but why should I? Now I can move boxes around without having to renumber them, which I already did 3 times. Kurt Erik Lindqvist wrote: > > On 1 dec 2005, at 12.01, Randy Bush wrote: > >>> If you have alternative ideas you know how it works - send text. >> >> draft-ietf-ipngwg-gseaddr-00.txt >> >> same one the ietf has ignored and lied about for eight years now > > I am looking forward to the BOF....:-) The BOF or the WAR? :) Kidding aside, the distribution of address space doesn't have much to do with routing table size, which is where most people seem to be concerned over. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 238 bytes Desc: OpenPGP digital signature URL: From mohta at necom830.hpcl.titech.ac.jp Mon Dec 5 14:33:32 2005 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Mon, 05 Dec 2005 22:33:32 +0900 Subject: [address-policy-wg] Re: [ipv6-wg] Re: Andre's guide to fix IPv6 In-Reply-To: References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> Message-ID: <439441AC.1060902@necom830.hpcl.titech.ac.jp> Kurt Erik Lindqvist wrote: > So AFAIK the state of the art routers does 40G line-rate deep-packet > inspection with any pattern matching. Once upon a time, there are people who thought 45Mbps were fast. > So remind me again what the > problem is? Price? Sure, that is a question of demand and volume > production... Terabit routers and corresponding bandwidth consumption. Recent findings on the amount of router buffers made terabit electrical routers much less expensive and terabit optical routers, which may be even less expensive than electrical ones, viable. > When MPLS was new I remember being told by vendors that it was the only > way we could forward IPv4 at 10G line-rate. Go figure. When I proposed MPLS, it was over ATM and I already noticed and warned that MPLS (over ATM) inherently is about 10 times slower than IP routers and that MPLS over Ethernet is no better than IP routers. Masataka Ohta From cgray at netegral.co.uk Mon Dec 5 14:33:23 2005 From: cgray at netegral.co.uk (Cameron C. Gray) Date: Mon, 05 Dec 2005 13:33:23 +0000 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> Message-ID: <439441A3.2050904@netegral.co.uk> Kurt Erik Lindqvist wrote: >> I think this hit the nail on the head. Providers (especially those >> non-LIR) will not accept something along the lines of SHIM6 or A.N.Other >> competing idea until it gives them just that -- INBOUND ROUTING >> INDEPENDENCE. > > Now you are mixing two issues that Per separated though. Per pointed out > that shim6 is work in progress while we need a policy now. Kurt, I agree with you they are separate concerns, however as I pointed out they must be addressed similarly if IPv6 is to be adopted on any meaningful scale. I think as far as possible policies should speak to the assumed use and be extensible rather than a stopgap - "we do it this way now, but we now its not good and will change". My point was that yes SHIM6 is a work-in-progress but is not a solution that non-LIR providers will accept willingly; many would rather welcome doomsday of no more address space than work with something that limits their independence. Addressing previous criticisms, As far as the recurring argument of investment to support growing routing tables and memory requirements - how many of you had this when specifying individual hosts? Why can't every server just have the 64K Bill Gates promised would be enough? And wait, didn't he also say the Internet wasn't worth worrying about? Routing equipment will grow and adapt to the technical needs and business will have to fund it or send their customers elsewhere, its an evolution not something we all have to be protected from. (Not that RIPE is a place to dictate business cases and budgets anyway...) Can anyone digest for me into simple bullet points the other arguments for not allowing end site multihoming (and possibly PI therefore), other than: a) routing table size and therefore equipment concerns b) growing/padding RIPE membership numbers c) other immature solutions which border on NAT-insanity which don't actually address the independence angle I see the a) and c) above as cosmetic and easy to work around, and i think that b) would only be a good thing (tm) as all our fees drop with more members. Otherwise I can't see any more limiting factors to running it almost the same way as v4, instead of multiple prefixes per applicant its one. -- Best Regards, Cameron Gray Director, Netegral Limited www.netegral.co.uk | 0871 277 6845 From tjc at ecs.soton.ac.uk Mon Dec 5 17:32:51 2005 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Mon, 5 Dec 2005 16:32:51 +0000 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> References: <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> Message-ID: <20051205163251.GC1458@login.ecs.soton.ac.uk> On Mon, Dec 05, 2005 at 02:17:25PM +0100, Kurt Erik Lindqvist wrote: > > I think each LIR should get a /32 and we should drop the 200 > "customer" rule. But that is just me... That would be too easy :) -- Tim/::1 From tjc at ecs.soton.ac.uk Mon Dec 5 17:34:19 2005 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Mon, 5 Dec 2005 16:34:19 +0000 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <439442BE.2010509@unfix.org> References: <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> <439442BE.2010509@unfix.org> Message-ID: <20051205163419.GD1458@login.ecs.soton.ac.uk> On Mon, Dec 05, 2005 at 02:38:06PM +0100, Jeroen Massar wrote: > > A question which most likely only RIPE NCC can answer: has there ever > been a LIR who requested an IPv6 allocation and got rejected? > > LIR's are usually already have 200+ customers, let alone in planning. > > The people who are complaining (and not proposing what could be done) on > this list don't want to be an LIR in the first place. > Removing the 200 rule thus would not have much effect in all those cases. There are certainly organisations that cannot meet the 200 rule that have a /32.. RIPE-NCC is not inflexible. Tim::/1 From president at ukraine.su Mon Dec 5 17:42:13 2005 From: president at ukraine.su (Max Tulyev) Date: Mon, 5 Dec 2005 19:42:13 +0300 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 PI In-Reply-To: <1133565349l.24742l.1l@sal.intra.chbm.net> References: <200511241822.jAOIMAfk018658@alpha.bartels.de> <1133565349l.24742l.1l@sal.intra.chbm.net> Message-ID: <200512051942.13694.president@ukraine.su> > On 25 Nov 2005 09:55:54, Roger Jorgensen wrote: > > Again, we don't need PI space and multihoming, what we need are a way to > > give the users and GOOD connectivity (uptime, speed etc) and make it easy > > for them to switch providers as they see fit. > > No. We want to peer with whoever we see fit. If that means becoming a LIR > and geting PA, so be it. Need .com? Become a registrar and get it! Isn't it? ;) -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From gert at space.net Mon Dec 5 18:06:48 2005 From: gert at space.net (Gert Doering) Date: Mon, 5 Dec 2005 18:06:48 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> References: <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> Message-ID: <20051205170648.GE69925@Space.Net> Hi, On Mon, Dec 05, 2005 at 02:17:25PM +0100, Kurt Erik Lindqvist wrote: > I think each LIR should get a /32 and we should drop the 200 > "customer" rule. But that is just me... Actually I like the "every AS should get a " approach (with a yearly recurring fee for AS and network, to guarantee return of the resources as soon as the importance of having a slot in the global routing table doesn't outweigh the costs anymore). "Every LIR gets a /32 (upon request), no questions asked" is a concept that I'm also happy with - as I have said before. For those that are afraid of the landrush: limit that policy to 5.000 LIRs per region. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From Olaf.Bonness at t-systems.com Mon Dec 5 18:13:03 2005 From: Olaf.Bonness at t-systems.com (Bonness, Olaf) Date: Mon, 5 Dec 2005 18:13:03 +0100 Subject: AW: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fi x IPv6 Message-ID: <97A461F3EE5284469E41ED3728202F4101101005@S4DE9JSAAMW.ost.t-com.de> Hi Gerd, > -----Ursprungliche Nachricht----- > Von: Gert Doering [mailto:gert at space.net] > Gesendet: Montag, 5. Dezember 2005 18:07 > An: Kurt Erik Lindqvist > Cc: Cameron C. Gray; Per Heldal; address-policy-wg at ripe.net; > ipv6-wg at ripe.net > Betreff: Re: [ipv6-wg] Re: Re: [address-policy-wg] Re: > Andre's guide to > fix IPv6 > > > Hi, > > On Mon, Dec 05, 2005 at 02:17:25PM +0100, Kurt Erik Lindqvist wrote: > > I think each LIR should get a /32 and we should drop the 200 > > "customer" rule. But that is just me... > > Actually I like the "every AS should get a " approach (with > a yearly recurring fee for AS and network, to guarantee return of the > resources as soon as the importance of having a slot in the global > routing table doesn't outweigh the costs anymore). > > "Every LIR gets a /32 (upon request), no questions asked" is a concept > that I'm also happy with - as I have said before. For those that are > afraid of the landrush: limit that policy to 5.000 LIRs per region. Not sure if that works. Kind of "First come - first serve" thing. Regards Olaf > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: 81421 > > SpaceNet AG Mail: netmaster at Space.Net > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > D- 80807 Muenchen Fax : +49-89-32356-234 > From dr at cluenet.de Mon Dec 5 18:27:24 2005 From: dr at cluenet.de (Daniel Roesen) Date: Mon, 5 Dec 2005 18:27:24 +0100 Subject: [ipv6-wg] Re: Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <20051205170648.GE69925@Space.Net> References: <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> <20051205170648.GE69925@Space.Net> Message-ID: <20051205172724.GA6858@srv01.cluenet.de> On Mon, Dec 05, 2005 at 06:06:48PM +0100, Gert Doering wrote: > On Mon, Dec 05, 2005 at 02:17:25PM +0100, Kurt Erik Lindqvist wrote: > > I think each LIR should get a /32 and we should drop the 200 > > "customer" rule. But that is just me... > > Actually I like the "every AS should get a " approach (with > a yearly recurring fee for AS and network, That sounds good, if the fee is reasonable (means: covers the cost of this only, and not subsidizing LIR operations of others). > "Every LIR gets a /32 (upon request), no questions asked" is a concept > that I'm also happy with - as I have said before. For those that are > afraid of the landrush: limit that policy to 5.000 LIRs per region. Those kind of ideas can only come from folks who are already in the business and have their own allocation already. *shaking head* "Sorry, you're to late in the game - the market already has 5000 players, but we have this nice transit offering with PA space here...". Brilliant. Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From gert at space.net Mon Dec 5 18:58:30 2005 From: gert at space.net (Gert Doering) Date: Mon, 5 Dec 2005 18:58:30 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fi x IPv6 In-Reply-To: <97A461F3EE5284469E41ED3728202F4101101005@S4DE9JSAAMW.ost.t-com.de> References: <97A461F3EE5284469E41ED3728202F4101101005@S4DE9JSAAMW.ost.t-com.de> Message-ID: <20051205175830.GF69925@Space.Net> Hi, On Mon, Dec 05, 2005 at 06:13:03PM +0100, Bonness, Olaf wrote: > > "Every LIR gets a /32 (upon request), no questions asked" is a concept > > that I'm also happy with - as I have said before. For those that are > > afraid of the landrush: limit that policy to 5.000 LIRs per region. > > Not sure if that works. Kind of "First come - first serve" thing. Yes, so what shall we do instead? "Nobody gets addresses, no mistakes made"? The whole point of this discussion is that there are two fractions: - one side is so afraid of doing the wrong thing that they want to delay everything until the perfect solution is found - the other side wants to get things rolling, and is willing to risk a few thousand entries in the global BGP table (whatever that is). and I don't think we'll ever reach consensus between those groups. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From ripe-wgs.cs at schiefner.de Mon Dec 5 19:14:33 2005 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Mon, 05 Dec 2005 19:14:33 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <97A461F3EE5284469E41ED3728202F4101101005@S4DE9JSAAMW.ost.t-com.de> References: <97A461F3EE5284469E41ED3728202F4101101005@S4DE9JSAAMW.ost.t-com.de> Message-ID: <43948389.6050309@schiefner.de> Bonness, Olaf wrote: >Von: Gert Doering [mailto:gert at space.net] >>"Every LIR gets a /32 (upon request), no questions asked" is a concept >>that I'm also happy with - as I have said before. For those that are >>afraid of the landrush: limit that policy to 5.000 LIRs per region. > > Not sure if that works. Kind of "First come - first serve" thing. > Regards Also, such a policy is most likely in direct conflict with one of the basic paradigms of a RIR - which is equal treatment of its members in equal circumstances. Best, -C. From jeroen at unfix.org Tue Dec 6 00:32:44 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 06 Dec 2005 00:32:44 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <20051205175830.GF69925@Space.Net> References: <97A461F3EE5284469E41ED3728202F4101101005@S4DE9JSAAMW.ost.t-com.de> <20051205175830.GF69925@Space.Net> Message-ID: <4394CE1C.6060103@unfix.org> Gert Doering wrote: > Hi, > > On Mon, Dec 05, 2005 at 06:13:03PM +0100, Bonness, Olaf wrote: >>> "Every LIR gets a /32 (upon request), no questions asked" is a concept >>> that I'm also happy with - as I have said before. For those that are >>> afraid of the landrush: limit that policy to 5.000 LIRs per region. >> Not sure if that works. Kind of "First come - first serve" thing. > > Yes, so what shall we do instead? > > "Nobody gets addresses, no mistakes made"? 2000::/3 is only 1/8th of the total IPv6 address space, we can make mistakes 8 times :) But the problem then is that we will have 8 swamps of crappy managed address space which most likely nobody will return. For that matter, there is not much force to get folks to return address space but having the parties they want to talk with filter it out. I wonder what would happen if eg Google would ask (access) ISP's to start paying for traffic 'or else' :) > The whole point of this discussion is that there are two fractions: > > - one side is so afraid of doing the wrong thing that they want to > delay everything until the perfect solution is found > > - the other side wants to get things rolling, and is willing to risk > a few thousand entries in the global BGP table (whatever that is). > > and I don't think we'll ever reach consensus between those groups. Especially as there are no proper argumented proposals being made by the second group, except that the current one is not to their liking and that things that get proposed doesn't fit their bill. My view on all of this is the following (hinting group #2 :) : - reserve a global, thus all the RIR's in one slot and split that up under the RIR's, block for 'multihoming purposes' (3ffe::/16 seems very appropriate as it is already swamp) - give people who want to multihome a /48(*) out of this block. - let them pay an annual fee for it that makes it a real incentive to maintain it and use it. - let them sign a document that when proper multihoming (eg SHIM6) comes that they will start using that and after X time stop announcing their /48 more specific. Also let other people filter at wish. (Add lawyer style wording in the above ;) * = or other appropriate size, maybe per /40 is better so that each multihomer could have 256 sites behind them, though then they are at the 200-rule which they seem to be bothered with already... :) This gives them PI address space, when SHIM6 or a similar method gets realized the swamp gets cleaned. Of course the swamp will only be cleansed when everybody cooperates and I don't see that happening. One advantage of the "multihoming block" is that it will be very easy to filter out. Of course such multihoming blocks can have private peerings and people that don't filter them won't see them. But HEY isn't that exactly what is already happening now? Check GRH* to see how many /48's from separate ASN's can already be seen (~60 at the moment). I guess that 6bone space will be a perfect example on what happens with swamp space that is supposed to be returned. The big issue in the above is that many people will not like SHIM6 or other methods because it is not what they have now and they will claim that they don't have proper control over the route announcements of that block. I am then inclined to ask them how much control they have over their route announcements when it leaves their ASN... ;) Greets, Jeroen * = http://www.sixxs.net/tools/grh/lg/?show=endsite&find=::/0 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 238 bytes Desc: OpenPGP digital signature URL: From jeroen at unfix.org Tue Dec 6 00:46:57 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 06 Dec 2005 00:46:57 +0100 Subject: [ipv6-wg] De-aggregation of assigned IPv6 prefixes? Message-ID: <4394D171.6080601@unfix.org> Hi, http://www.ripe.net/ripe/docs/ipv6policy.html#initial_criteria reads amongst others: 8<------------------- c) plan to provide IPv6 connectivity to organisations to which it will assign /48s by advertising that connectivity through its single aggregated address allocation -------------------->8 According to the above, after the /48, can one announce more specifics or should/must one not do this? (*) The RIPE Registry allows registering more specific route6 objects. If this is allowed, then why is the above parrt, after '/48', then included in the policy? What is the exact intention of the sentence? Greets, Jeroen *= of course one is lord of their own network and thus can announce whatever one wants and just hope/agree that others accept it. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 238 bytes Desc: OpenPGP digital signature URL: From gert at space.net Tue Dec 6 08:41:24 2005 From: gert at space.net (Gert Doering) Date: Tue, 6 Dec 2005 08:41:24 +0100 Subject: [ipv6-wg] De-aggregation of assigned IPv6 prefixes? In-Reply-To: <4394D171.6080601@unfix.org> References: <4394D171.6080601@unfix.org> Message-ID: <20051206074124.GG69925@Space.Net> Hi, On Tue, Dec 06, 2005 at 12:46:57AM +0100, Jeroen Massar wrote: > http://www.ripe.net/ripe/docs/ipv6policy.html#initial_criteria > reads amongst others: > 8<------------------- > c) plan to provide IPv6 connectivity to organisations to which it will > assign /48s by advertising that connectivity through its single > aggregated address allocation > -------------------->8 > > According to the above, after the /48, can one announce more specifics > or should/must one not do this? (*) When this came up last time, the explanation was "it is the LIR's duty to make sure that the aggregate will always be visible!" (so that the individual networks need not be announced). It's not meant to prohibit announcing more-specifics, though (which RIPE can't do anyway). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From oppermann at networx.ch Mon Dec 5 18:34:50 2005 From: oppermann at networx.ch (Andre Oppermann) Date: Mon, 05 Dec 2005 18:34:50 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 References: <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> <20051205170648.GE69925@Space.Net> Message-ID: <43947A3A.CE80737B@networx.ch> Gert Doering wrote: > > Hi, > > On Mon, Dec 05, 2005 at 02:17:25PM +0100, Kurt Erik Lindqvist wrote: > > I think each LIR should get a /32 and we should drop the 200 > > "customer" rule. But that is just me... > > Actually I like the "every AS should get a " approach (with > a yearly recurring fee for AS and network, to guarantee return of the > resources as soon as the importance of having a slot in the global > routing table doesn't outweigh the costs anymore). > > "Every LIR gets a /32 (upon request), no questions asked" is a concept > that I'm also happy with - as I have said before. For those that are > afraid of the landrush: limit that policy to 5.000 LIRs per region. You can't use this kind of arbitrary limit. Doing it this way is seriously hot water in terms of anti-trust law. In general some of the discussed (and the current) IPv6 policy has troublesome aspects from an EU anti-trust point of view. To be on the safe side all policy must be on pure technical, equality and justifyable terms. RIPE NCC and its membership system may be deemed to be an illegal monopoly under certain circumstances if equality rules are not strictly followed and requests for membership are treated selectively. Also the current IPv6 policy that only ISPs can get independently routeable address space is a fine line into anti-competitive behaviour which may be illegal according to EU anti-trust law. I think is very important that RIPE NCC conducts a legal assertion through some EU anti-trust specialized law firm to assert the problematic aspects of any current and future IPv6 policy or policy proposal. With IPv4 there are no anti-trust problems because everyone may get any justifyable amount of address space. AS numbers are equally available too and only bound on the actual use of them. All this is deemed fair under EU anti-trust law. -- Andre From marcus.gerdon at mainz-kom.de Tue Dec 6 02:30:56 2005 From: marcus.gerdon at mainz-kom.de (Marcus Gerdon) Date: Tue, 6 Dec 2005 02:30:56 +0100 Subject: [ipv6-wg] IPv6 prefixes / PI References: <4394D171.6080601@unfix.org> Message-ID: <004901c5fa04$b4c24190$d32f1fac@avalon> Hi @All, (in advance I'm sorry for the typo's and mis-chosen wordings as I'm not native English and just out of my favourite pub ...) I'm following this discussion for quite some time now, but to me it looks like many of you are going for a 'holy war'. Although I'm surely misunderstood, I've the impression (as for most discussions & votes) only the larger members here will get heard and/or will discuss this as the larger part of the members can't effort someone getting payed exclusively for community work. Let me start introducing a simple statement: Drop IPv6! No one (ok, nearly no one) is going to use IPv6. I'm speaking out of experience for de.mainzkom (a few months ago merger to de.citykom) being a regional ISP in Germany. Out of approx. 50 business customers I've spoken to TWO were interested in IPv6 trials. Only ONE of our transit customers explicitly asked for v6 (a university). How do you think a 'very large' member is going into the discussion for a lot more than a /32 ? Same way I stated need for our /32: let's count ANY end consumer (may it be a dynamic DSL account) a /64 and each business customer a /48. I had worries myself satisfying the 200-customer-rule - I solved it by assuming each of our DSL customers getting assigned a /48 ... regardless whether he needs/uses it. In the meanwhile applying this method the /32 is filled and to small ... could I argue for another one or maybe /30 or even more ? There's a point to the increasing number of IPv4 PI space allocated: Enterprise customers WANT to be independent f their ISP. Quite a number of them being governmental organizations or such HAVE TO open a Request for Proposal every few years (2-3) and change their ISP equivalently. Last time I had to explain that there's IPv4 PI but no IPv6 PI available. What do you think ? They dropped v6 completely! Surely, you'd have to recitate RIPE rules and deny the request for PI - but what would happen to your relationship towards your potential customer ? Can you afford dropping them - multiple a year ? Making v6 PI available may overload memory of current routers. And I'm the last ignoring this matter. There IS a limit any ISP can effort expenses on equipment. At least in Germany by the current market structure I'm glad of anybody NOT signing an end-consumer DSL contract. The 'the-cheaper-the-better' mentality is sooner or later killing all of us. By a 20 month ROI for a single DSL where do I get the money for upgrading routers from ? By not offering IPv6 so I can keep with my current routers ? Enterprise customers are asking (seldom enough, but they do) for Multicast and increasingly for v6 in addition to MPLS services - but these are the minority. Where's the point the average ISP is eaerning money ? Many of you (I've had no sense for looking up each one's approx. size specifically) sounds like one of these german (wanna-be)-monopolists: we're that large, customer have to come to us. You deny any small ISP their right for existence. Maybe there's need for an organized structure of the internet. Let's get the routing and address design be dictated by the known tier 1's & maybe 2's. You want that ? I think the mayority of attendents of these discussions do (as none of the smaller is able to effort time for RIPE-WG's, DECIX-WG's, AMS-IX-WG's etc...). When I get time for these I follow and sometimes response to WG's, but that's neither part of my job nor paid. You'd prefer a 200 pseudo-customer enterprise above a 100-customer ISP. To my personal opinion there're already too many non-ISP AS'es out there and much more - sadly mostly ISP - announcing nonsense (Gerd, I appreciated the discussion about aggregation some time ago) but HOW do you want to distinguish ? Maybe RIPE - and/or becoming a LIR in general - should be closed for non-ISP ... But where to draw the line ? Therefore I think we should go for IPv6 PI - with some constraints: - PI space (no matter whether v4 or v6) should be charged an annual fee - AS numbers should be charged an annual fee - a minimum size for PI assignments should be established I once got assigned a /24, /26, /27 of v4-PI. This satisfied the request made but when asked for routing we had to deny this as longer than /24 is simple pollution of the routing table. Why not go for v4 PI always being a multiple of /24 (if at least /25 is explained - any longer is nonsense by itself) and v6 being at most /40 (out of a 'dedicated' /32 or shorter) with more stringent criteria ? I always have a hard thought about equipment needs and cost - but do you remember the primary reason there's such a variety of ISP ? This reason are the variety of customer needs and the CUSTOMER's will. regards, Marcus PS: I'm sorry for the mix of thoughts above ... just had a '42' day .... :-| From gert at space.net Tue Dec 6 09:18:50 2005 From: gert at space.net (Gert Doering) Date: Tue, 6 Dec 2005 09:18:50 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <43948389.6050309@schiefner.de> References: <97A461F3EE5284469E41ED3728202F4101101005@S4DE9JSAAMW.ost.t-com.de> <43948389.6050309@schiefner.de> Message-ID: <20051206081850.GI69925@Space.Net> Hi, On Mon, Dec 05, 2005 at 07:14:33PM +0100, Carsten Schiefner wrote: > >Von: Gert Doering [mailto:gert at space.net] > >>"Every LIR gets a /32 (upon request), no questions asked" is a concept > >>that I'm also happy with - as I have said before. For those that are > >>afraid of the landrush: limit that policy to 5.000 LIRs per region. > > Also, such a policy is most likely in direct conflict with one of the > basic paradigms of a RIR - which is equal treatment of its members in > equal circumstances. Circumstances before and after reaching a given number of routes are not "equal". Right now, nobody knows whether we will *ever* reach 10.000 IPv6 routes in the global BGP table - if we hit 10.000, we know that there is a given possibility of having "very very very many routes", and that conservation of routing table slots might be more of an issue than right now (where the issue is more along the lines of "get it going, or abandon it"). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From gert at space.net Tue Dec 6 09:21:22 2005 From: gert at space.net (Gert Doering) Date: Tue, 6 Dec 2005 09:21:22 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <4394CE1C.6060103@unfix.org> References: <97A461F3EE5284469E41ED3728202F4101101005@S4DE9JSAAMW.ost.t-com.de> <20051205175830.GF69925@Space.Net> <4394CE1C.6060103@unfix.org> Message-ID: <20051206082122.GJ69925@Space.Net> Hi, On Tue, Dec 06, 2005 at 12:32:44AM +0100, Jeroen Massar wrote: > > - the other side wants to get things rolling, and is willing to risk > > a few thousand entries in the global BGP table (whatever that is). > > > > and I don't think we'll ever reach consensus between those groups. > > Especially as there are no proper argumented proposals being made by the > second group, except that the current one is not to their liking and > that things that get proposed doesn't fit their bill. That's not fully correct. There are a number of fairly specific proposals (to name three, in the order of "radicality": "abandon 200-customer rule", "give every LIR a /32", "give every AS holder a prefix"). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From gert at space.net Tue Dec 6 09:27:59 2005 From: gert at space.net (Gert Doering) Date: Tue, 6 Dec 2005 09:27:59 +0100 Subject: [ipv6-wg] Re: Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <20051205172724.GA6858@srv01.cluenet.de> References: <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> <20051205170648.GE69925@Space.Net> <20051205172724.GA6858@srv01.cluenet.de> Message-ID: <20051206082759.GM69925@Space.Net> Hi, On Mon, Dec 05, 2005 at 06:27:24PM +0100, Daniel Roesen wrote: > Those kind of ideas can only come from folks who are already in the > business and have their own allocation already. *shaking head* Unlike some other participants on this list, I'm actually aiming for something that could reach consensus. Otherwise, all this is wasted time, and we could directly go to ITU and ask them to fix the Internet. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From gert at space.net Tue Dec 6 09:31:53 2005 From: gert at space.net (Gert Doering) Date: Tue, 6 Dec 2005 09:31:53 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <43947A3A.CE80737B@networx.ch> References: <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> <20051205170648.GE69925@Space.Net> <43947A3A.CE80737B@networx.ch> Message-ID: <20051206083152.GN69925@Space.Net> Hi, On Mon, Dec 05, 2005 at 06:34:50PM +0100, Andre Oppermann wrote: > > "Every LIR gets a /32 (upon request), no questions asked" is a concept > > that I'm also happy with - as I have said before. For those that are > > afraid of the landrush: limit that policy to 5.000 LIRs per region. > > You can't use this kind of arbitrary limit. Doing it this way is seriously > hot water in terms of anti-trust law. It depends on how you handle it. My line of reasoning is "we don't have enough experience to judge how things will evolve, but there are some serious doubts on whether we can handle unreasonably large number of BGP routes - so we put a limit in there, and then reconsider in a few years whether our strategy is useful or not". I don't really expect the "5000" number to be a serious issue - but if it turns out to be, policy needs changing, of course. In whatever direction. [..] > Also the current IPv6 policy that only ISPs can get independently routeable > address space is a fine line into anti-competitive behaviour which may be > illegal according to EU anti-trust law. As nobody is preventing you from becoming an ISP, this line of argument is completly cr**. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From leo at ripe.net Tue Dec 6 09:42:09 2005 From: leo at ripe.net (leo vegoda) Date: Tue, 6 Dec 2005 09:42:09 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <439442BE.2010509@unfix.org> Message-ID: <003601c5fa40$f23b7140$1d0200c1@RIPENCCRS5> Hi Jeroen, Jeroen Massar wrote: > > > I think each LIR should get a /32 and we should drop the > 200 "customer" > > rule. But that is just me... > > A question which most likely only RIPE NCC can answer: has there ever > been a LIR who requested an IPv6 allocation and got rejected? We analysed the requests and questions we have received and presented the details at RIPE 50. http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-ap-ipv6nu mbers.pdf mms://webcast.ripe.net/ripe-50/address-policy-1.wmv http://www.ripe.net/ripe/wg/address-policy/r50-minutes.html (section F) Basically, ~2% of requests did not end in address space being registered. We don't know how many requests are not sent in. Regards, -- leo vegoda RIPE NCC Registration Services Manager From rogerj at jorgensen.no Tue Dec 6 09:43:56 2005 From: rogerj at jorgensen.no (Roger Jorgensen) Date: Tue, 6 Dec 2005 09:43:56 +0100 (CET) Subject: [ipv6-wg] a consensus, about what? In-Reply-To: <20051206082759.GM69925@Space.Net> References: <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfp m1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telst ra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837- 4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingeng ine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205D A32AE@kurtis.pp.se> <20051205170648.GE69925@Space.Net> <20051205172724.GA68 58@srv01.cluenet.de> <20051206082759.GM69925@Space.Net> Message-ID: took me the liberty to change the subject line yet again... On Tue, 6 Dec 2005, Gert Doering wrote: > Unlike some other participants on this list, I'm actually aiming for > something that could reach consensus. > > Otherwise, all this is wasted time, and we could directly go to ITU and > ask them to fix the Internet. After this quite long but interesting discussion on the two working group mailing lists involved I guess the above sums it up quite well, where do we want to go tomorrow and the day after tomorrow? The future of Internet to put it short... and I'm not sure any of the above are the right place for that discussion. so what sort of consensus are we aiming for, and about what? A new policy for AS, a net block, routing policy, multihoming, or just IPv6 in general? This entire discussion have been sidetracked alot, not a bad thing either, quite alot of topics have been discussed and interesting thoughts brought forward.. but what are our goal with all this? -- ------------------------------ Roger Jorgensen | rogerj at stud.cs.uit.no | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no ------------------------------------------------------- From gert at space.net Tue Dec 6 09:56:04 2005 From: gert at space.net (Gert Doering) Date: Tue, 6 Dec 2005 09:56:04 +0100 Subject: [ipv6-wg] Re: a consensus, about what? In-Reply-To: References: <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> <20051205170648.GE69925@Space.Net> <20051205172724.GA6858@srv01.cluenet.de> <20051206082759.GM69925@Space.Net> Message-ID: <20051206085604.GO69925@Space.Net> Hi, On Tue, Dec 06, 2005 at 09:43:56AM +0100, Roger Jorgensen wrote: > so what sort of consensus are we aiming for, and about what? A new policy > for AS, a net block, routing policy, multihoming, or just IPv6 in general? > This entire discussion have been sidetracked alot, not a bad thing either, > quite alot of topics have been discussed and interesting thoughts brought > forward.. but what are our goal with all this? The basic policy issue seems to me: - who can get a (globally routeable [1]) IPv6 prefix it might affect the policy "who can get an AS number". The basic technical issue seems to be: - is "IPv4-style" BGP multihoming the correct way to do in IPv6 [1] globally routeable in the sense of "the majority of the participants in the global IPv6 routing system will be able to send packets that way". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From cfriacas at fccn.pt Tue Dec 6 10:25:04 2005 From: cfriacas at fccn.pt (Carlos Friacas) Date: Tue, 6 Dec 2005 09:25:04 +0000 (WET) Subject: [ipv6-wg] Re: [address-policy-wg] IPv6 prefixes / PI In-Reply-To: <004901c5fa04$b4c24190$d32f1fac@avalon> References: <4394D171.6080601@unfix.org> <004901c5fa04$b4c24190$d32f1fac@avalon> Message-ID: Hi, On Tue, 6 Dec 2005, Marcus Gerdon wrote: > Hi @All, > > (in advance I'm sorry for the typo's and mis-chosen wordings as I'm not > native English and just out of my favourite pub ...) > > I'm following this discussion for quite some time now, but to me it looks > like many of you are going for a 'holy war'. I also would say that is a strong possibility. :-) > Although I'm surely misunderstood, I've the impression (as for most > discussions & votes) only the larger members here will get heard and/or will > discuss this as the larger part of the members can't effort someone getting > payed exclusively for community work. > > Let me start introducing a simple statement: > > Drop IPv6! Wow! Quite a radical statement. However, if we are going to talk about IPv6 deployment, i can agree that the population using IPv6 is rather small than the one not using it... so, convincing everyone to remove IPv6 from their networks is a shorter path than getting worldwide IPv6 deployment... (but not as interesting!) :-) > No one (ok, nearly no one) is going to use IPv6. Besides the fact people are already using it, some people are also using it without any knowledge about it (i.e. apps using Teredo, transparent proxying, newsfeeds, ...). If we look at the current active ASNs, we should see that networks (ASNs) using IPv6 are still a small set, yes! - but we don't know how will this evolve in the (near) future. Any crystal ball around? I usually keep my antennas tunned in with what Geoff Huston says about IPv4 address exaustion, and try to keep an eye on IANA's list... i hope we don't get a new "Y2K" issue, but i've been more optimistic about it than nowadays. > I'm speaking out of experience for de.mainzkom (a few months ago merger to > de.citykom) being a regional ISP in Germany. Out of approx. 50 business > customers I've spoken to TWO were interested in IPv6 trials. Only ONE of > our transit customers explicitly asked for v6 (a university). I read this as: Do you want to satisfy your customer demand? even if that means only 2% of your customer base? Then, some interesting questions arise: - is the customer able to pay for what he is demanding? (IPv6 is not free, you know... IPv6 also means packets getting in and out of your network...) - is this an opportunity to deploy a service, that 98% of the current customer base is not interested, but that can help bring new customers? - are you sure, that 98% figure won't go down in a year's time? and in 2 year's time? > How do you think a 'very large' member is going into the discussion for a > lot more than a /32 ? Same way I stated need for our /32: let's count ANY > end consumer (may it be a dynamic DSL account) a /64 and each business > customer a /48. > > I had worries myself satisfying the 200-customer-rule - I solved it by > assuming each of our DSL customers getting assigned a /48 ... regardless > whether he needs/uses it. In the meanwhile applying this method the /32 is > filled and to small ... could I argue for another one or maybe /30 or even > more ? Usually people don't bother. a /32 is perfectly ok for a small-medium ISP. And about the 200-rule... well, that will fade out with time, and when sensible policy proposals are accepted! *hint*, *hint*... > There's a point to the increasing number of IPv4 PI space allocated: > > Enterprise customers WANT to be independent f their ISP. Quite a number of > them being governmental organizations or such HAVE TO open a Request for > Proposal every few years (2-3) and change their ISP equivalently. Last time > I had to explain that there's IPv4 PI but no IPv6 PI available. What do you > think ? They dropped v6 completely! As I see it, most of LIRs are ISPs, hence ISPs are making policies. ISPs like to keep their customers. Saying to a customer they'll have to go through the pain of a renumbering process is a good argument to keep anyone aboard their network. :-) 1+1=2 Then there is "the routing table size problem" -- if everyone gets its own PI, some routers will not be able to keep up... but that's also a danger on the IPv4 world... if someone wants a PI, it's only a matter of money and imagination. :-) > Surely, you'd have to recitate RIPE rules and deny the request for PI - but > what would happen to your relationship towards your potential customer ? Can > you afford dropping them - multiple a year ? Surely not. :-) If ISP1 doesnt find a way to adapt the customer's situation to the rules in order to please the customer, ISP2 or ISP3 gladly will... > Making v6 PI available may overload memory of current routers. And I'm the > last ignoring this matter. What is a "current router" ? My ASN uses a Juniper M10, a Cisco 7206 and a Cisco 12410 to deal with BGP4+ (about 175k v4 routes + about 500 v6 routes). Every one of them deals with IPv4 and IPv6 routes, if i may add. Some years ago we used two Cisco 75xx. I dont really know which equipment will form my "border router team" 2-3 years from now... > There IS a limit any ISP can effort expenses on equipment. Surely. And if you provide a better network, you should mirror the costs of a better network to your customers... > At least in > Germany by the current market structure I'm glad of anybody NOT signing an > end-consumer DSL contract. The 'the-cheaper-the-better' mentality is sooner > or later killing all of us. By a 20 month ROI for a single DSL where do I > get the money for upgrading routers from ? By not offering IPv6 so I can > keep with my current routers ? Last 4 year experience says you can deploy IPv6 with minimal costs. Just use simple engineering... :-) If you don't want/cant to mess out with the IPv4 routers, just use a cheap alternative (quagga/zebra/...) > Enterprise customers are asking (seldom > enough, but they do) for Multicast and increasingly for v6 in addition to > MPLS services - but these are the minority. Luckly, we would expect most of the multicast thinggy to be intra-domain :-) > Where's the point the average ISP is eaerning money ? The point where it satisfies customer demand, without charging less for the usage of their infrastructure? > Many of you (I've had no sense for looking up each one's approx. size > specifically) sounds like one of these german (wanna-be)-monopolists: we're > that large, customer have to come to us. You deny any small ISP their right > for existence. > > Maybe there's need for an organized structure of the internet. Let's get the > routing and address design be dictated by the known tier 1's & maybe 2's. That's even a dangerous path. ISPs also want tier-1/tier-2 independence! :-))) > You want that ? I think the mayority of attendents of these discussions do > (as none of the smaller is able to effort time for RIPE-WG's, DECIX-WG's, > AMS-IX-WG's etc...). When I get time for these I follow and sometimes > response to WG's, but that's neither part of my job nor paid. Strongly agree. :-) > You'd prefer a 200 pseudo-customer enterprise above a 100-customer ISP. > > To my personal opinion there're already too many non-ISP AS'es out there and > much more - sadly mostly ISP - announcing nonsense (Gerd, I appreciated the > discussion about aggregation some time ago) but HOW do you want to > distinguish ? Maybe RIPE - and/or becoming a LIR in general - should be > closed for non-ISP ... But where to draw the line ? > > Therefore I think we should go for IPv6 PI - with some constraints: > > - PI space (no matter whether v4 or v6) should be charged an annual fee > - AS numbers should be charged an annual fee > - a minimum size for PI assignments should be established That is a possible set of ideas, yes. You can also raise the question of charging or not to your customers when announcing their PI prefixes. Thruthfully, when an ISP announces an extra PI prefix, its peers will have to accept it or not. Usually they do, but how about if they asked: "Hey, what do i gain by accepting it? I only agreed to receive your PA prefixes in the first place..." > I once got assigned a /24, /26, /27 of v4-PI. This satisfied the request > made but when asked for routing we had to deny this as longer than /24 is > simple pollution of the routing table. Is there an authority that can regulate what is pollution and what is not? :-) > Why not go for v4 PI always being a multiple of /24 (if at least /25 is > explained - any longer is nonsense by itself) and v6 being at most /40 (out > of a 'dedicated' /32 or shorter) with more stringent criteria ? > > I always have a hard thought about equipment needs and cost - but do you > remember the primary reason there's such a variety of ISP ? This reason are > the variety of customer needs and the CUSTOMER's will. Sure. And often *one* customer will get a better service from an ISP with a 50 customer base, than *one* customer on an ISP network with a 5000 customer base... unless its monthly numbers enter the TOP-whatever in the ISP's accounting dept. :-) > regards, > > Marcus > > PS: I'm sorry for the mix of thoughts above ... just had a '42' day .... :-| Found your e-mail to be very useful, and very, very market-wise. Thanks! Regards, ./Carlos -------------- Wide Area Network (WAN) Workgroup, CMF8-RIPE, CF596-ARIN FCCN - Fundacao para a Computacao Cientifica Nacional http://www.fccn.pt "Internet is just routes (175261/555), naming (millions) and... people!" From slz at baycix.de Tue Dec 6 11:09:12 2005 From: slz at baycix.de (Sascha Lenz) Date: Tue, 06 Dec 2005 11:09:12 +0100 Subject: [ipv6-wg] Re: Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <20051206082759.GM69925@Space.Net> References: <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> <20051205170648.GE69925@Space.Net> <20051205172724.GA6858@srv01.cluenet.de> <20051206082759.GM69925@Space.Net> Message-ID: <43956348.4040506@baycix.de> Hi, Gert Doering wrote: > Hi, > > On Mon, Dec 05, 2005 at 06:27:24PM +0100, Daniel Roesen wrote: >>Those kind of ideas can only come from folks who are already in the >>business and have their own allocation already. *shaking head* > > Unlike some other participants on this list, I'm actually aiming for > something that could reach consensus. > > Otherwise, all this is wasted time, and we could directly go to ITU and > ask them to fix the Internet. yes, please, fix the internet. I'd say we elect an Internet king which gives out all the rules! Worked for some hundret years. ...joke aside. The problem with consensus is, that it won't be reached with discussions, because in the internet world there is no "tie-breaker" who will finally make the descision about the outcome of the discussion ("no king"). The only way is to post some detailed policy suggestions and have some kind of voting about it, either in public (e.g. usenet-wise) or on RIPE/RIR level. That will give you at least some more exact numbers on the majority for or against a certain suggestion. I can't really tell about what's the most favoured policy for IPv6 Allocations and PI Address Assignments at the moment. It's not nescessarily the policy favoured by the ones who bark the loudest during the discussions. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From gert at space.net Tue Dec 6 11:46:12 2005 From: gert at space.net (Gert Doering) Date: Tue, 6 Dec 2005 11:46:12 +0100 Subject: [ipv6-wg] Re: Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <43956348.4040506@baycix.de> References: <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> <20051205170648.GE69925@Space.Net> <20051205172724.GA6858@srv01.cluenet.de> <20051206082759.GM69925@Space.Net> <43956348.4040506@baycix.de> Message-ID: <20051206104612.GQ69925@Space.Net> Hi, On Tue, Dec 06, 2005 at 11:09:12AM +0100, Sascha Lenz wrote: > The only way is to post some detailed policy suggestions and have some > kind of voting about it, either in public (e.g. usenet-wise) or on > RIPE/RIR level. OK, so now we need to find consensus on how we want to do voting. - does every LIR get one vote (I hear Daniel Roesen yelling)? - does every person on the Internet get one vote? - How do you prevent abuse due to "ok, all employees of $big_carrier vote X" (by coprorate order)? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From tjc at ecs.soton.ac.uk Tue Dec 6 11:51:56 2005 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Tue, 6 Dec 2005 10:51:56 +0000 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <20051206083152.GN69925@Space.Net> References: <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> <20051205170648.GE69925@Space.Net> <43947A3A.CE80737B@networx.ch> <20051206083152.GN69925@Space.Net> Message-ID: <20051206105156.GD20142@login.ecs.soton.ac.uk> On Tue, Dec 06, 2005 at 09:31:53AM +0100, Gert Doering wrote: > > [..] > > Also the current IPv6 policy that only ISPs can get independently routeable > > address space is a fine line into anti-competitive behaviour which may be > > illegal according to EU anti-trust law. > > As nobody is preventing you from becoming an ISP, this line of argument > is completly cr**. That's true. It didn't take much effort, and 'only' maybe 1,500 Euros p.a. for our site to in effect become an LIR. I guess for some people the fee is an issue, but the old argument is if PI is that important to you as a corporate organisation, that money is small change. So who exactly are these people calling for their IPv4 equivalent PI space? Are they all corporate enterprise networks? If not, who represents the other major consumers? And how many PI prefixes are in use today for IPv4? 10,000? 30,000? More? -- Tim/::1 From tjc at ecs.soton.ac.uk Tue Dec 6 11:55:39 2005 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Tue, 6 Dec 2005 10:55:39 +0000 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <003601c5fa40$f23b7140$1d0200c1@RIPENCCRS5> References: <439442BE.2010509@unfix.org> <003601c5fa40$f23b7140$1d0200c1@RIPENCCRS5> Message-ID: <20051206105539.GE20142@login.ecs.soton.ac.uk> On Tue, Dec 06, 2005 at 09:42:09AM +0100, leo vegoda wrote: > > We analysed the requests and questions we have received and presented > the details at RIPE 50. > > http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-ap-ipv6nu > mbers.pdf > > mms://webcast.ripe.net/ripe-50/address-policy-1.wmv > > http://www.ripe.net/ripe/wg/address-policy/r50-minutes.html > (section F) > > Basically, ~2% of requests did not end in address space being > registered. We don't know how many requests are not sent in. Thanks Leo, very interesting. We noted one knockon effect of RIPE policy. I don't know the full details, but essentially for a tunnel broker service we wanted to offer a /48 to end sites out of an existing /32, but were unable to do so because the 'paperwork' to be sent on to RIPE-NCC for each /48 was needed in advance for the ISP owning the /32 to allocate a (say) /40 to the broker service, and that added a notable hurdle. So we ended up using a /48 for the broker and allocating /56 and /64 blocks. Is this the way it's meant to be, or should the ISP owning the /32 only need to report usage when asking for more space itself? -- Tim/::1 From slz at baycix.de Tue Dec 6 12:09:59 2005 From: slz at baycix.de (Sascha Lenz) Date: Tue, 06 Dec 2005 12:09:59 +0100 Subject: [ipv6-wg] Re: Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <20051206104612.GQ69925@Space.Net> References: <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> <20051205170648.GE69925@Space.Net> <20051205172724.GA6858@srv01.cluenet.de> <20051206082759.GM69925@Space.Net> <43956348.4040506@baycix.de> <20051206104612.GQ69925@Space.Net> Message-ID: <43957187.3070108@baycix.de> Hi, Gert Doering wrote: > Hi, > > On Tue, Dec 06, 2005 at 11:09:12AM +0100, Sascha Lenz wrote: >>The only way is to post some detailed policy suggestions and have some >>kind of voting about it, either in public (e.g. usenet-wise) or on >>RIPE/RIR level. > > OK, so now we need to find consensus on how we want to do voting. . o O(...) > - does every LIR get one vote (I hear Daniel Roesen yelling)? > > - does every person on the Internet get one vote? > > - How do you prevent abuse due to "ok, all employees of $big_carrier vote X" > (by coprorate order)? actually, it's a RIR Policy. So it would be quite quite logical to follow the RIR policy process and only let RIR-members ("LIR" or whatever it's called outside RIPE) vote. Don't really know if Daniel would yell on that. But actually that's what i was thinking about (we're exclusively on RIPE WG Mailinglists here anyways). Don't know why i added the "in public" part in first place. No real reason. It would be stupid to think about a "at large" vote on that issue, ICANN failed trying to establish such things :-) -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From ripe-wgs.cs at schiefner.de Tue Dec 6 12:12:32 2005 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Tue, 06 Dec 2005 12:12:32 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <20051206081850.GI69925@Space.Net> References: <97A461F3EE5284469E41ED3728202F4101101005@S4DE9JSAAMW.ost.t-com.de> <43948389.6050309@schiefner.de> <20051206081850.GI69925@Space.Net> Message-ID: <43957220.7070008@schiefner.de> Hi Gert, Gert Doering wrote: >On Mon, Dec 05, 2005 at 07:14:33PM +0100, Carsten Schiefner wrote: >>Also, such a policy is most likely in direct conflict with one of the >>basic paradigms of a RIR - which is equal treatment of its members in >>equal circumstances. > > Circumstances before and after reaching a given number of routes are > not "equal". where _eaxctly!_ sits the difference between LIR #5000 and LIR #5001 - to pick up your example? And why is '5,000' _not!_ totally arbitrary? Although I am mostly agnostic wrt. the general discussion here so far, I am absolutely in line with Andre Oppermann's comment that we better have profound and sound answers to those questions ready before such a policy would be put in place - because they would be asked the second after anyways, most likely by these well-known, interested third parties... Best, Carsten From gert at space.net Tue Dec 6 12:29:42 2005 From: gert at space.net (Gert Doering) Date: Tue, 6 Dec 2005 12:29:42 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <20051206105539.GE20142@login.ecs.soton.ac.uk> References: <439442BE.2010509@unfix.org> <003601c5fa40$f23b7140$1d0200c1@RIPENCCRS5> <20051206105539.GE20142@login.ecs.soton.ac.uk> Message-ID: <20051206112942.GX69925@Space.Net> Hi, On Tue, Dec 06, 2005 at 10:55:39AM +0000, Tim Chown wrote: > a /48 for the broker and allocating /56 and /64 blocks. Is this the > way it's meant to be, or should the ISP owning the /32 only need to > report usage when asking for more space itself? Well, it depends. If you want to "ASSIGN" a /40 to the tunnel broker, it falls into the category "assignment of networks larger than a /48 to the end user", and that's paperwork. The way it was meant to be done is doing a sub-allocation (which never goes to "end-users", unlike an assignment), and IPv6 sub-allocations, as far as I understand the policy, don't need to be approved by the NCC beforehand. Of course, when you sub-allocate all of your space away, and the receipients don't use it, you won't be able to get more space for you - so use with care. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From dogwallah at gmail.com Tue Dec 6 12:32:01 2005 From: dogwallah at gmail.com (McTim) Date: Tue, 6 Dec 2005 14:32:01 +0300 Subject: [ipv6-wg] Re: Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <43957187.3070108@baycix.de> References: <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> <20051205170648.GE69925@Space.Net> <20051205172724.GA6858@srv01.cluenet.de> <20051206082759.GM69925@Space.Net> <43956348.4040506@baycix.de> <20051206104612.GQ69925@Space.Net> <43957187.3070108@baycix.de> Message-ID: Hi Sascha, On 12/6/05, Sascha Lenz wrote: > actually, it's a RIR Policy. So it would be quite quite logical to > follow the RIR policy process and only let RIR-members ("LIR" or > whatever it's called outside RIPE) vote. LIRs in the RIPE region vote only on RIPE NCC activities/budget/association stuff. The Policy Development Process is open to all. This is true in other regions as well. But actually that's what i was thinking about (we're exclusively on RIPE > WG Mailinglists here anyways). I am not an LIR, and I can play in this sandbox! BTW, I live in Africa now, (that's why you don't see me @ meetings anymore), but I can still participate on the lists. -- Cheers, McTim $ whois -h whois.afrinic.net mctim -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Tue Dec 6 12:39:50 2005 From: gert at space.net (Gert Doering) Date: Tue, 6 Dec 2005 12:39:50 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <43957220.7070008@schiefner.de> References: <97A461F3EE5284469E41ED3728202F4101101005@S4DE9JSAAMW.ost.t-com.de> <43948389.6050309@schiefner.de> <20051206081850.GI69925@Space.Net> <43957220.7070008@schiefner.de> Message-ID: <20051206113950.GY69925@Space.Net> Hi, On Tue, Dec 06, 2005 at 12:12:32PM +0100, Carsten Schiefner wrote: > Gert Doering wrote: > >On Mon, Dec 05, 2005 at 07:14:33PM +0100, Carsten Schiefner wrote: > >>Also, such a policy is most likely in direct conflict with one of the > >>basic paradigms of a RIR - which is equal treatment of its members in > >>equal circumstances. > > > >Circumstances before and after reaching a given number of routes are > >not "equal". > > where _eaxctly!_ sits the difference between LIR #5000 and LIR #5001 - > to pick up your example? It's like growing up, and being 18 years old, over night. Nothing but a small number change, but lots of effect. > And why is '5,000' _not!_ totally arbitrary? I didn't say that it's not completely arbitrary. It's a limit that is loosely in the same range as the current number of LIRs per RIR, and well below the limits that will cause problems for currently deployed router architectures. I don't seriously see us reaching this number anyway in the near future - but I've put it there in case that I'm wrong, and those people that are afraid of a massive land rush are right. > Although I am mostly agnostic wrt. the general discussion here so far, I > am absolutely in line with Andre Oppermann's comment that we better have > profound and sound answers to those questions ready before such a policy > would be put in place - because they would be asked the second after > anyways, most likely by these well-known, interested third parties... I'm open for any proposal that will fulfill all the necessary criteria (in no specific order, and I'm sure I forgot one or two): - fair - not-ITU-problematic - not-monopoly-problematic - not using up BGP routing table slots - giving anybody maximum independence from anything else in the Internet - not wasting address space - giving anybody maximum address space so that they can be maximum convenient (internal hierarchy and allocation, etc.) - having a one-size-fits-all model for end users, to discourage bureaucracy - giving machines on a link the benefit of autoconfiguration - not wasting a /64 on links, and /48s on users as you can easily see, there is no way any policy can fulfill all of this at the same time. So the only thing that can ever reach consensus is a foul compromise (or a miracle from the IETF). "Foul compromise" = "nobody is happy with it, but everybody can *live* with it". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From gert at space.net Tue Dec 6 12:42:46 2005 From: gert at space.net (Gert Doering) Date: Tue, 6 Dec 2005 12:42:46 +0100 Subject: [ipv6-wg] Re: Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <43957187.3070108@baycix.de> References: <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> <20051205170648.GE69925@Space.Net> <20051205172724.GA6858@srv01.cluenet.de> <20051206082759.GM69925@Space.Net> <43956348.4040506@baycix.de> <20051206104612.GQ69925@Space.Net> <43957187.3070108@baycix.de> Message-ID: <20051206114246.GZ69925@Space.Net> Hi, On Tue, Dec 06, 2005 at 12:09:59PM +0100, Sascha Lenz wrote: > > - does every LIR get one vote (I hear Daniel Roesen yelling)? > > > > - does every person on the Internet get one vote? > > > > - How do you prevent abuse due to "ok, all employees of $big_carrier vote X" > > (by coprorate order)? > > actually, it's a RIR Policy. So it would be quite quite logical to > follow the RIR policy process and only let RIR-members ("LIR" or > whatever it's called outside RIPE) vote. > > Don't really know if Daniel would yell on that. Sure, because it's "the ISP monopoly deciding things that hurt all the poor end users". Also, in the RIPE land, it has *never* been the way that "only LIRs decide" - to the contrary, all RIPE processes are open to anyone to come to meetings (or subscribe to mailing lists) and enter discussions. > But actually that's what i was thinking about (we're exclusively on RIPE > WG Mailinglists here anyways). > Don't know why i added the "in public" part in first place. No real > reason. It would be stupid to think about a "at large" vote on that > issue, ICANN failed trying to establish such things :-) Doing it in a non-open way would directly play into ITUs hands. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From iljitsch at muada.com Tue Dec 6 14:55:47 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 6 Dec 2005 14:55:47 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: <437DBBED.1080605@baycix.de> References: <200511171715.05767.marc.van.selm@nc3a.nato.int> <20051117233137.GA24229@srv01.cluenet.de> <437DBBED.1080605@baycix.de> Message-ID: <95A9DFC3-FF5A-407C-AC24-C67B76EE6BB0@muada.com> My apologies for replying to such an old message, but I couldn't let this one go. On 18-nov-2005, at 12:33, Sascha Lenz wrote: > In particular, noone came up with an equal solution to BGP Multihoming > with "PI"-space, which i hoped for back then. Well, you haven't been paying attention, because I've presented "provider-internal aggregation based on geography" at two different RIPE meetings a while ago. The only thing I got was perplexed stares. You really can't expect to keep doing the same thing we've been doing in IPv4 in IPv6 but now with different results (= more reasonable routing tables). Iljitsch -- I've written another book! http://www.runningipv6.net/ From fw at deneb.enyo.de Tue Dec 6 14:58:50 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Tue, 06 Dec 2005 14:58:50 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <20051201200556.GT44731@new.detebe.org> (Elmar K. Bins's message of "Thu, 1 Dec 2005 21:05:57 +0100") References: <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <20051130162129.GB12947@srv01.cluenet.de> <438F0F6F.5050409@oslo.net> <87mzjkkc8g.fsf@mid.deneb.enyo.de> <438F331D.3060208@unfix.org> <20051201200556.GT44731@new.detebe.org> Message-ID: <877jaiqqcl.fsf@mid.deneb.enyo.de> * Elmar K. Bins: > That's the independently-networking end-user problem we have. PI would > solve that. Removal of the 200 customer rule would solve that. One-block- > per-LIR would solve that. Doesn't need DENIC two blocks, one for their production network, and one for anycast? Or would you be willing to subject yourself to an ISP for the production network? Why not for anycast service? From dr at cluenet.de Tue Dec 6 15:36:57 2005 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 6 Dec 2005 15:36:57 +0100 Subject: [ipv6-wg] Re: Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <43947A3A.CE80737B@networx.ch> References: <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> <20051205170648.GE69925@Space.Net> <43947A3A.CE80737B@networx.ch> Message-ID: <20051206143657.GA17054@srv01.cluenet.de> On Mon, Dec 05, 2005 at 06:34:50PM +0100, Andre Oppermann wrote: > Also the current IPv6 policy that only ISPs can get independently routeable > address space is a fine line into anti-competitive behaviour which may be > illegal according to EU anti-trust law. Not only that, the billing scheme too. Every year it becomes more expensive to receive resources. See the time factor in the score algo. Given that this scheme is not a community-based decision, but a membership decision, this may (or may not, IANAL) subject to anti-trust laws as well. I think that RIPE needs a means to poll for votes in the RIPE region in an open manner, and base policy decisions on the outcome of those, not on the opinions of a few vocal folks who have the time and money to invest in mailing lists and RIPE meetings to bring forward their agenda, with someone then concluding "rough consensus" (or not). At least on a membership level that should be easy to achieve. Mail policy proposals to LIR contacts and ask to vote. Without having to read hundreds of mailing list postings and voicing opinions there. Of course the current policy discussion does affect members (LIRs) the least - they do already have their addresses (most of them), so asking only the membership to vote would be again the wrong thing to do. Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From slz at baycix.de Tue Dec 6 15:59:44 2005 From: slz at baycix.de (Sascha Lenz) Date: Tue, 06 Dec 2005 15:59:44 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: <95A9DFC3-FF5A-407C-AC24-C67B76EE6BB0@muada.com> References: <200511171715.05767.marc.van.selm@nc3a.nato.int> <20051117233137.GA24229@srv01.cluenet.de> <437DBBED.1080605@baycix.de> <95A9DFC3-FF5A-407C-AC24-C67B76EE6BB0@muada.com> Message-ID: <4395A760.6070608@baycix.de> Hi, Iljitsch van Beijnum wrote: > My apologies for replying to such an old message, but I couldn't let > this one go. > > On 18-nov-2005, at 12:33, Sascha Lenz wrote: > >> In particular, noone came up with an equal solution to BGP Multihoming >> with "PI"-space, which i hoped for back then. > > Well, you haven't been paying attention, because I've presented > "provider-internal aggregation based on geography" at two different > RIPE meetings a while ago. Actually, i did pay attention, but why do you think i consider that as an equal solution to BGP Multihoming with "PI"-space? It's _ONE_ alternative solution one might suggest, but still no reason for disallowing anyone in the globally distributed prefix table. Why do i want this at all? Because there are globally distributed prefixes right now, there is no geographically based assigment in sight anywhere and yes your presentation was a while ago. IIRC even your presentation said that this would require geographically based assigments "right now". Right? Do you expect everyone with a prefix today to give it back and renumber? "Too late" at least for a full solution. This is just another suggestion that might be helpful for preventing some amount of global prefixes (see below), but not god's own solution to the problem. > The only thing I got was perplexed stares. > > You really can't expect to keep doing the same thing we've been doing > in IPv4 in IPv6 but now with different results (= more reasonable > routing tables). *think* Of course... as mentioned before by many people, IPv6 implicitly solves some of the problems with "too many routes". Again, this leads to: - "usually" only one Prefix per AS even with nowerdays IPv6 policy ==> "more reasonable routing table" per default because almost noone needs a second Prefix - no impact on the IPv4 Routing Table size which you have to carry around for decades anyways. ==> no relief for any router in sight, regardless of the the IPv6 policy - There _ARE_ multihoming solutions besides world-wide prefix announcements, there are many. You can suggest all of them to your customers when they ask for "redundancy" or so. You even could be required by policy to tell your customers about the solutions as i suggested during the current thread. BUT - if someone insists on BGP Multihoming with worldwide prefix distribution for whatever reason he/she might have, noone must be forbidden to do so! ==> Even less End-site-customers who want an AS and PI-Prefixes because some actually _ARE_ OK with alternative. Noone denies the fact that there are most likely too many prefixes and probably even too many ASes in todays IPv4 Internet Routing Table. It's also a fact that many of them are not really needed, and the desired redundancy could be achieved by other means. Some customers might even be happy if they don't need to care for BGP Speaking Routers or so in their network and are pleased if you suggest a different solution. The main problem is just people who want to tell "me" (not literally) what's best for "my" network, and disallow "me" in the pond with the big fish. ..and there are absolutely no technical reasons which would forbid "me" in this pond if i want to swim there. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From fw at deneb.enyo.de Tue Dec 6 16:18:02 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Tue, 06 Dec 2005 16:18:02 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <20051206151046.GF33656@new.detebe.org> (Elmar K. Bins's message of "Tue, 6 Dec 2005 16:10:47 +0100") References: <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <20051130162129.GB12947@srv01.cluenet.de> <438F0F6F.5050409@oslo.net> <87mzjkkc8g.fsf@mid.deneb.enyo.de> <438F331D.3060208@unfix.org> <20051201200556.GT44731@new.detebe.org> <877jaiqqcl.fsf@mid.deneb.enyo.de> <20051206151046.GF33656@new.detebe.org> Message-ID: <8764q2p845.fsf@mid.deneb.enyo.de> * Elmar K. Bins: > fw at deneb.enyo.de (Florian Weimer) wrote: > >> > That's the independently-networking end-user problem we have. PI would >> > solve that. Removal of the 200 customer rule would solve that. One-block- >> > per-LIR would solve that. >> >> Doesn't need DENIC two blocks, one for their production network, and >> one for anycast? Or would you be willing to subject yourself to an >> ISP for the production network? Why not for anycast service? > > How come, it's always you who knows what other people need? This was a real question, not a rhetorical one. I was genuinely wondering whether "one-block-per-LIR" would be enough. Not everything I wrote is intended to be provocative. 8-) From elmi at 4ever.de Tue Dec 6 16:10:47 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Tue, 6 Dec 2005 16:10:47 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <877jaiqqcl.fsf@mid.deneb.enyo.de> References: <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <20051130162129.GB12947@srv01.cluenet.de> <438F0F6F.5050409@oslo.net> <87mzjkkc8g.fsf@mid.deneb.enyo.de> <438F331D.3060208@unfix.org> <20051201200556.GT44731@new.detebe.org> <877jaiqqcl.fsf@mid.deneb.enyo.de> Message-ID: <20051206151046.GF33656@new.detebe.org> fw at deneb.enyo.de (Florian Weimer) wrote: > > That's the independently-networking end-user problem we have. PI would > > solve that. Removal of the 200 customer rule would solve that. One-block- > > per-LIR would solve that. > > Doesn't need DENIC two blocks, one for their production network, and > one for anycast? Or would you be willing to subject yourself to an > ISP for the production network? Why not for anycast service? How come, it's always you who knows what other people need? Of course we are happy enough to connect our office to a potent ISP on a PA block, no hassle. If they let us advertise the assignment on some peering matrix and the partners take it, the better; but that's not really necessary for an office. Apart from that, we're working on solutions, both for registry services production and for the DNS problem, and I am sure we will find them. Elmar. From elmi at 4ever.de Tue Dec 6 16:21:26 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Tue, 6 Dec 2005 16:21:26 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <8764q2p845.fsf@mid.deneb.enyo.de> References: <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <20051130162129.GB12947@srv01.cluenet.de> <438F0F6F.5050409@oslo.net> <87mzjkkc8g.fsf@mid.deneb.enyo.de> <438F331D.3060208@unfix.org> <20051201200556.GT44731@new.detebe.org> <877jaiqqcl.fsf@mid.deneb.enyo.de> <20051206151046.GF33656@new.detebe.org> <8764q2p845.fsf@mid.deneb.enyo.de> Message-ID: <20051206152126.GG33656@new.detebe.org> fw at deneb.enyo.de (Florian Weimer) wrote: > >> Doesn't need DENIC two blocks, one for their production network, and > >> one for anycast? Or would you be willing to subject yourself to an > >> ISP for the production network? Why not for anycast service? > > > > How come, it's always you who knows what other people need? > > This was a real question, not a rhetorical one. I was genuinely > wondering whether "one-block-per-LIR" would be enough. Not everything > I wrote is intended to be provocative. 8-) Ok, then that's a misunderstanding (my memory has more than a week backlog or so). Actually, it's like I wrote - we're working on something. Not sure how to do it, though. Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, ) --------------------------------------------------------------[ ELMI-RIPE ]--- From iljitsch at muada.com Tue Dec 6 16:30:25 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 6 Dec 2005 16:30:25 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: <4395A760.6070608@baycix.de> References: <200511171715.05767.marc.van.selm@nc3a.nato.int> <20051117233137.GA24229@srv01.cluenet.de> <437DBBED.1080605@baycix.de> <95A9DFC3-FF5A-407C-AC24-C67B76EE6BB0@muada.com> <4395A760.6070608@baycix.de> Message-ID: <0DEF8DA7-3400-43C2-A921-043B2A98A1B8@muada.com> On 6-dec-2005, at 15:59, Sascha Lenz wrote: >>> In particular, noone came up with an equal solution to BGP >>> Multihoming >>> with "PI"-space, which i hoped for back then. >> Well, you haven't been paying attention, because I've presented >> "provider-internal aggregation based on geography" at two different >> RIPE meetings a while ago. > Actually, i did pay attention, but why do you think i consider that as > an equal solution to BGP Multihoming with "PI"-space? I don't understand what you're trying to say... But I'm happy that someone noticed what I was trying to say back then. > It's _ONE_ alternative solution one might suggest, but still no reason > for disallowing anyone in the globally distributed prefix table. To me, it's pretty obvious that if we can have aggregatable PI space, then that's an excellent reason to NOT have non-aggregatable PI space. Note however that the aggregation is optional in my plan: everyone can implement it in their own network independent of what everyone else does. In the beginning, there certainly won't be any reason to aggregate so this type of PI is completely equivalent to regular PI. > Why do i want this at all? Well, I don't know. I can get by with my PA /48 just fine. But apparently some people like to multihome and some of them insist that shim6 doesn't address their needs. And others want a portable prefix for other reasons. > Because there are globally distributed > prefixes right now, there is no geographically based assigment in > sight > anywhere So? If we really want this we can start doing this in a manner of weeks: the only requirement is that the RIRs start giving out prefixes that are aggregatable. In practice, it will take about the same amount of time as any other policy change. > Do you expect everyone with a prefix today to give it back and > renumber? Today, there is no PI in IPv6 so that's a moot question. > BUT - if someone insists on BGP Multihoming with worldwide prefix > distribution for whatever reason he/she might have, noone must be > forbidden to do so! I'd rather have a working internet without PI than a non-working one with it. Nobody can guarantuee that we won't run into trouble with PI so the only way we can be sure we won't have this trouble is to not have PI. If you want PI as it exists today in IPv4, the burden is on you to show, yes, SHOW that it can scale for decades to come. > The main problem is just people who want to tell "me" (not literally) > what's best for "my" network, and disallow "me" in the pond with > the big > fish. Do whatever you want, as long as you don't do it in my routing table. The internet only works as long as 99% of all people carry 99% of all routes. When a sizeable number of people starts filtering a sizeable number of routes for whatever reason, either technical (won't fit in their routers) or political (don't agree with the policies) then we're in knee-deep brown stuff. -- I've written another book! http://www.runningipv6.net/ From peter.sherbin at bell.ca Tue Dec 6 17:08:47 2005 From: peter.sherbin at bell.ca (peter.sherbin at bell.ca) Date: Tue, 6 Dec 2005 11:08:47 -0500 Subject: [ipv6-wg] a consensus, about what? Message-ID: >Date: Tue, 6 Dec 2005 09:43:56 +0100 (CET) >From >To: Gert Doering > cc: address-policy-wg at ripe.net, ipv6-wg at ripe.net > Subject: [ipv6-wg] a consensus, about what? >so what sort of consensus are we aiming for...? A new policy >for AS, a net block, routing policy, multihoming, or just IPv6 in general? >...quite a lot of topics have been discussed ... but what are our goal with all this? Get rid of the current hierarchy which requires ISP in order to connect to the network. The Internet is an aggregation of interconnected networks. We want to replicate what the Mother Nature has already given us, i.e. a brain like structure where neurons (individual networks) have multiple direct connections with each other. As brain cells networks should have about the same size. Network prefix determines the size. Peter Sherbin Bell Canada From iljitsch at muada.com Tue Dec 6 18:08:40 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 6 Dec 2005 18:08:40 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: <200512061635.jB6GZshq028157@alpha.bartels.de> References: <200512061635.jB6GZshq028157@alpha.bartels.de> Message-ID: <69C9413F-A032-491D-8B50-3396284E7A32@muada.com> On 6-dec-2005, at 17:36, Oliver Bartels wrote: >> To me, it's pretty obvious that if we can have aggregatable PI space, >> then that's an excellent reason to NOT have non-aggregatable PI >> space. > You may aggregatable PI space if you can convince the router > manufacturers create and implement a new RFC which adds an > additional layer for prefix aggregation within the BGP protocol. I can't imagine what such a layer would look like... > Geographical aggregation however, is _for_sure_ not the > solution for the new centrury. Geographical solutions happened > in the last century. In IP? Don't think so. If you have pointers, please enlighten me. > Nowadays carriers use DWDM technology, and yes, a link > between Frankfurt and London or even New York is cheaper and > easier to obtain than a link between Frankfurt and Wiesbaden. Sure. But trying to aggregate on network topology is never going to work for two very simple reasons: 1. It changes all the time 2. You can't express a topology with loops in it in an addressing hierarchy The reason to choose geography to aggregate on is not because it is somehow magically always the best fit with topology, because it isn't. However, it has two very important things going for it: it's not subject to change, and it allows for optimization on distance, which in turn has the potential to be be good for cost and performance. Please don't assume you understand my proposal just because it contains the term "geography". If you want to know what it entails have a look at http://www.muada.com/drafts/draft-van-beijnum-multi6- isp-int-aggr-01.txt > The key issue is whether competing dark fiber or leased line > carriers are available at a certain location and _not_ the distance > between those. Distance is actually very important. It's very hard to do decent high speed file transfer on out of the box OSes and applications with high delay. Also, it often makes sense to backhaul traffic over SOME distance, but that doesn't mean it also makes sense to backhaul it over even larger distances. I.e., even if a link to New York is cheap, you don't want to go over Palo Alto. > As routing was not really considered by the designers of the > IPv6 protocol (yes, this _is_ an fault, IPv6 can be considered > a lousy solution under this view), we can either live with it > or give it up. Living with it means providing a solution for > the PI requesting organisations and waiting for an aggregation > enhancement of the routing protocols or keep it experimental, > which probably means: Let it die. Your conclusions don't follow from your assumptions. Yes, IPv6 doesn't do anything for routing except allow very large aggregates. However, the choice isn't between allowing unlimited growth and hoping we can fix it later and not using IPv6, the choice is between: - Not allowing PI - Coming up with aggregatable PI of some kind - Give up and make the exact same mess of IPv6 as we did with IPv4 Today, IPv4 routing works but it has come close to the edge of the cliff twice (early 1990s just before CIDR routing tables were too large and late 1990s flapping cost too much CPU) and it's still pushing towards that edge, which we can't see clearly but know is out there somewhere. And that happened in 25 years. We'll very likely have to live with IPv6 for much longer than that, so we HAVE to be careful from the outset. Shim6 is coming, aggregation with PI is unexplored, IPv6 is still in the extremely early stages, so this is NOT the time to do stupid things. If we're still in the same boat in 5 years when we're down to 18 months of IPv4 addresses, sure, we can revisit this issue. But we still have some time. Let's use it. > Even if the PI question is solved these days, I won't be sure > if the answer isn't already too late. The market will tell us. What kind of logic makes this too late? >> I'd rather have a working internet without PI than a non-working one >> with it. Nobody can guarantuee that we won't run into trouble with PI >> so the only way we can be sure we won't have this trouble is to not >> have PI. > This argument is unreal, you can stop _any_ project with it, > in Germany we call it "Vollkaskomentatlitaet" and our country > suffers a lot from it. Well, then apply some of that mentality to PI in IPv6 and free it up elsewhere. :-) > There is simply no way to prove that a given solution won't > have a side effect. So because you can't prove that you're right I should just believe you without proof? > If you write: "Nobody can guarantee ..." then I will tell you: > Nobody can _guarantee_ that your posting by its formating or > content can't cause a significant harm to an important server, > cause a worldwide crash of the internet, thus impairs water and > electricity supply and at the end let the aliens conquer earth. No, but there's no reasonable scenario that makes this happen either. The scenario that de facto unlimited PI in IPv6 will make routing tables so large that it becomes problematic in some way or another is entirely reasonable, on the other hand. > More realistic: > I'd rather like a internet with IPv6 and PI and the very low > probability > of of trouble which can with a high probably be fixed than no real- > in-use > IPv6 because of arguments which request gurantees that can't be > given for _any_ solution on this planet. Yes, I've heard it all before. Why don't we work on something that we can all get behind? The beauty of my geographical aggregation thing is that you still get PI even if it turns out that it doesn't work. So you get what you want regardless of who's right. Pretty good deal, don't you think? > Up to now engineers have always proven to find solutions > for networking problems like the PI issue, thus there will > be some solution for sure if required. Sure, we can always implement some kind of aggregation later. This of course requires renumbering of all PI space. And isn't the idea behind PI space that you never have to renumber out of it...? > P.s. @RIPE NCC: Question: Is there a practical way to replace the > slow and cumbersome "consensus" principle of the RIPE by a democratic > majority vote of the RIPE NCC members to stop further damage to IPv6, > perhaps with a decision at the next RIPE NCC general meeting ? Please replace "RIPE NCC members" with "people who have to pay for bigger routers world wide" (not just the RIPE region) and I'm all for it. Iljitsch -- I've written another book! http://www.runningipv6.net/ From david.kessens at nokia.com Tue Dec 6 19:32:49 2005 From: david.kessens at nokia.com (David Kessens) Date: Tue, 6 Dec 2005 10:32:49 -0800 Subject: [ipv6-wg] Crossposting to address policy and ipv6 working group mail lists In-Reply-To: <20051206085604.GO69925@Space.Net> References: <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> <1133433440.15956.248746502@webmail.messagingengine.com> <438ED422.9090904@netegral.co.uk> <94A27B10-F8AF-4704-82CE-024205DA32AE@kurtis.pp.se> <20051205170648.GE69925@Space.Net> <20051205172724.GA6858@srv01.cluenet.de> <20051206082759.GM69925@Space.Net> <20051206085604.GO69925@Space.Net> Message-ID: <20051206183249.GC27914@nokia.com> I am seeing a lot of crosspostings on the ipv6 wg and address policy wg list. Before replying to a message, please consider who your intended audience is: is interested in technical topics related to the deplyment of ipv6 is concerned about the policies related to ip allocations and assignments in the RIPE region Please remove a working group list from the CC list if your message is not on topic for that particular working group. Thanks, David Kessens Chairperson ipv6 working group --- From gert at space.net Tue Dec 6 20:42:57 2005 From: gert at space.net (Gert Doering) Date: Tue, 6 Dec 2005 20:42:57 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <877jaiqqcl.fsf@mid.deneb.enyo.de> References: <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <20051130162129.GB12947@srv01.cluenet.de> <438F0F6F.5050409@oslo.net> <87mzjkkc8g.fsf@mid.deneb.enyo.de> <438F331D.3060208@unfix.org> <20051201200556.GT44731@new.detebe.org> <877jaiqqcl.fsf@mid.deneb.enyo.de> Message-ID: <20051206194257.GD69925@Space.Net> Hi, On Tue, Dec 06, 2005 at 02:58:50PM +0100, Florian Weimer wrote: > > That's the independently-networking end-user problem we have. PI would > > solve that. Removal of the 200 customer rule would solve that. One-block- > > per-LIR would solve that. > > Doesn't need DENIC two blocks, one for their production network, and > one for anycast? Or would you be willing to subject yourself to an > ISP for the production network? That's what DENIC is doing right now, doing BGP-multihoming with a /48 from their upstream ISP. (Which is certainly something people *do* disagree upon - but as they seem to be happy with their ISPs reliability, it will still work even if someone filters out the /48). > Why not for anycast service? It could certainly be done, but as there are going to be *many* instances, distributed all over the place, it would be a lot less hassle to have a network from a well-known block that people would know "hey, permit this through our filters, it's a TLD anycast network". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From gert at space.net Tue Dec 6 20:53:36 2005 From: gert at space.net (Gert Doering) Date: Tue, 6 Dec 2005 20:53:36 +0100 Subject: [ipv6-wg] a consensus, about what? In-Reply-To: References: Message-ID: <20051206195336.GF69925@Space.Net> Hi, On Tue, Dec 06, 2005 at 11:08:47AM -0500, peter.sherbin at bell.ca wrote: > Get rid of the current hierarchy which requires ISP in order to > connect to the network. The Internet is an aggregation of interconnected > networks. We want to replicate what the Mother Nature has already > given us, i.e. a brain like structure where neurons (individual > networks) have multiple direct connections with each other. As brain > cells networks should have about the same size. Network prefix > determines the size. Ah, back to the source-route-bridged times of (ring-) explorer packets... Sounds like a nice idea, would even be much more resilient than the current structure. Any IETF proposals where we can read up on how this is gonna work? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From iljitsch at muada.com Tue Dec 6 21:42:57 2005 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 6 Dec 2005 21:42:57 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: <200512061909.jB6J9chq022181@alpha.bartels.de> References: <200512061909.jB6J9chq022181@alpha.bartels.de> Message-ID: <4D7F8529-5BBA-4C70-8025-A589AF42EAD9@muada.com> On 6-dec-2005, at 20:10, Oliver Bartels wrote: >> I can't imagine what such a layer would look like... > Clustering all PI-prefixes originating at the same AS to form > a single "super-prefix" makes policy processing a lot easier, > because it need to be done just once for the whole block. I'm not sure I understand the "superprefix" but obviously a lot of work that now happens per-prefix in BGP should happen per-AS. But that's mostly moot in IPv6 as we should never reach the numbers of prefixes per AS that we see in IPv4. > With as few as 256MByte of DDRAM plus a 64K TCAM chip it is > possible to handle max. 8 Million Forwarding entries at full 128 bit > resolution I guess that means you throw everything in the TCAM first to get from 8M to about 125 entries and then look those up in a tree or hash table? Obviously it's possible to build architectures that allow fast forwarding with big tables. However, this doesn't come free: it takes more iron to do this, and also more power. TCAMs suck down the juice like a depressed alcoholic. This is bad for your design (both the box itself and the datacenter), your wallet and the environment. > I personally just received a patent on such router hardware concept. So big routing tables are good business for you, then? >> Sure. But trying to aggregate on network topology is never going to >> work for two very simple reasons: >> 1. It changes all the time > The same is true for geographical aggregation. I guess I you live in California or another place that is plagued by frequent earthquakes... > Geographical aggregation would require free transit, otherwise > it is not compatible with the ISP's business models. The point is to keep the aggregation inside the ISP network. Tier-1 ISPs would still have a full routing table, but rather than have a copy in each router, it's distributed over the network. So there is no free transit requirement. > country boundaries. > Such boundaries are artifical, the EU tries to avoid them. The idea behind aggregation is that you can move up or down. If country borders get in the way, drill down a bit and start looking at provinces or cities. In our design there are potentially 64k distinct areas (mostly cities) so if you want, you can have a route for each of those in your routing table and never run into country borders. >> 2. You can't express a topology with loops in it in an addressing >> hierarchy > Avoiding loops is the job of the routing protocol, not the > topology. ??? Are we talking about spanning tree now? Loops in the topology are good. You can't remove them. Routing is also dynamic, BTW. >> Distance is actually very important. It's very hard to do decent high >> speed file transfer on out of the box OSes and applications with high >> delay. Also, it often makes sense to backhaul traffic over SOME >> distance, but that doesn't mean it also makes sense to backhaul it >> over even larger distances. I.e., even if a link to New York is >> cheap, you don't want to go over Palo Alto. > If I would be located in Seattle, Palo Alto might be an alternative > way point as well as Chicago or even Dallas. Of course. But we're in Europe. If you're in Seattle you'll see a lot of your traffic to other people in Seattle flow through Palo Alto. That's normal, because it's not economical to peer with everyone everywhere. It's not so cool when intra-Seattle traffic starts to flow through Miami. > What you are trying is: > Map a two-and-a-half-dimensional world on a one-dimensional > address range. This won't work by Math. > Dimensions can only be replaced by dimensions. Ah, but we're not mathematicians but engineers. In software, you have one dimensional memory. Still, you can have multidimensional arrays. > Asked a database programmer how difficult it is to implement > a geographical 10km around some place search on a database > and ask them about the algorithms in use. Easy: select everything that's in a 20x20 km grid around the center point and then do the real distance calculation on everything in that grid. Obviously you'll select stuff that's at x+8 y+8 = ~12km from the center but that's only true for a relatively small part of the intermediate results. > What they try is interleaving the West-East (X) and North-South (Y) > coordinates bitwise in the search key and handle overruns by > exceptions, That sounds like Tony Hain's geographical addressing. The variant Michel Py and myself came up with is based on administrative borders such as countries so you already have on dimension: the alphabet. (Ok, not entirely how it works, but still.) > However this requires a _significant_ exception handling effort, > nothing someone would like to implement in a fast forwarding > engine for packet routing. Geography is long gone by the time we're forwarding packets. >> Today, IPv4 routing works but it has come close to the edge of the >> cliff twice (early 1990s just before CIDR routing tables were too >> large and late 1990s flapping cost too much CPU) and it's still >> pushing towards that edge, which we can't see clearly but know is out >> there somewhere. > It works. Period. Hm, if you only descern "works" / "doesn't work" it's hard to say anything about the routing system... Some quantitative and qualitative analysis can be helpful. > And it will continue to work, because of the > economic pressure. Engineers have found a solution, thus: > Don't worry. Guess what. I'm an engineer. I'm working on this stuff. And I'm saying: when de facto unlimited PI is allowed, it may not mean the end of the internet, but it's certainly reason to worry. Of course things will continue to work. However, they'll be less reliable and more expensive. >> So because you can't prove that you're right I should just believe >> you without proof? > Yes, because the theory of computer sience gives you the > prrof that there are theorems in this world which can't be proven. There are also many theorems that turn out to be false. Proof is a pretty good method to avoid those. If we can't have proof we'll need to have less reliable methods to avoid them. Just accept anything is not the solution. >> The scenario that de facto unlimited PI in IPv6 will make routing >> tables so large that it becomes problematic in some way or another is >> entirely reasonable, on the other hand. > The current experience let us make a reasonable and responsible > assumption that a IPv6 routing table would take not much more > growth than the current IPv4 table, whereas current technology > permits tables of 10 to 100 times that size. Today, people sometimes deaggregate a /16. That's bad: 255 unnecessary routes. What if they do the same thing with a /32 in IPv6? 65535 unnecessary routes. That will probably kill most existing IPv6 routers today. 10 times is 1.75M routes, 100 = 17.5. The former is probably doable for IPv4 on some extremely high end boxes but I'm not sure how those would handle real issues such as flapping, lots of full feeds etc. I don't believe the latter exists or will exist in the forseeable future, at least not in a way that anyone can afford to actually use. Even those 1.75M boxes will be very expensive and only affordable by the largest networks. Don't forget you and I all pay for their hardware, directly or indirectly. Iljitsch -- I've written another book! http://www.runningipv6.net/ From thuthuy at vnnic.net.vn Wed Dec 7 05:30:06 2005 From: thuthuy at vnnic.net.vn (Thu Thuy) Date: Wed, 7 Dec 2005 11:30:06 +0700 Subject: [ipv6-wg] IPv6 database service Message-ID: <035301c5fae6$e69d7cb0$100977cb@NGUYENTHUTHUY> Hi, all folk I would like to ask for your advise in IPv6 - support in database service. I don't know what kind of database now support IPv6. Could you pls advise me your knowleadge related to this matter. For IPv6 web service which require database, i don't know how is database service deployed. Do they used IPv6-supported database or they still use IPv4 database and the web server is dual-stack (IPv6 to handle user request and IPv4 to connect to database server). Thanks much for your help. Thu Thuy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From oliver at bartels.de Tue Dec 6 17:36:19 2005 From: oliver at bartels.de (Oliver Bartels) Date: Tue, 06 Dec 2005 17:36:19 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: <0DEF8DA7-3400-43C2-A921-043B2A98A1B8@muada.com> Message-ID: <200512061635.jB6GZshq028157@alpha.bartels.de> On Tue, 6 Dec 2005 16:30:25 +0100, Iljitsch van Beijnum wrote: >On 6-dec-2005, at 15:59, Sascha Lenz wrote: [...] >>> Well, you haven't been paying attention, because I've presented >>> "provider-internal aggregation based on geography" at two different >>> RIPE meetings a while ago. >> It's _ONE_ alternative solution one might suggest, but still no reason >> for disallowing anyone in the globally distributed prefix table. Ack. >To me, it's pretty obvious that if we can have aggregatable PI space, >then that's an excellent reason to NOT have non-aggregatable PI space. You may aggregatable PI space if you can convince the router manufacturers create and implement a new RFC which adds an additional layer for prefix aggregation within the BGP protocol. Geographical aggregation however, is _for_sure_ not the solution for the new centrury. Geographical solutions happened in the last century. Nowadays carriers use DWDM technology, and yes, a link between Frankfurt and London or even New York is cheaper and easier to obtain than a link between Frankfurt and Wiesbaden. The key issue is whether competing dark fiber or leased line carriers are available at a certain location and _not_ the distance between those. >Well, I don't know. I can get by with my PA /48 just fine. But >apparently some people like to multihome and some of them insist that >shim6 doesn't address their needs. And others want a portable prefix >for other reasons. Yes, and as these people make a significant part out of the IPv4 internet world, as ISP's we can either support their requirement or keep IPv6 experimental. Period. >So? If we really want this we can start doing this in a manner of >weeks: the only requirement is that the RIRs start giving out >prefixes that are aggregatable. In practice, it will take about the >same amount of time as any other policy change. The key issues is: What today might look like an aggregate, won't be one tomorrow. Today A might be related to B and C to D, thus (AB) or (CD) might sound like good aggregates, tommorow A is related to C and B to D. Math limits the aggregation possibilities for ABCD. In this case, a bit mask could help: (A=x00y, B=x01y, C=x10y, D=x11y, thus first case mask 10, second 01) but it is obviously not possible to find an aggregation solution for any possible combination (e.g. ABC vs. D). As routing was not really considered by the designers of the IPv6 protocol (yes, this _is_ an fault, IPv6 can be considered a lousy solution under this view), we can either live with it or give it up. Living with it means providing a solution for the PI requesting organisations and waiting for an aggregation enhancement of the routing protocols or keep it experimental, which probably means: Let it die. Even if the PI question is solved these days, I won't be sure if the answer isn't already too late. The market will tell us. >I'd rather have a working internet without PI than a non-working one >with it. Nobody can guarantuee that we won't run into trouble with PI >so the only way we can be sure we won't have this trouble is to not >have PI. This argument is unreal, you can stop _any_ project with it, in Germany we call it "Vollkaskomentatlitaet" and our country suffers a lot from it. There is simply no way to prove that a given solution won't have a side effect. If you write: "Nobody can guarantee ..." then I will tell you: Nobody can _guarantee_ that your posting by its formating or content can't cause a significant harm to an important server, cause a worldwide crash of the internet, thus impairs water and electricity supply and at the end let the aliens conquer earth. Thus you shouldn't post to this list ... Of course this is very very unlikely to happen, but, who knows, a word sequence within your comment might trigger this by a unknown bug within a common microprocessor type. You can't gurantee that your posts don't harm, thus by your own logic you should really consider not to post anymore ... More realistic: I'd rather like a internet with IPv6 and PI and the very low probability of of trouble which can with a high probably be fixed than no real-in-use IPv6 because of arguments which request gurantees that can't be given for _any_ solution on this planet. Up to now engineers have always proven to find solutions for networking problems like the PI issue, thus there will be some solution for sure if required. However I doubt there will be ever this requirement. > Do whatever you want, as long as you don't do it in my routing table. You are free to implement _your_ routing table as you like and to filter what you like, however: The global routing table is not _your_ routing table. Please don't block further enhancements of the Internet and please don't damage IPv6 by spreading out FUD. Thank You! Best regards Oliver Bartels P.s. @RIPE NCC: Question: Is there a practical way to replace the slow and cumbersome "consensus" principle of the RIPE by a democratic majority vote of the RIPE NCC members to stop further damage to IPv6, perhaps with a decision at the next RIPE NCC general meeting ? Of course some RIPE participants might then discuss adresss policies for ever, but for the RIPE NCC members we would then probably have practically acceptale policies for implementation in real world networks. Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver at bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 From oliver at bartels.de Tue Dec 6 20:10:09 2005 From: oliver at bartels.de (Oliver Bartels) Date: Tue, 06 Dec 2005 20:10:09 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: <69C9413F-A032-491D-8B50-3396284E7A32@muada.com> Message-ID: <200512061909.jB6J9chq022181@alpha.bartels.de> On Tue, 6 Dec 2005 18:08:40 +0100, Iljitsch van Beijnum wrote: >On 6-dec-2005, at 17:36, Oliver Bartels wrote: >> You may aggregatable PI space if you can convince the router >> manufacturers create and implement a new RFC which adds an >> additional layer for prefix aggregation within the BGP protocol. > >I can't imagine what such a layer would look like... Clustering all PI-prefixes originating at the same AS to form a single "super-prefix" makes policy processing a lot easier, because it need to be done just once for the whole block. This is obvious for single homed PI and even saves processing time on multihomed PI. Whether the address space occupied by this prefix is homogenous or not is a "don't care" nowadays, as a large forwarding table isn't a problem at all. With as few as 256MByte of DDRAM plus a 64K TCAM chip it is possible to handle max. 8 Million Forwarding entries at full 128 bit resolution with appx. 10 GBit/s typical and 1.5 GBit/s "bad weather" (small packets only) line rate. I personally just received a patent on such router hardware concept. >In IP? Don't think so. If you have pointers, please enlighten me. In POTS and X.25 networks. The latter died ... >> Nowadays carriers use DWDM technology, and yes, a link >> between Frankfurt and London or even New York is cheaper and >> easier to obtain than a link between Frankfurt and Wiesbaden. > >Sure. But trying to aggregate on network topology is never going to >work for two very simple reasons: > >1. It changes all the time The same is true for geographical aggregation. Geographical aggregation would require free transit, otherwise it is not compatible with the ISP's business models. There is no free transit and thus it doesn't work. Business relations changes all the time and in a global markets world these business relations don't stop on country boundaries. Such boundaries are artifical, the EU tries to avoid them. Thus the only aggregation you would gain is: Americas / Europe-Asia / Asia-Pacific. Not even Africa and with huge problems in Asia. Everything below this continental boundaries can be treated local and, with your own words : It changes all the time ( Why: See below, dimensions. ) Thus with a geographical approach your aggregation gain is near zero (might be a factor of 2..3 in the table, which is near zero in this context). Sorry, but geographical aggregation won't work in these days any more. >2. You can't express a topology with loops in it in an addressing >hierarchy Avoiding loops is the job of the routing protocol, not the topology. >Distance is actually very important. It's very hard to do decent high >speed file transfer on out of the box OSes and applications with high >delay. Also, it often makes sense to backhaul traffic over SOME >distance, but that doesn't mean it also makes sense to backhaul it >over even larger distances. I.e., even if a link to New York is >cheap, you don't want to go over Palo Alto. If I would be located in Seattle, Palo Alto might be an alternative way point as well as Chicago or even Dallas. What you are trying is: Map a two-and-a-half-dimensional world on a one-dimensional address range. This won't work by Math. Dimensions can only be replaced by dimensions. Asked a database programmer how difficult it is to implement a geographical 10km around some place search on a database and ask them about the algorithms in use. What they try is interleaving the West-East (X) and North-South (Y) coordinates bitwise in the search key and handle overruns by exceptions, like: X_MSB Y_MSB X_2SB Y_2SB X_3SB Y_3SB ... However this requires a _significant_ exception handling effort, nothing someone would like to implement in a fast forwarding engine for packet routing. Beleave me: The cost for 256MBytes of DDRAM is in the lower two digits Euro range, nothing to be discussed with high end routers. A large forwarding table is much cheaper than a geographical packet resolution. >However, the choice isn't between allowing unlimited growth and >hoping we can fix it later and not using IPv6, the choice is between: > >- Not allowing PI >- Coming up with aggregatable PI of some kind >- Give up and make the exact same mess of IPv6 as we did with IPv4 > >Today, IPv4 routing works but it has come close to the edge of the >cliff twice (early 1990s just before CIDR routing tables were too >large and late 1990s flapping cost too much CPU) and it's still >pushing towards that edge, which we can't see clearly but know is out >there somewhere. It works. Period. And it will continue to work, because of the economic pressure. Engineers have found a solution, thus: Don't worry. >So because you can't prove that you're right I should just believe >you without proof? Yes, because the theory of computer sience gives you the prrof that there are theorems in this world which can't be proven. Computer Software belongs to this sort of items, someone can just test it, make assumptions, but can't prove it will be correct for any but the most simple algorithms. And this is proven. Try to build an algorithm which checks that any other algorithm will correctly terminate. Try to apply this algorithm to itself, think about the consequences and then you might understand: Real technology is always believe at some point and not proof. There is no way to get a _proof_ that your post (or my) doesn't trigger a nasty CPU or router operating system bug which causes the internet meltdown. There is just believe and trust that reasonable router manufacturers will deliver reasonable products. >No, but there's no reasonable scenario that makes this happen either. Of course there is. Think of the nasty multiplication bug with the Intel 486 CPU. This happened just with a few numbers. Intel replaced a huge amount of these chips free of charge. Think of a race condition in a chip, which processes your post and creates a checksum. Under very rare circumstances the race condition applies for your checksum (see multiply bug), cascades to a bus collision and melts down the router. However the forwarding hardware already received the ok to output the dangerous packet to the next router in the chain without further intervention of the hardware which just died. >The scenario that de facto unlimited PI in IPv6 will make routing >tables so large that it becomes problematic in some way or another is >entirely reasonable, on the other hand. The current experience let us make a reasonable and responsible assumption that a IPv6 routing table would take not much more growth than the current IPv4 table, whereas current technology permits tables of 10 to 100 times that size. >Yes, I've heard it all before. Why don't we work on something that we >can all get behind? The beauty of my geographical aggregation thing >is that you still get PI even if it turns out that it doesn't work. >So you get what you want regardless of who's right. Pretty good deal, >don't you think? Again: 2 dimensions -> 1 dimension doesn't work. >Please replace "RIPE NCC members" with "people who have to pay for >bigger routers world wide" (not just the RIPE region) and I'm all for >it. People who pay for big routers pay for big pipes, too. They pay significantly more for big pipes than for big routers. If you give them the choice to save 10% on the pipe for using the cheaper offer instead of the one-dimensional-geographical ordering-correct offer, and increase the router price by 30% percent for increased routing flexibility and larger tables, they still will vote for the cheaper pipe. Best Regards Oliver Bartels Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver at bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 From fw at deneb.enyo.de Wed Dec 21 12:53:43 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 21 Dec 2005 12:53:43 +0100 Subject: [ipv6-wg] Real-world IPv6 SMTP experience Message-ID: <87u0d2oed4.fsf@mid.deneb.enyo.de> Hi, is there any document that contrasts RFC 3974 with the real world? I try to create a set of MX RRs which includes an IPv6 MX host, does not negatively impact reachability from v4-only hosts (or v6-enabled hosts without v6 connectivity), prefers v6 over v4 when possible, and does not waste any IPv4 addresses. This is what I've come up with so far: deneb.enyo.de. 172800 IN MX 9 v6.mail.enyo.de. deneb.enyo.de. 172800 IN MX 10 v4.mail.enyo.de. v6.mail.enyo.de. 172800 IN A 212.9.189.167 v6.mail.enyo.de. 172800 IN AAAA 2001:14b0:202:1::a7 v4.mail.enyo.de. 172800 IN A 212.9.189.167 The A RR of v6.mail is necessary because some broken anti-spam checks reject mail from deneb.enyo.de if they cannot find an A record for the primary MX. The v4.mail MX host is needed because some MTAs suppress A record lookup if they discover an AAAA record (even if there's no v6 connectivity available). I wouldn't be too surprised when this setup leads to bouncing mail, too. 8-> Florian From jeroen at unfix.org Wed Dec 21 13:26:48 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 21 Dec 2005 13:26:48 +0100 Subject: [ipv6-wg] Real-world IPv6 SMTP experience In-Reply-To: <87u0d2oed4.fsf@mid.deneb.enyo.de> References: <87u0d2oed4.fsf@mid.deneb.enyo.de> Message-ID: <43A94A08.4030707@unfix.org> Florian Weimer wrote: > Hi, > > is there any document that contrasts RFC 3974 with the real world? No, because that setup works perfectly well. Do you have reason to believe that it doesn't? > I > try to create a set of MX RRs which includes an IPv6 MX host, does not > negatively impact reachability from v4-only hosts (or v6-enabled hosts > without v6 connectivity), prefers v6 over v4 when possible, and does > not waste any IPv4 addresses. Then do it like described in the above RFC. > This is what I've come up with so far: > > deneb.enyo.de. 172800 IN MX 9 v6.mail.enyo.de. > deneb.enyo.de. 172800 IN MX 10 v4.mail.enyo.de. > > v6.mail.enyo.de. 172800 IN A 212.9.189.167 > v6.mail.enyo.de. 172800 IN AAAA 2001:14b0:202:1::a7 > v4.mail.enyo.de. 172800 IN A 212.9.189.167 This will (normally) never hit v4.mail.enyo.de as the SMTP client will try v6.mail.enyo.de IPv6's address, if that connect fails it will try v6.mail.enyo.de's IPv4 address. If v6.mail.enyo.de returns a 4xx then the client will try v4.mail.enyo.de, which only has an IPv4 address. > The A RR of v6.mail is necessary because some broken anti-spam checks > reject mail from deneb.enyo.de if they cannot find an A record for the > primary MX. Blame the broken implementation. Not much you can do about except contacting them to fix their setup. > The v4.mail MX host is needed because some MTAs suppress > A record lookup if they discover an AAAA record (even if there's no v6 > connectivity available). Then those implementations are wrong and need to be fixed. Thus simply use the following as in the RFC: deneb.enyo.de. MX 10 mx1.enyo.de. deneb.enyo.de. MX 20 mx2.enyo.de. mx1.enyo.de. A 212.9.189.167 AAAA 2001:14b0:202:1::a7 mx2.enyo.de. A AAAA Correct implementations will then first try mx1.enyo.de's IPv6 address, if the IPv6 connect fails it will try mx1's IPv4. If mx1 gives 4xx it will try mx2's IPv6, if that IPv6 connect fails it falls back to mx2's IPv4. This works flawlessly. If there is an implementation/setup that doesn't work with the above setup then contact them to let them fix it. I haven't seen any issues with setups of the above form btw and I have been running a A/AAAA setup for almost 4 years now on several domains. Also note that you might want to have more than 1 physically separated MX. If your sole machine now dies your mail will not be delivered. Having a separated MX will allow it to be directly delivered at that place and not entering queues at remote sites. Unless you loadbalance and have a 99.999999999999999% SLA on the link to the internet of course. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 238 bytes Desc: OpenPGP digital signature URL: From filiz at ripe.net Wed Dec 21 13:30:11 2005 From: filiz at ripe.net (Filiz Yilmaz) Date: Wed, 21 Dec 2005 13:30:11 +0100 Subject: [ipv6-wg] New IPv6 Address Block Allocated to the RIPE NCC Message-ID: <20051221123011.GE6801@ripe.net> [Apologies for Duplicates] Dear Colleagues The RIPE NCC received the IPv6 address range 2A01:0000::/16 from the IANA in December 2005. 2A01:0000::/23 was allocated to the RIPE NCC in July 2005. This latest range includes that previous allocation. You may wish to adjust any filters you have in place accordingly. You can find more information about the IP space administered by the RIPE NCC on our web site at: https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html Regards, Filiz Yilmaz RIPE NCC From jeroen at unfix.org Wed Dec 21 13:42:26 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 21 Dec 2005 13:42:26 +0100 Subject: [ipv6-wg] Re: New IPv6 Address Block Allocated to the RIPE NCC In-Reply-To: <20051221123011.GE6801@ripe.net> References: <20051221123011.GE6801@ripe.net> Message-ID: <43A94DB2.6050304@unfix.org> Filiz Yilmaz wrote: > The RIPE NCC received the IPv6 address range 2A01:0000::/16 from > the IANA in December 2005. !Finally! IANA is passing /16's directly to the RIR's! That is a good thing to see happening. Congrats (Or did somebody request a /17 ? :) > 2A01:0000::/23 was allocated to the RIPE NCC in July 2005. This > latest range includes that previous allocation. > > You may wish to adjust any filters you have in place accordingly. See http://www.space.net/~gert/RIPE/ipv6-filters.html I expect Gert to update those later today, give him a few moments ;) Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 238 bytes Desc: OpenPGP digital signature URL: From gert at space.net Wed Dec 21 13:43:33 2005 From: gert at space.net (Gert Doering) Date: Wed, 21 Dec 2005 13:43:33 +0100 Subject: [ipv6-wg] New IPv6 Address Block Allocated to the RIPE NCC In-Reply-To: <20051221123011.GE6801@ripe.net> References: <20051221123011.GE6801@ripe.net> Message-ID: <20051221124333.GK69925@Space.Net> Hi, On Wed, Dec 21, 2005 at 01:30:11PM +0100, Filiz Yilmaz wrote: > The RIPE NCC received the IPv6 address range 2A01:0000::/16 from > the IANA in December 2005. > > 2A01:0000::/23 was allocated to the RIPE NCC in July 2005. This > latest range includes that previous allocation. This is good news. No more "/23 piecemeal". Thank you very much to everybody involved. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From gert at space.net Wed Dec 21 13:52:55 2005 From: gert at space.net (Gert Doering) Date: Wed, 21 Dec 2005 13:52:55 +0100 Subject: [ipv6-wg] Re: [routing-wg]Re: New IPv6 Address Block Allocated to the RIPE NCC In-Reply-To: <43A94DB2.6050304@unfix.org> References: <20051221123011.GE6801@ripe.net> <43A94DB2.6050304@unfix.org> Message-ID: <20051221125255.GL69925@Space.Net> Hi, On Wed, Dec 21, 2005 at 01:42:26PM +0100, Jeroen Massar wrote: > > 2A01:0000::/23 was allocated to the RIPE NCC in July 2005. This > > latest range includes that previous allocation. > > > > You may wish to adjust any filters you have in place accordingly. > > See http://www.space.net/~gert/RIPE/ipv6-filters.html > I expect Gert to update those later today, give him a few moments ;) *done*, thanks for reminding me. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From fw at deneb.enyo.de Wed Dec 21 14:42:24 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 21 Dec 2005 14:42:24 +0100 Subject: [ipv6-wg] Real-world IPv6 SMTP experience In-Reply-To: <43A94A08.4030707@unfix.org> (Jeroen Massar's message of "Wed, 21 Dec 2005 13:26:48 +0100") References: <87u0d2oed4.fsf@mid.deneb.enyo.de> <43A94A08.4030707@unfix.org> Message-ID: <87y82ek1mn.fsf@mid.deneb.enyo.de> * Jeroen Massar: > Florian Weimer wrote: >> Hi, >> >> is there any document that contrasts RFC 3974 with the real world? > > No, because that setup works perfectly well. Do you have reason to > believe that it doesn't? Yes, real-world experiments with v6-enabled MX hosts which send and receive significant volumes of mail flatly contradict this document. The last DNS example in Section 2 breaks sender domain verification in Sendmail 8.12 (and others). >> try to create a set of MX RRs which includes an IPv6 MX host, does not >> negatively impact reachability from v4-only hosts (or v6-enabled hosts >> without v6 connectivity), prefers v6 over v4 when possible, and does >> not waste any IPv4 addresses. > > Then do it like described in the above RFC. I did, it doesn't work. >> This is what I've come up with so far: >> >> deneb.enyo.de. 172800 IN MX 9 v6.mail.enyo.de. >> deneb.enyo.de. 172800 IN MX 10 v4.mail.enyo.de. >> >> v6.mail.enyo.de. 172800 IN A 212.9.189.167 >> v6.mail.enyo.de. 172800 IN AAAA 2001:14b0:202:1::a7 >> v4.mail.enyo.de. 172800 IN A 212.9.189.167 > > This will (normally) never hit v4.mail.enyo.de as the SMTP client will > try v6.mail.enyo.de IPv6's address, if that connect fails it will try > v6.mail.enyo.de's IPv4 address. In the world, different things happened because AAAA records can mask the existence of A records. Sure, it's a bug, but I would expect that >> The A RR of v6.mail is necessary because some broken anti-spam checks >> reject mail from deneb.enyo.de if they cannot find an A record for the >> primary MX. > > Blame the broken implementation. Not much you can do about except > contacting them to fix their setup. I wish publish DNS which is as conservative as possible, while still enabling IPv6. This shouldn't be impossible. If it is, we simply need some other transition mechanism. If I must choose between "SMTP over IPv6" and "reliable Internet mail", my choice is clear, and most people will share my preferences. > Then those implementations are wrong and need to be fixed. Sure, but the ETA for that fix on real machines is mid-2007 to the end of 2008, and these estimates only deal with one piece of software (Exim in Debian). The other requirement (for interoperability, the primary MX MUST have an A record) is not amenable to a fix because it is rather widely implemented and not clearly a bug. > Thus simply use the following as in the RFC: There are several examples in that RFC, and I've tried most of them. > deneb.enyo.de. MX 10 mx1.enyo.de. > deneb.enyo.de. MX 20 mx2.enyo.de. > > mx1.enyo.de. A 212.9.189.167 > AAAA 2001:14b0:202:1::a7 > mx2.enyo.de. A > AAAA Doesn't work, it suffers from the same AAAA-masks-A problem I mentioned. > Correct implementations Real-world implementations behave differently, I'm afraid. And in the end, I receive my mail from real-world implementations which are not necessarily completely correct. > This works flawlessly. No, it doesn't. > If there is an implementation/setup that doesn't > work with the above setup then contact them to let them fix it. Too many machines to fix, I'm afraid. The AAAA-masks-A bug manifests itself even if there is no working IPv6 connectivity. It has been gradually introduced to the general mail server population since mid-2004, and since June 2005, there should be a measurable number of hosts affected by it. From pim at ipng.nl Wed Dec 21 14:54:37 2005 From: pim at ipng.nl (Pim van Pelt) Date: Wed, 21 Dec 2005 14:54:37 +0100 Subject: [ipv6-wg] New IPv6 Address Block Allocated to the RIPE NCC In-Reply-To: <20051221123011.GE6801@ripe.net> References: <20051221123011.GE6801@ripe.net> Message-ID: <20051221135437.GM2702@bfib.ipng.nl> Hi Filiz, | The RIPE NCC received the IPv6 address range 2A01:0000::/16 from | the IANA in December 2005. Yaay, finally decently sized chunks to RIRs. Well done. -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim at ipng.nl http://www.ipng.nl/ IPv6 Deployment ----------------------------------------------- From gert at space.net Wed Dec 21 15:10:59 2005 From: gert at space.net (Gert Doering) Date: Wed, 21 Dec 2005 15:10:59 +0100 Subject: [ipv6-wg] Real-world IPv6 SMTP experience In-Reply-To: <87y82ek1mn.fsf@mid.deneb.enyo.de> References: <87u0d2oed4.fsf@mid.deneb.enyo.de> <43A94A08.4030707@unfix.org> <87y82ek1mn.fsf@mid.deneb.enyo.de> Message-ID: <20051221141059.GO69925@Space.Net> Hi, On Wed, Dec 21, 2005 at 02:42:24PM +0100, Florian Weimer wrote: > > If there is an implementation/setup that doesn't > > work with the above setup then contact them to let them fix it. > > Too many machines to fix, I'm afraid. The AAAA-masks-A bug manifests > itself even if there is no working IPv6 connectivity. It has been > gradually introduced to the general mail server population since > mid-2004, and since June 2005, there should be a measurable number of > hosts affected by it. Interesting. My home DNS setup (since over a year now) looks like this: greenie.muc.de. 14m32s IN MX 5 kirk.greenie.muc.de. kirk.greenie.muc.de. 9m16s IN AAAA 2001:608:4::3 kirk.greenie.muc.de. 9m18s IN A 193.149.48.167 and I haven't had any reproduceable mail reception or delivery problems since then. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From fw at deneb.enyo.de Wed Dec 21 15:23:27 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 21 Dec 2005 15:23:27 +0100 Subject: [ipv6-wg] Real-world IPv6 SMTP experience In-Reply-To: <20051221141059.GO69925@Space.Net> (Gert Doering's message of "Wed, 21 Dec 2005 15:10:59 +0100") References: <87u0d2oed4.fsf@mid.deneb.enyo.de> <43A94A08.4030707@unfix.org> <87y82ek1mn.fsf@mid.deneb.enyo.de> <20051221141059.GO69925@Space.Net> Message-ID: <871x06jzq8.fsf@mid.deneb.enyo.de> * Gert Doering: > Hi, > > On Wed, Dec 21, 2005 at 02:42:24PM +0100, Florian Weimer wrote: >> > If there is an implementation/setup that doesn't >> > work with the above setup then contact them to let them fix it. >> >> Too many machines to fix, I'm afraid. The AAAA-masks-A bug manifests >> itself even if there is no working IPv6 connectivity. It has been >> gradually introduced to the general mail server population since >> mid-2004, and since June 2005, there should be a measurable number of >> hosts affected by it. > > Interesting. > > My home DNS setup (since over a year now) looks like this: > > greenie.muc.de. 14m32s IN MX 5 kirk.greenie.muc.de. > kirk.greenie.muc.de. 9m16s IN AAAA 2001:608:4::3 > kirk.greenie.muc.de. 9m18s IN A 193.149.48.167 Selective quoting. 8-) There are a couple more MX records: greenie.muc.de. 900 IN MX 15000 mx1.muc.de. greenie.muc.de. 900 IN MX 16000 mx-150.space.net. greenie.muc.de. 900 IN MX 16500 mx-200.space.net. These are IPv4-only, and they help to pamper over the AAAA-masks-A issue. If a broken Exim installation sees just this record for kirk.greenie.muc.de: kirk.greenie.muc.de. 9m16s IN AAAA 2001:608:4::3 it still falls back to the other MXes. But your experience indicates that this setup should be fairly safe (especially if you exchange mail regularly with some other site in Stuttgart which is thought to suffer from the AAAA-masks-A bug 8-). From gert at space.net Wed Dec 21 15:50:52 2005 From: gert at space.net (Gert Doering) Date: Wed, 21 Dec 2005 15:50:52 +0100 Subject: [ipv6-wg] Real-world IPv6 SMTP experience In-Reply-To: <871x06jzq8.fsf@mid.deneb.enyo.de> References: <87u0d2oed4.fsf@mid.deneb.enyo.de> <43A94A08.4030707@unfix.org> <87y82ek1mn.fsf@mid.deneb.enyo.de> <20051221141059.GO69925@Space.Net> <871x06jzq8.fsf@mid.deneb.enyo.de> Message-ID: <20051221145052.GQ69925@Space.Net> Hi, On Wed, Dec 21, 2005 at 03:23:27PM +0100, Florian Weimer wrote: > Selective quoting. 8-) There are a couple more MX records: > > greenie.muc.de. 900 IN MX 15000 mx1.muc.de. > greenie.muc.de. 900 IN MX 16000 mx-150.space.net. > greenie.muc.de. 900 IN MX 16500 mx-200.space.net. Indeed. > These are IPv4-only, and they help to pamper over the AAAA-masks-A > issue. If a broken Exim installation sees just this record for > kirk.greenie.muc.de: > > kirk.greenie.muc.de. 9m16s IN AAAA 2001:608:4::3 > > it still falls back to the other MXes. So if I understand this correctly, having a v4-only backup MX should solve all problems commonly experienced? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From fw at deneb.enyo.de Wed Dec 21 16:08:16 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 21 Dec 2005 16:08:16 +0100 Subject: [ipv6-wg] Real-world IPv6 SMTP experience In-Reply-To: <20051221145052.GQ69925@Space.Net> (Gert Doering's message of "Wed, 21 Dec 2005 15:50:52 +0100") References: <87u0d2oed4.fsf@mid.deneb.enyo.de> <43A94A08.4030707@unfix.org> <87y82ek1mn.fsf@mid.deneb.enyo.de> <20051221141059.GO69925@Space.Net> <871x06jzq8.fsf@mid.deneb.enyo.de> <20051221145052.GQ69925@Space.Net> Message-ID: <877j9yij33.fsf@mid.deneb.enyo.de> * Gert Doering: > So if I understand this correctly, having a v4-only backup MX should > solve all problems commonly experienced? As far as I know, the primary MX needs an A record (to satisfy Sendmail), and there needs to be a MX which has an A record only (and no AAAA or A6 record; this is done to satisfy Exim installations). My initial question to this list was whether if you can do this with just a single IPv4 address, and still prefer IPv6 over IPv4 (assuming that IPv6-capable hosts prefer IPv6 hosts over IPv4 hosts if they have the same priority). From Stig.Venaas at uninett.no Wed Dec 21 16:13:04 2005 From: Stig.Venaas at uninett.no (Stig Venaas) Date: Wed, 21 Dec 2005 16:13:04 +0100 Subject: [ipv6-wg] Real-world IPv6 SMTP experience In-Reply-To: <877j9yij33.fsf@mid.deneb.enyo.de> References: <87u0d2oed4.fsf@mid.deneb.enyo.de> <43A94A08.4030707@unfix.org> <87y82ek1mn.fsf@mid.deneb.enyo.de> <20051221141059.GO69925@Space.Net> <871x06jzq8.fsf@mid.deneb.enyo.de> <20051221145052.GQ69925@Space.Net> <877j9yij33.fsf@mid.deneb.enyo.de> Message-ID: <20051221151304.GD19052@tyholt.uninett.no> On Wed, Dec 21, 2005 at 04:08:16PM +0100, Florian Weimer wrote: > * Gert Doering: > > > So if I understand this correctly, having a v4-only backup MX should > > solve all problems commonly experienced? > > As far as I know, the primary MX needs an A record (to satisfy > Sendmail), and there needs to be a MX which has an A record only (and > no AAAA or A6 record; this is done to satisfy Exim installations). My > initial question to this list was whether if you can do this with just > a single IPv4 address, and still prefer IPv6 over IPv4 (assuming that > IPv6-capable hosts prefer IPv6 hosts over IPv4 hosts if they have the > same priority). At least at uninett.no this is done with only one IPv4 address. The primary MX has both A and AAAA, and the secondary is only A, but with same IPv4 address as primary. Well, you can check mx's for uninett.no yourself. I know several sites that have both A and AAAA for all MXs. It doesn't sound safe to me, but I assume it can't be that problematic then...? Stig From william at elan.net Wed Dec 21 16:15:08 2005 From: william at elan.net (william(at)elan.net) Date: Wed, 21 Dec 2005 07:15:08 -0800 (PST) Subject: [ipv6-wg] Real-world IPv6 SMTP experience In-Reply-To: <877j9yij33.fsf@mid.deneb.enyo.de> References: <87u0d2oed4.fsf@mid.deneb.enyo.de> <43A94A08.4030707@unfix.org> <87y82ek1mn.fsf@mid.deneb.enyo.de> <20051221141059.GO69925@Space.Net> <871x06jzq8.fsf@mid.deneb.enyo.de> <20051221145052.GQ69925@Space.Net> <877j9yij33.fsf@mid.deneb.enyo.de> Message-ID: On Wed, 21 Dec 2005, Florian Weimer wrote: > As far as I know, the primary MX needs an A record (to satisfy > Sendmail), and there needs to be a MX which has an A record only (and > no AAAA or A6 record; this is done to satisfy Exim installations). Where did you get that exim needs to see at least one MX with ONLY A record? -- William Leibzon Elan Networks william at elan.net From fw at deneb.enyo.de Wed Dec 21 16:22:25 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 21 Dec 2005 16:22:25 +0100 Subject: [ipv6-wg] Real-world IPv6 SMTP experience In-Reply-To: (william elan net's message of "Wed, 21 Dec 2005 07:15:08 -0800 (PST)") References: <87u0d2oed4.fsf@mid.deneb.enyo.de> <43A94A08.4030707@unfix.org> <87y82ek1mn.fsf@mid.deneb.enyo.de> <20051221141059.GO69925@Space.Net> <871x06jzq8.fsf@mid.deneb.enyo.de> <20051221145052.GQ69925@Space.Net> <877j9yij33.fsf@mid.deneb.enyo.de> Message-ID: <871x06iifi.fsf@mid.deneb.enyo.de> * william elan net: > On Wed, 21 Dec 2005, Florian Weimer wrote: > >> As far as I know, the primary MX needs an A record (to satisfy >> Sendmail), and there needs to be a MX which has an A record only (and >> no AAAA or A6 record; this is done to satisfy Exim installations). > > Where did you get that exim needs to see at least one MX with ONLY A > record? Some of the mail I sent to deneb.enyo.de through an MX running Exim bounced, and Marc Haber and I figured out that it was due to an AAAA-masks-A bug in Exim: Of course, this is a clear Exim bug, and no doubt it will be fixed soon in the official distribution. But it will take some time until this fix is deployed in the field, and in the meantime, I still need to receive mail from affected sites. From tjc at ecs.soton.ac.uk Wed Dec 21 17:10:42 2005 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Wed, 21 Dec 2005 16:10:42 +0000 Subject: [ipv6-wg] Real-world IPv6 SMTP experience In-Reply-To: <20051221151304.GD19052@tyholt.uninett.no> References: <87u0d2oed4.fsf@mid.deneb.enyo.de> <43A94A08.4030707@unfix.org> <87y82ek1mn.fsf@mid.deneb.enyo.de> <20051221141059.GO69925@Space.Net> <871x06jzq8.fsf@mid.deneb.enyo.de> <20051221145052.GQ69925@Space.Net> <877j9yij33.fsf@mid.deneb.enyo.de> <20051221151304.GD19052@tyholt.uninett.no> Message-ID: <20051221161042.GB24455@login.ecs.soton.ac.uk> On Wed, Dec 21, 2005 at 04:13:04PM +0100, Stig Venaas wrote: > On Wed, Dec 21, 2005 at 04:08:16PM +0100, Florian Weimer wrote: > > * Gert Doering: > > > > > So if I understand this correctly, having a v4-only backup MX should > > > solve all problems commonly experienced? > > > > As far as I know, the primary MX needs an A record (to satisfy > > Sendmail), and there needs to be a MX which has an A record only (and > > no AAAA or A6 record; this is done to satisfy Exim installations). My > > initial question to this list was whether if you can do this with just > > a single IPv4 address, and still prefer IPv6 over IPv4 (assuming that > > IPv6-capable hosts prefer IPv6 hosts over IPv4 hosts if they have the > > same priority). > > At least at uninett.no this is done with only one IPv4 address. The > primary MX has both A and AAAA, and the secondary is only A, but with > same IPv4 address as primary. Well, you can check mx's for uninett.no > yourself. > > I know several sites that have both A and AAAA for all MXs. It doesn't > sound safe to me, but I assume it can't be that problematic then...? Like Gert and Jeroen, we do that, and have not had complaints of failed or problematic email (and have done it for a long time). That's on a domain handling maybe 100K mails a day. -- Tim/::1 From pim at ipng.nl Wed Dec 21 17:22:27 2005 From: pim at ipng.nl (Pim van Pelt) Date: Wed, 21 Dec 2005 17:22:27 +0100 Subject: [ipv6-wg] Real-world IPv6 SMTP experience In-Reply-To: <20051221145052.GQ69925@Space.Net> References: <87u0d2oed4.fsf@mid.deneb.enyo.de> <43A94A08.4030707@unfix.org> <87y82ek1mn.fsf@mid.deneb.enyo.de> <20051221141059.GO69925@Space.Net> <871x06jzq8.fsf@mid.deneb.enyo.de> <20051221145052.GQ69925@Space.Net> Message-ID: <20051221162227.GO2702@bfib.ipng.nl> Hi, | So if I understand this correctly, having a v4-only backup MX should | solve all problems commonly experienced? Yes. Note that BIT has not seen any MTA problems, even though BIT may be somewhat bolder than most. We have our MX records pointing to: bit.nl mail is handled by 100 mx1.bit.nl. bit.nl mail is handled by 200 mx2.bit.nl. bit.nl mail is handled by 300 mx3.bit.nl. ... and each of these has an IPv4 and an IPv6 address. -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim at ipng.nl http://www.ipng.nl/ IPv6 Deployment ----------------------------------------------- From md at Linux.IT Wed Dec 21 18:30:36 2005 From: md at Linux.IT (Marco d'Itri) Date: Wed, 21 Dec 2005 18:30:36 +0100 Subject: [ipv6-wg] Real-world IPv6 SMTP experience In-Reply-To: <20051221151304.GD19052@tyholt.uninett.no> References: <87u0d2oed4.fsf@mid.deneb.enyo.de> <43A94A08.4030707@unfix.org> <87y82ek1mn.fsf@mid.deneb.enyo.de> <20051221141059.GO69925@Space.Net> <871x06jzq8.fsf@mid.deneb.enyo.de> <20051221145052.GQ69925@Space.Net> <877j9yij33.fsf@mid.deneb.enyo.de> <20051221151304.GD19052@tyholt.uninett.no> Message-ID: <20051221173036.GC10456@wonderland.linux.it> On Dec 21, Stig Venaas wrote: > I know several sites that have both A and AAAA for all MXs. It doesn't > sound safe to me, but I assume it can't be that problematic then...? In my experience (linux.it and other domains, IIRC since three years) a single MX record with A + AAAA records has not caused deliverability errors for incoming nor for outgoing mail. The same applies to a domain with A and AAAA records and no explicit MX. (I had many more troubles from broken CPMTA installs, which for some unknown reason in Italy are often configured by default to not deliver mail to domains without a MX record.) -- ciao, Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From dr at cluenet.de Thu Dec 22 00:01:10 2005 From: dr at cluenet.de (Daniel Roesen) Date: Thu, 22 Dec 2005 00:01:10 +0100 Subject: [ipv6-wg] New IPv6 Address Block Allocated to the RIPE NCC In-Reply-To: <20051221135437.GM2702@bfib.ipng.nl> References: <20051221123011.GE6801@ripe.net> <20051221135437.GM2702@bfib.ipng.nl> Message-ID: <20051221230110.GA18975@srv01.cluenet.de> On Wed, Dec 21, 2005 at 02:54:37PM +0100, Pim van Pelt wrote: > | The RIPE NCC received the IPv6 address range 2A01:0000::/16 from > | the IANA in December 2005. > Yaay, finally decently sized chunks to RIRs. Well done. You're jumping to conclusions. As Jeroen mentioned, it could be just someone getting an /17 (with a /17 above reserved for expansion). Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From fw at deneb.enyo.de Tue Dec 27 10:11:18 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Tue, 27 Dec 2005 10:11:18 +0100 Subject: [ipv6-wg] Real-world IPv6 SMTP experience In-Reply-To: <20051221173036.GC10456@wonderland.linux.it> (Marco d'Itri's message of "Wed, 21 Dec 2005 18:30:36 +0100") References: <87u0d2oed4.fsf@mid.deneb.enyo.de> <43A94A08.4030707@unfix.org> <87y82ek1mn.fsf@mid.deneb.enyo.de> <20051221141059.GO69925@Space.Net> <871x06jzq8.fsf@mid.deneb.enyo.de> <20051221145052.GQ69925@Space.Net> <877j9yij33.fsf@mid.deneb.enyo.de> <20051221151304.GD19052@tyholt.uninett.no> <20051221173036.GC10456@wonderland.linux.it> Message-ID: <87d5ji9a6h.fsf@mid.deneb.enyo.de> * Marco d'Itri: > On Dec 21, Stig Venaas wrote: > >> I know several sites that have both A and AAAA for all MXs. It doesn't >> sound safe to me, but I assume it can't be that problematic then...? > In my experience (linux.it and other domains, IIRC since three years) > a single MX record with A + AAAA records has not caused deliverability > errors for incoming nor for outgoing mail. The same applies to a domain > with A and AAAA records and no explicit MX. Try to get logs from master.debian.org. I'm pretty sure they will show some bounces. bugs.debian.org (= spohr.debian.org) probably has similar issues. Just because you don't know about these bounces doesn't mean they don't exist. 8-) From md at Linux.IT Tue Dec 27 11:40:17 2005 From: md at Linux.IT (Marco d'Itri) Date: Tue, 27 Dec 2005 11:40:17 +0100 Subject: [ipv6-wg] Real-world IPv6 SMTP experience In-Reply-To: <87d5ji9a6h.fsf@mid.deneb.enyo.de> References: <87u0d2oed4.fsf@mid.deneb.enyo.de> <43A94A08.4030707@unfix.org> <87y82ek1mn.fsf@mid.deneb.enyo.de> <20051221141059.GO69925@Space.Net> <871x06jzq8.fsf@mid.deneb.enyo.de> <20051221145052.GQ69925@Space.Net> <877j9yij33.fsf@mid.deneb.enyo.de> <20051221151304.GD19052@tyholt.uninett.no> <20051221173036.GC10456@wonderland.linux.it> <87d5ji9a6h.fsf@mid.deneb.enyo.de> Message-ID: <20051227104017.GA4494@wonderland.linux.it> On Dec 27, Florian Weimer wrote: > Try to get logs from master.debian.org. I'm pretty sure they will > show some bounces. bugs.debian.org (= spohr.debian.org) probably has > similar issues. I get my spam and bugs as usual from the Debian machines, so if there is a problem it looks like it is intermittent. -- ciao, Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From dr at cluenet.de Wed Dec 28 06:56:39 2005 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 28 Dec 2005 06:56:39 +0100 Subject: [ipv6-wg] Re: Re: Re: Andre's guide to fix IPv6 In-Reply-To: <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> References: <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <08D2E092-8FB3-4C5D-9837-4433C77F0B46@kurtis.pp.se> Message-ID: <20051228055639.GA25461@srv01.cluenet.de> On Thu, Dec 01, 2005 at 09:11:48AM +0100, Kurt Erik Lindqvist wrote: > >ISPs do exist for customers, not customers do exist to feed ISPs > >in the > >most convenient way for the ISPs. Some folks seem to forget that, > >looking at all the discussion trying to ignore the demand for real > >multihoming (and that includes TE and network-wide routing policy > >implementation, neither being delivered by things like shim6). > > I think you are contradicting yourself here. Shim6 does give the end- > user TE capability. It doesn't. Unless I'm missing on how I can influence e.g. inbound routing like I can do with BGP announcements, tagged with special communities to tweak announcement properties (yes/no, prepending etc.) and things like routing preference ("local-pref" in BGP semantics) in my upstream's network or even more far reaching than that. I cannot. And as far as I hear, folks at NANOG (IESG BoF on IPv6 multihoming) have clearly laid out why shim6 is NOT what we're looking for - and why. [this is hearsay, I didn't get around to check minutes and/or slides yet] > I am not sure what you mean with "network-wide routing policy > implementation".... As a network administrator I want to define routing properties for my whole network in a consistent way, not to tweak each policy decision in each IPv6 stack on each host. The routing policy of a network is a network property, not a host property. I don't want to HAVE to control (read: administer!) each and every end device on the network just to provide proper global routing to it. That's just ridiculous. > I have still to figure out what the "real multihoming" thing is, That's the basic problem. The IETF folks either don't understand, or chose to ignore the requirements. There is a nice 6NET document detailing all requirements and showing a matrix outlining requirements against proposed solutions. Outcome: NONE except BGP offer a solution to ALL requirements. I'm happy to look into any solution proposed that fulfils the needs. Unfortunately that's not there yet. I'm sure we all would be happy to get rid of the latent possible danger of BGP. > >HOW the requirements are being delivered is another topic. multi6 has > >resulted in the decision to ignore many critical requirements. We're > >just asking for something that delivers on the targets. Wasting time > >with half-solutions is not productive. Halting any development because > >the magic bullet wasn't found yet ain't either. > > If you have alternative ideas you know how it works - send text. I don't, as stated. Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From jeroen at unfix.org Sat Dec 31 10:51:51 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Sat, 31 Dec 2005 10:51:51 +0100 Subject: [ipv6-wg] Re: New IPv6 Address Block Allocated to the RIPE NCC In-Reply-To: <43A94DB2.6050304@unfix.org> References: <20051221123011.GE6801@ripe.net> <43A94DB2.6050304@unfix.org> Message-ID: <43B654B7.1000501@unfix.org> Jeroen Massar wrote: > Filiz Yilmaz wrote: >> The RIPE NCC received the IPv6 address range 2A01:0000::/16 from >> the IANA in December 2005. > !Finally! IANA is passing /16's directly to the RIR's! That is a good > thing to see happening. Congrats (Or did somebody request a /17 ? :) Cheered to early, it's just a big block again: inet6num: 2a01:c000::/19 netname: FR-TELECOM-20051230 descr: France Telecom But it could mean that the wine lovers will get a broad availability of IPv6!!! Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 238 bytes Desc: OpenPGP digital signature URL: