- ipv6-wg - mailman.ripe.net

De-aggregation of assigned IPv6 prefixes?
by Jeroen Massar 06 Dec '05

06 Dec '05

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.

4 3

IPv6 micro allocation or something else?
by Mohacsi Janos 02 Dec '05

02 Dec '05

Dear All, I have a question regarding the IPv6 address assignment to cc level DNS server. If you don't have answer to this question please forward it to an appropriate working group - sorry for cross-posting this mail to two wg. We have here in Hungary a dilemma: - Traditionally, the IPv4 address of the primary cc level DNS server in of belonged to NIIF/HUNGARNET. - The DNS registration service a while ago was delegated to Council of Hungarian Internet Providers (ISZT) who is also operating the biggest Internet Exchange of Hungary (BIX). All big ISPs in Hungary (including NIIF/HUNGARNET) has right to do the registration via a special interface. - The IPv4 address of the primary cc level DNS server announced by NIIF/HUNGARNET. But ISZT is reorganizing its infrastructure to allocate address from a new PI type IPv4 address space to DNS servers. - The primary hu DNS server is connected to BIX - to be well connected. What IPv6 address space should we allocate to hu primary DNS server? 1. Assign IPv6 address from /32 address space of NIIF/HUNGARNET? - not very optimal since the only transit to hu primary will be NIIF/HUNGARNET - not ISP neutral - easy, no problem from point of view of NIIF/HUNGARNET 2. Assign IPv6 address space from /48 allocated to BIX (based on ripe-256 and ripe-310)? - According to the RIPE documents: "Networks assigned under this policy may not be globally routable" - which problematical since primary DNS servers should be globally reachable. 3. Allocate multiple /48 from IPv6 providers in HUNGARY to primary hu DNS server? - This can be problematical since the answers to DNS queries might be quite big. 4. Allocate /48 to primary hu DNS server that is globally routable? Are there similar to /48 from 2001:0500::/30 in RIPE region? - I think this is the cleanest solution. Can we discuss this issue on the working group or mailing lists? I saw a proposal: http://www.ripe.net/ripe/policies/proposals/2005-2.html In my opinion this can solve the problem.... Best Regards, Janos Mohacsi Network Engineer, Research Associate NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98

21 60

Re: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide tofix IPv6
by Randy Bush 01 Dec '05

01 Dec '05

