Re: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy
Well, this can be argued the otherway around as well. We know that ISPs filter out previously unused space, and that they are not very active in updating those filters when IANA starts allocating out of new blocks. Having all in well-known block would limit that.
...wouldn't we/you/they/all have to do some filtering the "other way 'round" if all of those prefixes are contained in _one_ superblock to guard against someone/something announcing (and potentially black- holeing(sp?)) a route for that /32?
Eh, I would assume there is no /32 to announce and that more specifics will always win.
- - kurtis -
In a perfect world - yes. But "per default" when you announce something in v6-world, you are "supposed" to announce a /32 (or maybe a /35) _and_ filter anything that is longer than that. I really don't see any benefit from adding complexity again, other than clinging to the well-worn conservatiopn goal from IPv4. Wilfried.
On 24-mrt-05, at 9:53, Wilfried Woeber, UniVie/ACOnet wrote:
But "per default" when you announce something in v6-world, you are "supposed" to announce a /32
Yes.
(or maybe a /35)
No, certainly not those.
_and_ filter anything that is longer than that.
That's what it says in the documents but then ARIN started to give out /48s so this policy doesn't work anymore. (Noboby bothered to change the documents that say it's ok to filter, though.) So the can of complexity worms has been opened, wasting address space (even though there is a lot to waste) has no upside anymore. Also, for reasons of flap dampening exceptions and the like it's good to have these addresses in a single block.
On Thu, 24 March 2005 11:13:36 +0100, Iljitsch van Beijnum wrote:
_and_ filter anything that is longer than that.
That's what it says in the documents but then ARIN started to give out /48s so this policy doesn't work anymore. (Noboby bothered to change the documents that say it's ok to filter, though.)
Strongest argument so far. Besides the point that I agree with the argument a /32 is probably oversized, be it v6 or not. Now that we have to take special care of the filters we place anyway, why not do one approach, and that's pretty much it.
Also, for reasons of flap dampening exceptions and the like it's good to have these addresses in a single block.
Yes, excellent point, I agree with that for sure! I do not want to think of some fancy BGP Flap Damping advisories that gives me 7 /32 blocks I should not be damping or so. Argh. Regards, Alexander -- Alexander Koch <koch@tiscali.net> / ako4-ripe Phone +49 6103 916 480, Fax +49 6103 916 464
On 24-mrt-05, at 13:00, Kurtis Lindqvist wrote:
_and_ filter anything that is longer than that.
That's what it says in the documents
Those documents I assume is the 6bone routing guidelines document?
No, this one/ones: http://lacnic.net/en/chapter-4.html http://ftp.apnic.net/apnic/docs/ipv6-address-policy http://www.ripe.net/ripe/docs/ipv6-policies.html http://www.arin.net/policy/index.html#six43 http://www.iana.org/ipaddress/ipv6-allocation-policy-26jun02 See section 4.3.
On Thu, 24 Mar 2005, Iljitsch van Beijnum wrote:
On 24-mrt-05, at 13:00, Kurtis Lindqvist wrote:
_and_ filter anything that is longer than that.
That's what it says in the documents
Those documents I assume is the 6bone routing guidelines document?
No, this one/ones:
http://lacnic.net/en/chapter-4.html http://ftp.apnic.net/apnic/docs/ipv6-address-policy http://www.ripe.net/ripe/docs/ipv6-policies.html http://www.arin.net/policy/index.html#six43 http://www.iana.org/ipaddress/ipv6-allocation-policy-26jun02
See section 4.3.
Section 4.3 says : 4.3. Minimum allocation RIRs will apply a minimum size for IPv6 allocations to facilitate prefix-based filtering. The minimum allocation size for IPv6 address space is /32. I think I must have a very different understanding of the word "facilitate" than the rest of the world... - kurtis -
On 24-mrt-05, at 13:22, Kurtis Lindqvist wrote:
4.3. Minimum allocation
RIRs will apply a minimum size for IPv6 allocations to facilitate prefix-based filtering.
The minimum allocation size for IPv6 address space is /32.
I think I must have a very different understanding of the word "facilitate" than the rest of the world...
My reading of this text is: "the RIRs will only give out /32 or shorter prefixes so if you want, you can filter out any prefix that's longer than 32 bits" What's yours?
On Thu, Mar 24, 2005 at 01:34:34PM +0100, Iljitsch van Beijnum wrote:
My reading of this text is: "the RIRs will only give out /32 or shorter prefixes so if you want, you can filter out any prefix that's longer than 32 bits"
What's yours?
About the same here. But we're speaking of assignments, not allocations. This policy doesn't apply. Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
On 24-mrt-05, at 14:45, Daniel Roesen wrote:
On Thu, Mar 24, 2005 at 01:34:34PM +0100, Iljitsch van Beijnum wrote:
My reading of this text is: "the RIRs will only give out /32 or shorter prefixes so if you want, you can filter out any prefix that's longer than 32 bits"
What's yours?
About the same here. But we're speaking of assignments, not allocations. This policy doesn't apply.
So how exactly do I build a prefix length filter that only applies to allocations and not assignments?
On Thu, Mar 24, 2005 at 02:55:24PM +0100, Iljitsch van Beijnum wrote:
So how exactly do I build a prefix length filter that only applies to allocations and not assignments?
This is why people propose reserving a range for PI assignments, so that this range can have different filtering. No rocket science. Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
On Thursday 24 March 2005 14:44, Daniel Roesen wrote:
On Thu, Mar 24, 2005 at 02:55:24PM +0100, Iljitsch van Beijnum wrote:
So how exactly do I build a prefix length filter that only applies to allocations and not assignments?
This is why people propose reserving a range for PI assignments, so that this range can have different filtering. No rocket science.
But Daniel, there's no such thing as v6 PI :) As I read it, they're talking about reserving a block for what would effectively be micro-allocations no PI. Jon
On Thu, Mar 24, 2005 at 03:44:42PM +0000, Jon Lawrence wrote:
On Thursday 24 March 2005 14:44, Daniel Roesen wrote:
On Thu, Mar 24, 2005 at 02:55:24PM +0100, Iljitsch van Beijnum wrote:
So how exactly do I build a prefix length filter that only applies to allocations and not assignments?
This is why people propose reserving a range for PI assignments, so that this range can have different filtering. No rocket science.
But Daniel, there's no such thing as v6 PI :)
That's what THEY want to make you believe. :-)=
As I read it, they're talking about reserving a block for what would effectively be micro-allocations no PI.
And what's the difference please? Especially since those aren't allocations (you can't assign more-specifics to others) but assignments? Don't play with words. It's IPv6 PI for whoever-is-deemed-special. Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Hi, On Thu, Mar 24, 2005 at 03:44:42PM +0000, Jon Lawrence wrote:
This is why people propose reserving a range for PI assignments, so that this range can have different filtering. No rocket science. But Daniel, there's no such thing as v6 PI :) As I read it, they're talking about reserving a block for what would effectively be micro-allocations no PI.
Microallocations are PI in disguise - end users get address space directly from a RIR. If that's not PI, then what else is? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
gert@space.net (Gert Doering) wrote:
Microallocations are PI in disguise - end users get address space directly from a RIR. If that's not PI, then what else is?
Actually, the people (who argue to be) in need of v6 microallocations do not care what the baby is called. And there's no valid presumption they are not LIRs already. But AFAIR there's still a 200-customer problem which an end site (RIR-wise) cannot solve. Nonetheless they want to multihome, and they want to _really_ multihome, being that anycast instances are usually scattered all over the globe. This implies that there must be a way to get a (however big) routable block that's unlikely to be filtered - well, the proposal has it all. And frankly, I do not care whether it's a /32, /35, /48 or /64, as long as it's accepted and (if </32) well-known. Swamp anyone? ;-) Local multihoming with a PA /48 from one of the transits, and informing the other transits of it, has not been a problem yet (at least, not for us). Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <bu6o7e$e6v0p$2@ID-31.news.uni-berlin.de>) --------------------------------------------------------------[ ELMI-RIPE ]---
Nonetheless they want to multihome, and they want to _really_ multihome, being that anycast instances are usually scattered all over the globe. This implies that there must be a way to get a (however big) routable block that's unlikely to be filtered - well, the proposal has it all.
Why not learn from the lessons of radio spectrum? A fixed number of 3G frequency allocations were put up for auction (or beauty contest). Why should RIPE not offer a limited number of /32 allocations for operators of anycast fabrics? I suggest that RIPE offer 16 allocations of /32 to organizations who intend to operate diverse anycast fabrics globally to serve TLD operators and others who can benefit from an anycast fabric. Select the winners by beauty contest based on technical and commercial fitness. --Michael Dillon
On Tue, 2005-03-29 at 15:47 +0100, Michael.Dillon@radianz.com wrote:
Nonetheless they want to multihome, and they want to _really_ multihome, being that anycast instances are usually scattered all over the globe. This implies that there must be a way to get a (however big) routable block that's unlikely to be filtered - well, the proposal has it all.
Why not learn from the lessons of radio spectrum? A fixed number of 3G frequency allocations were put up for auction (or beauty contest).
Why should RIPE not offer a limited number of /32 allocations for operators of anycast fabrics? I suggest that RIPE offer 16 allocations of /32 to organizations who intend to operate diverse anycast fabrics globally to serve TLD operators and others who can benefit from an anycast fabric. Select the winners by beauty contest based on technical and commercial fitness.
Very simple answer for what is possible with _CURRENT_ policy: 8<------------------- jeroen@purgatory:~$ whois -h whois.arin.net GOOGLE-IPV6 OrgName: Google Inc. OrgID: GOGL Address: 1600 Amphitheatre Parkway City: Mountain View StateProv: CA PostalCode: 94043 Country: US NetRange: 2001:4860:0000:0000:0000:0000:0000:0000 - 2001:4860:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF CIDR: 2001:4860:0000:0000:0000:0000:0000:0000/32 NetName: GOOGLE-IPV6 NetHandle: NET6-2001-4860-1 Parent: NET6-2001-4800-0 NetType: Direct Allocation Comment: RegDate: 2005-03-14 Updated: 2005-03-14 ----------------->8 Greets, Jeroen
Why not learn from the lessons of radio spectrum? A fixed number of 3G frequency allocations were put up for auction (or beauty contest).
Why should RIPE not offer a limited number of /32 allocations for operators of anycast fabrics? I suggest that RIPE offer 16 allocations of /32 to organizations who intend to operate diverse anycast fabrics globally to serve TLD operators and others who can benefit from an anycast fabric. Select the winners by beauty contest based on technical and commercial fitness.
Very simple answer for what is possible with _CURRENT_ policy: $ whois -h whois.arin.net GOOGLE-IPV6
As far as I know, Google is not a service provider. They operate their own network for their own business. I am suggesting that a certain number of /32's should be given to companies which will provide global anycast meshes as a service to 3rd party customers. That way, TLD operators can choose one or more anycast hosting services to host their "critical" service. This makes more sense than giving a /32 to everyone who feels that their service is "critical". If you analyse the situation by the 80/20 rule, then Google represents the 20% of "critical" services that are big enough to be their own ISP. My suggestion is meant to support the 80% of "critical" services that could benefit from the same technology as Google, but which are not large enough to go it alone. --Michael Dillon
Michael.Dillon@radianz.com (Michael.Dillon@radianz.com) wrote:
This makes more sense than giving a /32 to everyone who feels that their service is "critical". If you analyse the situation by the 80/20 rule, then Google represents the 20% of "critical" services that are big enough to be their own ISP. My suggestion is meant to support the 80% of "critical" services that could benefit from the same technology as Google, but which are not large enough to go it alone.
Yet, we do not have a solution (in the RIPE area) for your 20%. Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <bu6o7e$e6v0p$2@ID-31.news.uni-berlin.de>) --------------------------------------------------------------[ ELMI-RIPE ]---
Michael.Dillon@radianz.com wrote:
Why not learn from the lessons of radio spectrum? A fixed number of 3G frequency allocations were put up for auction (or beauty contest).
Why should RIPE not offer a limited number of /32 allocations for operators of anycast fabrics? I suggest that RIPE offer 16 allocations of /32 to organizations who intend to operate diverse anycast fabrics globally to serve TLD operators and others who can benefit from an anycast fabric. Select the winners by beauty contest based on technical and commercial fitness.
Very simple answer for what is possible with _CURRENT_ policy: $ whois -h whois.arin.net GOOGLE-IPV6
As far as I know, Google is not a service provider. They operate their own network for their own business. I am suggesting that a certain number of /32's should be given to companies which will provide global anycast meshes as a service to 3rd party customers. That way, TLD operators can choose one or more anycast hosting services to host their "critical" service.
This makes more sense than giving a /32 to everyone who feels that their service is "critical". If you analyse the situation by the 80/20 rule, then Google represents the 20% of "critical" services that are big enough to be their own ISP. My suggestion is meant to support the 80% of "critical" services that could benefit from the same technology as Google, but which are not large enough to go it alone.
Sounds great! Do you work for ITU perhaps? Any such criteria as you propose are broken by design. Even more so than many of the other IPv6 thingies. This is not the way to go. -- Andre
On Wed, 2005-03-30 at 18:30 +0200, Andre Oppermann wrote:
Michael.Dillon@radianz.com wrote:
Why not learn from the lessons of radio spectrum? A fixed number of 3G frequency allocations were put up for auction (or beauty contest).
Why should RIPE not offer a limited number of /32 allocations for operators of anycast fabrics? I suggest that RIPE offer 16 allocations of /32 to organizations who intend to operate diverse anycast fabrics globally to serve TLD operators and others who can benefit from an anycast fabric. Select the winners by beauty contest based on technical and commercial fitness.
Very simple answer for what is possible with _CURRENT_ policy: $ whois -h whois.arin.net GOOGLE-IPV6
As far as I know, Google is not a service provider.
Which is exactly my point. They don't serve the '200 customer rule'. They might have 200 anycast nodes though, but not disjunct organizations. Unless they reported every tld as a separate org ;) Akamai, who also got an alloc on the same day, might be easily able to claim it though.
They
operate their own network for their own business. I am suggesting that a certain number of /32's should be given to companies which will provide global anycast meshes as a service to 3rd party customers. That way, TLD operators can choose one or more anycast hosting services to host their "critical" service.
Thus you basically say that TLD operators should go to say, Easynet/Tiscali/Telia/$bigcarriers etc who already have IPv6 connectivity in place and ask them to give them a /48 out of their /32, they can do the carry service and presto? Sounds like a perfect plan, those carriers are already present, can fix their internal routing and usually also have perfect colo facilities in place. But..... this is already there, so why change policy?
This makes more sense than giving a /32 to everyone who feels that their service is "critical". If you analyse the situation by the 80/20 rule, then Google represents the 20% of "critical" services that are big enough to be their own ISP.
Every entity that is big enough can always buy themselves what they want, policy or not.
My suggestion is meant to support the 80% of "critical" services that could benefit from the same technology as Google, but which are not large enough to go it alone.
As mentioned above, let them request some address space from one of the larger carriers. Oh oops, there is one problem there, they actually wanted Independent Address Space, that is if they suddenly hate their upstream, it goes belly up etc that they don't have to change anything. Ergo sum they want a slot in the routing table and nothing else.
Sounds great! Do you work for ITU perhaps?
Any such criteria as you propose are broken by design. Even more so than many of the other IPv6 thingies. This is not the way to go.
I suspect Andre also to visit the upcoming (May 1+2) ITU/IETF NGN workshop in Geneva? :) See: http://www.itu.int/ITU-T/worksem/ngn/200505/index.html Greets, Jeroen
My suggestion is meant to support the 80% of "critical" services that could benefit from the same technology as Google, but which are not large enough to go it alone.
As mentioned above, let them request some address space from one of the larger carriers.
I don't know of any large carrier that operates a globally diverse network offering globally diverse hosting of the sort that these anycast meshes need. And I don't think we should be trying to create such things either. However, if we give a /32 to a company who will offer anycast services similar to the anycast services used by some root DNS servers, then we make it possible for TLD operators to buy the anycasting rather than forcing them to build their own. However, if you want to force them to build their own then you have to support giving every one of them their own /32. I think the world is better off if we encourage 3rd parties to build anycast meshes and offer them as a service to TLD operators and others.
Oh oops, there is one problem there, they actually wanted Independent Address Space, that is if they suddenly hate their upstream, it goes belly up etc that they don't have to change anything. Ergo sum they want a slot in the routing table and nothing else.
The idea is that anycasting is a solution for services which are "critical" and therefore they need independent address space. However, this could be provided by an anycast mesh operator who aggregates many networks and who offers an escrow agreement in their customer contracts to ensure continuity. Also, if RIPE enables several of these anycast meshes, I would expect that most TLD operators would use two or three independent anycast meshes. When you consider that they can easily use up to 13 IP addresses, it is easy to configure 3 addresses from 3 different anycast mesh operators, along with 10 diverse unicast addresses.
I really don't see how the ITU is relevant here. This has nothing to do with them. It is all about Internet infrastructure and Internet addressing. --Michael Dillon
On Thursday 24 March 2005 19:08, Gert Doering wrote:
Microallocations are PI in disguise - end users get address space directly from a RIR. If that's not PI, then what else is?
Yes, I agree that they are PI in disguise. But they are still a way of saying to general end users that there's no such thing as PI space - by general end users, I mean corporations not people like TLD (or ccTLD) operators (they should know full well what's what). Or are we just going to say, if you can create a good enough case then PI exists - come and get it. I think that giving every TLD (or every 'special' case if you like) a /32 is a complete waste of address space, and as Randy said have we learnt nothing from the past. It's not so much about conservation as about being sensible. We don't know and no one has been very successful (afaict) in predicting the growth of the 'net, so perhaps being sensible is a good idea :). If we (as in RIPE) are going to start handing out longer than /32's then all the RIR's have to make it abundantly clear that they don't support the idea of /32 filters - or should they (RIR's) make allocations/assignments (call them what you will) from a global pool for these micro allocations and everyone then shouts about how this specific /32 shouldn't be filtered. How soon do we think the routing tables are going to become unmanageable (and I mean unmanageable by the routers themselves) ?? 3 years, 5 years ?? Perhaps we ought to be asking the people who design/build the routers what they think their kit will be capable of by then. We have seen large increases (in % terms) of what routers can now do compared to 5 years ago, what's to say we're not going to see even bigger % increases over the next 5 years. Jon
On Thu, Mar 24, 2005 at 08:47:12PM +0000, Jon Lawrence wrote:
Yes, I agree that they are PI in disguise. But they are still a way of saying to general end users that there's no such thing as PI space - by general end users, I mean corporations not people like TLD (or ccTLD) operators (they should know full well what's what). Or are we just going to say, if you can create a good enough case then PI exists - come and get it.
PI will come or IPv6 not fly. Face it.
If we (as in RIPE) are going to start handing out longer than /32's then all the RIR's have to make it abundantly clear that they don't support the idea of /32 filters
ARIN and LACNIC already do. RIPE (not NCC) folks are still trying to make policy around people's failure to properly maintain filters. It's like capitulating before the battle even started (looking at actual deployment out there, the few who don't get it [filtering] will learn it the hard way later).
or should they (RIR's) make allocations/assignments (call them what you will) from a global pool for these micro allocations and everyone then shouts about how this specific /32 shouldn't be filtered.
Yes. ARIN: http://www.arin.net/registration/ipv6/micro_alloc.html (2001:0500::/29) LACNIC: http://lacnic.net/en/registro/index.html "IPv6: 2001:1200::/23 (minimum allocation /48)" "NAPs/IXP in the region: [...] 2001:12f8::/32" So basically you have to (judging from above statement) expect valid /48 announcements from whole LACNIC space. And from ARIN space within 2001:500::/29.
How soon do we think the routing tables are going to become unmanageable (and I mean unmanageable by the routers themselves) ?? 3 years, 5 years ??
Can you give some well-funded projection, or just hand-waving FUD?
Perhaps we ought to be asking the people who design/build the routers what they think their kit will be capable of by then.
They say that they test their RPs for 1 million RIB routes since years. Not the (then) high-end gear you have bought ten years ago, or even only a few years ago where you may have made questionable and/or short-sighted purchase decisions.
We have seen large increases (in % terms) of what routers can now do compared to 5 years ago, what's to say we're not going to see even bigger % increases over the next 5 years.
We don't need. We don't even push (good) 5-year old gear to the limits with today's IPv4 junk DFZ RIB. Give every IPv6 ASN a prefix to announce and we'll add about 10-15% to this RIB. Big deal? I strongly disagree. Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
On Thursday 24 March 2005 21:54, Daniel Roesen wrote:
On Thu, Mar 24, 2005 at 08:47:12PM +0000, Jon Lawrence wrote:
Yes, I agree that they are PI in disguise. But they are still a way of saying to general end users that there's no such thing as PI space - by general end users, I mean corporations not people like TLD (or ccTLD) operators (they should know full well what's what). Or are we just going to say, if you can create a good enough case then PI exists - come and get it.
PI will come or IPv6 not fly. Face it.
If we (as in RIPE) are going to start handing out longer than /32's then all the RIR's have to make it abundantly clear that they don't support the idea of /32 filters
ARIN and LACNIC already do. RIPE (not NCC) folks are still trying to make policy around people's failure to properly maintain filters. It's like capitulating before the battle even started (looking at actual deployment out there, the few who don't get it [filtering] will learn it the hard way later).
or should they (RIR's) make allocations/assignments (call them what you will) from a global pool for these micro allocations and everyone then shouts about how this specific /32 shouldn't be filtered.
Yes.
ARIN: http://www.arin.net/registration/ipv6/micro_alloc.html (2001:0500::/29) LACNIC: http://lacnic.net/en/registro/index.html "IPv6: 2001:1200::/23 (minimum allocation /48)" "NAPs/IXP in the region: [...] 2001:12f8::/32"
So basically you have to (judging from above statement) expect valid /48 announcements from whole LACNIC space.
And from ARIN space within 2001:500::/29.
How soon do we think the routing tables are going to become unmanageable (and I mean unmanageable by the routers themselves) ?? 3 years, 5 years ??
Can you give some well-funded projection, or just hand-waving FUD?
I can't give any projections - That's why I asked :) I'm sure someone could work out given the current growth rate, how long it would take to cripple todays routers.
Perhaps we ought to be asking the people who design/build the routers what they think their kit will be capable of by then.
They say that they test their RPs for 1 million RIB routes since years. Not the (then) high-end gear you have bought ten years ago, or even only a few years ago where you may have made questionable and/or short-sighted purchase decisions.
We have seen large increases (in % terms) of what routers can now do compared to 5 years ago, what's to say we're not going to see even bigger % increases over the next 5 years.
We don't need. We don't even push (good) 5-year old gear to the limits with today's IPv4 junk DFZ RIB. Give every IPv6 ASN a prefix to announce and we'll add about 10-15% to this RIB. Big deal? I strongly disagree.
We don't push them now ?? - even the big guys ?? If even they don't push their routers hard, then even with phenomenal growth over the next 5 years or so then what ever the current routers are then will probably be able to cope. If the routers can cope then the size of the routing table becomes a non issue - that's what I'm trying to say. Jon
I'm sure someone could work out given the current growth rate, how long it would take to cripple todays routers.
be suspicious of any answers you get to this question. i am not aware of any real *operational* (i.e. relevant to routers in the *real* network) solid work on this; but i sure would love to see some, done rigorously, of course, and not by some vendor's droids. randy
On Thu, 24 Mar 2005 23:41:18 +0000, Jon Lawrence wrote: >> PI will come or IPv6 not fly. Face it. Full Ack. You won't force company decision makers to get back into the mercy of a single ISP and become dependent from it. Not with policies. You would have to order the army ;-/ >We don't push them now ?? - even the big guys ?? >If even they don't push their routers hard, then even with phenomenal growth >over the next 5 years or so then what ever the current routers are then will >probably be able to cope. >If the routers can cope then the size of the routing table becomes a non issue >- that's what I'm trying to say. *Todays* routers *are* able to handle +20K prefixes. And if they don't, the ISP has to *invest* into new gear. An ISP is a company like any other company, if the market requests that doors and windows should be build with 1mm precision, it won't help the carpenters with old manufacturing equipment to make a policy which defines that 5mm precision is good enough. Face it: Customers demand provider independent address space and multihoming, as a IPv6 provider you may either deliver some solution or you won't sell your product. There is enough IPv4 PI competition ... Best Regards Oliver P.s.: - A good *Engineer* would think of a router beeing capable of >>1 Mio. prefix entries with >>100K different paths. And yes, this is possible. And no, there are customers who need more than 640KB of memory, and yes, there are PC's with more than 640KB ... - A good *Marketing Guy* would then sell Engineers products with the Label "IPv6-PI-ready" and would create a new "this is hip you must have it" *premium* IPv6 product which permits $customer to just *install* his IPv6 prefix at the ISP of his choice. If $customer is on vacation: Just install the prefix there. Such "Customer: you should not have this and that" policies are for the buerocrats (the bad ones, a good buerocrat would see its job in assigning the "IPv6-PI-ready" label ;-) and the market has shown that such policies don't survive. Ceterum Censeo: Either IPv6 PI routing or IPv6 will die. Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver@bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0
Jon Lawrence wrote:
PI will come or IPv6 not fly. Face it.
I agree that IPv6 needs multi-homing to fly - but I was hoping there would be other technical implementations of multi-homing than PI. I do however undersand how multi-homing works with PI addresses - I am not shure I can say the same of other proposals. -hph
On Wed, 30 Mar 2005 21:30:38 +0200, Hans Petter Holen wrote:
I agree that IPv6 needs multi-homing to fly - but I was hoping there would be other technical implementations of multi-homing than PI. It seems we need a thing called "wonder".
Call it PI, Prefix or whatever, here is what we have: - A *arbitrarily* connected set of nodes - called AS'es- in a graph, called "Internet". - A set of destinations, called "prefixes". - Things called "packets", which should be routed thru the graph on a short (best: the shortest) path. If one can find a way to route these packets on the shortest path in any topology without telling the nodes something about each destination, - even a source route is such information and requires knowledge about the structure of the graph - he will probably receive the Fields medal and/or a Nobel price ;-/ The original idea behind the IPv6 TLA, NLA, SLA was a geographical and administrative hierachical design, in the century of *competitive* operators this concept is *broken by design*. In this competitive network world, where operator A charges B for transit, the only chance to implement *true* multihoming is to pass information about the destination to all relevant nodes. But I don't see why we should have a problem doing so. Memory is cheap. However there *are* possible technical improvements, example given: - Use a two level address distribution concept: Level 1 : Pass path information about ISP AS'es only* Level 2 : Flood address origination information separate. ( Example: Multihoming Customer 1 is using AS1 and AS2 for prefix X, Customer 2 is using AS2 and AS3 for prefix Y, then a far AS would see Level 1 : Paths : (AS5 AS4 AS1), (AS5 AS6 AS7 AS2), (AS3) This is sufficient to avoid loops and build policies. Level 2 : Offers: AS1:(X), AS2(X,Y), AS3(Y) No path information is required in these floods. ) - Pass information on demand ( However this should only be done in a two level concept for stability reasons, think of "bad weather" DDoS Flood conditions. ) *However* all this solutions have one impact: - New BGP protocol, new routers, new budget ... Ceterum Censeo: Either there is way to *route* the IPv6 address space, *at least* *with the IPv4 quality* - which means serving the customer demand "true multihoming", or IPv6 is dead. If a large address space is offered, it must be *usable*, which means *routable*, at least with the capabilities of the good old IPv4. No one needs a 40 digit ZIP code for letters for a human postman, a 5 digit code is suffiicient. And a postal service offering 40 digits ZIP codes as "premium service" for standard letters will probably economically fail ;-/ Best Regards Oliver P.s.: Think of UMTS. Design driven by comissions and managers. Today: Billions spend. >270ms ping time. B.t.d.t. Same for IPv6 ?! Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver@bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0
The original idea behind the IPv6 TLA, NLA, SLA was a geographical and administrative hierachical design, in the century of *competitive* operators this concept is *broken by design*.
It was never tried so how can you say that it was broken by design? The IPv6 is so vast that perhaps we should offer some address space to be allocated by geography and see where it leads to. Let the market decide rather than forcing everyone into the "one true way".
*However* all this solutions have one impact: - New BGP protocol, new routers, new budget ...
New routers? Since when does BGP or any routing protocol have to run on the routers themselves. Look inside a modern router and you will often see that the routing and packet forwarding decisions are done on separate CPUs. And there are boxes on the market that do "route optimization" which is just a way of taking the routing decisions outside of the routers themselves. --Michael Dillon
The original idea behind the IPv6 TLA, NLA, SLA was a geographical and administrative hierachical design, in the century of *competitive* operators this concept is *broken by design*.
It was never tried so how can you say that it was broken by design? The IPv6 is so vast that perhaps we should offer some address space to be allocated by geography and see where it leads to. Let the market decide rather than forcing everyone into the "one true way".
If I've understood correctly, geographical addressing will lead to forced interconnection of providers in the geographical area (some might think this is good) but also of carriage of transit traffic destined to other providers' customers, i.e. you as a provider would be forced to shoulder costs with no way to recover them. Ensuring some semblance of equality of this burden for such interconnected providers appears difficult, and requires tight cooperation among them, which is "somewhat" at odds with the idea of independence and competition. Regards, - Håvard
If I've understood correctly, geographical addressing will lead to forced interconnection of providers in the geographical area
It would only be forced if geographical IPv6 addressing was the only kind available. But if geo IPv6 addressing is offered as an option, then market forces can sort out which way is better. To allow market forces to work, you would have to offer every company, both kinds of IPv6 addresses.
but also of carriage of transit traffic destined to other providers' customers, i.e. you as a provider would be forced to shoulder costs with no way to recover them.
One would assume that if you interconnect with your geographical neighbours for the purposes of exchanging geo-addressed traffic then you would also work out a cost-sharing agreement of some sort. As long as geo-addressing is optional, this type of problem will not exist. In the end we may find that geo-addressing dominates in some parts of the world, where it suits their culture and communication patterns. And the current random addressing dominates in other parts of the world, such as the USA, where chaos is highly valued in the culture. I don't see geo-addressing as a cure-all, just an option that we should make available using the vast reserved space in IPv6. 50 years from now the Internet will not be able to cope with global routing table size using the existing random addressing scheme because every small and mid-sized company will want to be multi-homed. Multi-homing is something that people learn to need when they see the disasters that happen to single-homed companies. Over time, basically every organization will want to be multi-homed in order to spread the risk. In fact, it may become a requirement of many business insurance policies. In a world where geo-addressing is widespread, a North American ISP can have a single route for all of Europe. A small German company can have geo-addresses, and be connected to three local ISPs who all peer locally to exchange geo-addressed traffic. Any two of those three ISPs can go off-line and the small German company will still be fully connected. We have enough knowledge of intercontinental cable routes today in order to design a geographical aggregation topology. There are unlikely to be any significantly new intercontinental or overland paths that could not be predicted based on today's knowledge. It would make an interesting university research project to design such an addressing topology and I hope that someone will take up the challenge. Until we have this kind of work on the table to discuss, it is hard to prove that geographic addressing will work or that it won't work. --Michael Dillon P.S. if anyone here is under the illusion that I am talking about assigning IPv6 addresses to countries in the same way as E.164 addressing, then you should check the difference between geographical and geopolitical in the dictionary.
On Thu, 31 Mar 2005 15:20:21 +0100, Michael.Dillon@radianz.com wrote:
We have enough knowledge of intercontinental cable routes today in order to design a geographical aggregation topology. Do you *really* think anyone is willing to invest *real* money into a *real* project for a geographical aggregation topology ?
Especially as switching and digging new cables can be avoided by putting a bit more computing power into these boxes called routers ? And all this in a world, where certain "we think we are big" operators are refusing peerings with smaller ISP's ? Do you *really* think these "big is best" policy operators would change their dominating policy for a geographical concept ? Best Regards Oliver Bartels Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver@bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0
We have enough knowledge of intercontinental cable routes today in order to design a geographical aggregation topology.
Do you *really* think anyone is willing to invest *real* money into a *real* project for a geographical aggregation topology ?
Yes I do. I know for a fact that universities invest a lot of real money into network research to evaluate many, many different possible futures. I regularly read research papers about these things and I think that design of a feasible geo-addressing topology is exactly the kind of thing that a university researcher or grad student would do. --Michael Dillon
On 31-mrt-05, at 16:20, Michael.Dillon@radianz.com wrote:
If I've understood correctly, geographical addressing will lead to forced interconnection of providers in the geographical area
This is a common misconception. Unfortunately, many people have assumptions about geography in routing based on mailing list discussions.
We have enough knowledge of intercontinental cable routes today in order to design a geographical aggregation topology. There are unlikely to be any significantly new intercontinental or overland paths that could not be predicted based on today's knowledge. It would make an interesting university research project to design such an addressing topology and I hope that someone will take up the challenge. Until we have this kind of work on the table to discuss, it is hard to prove that geographic addressing will work or that it won't work.
I put a lot of effort into geographic addressing. Some of you may even remember that I talked about this at RIPE 44 and RIPE 46: once for the IPv6 wg, which was slightly perplexed, and then for the routing wg where I don't think anyone got it. It's a significant departure from business as usual, I'm afraid... Have a look at: http://www.bgpexpert.com/presentations/ http://www.muada.com/drafts/draft-van-beijnum-multi6-isp-int-aggr-01.txt The interesting part here is that each AS gets to implement geographical aggregation completely independent from every other AS. This includes NOT aggregating, which means that there is absolutely NO difference between simply doing PI and following my proposal for anyone who chooses to carry all routes everywhere (except that the address space for multihomers must be allocated according to geography). There are no changes to BGP. The idea is that everyone announces their geographical customer routes everywhere, but people filter out the geographically undesirable routing information _within_ _their_ _own_ _AS_. So there is no dependency on free transit, and only a limited dependency on interconnection. When there is lack of interconnection in an area, this doesn't lead to lack of reachability, just to lack of aggregation. In the common case where a multihomer connects to two ISPs in the same area and both ISPs are well-connected in the area, there is potential for aggregation. In places where there are so many multihomers that the amount of routing information becomes problematic, there is bound to be reasonable interconnection, especially when looking at the continent or part-of-a-continent scale.
On Thu, 31 Mar 2005 11:51:59 +0100, Michael.Dillon@radianz.com wrote:
>It was never tried so how can you say that it was broken
>by design?
I also never tried to drive my car with 200km/h against
a tree but I can tell you definately its no good ...
Geographical hierachies require a interconnection concept
which is radically different from the concept required for a
*competitive* ISP market. They would require "leading"
operators and "sub-level" operators dependent from them.
The time of "postal office" monopolies is over,
*and this is good so*.
>New routers? Since when does BGP or any routing protocol
>have to run on the routers themselves. Look inside a modern
>router and you will often see that the routing and
>packet forwarding decisions are done on separate CPUs.
>And there are boxes on the market that do "route optimization"
>which is just a way of taking the routing decisions outside
>of the routers themselves.
At the end of day one
- might require an update of a underdimensioned forwarding engine.
- a new router because $VENDOR might not be willing to implement
"IPv6-BGP 4+x" on an old box.
I am not talking about *can't* implement, but the chance is high
that $VENDOR sees this as an oportunity to gain additional
$REVENUE. If you have a ten year old car, you probably won't
get an "update" for the latest engine.
The whole table discussion is just because of this resource-limiting
policy build by several $VENDORS and some operators living in
the past century with good old postal telco office "offical" services
("Bundespost").
Take 1 Mio. prefixes with 100 Byte (!) each. And 100 Byte is a *lot*,
even with communities and paths, which even can be combined
for several prefixes together in memory.
This is 100 MByte. No problem today. Why do we talk about the
table size here ?
And in fact, if one would combine all IPv6 prefixes of some ISP
in a *bundle* (remember my level 1/2 proposal), with e.g. 8 Byte
routable address part, one mask length byte plus 7 bytes other stuff,
we are talking about 16 bytes.
10 Mio. (!) prefixes are then 160 MBytes. Again no problem today.
In this scenario you might give each customer its own prefix,
if he want's one or not ...
Conclusion: The "table problem" is a pseudo-problem and is
easily solvalble with modern hardware.
With more than 500K to 1 Mio. prefixes it might be usefull to
think of a new two level BGP4.
Below that: Take BGP4 as it is, no problem.
+20K IPv6 Routes: Again no problem.
We had an 30% increase in the number of IPv4 Routes and
*nothing* happened.
I am a friend of open words:
- The *real* problem is that some big companies would be happy with a
hierachical structure - of course with them on top of the hierachy :-| -
and with totally dependend customers and smaller ISP's.
- And there is a reluctance to invest into modern hardware,
probably because of the dumping price offers within the ISP market.
* These * are the points, not technology, not hardware or software.
Best Regards
Oliver
Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany
oliver@bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0
> Geographical hierachies require a interconnection concept > which is radically different from the concept required for a > *competitive* ISP market. They would require "leading" > operators and "sub-level" operators dependent from them. Not true. Geographical addressing means that a provider uses addresses from a city aggregate for all infrastructure and customers in that city. The city aggregate would be determined and administered by RIPE. All providers who have infrastructure in Paris, for instance, would ask RIPE for the number of Paris addresses that they need, regardless of the size of the operator or their dominance in the market. There already are "leading" operators and "sub-level" operators in the Internet access market. Geo addressing does not change this because geo-addressing is a technical solution to a technical problem of packet routing. > >New routers? Since when does BGP or any routing protocol > >have to run on the routers themselves. Look inside a modern > >router and you will often see that the routing and > >packet forwarding decisions are done on separate CPUs. > >And there are boxes on the market that do "route optimization" > >which is just a way of taking the routing decisions outside > >of the routers themselves. > At the end of day one > - might require an update of a underdimensioned forwarding engine. > - a new router because $VENDOR might not be willing to implement > "IPv6-BGP 4+x" on an old box. The vendor doesn't need to implement IPv6-BGP-4+x on the router if servers in the operator's management systems are doing the IPv6-BGP 4+x function and passing the instructions to the routers using plain BGP4. And the whole point of geo addressing is to avoid the update of underdimensioned forwarding engines when insurance companies require every company to be multihomed in order to qualify for business insurance. Why is it necessary for routers to speak BGP in order to maintain a view of the relatively stable mesh of AS interconnections? Why don't more people do this work with servers which are faster and cheaper and easier to swap(upgrade) than routers? --Michael Dillon
On Thu, 31 Mar 2005 16:23:36 +0100, Michael.Dillon@radianz.com wrote:
Geographical addressing means that a provider uses addresses from a city aggregate for all infrastructure and customers in that city. The city aggregate would be determined and administered by RIPE. All providers who have infrastructure in Paris, for instance, would ask RIPE for the number of Paris addresses that they need, regardless of the size of the operator or their dominance in the market. I don't see the point behind this, you would create even *more* table entries with this approach.
There is operator A with customers in Paris, London and Berlin and operator B with customers in London, Manchester and Birmingham. Result: 6 Prefixes instead of 2. Why: Operator networks are *not* interconnected in regional area categories and prefer internal and peer routes instead of regional upstreams.
There already are "leading" operators and "sub-level" operators in the Internet access market. Geo addressing does not change this because geo-addressing is a technical solution to a technical problem of packet routing. Sorry, I don't see this as an solution.
This is the old Telco approach which works with *one* main operator in Paris, one in London etc. It does not work in a market with non-regional variable interconnections. E.g. we prefer to receive our traffic for Stuttgart in Munich or Frankfurt, because in Stuttgart there is no international exchange.
And the whole point of geo addressing is to avoid the update of underdimensioned forwarding engines when insurance companies require every company to be multihomed in order to qualify for business insurance.
Ceterum Censeo: Routing capacity can only be replaced by routing capacity. Someone has to *calculate* the best path for the IP packets and this someone is called "router". Either it can handle the address space or it cannot, in the second case IPv6 is *useless*. The point: There is no way to make a 1 H.P. 1900 car competitive in a Formula One race. Best Regards Oliver Bartels Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver@bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0
On Wed, Mar 30, 2005 at 09:30:38PM +0200, Hans Petter Holen wrote:
PI will come or IPv6 not fly. Face it.
I agree that IPv6 needs multi-homing to fly - but I was hoping there would be other technical implementations of multi-homing than PI. I do however undersand how multi-homing works with PI addresses - I am not shure I can say the same of other proposals.
http://www.6net.org/publications/deliverables/D4.5.3.pdf Interesting reading, especially the nice table on page 31. All proposals on the table fall short. None can provide all the benefits of true multihoming. Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Hi, El 30/03/2005, a las 21:30, Hans Petter Holen escribió:
Jon Lawrence wrote:
PI will come or IPv6 not fly. Face it.
I agree that IPv6 needs multi-homing to fly - but I was hoping there would be other technical implementations of multi-homing than PI. I do however undersand how multi-homing works with PI addresses - I am not shure I can say the same of other proposals.
I think that it is important to distinguish between the different type of sites and their requirements. I mean i guess that there is a difference between the requirements of a big site with multiple locations over the globe and the requirements of a home network multihomed to the ADSL and cable providers. In addition, i guess that the expected number of multihomed home networks is quite higher than the expected number of really big multihomed sites. So we have that multihoming does not mean the same in the different scenarios. We have different requirements and different scalability requirements. I guess that is it important to find a solution for SOHO multihomed that does not impose additional routes in the global routing table, because of the expected number of such sites. Perhaps such solution will not provide all the benefits of current BGP based multihoming (like traffic engineering, provider independence and perhaps some other). However, it will probably will suit the needs of most SOHO multihomed networks. On the other hand, it is possible that certain mutlihomed sites (probably the big ones) won't find that this alternative solution will suit their needs. In this case, i guess that it is reasonable to assign PI to those. So, my take is that the path is to first understand what types of multihomed sites are well serve with an alternative multihoming solution (like the shim being deployed in the IETF) that does not impose additional burden in the inter domain routing. then understand what sites are not well served by this solution and really need BGP based multihoming. At this point i guess we could be ready to define a policy to assign PI addresses for this type of sites that really need it for multihoming. Regards, marcelo
-hph
On Thu, 24 Mar 2005, Wilfried Woeber, UniVie/ACOnet wrote:
In a perfect world - yes.
But "per default" when you announce something in v6-world, you are "supposed" to announce a /32 (or maybe a /35) _and_ filter anything that is longer than that.
I really don't see any benefit from adding complexity again, other than clinging to the well-worn conservatiopn goal from IPv4.
This is a myth that is hard to kill. There are already today valid, RIR assignments that are /48s. If you where to do what you state above, you have already missed out a part of the IPv6 Internet and there is not much to do. The "filter on /32" comes from some belife that that would be the longest assigned or allocated prefixes. That is not true, and the policy proposed would add to that. I have a hard time seeing what harm consvertaion does and what complexity it would add? - kurtis -
participants (16)
-
Alexander Koch -
Andre Oppermann -
Daniel Roesen -
Elmar K. Bins -
Gert Doering -
Hans Petter Holen -
Havard Eidnes -
Iljitsch van Beijnum -
Jeroen Massar -
Jon Lawrence -
Kurtis Lindqvist -
marcelo bagnulo braun -
Michael.Dillon＠radianz.com -
Oliver Bartels -
Randy Bush -
Wilfried Woeber, UniVie/ACOnet