Re: shim6 @ NANOG
--On March 7, 2006 1:38:50 PM -0500 John Curran <[EMAIL PROTECTED]> wrote: At 1:08 PM -0800 3/6/06, Owen DeLong wrote: I've got no opposition to issuing addresses based on some geotop. design, simply because on the off chance it does provide useful aggregation, why not. OTOH, I haven't seen anyone propose geotop allocation as a policy in the ARIN region (hint to those pushing for it). Does anyone have statistics for the present prefix mobility experiment in the US with phone number portability? It would be interesting to know what percent of personal and business numbers are now routed permanently outside their original NPA assignment area... Almost impossible to get statistics on this because of the influx of portable VOIP devices and cellular phones. However, if you're just talking about at the SS7 level, then, realistically, LNP doesn't really provide NPA level portability of numbers. At least I don't know of any telcos allowing you to take your 408 number to the 212 area when you move. If one presumes a modest movement rate across the entire population of businesses, and locality for some percent of those moves (which may be hidden from global visibility due to regional interconnects/exchanges), would the resulting global routing table really be any larger then the current AS allocation count? It certainly would result in a lot of happy businesses to have a PI allocation from a local LIR, even if portability wasn't assured if they relocated to another state. Interesting question. I wonder if CAIDA has any statistics which could provide illumination on this question. /John p.s. personal thoughts only, designed entirely to encourage discussion... :-) pgp5PsRpK7Th7.pgp Description: PGP signature
Re: shim6 @ NANOG
--On March 7, 2006 4:29:28 PM +0100 Iljitsch van Beijnum <[EMAIL PROTECTED]> wrote: On 6-mrt-2006, at 22:08, Owen DeLong wrote: What I hear is "any type of geography can't work because network topology != geography". That's like saying cars can't work because they can't drive over water which covers 70% of the earth's surface. No, it's more like saying "Cars which can't operate off of freeways won't work" because there are a lot of places freeways don't go. Hmmm... Come to think of it, I haven't seen anyone selling a car which won't operate off of a freeway. If we slightly open this up to "vehicles on wheels" and "long distance infrastructure created specially for said vehicles" trains would qualify... True, and, a good case in point. A relatively small percentage of the US population finds trains routinely useful. An even smaller percentage (infinitessimal, actually) finds them useful enough to not have a car. I've got no opposition to issuing addresses based on some geotop. design, simply because on the off chance it does provide useful aggregation, why not. Exactly, that's all I ask. OTOH, I haven't seen anyone propose geotop allocation as a policy in the ARIN region (hint to those pushing for it). Hm, I would rather do this globally but maybe this is the way to go... The only way to achieve global policy is to achieve a similar policy in each RIR and then get them to agree on a globally consistent one together. This is by design because it is a process which allows each region to have full input into the process without the stakeholders in any region being steamrolled by the needs of another region. Owen pgphz9FnKSlR3.pgp Description: PGP signature
RE: shim6 @ NANOG
On Tue, 7 Mar 2006, Tony Hain wrote:
While I agree that any aggregation would happen locally, the
overall allocation policy for a consistent geo approach needs to be
done globally.
Ideally, yes. Failling that, it's still possible for it to be done
unilaterally at a regional level, there would still be benefits. I.e.
"globally agreed policy" need not be a blocking dependency.
You are mixing issues here.
Quite possibly ;).
A policy for assigning PI space is what ARIN can deal with. A
deployment agreement about aggregating a collection of PI
assignments is what operators can deal with.
Sure. However, imagine if $RIR can not agree on such a policy, it
then could still be done within $REGION (in the $RIRs service area),
presuming $RIR can at least agree to delegate the required address
space (even if it can not agree on a policy).
I agree though it would be better if $RIR would drive policy
formulation, and even if better if the RIRs could jointly agree on
such polic{y,ies}.
What needs to happen is to define a global mechanism for PI
assignments such that it is possible to do aggregations when it
becomes necessary. Any of the geo approaches allows aggregation of
a high-density pocket without requiring aggregation of all pockets
globally. In particular the approach I have been pursuing allows
the definition of any aggregate to evolve and track population
shifts over time.
Do you have any pointers to online material? Sounds very interesting.
regards,
--
Paul Jakma [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A
Fortune:
The truth about a man lies first and foremost in what he hides.
-- Andre Malraux
RE: shim6 @ NANOG
Paul Jakma wrote: > On Tue, 7 Mar 2006, Iljitsch van Beijnum wrote: > > > Hm, I would rather do this globally but maybe this is the way to go... > > Geo-aggregation is something that stands its best chance of being > implemented locally: While I agree that any aggregation would happen locally, the overall allocation policy for a consistent geo approach needs to be done globally. > > - the 'players' involved will be fewer > - requirements for a workable policy will be easier to work out >(and fewer conflicts between requirements) > - there may be existing 'arbiter of last resort' (particularly at >national levels) to resolve the inevitable conflicts. > > Ie this may be best done even /below/ the RIR level (though, RIR > agreement would be needed). > > Still though, hard to see it happening without some acceptance by > operators. You are mixing issues here. A policy for assigning PI space is what ARIN can deal with. A deployment agreement about aggregating a collection of PI assignments is what operators can deal with. What needs to happen is to define a global mechanism for PI assignments such that it is possible to do aggregations when it becomes necessary. Any of the geo approaches allows aggregation of a high-density pocket without requiring aggregation of all pockets globally. In particular the approach I have been pursuing allows the definition of any aggregate to evolve and track population shifts over time. Tony
Re: shim6 @ NANOG
On Tue, 7 Mar 2006, Iljitsch van Beijnum wrote: Hm, I would rather do this globally but maybe this is the way to go... Geo-aggregation is something that stands its best chance of being implemented locally: - the 'players' involved will be fewer - requirements for a workable policy will be easier to work out (and fewer conflicts between requirements) - there may be existing 'arbiter of last resort' (particularly at national levels) to resolve the inevitable conflicts. Ie this may be best done even /below/ the RIR level (though, RIR agreement would be needed). Still though, hard to see it happening without some acceptance by operators. regards, -- Paul Jakma [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A Fortune: The public is an old woman. Let her maunder and mumble. -- Thomas Carlyle
Re: shim6 @ NANOG
JC> Date: Tue, 7 Mar 2006 13:38:50 -0500 JC> From: John Curran JC> Does anyone have statistics for the present prefix mobility experiment JC> in the US with phone number portability? It would be interesting to JC> know what percent of personal and business numbers are now routed JC> permanently outside their original NPA assignment area... NPA or NXX? With ILECs required to interconnect with CLECs, it seems the distinction between NPA and NXX is significant. Of course, this brings up the issue of cellular telephony. Perhaps we should see what knowledge may be gleaned from cell infrastructure. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: shim6 @ NANOG
At 1:08 PM -0800 3/6/06, Owen DeLong wrote: >I've got no opposition to issuing addresses based on some geotop. design, >simply because on the off chance it does provide useful aggregation, why >not. OTOH, I haven't seen anyone propose geotop allocation as a policy >in the ARIN region (hint to those pushing for it). Does anyone have statistics for the present prefix mobility experiment in the US with phone number portability? It would be interesting to know what percent of personal and business numbers are now routed permanently outside their original NPA assignment area... If one presumes a modest movement rate across the entire population of businesses, and locality for some percent of those moves (which may be hidden from global visibility due to regional interconnects/exchanges), would the resulting global routing table really be any larger then the current AS allocation count? It certainly would result in a lot of happy businesses to have a PI allocation from a local LIR, even if portability wasn't assured if they relocated to another state. /John p.s. personal thoughts only, designed entirely to encourage discussion... :-)
Re: shim6 @ NANOG
On 6-mrt-2006, at 22:08, Owen DeLong wrote: What I hear is "any type of geography can't work because network topology != geography". That's like saying cars can't work because they can't drive over water which covers 70% of the earth's surface. No, it's more like saying "Cars which can't operate off of freeways won't work" because there are a lot of places freeways don't go. Hmmm... Come to think of it, I haven't seen anyone selling a car which won't operate off of a freeway. If we slightly open this up to "vehicles on wheels" and "long distance infrastructure created specially for said vehicles" trains would qualify... I've got no opposition to issuing addresses based on some geotop. design, simply because on the off chance it does provide useful aggregation, why not. Exactly, that's all I ask. OTOH, I haven't seen anyone propose geotop allocation as a policy in the ARIN region (hint to those pushing for it). Hm, I would rather do this globally but maybe this is the way to go...
Re: shim6 @ NANOG (forwarded note from John Payne)
> > Thus spake <[EMAIL PROTECTED]> > > Let's face it, IPv6 is close enough to IPv4 that any > > attempt to put a price on IPv4 addresses will simply > > cause a massive migration to free and plentiful IPv6 > > addresses. > > You assume that there will be a source of free and plentiful IPv6 addresses. Why not? It is CORE idea of IPcv6 addres space (no matter whart is written abouyt allocation policies). And I can bet, we will see how every business can get PI space when required (in ipv6) for multi home, in less than 3 - 4 years. Except if IPv6 will be replaced by something simpler and more reliable like IPv8 (but it looks very unlikely now).
Re: shim6 @ NANOG (forwarded note from John Payne)
Not to digress too far, but, I guess that depends on your definition of best. I am sure that many peoples of this world would argue that capitalism has been rather catastrophic in terms of resource allocation and resulting effects with regard to oil, for example. Owen
Re: shim6 @ NANOG (forwarded note from John Payne)
On 3/6/06 6:14 PM, "Stephen Sprunk" <[EMAIL PROTECTED]> wrote: > Thus spake "Daniel Golding" <[EMAIL PROTECTED]> >> On 3/6/06 10:25 AM, "Stephen Sprunk" <[EMAIL PROTECTED]> wrote: >>> So, unless there's policy change, most end-user orgs will have no >>> choice but to pay the market rate for IPv4 addresses. Spot markets >>> are good when demand is elastic, but we're faced with a market that >>> has growing inelastic demand that will outstrip fixed supply in a >>> decade. Capitalism doesn't handle that well. >> >> There will be a average cost per host to transition from v4 to v6. When >> the >> cost of IPv4 addresses exceeds the transition cost, then you have the one >> thing missing from IPv6 discussions: an ROI. > > Please quantify the cost of not being able to multihome your > mission-critical business. Compare to the cost of obtaining an IPv4 PI > block. Both are likely to exceed the possible revenue for small businesses > at some point not too far off. > This is of course, making the assumption (which may be in error) at PI IPv6 space will happen, through 2005-1 or some other policy. Absent PI IPv6 space, IPv6 simply wont happen, shim6 or not. -- Daniel Golding
Re: shim6 @ NANOG (forwarded note from John Payne)
On Mon, 06 Mar 2006 17:05:52 -0500 Daniel Golding <[EMAIL PROTECTED]> wrote: > > ARIN (and/or RIPE, APNIC) should really use a bit of their budget surplus to > provide a few grants to economics professors who are experts in commodity > market issues. As engineers, we grope in the dark concerning fairly well > established scientific principles we are unfamiliar with. Its like > reinventing the wheel. :( > For a view by some computer scientists, see: Yakov Rekhter, Paul Resnick, and Steven M. Bellovin, "Financial Incentives for Route Aggregation and Efficient Address Utilization in the Internet," in Proceedings of Telecommunications Policy Research Conference, Solomons, MD..Also in Brian Kahin and James H. Keller, eds., Coordinating the Internet, MIT Press, 1997 http://www.cs.columbia.edu/~smb/papers/piara/index.html We even held a BoF at an IETF, long ago. The enthusiasm was, shall we say, underwhelming.
Re: shim6 @ NANOG (forwarded note from John Payne)
Thus spake "Daniel Golding" <[EMAIL PROTECTED]> On 3/6/06 10:25 AM, "Stephen Sprunk" <[EMAIL PROTECTED]> wrote: So, unless there's policy change, most end-user orgs will have no choice but to pay the market rate for IPv4 addresses. Spot markets are good when demand is elastic, but we're faced with a market that has growing inelastic demand that will outstrip fixed supply in a decade. Capitalism doesn't handle that well. There will be a average cost per host to transition from v4 to v6. When the cost of IPv4 addresses exceeds the transition cost, then you have the one thing missing from IPv6 discussions: an ROI. Please quantify the cost of not being able to multihome your mission-critical business. Compare to the cost of obtaining an IPv4 PI block. Both are likely to exceed the possible revenue for small businesses at some point not too far off. IPv6 is not a replacement for IPv4 today; it's less attractive for a number of reasons, and running out of IPv4 addresses will only solve one (maybe two) of the problems. Many organizations wont even look at this without an ROI. Folks who want to see v6 adopted would be well advised to support the creation of a hard ROI through these means. That'd be interesting to see, but there's just too many variables we don't (and can't) have numbers for yet. Maybe it'd be a useful exercise to at least identify what needs to be quantified... ARIN (and/or RIPE, APNIC) should really use a bit of their budget surplus to provide a few grants to economics professors who are experts in commodity market issues. As engineers, we grope in the dark concerning fairly well established scientific principles we are unfamiliar with. Its like reinventing the wheel. :( That would require the RIRs to admit that IP addresses are marketable commodities, which is something that, to date, they have refused to do. S Stephen Sprunk"Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin
Re: shim6 @ NANOG (forwarded note from John Payne)
On 3/6/06 10:25 AM, "Stephen Sprunk" <[EMAIL PROTECTED]> wrote: > > Thus spake <[EMAIL PROTECTED]> >> Let's face it, IPv6 is close enough to IPv4 that any >> attempt to put a price on IPv4 addresses will simply >> cause a massive migration to free and plentiful IPv6 >> addresses. > > You assume that there will be a source of free and plentiful IPv6 addresses. > AFAIK, none of them are rent-free, and they're not even available unless you > have the clue and resources to prented to be an LIR. > > So, unless there's policy change, most end-user orgs will have no choice but > to pay the market rate for IPv4 addresses. Spot markets are good when > demand is elastic, but we're faced with a market that has growing inelastic > demand that will outstrip fixed supply in a decade. Capitalism doesn't > handle that well. > > S > > Stephen Sprunk"Stupid people surround themselves with smart > CCIE #3723 people. Smart people surround themselves with > K5SSS smart people who disagree with them." --Aaron Sorkin > Stephen, There will be a average cost per host to transition from v4 to v6. When the cost of IPv4 addresses exceeds the transition cost, then you have the one thing missing from IPv6 discussions: an ROI. Many organizations wont even look at this without an ROI. Folks who want to see v6 adopted would be well advised to support the creation of a hard ROI through these means. (Just as an aside - capitalism has historically been the best mechanism for resource allocation - scarce resource or plentiful. Command economics have never historically beaten a fair and open market, despite the beliefs of a certain sector of those involved with IP address allocation. ARIN (and/or RIPE, APNIC) should really use a bit of their budget surplus to provide a few grants to economics professors who are experts in commodity market issues. As engineers, we grope in the dark concerning fairly well established scientific principles we are unfamiliar with. Its like reinventing the wheel. :( -- Daniel Golding
Re: shim6 @ NANOG
--On March 6, 2006 12:46:51 PM +0100 Iljitsch van Beijnum <[EMAIL PROTECTED]> wrote: > > On 6-mrt-2006, at 3:52, Roland Dobbins wrote: > >> fixed geographic allocations (another nonstarter for reasons which >> have been elucidated previously) > > What I hear is "any type of geography can't work because network > topology != geography". That's like saying cars can't work because they > can't drive over water which covers 70% of the earth's surface. > No, it's more like saying "Cars which can't operate off of freeways won't work" because there are a lot of places freeways don't go. Hmmm... Come to think of it, I haven't seen anyone selling a car which won't operate off of a freeway. > Early proposals for doing any geographic stuff were fatally flawed but > there is enough correlation between geography and topology to allow for > useful savings. Even if it's only at the continent level that would > allow for about an 80% reduction of routing tables in the future when > other continents reach the same level of multihoming as North America > and Europe. I've got no opposition to issuing addresses based on some geotop. design, simply because on the off chance it does provide useful aggregation, why not. OTOH, I haven't seen anyone propose geotop allocation as a policy in the ARIN region (hint to those pushing for it). Owen -- If it wasn't crypto-signed, it probably didn't come from me. pgp7Ie5AZ0LS1.pgp Description: PGP signature
Re: shim6 @ NANOG (forwarded note from John Payne)
Stephen, > I'm not a fan of "build it and they will come" engineering. I suppose a reasonable question one could ask is this: who's the customer? Is the customer the ISP? I tend to actually it's the end enterprise. But that's just me. Eliot
Re: shim6 @ NANOG (forwarded note from John Payne)
Thus spake "Eliot Lear" <[EMAIL PROTECTED]> Stephen Sprunk wrote: Shim6 is an answer to "what kind of multihoming can we offer to sites without PI space?"; it is yet to be seen if anyone cares about the answer to that question. This argument is circular. The only real way to test demand is to offer a service and see if customers bite. I'm not a fan of "build it and they will come" engineering. One might first talk to customers and see if your proposal is laughed at, at least. So far, that's the most charitable reaction I've seen to shim6. It's also not encouraging that many of the folks working on shim6 happen to have PI blocks themselves (despite not qualifying as LIRs); I'm also not a fan of "it's good enough for everyone else, but not good enough for me." S Stephen Sprunk"Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin
Re: shim6 @ NANOG
Stephen, > Thus spake "Tony Li" <[EMAIL PROTECTED]> > >Stephen Sprunk wrote: > >>Who exactly has been trying to find scalable routing solutions? > > > >Well, for the last decade or so, there's been a small group of us who > >have been working towards a new routing architecture. Primary > >influences in my mind are Chiappa, O'Dell, Hain, Hinden, Nordmark, > >Atkinson, Fuller, Huston, Rekhter and Meyer. Apologies to any folks > >that feel I've incorrectly included or excluded them. ;-) > > And my apologies for not recognizing the work that y'all have done; my > point was that none of this seems to be officially supported by the IETF, > and thus hasn't borne much fruit. I've seen a few proposals by folks > listed above, and it seems to be old drafts (or even napkins) that get > trotted out when this discussion comes up. If there's work actively going > on today, it's not well publicized. Speaking for myself, I can say that many of us are trying to raise the profile of exactly these issues in the IETF. As you might imagine, that's not exactly a "path of least resistance", given the history/baggage. My position, however, is that the past is something we can learn from, but not be controlled by (a perhaps metaphorical way of saying "lets get on with it"). I'm optimistic that we're getting traction, but as I said, history and inertia are pushing the other way (not that that's going to stop us, but it does slow things down at times). > >>IPv6 advocates have been pushing a no-PI model for over a decade > >>because that's what ISPs told them to do. > > > >More accurately, the routing community has been trying to avoid PI > >addressing simply because of the scalability (and thus cost) concerns. > > s/routing/ISP/ and I'd agree with that. The IETF has virtually no > enterprise representation, and those folks (a) have a lot more routers than > the ISPs, and (b) pay the ISPs' bills. Agreed, and representation is a big problem. I'm trying to work that too. The first thing we tried was the NANOG/APRICOT BOFs (and I think we're going to try it at RIPE too, waiting to hear from the PC on that one). So maybe these were not as successful as I would have hoped, but hey, you have to start somewhere (on the theory that the best way to finish anything is to start). > I agree that PI has scaling/cost problems, but so far all of the > alternatives presented by the IETF present worse problems _in the eyes of > the people that pay the bills_. That doesn't mean the latter are right, > but their views should not be taken lightly. > > >>When they found end users didn't like that, they went off and > >>developed what has become shim6 as a poor apology. There has > >>never been any significant work done on replacing CIDR with > >>something that scales better. > > > >More accurately, that work (GSE/8+8) was slapped down politically > >without due technical consideration. > > Correction noted. > > >Note that replacing CIDR isn't exactly the point. The point is to have > >something that scales. Where CIDR can't cope is exactly when we > >come to multihoming. When multihoming was a rare exception, the > >small number of PI prefixes remains tolerable. However, over time, > >the continued growth in multihoming, even solely as a function of the > >growth of the Internet will come to dominate the cost structure of > >the routing subsystem. > > I'm not sure I agree with that. The ISPs out there have tens of prefixes > each even in v6 land (and hundreds in v4 land), whereas the goal is to have > one per end site. Until the number of multihomed end sites exceeds the > number of ISPs by several orders of magnitude, the impact on the routing > table will be non-dominant though certainly also non-trivial. > > Also, consider how easy it is to do PI-based multihoming in v4: all you > need is a couple pipes (or tunnels), an ASN, and enough hosts to justify a > /24. If you believed all the chicken littles, this would leave us with > millions of v4 PI routes and the DFZ would be in ruins, yet only a few > hundred people have taken ARIN up on that offer. In short, implementation > of PI-based multihoming has ground almost to a halt even under today's > liberal policies. > > Now, given the floodgates are open for v4 and all we see is a trickle of > water, why is everyone running around screaming that the sky will fall if > we do something similar for v6? Do we have any evidence at all that > multihoming growth will outpace Moore and this whole debate is even > relevant? > > >The only alternative to a PI-like architecture is to provide multihomed > >sites with multiple prefixes, none of which need to be globally > >disseminated. Making this multiple prefix architecture work was the > >charter of the multi6 group. This was constrained in interesting ways, >
Re: shim6 @ NANOG (forwarded note from John Payne)
Thus spake <[EMAIL PROTECTED]> Let's face it, IPv6 is close enough to IPv4 that any attempt to put a price on IPv4 addresses will simply cause a massive migration to free and plentiful IPv6 addresses. You assume that there will be a source of free and plentiful IPv6 addresses. AFAIK, none of them are rent-free, and they're not even available unless you have the clue and resources to prented to be an LIR. So, unless there's policy change, most end-user orgs will have no choice but to pay the market rate for IPv4 addresses. Spot markets are good when demand is elastic, but we're faced with a market that has growing inelastic demand that will outstrip fixed supply in a decade. Capitalism doesn't handle that well. S Stephen Sprunk"Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin
Re: shim6 @ NANOG
Thus spake "Tony Li" <[EMAIL PROTECTED]> Stephen Sprunk wrote: Who exactly has been trying to find scalable routing solutions? Well, for the last decade or so, there's been a small group of us who have been working towards a new routing architecture. Primary influences in my mind are Chiappa, O'Dell, Hain, Hinden, Nordmark, Atkinson, Fuller, Huston, Rekhter and Meyer. Apologies to any folks that feel I've incorrectly included or excluded them. ;-) And my apologies for not recognizing the work that y'all have done; my point was that none of this seems to be officially supported by the IETF, and thus hasn't borne much fruit. I've seen a few proposals by folks listed above, and it seems to be old drafts (or even napkins) that get trotted out when this discussion comes up. If there's work actively going on today, it's not well publicized. IPv6 advocates have been pushing a no-PI model for over a decade because that's what ISPs told them to do. More accurately, the routing community has been trying to avoid PI addressing simply because of the scalability (and thus cost) concerns. s/routing/ISP/ and I'd agree with that. The IETF has virtually no enterprise representation, and those folks (a) have a lot more routers than the ISPs, and (b) pay the ISPs' bills. I agree that PI has scaling/cost problems, but so far all of the alternatives presented by the IETF present worse problems _in the eyes of the people that pay the bills_. That doesn't mean the latter are right, but their views should not be taken lightly. When they found end users didn't like that, they went off and developed what has become shim6 as a poor apology. There has never been any significant work done on replacing CIDR with something that scales better. More accurately, that work (GSE/8+8) was slapped down politically without due technical consideration. Correction noted. Note that replacing CIDR isn't exactly the point. The point is to have something that scales. Where CIDR can't cope is exactly when we come to multihoming. When multihoming was a rare exception, the small number of PI prefixes remains tolerable. However, over time, the continued growth in multihoming, even solely as a function of the growth of the Internet will come to dominate the cost structure of the routing subsystem. I'm not sure I agree with that. The ISPs out there have tens of prefixes each even in v6 land (and hundreds in v4 land), whereas the goal is to have one per end site. Until the number of multihomed end sites exceeds the number of ISPs by several orders of magnitude, the impact on the routing table will be non-dominant though certainly also non-trivial. Also, consider how easy it is to do PI-based multihoming in v4: all you need is a couple pipes (or tunnels), an ASN, and enough hosts to justify a /24. If you believed all the chicken littles, this would leave us with millions of v4 PI routes and the DFZ would be in ruins, yet only a few hundred people have taken ARIN up on that offer. In short, implementation of PI-based multihoming has ground almost to a halt even under today's liberal policies. Now, given the floodgates are open for v4 and all we see is a trickle of water, why is everyone running around screaming that the sky will fall if we do something similar for v6? Do we have any evidence at all that multihoming growth will outpace Moore and this whole debate is even relevant? The only alternative to a PI-like architecture is to provide multihomed sites with multiple prefixes, none of which need to be globally disseminated. Making this multiple prefix architecture work was the charter of the multi6 group. This was constrained in interesting ways, as both NAT box solutions were considered politically unacceptable, as was changing the core functionality of the v6 stack (i.e., redefining the TCP pseudoheader). Given these constraints, it was somewhat unsurprising that NAT got pushed into the host. From my perspective, we have now explored the dominant quadrants of the solution space and various factions have vociferously denounced all possible solutions. You'll pardon me if some of us are feeling just a tad frustrated. I think we're all a bit frustrated at this point. However, I think we haven't adequately explored several ideas that allow PI space for all that need it yet don't require carrying all those routes in every DFZ router or schemes that do away with our current idea of the DFZ entirely. The solution space is a lot bigger than the few corners that we've explored over and over. Every such proposal I've seen has been ignored or brushed aside by folks who've been doing CIDR for their entire careers and refuse to even consider that anything else might be better. More accurately, the folks that have been CIDR advocates 'for their entire careers' are exactly the same folks who have been advocating shifting to something else, but have been rejected by other political
Re: shim6 @ NANOG (forwarded note from John Payne)
On Mar 6, 2006, at 4:32 AM, [EMAIL PROTECTED] wrote: Sadly, many of the folks who are involved with ARIN are sadly short sighted in this regard. They dismiss both the idea of an address market upon v4 exhaustion and the idea of clear title to address blocks. I can imagine a similar scenario in the boardrooms of Exxon et al. A young executive suggests that gasoline prices should be raised to $20 per gallon because reserves are dropping. The seasoned executives glance nervously at the unknown Russian oil reserves and the huge Canadian oilsands reserves and wonder what would happen to that plan if huge new supplies suddenly entered the market. Let's face it, IPv6 is close enough to IPv4 that any attempt to put a price on IPv4 addresses will simply cause a massive migration to free and plentiful IPv6 addresses. Or a freeing up of hoarded or unused IPv4 addresses. That's one thing spot markets are pretty efficient at doing in times of scarcity. Regards Marshall --Michael Dillon
Re: shim6 @ NANOG (forwarded note from John Payne)
Stephen Sprunk wrote: > Shim6 is an answer to "what kind of multihoming can we offer to sites > without PI space?"; it is yet to be seen if anyone cares about the > answer to that question. This argument is circular. The only real way to test demand is to offer a service and see if customers bite. Eliot
Re: shim6 @ NANOG
On 5-mrt-2006, at 20:38, Matthew Petach wrote: Hotmail runs shim6 so that multihomed Hotmail users can keep sending mail even when one ISP fails, while Gmail doesn't? The customers who can't reach gmail will call their ISP to complain about the Internet being broken. They're not going to call Google and ask why they aren't installing/configuring shim6 on 150,000+ servers. This is observable today, and is not a matter of conjecture. People who go through the expense of adding a second ISP are likely to be a bit more clueful than that, especially when they see that Gmail doesn't work and Hotmail does. I think the trend has been pretty clear thus far--large networks/ large providers have been getting PI /32 allocations in order to be able to multihome in v6 in the same way they multihome in v4 today. And for those organizations that today have multiple locations that aren't connected but still need to talk to the Internet, they have separate v4 allocations and separate ASNs Some of them, certainly. But others use one AS number and one prefix and break the prefix into smaller pieces that are announced from different locations. Installing shim6 will not provide companies with the same level of redundancy that multihoming with PI space provides in the IPv4 world today, In a world where most hosts are shim-capable it would. It doesn't buy you fast and painless provider switching that having your own PI block does, but that's another issue. In case you've never had to discuss network upgrades/conversions/ migrations with executives before, the answer to any proposal that increases the risk to the company's business without clear benefits that well exceed the added risk is "NO". Letting business people make engineering decisions is not a good idea, just like having engineers make business decisions. If the risk is too great, just let them wait and the risk will become smaller. And that's exactly what they're doing anyway. 2 million prefixes in a router that supports 1 million is also a non- starter. And in 1996, we would have said 200,000 prefixes in a router that supports 100,000 is a non-starter. And yet here we are, with everyone in the core holding 200,000 prefixes without complaint. 2 million prefixes in a router that supports 1 million is a non- starter *today*; No, it's a non-starter ALWAYS. The only variables are whether routers of the required capacity are available and if so, how much they cost. I think the only time that routing table size wasn't a consideration when buying routers for me and my customers was a few years around 2000 when a Cisco 7200 was fast enough to handle the required amounts of traffic, supported memory to do full routing and was affordable with regard to revenues in the internet business as I knew/know it (= in the Netherlands). Before that, a C7200 was too expensive for many ISPs that I knew and these days, traffic volumes are such that you really need something with hardware support but then you either have cheap multilayer switches that can't do full routing or routers that are too expensive for small ASes. Routing table growth is more limited by the ability of entities to get physical links installed, obtain an AS, and learn how to spell BGP than it is by our allocation policies. Conjecture. Yes, someday we'll get to 2 million prefixes, as more people learn to speak BGP, and purchasing multiple physical links becomes cheaper. But it won't be overnight, and routers will continue to scale, as they have from the CIDR crisis of the 90's to our IPv6 non-crisis of today. There is no way of knowing that. Moore's Law certainly appeared to be in bad shape a few years back as the traditional process shrinking in the chip industry hit some walls. We're back on track now, but there's no telling what will happen in the future. IPv4 has been in operation for 25 years now. Let me be generous and assume that the switch to IPv6 happens 5 years from now. With more and more stuff connected to networks the switch to IPv7 isn't going to be faster than the one from v4 to v6, so IPv6 will have to last for at least 30 years like IPv4 before it. So we have to make certain that what we do today still works in 2041. That is a LONG time to keep doubling performance every 18 months. Now, for the rest of us, let's move on to draft a useful allocation strategy that allows for PI multihoming in IPv6 in the same way companies are able to do so in the IPv4 world. Bad idea. If we aren't comfortable doing that, then let's draft up the terms of the market economy that will develop in buying and selling IPv4 addresses as the pool runs dry If you're happy with that as an alternative for PI in IPv6, then go right ahead. Personally, I don't like the idea of organizations who got a /8 now reaping huge benefits from that and the moment this is seriously suggested you
Re: shim6 @ NANOG
On 6-mrt-2006, at 2:34, Steven M. Bellovin wrote: What Tony said, especially about what happened to 8+8. A lot of the grounds for rejection were security, but there wasn't a single security person on the committee. In my opinion, most of the arguments just didn't hold up. [RB = routing bits, IB = identity bits] So when I send you an 8+8 packet where [RB=me+IB=www.paypal.com] how do you know that this is bad while if Paypal sends you a packet with [RB=paypal+IB=www.paypal.com] that's good? Also, how does 8+8 accomplish failover? Original 8+8/GSE is incomplete. If you add the necessary extra stuff and think about backward compatibility for a while, you end up with something that's extremely close to shim6. If we add source address rewriting to shim6 (which is certainly doable) the family resemblence becomes even clearer.
Re: Time for IPv8? (was Re: shim6 @ NANOG)
On Sun, 5 Mar 2006, Roland Dobbins wrote: Given the manifold difficulties we're facing today as a result of these two design decisions (#2 is a 'hidden' reason behind untold amounts of capex and opex being spent in frustratingly nonproductive ways), perhaps it is time to consider declaring the 'Limited-Deployment IPv6 Proof-of-Concept Experiment' to be a success, take the lessons learned (there are a lot more unresolved and potentially problematic issues than those mentioned in this thread) into account and get started on IPv8. If you want to redesign IPv[4|6] into IPvNG that deals with all known issues - more power to you. But do you really think we can have fully working prototype and set of RFCs from WG by the time we ran out of IPv4 addresses? One of the lessons learned from IPv6 is actually that it takes long time to agree on changes to TCP/IP stack and even longer before those changes begin to appear on end-devices. Another lesson is that any new type of "address" also has associated allocation policy issues and to get consensus on that in entire world is also very difficult and takes just as much time. -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: shim6 @ NANOG
On 6-mrt-2006, at 3:52, Roland Dobbins wrote: fixed geographic allocations (another nonstarter for reasons which have been elucidated previously) What I hear is "any type of geography can't work because network topology != geography". That's like saying cars can't work because they can't drive over water which covers 70% of the earth's surface. Early proposals for doing any geographic stuff were fatally flawed but there is enough correlation between geography and topology to allow for useful savings. Even if it's only at the continent level that would allow for about an 80% reduction of routing tables in the future when other continents reach the same level of multihoming as North America and Europe.
Re: shim6 @ NANOG (forwarded note from John Payne)
On Mon, 6 Mar 2006, Mikael Abrahamsson wrote: Let's say we put a price of $1 per year per IP address you want allocated to you. For the people really using their IP addresses according to current policy, this is nothing. For the people with historic allocations (/8 for instance), they would really have to think if it's worth $16m to keep that /8. Most likely scenario is that this would free up a lot of IPv4 address space. If this causes migration to IPv6, well, so be it. I seriously doubt it, only thing I think would happen is that we would free up IPv4 space and it would live longer. I'd love to see something like that (even better: charging by what you advertise).. but unfortunately, I don't think it'd happen, and if it did, I guess the main folks benefiting would be lawyers.. :) -- Pekka Savola "You each name yourselves king, yet the Netcore Oykingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: shim6 @ NANOG (forwarded note from John Payne)
On Mon, 6 Mar 2006 [EMAIL PROTECTED] wrote: Let's face it, IPv6 is close enough to IPv4 that any attempt to put a price on IPv4 addresses will simply cause a massive migration to free and plentiful IPv6 addresses. Let's say we put a price of $1 per year per IP address you want allocated to you. For the people really using their IP addresses according to current policy, this is nothing. For the people with historic allocations (/8 for instance), they would really have to think if it's worth $16m to keep that /8. Most likely scenario is that this would free up a lot of IPv4 address space. If this causes migration to IPv6, well, so be it. I seriously doubt it, only thing I think would happen is that we would free up IPv4 space and it would live longer. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
Re: shim6 @ NANOG
> I can tell you this: the only scalable solutions > on the horizon are: > > - moving multihoming related state out of the DFZ (this is what shim6 > does) This is what geo-topological addressing does. > - remove the requirement that every DFZ router carries every prefix, > which can't be done as long as PI blocks sit at the top of the > addressing hierarchy Geotop addressing does this also because only a few aggregates are in the DFZ. The detail is elsewhere. > The closest thing to a magic, pain-free solution would be to allocate > PI blocks such that it's possible to aggregate them together and > ignore the more specifics for far away regions of the world, so that > in 2030 you don't have to carry 6 Chinese PI blocks world wide > that all sit behind the same Great Firewall anyway, Exactly! And this doesn't need to be done in a mandatory way. It can be done so that large providers can continue to use provider-aggregatable addresses. Geotop addressing is one of those 80-20 solutions where the largest 20% of providers mostly use classic IPv6 address but the other 80% of smaller multihomers use geotopologically aggregatable addresses. --Michael Dillon
Re: shim6 @ NANOG (forwarded note from John Payne)
[EMAIL PROTECTED] wrote on 04/03/2006 00:16:28: > > On 3-mrt-2006, at 11:30, [EMAIL PROTECTED] wrote: > >> The term LIR is used in IPv6 allocation policy in all regions > > no Yes. I checked all 5 RIR sites and they all use the term LIR in their IPv6 policy. This is by design since the original IPv6 policy was jointly written by all RIRs. http://www.afrinic.net/docs/policies/afpol-v6200407-000.htm http://lacnic.net/sp/politicas/ipv6.html http://www.apnic.net/docs/policy/ipv6-address-policy.html http://www.ripe.net/ripe/docs/ipv6policy.html http://www.arin.net/policy/nrpm.html#ipv6 --Michael Dillon
Re: shim6 @ NANOG (forwarded note from John Payne)
> Sadly, many of the folks who are involved with ARIN are sadly short sighted > in this regard. They dismiss both the idea of an address market upon v4 > exhaustion and the idea of clear title to address blocks. I can imagine a similar scenario in the boardrooms of Exxon et al. A young executive suggests that gasoline prices should be raised to $20 per gallon because reserves are dropping. The seasoned executives glance nervously at the unknown Russian oil reserves and the huge Canadian oilsands reserves and wonder what would happen to that plan if huge new supplies suddenly entered the market. Let's face it, IPv6 is close enough to IPv4 that any attempt to put a price on IPv4 addresses will simply cause a massive migration to free and plentiful IPv6 addresses. --Michael Dillon
Re: shim6 @ NANOG
On Sat, 4 Mar 2006 20:17:26 +0100, "Iljitsch van Beijnum" <[EMAIL PROTECTED]> said: > > On 4-mrt-2006, at 14:07, Kevin Day wrote: > [snip] > > > Unless we start now working on getting people moved to IPv6, the > > pain of running out of IPv4 before IPv6 has reached critical mass > > is going to be much much worse than a long term problem of IPv6 > > route size. > > I disagree. You assume that IPv6 will be able to gain critical mass > before IPv4 addresses run out. I don't think that will happen, > because of the chicken/egg problem. "Running out" is a relative term. > John Klensin says we've effictively already run out because IPv4 > addresses are too hard to get for some applications. That may be true > but people aren't turning to IPv6 (yet) to run those applications. My > prediction is that we'll see interesting things happen when the > remaining IPv4 address suppy < 3 * addresses used per year. That will > probably happen around the end of this decade. At that point, there > is likely to be hoarding and/or the allocation policies will become > stricter, and people will start to think about a future where it's no > longer possible to get IPv4 addresses. At this point, there will > still be time to migrate. Doesn't the above disagreement indicate that IPv6 is incomplete until a workable locator/id-split is implemented? If so, why bother with operational policies and deployment beyond what is of experimental nature necessary to facilitate further development? //per -- Per Heldal http://heldal.eml.cc/
Re: shim6 @ NANOG (forwarded note from John Payne)
On Sat, 4 Mar 2006 13:59:18 +0100, "Kurt Erik Lindqvist" <[EMAIL PROTECTED]> said: > > > On 3 mar 2006, at 04.13, Marshall Eubanks wrote: > > > I would be surprised if Shim6 going into actual deployed boxes was > > any faster. So, if Shim6 was finalized today, which it won't be, > > in 2010 we might have 70% deployment and in 2012 we might have 90% > > deployment. > > OTOH Teredo, which isn't even a standard is in more or less all > Windows XP boxes > It illustrates an important difference in motivation. Is the primary goal to solve a problem or to make a standard? Remember, quite a few important technologies were implemented, tested and even in production-use for a long time before standardisation (e.g. ssh). //per -- Per Heldal http://heldal.eml.cc/
Re: Time for IPv8? (was Re: shim6 @ NANOG)
I disagree with your understanding of the "limited deployment ...". There is much more commercial deployment and traffic that what you realize. Because some ISPs didn't deployed yet IPv6 doesn't meant is a failure. The deployment of any new protocol take time, and actually I will say that IPv6 has taken the right time to ensure a smooth transition. Precisely because that, most people is not noticing that some applications are already using IPv6, and we will see this much more in the next 12-18 months or so. So yes, is happening, and is a success. Regards, Jordi > De: Roland Dobbins <[EMAIL PROTECTED]> > Responder a: <[EMAIL PROTECTED]> > Fecha: Sun, 5 Mar 2006 19:19:46 -0800 > Para: <[EMAIL PROTECTED]> > Asunto: Time for IPv8? (was Re: shim6 @ NANOG) > > > > On Mar 5, 2006, at 6:59 PM, Owen DeLong wrote: > >> Far from it, but, there are lessons to be >> learned that are applicable to the internet, and, separating the >> end system identifier from the routing function is one we still seem >> determined to avoid for reasons passing my understanding. > > And this is the real answer, of course. > > There were two fundamental design decisions made back in the Olden > Days which continue to exert a strong and in many cases quite > negative sway over this entire set of inter-related issues: > > 1. Utilizing the endpoint identifier in the routing function, as > Vince Fuller and you (among others) have stated, and > > 2. The ships-in-the-night nature of the TCP/IP protocol stack. > This latter design decision is a big part of the reason TCP/IP > has been so successful to date; however, we find more and > more kludgey, brittle hacks to try and provide some sort > of linkages for purposes of enforcing policy, etc. The > irony is that these attempts largely stem from the unforeseen > side-effects of #1, and also contribute to a reinforcing > feedback loop which further locks us into #1. > > Given the manifold difficulties we're facing today as a result of > these two design decisions (#2 is a 'hidden' reason behind untold > amounts of capex and opex being spent in frustratingly nonproductive > ways), perhaps it is time to consider declaring the 'Limited- > Deployment IPv6 Proof-of-Concept Experiment' to be a success, take > the lessons learned (there are a lot more unresolved and potentially > problematic issues than those mentioned in this thread) into account > and get started on IPv8. > > -- > Roland Dobbins <[EMAIL PROTECTED]> // 408.527.6376 voice > > Everything has been said. But nobody listens. > > -- Roger Shattuck > ** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Time for IPv8? (was Re: shim6 @ NANOG)
On Mar 5, 2006, at 6:59 PM, Owen DeLong wrote: Far from it, but, there are lessons to be learned that are applicable to the internet, and, separating the end system identifier from the routing function is one we still seem determined to avoid for reasons passing my understanding. And this is the real answer, of course. There were two fundamental design decisions made back in the Olden Days which continue to exert a strong and in many cases quite negative sway over this entire set of inter-related issues: 1. Utilizing the endpoint identifier in the routing function, as Vince Fuller and you (among others) have stated, and 2. The ships-in-the-night nature of the TCP/IP protocol stack. This latter design decision is a big part of the reason TCP/IP has been so successful to date; however, we find more and more kludgey, brittle hacks to try and provide some sort of linkages for purposes of enforcing policy, etc. The irony is that these attempts largely stem from the unforeseen side-effects of #1, and also contribute to a reinforcing feedback loop which further locks us into #1. Given the manifold difficulties we're facing today as a result of these two design decisions (#2 is a 'hidden' reason behind untold amounts of capex and opex being spent in frustratingly nonproductive ways), perhaps it is time to consider declaring the 'Limited- Deployment IPv6 Proof-of-Concept Experiment' to be a success, take the lessons learned (there are a lot more unresolved and potentially problematic issues than those mentioned in this thread) into account and get started on IPv8. -- Roland Dobbins <[EMAIL PROTECTED]> // 408.527.6376 voice Everything has been said. But nobody listens. -- Roger Shattuck
Re: shim6 @ NANOG
--On March 5, 2006 3:28:05 PM -0500 Joe Abley <[EMAIL PROTECTED]> wrote: > > On 5-Mar-2006, at 14:16, Owen DeLong wrote: > >> It flies if you look at changing the routing paradigm instead of >> pushing >> routing decisions out of the routers and off to the hosts. Source >> Routing >> is a technology that most of the internet figured out is problematic >> years ago. Making source routing more complicated and calling it >> something >> else doesn't make it less of a bad idea. > > Calling shim6 source-routing when it's not in order to give it an aura > of evil is similarly unproductive :-) > Sorry, I guess we'll agree to disagree on this, but, I see very little difference between shim6 and LSR other than the mechanism of implementation (shim6 requires a bit more overhead). >> I don't think it will be as expensive as you think to fix it. I >> think if >> we start working on a new routing paradigm today in order to >> support IDR >> based on AS PATH instead of Prefix, we would realistically see this in >> deployable workable code within 3-5 years. > > I'm confused by statements such as these. > > Was it not the lack of any scalable routing solution after many years of > trying that led people to resort to endpoint mobility in end systems, Ã > la shim6? > I haven't seen any concrete proposals presented around the idea of IDR based on something other than prefix. Everything I've seen leading up to shim6 was about ways to continue to use prefixes and, to me, shim6 is just another answer to the wrong question... "How can we help scale prefix based routing?". The right question still hasn't been asked by most people in my opinion... "What can we use for routing instead of prefixes that will scale better?" As much as I agree the internet is not the PSTN, this is one place where we have a lot to learn from SS7. No, SS7 is not perfect... Far from it, but, there are lessons to be learned that are applicable to the internet, and, separating the end system identifier from the routing function is one we still seem determined to avoid for reasons passing my understanding. Owen > > Joe > -- If it wasn't crypto-signed, it probably didn't come from me. pgpzu6K7u4ZlK.pgp Description: PGP signature
Re: shim6 @ NANOG
On Mar 5, 2006, at 2:51 PM, Joe Abley wrote: Very little time has been spent on shim6 so far. Far more time before that was spent on multi6, which considered many different approaches to multi-homing. Spending time in and of itself has no value, you're entirely correct. Spending time to come up with a solution which does not engage in problem-shifting routing onto the nodes, fixed geographic allocations (another nonstarter for reasons which have been elucidated previously), and other schemes which ignore customer requirements and correspond to operational and business realities - does- have value, and that's what's being proposed. -- Roland Dobbins <[EMAIL PROTECTED]> // 408.527.6376 voice Everything has been said. But nobody listens. -- Roger Shattuck
Re: shim6 @ NANOG
What Tony said, especially about what happened to 8+8. A lot of the grounds for rejection were security, but there wasn't a single security person on the committee. In my opinion, most of the arguments just didn't hold up. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Re: shim6 @ NANOG
Stephen Sprunk wrote: > Who exactly has been trying to find scalable routing solutions? Well, for the last decade or so, there's been a small group of us who have been working towards a new routing architecture. Primary influences in my mind are Chiappa, O'Dell, Hain, Hinden, Nordmark, Atkinson, Fuller, Huston, Rekhter and Meyer. Apologies to any folks that feel I've incorrectly included or excluded them. ;-) > IPv6 advocates have been pushing a no-PI model for over a decade because > that's what ISPs told them to do. More accurately, the routing community has been trying to avoid PI addressing simply because of the scalability (and thus cost) concerns. > When they found end users didn't like > that, they went off and developed what has become shim6 as a poor > apology. There has never been any significant work done on replacing > CIDR with something that scales better. More accurately, that work (GSE/8+8) was slapped down politically without due technical consideration. Note that replacing CIDR isn't exactly the point. The point is to have something that scales. Where CIDR can't cope is exactly when we come to multihoming. When multihoming was a rare exception, the small number of PI prefixes remains tolerable. However, over time, the continued growth in multihoming, even solely as a function of the growth of the Internet will come to dominate the cost structure of the routing subsystem. The only alternative to a PI-like architecture is to provide multihomed sites with multiple prefixes, none of which need to be globally disseminated. Making this multiple prefix architecture work was the charter of the multi6 group. This was constrained in interesting ways, as both NAT box solutions were considered politically unacceptable, as was changing the core functionality of the v6 stack (i.e., redefining the TCP pseudoheader). Given these constraints, it was somewhat unsurprising that NAT got pushed into the host. >From my perspective, we have now explored the dominant quadrants of the solution space and various factions have vociferously denounced all possible solutions. You'll pardon me if some of us are feeling just a tad frustrated. > Every such proposal I've seen > has been ignored or brushed aside by folks who've been doing CIDR for > their entire careers and refuse to even consider that anything else > might be better. More accurately, the folks that have been CIDR advocates 'for their entire careers' are exactly the same folks who have been advocating shifting to something else, but have been rejected by other political elements when trying to propose actual architectural change. Further, those same CIDR advocates have been, and continue to be, in such political disfavor that they are effectively powerless anyhow. It hardly seems like their rejection could count for much. > All this time, energy, and thought spent on shim6 would have been better > spent on a scalable IDR solution. On that, we can agree. However, my feeling is that fully exploring the solution space is an unfortunate necessity before the community is willing to accept changes to the fundamental v6 architecture. > Luckily, we still have another decade or so to come up with something. Unfortunately, that's not entirely true. If the RIR's begin wholesale PI assignment, then we start down the road of re-constituting the v4 routing architecture, locking in additional cost and complexity with each PI prefix. All such prefixes will be indefinitely grandfathered, so even if something new does come along, we will continue to pay for the overhead forever. Regards, Tony
Re: shim6 @ NANOG
On 5-Mar-2006, at 17:03, Stephen Sprunk wrote: All this time, energy, and thought spent on shim6 would have been better spent on a scalable IDR solution. Luckily, we still have another decade or so to come up with something. So the answer to the lack of a routing solution to multi-homing in v6 is to proceed as if we do have one, and hope that one appears at some point in the future before the lack of one causes too much pain? Very little time has been spent on shim6 so far. Far more time before that was spent on multi6, which considered many different approaches to multi-homing. Note that I'm not saying that the IETF process in general (and the multi6/shim6 process in particular) have been without dysfunction; however, I think your characterisation that "there has never been any significant work done on replacing CIDR with something that scales better" is a little misleading. Joe
Re: shim6 @ NANOG
Thus spake "Joe Abley" <[EMAIL PROTECTED]> Was it not the lack of any scalable routing solution after many years of trying that led people to resort to endpoint mobility in end systems, Ã la shim6? Who exactly has been trying to find scalable routing solutions? IPv6 advocates have been pushing a no-PI model for over a decade because that's what ISPs told them to do. When they found end users didn't like that, they went off and developed what has become shim6 as a poor apology. There has never been any significant work done on replacing CIDR with something that scales better. Every such proposal I've seen has been ignored or brushed aside by folks who've been doing CIDR for their entire careers and refuse to even consider that anything else might be better. All this time, energy, and thought spent on shim6 would have been better spent on a scalable IDR solution. Luckily, we still have another decade or so to come up with something. S Stephen Sprunk"Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin
Re: shim6 @ NANOG
On 5-mrt-2006, at 17:37, Christopher L. Morrow wrote: The solution is routing based on geography: give every city of ~ 250k people a /32, and give people who multihome in or near that city a / 48 out of that /32. can the v6 table/space work with 6B /48's? It can if you distribute those 6G prefixes over 6k - 64k routers, so each only has to carry 100k - 1M of those prefixes. Our approximate design goal was 1 multihomers per 10 people in the year 2050. That would be around one billion mulithomers. Today we don't see much more than 1 in 25000 in parts of the world where multihoming is popular, and in most places it isn't. Additionally, how many /32's are there? Does scaling that to each municipality make sense? the arbitrary (I suspect) 250k person limit will quickly devolve into 'any municipality' with much less restriction on it. The idea was having 64k /32s holding 64k /48s each. That means you'll end up with a /32 for each area with around 250k people. Having aggregation below that level doesn't look worthwhile and the number of municipal /32s would become uncomfortably large. Of course people living in small towns aren't left in the cold, it's just that they have to share a /32 with other small towns, the surrounding rural area or fall under a big city close by. 48s that are filtered here are still known. Since every AS still has all the /48s somewhere within the AS, this works without strange requirements such as free transit or interconnection in every city. I think I'm missing how this would work... if I don't have a route to you you don't exist. That's the beauty of aggregation. As an example, your AS could have US routes split into two sets: east of the Mississippi and west of the Mississippi. If you then want to send a packet from Boston to a multihomer in San Diego, the routers in Boston don't carry the /48 for that San Diego multihomer. But there is an aggregate for San Diego, so the packet is sent on its way with help from the aggregate. When the packet hits the first router west of the Mississippi, it is forwarded as per the actual /48. inside a single ASN aggregation may be workable. On the entire network it's going to be much more complex :( As long as each AS carries its customer routers everywhere and announces them to other ASes everywhere, there is no need to coordinate, because the outward behavior of each AS is as before. The only difference is that internally, things happen slightly differently. Obviously strange ways of multihoming (towards ISPs on different continents, for instance) or strange ways of interconnecting (such as ah, like pipex or vnsl or ... name your extra-us provider of choice. From the 'non-NAnog' perspective, what about US carriers in ASPAC that multihome to several pacific island nations at once? Not sure what you mean, but suppose there is an island in the pacific where several US carriers land, but they don't interconnect there. Also suppose that carrier 1 links this island to LA and carrier 2 to Palo Alto. A packet from a customer of carrier 1 to a customer of carrier 2 will flow to LA because the /32 for the island points to LA (not to the island itself because there is no interconnection there). Carrier 2 doesn't have the full set of more specifics for the island in LA (they have those in Palo Alto) but they DO have all their customer routes in LA, so carrier 1 hears the /48 for carrier 2's customer in LA and hands the packet off to carrier 2, which transports it to Palo Alto and on to the island. Return packets will flow from carrier 2 to carrier 1 in Palo Alto. two European networks interconnecting in Chicago) aren't very compatible with geographic aggregation, but who cares about 10% exceptions as long as you can aggregate the other 90%. Enterprises is it 10%? did you measure this? No. The only thing that we can possibly measure is what's in place today, and that's not representative for a situation where we have more than a million multihomers. However, it is to be expected that when we reach the point where there are that many multihomers, there will be some reason to the way multihomers connect to their ISPs. I would expect that the vast majority connects to local or regional ISPs. Even if they don't, it's not going to be that 5% of Paris multihomers connects to Montana, another 5% to Cape Town, 5% to Aruba and so on. If they do at the point that geographical aggregation takes off, they'll find that their traffic takes detours, i.e. a packet from Montana to Paris will first flow to Paris as per the aggregate, then go to the multihomer's ISP, then to Montana where the multihomer connects and finally back to Paris. So they'll have an incentive to multihome to ISPs closer to home but doing that wouldn't be too painful because they don't have to renumber if they used a Paris prefix from the start.
Re: shim6 @ NANOG
On 5-Mar-2006, at 14:16, Owen DeLong wrote: It flies if you look at changing the routing paradigm instead of pushing routing decisions out of the routers and off to the hosts. Source Routing is a technology that most of the internet figured out is problematic years ago. Making source routing more complicated and calling it something else doesn't make it less of a bad idea. Calling shim6 source-routing when it's not in order to give it an aura of evil is similarly unproductive :-) I don't think it will be as expensive as you think to fix it. I think if we start working on a new routing paradigm today in order to support IDR based on AS PATH instead of Prefix, we would realistically see this in deployable workable code within 3-5 years. I'm confused by statements such as these. Was it not the lack of any scalable routing solution after many years of trying that led people to resort to endpoint mobility in end systems, Ã la shim6? Joe
Re: shim6 @ NANOG (forwarded note from John Payne)
At 07:43 AM 4/03/2006, Brandon Ross wrote: On Fri, 3 Mar 2006, Marshall Eubanks wrote: I will bet anyone reading this $ 20 USD right now that what will actually happen is the development of a spot market in IPv4 address space. That's a sucker bet. What's worse is that unless people start changing their tune soon and make the ownership of IP space official, this will be a black market (like it is now, just much bigger). There is a lot to agree with in this statement, but also perhaps more to do that just that - how to support such a market such that uniqueness of current control over address resources is clearly demonstrable is necessary, but so is coherence of transfer of such control between consenting parties. I _think_ you are referring to some form of title registration or similar instrument that could support such a market - yes? cheers, Geoff
Re: shim6 @ NANOG (forwarded note from John Payne)
At 07:37 AM 4/03/2006, Marshall Eubanks wrote: On Mar 3, 2006, at 5:55 AM, Kurt Erik Lindqvist wrote: On 2 mar 2006, at 06.16, Kevin Day wrote: No, I'm just trying to be practical here... Estimates of IPv4 pool exhaustion range from Mid 2008 (Tony Hain's ARIN presentation) to roughly 2012 (Geoff Huston's ARIN presentation). Sooner if a mad dash for space starts happening (or isn't happening already). Does anyone here really believe that there is time for: So what I think we might need (that I wrote in an internet-draft some years ago) is the following things in exactly this order : 0. PI space with an artifically high barrier on entry yet available when needed (read cost+administration=LIR or equiv.). 1. Ducttape ala shim6 2. One of breakthrough in graph-theory or a completely new addressing/routing paradigm. Most like the latter. I will bet anyone reading this $ 20 USD right now that what will actually happen is the development of a spot market in IPv4 address space. That was part of the speculative component of my report at the time, and, no, I won't be lining up to take your bet - I agree with you that such a market is pretty much an inevitably. Of course you could always start a futures market right now! cheers, Geoff .
Re: shim6 @ NANOG
> You are absolutely right that having to upgrade not only all hosts in a > multihomed site, but also all the hosts they communicate with is an > important weakness of shim6. We looked very hard at ways to do this type > of multihoming that would work if only the hosts in the multihomed site > were updated, but that just wouldn't fly. > It flies if you look at changing the routing paradigm instead of pushing routing decisions out of the routers and off to the hosts. Source Routing is a technology that most of the internet figured out is problematic years ago. Making source routing more complicated and calling it something else doesn't make it less of a bad idea. >> In IPv6/shim6 what happens if shim6 has an unanticipated >> bottleneck, security issue, or scaleability problem? Everyone, >> everywhere, has to upgrade at some point. This means that upgrade/ >> workaround has to backwards compatible indefinitely, since it isn't >> going to be possible to force all the world's servers, desktops and >> devices to upgrade by some flag day. > > That's why it's extremely important to get it right the first time. On > the other hand, the fact that shim6 works between just two hosts without > having to upgrade the whole internet first makes it a lot easier to test > and work out the kinks. > Sure, it's really easy to test shim6 between two hosts without involving the internet. I'll buy that. I'm not sure what the benefit of that is supposed to be to the average end user, but, I can accept that as a reason that developers of shim6 might like it. > But again, it cuts both ways: if only two people run shim6 code, those > two people gain shim6 benefits immediately. > Only to the extent that they are talking to each other. If I deploy shim6, but, the top 5000 web sites that my users need to talk to do not, then, there's no benefit whatsoever to shim6 to the majority of my users. > One thing I'll take away from these discussions is that we should > redouble our efforts to support shim6 in middleboxes as an alternative > for doing it in individual hosts, so deployment can be easier. > That's a small step in the right direction. Looking at the possibility to change the fundamental routing paradigm for interdomain routing is probably a better possibility. Of course, these options are not technically mutually exclusive, but, I think the latter will be actually easier to deploy and yield greater benefit. >> The real "injustice" about this is that it's creating two classes >> of organizations on the internet. One that's meets the guidelines >> to get PI space, multihomes with BGP, and can run their whole >> network(including shim6less legacy devices) with full redundancy, >> even when talking to shim6 unaware clients. Another(most likely >> smaller) that can't meet the rules to get PI space, is forced to >> spend money upgrading hardware and software to shim6 compatible >> solution or face a lower reliability than their bigger competitors. > > And that's exactly why it's so hard to come up with a good PI policy: > you can't just impose an arbitrary limit, because that would be anti- > competitive. > A good PI policy is easy. Coming up with a scalable routing solution that supports good PI policy is hard. That's what we should be working on. A good PI policy is "If you need PI space, you get it." What we are trying to come up with in the meantime is a PI policy that will meet the needs of the majority of users while somewhat constraining growth in the routing table until that problem can be solved. (At least that's my intent with 2005-1) >> Someone earlier brought up that a move to shim6, or not being able >> to get PI space was similar to the move to name based vhosting(HTTP/ >> 1.1 shared IP hosting). It is, somewhat. It was developed to allow >> hosting companies to preserve address space, instead of assigning >> one IP address per hostname. (Again, however, this could be done >> slowly, without forcing end users to do anything.) > Yeah, and it worked right up to the point that SSL became improtant and then it pretty much went away as a practical matter. > Tthis isn't that good an analogy. With name based virtual hosting, the > server either is name based or IP based. If you run name based, old HTTP > 1.0 clients won't be served the content they're looking for. So people > running servers had to wait until a large enough percentage of users ran > clients that supported HTTP 1.1 (or HTTP 1.0 with the host: variable). > Fortunately, there was a browser war on at that time so people upgraded > their web browser software relatively often, but it still took a few > years before name based virtual hosting became viable. > And you think it won't be years before shim6 provides tangible benefits? You're dreaming. > Shim6 is completely backward compatible. If either end doesn't support > the protocol, everything still works, but without multihoming benefits >
Re: shim6 @ NANOG
On Sun, 5 Mar 2006, Iljitsch van Beijnum wrote: > > Of course having a TCP session or the like change addresses halfway > through the session may throw stateful firewalls a bit. > I just love that shim6 basically == natv6... It WILL be implemented as such if available to folks in that manner. I do think there wiill be a market for a 'firewall' that is really a shim6 box that 'nat's the internal network behind a single prefix, this is going to be 'fun' (but not in the good way). Oh, not just stateful firewalls... How are you planning on dealing with LEO requests for CALEA when the addr changes mid-stream to some newly arbitrary prefix? What about log correlation on web/content servers? what about loadbalancers that balance on 'flows' ? this is quite the rabbit-hole dorothy jumped down :(
Re: shim6 @ NANOG
ME> Date: Sat, 4 Mar 2006 19:01:14 -0500 ME> From: Marshall Eubanks ME> So, if we gave every active ASN a contiguous IPv6 block, and moved ME> everyone over to IPv6, we would REDUCE the size of the routing table ME> by a factor of 8.28. That would gain several years of growth before ME> the routing table is the size it is now. Exactly. Fragmentation doesn't help... ME> Don't hand these out in contiguous blocks, though. One simple ME> procedure would just be to hand out the first /48 from, say, a /38 ME> and reserve the rest of the /38 for future growth of that ASN. ...and was/is caused by stride-n allocation policies where "n" is too small. (Would any sane software developer use strictly skip lists and unsorted arrays?) Exponential problems need logarithmic solutions. ME> I am sure that better procedures could be arrived at "Allocate from the middle of the largest contiguous block. Align as appropriate." Exponential problems need logarithmic solutions. ME> With luck, that would snowball into actual usage. It depends how forward-thinking people are. A carrot now to avoid a stick later would appear enticing... Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: shim6 @ NANOG
(oh how I'm going to regret jumping into this conversation at point 'here' not at the beginning :( ) On Sun, 5 Mar 2006, Iljitsch van Beijnum wrote: > On 5-mrt-2006, at 5:48, Roland Dobbins wrote: > > > This fundamental misconception of the requirements of large > > enterprise customers should be an indicator to proponents of shim6, > > among others, that they do not have a good grasp of the day-to-day > > operational and business realities faced by large enterprises. > > This lack of understanding has led to such fundamental > > misconceptions as a belief that large enterprises can accept > > frequent renumbering within their organizations based upon changing > > business relationships with their SPs (they cannot, see RFC 4192 > > for some of the reasons why not) > > The solution is routing based on geography: give every city of ~ 250k > people a /32, and give people who multihome in or near that city a / > 48 out of that /32. Since such a /48 will be easy to get, the global can the v6 table/space work with 6B /48's? Assume that in the end-state each 'person' is multi-homed: 802.11 + cell + cable + gprs. Also though a /48 is quite large for a single person there will be something (most likely) to interconnect each family member in a household most likely as well... or there might be :) who knows. Additionally, how many /32's are there? Does scaling that to each municipality make sense? the arbitrary (I suspect) 250k person limit will quickly devolve into 'any municipality' with much less restriction on it. > routing table will fill up with these /48s relatively quickly, and at > some point it will start to look attractive to filter some of them > out in part of an AS. This can be done without trouble by adding a > few /32 aggregates that point towards the part of the AS where the / For a single provider situation this might work, MIGHT. For a multi-provider world, like the one we live in today, it seems doubtful that this will scale... Unless we implement 'default to the left' or something of that sort (pass default to the guy on your left, hope he knows where west-kalamzoo's /32 is in the network) > 48s that are filtered here are still known. Since every AS still has > all the /48s somewhere within the AS, this works without strange > requirements such as free transit or interconnection in every city. > I think I'm missing how this would work... if I don't have a route to you you don't exist. I have to have a default to 'somewhere' or a route, it seems fairly simple to me... see 'default to the left' above (also not a good solution, but :) ) > So what do we need to get this off the ground? New allocation > policies. As long as the number of geo PI prefixes is smaller than > what comfortably fits inside routers that's all. If the global > routing table continues to grow transit ASes will have to choose > between buying more expensive routers or adding complexity by > implementing geographic aggregation using BGP filters. > inside a single ASN aggregation may be workable. On the entire network it's going to be much more complex :( > Obviously strange ways of multihoming (towards ISPs on different > continents, for instance) or strange ways of interconnecting (such as ah, like pipex or vnsl or ... name your extra-us provider of choice. From the 'non-NAnog' perspective, what about US carriers in ASPAC that multihome to several pacific island nations at once? > two European networks interconnecting in Chicago) aren't very > compatible with geographic aggregation, but who cares about 10% > exceptions as long as you can aggregate the other 90%. Enterprises is it 10%? did you measure this? or did Geoff? or Randy? or KC? > will have to choose between individual geo /48s in every location or > becoming their own ISP with a /32 and backhaul traffic between > locations themselves.
Re: shim6 @ NANOG
On 5-mrt-2006, at 12:09, Ian Dickinson wrote: As an irrelevent aside, when someone comes up with a way to firewall/acl shim6, how much breaks? The idea is that there will be a shim6 header that can do two things: carry shim6 signalling and carry data packets with rewritten addresses after a rehoming. Since data packets with rewritten addresses can only occur after there have been shim6 signalling packets on the same path, filtering out packets with the shim6 header on the initially chosen path makes it impossible for the shim state to be created so there is no multihoming. If shim packets are allowed on the initially chosen path but not on the backup path, shim6 (un) reachability detection won't work over the backup path so the backup path will be considered broken and won't be used. In other words: you fall back to single homing without ill effects. Of course having a TCP session or the like change addresses halfway through the session may throw stateful firewalls a bit.
Re: shim6 @ NANOG
On 5-mrt-2006, at 5:48, Roland Dobbins wrote: This fundamental misconception of the requirements of large enterprise customers should be an indicator to proponents of shim6, among others, that they do not have a good grasp of the day-to-day operational and business realities faced by large enterprises. This lack of understanding has led to such fundamental misconceptions as a belief that large enterprises can accept frequent renumbering within their organizations based upon changing business relationships with their SPs (they cannot, see RFC 4192 for some of the reasons why not) Ok, let me show you a trick I learned recently. I'm going to agree with you (although like everything else, the "need" for stable addresses can be translated into money, at some point it makes sense to renumber), and tell you I have the solution that fixes all of this, doesn't cost any money, no new code, nothing. Then after this, you'll see that nobody replies to this message and we simply go on arguing about the relative evil of PI in IPv6 vs that of shim6. The solution is routing based on geography: give every city of ~ 250k people a /32, and give people who multihome in or near that city a / 48 out of that /32. Since such a /48 will be easy to get, the global routing table will fill up with these /48s relatively quickly, and at some point it will start to look attractive to filter some of them out in part of an AS. This can be done without trouble by adding a few /32 aggregates that point towards the part of the AS where the / 48s that are filtered here are still known. Since every AS still has all the /48s somewhere within the AS, this works without strange requirements such as free transit or interconnection in every city. So what do we need to get this off the ground? New allocation policies. As long as the number of geo PI prefixes is smaller than what comfortably fits inside routers that's all. If the global routing table continues to grow transit ASes will have to choose between buying more expensive routers or adding complexity by implementing geographic aggregation using BGP filters. Obviously strange ways of multihoming (towards ISPs on different continents, for instance) or strange ways of interconnecting (such as two European networks interconnecting in Chicago) aren't very compatible with geographic aggregation, but who cares about 10% exceptions as long as you can aggregate the other 90%. Enterprises will have to choose between individual geo /48s in every location or becoming their own ISP with a /32 and backhaul traffic between locations themselves.
Re: shim6 @ NANOG
On 4-Mar-2006, at 23:48, Roland Dobbins wrote: On Mar 4, 2006, at 7:06 PM, Joe Abley wrote: No support in big networks is required, beyond the presence of shim6 in server stacks. Why do you say this? Enterprises who multihome need their client machines (tens and hundreds of thousands of them) to be able to take advantage of multihoming, as well. It's a requirement, not a luxury. You're missing the context; by "big networks" I was referring to those who are able to obtain PI addresses, following from: On 4-Mar-2006, at 16:31, Matthew Petach wrote: And given that any network big enough to get their own PI /32 has *zero* incentive to install/support shim6 [...] [I didn't mean to imply that enterprise networks weren't big or complicated.] Joe
Re: shim6 @ NANOG
On 4-mrt-2006, at 22:31, Matthew Petach wrote: And given that any network big enough to get their own PI /32 has *zero* incentive to install/support shim6 means that all those smaller networks that are pushed to install shim6 are going to see *zero* benefit when they try to reach the major sites on the internet. A case can be made that some big sites sitting high and dry wouldn't care enough about their customers to do shim6 with them if they're multihomed using shim6, but that's not the same thing as there being zero benefit. Especially in a competitive market place: what if Hotmail runs shim6 so that multihomed Hotmail users can keep sending mail even when one ISP fails, while Gmail doesn't? You assume that all the big sites will get PI /32s and that this will allow them to multihome the way they want. I'm sure _some_ big sites will get a /32 or /48 or other PI block, but it remains to be seen whether all do. And having a single block isn't enough if you connect to the net in various locations but don't want to backhaul traffic between those locations yourself. Yes, this is an issue. If we have to wait for a major release or even a service pack, that will take some time. But OS vendors have software update mechanisms in place so they could send out shim6 code in between. And no major company supports/allows automated software update mechanisms Dit I use the word "automated"? But again, it cuts both ways: if only two people run shim6 code, those two people gain shim6 benefits immediately. Cool. So let individuals make a choice to install it if they want. But that's a choice they make, and should not be part of a mandated IP allocation policy Nobody is forced to implement shim6 if they don't want. But not liking shim6 doesn't buy you PI in IPv6. shim6 is _more_ anti-competitive than extending the existing IP allocation policies from v4 into v6, and is therefore not going to garner the support of the companies that actually spend money to create this thing we call the Internet. And without money behind it, the effort is a non-starter. 2 million prefixes in a router that supports 1 million is also a non- starter. Insisting that shim6 isn't going to work is a waste of time, because it doesn't do anything to make shim6 better so it could work or create alternatives, it just adds FUD. I have more faith in our ability to deal with route table growth than I do in our ability to come up with a viable instantiation of shim6. Engineering based on faith is insane. Even with today's science we have balconies falling off of appartment buildings and roofs collapsing when it rains or snows a bit harder than usual, so a little caution here and there isn't too much to ask for.
Re: shim6 @ NANOG (forwarded note from John Payne)
On 4 mar 2006, at 17.43, Steven M. Bellovin wrote: On Sat, 4 Mar 2006 13:59:18 +0100 Kurt Erik Lindqvist <[EMAIL PROTECTED]> wrote: On 3 mar 2006, at 04.13, Marshall Eubanks wrote: I would be surprised if Shim6 going into actual deployed boxes was any faster. So, if Shim6 was finalized today, which it won't be, in 2010 we might have 70% deployment and in 2012 we might have 90% deployment. OTOH Teredo, which isn't even a standard is in more or less all Windows XP boxes Teredo is described in RFC 4380; it's a Proposed Standard. Duh. Given I was part of the discussion of which prefixes to use in the document I should have remembered that... Still it was deployed way before that. - kurtis -
Re: shim6 @ NANOG (forwarded note from John Payne)
Thus spake "Mark Newton" <[EMAIL PROTECTED]> On Fri, Mar 03, 2006 at 09:50:55PM +0100, Iljitsch van Beijnum wrote: > On 3-mrt-2006, at 21:43, Brandon Ross wrote: > >What's worse is that unless people start changing their tune soon > >and make the ownership of IP space official, this will be a black > >market (like it is now, just much bigger). > > But that will end as soon as interdomain routing is protected by > certificates given out by the RIRs. No, it'll end as soon as those certificates become mandatory. Which will, in my humble estimation, happen at some point near the year 4523. I agree that RIR certs will never become truly mandatory, but it'll be a Good Idea(tm) to have one to prevent hijacking. However, some bright accountant at a big telco is going to figure out it's not RIR certs they want to see -- they'll want to issue their own certs to squeeze revenue from non-customers. "You want to buy transit from our peers instead of us? That's great. But, if you want reliable access to our customers from your PI block, you have to pay $100/mo for a routing slot." Bingo, the swamp problem becomes self-correcting. S Stephen Sprunk"Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin
Re: shim6 @ NANOG
On Mar 4, 2006, at 7:06 PM, Joe Abley wrote: No support in big networks is required, beyond the presence of shim6 in server stacks. Why do you say this? Enterprises who multihome need their client machines (tens and hundreds of thousands of them) to be able to take advantage of multihoming, as well. It's a requirement, not a luxury. [Note that I do not address the blurring of client and server roles which is happening even now, and which will almost certainly become more prevalent over the anticipated lifetime of the success protocol to IPv4.] This fundamental misconception of the requirements of large enterprise customers should be an indicator to proponents of shim6, among others, that they do not have a good grasp of the day-to-day operational and business realities faced by large enterprises. This lack of understanding has led to such fundamental misconceptions as a belief that large enterprises can accept frequent renumbering within their organizations based upon changing business relationships with their SPs (they cannot, see RFC 4192 for some of the reasons why not), as well as underestimating the importance of multihoming for client computers as well as servers. shim6 is simply not viable for large enterprises, who are the customers who require multihoming. I would argue that it's not really viable for smaller organizations either, due to the complexity it adds to the troubleshooting matrix for support staff. I hope that the operational community will turn to more fruitful lines of enquiry regarding IPv6 multihoming. -- Roland Dobbins <[EMAIL PROTECTED]> // 408.527.6376 voice Everything has been said. But nobody listens. -- Roger Shattuck
Re: shim6 @ NANOG (forwarded note from John Payne)
On Fri, Mar 03, 2006 at 09:50:55PM +0100, Iljitsch van Beijnum wrote:
> On 3-mrt-2006, at 21:43, Brandon Ross wrote:
> >What's worse is that unless people start changing their tune soon
> >and make the ownership of IP space official, this will be a black
> >market (like it is now, just much bigger).
>
> But that will end as soon as interdomain routing is protected by
> certificates given out by the RIRs.
No, it'll end as soon as those certificates become mandatory.
Which will, in my humble estimation, happen at some point near the
year 4523.
("Hey, guys, you're all using these CIDR blocks which have real
monetary value, how about you all agree to deploy this technology
which will make them all valueless again? Huh? Hello? Anyone
listening? Where'd everyone go?")
- mark
--
Mark Newton Email: [EMAIL PROTECTED] (W)
Network Engineer Email: [EMAIL PROTECTED] (H)
Internode Systems Pty Ltd Desk: +61-8-82282999
"Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223
Re: shim6 @ NANOG
On 4-Mar-2006, at 16:31, Matthew Petach wrote: And given that any network big enough to get their own PI /32 has *zero* incentive to install/support shim6 means that all those smaller networks that are pushed to install shim6 are going to see *zero* benefit when they try to reach the major sites on the internet. No support in big networks is required, beyond the presence of shim6 in server stacks. The assumption is, therefore, that if there has been sufficient deployment of shim6 in client stacks for this to matter, the chances are that the servers that those clients want to talk to have already enjoyed similar upgrades. In the companies I have been involved in which do hosting, my observation has been that the servers are generally upgraded and patched far more vigourously than machines belonging to clients. If that non-scientific observation holds any water, then this suggests that the issue of shim6 support in servers which are being used by shim6-capable clients will look after itself. Joe
Re: shim6 @ NANOG
Hello; On Mar 4, 2006, at 4:31 PM, Matthew Petach wrote: On 3/4/06, Iljitsch van Beijnum <[EMAIL PROTECTED]> wrote: On 4-mrt-2006, at 14:07, Kevin Day wrote: >> We got lucky with CIDR because even though all default free >> routers had to be upgraded in a short time, it really wasn't that >> painful. [Because there was no need to renumber] > Isn't that an excellent argument against shim6 though? > In IPv4, something unanticipated occurred by the original developers > (the need for CIDR), and everyone said "Oh, thank god that all we > have to do is upgrade DFZ routers." You are absolutely right that having to upgrade not only all hosts in a multihomed site, but also all the hosts they communicate with is an important weakness of shim6. We looked very hard at ways to do this type of multihoming that would work if only the hosts in the multihomed site were updated, but that just wouldn't fly. And given that any network big enough to get their own PI /32 has *zero* incentive to install/support shim6 means that all those smaller networks that are pushed to install shim6 are going to see *zero* benefit when they try to reach the major sites on the internet. What benefit does shim6 bring, if only the little guys are using it? This dog won't hunt. Move on to something useful. Yes, this is an issue. If we have to wait for a major release or even a service pack, that will take some time. But OS vendors have software update mechanisms in place so they could send out shim6 code in between. And no major company supports/allows automated software update mechanisms to run on their production machines--it adds too much of an element of randomness to an environment that has to be as much as possible deterministic in its behaviour. But again, it cuts both ways: if only two people run shim6 code, those two people gain shim6 benefits immediately. Cool. So let individuals make a choice to install it if they want. But that's a choice they make, and should not be part of a mandated IP allocation policy, because otherwise we're codifying a split between "big" companies and everyone else. The companies that can justify /32 allocations _aren't_ going to install shim6; they already have their multihoming options (for the most part) covered--so the little guys who install shim6 to "multihome" are going to discover it doesn't do diddly squat for helping them reach any major sites on the internet during an outage of one of their providers. You haven't preserved end-to-end connectivity this way, you've just waved a pretty picture in front of the smaller company's face to make them think they'll have the benefits of multihoming when they really don't. Even guys in the middle may not. If I am streaming for profit, and if I am comfortable with my bandwidth suppliers (or if I am multihoming one way or another), then why should I spend a dime installing and running shim6 ? If you (an end user in a SOHO with 2 connections say) go down for 5 minutes once per day, that's too bad, but the ad revenue I would lose would be tiny, and you wouldn't blame me for the outage, you would blame your provider. Also, qn outage may hurt you with 100% probability, but it will only hurt me if it happens while you are using my services, which will probably be < 100% of the time. Again, the downside to me from your outages is very small. So, my feeling is that most content providers would be very slow to adopt this. > Getting systems not controlled by the networking department of an > organization upgraded, when it's for reasons that are not easily > visible to the end user, will be extraordinarily difficult to start > with. Adding shim6 at all to hosts will be one fight. Any upgrades > or changes later to add features will be another. One thing I'll take away from these discussions is that we should redouble our efforts to support shim6 in middleboxes as an alternative for doing it in individual hosts, so deployment can be easier. Won't matter. shim6 on a middle box still won't be able to re- route to the majority of the large sites on the Internet during an outage on one of the upstream providers given that the large content players and large network providers aren't going to be installing shim6 on their servers and load balancers. I could see a business built around integrating shim6 into a proxy, such that an end user with two connections runs shim6 to get to an outside proxy (which could be very multihomed) and the proxy gets the packets to ordinary (non shim6) sites. This is under the model that my home office may need shim6 for multi- homing, but AOL or Google will not, and thus won't be supporting it. So I wouldn't count it out even if deployment is << 100%. But that is of course not a reason to have it drive address allocation policies. > The real "injustice" about this is that it's creating two classes > of organizations on the internet. One that's me
Re: shim6 @ NANOG
On 3/4/06, Iljitsch van Beijnum <[EMAIL PROTECTED]> wrote: On 4-mrt-2006, at 14:07, Kevin Day wrote:>> We got lucky with CIDR because even though all default free>> routers had to be upgraded in a short time, it really wasn't that>> painful. [Because there was no need to renumber]> Isn't that an excellent argument against shim6 though?> In IPv4, something unanticipated occurred by the original developers> (the need for CIDR), and everyone said "Oh, thank god that all we > have to do is upgrade DFZ routers."You are absolutely right that having to upgrade not only all hosts ina multihomed site, but also all the hosts they communicate with is animportant weakness of shim6. We looked very hard at ways to do this type of multihoming that would work if only the hosts in themultihomed site were updated, but that just wouldn't fly.And given that any network big enough to get their own PI /32 has *zero* incentive to install/support shim6 means that all those smaller networksthat are pushed to install shim6 are going to see *zero* benefit when theytry to reach the major sites on the internet.What benefit does shim6 bring, if only the little guys are using it? This dog won't hunt. Move on to something useful.Yes, this is an issue. If we have to wait for a major release or even a service pack, that will take some time. But OS vendors havesoftware update mechanisms in place so they could send out shim6 codein between.And no major company supports/allows automated software update mechanisms to run on their production machines--it adds too much of an element of randomness to an environment that has to be as muchas possible deterministic in its behaviour. But again, it cuts both ways: if only two people run shim6 code,those two people gain shim6 benefits immediately.Cool. So let individuals make a choice to install it if they want. Butthat's a choice they make, and should not be part of a mandated IP allocation policy, because otherwise we're codifying a split between"big" companies and everyone else. The companies that can justify /32allocations _aren't_ going to install shim6; they already have their multihoming options (for the most part) covered--so the little guys whoinstall shim6 to "multihome" are going to discover it doesn't do diddlysquat for helping them reach any major sites on the internet during an outage of one of their providers. You haven't preserved end-to-endconnectivity this way, you've just waved a pretty picture in front of thesmaller company's face to make them think they'll have the benefits of multihoming when they really don't.> Getting systems not controlled by the networking department of an > organization upgraded, when it's for reasons that are not easily> visible to the end user, will be extraordinarily difficult to start> with. Adding shim6 at all to hosts will be one fight. Any upgrades > or changes later to add features will be another.One thing I'll take away from these discussions is that we shouldredouble our efforts to support shim6 in middleboxes as analternative for doing it in individual hosts, so deployment can be easier.Won't matter. shim6 on a middle box still won't be able to re-route to themajority of the large sites on the Internet during an outage on one of theupstream providers given that the large content players and large network providers aren't going to be installing shim6 on their servers and loadbalancers. > The real "injustice" about this is that it's creating two classes> of organizations on the internet. One that's meets the guidelines> to get PI space, multihomes with BGP, and can run their whole > network(including shim6less legacy devices) with full redundancy,> even when talking to shim6 unaware clients. Another(most likely> smaller) that can't meet the rules to get PI space, is forced to > spend money upgrading hardware and software to shim6 compatible> solution or face a lower reliability than their bigger competitors.And that's exactly why it's so hard to come up with a good PI policy: you can't just impose an arbitrary limit, because that would be anti-competitive.You failed to note that the smaller company, *even after spending moneyupgrading hardware and software to shim6 compatible solution* won't achieve the same reliability as their bigger competitors. (see above if you missed it).shim6 is _more_ anti-competitive than extending the existing IP allocationpolicies from v4 into v6, and is therefore not going to garner the support of the companies that actually spend money to create this thing we call theInternet. And without money behind it, the effort is a non-starter. > Someone earlier brought up that a move to shim6, or not being able> to get PI space was similar to the move to name based vhosting(HTTP/> 1.1 shared IP hosting). It is, somewhat. It was developed to allow > hosting companies to preserve address space, instead of assigning> one IP address per hostname. (Again, however, this could be done> slowly, without forcing end users to do any
Re: shim6 @ NANOG
On 4-mrt-2006, at 14:07, Kevin Day wrote: We got lucky with CIDR because even though all default free routers had to be upgraded in a short time, it really wasn't that painful. [Because there was no need to renumber] Isn't that an excellent argument against shim6 though? In IPv4, something unanticipated occurred by the original developers (the need for CIDR), and everyone said "Oh, thank god that all we have to do is upgrade DFZ routers." You are absolutely right that having to upgrade not only all hosts in a multihomed site, but also all the hosts they communicate with is an important weakness of shim6. We looked very hard at ways to do this type of multihoming that would work if only the hosts in the multihomed site were updated, but that just wouldn't fly. In IPv6/shim6 what happens if shim6 has an unanticipated bottleneck, security issue, or scaleability problem? Everyone, everywhere, has to upgrade at some point. This means that upgrade/ workaround has to backwards compatible indefinitely, since it isn't going to be possible to force all the world's servers, desktops and devices to upgrade by some flag day. That's why it's extremely important to get it right the first time. On the other hand, the fact that shim6 works between just two hosts without having to upgrade the whole internet first makes it a lot easier to test and work out the kinks. If it requires an OS update to add a feature, you can't rely on having 90% penetration within YEARS of it being released. After XP Service Pack 2 was released, only 24% had upgraded after 9 months. According to one of our website's stats, we still see 5% of our users on Windows 98, and 13% on Windows 2000. Yes, this is an issue. If we have to wait for a major release or even a service pack, that will take some time. But OS vendors have software update mechanisms in place so they could send out shim6 code in between. But again, it cuts both ways: if only two people run shim6 code, those two people gain shim6 benefits immediately. Getting systems not controlled by the networking department of an organization upgraded, when it's for reasons that are not easily visible to the end user, will be extraordinarily difficult to start with. Adding shim6 at all to hosts will be one fight. Any upgrades or changes later to add features will be another. One thing I'll take away from these discussions is that we should redouble our efforts to support shim6 in middleboxes as an alternative for doing it in individual hosts, so deployment can be easier. In an enterprise environment, you're not talking the DBA of your Oracle box into installing service packs, upgrades or new software just because you want to use a new routing feature that wasn't around when their OS was released. I know of several enterprises still running NT 4.0 and Mac OS 9 boxes for some legacy applications. Ah, but in the world of shim6 "legacy" takes on a whole new meaning, because it relates to today's IPv6 which the OSes you mention don't even implement. (-: And don't forget that in enterprises, most boxes don't talk directly (or at least not much) to the outside world. The real "injustice" about this is that it's creating two classes of organizations on the internet. One that's meets the guidelines to get PI space, multihomes with BGP, and can run their whole network(including shim6less legacy devices) with full redundancy, even when talking to shim6 unaware clients. Another(most likely smaller) that can't meet the rules to get PI space, is forced to spend money upgrading hardware and software to shim6 compatible solution or face a lower reliability than their bigger competitors. And that's exactly why it's so hard to come up with a good PI policy: you can't just impose an arbitrary limit, because that would be anti- competitive. Someone earlier brought up that a move to shim6, or not being able to get PI space was similar to the move to name based vhosting(HTTP/ 1.1 shared IP hosting). It is, somewhat. It was developed to allow hosting companies to preserve address space, instead of assigning one IP address per hostname. (Again, however, this could be done slowly, without forcing end users to do anything.) Tthis isn't that good an analogy. With name based virtual hosting, the server either is name based or IP based. If you run name based, old HTTP 1.0 clients won't be served the content they're looking for. So people running servers had to wait until a large enough percentage of users ran clients that supported HTTP 1.1 (or HTTP 1.0 with the host: variable). Fortunately, there was a browser war on at that time so people upgraded their web browser software relatively often, but it still took a few years before name based virtual hosting became viable. Shim6 is completely backward compatible. If either end doesn't support the protocol, everything stil
Re: shim6 @ NANOG (forwarded note from John Payne)
On Mar 4, 2006, at 11:43 AM, Steven M. Bellovin wrote: On 3 mar 2006, at 04.13, Marshall Eubanks wrote: I would be surprised if Shim6 going into actual deployed boxes was any faster. So, if Shim6 was finalized today, which it won't be, in 2010 we might have 70% deployment and in 2012 we might have 90% deployment. OTOH Teredo, which isn't even a standard is in more or less all Windows XP boxes Teredo is described in RFC 4380; it's a Proposed Standard. I should note that Microsoft really believes in IPv6. I wonder what that means for its future Let's hope it means that they'll eventually come up with nicer ways to configure IPv6 stacks in Windows flavors than they have this far...
Re: shim6 @ NANOG (forwarded note from John Payne)
On Sat, 4 Mar 2006 13:59:18 +0100 Kurt Erik Lindqvist <[EMAIL PROTECTED]> wrote: > > > On 3 mar 2006, at 04.13, Marshall Eubanks wrote: > > > I would be surprised if Shim6 going into actual deployed boxes was > > any faster. So, if Shim6 was finalized today, which it won't be, > > in 2010 we might have 70% deployment and in 2012 we might have 90% > > deployment. > > OTOH Teredo, which isn't even a standard is in more or less all > Windows XP boxes > Teredo is described in RFC 4380; it's a Proposed Standard. I should note that Microsoft really believes in IPv6. I wonder what that means for its future
Re: shim6 @ NANOG (forwarded note from John Payne)
On Mar 4, 2006, at 8:03 AM, Kurt Erik Lindqvist wrote: On 3 mar 2006, at 21.37, Marshall Eubanks wrote: I will bet anyone reading this $ 20 USD right now that what will actually happen is the development of a spot market in IPv4 address space. I won't bet against you, but it will only take you that far. At one point IPv4 addresses will just be black tulips... - kurtis - Be careful. If a /24 becomes worth briefly a landed estate (roughly what the reference translates too), I suspect that a lot of the readers of this list (but not, alas, me) would retire happy. Regards Marshall
Re: shim6 @ NANOG (forwarded note from John Payne)
On 3 mar 2006, at 21.37, Marshall Eubanks wrote: I will bet anyone reading this $ 20 USD right now that what will actually happen is the development of a spot market in IPv4 address space. I won't bet against you, but it will only take you that far. At one point IPv4 addresses will just be black tulips... - kurtis -
Re: shim6 @ NANOG (forwarded note from John Payne)
On 3 mar 2006, at 04.13, Marshall Eubanks wrote: I would be surprised if Shim6 going into actual deployed boxes was any faster. So, if Shim6 was finalized today, which it won't be, in 2010 we might have 70% deployment and in 2012 we might have 90% deployment. OTOH Teredo, which isn't even a standard is in more or less all Windows XP boxes - kurtis -
Re: shim6 @ NANOG
On Mar 4, 2006, at 2:21 AM, Iljitsch van Beijnum wrote: ... which is what I expect to happen. A few folks will see it coming, design a fix, and everyone will deploy it overnight when they discover they have no other choice. Isn't that about what happened with CIDR, in a nutshell? We got lucky with CIDR because even though all default free routers had to be upgraded in a short time, it really wasn't that painful. Isn't that an excellent argument against shim6 though? In IPv4, something unanticipated occurred by the original developers (the need for CIDR), and everyone said "Oh, thank god that all we have to do is upgrade DFZ routers." Eventually all hosts got CIDR routing, but it didn't break anything if you didn't. In IPv6/shim6 what happens if shim6 has an unanticipated bottleneck, security issue, or scaleability problem? Everyone, everywhere, has to upgrade at some point. This means that upgrade/workaround has to backwards compatible indefinitely, since it isn't going to be possible to force all the world's servers, desktops and devices to upgrade by some flag day. If it requires an OS update to add a feature, you can't rely on having 90% penetration within YEARS of it being released. After XP Service Pack 2 was released, only 24% had upgraded after 9 months. According to one of our website's stats, we still see 5% of our users on Windows 98, and 13% on Windows 2000. Getting systems not controlled by the networking department of an organization upgraded, when it's for reasons that are not easily visible to the end user, will be extraordinarily difficult to start with. Adding shim6 at all to hosts will be one fight. Any upgrades or changes later to add features will be another. I don't think (many) operators are really dreading having to eventually and slowly upgrade their DFZ routers to support 32 bit ASNs. It'll require an OS upgrade, probably an upgrade to a few tools (netflow parsers, etc), but nothing customer impacting. There will be a crossover period where the software will be available but no 32-bit ASNs will be visible, until one day some unlucky sap gets AS65536 and guinea-pigs the internet. It's a networking problem being solved by the guys who run the network, and it can get done in a reasonable timeframe, without bothering end users, other departments or touching boxes outside the network admin's control. In an enterprise environment, you're not talking the DBA of your Oracle box into installing service packs, upgrades or new software just because you want to use a new routing feature that wasn't around when their OS was released. I know of several enterprises still running NT 4.0 and Mac OS 9 boxes for some legacy applications. A parallel to that is going to still be happening in the next 4-8 years when shim6 would have to prove itself. There are going to be enterprises, end users, database servers, and embedded devices that have IPv6 support because they shipped with it (XP, Vista, OS X, Solaris, etc), but don't have shim6 support. The services either get an expensive upgrade or lose out on multihoming. The real "injustice" about this is that it's creating two classes of organizations on the internet. One that's meets the guidelines to get PI space, multihomes with BGP, and can run their whole network (including shim6less legacy devices) with full redundancy, even when talking to shim6 unaware clients. Another(most likely smaller) that can't meet the rules to get PI space, is forced to spend money upgrading hardware and software to shim6 compatible solution or face a lower reliability than their bigger competitors. Someone earlier brought up that a move to shim6, or not being able to get PI space was similar to the move to name based vhosting(HTTP/1.1 shared IP hosting). It is, somewhat. It was developed to allow hosting companies to preserve address space, instead of assigning one IP address per hostname. (Again, however, this could be done slowly, without forcing end users to do anything.) ARIN's policy is that you should use name based hosting wherever possible. However, if you're not using name based hosting(blowing through many IPs that could be consolidated if you didn't), all that's asked is that you justify why you can't/won't do it that way on your application for PI space. If IPv6 PI space worked the same way - If you could justify why shim6 isn't sufficient for your network, and receive PI space... I'd have zero objections to anything shim6 wanted to do. Let those who want to use it use it, and let those who can't do what they need to do use the existing alternatives. People aren't going to frivolously pay the yearly fees for an ASN and address space unless they truly believe they need it, and it would completely level the playing field. Small businesses won't have an unfair disadvantage to their larger competitors who get PI sp
Re: shim6 @ NANOG
On 4-mrt-2006, at 3:05, Stephen Sprunk wrote: The alternative, of course, is to wait for IDR to implode and let the finger-pointing begin. ... which is what I expect to happen. A few folks will see it coming, design a fix, and everyone will deploy it overnight when they discover they have no other choice. Isn't that about what happened with CIDR, in a nutshell? We got lucky with CIDR because even though all default free routers had to be upgraded in a short time, it really wasn't that painful. Ok, I wasn't there, but what I mean is that the problem was solved by aggregating already deployed address space, which isn't going to fly if excessive PI makes IDR implode in the future. I've been in multi6, two multi6 design teams and shim6 for nearly five years, and I've seen many of the smartest people in the IETF community join in. I can tell you this: the only scalable solutions on the horizon are: - moving multihoming related state out of the DFZ (this is what shim6 does) - remove the requirement that every DFZ router carries every prefix, which can't be done as long as PI blocks sit at the top of the addressing hierarchy There are many aspects to current IDR that can stand to be improvemed, but at the end of the day that doesn't shrink your FIB by orders of magnitude. The closest thing to a magic, pain-free solution would be to allocate PI blocks such that it's possible to aggregate them together and ignore the more specifics for far away regions of the world, so that in 2030 you don't have to carry 6 Chinese PI blocks world wide that all sit behind the same Great Firewall anyway, but no, that doesn't make sense because how can I multihome to ISPs in Shainghai and Toronto then, this will never work.
Re: shim6 @ NANOG (forwarded note from John Payne)
One thing that Geoff hasn't been cynical enough to put forward is the idea that orgs with lots of valuable, monetized address space may very well end up lobbying the IAB and RIRs to erect new cost structures around green-fields IPv6 allocations as well, to make sure that the profit-providing marketplace survives for as long as possible by making the IPv6 migration process as expensive and inconvenient as possible. I'd suggest that there is no need to do so, as that particular reality is already in place. For customers its still just mail, its still just google, ebay, yahoo, etc. Why should they pay their ISP any more money to have the packets colored red, blue or green? Or use 32 bit address fields in their packets or 128bits? The barriers to IPv6 adoption are already in place in terms of a customer-unfunded transition to get effectively to a place thats not very much different from where they were when they started. It really doesn't make much sense does it? What will happen when the MCI's of the world discover that the race to $0 for IP transit prices has created a world in which they make more money by selling their IPv4 addresses than they make by selling Internet access? Will we see them coming out as a strong supporter of restrictive RIR policies and IPv6 technologies which don't work as a way of artificially boosting the price of IPv6? The real question for such holders is when to sell. In a market with rising demand and insufficient supply, the typical seller's strategy is to hang on to further exacerbate demand. At what point such behaviour results in collapse of the market as buyers find the substitution of IPv6 viable is the key question for the seller. It's going to be a fun ride :-) indeed. Geoff
Re: shim6 @ NANOG
>> The alternative, of course, is to wait for IDR to implode and let the >> finger-pointing begin. > > ... which is what I expect to happen. A few folks will see it coming, > design a fix, and everyone will deploy it overnight when they discover > they have no other choice. Isn't that about what happened with CIDR, in > a nutshell? Actually, no. For the most part, folks realized that the swamp didn't scale and they were willing to deploy the fix well before things would have actually imploded. Furthermore, the fix and the associated angst were far less painful and time consuming to deploy than an entirely new architecture will be. In short, they were better 'netizens' in that they could see a distant wall coming and act decisively well before panic set in. Tony
Re: shim6 @ NANOG (forwarded note from John Payne)
>>> On 3-mrt-2006, at 11:30, [EMAIL PROTECTED] wrote: The term LIR is used in IPv6 allocation policy in all regions >> no > Hmm...sure looks like it to me i stand corrected. apologies. randy
Re: shim6 @ NANOG
SS> Date: Fri, 3 Mar 2006 20:05:36 -0600 SS> From: Stephen Sprunk SS> > Unfortunately, that involves change from the status quo, and thus SS> > altruistic action. SS> SS> Only when self-interest and altruism are coincident is the latter SS> consistently achieved. Witness BCP38, spam/worm cleanup, prefix deaggregation. If the past is any indication of the future... SS> > The alternative, of course, is to wait for IDR to implode and let the SS> > finger-pointing begin. SS> SS> ... which is what I expect to happen. A few folks will see it coming, SS> design a fix, and everyone will deploy it overnight when they discover they SS> have no other choice. Isn't that about what happened with CIDR, in a SS> nutshell? Those who do not study (or remember) history... Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: shim6 @ NANOG
Thus spake "Tony Li" <[EMAIL PROTECTED]> I'm more confident that we'll find an answer to the IDR problem sooner than we'll convince people to act in the good of the community at their own expense. The solution to the IDR problem is to have a scalable routing architecture. Unfortunately, that involves change from the status quo, and thus altruistic action. Not if/when folks understand that the implosion is imminent and the only way to preserve their business is to build a better routing architecture. Only when self-interest and altruism are coincident is the latter consistently achieved. The alternative, of course, is to wait for IDR to implode and let the finger-pointing begin. ... which is what I expect to happen. A few folks will see it coming, design a fix, and everyone will deploy it overnight when they discover they have no other choice. Isn't that about what happened with CIDR, in a nutshell? S Stephen Sprunk"Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin
Re: shim6 @ NANOG (forwarded note from John Payne)
On Fri, Mar 03, 2006 at 09:50:55PM +0100, Iljitsch van Beijnum wrote: > > On 3-mrt-2006, at 21:43, Brandon Ross wrote: > > >>I will bet anyone reading this $ 20 USD right now that what will > >>actually happen is the development of a spot market in IPv4 > >>address space. > > >That's a sucker bet. > > >What's worse is that unless people start changing their tune soon > >and make the ownership of IP space official, this will be a black > >market (like it is now, just much bigger). > > But that will end as soon as interdomain routing is protected by > certificates given out by the RIRs. er, not at all. RIR's issuing certificates and expecting the routing system to kowtow is a stretch. --bill
Re: shim6 @ NANOG (forwarded note from John Payne)
On Fri, Mar 03, 2006 at 10:30:44AM +, [EMAIL PROTECTED] wrote: > > > > If you feel you should qualify as an LIR, > > > > With RIPE, an LIR is simply an organization that pays the membership > > fee and thus gets to submit requests for address space and AS > > numbers. ARIN doesn't seem to use this terminology except in their > > IPv6 address allocation policy. > > That's what we were talking about. Shim6 and IPv6. The term > LIR is used in IPv6 allocation policy in all regions and refers > to an entity that assigns /48 blocks to its subscribers. Such > an entity can receive a /32 from ARIN or RIPE or APNIC or LACNIC > or AFRINIC. > > --Michael Dillon hum... so what happens if i chose to delegated /56's to my customers? does that invalidate my LIR status 'cause i'm not toeing the /48 line? presuming of course i have LIR status along w/ the /32 that has ben delegated to me. to borrow a line, "some days your the IANA, some days your the endnode" --bill
Re: shim6 @ NANOG (forwarded note from John Payne)
At 08:16 AM 3/4/2006 +0800, Randy Bush wrote: > >> On 3-mrt-2006, at 11:30, [EMAIL PROTECTED] wrote: >>> The term LIR is used in IPv6 allocation policy in all regions > >no > Hmm...sure looks like it to me http://lacnic.net/en/politicas/ipv6.html 2.4 A Local Internet Registry (LIR) is an IR that primarily assigns address space to the users of the network services that it provides. LIRs are generally ISPs, whose customers are primarily end users and possibly other ISPs. http://www.arin.net/policy/nrpm.html 6.2.4 A Local Internet Registry (LIR) is an IR that primarily assigns address space to the users of the network services that it provides. LIRs are generally ISPs, whose customers are primarily end users and possibly other ISPs. http://www.afrinic.net/docs/policies/afpol-v6200407-000.htm 2.2. Local Internet Registry (LIR) A Local Internet Registry primarily assigns address space to the users of the network services that it provides. LIRs are generally ISPs whose customers are primarily End Users and possibly other ISPs. http://www.ripe.net/ripe/docs/ipv6policy.html 2.4. Local Internet Registry (LIR) A Local Internet Registry is an IR that primarily assigns address space to the users of the network services that it provides. LIRs are generally ISPs whose customers are primarily End Users and possibly other ISPs. http://www.apnic.net/docs/policy/ipv6-address-policy.html 2.4. Local Internet Registry (LIR) A Local Internet Registry (LIR) is an IR that primarily assigns address space to the users of the network services that it provides. LIRs are generally ISPs, whose customers are primarily end users and possibly other ISPs.
Re: shim6 @ NANOG
> I'm more confident that we'll find an answer > to the IDR problem sooner than we'll convince people to act in the good > of the community at their own expense. The solution to the IDR problem is to have a scalable routing architecture. Unfortunately, that involves change from the status quo, and thus altruistic action. The alternative, of course, is to wait for IDR to implode and let the finger-pointing begin. Tony
Re: shim6 @ NANOG (forwarded note from John Payne)
> On 3-mrt-2006, at 11:30, [EMAIL PROTECTED] wrote: >> The term LIR is used in IPv6 allocation policy in all regions no
Re: shim6 @ NANOG (forwarded note from John Payne)
On 3-mrt-2006, at 21:43, Brandon Ross wrote: I will bet anyone reading this $ 20 USD right now that what will actually happen is the development of a spot market in IPv4 address space. That's a sucker bet. What's worse is that unless people start changing their tune soon and make the ownership of IP space official, this will be a black market (like it is now, just much bigger). But that will end as soon as interdomain routing is protected by certificates given out by the RIRs.
Re: shim6 @ NANOG (forwarded note from John Payne)
On Fri, 3 Mar 2006, Marshall Eubanks wrote: I will bet anyone reading this $ 20 USD right now that what will actually happen is the development of a spot market in IPv4 address space. That's a sucker bet. What's worse is that unless people start changing their tune soon and make the ownership of IP space official, this will be a black market (like it is now, just much bigger). -- Brandon Ross AIM: BrandonNRoss Director, Network Engineering ICQ: 2269442 Internap Skype: brandonross Yahoo: BrandonNRoss
Re: shim6 @ NANOG (forwarded note from John Payne)
On Mar 3, 2006, at 5:55 AM, Kurt Erik Lindqvist wrote: On 2 mar 2006, at 06.16, Kevin Day wrote: No, I'm just trying to be practical here... Estimates of IPv4 pool exhaustion range from Mid 2008 (Tony Hain's ARIN presentation) to roughly 2012 (Geoff Huston's ARIN presentation). Sooner if a mad dash for space starts happening (or isn't happening already). Does anyone here really believe that there is time for: So what I think we might need (that I wrote in an internet-draft some years ago) is the following things in exactly this order : 0. PI space with an artifically high barrier on entry yet available when needed (read cost+administration=LIR or equiv.). 1. Ducttape ala shim6 2. One of breakthrough in graph-theory or a completely new addressing/routing paradigm. Most like the latter. I will bet anyone reading this $ 20 USD right now that what will actually happen is the development of a spot market in IPv4 address space. Regards Marshall That will take us past IPv4 exhaustion+IPv6 initial deployment, through wider uptake through to the 10-15 years from now when we might have an idea of what 2 is. I used to believe that it would take 10 years to deploy a standardised version of a stack change, I must say I changing my mind and I am starting to agree with however said that we just need to wait for the next major security hole+patch. - kurtis -
Re: shim6 @ NANOG
Thus spake "Iljitsch van Beijnum" <[EMAIL PROTECTED]> Man, I hope I never become as cynical as you. A pessimist is never disappointed. On 2-mrt-2006, at 11:09, Stephen Sprunk wrote: Why is it even remotely rational that a corporate admin trust 100k+ hosts infested with worms, virii, spam, malware, etc. to handle multihoming decisions? They trust those hosts to do congestion control too, which is even more important. No, they don't. That's why nearly every enterprise has deployed intradomain QoS of some sort. Nearly everyone doing VoIP has to use QoS to prevent hosts (with "congestion control") from messing with their voice traffic. Others have had to deploy it to prevent non-mission-critical (or even prohibited) apps from interfering with mission-critical stuff. I had one customer that had to implement QoS on their entire WAN just to keep Outlook and web access from starving out their serial-over-X.25-over-IP business application. The people who pay for the network want to have control over it. Especially when we don't even have a sample of working code today? The IAB goes out of its way to solicit input on ongoing work, and now you whine about lack of working code? I'm not whining (at least I don't think so), but I think it's very premature to talk about shim6 as the solution to IPv6 multihoming when it's not a deployable solution or even a fully specified one. Now, some may take that as a sign the IETF needs to figure out how to handle 10^6 BGP prefixes... I'm not sure we'll be there for a few years with IPv6, but sooner or later we will, and someone needs to figure out what the Internet is going to look like at that point. It won't look good. ISPs will have to buy much more expensive routers. At some point, people will start to filter out routes that they feel they can live without and universal reachability will be a thing of the past. That's one possible end case. The other is that all of this is a tempest in a teapot and the growth of IPv6 PI routes will continue to be non-dominant just as PI is with IPv4. As others have noted, one prefix per ASN (which is the goal of IPv6 PI policy) is nowhere near enough to create a problem unless there's a serious explosion in ASN assignment. The policies for IPv4 are pretty darn lax, so if we don't have a problem today, why do people think we'll have a problem with stricter policies on the IPv6 side? And I'm the cynic... It will be just like NAT: every individual problem will be solvable, but as an industry, or even a society, we'll be wasting enormous amounts of time, energy and money just because we didn't want to bite the bullet earlier on. People pay what they perceive to be the lowest cost to themselves; so far, NAT has that honor. I'm more confident that we'll find an answer to the IDR problem sooner than we'll convince people to act in the good of the community at their own expense. S Stephen Sprunk"Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin
Re: shim6 @ NANOG (forwarded note from John Payne)
Thus spake "Iljitsch van Beijnum" <[EMAIL PROTECTED]> On 3-mrt-2006, at 17:04, Stephen Sprunk wrote: Keep in mind that current RIR allocations/assignments are effectively leases (though the RIRs deny that fact) and, like any landlord, they can refuse to renew a lease or increase the rent at any point. I can only imagine the fun the lawyers are going to have with this: 1. Get address space from Internic, no questions asked 2. ARIN is formed and starts making policies that say address space isn't owned 3. ARIN never enforces these no ownership policies (that I know of) 4. ARIN tries to take away the addresses That's the best advertisement IPv6 could ever hope for: "no lawyers!" Thanks for silently snipping the paragraph that partially answered that. There may be some legal battles over it, but since the orgs have no records of ever purchasing those legacy addresses, it's hard to claim true ownership -- not that one could easily establish owning a number even with a bill of sale. My guess is we'll continue to grandfather them forever, but RIR policy will change to requiring orgs to start paying rent on them in order to receive any new assignments (either v4 or v6). Wait a few years, and we can reclaim most of the space without the lawyers being able to interfere. v6 does have an advantage (to the RIRs) of not having legacy issues, but that's a disadvantage for the orgs getting space. Consider that the vast majority of orgs with multiple legacy swamp allocations haven't traded them in for a rent-free CIDR one; part of that is inertia, but part is the risk that doing so will more likely expose them to rent in the future. So even if it's free, deploying IPv6 today isn't all that useful. But when you're the last one running IPv4, you'll really want to move over to IPv6, even if it's very expensive. Ah, but why? As long as IPv4 has similar or better performance characteristics to IPv6, why would anyone _need_ to migrate? Add to that the near certainty that vendors will create NAT devices that will allow an entire v4 enterprise to reach the v6 Internet... Don't they teach you IPv6 network design in CCIE school? There weren't CCIE schools back when I got mine, but my understanding is that the ones today still don't teach anything (or at least anything useful) about IPv6. Once you've worked with link local addressing/routing and generating addresses from EUI-64s you never want to go back to the tedious address and subnet management that's necessary in IPv4. When you're using RFC1918 space, as nearly all leaf orgs do today, subnet assignment isn't tedious: just give every VLAN a /24 or so and be done with it; similar to assigning /64s. Maintaining DHCP servers sucks, but it's an accepted cost that doesn't amount to much in the budget since they're already paid for (or free with your routers). I agree that IPv6 is better from this perspective, but unless one is building out a greenfield network, the transition cost is higher than the cost of status quo. Just upgrading all those L3 switches to v6-capable models will cost large enterprises tens of millions of dollars (and don't say regular upgrade cycles will fix that, as obsolete equipment just moves out of the core to other places). So building boxes just so you can stick to IPv4 when the rest of the world is already on IPv6 seems a bit backward to me. It's not a matter of building boxes: all that needs to happen is for Cisco to release an upgrade for PIX (ditto for other vendors) that is free with a maintenance contract, and every enterprise will be doing it overnight. What's to stop the vendors from doing it? All it takes is one big (or several small) RFP(s) asking for the feature, and it'll be there. Since you can't express the IPv6 address space in the IPv4 address space (the reverse is easy and available today), the translation needs to happen a bit higher in the stack. Off-the-cuff solution: translate all incoming v6 addresses to temporary v4 addresses (172.16/12 will do nicely). You'll need to intercept DNS, but most NAT devices do that today anyways for other reasons. When I was testing running IPv6-only I installed an Apache 2 proxy in order to reach the IPv4 web from my IPv6-only system. But it worked the other way around too, of course: using the proxy, I could visit sites over IPv6 with IPv4-only systems. Which supports my point: why upgrade when you can proxy / translate / whatever for (almost) free? Especially when you're using 10/8 internally and thus will never directly feel any v4 exhaustion pain? S Stephen Sprunk"Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin
Re: shim6 @ NANOG (forwarded note from John Payne)
On 3-mrt-2006, at 17:04, Stephen Sprunk wrote: Keep in mind that current RIR allocations/assignments are effectively leases (though the RIRs deny that fact) and, like any landlord, they can refuse to renew a lease or increase the rent at any point. I can only imagine the fun the lawyers are going to have with this: 1. Get address space from Internic, no questions asked 2. ARIN is formed and starts making policies that say address space isn't owned 3. ARIN never enforces these no ownership policies (that I know of) 4. ARIN tries to take away the addresses That's the best advertisement IPv6 could ever hope for: "no lawyers!" So even if it's free, deploying IPv6 today isn't all that useful. But when you're the last one running IPv4, you'll really want to move over to IPv6, even if it's very expensive. Ah, but why? As long as IPv4 has similar or better performance characteristics to IPv6, why would anyone _need_ to migrate? Add to that the near certainty that vendors will create NAT devices that will allow an entire v4 enterprise to reach the v6 Internet... Don't they teach you IPv6 network design in CCIE school? Once you've worked with link local addressing/routing and generating addresses from EUI-64s you never want to go back to the tedious address and subnet management that's necessary in IPv4. So building boxes just so you can stick to IPv4 when the rest of the world is already on IPv6 seems a bit backward to me. Since you can't express the IPv6 address space in the IPv4 address space (the reverse is easy and available today), the translation needs to happen a bit higher in the stack. When I was testing running IPv6-only I installed an Apache 2 proxy in order to reach the IPv4 web from my IPv6-only system. But it worked the other way around too, of course: using the proxy, I could visit sites over IPv6 with IPv4- only systems.
Re: shim6 @ NANOG (forwarded note from John Payne)
Thus spake "Tony Li" <[EMAIL PROTECTED]> Marshall, That's after 6 years. I would be surprised if Shim6 going into actual deployed boxes was any faster. So, if Shim6 was finalized today, which it won't be, in 2010 we might have 70% deployment and in 2012 we might have 90% deployment. I actually think that 2012 would be a more realistic date for 70% deployment of Shim6, given the lack of running code and a finalized protocol now. In my opinion, that doesn't imply that Shim6 should be abandoned. But it does mean IMHO that regarding it as a means to spur IPv6 deployment is just not realistic. Sorry, but I'm just not buying the analogy. The market drivers for IGMP are somewhat smaller than they are for IPv6. That depends on your perspective. There's a compelling need for usable multicast in many environments, and so far there's nobody (in the US) with a compelling need for IPv6, much less shim6. Yes, it would take a couple of years for Shim6 to be implemented and depending on where we hit Redmond's release cycle, actually penetrate a significant number of hosts. Shim6 needs to be finalized first, then someone has to convince MS to implement it. I'd put that, conservatively, at 4 years. 6 years is probably long, and definitely long if we get a confluence of panic about the death of v4 plus a strong endorsement about Shim6 from the IETF. The most dire predictions of v4's death have it at least 12-15 years away. To companies worried about next quarter's profits, you might as well be talking about global warming. Consider that the IETF *could* conceivably require every compliant v6 implementation to include it. I grant that that's unlikely and some lesser endorsement is probably more reasonable, but I don't think that you should underestimate the capability of the IETF/ISP/vendor/ host community to act a bit more quickly, if there is sufficient motivation. Without any enforcement powers, an IETF "requirement" is pretty useless. Those vendors that care will merely see one more complicated thing they have to add to their IPv6 stack and put it off adding IPv6 even longer. I suggest that we compromise, split the difference and swag it at 4 years. His was a minimum; I'd put the likely number at 4-6 years after shim6 is finally published (itself no fixed date), and potentially much longer if middlebox support is added (and without which shim6 will certainly never see the light of day). S Stephen Sprunk"Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin
Re: shim6 @ NANOG (forwarded note from John Payne)
On 3/3/06 11:04 AM, "Stephen Sprunk" <[EMAIL PROTECTED]> wrote: > > Keep in mind that current RIR allocations/assignments are effectively leases > (though the RIRs deny that fact) and, like any landlord, they can refuse to > renew a lease or increase the rent at any point. > > There might be some interesting political battles when it comes to legacy > allocations which are currently rent-free, but those tenants will find > themselves woefully outnumbered when that day comes. > > Stephen Sprunk"Stupid people surround themselves with smart > CCIE #3723 people. Smart people surround themselves with > K5SSS smart people who disagree with them." --Aaron Sorkin > Leases are actually a bad thing, from an address exhaustion point of view. Its like a country where the government owns all the land, but people have been farming it for generations. They can't sell it. If an address trading scheme evolves, address block holders will need clear title granted them by the RIRs. That would make an IP address market, moderated through the RIRs as clearing houses, tenable. Sadly, many of the folks who are involved with ARIN are sadly short sighted in this regard. They dismiss both the idea of an address market upon v4 exhaustion and the idea of clear title to address blocks. While I can't state unequivocally that this is the answer, it does seem to merit further study. -- Daniel Golding
Re: shim6 @ NANOG (forwarded note from John Payne)
On 2 mar 2006, at 06.16, Kevin Day wrote: No, I'm just trying to be practical here... Estimates of IPv4 pool exhaustion range from Mid 2008 (Tony Hain's ARIN presentation) to roughly 2012 (Geoff Huston's ARIN presentation). Sooner if a mad dash for space starts happening (or isn't happening already). Does anyone here really believe that there is time for: So what I think we might need (that I wrote in an internet-draft some years ago) is the following things in exactly this order : 0. PI space with an artifically high barrier on entry yet available when needed (read cost+administration=LIR or equiv.). 1. Ducttape ala shim6 2. One of breakthrough in graph-theory or a completely new addressing/ routing paradigm. Most like the latter. That will take us past IPv4 exhaustion+IPv6 initial deployment, through wider uptake through to the 10-15 years from now when we might have an idea of what 2 is. I used to believe that it would take 10 years to deploy a standardised version of a stack change, I must say I changing my mind and I am starting to agree with however said that we just need to wait for the next major security hole+patch. - kurtis -
Re: shim6 @ NANOG (forwarded note from John Payne)
Thus spake "Iljitsch van Beijnum" <[EMAIL PROTECTED]> On 3-mrt-2006, at 0:22, Mark Newton wrote: Right now we can hand them out to anyone who demonstrates a need for them. When they run out we'll need to be able to reallocate address blocks which have already been handed out from orgs who perhaps don't need them as much as they thought they did to orgs which need them more. Sounds like a marketplace to me. How much do you think a /24 is worth? How many microseconds do you think it'll take for members of each RIR to debate the policy changes needed to alter their rules to permit trading of IPv4 resource allocations once IANA says, "No!" for the first time? This is what I wrote about this a couple of months ago: http:// ablog.apress.com/?p=835 An interesting aspect about address trading is that some organizations have huge amounts of address space which didn't cost them anything, or at least not significantly more than what smaller blocks of address space cost others. Having them pocket the proceeds strikes me as rather unfair, and also counter productive because it encourages hoarding. Maybe a system where ARIN and other RIRs buy back addresses for a price per bit prefix length rather than per address makes sense. Keep in mind that current RIR allocations/assignments are effectively leases (though the RIRs deny that fact) and, like any landlord, they can refuse to renew a lease or increase the rent at any point. There might be some interesting political battles when it comes to legacy allocations which are currently rent-free, but those tenants will find themselves woefully outnumbered when that day comes. We'll also have a reasonably good idea of what it'd cost to perform an IPv6 migration as we gather feedback from orgs who have actually done it. I don't think the cost is too relevant (and hard to calculate because a lot of it is training and other not easily quantified expenditures), what counts is what it buys you. I ran a web bug for a non-networking related page in Dutch for a while and some 0.16% of all requests were done over IPv6. (That's 1 in 666.) So even if it's free, deploying IPv6 today isn't all that useful. But when you're the last one running IPv4, you'll really want to move over to IPv6, even if it's very expensive. Ah, but why? As long as IPv4 has similar or better performance characteristics to IPv6, why would anyone _need_ to migrate? Add to that the near certainty that vendors will create NAT devices that will allow an entire v4 enterprise to reach the v6 Internet... S Stephen Sprunk"Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin
Re: shim6 @ NANOG (forwarded note from John Payne)
On 3-mrt-2006, at 11:30, [EMAIL PROTECTED] wrote: If you feel you should qualify as an LIR, With RIPE, an LIR is simply an organization that pays the membership fee and thus gets to submit requests for address space and AS numbers. ARIN doesn't seem to use this terminology except in their IPv6 address allocation policy. That's what we were talking about. Shim6 and IPv6. The term LIR is used in IPv6 allocation policy in all regions and refers to an entity that assigns /48 blocks to its subscribers. Such an entity can receive a /32 from ARIN or RIPE or APNIC or LACNIC or AFRINIC. No, a LIR has the privilege of paying their RIR a fee. Wether they can get a /32 is another matter.
Re: shim6 @ NANOG (forwarded note from John Payne)
> Right now, DDoS attacks from Botnets > are bad enough. DDos!?!?!? What about the $1 billion dollars of clickbot fraud that the advertising industry is presently struggling with? Has anyone ever put a figure on the cost of DDos per year? > Where is the IETF leadership? Not on the NANOG list... --Michael Dillon
Re: shim6 @ NANOG (forwarded note from John Payne)
> > If you feel you should qualify as an LIR, > > With RIPE, an LIR is simply an organization that pays the membership > fee and thus gets to submit requests for address space and AS > numbers. ARIN doesn't seem to use this terminology except in their > IPv6 address allocation policy. That's what we were talking about. Shim6 and IPv6. The term LIR is used in IPv6 allocation policy in all regions and refers to an entity that assigns /48 blocks to its subscribers. Such an entity can receive a /32 from ARIN or RIPE or APNIC or LACNIC or AFRINIC. --Michael Dillon
Re: shim6 @ NANOG (forwarded note from John Payne)
Mark Newton wrote: I mean, who accepts prefixes longer than /24 these days anyway? We've all decided that we "can live without" any network smaller than 254 hosts and it hasn't made a lick of difference to universal reachability. What's to stop someone who wants to carry around less prefixes from saying, "Bugg'rit, I'm not going to accept anything smaller than a /18"? Hopefully, customers. Furthermore, such a policy will also do little to encourage IPv4 conservation. We're already in a situation where for each routing policy, folk are recommended to use /20 or smaller prefixes (per routing policy) when applying for PI, despite the fact that a /23 might suit their multi-homed, end-site network, in order to help beat-the-filters. -a
Re: shim6 @ NANOG (forwarded note from John Payne)
--- Tony Li <[EMAIL PROTECTED]> wrote: > Consider that the IETF > *could* conceivably > require every compliant v6 implementation to include > it. God Forbid. I somehow don't want my core routers deciding to speak shim6... David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: shim6 @ NANOG (forwarded note from John Payne)
Marshall, > That's after 6 years. > > I would be surprised if Shim6 going into actual deployed boxes was any > faster. So, if Shim6 was finalized today, which it won't be, in 2010 we > might have 70% deployment and in 2012 we might have 90% deployment. > > I actually think that 2012 would be a more realistic date for 70% > deployment of Shim6, given the lack of running code and a finalized > protocol now. > > In my opinion, that doesn't imply that Shim6 should be abandoned. But it > does mean IMHO that regarding it as a > means to spur IPv6 deployment is just not realistic. Sorry, but I'm just not buying the analogy. The market drivers for IGMP are somewhat smaller than they are for IPv6. Yes, it would take a couple of years for Shim6 to be implemented and depending on where we hit Redmond's release cycle, actually penetrate a significant number of hosts. 6 years is probably long, and definitely long if we get a confluence of panic about the death of v4 plus a strong endorsement about Shim6 from the IETF. Consider that the IETF *could* conceivably require every compliant v6 implementation to include it. I grant that that's unlikely and some lesser endorsement is probably more reasonable, but I don't think that you should underestimate the capability of the IETF/ISP/vendor/host community to act a bit more quickly, if there is sufficient motivation. I suggest that we compromise, split the difference and swag it at 4 years. Tony
Re: shim6 @ NANOG (forwarded note from John Payne)
Hello; On Mar 1, 2006, at 10:45 AM, Joe Abley wrote: On 1-Mar-2006, at 10:33, John Payne wrote: On Mar 1, 2006, at 1:52 AM, Joe Abley wrote: Shim6 also has some features which aren't possible with the swamp -- for example, it allows *everybody* to multi-home, down to people whose entire infrastructure consists of an individual device, and to do so in a scaleable way. Only if *everybody* has a shim6 capable stack... Not quite -- the practical usefulness of the multi-homing increases with the deployment of shim6-capable stacks. You could imagine a threshold of server and host upgrades which would provide useful multi-homing a good proportion of the time without universal deployment. If Linux and the currently-supported variants of Windows were to be updated to support shim6, and we waited through three or four widely-publicised security vulnerabilities which required OS/kernel upgrades, perhaps that would be sufficient deployment for the benefits of shim6 to be felt, most of the time. My hands are waving again, of course. I have to object to this here; your hands are not waving nearly hard enough. This was exactly the same mistake that was made with IGMPv3, which IIRC was finalized around the time of the Adelaide IETF (i.e., almost exactly 6 years ago). 1.) It took about 4 years for Windows variants with IGMPv3 support to dominate the Windows logs in my web servers. (By dominate, I mean > 80% of hits from windows machines.) In February of this year, Windows 98 (non IGMPv3 capable) was still 2% of the total web hits, compared to 0.56 % for all flavors of Linux and 0.03% for all flavors of BSD. 2.) The Mac (8% of web hits in February 2006), still doesn't have it. 3.) So IGMPv3 deployment in hosts _at this instant_ is almost certainly less than 90%. 4.) Partially as a result, SSM deployment is still miniscule. That's after 6 years. I would be surprised if Shim6 going into actual deployed boxes was any faster. So, if Shim6 was finalized today, which it won't be, in 2010 we might have 70% deployment and in 2012 we might have 90% deployment. I actually think that 2012 would be a more realistic date for 70% deployment of Shim6, given the lack of running code and a finalized protocol now. In my opinion, that doesn't imply that Shim6 should be abandoned. But it does mean IMHO that regarding it as a means to spur IPv6 deployment is just not realistic. Regards Marshall Eubanks I feel fairly certain I have exceeded some kind of unenforced posting threshold to this list in the last twelve hours. I will try hard to be quiet for a while, now :-) Joe
Re: shim6 @ NANOG (forwarded note from John Payne)
> Shim6 is an answer to "what kind of multihoming can we offer to sites > without PI space? as far as i can tell, s/sites/hosts/. to make it work for sites, as yet unspecified middleware (adding even more complexity and thus further reducing reliability (and margins)) will be needed if there is any concern for security and/or site management; and, aside from the home user, there always are. randy
Re: shim6 @ NANOG (forwarded note from John Payne)
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) [Thu 02 Mar 2006, 17:03 CET]: If your current business model means that your business cannot continue in an IPv6 world, then a competent business manager will change that model. If the IPv6 I assume that you mean that the IPv6 model will be changed, no? Because I hope that it has become clear from this thread that the adoption of IPv6 by a significant amount of players currently reachable over IPv4 is far from certain, and unless IPv6 offers at least feature compatibility it may not even happen. [..] If you feel you should qualify as an LIR, then apply for your /32. If you get rejected, asked for detailed reasons why. If the reasons are due to misunderstanding or a lack of information, then remedy the situation and reapply. If the reasons have to do with your structure or your plans, then change them and reapply. If you can't do that then I would question whether you have a serious intention to be an IPv6 service provider. Why should a certain business model be forced upon you? To multihome right now you need to cough up some money for equipment and some clue for configuration. Why would IPv6 require you to change your business model to achieve the same? [unattributed wrote:] One customer on one dedicated server gets a /128. That is, of course, insane. IPv6 addresses are far from rare. Why do you a priori rule out applications like https and virtualisation? -- Niels.
Re: shim6 @ NANOG (forwarded note from John Payne)
On 3-mrt-2006, at 0:22, Mark Newton wrote: You've probably seen Geoff Huston's comments about this; I tend to agree with him here. Geoff tends to make lots of comments, it's hard to either agree or disagree with them all. :-) When IPv4 space is exhausted, the sky won't fall; We'll simply work out an address space management policy which is different from the one we have right now. Of course. But don't underestimate how address-hungry some people/ organizations/places are. For instance, Comcast got 12.5 million addresses last year. Right now we can hand them out to anyone who demonstrates a need for them. When they run out we'll need to be able to reallocate address blocks which have already been handed out from orgs who perhaps don't need them as much as they thought they did to orgs which need them more. Sounds like a marketplace to me. How much do you think a /24 is worth? How many microseconds do you think it'll take for members of each RIR to debate the policy changes needed to alter their rules to permit trading of IPv4 resource allocations once IANA says, "No!" for the first time? This is what I wrote about this a couple of months ago: http:// ablog.apress.com/?p=835 An interesting aspect about address trading is that some organizations have huge amounts of address space which didn't cost them anything, or at least not significantly more than what smaller blocks of address space cost others. Having them pocket the proceeds strikes me as rather unfair, and also counter productive because it encourages hoarding. Maybe a system where ARIN and other RIRs buy back addresses for a price per bit prefix length rather than per address makes sense. We'll also have a reasonably good idea of what it'd cost to perform an IPv6 migration as we gather feedback from orgs who have actually done it. I don't think the cost is too relevant (and hard to calculate because a lot of it is training and other not easily quantified expenditures), what counts is what it buys you. I ran a web bug for a non-networking related page in Dutch for a while and some 0.16% of all requests were done over IPv6. (That's 1 in 666.) So even if it's free, deploying IPv6 today isn't all that useful. But when you're the last one running IPv4, you'll really want to move over to IPv6, even if it's very expensive.
Re: shim6 @ NANOG (forwarded note from John Payne)
On Thu, Mar 02, 2006 at 10:44:01PM +0100, Iljitsch van Beijnum wrote: > >And why would those people consider migrating to IPv6? > > Because they can't get IPv4 addresses or so many other people use > IPv6 (because _they_ can't get IPv4 addresses) that communicating > with them natively is important. > But today there are still enough IPv4 addresses (I just checked: we > still have 1444.12 million addresses or 86.08 /8s) so that won't > happen for a few more years. You've probably seen Geoff Huston's comments about this; I tend to agree with him here. When IPv4 space is exhausted, the sky won't fall; We'll simply work out an address space management policy which is different from the one we have right now. Right now we can hand them out to anyone who demonstrates a need for them. When they run out we'll need to be able to reallocate address blocks which have already been handed out from orgs who perhaps don't need them as much as they thought they did to orgs which need them more. Sounds like a marketplace to me. How much do you think a /24 is worth? How many microseconds do you think it'll take for members of each RIR to debate the policy changes needed to alter their rules to permit trading of IPv4 resource allocations once IANA says, "No!" for the first time? That'll be interesting, because it'll place a cost on not migrating to IPv6: If an ISP wishes to grow its business it'll need to have sufficient resources to buy the address space it needs. We'll also have a reasonably good idea of what it'd cost to perform an IPv6 migration as we gather feedback from orgs who have actually done it. My guess is that we'll keep using IPv4 until the cost of growing businesses with the old address space exceeds the cost of migrating to the new one. One thing that Geoff hasn't been cynical enough to put forward is the idea that orgs with lots of valuable, monetized address space may very well end up lobbying the IAB and RIRs to erect new cost structures around green-fields IPv6 allocations as well, to make sure that the profit-providing marketplace survives for as long as possible by making the IPv6 migration process as expensive and inconvenient as possible. What will happen when the MCI's of the world discover that the race to $0 for IP transit prices has created a world in which they make more money by selling their IPv4 addresses than they make by selling Internet access? Will we see them coming out as a strong supporter of restrictive RIR policies and IPv6 technologies which don't work as a way of artificially boosting the price of IPv6? It's going to be a fun ride :-) - mark -- Mark Newton Email: [EMAIL PROTECTED] (W) Network Engineer Email: [EMAIL PROTECTED] (H) Internode Systems Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223
Re: shim6 @ NANOG (forwarded note from John Payne)
At 11:27 AM 3/2/2006 -0500, Daniel Golding wrote: There is a tremendous amount of effort being wasted here arguing against it and even more so in the IETF, where time being wasted on shim6 could be better spent on a new IDR paradigm. Where is the IETF leadership? I think the IRTF is the right place to discuss the new IDR paradigm. http://www.irtf.org/charter?gtype=rg&group=rrg "This research group is chartered to explore routing problems that are important to the development of the Internet but are not yet mature enough for engineering work within the IETF. The group will work closely with the IESG Routing Area Directors to ensure the free flow of information in both directions and avoid duplication of work with the various IETF working groups. The first steps taken in the RRG consisted of conducting a survey the state of the art in routing research, the needs of the user community (ISPs, router vendors, etc.) and the history of routing requirements. While this work will be ongoing as the state of research and of needs changes, the next step involves taking a number of the problem brought out in the analysis and focusing on these issues. The current set of sub-groups includes: Future Domain Routing Scalability" gus