[ 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: <Pine.LNX.4.56.0511211704050.10258(a)chandra.student.uit.no><87slt m3p3n.fsf(a)mid.deneb.enyo.de><Pine.LNX.4.56.0511251013060.10258(a)chandra.stud ent.uit.no><4386E053.73B661B3(a)networx.ch><43886509.6060600(a)unfix.org><87acf r1mjl.fsf(a)mid.deneb.enyo.de><002f01c5f43a$12631110$44eea2d5@l><6.2.0.14.2.2 0051129101355.02919160(a)kahuna.telstra.net><87fypfpm1e.fsf(a)mid.deneb.enyo.de ><6.2.0.14.2.20051130053430.02d015d0(a)kahuna.telstra.net><20051130161647.GA1 2947(a)srv01.cluenet.de><08D2E092-8FB3-4C5D-9837-4433C77F0B46(a)kurtis.pp.se><1 7294.55288.858722.708230(a)roam.psg.com><6.2.0.14.2.20051202045722.02de10b0@k ahuna.telstra.net> <17295.18210.797714.378814(a)roam.psg.com>

1 0

2001:4200::/32, 2001:4308::/32, 2001:4310::/32 AFRINIC, ARIN or RIPE?
by Jeroen Massar 01 Dec '05

01 Dec '05

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(a)ripe.net <SNIP> inet6num: 2001:4300::/25 netname: EU-ZZ-2001-4300 descr: RIPE NCC (AFRINIC) descr: European Regional Registry country: EU --------------------------------------------------------->8

2 1

unsubscribe jkuijer@dds.nl
by jkuijer＠dds.nl 30 Nov '05

30 Nov '05

Citeren ipv6-wg-request(a)ripe.net: > Send ipv6-wg mailing list submissions to > ipv6-wg(a)ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.ripe.net/mailman/listinfo/ipv6-wg > or, via email, send a message with subject or body 'help' to > ipv6-wg-request(a)ripe.net > > You can reach the person managing the list at > ipv6-wg-admin(a)ripe.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ipv6-wg digest..." > > > Today's Topics: > > 1. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Per Heldal) > 2. unsubscibe jkuijer(a)dds.nl (jkuijer(a)dds.nl) > 3. Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 (Florian > Weimer) > 4. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Randy Bush) > 5. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Geoff Huston) > 6. Re: Re: [address-policy-wg] Re: Andre's guide to fix > IPv6 (Geoff Huston) > 7. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Geoff Huston) > 8. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (william(at)elan.net) > 9. Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 (Max Tulyev) > > --__--__-- > > Message: 1 > From: "Per Heldal" <heldal(a)eml.cc> > To: "Salman Asadullah" <sasad(a)cisco.com> > Cc: "ipv6-wg(a)ripe.net" <ipv6-wg(a)ripe.net>, "address-policy-wg(a)ripe.net" > <address-policy-wg(a)ripe.net> > Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI > Date: Tue, 29 Nov 2005 12:21:52 +0100 > > > On Mon, 28 Nov 2005 15:55:16 -0800, "Salman Asadullah" <sasad(a)cisco.com> > said: > > You seem to be far away from the ground realities. > > > > Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these real > > issues for a good reason. > > > > Regardless of the efforts, from a provider POV it's only "work in > progress". Make sure your preferred technology is implemented across all > platforms and accompanied by solutions for traffic-engineering, > filtering and other issues. Then you may have a viable alternative to > present to the operators community. Don't expect anybody to adopt new > technologies unless they represent some progress. > > I'm not saying that shim6 is DOA. It *may become* an alternative, but it > *is not*. Unless you can convince content-providers to trust their > upstream to provide redundancy and thus eliminate the need for end-site > multihoming you have the following realistic short-term alternatives: > > * Keep ipv6 experimental and postpone operational > deployment until there's a good technical solution > to the multi-homing problem or a way to eliminate > the DFZ and the related concerns about routing- > table size. > > * Adopt a PI policy for v6 similar to the current > v4-policy, and hope that moore can keep up with > the growth of the routing-table. > > From there policies will have to evolve, along with the development of > new technology. Evolution is a perpetual process, not a project with a > finite deadline. > > PS! am I missing something, or is IETF/IAB trying to copy the ITU in the > way they produce paper-standards? Is that really such a good idea? > > //per > -- > Per Heldal > heldal(a)eml.cc > > > --__--__-- > > Message: 2 > Date: Tue, 29 Nov 2005 12:25:08 +0100 > From: jkuijer(a)dds.nl > To: ipv6-wg(a)ripe.net > Subject: [ipv6-wg] unsubscibe jkuijer(a)dds.nl > > Citeren ipv6-wg-request(a)ripe.net: > > > Send ipv6-wg mailing list submissions to > > ipv6-wg(a)ripe.net > > > > To subscribe or unsubscribe via the World Wide Web, visit > > http://www.ripe.net/mailman/listinfo/ipv6-wg > > or, via email, send a message with subject or body 'help' to > > ipv6-wg-request(a)ripe.net > > > > You can reach the person managing the list at > > ipv6-wg-admin(a)ripe.net > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of ipv6-wg digest..." > > > > > > Today's Topics: > > > > 1. Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 (McTim) > > 2. Re: [address-policy-wg] Re: Andre's guide to fix IPv6 (Geoff Huston) > > 3. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Randy Bush) > > 4. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Andre Oppermann) > > > > -- __--__-- > > > > Message: 1 > > Date: Tue, 29 Nov 2005 07:19:49 +0300 > > From: McTim <dogwallah(a)gmail.com> > > To: =?ISO-8859-1?Q?J=F8rgen_Hovland?= <jorgen(a)hovland.cx> > > Subject: Re: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix > IPv6 > > Cc: ipv6-wg(a)ripe.net > > > > hiya, > > > > (removed address-policy-wg from the cc:) > > > > On 11/28/05, J=F8rgen Hovland <jorgen(a)hovland.cx> wrote: > > > > > > -----Original Message----- > > > From: McTim [mailto:dogwallah@gmail.com] > > > > > > > >#2 sounds like PI to me. What have I missed? > > > > > > Hello McTim, > > > You are correct. That's why I wrote PI in the email:-). > > > > I guess I misread the below wrong then ;-) > > > > J=F8rgen Hovland wrote: > > > > >> - > > >> 1. No PI. _Only_ network operators get a prefix. > > > > > It is an attempt to suggest an alternative idea to the PI discussion. > > > Don't get me wrong. I am for PI. This idea is perhaps a bit more > > > hierarchical instead of the standard flat one. Just making sure we have > > > thought of everything before we reach consensus > > > > I am sure thiat consensus will take a very long tiime on this one! We > > will probably have to talk about grotopological v6 adressing (as they > > are doing on the ARIN ppml) and a host of other issues. I reckon we > > ought to wait for shim6 to do their work as well. > > > > > because this PI discussion > > > is very important to ipv6. > > > > v. true. > > > > -- > > Cheers, > > > > McTim > > $ whois -h whois.afrinic.net mctim > > > > > > -- __--__-- > > > > Message: 2 > > Date: Tue, 29 Nov 2005 10:15:27 +1100 > > To: =?iso-8859-1?Q?J=F8rgen?= Hovland <jorgen(a)hovland.cx>, > > <address-policy-wg(a)ripe.net>, <ipv6-wg(a)ripe.net> > > From: Geoff Huston <gih(a)apnic.net> > > Subject: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix IPv6 > > > > At 03:37 AM 29/11/2005, J=F8rgen Hovland wrote: > > >----- Original Message ----- From: "Florian Weimer" <fw(a)deneb.enyo.de> > > >Sent: Saturday, November 26, 2005 4:00 PM > > > > > > > > >>* Jeroen Massar: > > >> > > >>>>1. Make /32 the only routable entity so we can use perfect match in > > >>>> the DFZ instead of longest-prefix match. > > >>> > > >>>What about the organizations that have say a /19, want them to inject > > >>>all their more specific /32's? > > >> > > >>You can inject a /19 as 8192 /32s. Shouldn't make a difference if the > > >>/19 is really used. > > >> > > >>At this stage, it's probably not too wise to embed the /32--/48--/64 > > >>in silicon, but vendors will undoubtedly do this if they can save a > > >>few bucks and current policies remain as inflexible as they are. > > > > > >Hi, > > >Perfect match is faster but far from better. What I think perhaps would > be= > > =20 > > >interesting to see in the future with regards to IPv6 and PI is the= > > following: > > > > > >1. No PI. _Only_ network operators get a prefix. > > >2. Customers of network operators can at any time change provider and > take= > > =20 > > >their assigned prefix with them. The new provider will announce it as a=20 > > >more specific overriding the aggregate. If the customer decides to get=20 > > >multiple providers, then the network operator with the /32 could also=20 > > >announce a more specific. > > > > > >In the country I live in I can change telecom provider and take my > phone=20 > > >number with me to the new provider. Why shouldn't I be able to do that=20 > > >with internet providers? > > >Yes, it will somehow create millions/billions of prefixes (atleasat > with=20 > > >todays routing technology/protocols). Network operators should be able to= > > =20 > > >handle that hence rule #1. > > > > > > Interesting - it will work for a while, and then you will get to the limit= > > =20 > > of deployed capability of routing. > > > > Then what? > > > > Geoff > > > > > > > > > > > > -- __--__-- > > > > Message: 3 > > From: Randy Bush <randy(a)psg.com> > > Date: Mon, 28 Nov 2005 21:49:17 -1000 > > To: Salman Asadullah <sasad(a)cisco.com> > > Cc: Roger Jorgensen <rogerj(a)jorgensen.no>, > > Oliver Bartels <oliver(a)bartels.de>, > > "ipv6-wg(a)ripe.net" <ipv6-wg(a)ripe.net>, > > "address-policy-wg(a)ripe.net" <address-policy-wg(a)ripe.net>, > > roger(a)jorgensen.no > > Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI > > > > > Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these real > > > issues for a good reason. > > > > i gather that the message that leslie daigle was given at the > > last nanog was not well-transmitted to the ietf. no big > > surprise. > > > > you may want to look at http://nanog.org/mtg-0510/real/ipv6-bof.ram > > > > randy > > > > > > -- __--__-- > > > > Message: 4 > > Date: Tue, 29 Nov 2005 10:13:39 +0100 > > From: Andre Oppermann <oppermann(a)networx.ch> > > To: Salman Asadullah <sasad(a)cisco.com> > > CC: Roger Jorgensen <rogerj(a)jorgensen.no>, > > Oliver Bartels <oliver(a)bartels.de>, > > "ipv6-wg(a)ripe.net" <ipv6-wg(a)ripe.net>, > > "address-policy-wg(a)ripe.net" <address-policy-wg(a)ripe.net>, > > roger(a)jorgensen.no > > Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI > > > > Salman Asadullah wrote: > > > > > > You seem to be far away from the ground realities. > > > > > > Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these real > > > issues for a good reason. > > > > Neither Multi6 nor SHIM6 are even in an draft RFC state yet and to be > > workable they'd have to be implemented on every end-host out there. > > That is every operating system in sufficient existence. That puts IPv6 > > even further in the already distant future considering common OS upgrade > > and replacement cycles. > > > > Second this doesn't solve the renumbering problem. Renumbering is not > > just giving hosts new IP addresses but alost managing DNS and Firewalls. > > No even remotely workable and scaleable solution has been presented yet. > > > > So nice try but no cookie. > > > > -- > > Andre > > > > > > > Regards, > > > Salman > > > > > > At 10:55 AM 11/25/2005 +0100, Roger Jorgensen wrote: > > > > > > > On Thu, 24 Nov 2005, Oliver Bartels wrote: > > > > > On Mon, 21 Nov 2005 17:10:10 +0100 (CET), Roger Jorgensen wrote: > > > > <snip> > > > > > If IPv4 offers PI = provider _independence_ and multihoming > > > > > and IPv6 doesn't, then IPv4 is obviously the better solution for > > > > > those who requires this functionallity. > > > > > > > > > > Thus they won't use IPv6. > > > > > > > > > > Please keep in mind: The _customer_ votes, not you, not me. > > > > > > > > > > And as the majority of the large and a significant portion of medium > > > > > size businesses are obviously not willing to accept an IP protocol > not > > > > > providing this functionallity, IPv6 will remain at it's current > status: > > > > > > > > > > A technical playground for technically interested people. > > > > > > > > a very true point in one way but that is again as I see it, we're still > > > > thinking IPv4 when talking IPv6. > > > > > > > > Why do they need multihoming and PI? They don't trust the ISP and > vendors > > > > to deliver them uptime and freedom... isn't this a problem the ISP and > > > > vendors should try to solve? Of course, the idea of easy renumbering > was > > > > suppose to solve this but again, we're thinking IPv4 so it's not easy > to > > > > understand. > > > > > > > > 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. > > > > > > > > > > > > > > > > <snip> > > > > > > > > > > Hmm, please let me translate: > > > > > "Even if the car doesn't drive and the engine doesn't deliver a > single > > > > > horse power at the wheels, drop the thought about driving, > > > > > start to think about other way to use the possibility this great car > > > > > gives us." > > > > > > > > > > Sound like newspeak: > > > > > If we _think_ we can't solve the problem, drop discussing the > problem. > > > > > > > > for several years this discussion have been going on, still no real > > > > solution. IPv6 give us the freedom todo ALOT of things, USE those > > > > possibilities, if we have to change how IP are done, some TCP headers > > etc, > > > > then do it... propose a good idea and prove it. That could give us > > > > multihoming. Actually there is a master thesis about howto create > > > > connectivity for TCP session even if one of the links went down, the > > > > session just used another IP (1)... the user don't notice anything > > > > either and it have zero problem working with standard tcp-stacks since > it > > > > use the extended header of IPv6. > > > > > > > > That's just ONE of many possible ways... > > > > > > > > > > > > > > > > (1) it's a master thesis writting by a student related to University of > > > > TromsÃ¸ as part of the Pasta project, www.pasta.cs.uit.no > > > > > > > > -- > > > > > > > > ------------------------------ > > > > Roger Jorgensen | > > > > rogerj(a)stud.cs.uit.no | - IPv6 is The Key! > > > > http://www.jorgensen.no | roger(a)jorgensen.no > > > > ------------------------------------------------------- > > > > > > > > > > End of ipv6-wg Digest > > > > > > > --__--__-- > > Message: 3 > From: Florian Weimer <fw(a)deneb.enyo.de> > To: Geoff Huston <gih(a)apnic.net> > Cc: =?iso-8859-1?Q?J=F8rgen?= Hovland <jorgen(a)hovland.cx>, > <address-policy-wg(a)ripe.net>, <ipv6-wg(a)ripe.net> > Subject: Re: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix IPv6 > Date: Tue, 29 Nov 2005 15:26:53 +0100 > > * 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. > > What's next? Do you plan to lobby Hollywood to reduce the number of > movies create per year, so that your customers have fewer of them to > download, and the capacity of your pipes is not exceeded? > > > --__--__-- > > Message: 4 > From: Randy Bush <randy(a)psg.com> > Date: Tue, 29 Nov 2005 06:17:54 -1000 > To: Per Heldal <heldal(a)eml.cc> > Cc: Salman Asadullah <sasad(a)cisco.com>, > ipv6-wg(a)ripe.net, > address-policy-wg(a)ripe.net > Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI > > >> Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these real > >> issues for a good reason. > > Regardless of the efforts, from a provider POV it's only "work in > > progress". > > one of the key points from the nanog session was that shim6 is the > *wrong* work in progress. what is needed is _site_ multi-homing, > not host multi-homing. > > randy > > > --__--__-- > > Message: 5 > Date: Wed, 30 Nov 2005 05:34:05 +1100 > To: Randy Bush <randy(a)psg.com>, Per Heldal <heldal(a)eml.cc> > From: Geoff Huston <gih(a)apnic.net> > Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI > Cc: Salman Asadullah <sasad(a)cisco.com>, ipv6-wg(a)ripe.net, > address-policy-wg(a)ripe.net > > At 03:17 AM 30/11/2005, Randy Bush wrote: > > >> Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these real > > >> issues for a good reason. > > > Regardless of the efforts, from a provider POV it's only "work in > > > progress". > > > >one of the key points from the nanog session was that shim6 is the > >*wrong* work in progress. what is needed is _site_ multi-homing, > >not host multi-homing. > > "wrong"? "right"? > > Usual response - if you believe that there is a better way of doing this > work through the issues here, then write up an approach, gather support, > get peer review etc etc. > > As I said at NANOG, part of the problem with distributed models where there > is action at a distance is to understand and clearly identify instances of > gratuitous packet header rewriting by hostile agents as compared to packet > rewriting by agents who believe that they are doing this in a friendly and > helpful fashion. This becomes a challenging problem,of course. > > I don't think any single approach today is the one true right approach at > this point, but unless we explore this space with some diligence, allow for > experimentation and keep an open mind on this work then you are going to > get intractably wedged between the desire for greater flexibility in the > use of addresses as a form of semi-persistent endpoint identifiers and the > desire for reduced flexibility in the use of addresses as forwarding tokens > in order to keep the routing space confined to readily computable dimensions. > > But of course _all_ this will be solved in MPLS - right? :-) > > Geoff > > > > > > --__--__-- > > Message: 6 > Date: Wed, 30 Nov 2005 05:36:11 +1100 > To: Florian Weimer <fw(a)deneb.enyo.de> > From: Geoff Huston <gih(a)apnic.net> > Subject: Re: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix > IPv6 > Cc: =?iso-8859-1?Q?J=F8rgen?= Hovland <jorgen(a)hovland.cx>, > <address-policy-wg(a)ripe.net>, <ipv6-wg(a)ripe.net> > > At 01:26 AM 30/11/2005, 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 what you are saying is that _I_ want address portability and _you_ have > to buy new routers. > > > Well that sure works for me! How's the chequebook feeling on your side? > > (I'm not convinced that you've selected the best of business models, as > there does appear to be a significant inconsistency going on in your model > in that cost and benefit are not related all that well.) > > Geoff > > > > --__--__-- > > Message: 7 > Date: Wed, 30 Nov 2005 06:01:56 +1100 > To: Andre Oppermann <oppermann(a)networx.ch>, Salman Asadullah > <sasad(a)cisco.com> > From: Geoff Huston <gih(a)apnic.net> > Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI > Cc: Roger Jorgensen <rogerj(a)jorgensen.no>, Oliver Bartels > <oliver(a)bartels.de>, > "ipv6-wg(a)ripe.net" <ipv6-wg(a)ripe.net>, > "address-policy-wg(a)ripe.net" <address-policy-wg(a)ripe.net>, > roger(a)jorgensen.no > > At 08:13 PM 29/11/2005, Andre Oppermann wrote: > >Salman Asadullah wrote: > > > > > > You seem to be far away from the ground realities. > > > > > > Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these real > > > issues for a good reason. > > > >Neither Multi6 nor SHIM6 are even in an draft RFC state yet > > Multi6 produced 5 WG drafts, all of which have been published as RFCs You > can (and probably should) read through RFCs 3582, 4116, 4177, 4219, and 4218 > > SHIM6 is working on the following drafts - again I would recommend that you > read though all of them:... > draft-ietf-shim6-app-refer, draft-ietf-shim6-applicability, > draft-ietf-shim6-arch, draft-ietf-shim6-failure-detection, > draft-ietf-shim6-hba, draft-ietf-shim6-proto, > and draft-ietf-shim6-reach-detect. > > > > and to be > >workable they'd have to be implemented on every end-host out there. > >That is every operating system in sufficient existence. That puts IPv6 > >even further in the already distant future considering common OS upgrade > >and replacement cycles. > > yep - any form of locator / identity split is such a basic shift in the > architectural model used by IP that changes to the stack are required. This > is the case in mobility, nomadism, ad-hoc networking and this form of > multi-homing. If you want agile locators and any form of persistence in > endpoint identifiers then you are not going to get that without changes to > the stack. Now if you are arguing that the deployed base of IPv6 is so > large that further changes are impossible in this particular technology due > to the inertia of the deployed IPv6 base, then that's certainly an > interesting perspective, and not one I've heard all that often so far. If > you are saying that this will take time to develop and deploy, then you are > probably right, and a model that can use incremental deployment using a > conventional initial context followed by a capability exchange to explore > if there is mutual support for this form of communication capability, then > you may well be onto something interesting. Although I'd hasten to add that > this is the approach being taken within the SHIM6 architecture. > > >Second this doesn't solve the renumbering problem. Renumbering is not > >just giving hosts new IP addresses but alost managing DNS and Firewalls. > >No even remotely workable and scaleable solution has been presented yet. > > I'm not sure I agree with you about the DNS and renumbering - its not a > clearly defined space, and the implications relating to the DNS are not > clearly understood in communication models where feasible locator sets are > dynamically exchanged rather than always loaded into third party rendezvous > points, as in the DNS model. > > > >So nice try but no cookie. > > Thank you, > > Geoff > > > > > > --__--__-- > > Message: 8 > Date: Wed, 30 Nov 2005 01:53:49 -0800 (PST) > From: "william(at)elan.net" <william(a)elan.net> > To: Geoff Huston <gih(a)apnic.net> > cc: Randy Bush <randy(a)psg.com>, Per Heldal <heldal(a)eml.cc>, > Salman Asadullah <sasad(a)cisco.com>, ipv6-wg(a)ripe.net, > address-policy-wg(a)ripe.net > Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI > > > On Wed, 30 Nov 2005, Geoff Huston wrote: > > > At 03:17 AM 30/11/2005, Randy Bush wrote: > >> >> Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these > >> real > >> >> issues for a good reason. > >> > Regardless of the efforts, from a provider POV it's only "work in > >> > progress". > >> > >> one of the key points from the nanog session was that shim6 is the > >> *wrong* work in progress. what is needed is _site_ multi-homing, > >> not host multi-homing. > > Yes, well if it goes forward, it may well end up being used for setting > up site-multihoming: > > http://www.ietf.org/mail-archive/web/architecture- discuss/current/msg00095.html > and will be seen as friendly and right solution (on what "friendly" and > "right" can mean seen below). > > > "wrong"? "right"? > > > > Usual response - if you believe that there is a better way of doing this > > work through the issues here, then write up an approach, gather support, > get > > peer review etc etc. > > > > As I said at NANOG, part of the problem with distributed models where there > > is action at a distance is to understand and clearly identify instances of > > gratuitous packet header rewriting by hostile agents as compared to packet > > rewriting by agents who believe that they are doing this in a friendly and > > helpful fashion. This becomes a challenging problem,of course. > > If its hostile or friendly behavior is in the eye of the beholder - but > in fact it may not even be only one side or the other for the same person. > > If I sit under a NAT and it prevents my application from running, I'm > hostile to that behavior. But same NAT box may well be protecting my > home network from intrusion and allowing me to have multiple computers > connected through the same dsl/cable/wireless connection, so I'd view > it as a friendly. Since most people don't notice its hostile behavior > (due to kind of applications they run) and all notice its friendly > behavior it will overall be seen as a friend and "right" solution. > > So is there better way to do it and without NAT? Of course there is - > have real firewall and have block of ips - but NAT is winning as a > business case because it can do those several friendly things well for > almost everyone and without dependence on network provider and those > few users who are inconvenienced and their application are viewed as > minor percentage and not a problem in the overall business case. > So business case won but IETF end-end tcp/ip architecture broken ... > > > I don't think any single approach today is the one true right approach at > > this point, but unless we explore this space with some diligence, > > Diligence is the right word. But is it really the size of the routing > table that we're being most concerned (considering #of routes in ipv6 > will most definitely be smaller then with ipv4 because of less > fragmentation - generally one ip block per ASN) or business case of > users who do not want to be dependent on IP provider and RIR to be > able to multihome? > > And should due diligence be applied so that proposed solution both > makes sense to do for those who will use it (i.e. small businesses > in case of shim6) an does not break applications when that is done? > > -- > William Leibzon > Elan Networks > william(a)elan.net > > > --__--__-- > > Message: 9 > From: Max Tulyev <president(a)ukraine.su> > To: ipv6-wg(a)ripe.net > Subject: Re: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix IPv6 > Date: Wed, 30 Nov 2005 13:33:52 +0300 > > Hi! > > > > 1. No PI. _Only_ network operators get a prefix. > > > > I am an operator of a network - do I get a prefix ? (we have lots of > > computers and need lots of IP addresses: currently the 5 PCs, 2 > > printers, a phone and some PDA and a server online) > > > > I guess you need to define the criteria in some other way. Perhaps > > beeing registered with the national regulator > > I'm looking at all of that and begin to think that all this discussion about > PI vs PA (and only [large] operators can get a prefix) is just for > implementing some unfair rules in ISP market. > > Wise customers wants to have PI because of to be multihoming and have stable > and really _provider_independent_ (i.e. not depending on upstream's faults) > connection. > Small operators wants to have PI because of LIR is often too expensive for > them. > > Large operators do NOT want PI because of they can hold a client with their > address space ("if you are going to change ISP - you will have a large > trouble with renumbering your network and changing domains" or even "if you > do not do ... - we will immediately shut down your connection"). Large > operators (can pay for LIR) do NOT want PI because of it makes the extra > money barrier to be an operator (LIR cost). > > See more on. Imagine there is no PI. If somebody really-really-really needs > to > be multihoming - he will be a LIR and do the LIR initial request (/20 PA for > IPv4 instead of /24 PI he really need for years). So in this case we do not > conserve one row of route table, but slightly loss in conserving space (/20 > instead of /24). > > Even more. Who is making the most noise about no PI? As I can see, large > operators. People who have enough powerful routers to not to think about > extra routes there. > > P.S. And please do not compare IP connectivity with global dynamic routing > (it > is a really BIG achievement of the Internet!) with PSTN and global static > routing where switching routes to certain number plan can take several > monthes. Of course, in PSTN we can't ever think about hot backup and upstream > reservation (multihoming). > > -- > WBR, > Max Tulyev (MT6561-RIPE, 2:463/253@FIDO) > > > > > End of ipv6-wg Digest >

1 0

unsubscibe jkuijer@dds.nl
by jkuijer＠dds.nl 29 Nov '05

29 Nov '05

Citeren ipv6-wg-request(a)ripe.net: > Send ipv6-wg mailing list submissions to > ipv6-wg(a)ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.ripe.net/mailman/listinfo/ipv6-wg > or, via email, send a message with subject or body 'help' to > ipv6-wg-request(a)ripe.net > > You can reach the person managing the list at > ipv6-wg-admin(a)ripe.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ipv6-wg digest..." > > > Today's Topics: > > 1. Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 (McTim) > 2. Re: [address-policy-wg] Re: Andre's guide to fix IPv6 (Geoff Huston) > 3. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Randy Bush) > 4. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Andre Oppermann) > > --__--__-- > > Message: 1 > Date: Tue, 29 Nov 2005 07:19:49 +0300 > From: McTim <dogwallah(a)gmail.com> > To: =?ISO-8859-1?Q?J=F8rgen_Hovland?= <jorgen(a)hovland.cx> > Subject: Re: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix IPv6 > Cc: ipv6-wg(a)ripe.net > > hiya, > > (removed address-policy-wg from the cc:) > > On 11/28/05, J=F8rgen Hovland <jorgen(a)hovland.cx> wrote: > > > > -----Original Message----- > > From: McTim [mailto:dogwallah@gmail.com] > > > > > >#2 sounds like PI to me. What have I missed? > > > > Hello McTim, > > You are correct. That's why I wrote PI in the email:-). > > I guess I misread the below wrong then ;-) > > J=F8rgen Hovland wrote: > > >> - > >> 1. No PI. _Only_ network operators get a prefix. > > > It is an attempt to suggest an alternative idea to the PI discussion. > > Don't get me wrong. I am for PI. This idea is perhaps a bit more > > hierarchical instead of the standard flat one. Just making sure we have > > thought of everything before we reach consensus > > I am sure thiat consensus will take a very long tiime on this one! We > will probably have to talk about grotopological v6 adressing (as they > are doing on the ARIN ppml) and a host of other issues. I reckon we > ought to wait for shim6 to do their work as well. > > > because this PI discussion > > is very important to ipv6. > > v. true. > > -- > Cheers, > > McTim > $ whois -h whois.afrinic.net mctim > > > --__--__-- > > Message: 2 > Date: Tue, 29 Nov 2005 10:15:27 +1100 > To: =?iso-8859-1?Q?J=F8rgen?= Hovland <jorgen(a)hovland.cx>, > <address-policy-wg(a)ripe.net>, <ipv6-wg(a)ripe.net> > From: Geoff Huston <gih(a)apnic.net> > Subject: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix IPv6 > > At 03:37 AM 29/11/2005, J=F8rgen Hovland wrote: > >----- Original Message ----- From: "Florian Weimer" <fw(a)deneb.enyo.de> > >Sent: Saturday, November 26, 2005 4:00 PM > > > > > >>* Jeroen Massar: > >> > >>>>1. Make /32 the only routable entity so we can use perfect match in > >>>> the DFZ instead of longest-prefix match. > >>> > >>>What about the organizations that have say a /19, want them to inject > >>>all their more specific /32's? > >> > >>You can inject a /19 as 8192 /32s. Shouldn't make a difference if the > >>/19 is really used. > >> > >>At this stage, it's probably not too wise to embed the /32--/48--/64 > >>in silicon, but vendors will undoubtedly do this if they can save a > >>few bucks and current policies remain as inflexible as they are. > > > >Hi, > >Perfect match is faster but far from better. What I think perhaps would be= > =20 > >interesting to see in the future with regards to IPv6 and PI is the= > following: > > > >1. No PI. _Only_ network operators get a prefix. > >2. Customers of network operators can at any time change provider and take= > =20 > >their assigned prefix with them. The new provider will announce it as a=20 > >more specific overriding the aggregate. If the customer decides to get=20 > >multiple providers, then the network operator with the /32 could also=20 > >announce a more specific. > > > >In the country I live in I can change telecom provider and take my phone=20 > >number with me to the new provider. Why shouldn't I be able to do that=20 > >with internet providers? > >Yes, it will somehow create millions/billions of prefixes (atleasat with=20 > >todays routing technology/protocols). Network operators should be able to= > =20 > >handle that hence rule #1. > > > Interesting - it will work for a while, and then you will get to the limit= > =20 > of deployed capability of routing. > > Then what? > > Geoff > > > > > > --__--__-- > > Message: 3 > From: Randy Bush <randy(a)psg.com> > Date: Mon, 28 Nov 2005 21:49:17 -1000 > To: Salman Asadullah <sasad(a)cisco.com> > Cc: Roger Jorgensen <rogerj(a)jorgensen.no>, > Oliver Bartels <oliver(a)bartels.de>, > "ipv6-wg(a)ripe.net" <ipv6-wg(a)ripe.net>, > "address-policy-wg(a)ripe.net" <address-policy-wg(a)ripe.net>, > roger(a)jorgensen.no > Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI > > > Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these real > > issues for a good reason. > > i gather that the message that leslie daigle was given at the > last nanog was not well-transmitted to the ietf. no big > surprise. > > you may want to look at http://nanog.org/mtg-0510/real/ipv6-bof.ram > > randy > > > --__--__-- > > Message: 4 > Date: Tue, 29 Nov 2005 10:13:39 +0100 > From: Andre Oppermann <oppermann(a)networx.ch> > To: Salman Asadullah <sasad(a)cisco.com> > CC: Roger Jorgensen <rogerj(a)jorgensen.no>, > Oliver Bartels <oliver(a)bartels.de>, > "ipv6-wg(a)ripe.net" <ipv6-wg(a)ripe.net>, > "address-policy-wg(a)ripe.net" <address-policy-wg(a)ripe.net>, > roger(a)jorgensen.no > Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI > > Salman Asadullah wrote: > > > > You seem to be far away from the ground realities. > > > > Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these real > > issues for a good reason. > > Neither Multi6 nor SHIM6 are even in an draft RFC state yet and to be > workable they'd have to be implemented on every end-host out there. > That is every operating system in sufficient existence. That puts IPv6 > even further in the already distant future considering common OS upgrade > and replacement cycles. > > Second this doesn't solve the renumbering problem. Renumbering is not > just giving hosts new IP addresses but alost managing DNS and Firewalls. > No even remotely workable and scaleable solution has been presented yet. > > So nice try but no cookie. > > -- > Andre > > > > Regards, > > Salman > > > > At 10:55 AM 11/25/2005 +0100, Roger Jorgensen wrote: > > > > > On Thu, 24 Nov 2005, Oliver Bartels wrote: > > > > On Mon, 21 Nov 2005 17:10:10 +0100 (CET), Roger Jorgensen wrote: > > > <snip> > > > > If IPv4 offers PI = provider _independence_ and multihoming > > > > and IPv6 doesn't, then IPv4 is obviously the better solution for > > > > those who requires this functionallity. > > > > > > > > Thus they won't use IPv6. > > > > > > > > Please keep in mind: The _customer_ votes, not you, not me. > > > > > > > > And as the majority of the large and a significant portion of medium > > > > size businesses are obviously not willing to accept an IP protocol not > > > > providing this functionallity, IPv6 will remain at it's current status: > > > > > > > > A technical playground for technically interested people. > > > > > > a very true point in one way but that is again as I see it, we're still > > > thinking IPv4 when talking IPv6. > > > > > > Why do they need multihoming and PI? They don't trust the ISP and vendors > > > to deliver them uptime and freedom... isn't this a problem the ISP and > > > vendors should try to solve? Of course, the idea of easy renumbering was > > > suppose to solve this but again, we're thinking IPv4 so it's not easy to > > > understand. > > > > > > 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. > > > > > > > > > > > > <snip> > > > > > > > > Hmm, please let me translate: > > > > "Even if the car doesn't drive and the engine doesn't deliver a single > > > > horse power at the wheels, drop the thought about driving, > > > > start to think about other way to use the possibility this great car > > > > gives us." > > > > > > > > Sound like newspeak: > > > > If we _think_ we can't solve the problem, drop discussing the problem. > > > > > > for several years this discussion have been going on, still no real > > > solution. IPv6 give us the freedom todo ALOT of things, USE those > > > possibilities, if we have to change how IP are done, some TCP headers > etc, > > > then do it... propose a good idea and prove it. That could give us > > > multihoming. Actually there is a master thesis about howto create > > > connectivity for TCP session even if one of the links went down, the > > > session just used another IP (1)... the user don't notice anything > > > either and it have zero problem working with standard tcp-stacks since it > > > use the extended header of IPv6. > > > > > > That's just ONE of many possible ways... > > > > > > > > > > > > (1) it's a master thesis writting by a student related to University of > > > TromsÃ¸ as part of the Pasta project, www.pasta.cs.uit.no > > > > > > -- > > > > > > ------------------------------ > > > Roger Jorgensen | > > > rogerj(a)stud.cs.uit.no | - IPv6 is The Key! > > > http://www.jorgensen.no | roger(a)jorgensen.no > > > ------------------------------------------------------- > > > > > End of ipv6-wg Digest >

1 0

Re: "Special Application Addresses" (Was: Re: [ipv6-wg] RE: address-policy-wg (ipv6-wg digest, Vol 1 #271 - 11 msgs))
by Jeroen Massar 26 Nov '05

26 Nov '05

peter.sherbin(a)bell.ca wrote: > Jeroen, thanks for your response. > >>> The application has to: >>> 1. avoid renumbering of the network >> Why? Your application should be able to use renumber easily using a form >> of management interface. > > I am using addresses to monitor my devices all the way through their > life cycle. In some cases it could be a physical life cycle from a few > weeks to a few years. I may also aggregate individual items to larger > sub groups. That is why I do not want any changes to static addresses > for unspecified time. The solution for the above can easily be solved by using DNS or a myriad of other solutions. Either you give all those devices a DNS label where they can contact their 'report server' or you give those devices the ability to register to that server. There are many possibilities here and none of these require any specific address space. I suggest you check out mail spam bots and viruses. They implement this all too perfectly well. <SNIP> >> PS: You might want to delete unused parts of emails, sending 27kb of >> quoted email which you don't reference is useless. Also changing the >> subject helps identifying what you are actually mailing about. > > It is a learning curve. will do next time. thanks for pointing this out. I suggest you also read the following article: http://www.xs4all.nl/~hanb/documents/quotingguide.html (Lines 80 chars and more are not very readable either) Greets, Jeroen

1 0

RE: address-policy-wg (ipv6-wg digest, Vol 1 #271 - 11 msgs)
by peter.sherbin＠bell.ca 25 Nov '05

25 Nov '05

>Oliver Bartels: >If IPv4 offers PI = provider _independence_ and multihoming >and IPv6 doesn't, then IPv4 is obviously the better solution for >those who requires this functionallity. > >Thus they won't use IPv6. > >Please keep in mind: The _customer_ votes, not you, not me. > >And as the majority of the large and a significant portion of medium >size businesses are obviously not willing to accept an IP protocol not >providing this functionallity, IPv6 will remain at it's current status: > >A technical playground for technically interested people. My project requires a few millions of IPv6 addresses. The application has to: 1. avoid renumbering of the network 2. keep allocated addresses for an extended period of time Current ARIN allocation schema: ARIN -> LIR -> End User does not make much sence because to get addresses I: - either have to become a LIR, which I may not necessarily want, or - the entire application depends on fortunes of a third party (LIR), which is a prohibitive risk factor for the investment On the other side I am willing to "rent" addresses from a registry (ARIN) and return the allocation when it is no longer needed. Now, how do we change the current address allocation policy which kills IPv6 in its cradle? Thank you, Peter Sherbin 416 353-5917 >-----Original Message----- >From: ipv6-wg-admin(a)ripe.net [mailto:ipv6-wg-admin@ripe.net] On Behalf Of ipv6- >wg-request(a)ripe.net >Sent: November/25/ 2005 06:00 >To: ipv6-wg(a)ripe.net >Subject: ipv6-wg digest, Vol 1 #271 - 11 msgs > >Send ipv6-wg mailing list submissions to > ipv6-wg(a)ripe.net > >To subscribe or unsubscribe via the World Wide Web, visit > http://www.ripe.net/mailman/listinfo/ipv6-wg >or, via email, send a message with subject or body 'help' to > ipv6-wg-request(a)ripe.net > >You can reach the person managing the list at > ipv6-wg-admin(a)ripe.net > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of ipv6-wg digest..." > > >Today's Topics: > > 1. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Florian Weimer) > 2. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Oliver Bartels) > 3. closed network and need for global uniqe IP space (Roger Jorgensen) > 4. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Roger Jorgensen) > 5. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Roger Jorgensen) > 6. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Andre Oppermann) > 7. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Andre Oppermann) > 8. Re: closed network and need for global uniqe IP space (Gert Doering) > 9. Re: [address-policy-wg] Re: [ipv6-wg] closed network and need for > globa l uniqe IP space (Roger Jorgensen) > 10. Re: [address-policy-wg] Re: [ipv6-wg] closed network and need for globa l >uniqe IP space (Gert Doering) > >--__--__-- > >Message: 1 >From: Florian Weimer <fw(a)deneb.enyo.de> >To: Roger Jorgensen <rogerj(a)jorgensen.no> >Cc: Lea Roberts <lea.roberts(a)stanford.edu>, address-policy-wg(a)ripe.net, ipv6- >wg(a)ripe.net, roger(a)jorgensen.no >Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI >Date: Thu, 24 Nov 2005 18:58:04 +0100 > >* Roger Jorgensen: > >> Can't we all just drop using the word multihoming and IPv6 PI? >> They all reflect back to how thing was done with IPv4 and those ways are >> doomed to fail with IPv6 simply due to the size of the IP space. > >I'm a relative newcomer to this area. Could you give a pointer to >some explanation *why* the IPv6 address space size causes this >problem? > > >--__--__-- > >Message: 2 >From: "Oliver Bartels" <oliver(a)bartels.de> >To: "ipv6-wg(a)ripe.net" <ipv6-wg(a)ripe.net>, > "address-policy-wg(a)ripe.net" <address-policy-wg(a)ripe.net>, > "Roger Jorgensen" <rogerj(a)jorgensen.no> >Date: Thu, 24 Nov 2005 19:22:24 +0100 >Reply-To: "Oliver Bartels" <oliver(a)bartels.de> >Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI > >On Mon, 21 Nov 2005 17:10:10 +0100 (CET), Roger Jorgensen wrote: >>Can't we all just drop using the word multihoming and IPv6 PI? > >The better solution is the enemy of the good solution. > >If IPv4 offers PI = provider _independence_ and multihoming >and IPv6 doesn't, then IPv4 is obviously the better solution for >those who requires this functionallity. > >Thus they won't use IPv6. > >Please keep in mind: The _customer_ votes, not you, not me. > >And as the majority of the large and a significant portion of medium >size businesses are obviously not willing to accept an IP protocol not >providing this functionallity, IPv6 will remain at it's current status: > >A technical playground for technically interested people. > >>They all reflect back to how thing was done with IPv4 and those ways are >>doomed to fail with IPv6 simply due to the size of the IP space. > >Could you please explain this a bit more in detail ? >To me this sounds like "engines will never fly". > >>Last I checked around there were some promissing new proposal on the >>way for how to solve this very basic problem. > >Could you please be a bit more verbose. > >>And in the meantime, drop >>the thought about multihoming and PI space, start to think about other >>ways to use the possibility IPv6 give us. > >Hmm, please let me translate: >"Even if the car doesn't drive and the engine doesn't deliver a single >horse power at the wheels, drop the thought about driving, >start to think about other way to use the possibility this great car >gives us." > >Sound like newspeak: >If we _think_ we can't solve the problem, drop discussing the problem. > >Best Regards >Oliver > > > >Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany >oliver(a)bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 > > > > > >--__--__-- > >Message: 3 >Date: Fri, 25 Nov 2005 10:12:35 +0100 (CET) >From: Roger Jorgensen <rogerj(a)jorgensen.no> >To: ipv6-wg(a)ripe.net, address-policy-wg(a)ripe.net >cc: roger(a)jorgensen.no >Subject: [ipv6-wg] closed network and need for global uniqe IP space > >Sorry for cross-posting but not sure where it really belong... >----------- > >Hi, > >First, the question is more, what is the correct way of dealing with >situation like this? > > > > >I work for a entity with a big and closed network where security and >being closed came first. We're not governement but we have our mandate >defined by them. >Our only connection to Internet are through several uplinks with few >public IP where we run proxy solution for the little traffic that are >allowed to hit internet. Are in reality no incoming routes to us, and none >out. >Internal we use RFC1918 IP space,(private IP) and we for now have enough >IP space but we are experience conflicts between IP space when connecting >to other big closed network. Not to forget the size, we will probably run >out of IP space to... (and I know others have run out of RFC1918 space on >their internal network) > > >Most would suggest request a /48 or bigger from your uplink right now and >that's not going to work for several reasons: >* size, just one of bigger sites connected probably need more than a /48 >just for themself, and we have several of them, and alot of smaller >sites/network. We're probably talking /32 or more if I have to guess. > >* scalability, we could of course get /48 and break the /64 boundary, >a thought I seriously hate. But that will give us other kind of problems, >sites needing a /64 or more due to some equipment or so... > >* there are other BIGGER network of the same type. > >* control over who is using what IP and where etc... as said above, >security and being closed are probably the two most important factors for >us. > >* need global unique IP's since we're connecting to other network of the >same type, and NAT are not really the way we want to go with IPv6 > >... and probably more I can't remember right now. > > >The solutions aren't really that tricky but let me mention a few >options... >* Site local would have solved our problem BUT it's obsolite, quite >stupid really. > >* just take a prefix and use it... this will give us problem in the future >due to not being unique. > >* extensiv usage of NAT, eh do we really want to even consider THAT for >IPv6? > >* become LIR and request the needed IP space. > >* let one of our uplinks request the IP space for us. > > > >I'm in favour of the last two options, any of them... and they are as I >see it the really two options as things are now. Any thoughts? comments? > > > >-- > >------------------------------ >Roger Jorgensen | >rogerj(a)stud.cs.uit.no | - IPv6 is The Key! >http://www.jorgensen.no | roger(a)jorgensen.no >------------------------------------------------------- > > >--__--__-- > >Message: 4 >Date: Fri, 25 Nov 2005 10:36:25 +0100 (CET) >From: Roger Jorgensen <rogerj(a)jorgensen.no> >To: Florian Weimer <fw(a)deneb.enyo.de> >cc: address-policy-wg(a)ripe.net, ipv6-wg(a)ripe.net, roger(a)jorgensen.no >Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI > >On Thu, 24 Nov 2005, Florian Weimer wrote: >> * Roger Jorgensen: >> >> > Can't we all just drop using the word multihoming and IPv6 PI? >> > They all reflect back to how thing was done with IPv4 and those ways are >> > doomed to fail with IPv6 simply due to the size of the IP space. >> >> I'm a relative newcomer to this area. Could you give a pointer to >> some explanation *why* the IPv6 address space size causes this >> problem? > >Just do the math yourself and consider all possibilities and how the IPv4 >space are used... but some numbers > >- the address space is 128bit. >- we have a 64bits host prefix at the lower end. >- the above give us 64bits of network numbers, that's quite a few billions >of networks. BUT >- the /48 boundary leaving us with a usable globaly network space of 48bit >- from the 48bits only a /8 are usable as it is now, the other 7 /8 are >reserved for the future. > >The absolute max global routing table would by this be 40bits, of >course the real one are alot smaller. That one is closer to 32bits, and >that is STILL A huge number, probably more close to 20bits of entries. > > > >a last comment: the entire idea behind /64 and /48 will cause IPv6 to fail >as it is now. Odd as it is, we don't have enough IP space in IPv6. Sure it >will last 10, maybe 15-20 years, but that did IPv4 to...... > > > >-- > >------------------------------ >Roger Jorgensen | >rogerj(a)stud.cs.uit.no | - IPv6 is The Key! >http://www.jorgensen.no | roger(a)jorgensen.no >------------------------------------------------------- > > >--__--__-- > >Message: 5 >Date: Fri, 25 Nov 2005 10:55:54 +0100 (CET) >From: Roger Jorgensen <rogerj(a)jorgensen.no> >To: Oliver Bartels <oliver(a)bartels.de> >cc: "ipv6-wg(a)ripe.net" <ipv6-wg(a)ripe.net>, > "address-policy-wg(a)ripe.net" <address-policy-wg(a)ripe.net>, > roger(a)jorgensen.no >Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI > >On Thu, 24 Nov 2005, Oliver Bartels wrote: >> On Mon, 21 Nov 2005 17:10:10 +0100 (CET), Roger Jorgensen wrote: ><snip> >> If IPv4 offers PI = provider _independence_ and multihoming >> and IPv6 doesn't, then IPv4 is obviously the better solution for >> those who requires this functionallity. >> >> Thus they won't use IPv6. >> >> Please keep in mind: The _customer_ votes, not you, not me. >> >> And as the majority of the large and a significant portion of medium >> size businesses are obviously not willing to accept an IP protocol not >> providing this functionallity, IPv6 will remain at it's current status: >> >> A technical playground for technically interested people. > >a very true point in one way but that is again as I see it, we're still >thinking IPv4 when talking IPv6. > >Why do they need multihoming and PI? They don't trust the ISP and vendors >to deliver them uptime and freedom... isn't this a problem the ISP and >vendors should try to solve? Of course, the idea of easy renumbering was >suppose to solve this but again, we're thinking IPv4 so it's not easy to >understand. > >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. > > > ><snip> >> >> Hmm, please let me translate: >> "Even if the car doesn't drive and the engine doesn't deliver a single >> horse power at the wheels, drop the thought about driving, >> start to think about other way to use the possibility this great car >> gives us." >> >> Sound like newspeak: >> If we _think_ we can't solve the problem, drop discussing the problem. > >for several years this discussion have been going on, still no real >solution. IPv6 give us the freedom todo ALOT of things, USE those >possibilities, if we have to change how IP are done, some TCP headers etc, >then do it... propose a good idea and prove it. That could give us >multihoming. Actually there is a master thesis about howto create >connectivity for TCP session even if one of the links went down, the >session just used another IP (1)... the user don't notice anything >either and it have zero problem working with standard tcp-stacks since it >use the extended header of IPv6. > >That's just ONE of many possible ways... > > > >(1) it's a master thesis writting by a student related to University of >TromsÃ¸ as part of the Pasta project, www.pasta.cs.uit.no > >-- > >------------------------------ >Roger Jorgensen | >rogerj(a)stud.cs.uit.no | - IPv6 is The Key! >http://www.jorgensen.no | roger(a)jorgensen.no >------------------------------------------------------- > > >--__--__-- > >Message: 6 >Date: Fri, 25 Nov 2005 10:58:43 +0100 >From: Andre Oppermann <oppermann(a)networx.ch> >To: Roger Jorgensen <rogerj(a)jorgensen.no> >CC: Florian Weimer <fw(a)deneb.enyo.de>, address-policy-wg(a)ripe.net, > ipv6-wg(a)ripe.net, roger(a)jorgensen.no >Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI > >Roger Jorgensen wrote: >> >> On Thu, 24 Nov 2005, Florian Weimer wrote: >> > * Roger Jorgensen: >> > >> > > Can't we all just drop using the word multihoming and IPv6 PI? >> > > They all reflect back to how thing was done with IPv4 and those ways are >> > > doomed to fail with IPv6 simply due to the size of the IP space. >> > >> > I'm a relative newcomer to this area. Could you give a pointer to >> > some explanation *why* the IPv6 address space size causes this >> > problem? >> >> Just do the math yourself and consider all possibilities and how the IPv4 >> space are used... but some numbers >> >> - the address space is 128bit. >> - we have a 64bits host prefix at the lower end. >> - the above give us 64bits of network numbers, that's quite a few billions >> of networks. BUT >> - the /48 boundary leaving us with a usable globaly network space of 48bit >> - from the 48bits only a /8 are usable as it is now, the other 7 /8 are >> reserved for the future. >> >> The absolute max global routing table would by this be 40bits, of >> course the real one are alot smaller. That one is closer to 32bits, and >> that is STILL A huge number, probably more close to 20bits of entries. >> >> a last comment: the entire idea behind /64 and /48 will cause IPv6 to fail >> as it is now. Odd as it is, we don't have enough IP space in IPv6. Sure it >> will last 10, maybe 15-20 years, but that did IPv4 to...... > >You post is still pretty content-free. You're waving with your hand >but what do you propose exactly? I've posted my proposals under "Andre's >guide to fix IPv6". When do you with yours? > >-- >Andre > > >--__--__-- > >Message: 7 >Date: Fri, 25 Nov 2005 11:02:45 +0100 >From: Andre Oppermann <oppermann(a)networx.ch> >To: Roger Jorgensen <rogerj(a)jorgensen.no> >CC: Oliver Bartels <oliver(a)bartels.de>, > "ipv6-wg(a)ripe.net" <ipv6-wg(a)ripe.net>, > "address-policy-wg(a)ripe.net" <address-policy-wg(a)ripe.net>, > roger(a)jorgensen.no >Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI > >Roger Jorgensen wrote: >> >> On Thu, 24 Nov 2005, Oliver Bartels wrote: >> > On Mon, 21 Nov 2005 17:10:10 +0100 (CET), Roger Jorgensen wrote: >> <snip> >> > If IPv4 offers PI = provider _independence_ and multihoming >> > and IPv6 doesn't, then IPv4 is obviously the better solution for >> > those who requires this functionallity. >> > >> > Thus they won't use IPv6. >> > >> > Please keep in mind: The _customer_ votes, not you, not me. >> > >> > And as the majority of the large and a significant portion of medium >> > size businesses are obviously not willing to accept an IP protocol not >> > providing this functionallity, IPv6 will remain at it's current status: >> > >> > A technical playground for technically interested people. >> >> a very true point in one way but that is again as I see it, we're still >> thinking IPv4 when talking IPv6. > >We're thinking Real World(TM). > >> Why do they need multihoming and PI? They don't trust the ISP and vendors >> to deliver them uptime and freedom... isn't this a problem the ISP and >> vendors should try to solve? Of course, the idea of easy renumbering was >> suppose to solve this but again, we're thinking IPv4 so it's not easy to >> understand. >> >> 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. > >That's only part of the reasoning. Customers don't want to be locked >in to any one ISP. They want to have bargaining power which only comes >with the ability to switch ISPs at will. > >> <snip> >> > >> > Hmm, please let me translate: >> > "Even if the car doesn't drive and the engine doesn't deliver a single >> > horse power at the wheels, drop the thought about driving, >> > start to think about other way to use the possibility this great car >> > gives us." >> > >> > Sound like newspeak: >> > If we _think_ we can't solve the problem, drop discussing the problem. >> >> for several years this discussion have been going on, still no real >> solution. IPv6 give us the freedom todo ALOT of things, USE those >> possibilities, if we have to change how IP are done, some TCP headers etc, >> then do it... propose a good idea and prove it. That could give us >> multihoming. Actually there is a master thesis about howto create >> connectivity for TCP session even if one of the links went down, the >> session just used another IP (1)... the user don't notice anything >> either and it have zero problem working with standard tcp-stacks since it >> use the extended header of IPv6. > >Yea, that's known as SCTP. > >> That's just ONE of many possible ways... > >You're only handwaiving and saying "no". We are looking for ways to fit >IPv6 to the reality of how millions of people and corporations use and >want to use the Internet, technically and commercially. > >-- >Andre > > >--__--__-- > >Message: 8 >Date: Fri, 25 Nov 2005 11:18:46 +0100 >From: Gert Doering <gert(a)space.net> >To: Roger Jorgensen <rogerj(a)jorgensen.no> >Cc: ipv6-wg(a)ripe.net, address-policy-wg(a)ripe.net, roger(a)jorgensen.no >Subject: Re: [ipv6-wg] closed network and need for global uniqe IP space > >Hi, > >On Fri, Nov 25, 2005 at 10:12:35AM +0100, Roger Jorgensen wrote: >> The solutions aren't really that tricky but let me mention a few >> options... >> * Site local would have solved our problem BUT it's obsolite, quite >> stupid really. > >That's why there are ULA ("unique local addresses") now. They should >fit your needs pretty well - as much addresses as you want, and the >guarantee to be not officially assigned to anyone. > >Gert Doering > -- NetMaster >-- >Total number of prefixes smaller than registry allocations: 81421 > >SpaceNet AG Mail: netmaster(a)Space.Net >Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 >D- 80807 Muenchen Fax : +49-89-32356-234 > > >--__--__-- > >Message: 9 >Date: Fri, 25 Nov 2005 11:25:07 +0100 (CET) >From: Roger Jorgensen <rogerj(a)jorgensen.no> >To: Gert Doering <gert(a)space.net> >cc: ipv6-wg(a)ripe.net, address-policy-wg(a)ripe.net, roger(a)jorgensen.no >Subject: Re: [address-policy-wg] Re: [ipv6-wg] closed network and need for > globa l uniqe IP space > >On Fri, 25 Nov 2005, Gert Doering wrote: >> Hi, >> >> On Fri, Nov 25, 2005 at 10:12:35AM +0100, Roger Jorgensen wrote: >> > The solutions aren't really that tricky but let me mention a few >> > options... >> > * Site local would have solved our problem BUT it's obsolite, quite >> > stupid really. >> >> That's why there are ULA ("unique local addresses") now. They should >> fit your needs pretty well - as much addresses as you want, and the >> guarantee to be not officially assigned to anyone. > >what about the other part about globaly unique when we connect to other >network of the same type? > > > >-- > > >------------------------------ >Roger Jorgensen | >rogerj(a)stud.cs.uit.no | - IPv6 is The Key! >http://www.jorgensen.no | roger(a)jorgensen.no >------------------------------------------------------- > > >--__--__-- > >Message: 10 >Date: Fri, 25 Nov 2005 11:38:44 +0100 >From: Gert Doering <gert(a)space.net> >To: Roger Jorgensen <rogerj(a)jorgensen.no> >Cc: Gert Doering <gert(a)space.net>, ipv6-wg(a)ripe.net, > address-policy-wg(a)ripe.net, roger(a)jorgensen.no >Subject: Re: [address-policy-wg] Re: [ipv6-wg] closed network and need for globa > l uniqe IP space > >Hi, > >On Fri, Nov 25, 2005 at 11:25:07AM +0100, Roger Jorgensen wrote: >> > On Fri, Nov 25, 2005 at 10:12:35AM +0100, Roger Jorgensen wrote: >> > > The solutions aren't really that tricky but let me mention a few >> > > options... >> > > * Site local would have solved our problem BUT it's obsolite, quite >> > > stupid really. >> > >> > That's why there are ULA ("unique local addresses") now. They should >> > fit your needs pretty well - as much addresses as you want, and the >> > guarantee to be not officially assigned to anyone. >> >> what about the other part about globaly unique when we connect to other >> network of the same type? > >The idea is that ULAs are random-generated in a way that makes it "fairly >unlikely" that you end up in an address collision. But there is no >guarantee, of course. > >There is also a second sort of ULAs that are globally unique but still >private, but as far as I know, there is no registry yet that will hand >them out. So these can't be used yet. > >Gert Doering > -- NetMaster >-- >Total number of prefixes smaller than registry allocations: 81421 > >SpaceNet AG Mail: netmaster(a)Space.Net >Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 >D- 80807 Muenchen Fax : +49-89-32356-234 > > > > >End of ipv6-wg Digest

2 1

RE: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or so mething else?
by Koepp, Karsten 23 Nov '05

23 Nov '05

Hi all, I also followed the discussion, not stepping in here because of no background in TLD operations. Getting a bit frustrated as I see NO movement here. Unlike others, I do see dns being _critical_ to the infrastructure. No other protocol is that much subject of political discussions. As an operator being dependent on TLD operations I want to see a stable operations of the dns tree. Consequently I support giving the TLD operators the tools they need to make it a stable service. I have read an _expressed need_ of the tld community for anycast where I have not seen any constructive proposal against. Hence I have to ACCEPT that large TLDs need it. It brings us no step further towards a stable dns chain if we deny this. What is the impact onto my network if I accept to grant special resources to this need? I can see hardly any besides at most 200 prefixes polluting the DFZ. I can question whether the anycast allocations should be /32 or /48 or something else. It doesn't make a difference in terms of resources stressing my network provided I have a finite number of objects here. Operationally I believe /32 assignments are more stable, so I tend handing out /32 to TLD operators. Current policy does not allow to allocate routeable blocks to TLDs, so we have to change the policy. Before you start flaming I do not regard this opening the flooding gates, as I don't see the flood. TLD operators are being defined as critical infrastructure. It can be decided case by case to allow further infrastructure - by the RIPE members, but I haven't seen such case yet. Let it be xyz.com, have they ever claimed a need for themselves? regards Karsten > -----Original Message----- > From: Mohsen Souissi [mailto:Mohsen.Souissi@nic.fr] > Sent: Thursday, November 17, 2005 11:51 AM > To: Florian Weimer > Cc: address-policy-wg(a)ripe.net; ipv6-wg(a)ripe.net > Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 micro > allocation or > something else? > > > Florian & all, > > On 16 Nov, Florian Weimer wrote: > [...] > | It depends on the PI criteria. If slots in the global > routing tables > | are kept in short supply *and* you get at most one if you aren't an > | ISP *and* you need to do IPv6 anycast, you might have a problem > | because you need two globally visible prefixes (one for your > | production network, one for anycast). > | > | But I think you are right that it makes sense to resolve > the PI first, > | either negatively or positively. > > ==> This is just amazing! I have been follwing this topic for more > than two years and I have the feeling that we are making again and > again the history! I remember that when the IPv6 "PI" issue was first > raised in the IPv6/LIR wgs ("LIR" was the old name for "AP" at that > time), the answer was "PI is out of scope of this wg". Then came the > first draft proposel of Andreas in the AP wg asking for a /32 for > ccTLDs wishing to deploy anycast. At that time, the wg said "let's not > talk about "PI", which is still out of scope of this wg. Let's rather > talk about specific needs of TLDs wishing to do anycast and see what > we can do for them in termes of (micro-)allocation." > > Now, I'm surprised that we are going back to the original issue and > asking to first solve the PI problem... > > If that's to be done and while we ar at it, we can see again how RIPE > is the only RIR not considering TLD networks as "critical > infrastructure" while an appropriate policy has been already > implemented in all other existing RIRs for a long while (please > revisit the comparative matrix of RIR policies at > http://www.ripe.net/info/resource-admin/rir-comp-matrix-rev.html and > see how RIPE is lagging behind in this matter. Some of this > mailing-list member would say: "that was our choice!"). Isn't it a > European speciality to discuss over again and again issues without > coming to any solution? Some people on RIPE mailing-lists are now > used to coming after a consensus is almost reached and try to break > everything just for the sake of building CLEAN solutions... > > (cc)TLD need an allocation (whether it is a /32 or whatever "routable > prefix") because they need to do anycast, full stop. To recall only a > few of the arguments for deploying anycast for a TLD, I would say: > Redundance & Resilience against DDoS attacks, better global time > response, a greater flexibility in adding and removing name servers > without notifying IANA! > > Btw, I'd like to remind some of this mailing-list readers that the > request of DENIC is not isolated since AFNIC asked even before > Adndreas first draft for a constency between all RIRs in the way IPv6 > allocation were made for "critical infrastructure". AFNIC has then > strongly supported Andreas proposal from the beginning and hoped that > the solution would come rapidly because AFNIC is still needing such a > solution to start deploying anycast in IPv4 AND in IPv6 in a > consistent way! > > I still hope this debate will lead to a concrete solution within the > coming 3 years! > > Good luck :-) > > Mohsen. > >

6 5

Re: [ipv6-wg] Re: 200 customer requirements for IPv6
by Thomas Narten 18 Nov '05

18 Nov '05

Daniel Roesen <dr(a)cluenet.de> writes: > The folks all having their own /32 already allocated to them and > trying to limit independent address space to "service providers" (or > those who manage to pretend being it, which seems to be easy) are > still arguing for "not for them!" paradigm - easy position with > having their own dishes already done. With all due respect, these sorts of comments are not helpful. They imply bad motivations on some, that IMO, are simply false. There are (IMO) valid reasons for not giving out /32s to everyone. The original (and still compelling, IMO) rational behind the current policy is to ensure good aggregation for the long term, in order to keep the number of distinct prefixes in the DFZ manageable. Hence, the current policy is oriented not towards _all_ ISPs, but those who will (hopefully) have _many_ customers that they assign addresses too. That is, they aggregate addresses for _many_ customers. That is where the "plan for 200 customers" wording originally came from. The presumption is that an ISP/LIR that realistically expects to have 200 customers will be aggregating _many_ customer addresses. If an ISP will have (say) only 100 customers long term, its not at all clear that they will be aggregating significant amounts of address space. Note, I'm not defending the the "200 customer" rule per se; I understand that it is viewed as problematic. But I think the motivation that led to it is still valid, and when folk say "get rid of this requirement," I object to "forgetting" about the original concern when coming up with a replacement policy. > Until we have a clear full replacement (that means a solution which does > NOT ignore real requirements like shim6 does) there should be a very > simple PI policy which issues a /48 or whatever to end sites at a > nominal small fee, paid directly to the RIR. An initial setup fee and a > yearly renewal fee, paid by credit card or something equally simple. > No payment => assignment withdrawn. The initial fee covering the cost of > evaluation of the request, doing the assignment and setting up the > billing account and DNS reverse. The yearly fee covering the maintenance > of the entries in the database and DNS rev NS RRset and the yearly > recurring fee invoicing/billing. Done. Note that ARIN has been and continues to have discussions about how to give out PI space to end sites, but in a way that doesn't explode the routing tables going forward. I think there is (very strong) support for the idea of giving out more PI space, the difficulty has been in coming up with details that people are comfortable won't explode the routing tables going forward. I.e., that in five years we look back and say "oops, we should not have done that, now what do we do" > Setting aside my disbelieve in the FUD about the scalability problem of > real BGP multihoming (noone yet has shown that the relative amount of > multihomers does or will explode), Um, do the math. How many end sites do you think will want to multihome ten years from now? Can you honestly/realistically say it won't be a million? Can the routing infrastructure handle that? (Enough people say "not sure" that IMO it would be foolish to just assume we can do this). Thomas

3 2