On Mon, 21 Nov 2005, Lea Roberts wrote: <snip>
the problem with using ASNs is that when you think over the projected lifetime of IPv6, there will be *lots* of ASNs. Note that the 4-byte ASN draft is entering the standards track in IETF. Don't think that tying PI to ASNs is anything more that passing the problem to the next generation (if that long... :-)
It would seem obvious that as network connectivity becomes essential for doing business, it must be reliable. It is unwise to carry forward the IPv4 multi-homing model for network resilience with just faith that the system will be able to scale to an ever larger number of routes. IPv6 has so far failed to deliver on its original promise of seamless renumbering and multi-homing using multiple prefixes. The hard problems still need to be solved in a way that can scale for decades to come.
Can't we all just drop using the word multihoming and IPv6 PI? They all reflect back to how thing was done with IPv4 and those ways are doomed to fail with IPv6 simply due to the size of the IP space. Last I checked around there were some promissing new proposal on the way for how to solve this very basic problem. And in the meantime, drop the thought about multihoming and PI space, start to think about other ways to use the possibility IPv6 give us. Just to mention maybe the biggest advantage, we have that extended header part of IPv6, it give us endless possibilities. and yes I do have some idea about how it can be done but no one really bother to consider geo-based IP's either so... :) Not to forget it quite likely will undermine the entire business case for how ISP's today operate. -- ------------------------------ Roger Jorgensen | rogerj@stud.cs.uit.no | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no -------------------------------------------------------
On Mon, 21 Nov 2005, Roger Jorgensen wrote:
On Mon, 21 Nov 2005, Lea Roberts wrote: <snip>
the problem with using ASNs is that when you think over the projected lifetime of IPv6, there will be *lots* of ASNs. Note that the 4-byte ASN draft is entering the standards track in IETF. Don't think that tying PI to ASNs is anything more that passing the problem to the next generation (if that long... :-)
It would seem obvious that as network connectivity becomes essential for doing business, it must be reliable. It is unwise to carry forward the IPv4 multi-homing model for network resilience with just faith that the system will be able to scale to an ever larger number of routes. IPv6 has so far failed to deliver on its original promise of seamless renumbering and multi-homing using multiple prefixes. The hard problems still need to be solved in a way that can scale for decades to come.
Can't we all just drop using the word multihoming and IPv6 PI? They all reflect back to how thing was done with IPv4 and those ways are doomed to fail with IPv6 simply due to the size of the IP space. <snip>
Well said.
Can't we all just drop using the word multihoming and IPv6 PI? They all reflect back to how thing was done with IPv4 and those ways are doomed to fail with IPv6 simply due to the size of the IP space. Well said.
indeed. since, by this argument, we can now assume v6 sites will not multi-home, there is no need for PI space at all. randy
* Roger Jorgensen:
Can't we all just drop using the word multihoming and IPv6 PI? They all reflect back to how thing was done with IPv4 and those ways are doomed to fail with IPv6 simply due to the size of the IP space.
I'm a relative newcomer to this area. Could you give a pointer to some explanation *why* the IPv6 address space size causes this problem?
On Thu, 24 Nov 2005, Florian Weimer wrote:
* Roger Jorgensen:
Can't we all just drop using the word multihoming and IPv6 PI? They all reflect back to how thing was done with IPv4 and those ways are doomed to fail with IPv6 simply due to the size of the IP space.
I'm a relative newcomer to this area. Could you give a pointer to some explanation *why* the IPv6 address space size causes this problem?
Just do the math yourself and consider all possibilities and how the IPv4 space are used... but some numbers - the address space is 128bit. - we have a 64bits host prefix at the lower end. - the above give us 64bits of network numbers, that's quite a few billions of networks. BUT - the /48 boundary leaving us with a usable globaly network space of 48bit - from the 48bits only a /8 are usable as it is now, the other 7 /8 are reserved for the future. The absolute max global routing table would by this be 40bits, of course the real one are alot smaller. That one is closer to 32bits, and that is STILL A huge number, probably more close to 20bits of entries. a last comment: the entire idea behind /64 and /48 will cause IPv6 to fail as it is now. Odd as it is, we don't have enough IP space in IPv6. Sure it will last 10, maybe 15-20 years, but that did IPv4 to...... -- ------------------------------ Roger Jorgensen | rogerj@stud.cs.uit.no | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no -------------------------------------------------------
Roger Jorgensen wrote:
On Thu, 24 Nov 2005, Florian Weimer wrote:
* Roger Jorgensen:
Can't we all just drop using the word multihoming and IPv6 PI? They all reflect back to how thing was done with IPv4 and those ways are doomed to fail with IPv6 simply due to the size of the IP space.
I'm a relative newcomer to this area. Could you give a pointer to some explanation *why* the IPv6 address space size causes this problem?
Just do the math yourself and consider all possibilities and how the IPv4 space are used... but some numbers
- the address space is 128bit. - we have a 64bits host prefix at the lower end. - the above give us 64bits of network numbers, that's quite a few billions of networks. BUT - the /48 boundary leaving us with a usable globaly network space of 48bit - from the 48bits only a /8 are usable as it is now, the other 7 /8 are reserved for the future.
The absolute max global routing table would by this be 40bits, of course the real one are alot smaller. That one is closer to 32bits, and that is STILL A huge number, probably more close to 20bits of entries.
a last comment: the entire idea behind /64 and /48 will cause IPv6 to fail as it is now. Odd as it is, we don't have enough IP space in IPv6. Sure it will last 10, maybe 15-20 years, but that did IPv4 to......
You post is still pretty content-free. You're waving with your hand but what do you propose exactly? I've posted my proposals under "Andre's guide to fix IPv6". When do you with yours? -- Andre
Andre Oppermann wrote:
I've posted my proposals under "Andre's guide to fix IPv6". When do you with yours?
Ripped from: http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2005/msg01166....
1. Make /32 the only routable entity so we can use perfect match in the DFZ instead of longest-prefix match.
What about the organizations that have say a /19, want them to inject all their more specific /32's? You can currently already do a perfect match on the first 32bits and then check if there are more specifics for this block or not. But I guess that theory is much better known to you than to me ;)
Perfect match scales better and is way more economically to implement in hard- and soft- ware. (MPLS is perfect match too.) Beyond /32 use longest-prefix up to /64. 32 bit in the DFZ give us 4 billion routable entities. See "Scalability issues in the Internet routing system" thread on NANOG, starting 18. October 2005.
Should indeed work pretty well. This is also one of the many reasons for me to say that when there will be any "IPv6 PI" introduced it should either be of size /32 or come out of a globally single /20 or something large that should accommodate all these prefixes, so that routing engines can be configured to support longer prefixes in that prefix.
2. Drop the Flow Label and Next Header fields from the IPv6 header.
Next Header is required or how else do you know what follows the IPv6 header? Or do you only want to do TCP? What about UDP,SCTP and many other headers (for IPv6 in IPv6, IPv4 in IPv6, IPSEC etc).
They are architectually broken and do not belong to this layer. Just encapsulate the packet in another layer like MPLS.
Then why not drop IP and just route with MPLS? :)
Next Header is broken because it's just source routing again. Dead for a long time. Nobody in their right mind will allow header popping through their firewall/network.
That is only one of the many possibilities to use Next Header for. I guess what you wanted to state here is that you don't see a need for "Hop by Hop Options" and other such headers so that routers don't have to parse through the next header because they don't have to expect anything there. Next Header in itself is the same as the IPv4 protocol field stating that TCP/UDP/etc is following it.
3. Reinsert packet fragmentation into the IPv6 header. Path MTU discovery just ain't cutting it.
And then have routers do fragmentation again? Nah. IMHO fragmentations at endhosts was one of the best things introduced in IPv6. Especially for routers. Also Path MTU works perfectly fine, unless somebody of course drops ICMP, well that is then your issue, not mine.
4. Drop 64 bits from the IPv6 address. The lower 64 bit are just pointless as host indentifier. Very poor overhead ratio.
Maybe you would like to see something like IPv8/IPv16 then, which according to the fortunately vanished mr Fla^Heming used a "StarGate" model. Something like: +----------------------------------------------+ | Ethernet macsrc+dst next=IPv16_SG | +----------------------------------------------+ | IPv16 StarGate = 3ffe::1 next=IPv16_Planet | +----------------------------------------------+ | IPv16 Planet = 4526::1 next=TCP | +----------------------------------------------+ | TCP | +----------------------------------------------+
6. Do away with those stupid ':' separators in IPv6 addresses.
That is just representation, if you want you can drop those, just don't expect any (afaik) tool to parse it for you. Most human brains will not like you dropping it though, they are quite comfortable reading hex nicely grouped in clusters of 16bits but would not like to read something that is not nicely clustered, YMMV. You can always easily patch your kernel to support it if you want. The whole idea with IP addresses is that you stick them in DNS in the first place, so you would not see them anyway. (Or are you mailing address-policy-wg@<hmmm what shall we fill in here, gee so many options>...) Greets, Jeroen
* Jeroen Massar:
1. Make /32 the only routable entity so we can use perfect match in the DFZ instead of longest-prefix match.
What about the organizations that have say a /19, want them to inject all their more specific /32's?
You can inject a /19 as 8192 /32s. Shouldn't make a difference if the /19 is really used. At this stage, it's probably not too wise to embed the /32--/48--/64 in silicon, but vendors will undoubtedly do this if they can save a few bucks and current policies remain as inflexible as they are.
2. Drop the Flow Label and Next Header fields from the IPv6 header.
Next Header is required or how else do you know what follows the IPv6 header? Or do you only want to do TCP? What about UDP,SCTP and many other headers (for IPv6 in IPv6, IPv4 in IPv6, IPSEC etc).
IPv6 was designed for ACL-free software forwarding. This is not what we need today. Real routers must be able to access some layer 4 information. A better header would do away with any layer 3 options or option replacement. It would consist of 7 64-bit words. The first word contains the IP protocol version number, a hop counter (not a TTL, because it can be spoofed), and a bidirectional next-layer protocol identifier (protocol number plus some optional data that is indepedent of the direction of the packet flow and constant for a given "connection"). You can include some bits for QoS if you want, but I'm not sure if this makes sense. This is the first word. After that, the source and destination address follow (two words each). The remaining two remaining words are the next-layer source and destination address identifier (think port number, but you can put some additional cookie in there to make blind spoofing harder). In order to create a reflexive ACL entry, a router would zap the header flags and the hop count (which are ignored during matching anyway) and swap the source and destination addresses. No more upgrades so that you can filter still-a-bit=obscure protocols such as SCTP. Of course, a discussion about header layout is a bit pointless. But it is still a bit unfortunate that a protocol header explicitly designed for efficient forwarding does not come anywhere near that goal.
3. Reinsert packet fragmentation into the IPv6 header. Path MTU discovery just ain't cutting it.
And then have routers do fragmentation again? Nah. IMHO fragmentations at endhosts was one of the best things introduced in IPv6.
Sure, makes sesnse. But signaling that fragmentation is needed must be completely in-line. What about this: Truncate the packet, set a bit in the header, and forward it to the destination? The destination can request retransmission from the source and specify the exact packet size that went through.
Also Path MTU works perfectly fine, unless somebody of course drops ICMP, well that is then your issue, not mine.
The market has spoken. Dropping ICMP is fine, I'm afraid.
4. Drop 64 bits from the IPv6 address. The lower 64 bit are just pointless as host indentifier. Very poor overhead ratio.
Maybe you would like to see something like IPv8/IPv16 then, which according to the fortunately vanished mr Fla^Heming used a "StarGate" model. Something like:
This is indeed a bit drastic. I'd rather see this attacked from the other angle, wasting less then 64 bits for access networks. The main problem I see with the /64 approach is that the remaining number of bits (< 64, may less than 60) is not sufficient to stuff two unique identifiers into the address (provider identifier and globally unique customer site identifier).
(deleted address-policy-wg from the cc:) On 26 nov 2005, at 16.00, Florian Weimer wrote:
2. Drop the Flow Label and Next Header fields from the IPv6 header.
Next Header is required or how else do you know what follows the IPv6 header? Or do you only want to do TCP? What about UDP,SCTP and many other headers (for IPv6 in IPv6, IPv4 in IPv6, IPSEC etc).
IPv6 was designed for ACL-free software forwarding. This is not what we need today. Real routers must be able to access some layer 4 information.
A better header would do away with any layer 3 options or option replacement. It would consist of 7 64-bit words. The first word contains the IP protocol version number, a hop counter (not a TTL, because it can be spoofed), and a bidirectional next-layer protocol identifier (protocol number plus some optional data that is indepedent of the direction of the packet flow and constant for a given "connection"). You can include some bits for QoS if you want, but I'm not sure if this makes sense. This is the first word.
After that, the source and destination address follow (two words each). The remaining two remaining words are the next-layer source and destination address identifier (think port number, but you can put some additional cookie in there to make blind spoofing harder).
In order to create a reflexive ACL entry, a router would zap the header flags and the hop count (which are ignored during matching anyway) and swap the source and destination addresses. No more upgrades so that you can filter still-a-bit=obscure protocols such as SCTP.
Of course, a discussion about header layout is a bit pointless. But it is still a bit unfortunate that a protocol header explicitly designed for efficient forwarding does not come anywhere near that goal.
So AFAIK the state of the art routers does 40G line-rate deep-packet inspection with any pattern matching. So remind me again what the problem is? Price? Sure, that is a question of demand and volume production... When MPLS was new I remember being told by vendors that it was the only way we could forward IPv4 at 10G line-rate. Go figure. - kurtis -
Kurt Erik Lindqvist wrote:
So AFAIK the state of the art routers does 40G line-rate deep-packet inspection with any pattern matching.
Once upon a time, there are people who thought 45Mbps were fast.
So remind me again what the problem is? Price? Sure, that is a question of demand and volume production...
Terabit routers and corresponding bandwidth consumption. Recent findings on the amount of router buffers made terabit electrical routers much less expensive and terabit optical routers, which may be even less expensive than electrical ones, viable.
When MPLS was new I remember being told by vendors that it was the only way we could forward IPv4 at 10G line-rate. Go figure.
When I proposed MPLS, it was over ATM and I already noticed and warned that MPLS (over ATM) inherently is about 10 times slower than IP routers and that MPLS over Ethernet is no better than IP routers. Masataka Ohta
----- Original Message ----- From: "Florian Weimer" <fw@deneb.enyo.de> Sent: Saturday, November 26, 2005 4:00 PM
* Jeroen Massar:
1. Make /32 the only routable entity so we can use perfect match in the DFZ instead of longest-prefix match.
What about the organizations that have say a /19, want them to inject all their more specific /32's?
You can inject a /19 as 8192 /32s. Shouldn't make a difference if the /19 is really used.
At this stage, it's probably not too wise to embed the /32--/48--/64 in silicon, but vendors will undoubtedly do this if they can save a few bucks and current policies remain as inflexible as they are.
Hi, Perfect match is faster but far from better. What I think perhaps would be interesting to see in the future with regards to IPv6 and PI is the following: 1. No PI. _Only_ network operators get a prefix. 2. Customers of network operators can at any time change provider and take their assigned prefix with them. The new provider will announce it as a more specific overriding the aggregate. If the customer decides to get multiple providers, then the network operator with the /32 could also announce a more specific. In the country I live in I can change telecom provider and take my phone number with me to the new provider. Why shouldn't I be able to do that with internet providers? Yes, it will somehow create millions/billions of prefixes (atleasat with todays routing technology/protocols). Network operators should be able to handle that hence rule #1. Joergen Hovland
Jørgen Hovland wrote:
- 1. No PI. _Only_ network operators get a prefix.
I am an operator of a network - do I get a prefix ? (we have lots of computers and need lots of IP addresses: currently the 5 PCs, 2 printers, a phone and some PDA and a server online) I guess you need to define the criteria in some other way. Perhaps beeing registered with the national regulator
2. Customers of network operators can at any time change provider and take their assigned prefix with them. The new provider will announce it as a more specific overriding the aggregate. If the customer decides to get multiple providers, then the network operator with the /32 could also announce a more specific.
In the country I live in I can change telecom provider and take my phone number with me to the new provider. Why shouldn't I be able to do that with internet providers?
Maybe we live in the same country ? The National Reference DataBase NRDB will take care of the routing (http://www.nrdb.no - at some point in time I guess they will move to ENUM - so perhaps jump directly to such a solution. But then it will be more difficult to implement the payment model they have. (It costs the operator more to be connected to this database than to get IP addressess from RIPE in addition there is a quarterly service fee to port numbers and even a per lookup fee)
Yes, it will somehow create millions/billions of prefixes (atleasat with todays routing technology/protocols). Network operators should be able to handle that hence rule #1.
Why should my last provider carry my traffic after I switch provider ? In POTS this may work because there is elaborate interconnect agreements between the providers - I dont know of too may ISPs doing pr user accounting of transit any more.
From the consumer point of view - this is great - from a routing point of view and ISP interconnect point of view - I am not quite sure...
-hph
-----Original Message----- From: Hans Petter Holen [mailto:hph@oslo.net] Sent: 28. november 2005 19:16 Jørgen Hovland wrote:
- 1. No PI. _Only_ network operators get a prefix.
I am an operator of a network - do I get a prefix ? (we have lots of computers and need lots of IP addresses: currently the 5 PCs, 2 printers, a phone and some PDA and a server online)
I guess you need to define the criteria in some other way. Perhaps beeing registered with the national regulator
True. The existing RIPE 200 customer rule for ipv6 PA for instance.
2. Customers of network operators can at any time change provider and take their assigned prefix with them. The new provider will announce it as a more specific overriding the aggregate. If the customer decides to get multiple providers, then the network operator with the /32 could also announce a more specific.
In the country I live in I can change telecom provider and take my phone number with me to the new provider. Why shouldn't I be able to do that with internet providers?
Maybe we live in the same country ? We sure do (well at least since a few months ago)!
The National Reference DataBase NRDB will take care of the routing (http://www.nrdb.no - at some point in time I guess they will move to ENUM - so perhaps jump directly to such a solution. But then it will be more difficult to implement the payment model they have. (It costs the operator more to be connected to this database than to get IP addressess from RIPE in addition there is a quarterly service fee to port numbers and even a per lookup fee)
Yes, it will somehow create millions/billions of prefixes (atleasat with todays routing technology/protocols). Network operators should be able to handle that hence rule #1.
Why should my last provider carry my traffic after I switch provider ? In POTS this may work because there is elaborate interconnect agreements between the providers - I dont know of too may ISPs doing pr user accounting of transit any more.
The only thing the last provider has to pay for is the LIR fee for their /32, not the traffic. More specific routes usually get priority unless Andres magic 32 constant is implemented. I was talking about putting these prefixes in dfz or not. You decide by the amount of interconnections you got. Then you would also probably have to decide a payment model, but it is not my business what you do.
From the consumer point of view - this is great - from a routing point of view and ISP interconnect point of view - I am not quite sure...
Yes thats a question I wasnt even sure about myself. Cheers, Joergen Hovland
HI, On 11/28/05, Jørgen Hovland <jorgen@hovland.cx>
Hi, Perfect match is faster but far from better. What I think perhaps would be interesting to see in the future with regards to IPv6 and PI is the following:
1. No PI. _Only_ network operators get a prefix. 2. Customers of network operators can at any time change provider and take their assigned prefix with them.
#2 sounds like PI to me. What have I missed? -- Cheers, McTim $ whois -h whois.afrinic.net mctim
-----Original Message----- From: McTim [mailto:dogwallah@gmail.com]
#2 sounds like PI to me. What have I missed?
Hello McTim, You are correct. Thats why I wrote PI in the email:-). It is an attempt to suggest an alternative idea to the PI discussion. Don't get me wrong. I am for PI. This idea is perhaps a bit more hierarchical instead of the standard flat one. Just making sure we have thought of everything before we reach consensus because this PI discussion is very important to ipv6. Cheers, Joergen Hovland
* Jørgen Hovland:
1. No PI. _Only_ network operators get a prefix. 2. Customers of network operators can at any time change provider and take their assigned prefix with them. The new provider will announce it as a more specific overriding the aggregate. If the customer decides to get multiple providers, then the network operator with the /32 could also announce a more specific.
This would imply that you cannot filter the routing table at prefix lengths less than /48. What's worse, outage of an ISP routes traffic to a now-unrelated ISP, which must discard traffic at its own cost. Better get rid of the aggregates. 8-/
In the country I live in I can change telecom provider and take my phone number with me to the new provider. Why shouldn't I be able to do that with internet providers?
PSTN routing is completely different. In Germany, routing is mostly static AFAIK, and there is no expectation that you can reach all phone numbers from every phone (and it doesn't work in some cases).
-----Original Message----- From: Florian Weimer [mailto:fw@deneb.enyo.de]
This would imply that you cannot filter the routing table at prefix lengths less than /48. What's worse, outage of an ISP routes traffic to a now-unrelated ISP, which must discard traffic at its own cost. Better get rid of the aggregates. 8-/
In the country I live in I can change telecom provider and take my phone number with me to the new provider. Why shouldn't I be able to do that with internet providers?
PSTN routing is completely different. In Germany, routing is mostly static AFAIK, and there is no expectation that you can reach all phone numbers from every phone (and it doesn't work in some cases).
I can agree to that. So unless there are more to discuss in this matter may I suggest that somebody that really needs it, hello DENIC!:-), write a general PI proposal to speed up the process. Then maybe we all can begin using IPv6! That would be great. Cheers, Joergen Hovland
At 03:37 AM 29/11/2005, Jørgen Hovland wrote:
----- Original Message ----- From: "Florian Weimer" <fw@deneb.enyo.de> Sent: Saturday, November 26, 2005 4:00 PM
* Jeroen Massar:
1. Make /32 the only routable entity so we can use perfect match in the DFZ instead of longest-prefix match.
What about the organizations that have say a /19, want them to inject all their more specific /32's?
You can inject a /19 as 8192 /32s. Shouldn't make a difference if the /19 is really used.
At this stage, it's probably not too wise to embed the /32--/48--/64 in silicon, but vendors will undoubtedly do this if they can save a few bucks and current policies remain as inflexible as they are.
Hi, Perfect match is faster but far from better. What I think perhaps would be interesting to see in the future with regards to IPv6 and PI is the following:
1. No PI. _Only_ network operators get a prefix. 2. Customers of network operators can at any time change provider and take their assigned prefix with them. The new provider will announce it as a more specific overriding the aggregate. If the customer decides to get multiple providers, then the network operator with the /32 could also announce a more specific.
In the country I live in I can change telecom provider and take my phone number with me to the new provider. Why shouldn't I be able to do that with internet providers? Yes, it will somehow create millions/billions of prefixes (atleasat with todays routing technology/protocols). Network operators should be able to handle that hence rule #1.
Interesting - it will work for a while, and then you will get to the limit of deployed capability of routing. Then what? Geoff
* Geoff Huston:
Interesting - it will work for a while, and then you will get to the limit of deployed capability of routing.
Then what?
You buy new routers. What's next? Do you plan to lobby Hollywood to reduce the number of movies create per year, so that your customers have fewer of them to download, and the capacity of your pipes is not exceeded?
At 01:26 AM 30/11/2005, Florian Weimer wrote:
* Geoff Huston:
Interesting - it will work for a while, and then you will get to the limit of deployed capability of routing.
Then what?
You buy new routers.
So what you are saying is that _I_ want address portability and _you_ have to buy new routers. Well that sure works for me! How's the chequebook feeling on your side? (I'm not convinced that you've selected the best of business models, as there does appear to be a significant inconsistency going on in your model in that cost and benefit are not related all that well.) Geoff
So what you are saying is that _I_ want address portability and _you_ have to buy new routers.
Why does inter-AS routing have to be done on the packet-forwarding gateways commonly called "routers"? If routing was done on boxes separate from the packet-forwarding gateways, it would be possible to handle much larger routing tables at much lower cost. The internal architecture of current routers has basically arrived at this solution already except that you are tied to the router manufacturer's hardware and pricelist. --Michael Dillon
On Wed, Nov 30, 2005 at 05:36:11AM +1100, Geoff Huston wrote:
Interesting - it will work for a while, and then you will get to the limit of deployed capability of routing.
Then what?
You buy new routers.
So what you are saying is that _I_ want address portability and _you_ have to buy new routers.
No, what he's saying is "_you_ want _my_ business, so _you_ have to deliver what _I_ want. If you cannot deliver, there is no business for _you_". ISPs do exist for customers, not customers do exist to feed ISPs in the most convenient way for the ISPs. Some folks seem to forget that, looking at all the discussion trying to ignore the demand for real multihoming (and that includes TE and network-wide routing policy implementation, neither being delivered by things like shim6). HOW the requirements are being delivered is another topic. multi6 has resulted in the decision to ignore many critical requirements. We're just asking for something that delivers on the targets. Wasting time with half-solutions is not productive. Halting any development because the magic bullet wasn't found yet ain't either. IMHO PI can buy us the time to find Something New[tm] which delivers without the associated possible problems. Until then, there are two options: halt IPv6 completely, now, or implement as sensible PI policy (1 PI prefix per ASN, no questions asked) to buy us the time. I don't know which way is the better one. But this whole "go to IPv6 but no cookies^WPI for you" ain't fly, that for sure (IMHO, YMMV). Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
On Wed, Nov 30, 2005 at 05:16:47PM +0100, Daniel Roesen wrote:
On Wed, Nov 30, 2005 at 05:36:11AM +1100, Geoff Huston wrote:
Interesting - it will work for a while, and then you will get to the limit of deployed capability of routing.
Then what?
You buy new routers.
So what you are saying is that _I_ want address portability and _you_ have to buy new routers.
No, what he's saying is "_you_ want _my_ business, so _you_ have to deliver what _I_ want. If you cannot deliver, there is no business for _you_".
ISPs do exist for customers, not customers do exist to feed ISPs in the most convenient way for the ISPs. Some folks seem to forget that, looking at all the discussion trying to ignore the demand for real multihoming (and that includes TE and network-wide routing policy implementation, neither being delivered by things like shim6).
BTW... in Germany, the phone operators were forced to implement phone number portability by law. The regulator didn't care about all the whining from the telcos about that being impossible, uneconomic, the world will explode etc. If they manage to get that imposed on the traditional telcos, I wonder how much easier it will be to do that on the ISPs. Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
ISPs do exist for customers, not customers do exist to feed ISPs in the most convenient way for the ISPs. Some folks seem to forget that, looking at all the discussion trying to ignore the demand for real multihoming (and that includes TE and network-wide routing policy implementation, neither being delivered by things like shim6).
BTW... in Germany, the phone operators were forced to implement phone number portability by law. The regulator didn't care about all the whining from the telcos about that being impossible, uneconomic, the world will explode etc. If they manage to get that imposed on the traditional telcos, I wonder how much easier it will be to do that on the ISPs.
Regards, Daniel
-- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
why does this remind me of the law passed (in several different jurisdictions, if the urban myths are to be believed) that mandated PI == 3.2. ... legal talent can not change some laws. --bill
Daniel Roesen wrote:
On Wed, Nov 30, 2005 at 05:16:47PM +0100, Daniel Roesen wrote:
On Wed, Nov 30, 2005 at 05:36:11AM +1100, Geoff Huston wrote:
Interesting - it will work for a while, and then you will get to the limit of deployed capability of routing.
Then what? You buy new routers. So what you are saying is that _I_ want address portability and _you_ have to buy new routers. No, what he's saying is "_you_ want _my_ business, so _you_ have to deliver what _I_ want. If you cannot deliver, there is no business for _you_".
The 'you' here is a remote site where you have no (direct) business relationship with. For that remote site, especially with those words, there is no reason at all to any business with you. They are not going to invest any cash to upgrade their network for you (the I in the sentence).
ISPs do exist for customers, not customers do exist to feed ISPs in the most convenient way for the ISPs. Some folks seem to forget that, looking at all the discussion trying to ignore the demand for real multihoming (and that includes TE and network-wide routing policy implementation, neither being delivered by things like shim6).
But is it PI or a slot in the routing tables you want? The slot can be bought by giving a lot of cash to ISP's so that they accept your prefix.
BTW... in Germany, the phone operators were forced to implement phone number portability by law. The regulator didn't care about all the whining from the telcos about that being impossible, uneconomic, the world will explode etc. If they manage to get that imposed on the traditional telcos, I wonder how much easier it will be to do that on the ISPs.
Why do you even go near the analogy of a Telco? I, nor any other endsite (who isn't a telco) can't do TE nor network-wide routing policies nor any of the other things that people like so much about in the current IPv4 with telephone systems. Telephone is much more like DNS than IP. If you want telco-style "IP portability" then simply (ahem) change (renumber) the IP's on your servers/firewalls etc and update DNS. As that is how a number is 'ported'. Also telco style means that all incoming traffic gets routed over your old ISP. Andre Opperman had a large explanation on this subject on NANOG a couple of weeks ago. See the thread around: http://www.merit.edu/mail.archives/nanog/2005-10/msg00782.html What you seem to want is "IPv6 PI", exactly the same thing as "IPv4 PI". The worry here: routing table size. As not only you will want this, but it might be that suddenly a million or so others also will want this in the future, 20 years and more maybe even 50. We could make a policy to give out "IPv6 PI" the IPv4 way but then we automatically end up with IPv6 swamp when ISP's start restricting the prefixes they accept because they don't want to buy yet another new routing setup. Also remember that to participate in it, you have to see everything, thus all the small fish (the ones needing "IPv6 PI") will require that big fancy new router, got cash for that? The only solution I see here is somewhat of the lines of: +-------------+ | l3 src | | l3 dst | +-------------+ | shim src | | shim dst | +-------------+ Where the 'shim' addresses are "PI" prefixes given out from a special block (eg a /16) where /40's and /48's come out of for the simple purpose that one doesn't have to renumber, just add links and enable your edge boxes to move the original l3 header to shim, and then adding the l3 addresses from the ISP. When the other side receives it, verify&strip the l3's (which are only used between transit/ISP's) and tada done. It's something you can call double NAT or tunneling and this is as far as I understood an extreme simplification of what shim6 is going to do, first per host, but very easily also per site. Indeed that doesn't allow those nice routing tricks to be defined, but if you want to be able to do that, then don't ask for "provider independent address space" but just say that you want a prefix that can be stuck, and then work, in global bgp/dfz*. Greets, Jeroen * = before the obvious person asks, the routing table that is seen by most ISP's on the "internet".
Daniel Roesen wrote:
BTW... in Germany, the phone operators were forced to implement phone number portability by law. The regulator didn't care about all the whining from the telcos about that being impossible, uneconomic, the world will explode etc. If they manage to get that imposed on the traditional telcos, I wonder how much easier it will be to do that on the ISPs.
Very easy. In the Internet the equivalent of phone numers, the DNS names are alleady portable - so you can easily switch ISP and keep your email address and URLs without renumbering. Hans Petter
Very easy. In the Internet the equivalent of phone numers, the DNS names are alleady portable - so you can easily switch ISP and keep your email address and URLs without renumbering.
Imagine you are a hosting provider with, say, 10000 sites (domains), 3000 of them is even not under your control. You have 10 servers to host them (i.e. you need 10 IPs). Changing ISP is really easy? To be a LIR and grab /20 if really need only /28? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
Max Tulyev wrote:
Very easy. In the Internet the equivalent of phone numers, the DNS names are alleady portable - so you can easily switch ISP and keep your email address and URLs without renumbering.
Imagine you are a hosting provider with, say, 10000 sites (domains), 3000 of them is even not under your control. You have 10 servers to host them (i.e. you need 10 IPs).
Changing ISP is really easy?
To be a LIR and grab /20 if really need only /28?
With a /28 you won't appear far in the current IPv4 routing tables either. Most sites filter prefixes longer than 24. How do you currently use such a /28 as PI? Or did you become a LIR and got that /20, just like is possible now with IPv6? As an exercise for the readers try to remember why there are filters on IPv4 /24 boundaries and the try to figure out why there are quite a number of people not wanting IPv6 PI to fill their IPv6 routing tables. Greets, Jeroen
jeroen@unfix.org (Jeroen Massar) wrote:
To be a LIR and grab /20 if really need only /28?
With a /28 you won't appear far in the current IPv4 routing tables either. Most sites filter prefixes longer than 24. How do you currently use such a /28 as PI? Or did you become a LIR and got that /20, just like is possible now with IPv6?
As an exercise for the readers try to remember why there are filters on IPv4 /24 boundaries and the try to figure out why there are quite a number of people not wanting IPv6 PI to fill their IPv6 routing tables.
Even to the risk of upsetting you... These filters do not exist to blind out small PI assignments, they are in place to remove accidental leakage of IGP prefixes caused by some fat-fingered jerk like myself... Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <bu6o7e$e6v0p$2@ID-31.news.uni-berlin.de>) --------------------------------------------------------------[ ELMI-RIPE ]---
On Thu, Dec 01, 2005 at 04:53:44PM +0100, Jeroen Massar wrote:
Max Tulyev wrote:
Very easy. In the Internet the equivalent of phone numers, the DNS names are alleady portable - so you can easily switch ISP and keep your email address and URLs without renumbering.
Imagine you are a hosting provider with, say, 10000 sites (domains), 3000 of them is even not under your control. You have 10 servers to host them (i.e. you need 10 IPs).
Changing ISP is really easy?
To be a LIR and grab /20 if really need only /28?
With a /28 you won't appear far in the current IPv4 routing tables either. Most sites filter prefixes longer than 24. How do you currently use such a /28 as PI? Or did you become a LIR and got that /20, just like is possible now with IPv6?
As an exercise for the readers try to remember why there are filters on IPv4 /24 boundaries and the try to figure out why there are quite a number of people not wanting IPv6 PI to fill their IPv6 routing tables.
Greets, Jeroen
one might also ask why a RIB/FIB entry has more relevance for one size prefix instead of another. --bill
Hi, On Thu, Dec 01, 2005 at 06:30:15PM +0300, Max Tulyev wrote:
Very easy. In the Internet the equivalent of phone numers, the DNS names are alleady portable - so you can easily switch ISP and keep your email address and URLs without renumbering.
Imagine you are a hosting provider with, say, 10000 sites (domains), 3000 of them is even not under your control. You have 10 servers to host them (i.e. you need 10 IPs).
Changing ISP is really easy?
Sounds fairly easy to me - as long as you avoid the mistake of having the DNS not under your control. Which will always make problems anyway - just imagine having high load on one of your servers, and wanting to move those domains hosted there to other servers with less load. So what you saying is "because of not-so-good planning on the side of the hosting provider, the whole world needs to reserve some memory in their routers to route their /28"? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
* Hans Petter Holen:
Very easy. In the Internet the equivalent of phone numers, the DNS names are alleady portable - so you can easily switch ISP and keep your email address and URLs without renumbering.
I can't put DNS names on network interfaces. But I can use private address space and NAT, or public address space, DNS rewriting and double NAT. Not pretty, but gets the job done.
[multiple messages compressed into one] Florian Weimer wrote:
* Hans Petter Holen:
Very easy. In the Internet the equivalent of phone numers, the DNS names are alleady portable - so you can easily switch ISP and keep your email address and URLs without renumbering.
I can't put DNS names on network interfaces. But I can use private address space and NAT, or public address space, DNS rewriting and double NAT. Not pretty, but gets the job done.
(psst... 'double NAT' is one of the things shim6 is going to use) As for "DNS rewriting" any example of that? bmanning@vacation.karoshi.com wrote:
On Thu, Dec 01, 2005 at 04:53:44PM +0100, Jeroen Massar wrote:
As an exercise for the readers try to remember why there are filters on IPv4 /24 boundaries and the try to figure out why there are quite a number of people not wanting IPv6 PI to fill their IPv6 routing tables.
one might also ask why a RIB/FIB entry has more relevance for one size prefix instead of another.
Ease of filtering. Not much more. The 'worthiness' of a prefix depends more on the service provided in that prefix. One for instance would not really want to loose the connectivity to all the DNS root or TLD servers and most ISP's will have a nice red glowing phone when connectivity to google/msn etc is broken. Max Tulyev wrote:
Last time I was a hosting proivider I signed up as a LIR and built my own network infrastructure to the nearest IX points. This time I have outrourced the lot and my 300 server serverfarm is behind a firewall on a handfull of IP addresses
Changing ISP is really easy? Yes.
Stop. You have 10000 domains. You have IP address(es) from ISP A . You are moving to ISP B with OTHER address(es). And you don't need to send 10000 modify requests for these 10000 domains to change A (NS, MX) records. Where is the magic? ;-)
The same as the phone number system. One at a time. Or script your setup, you do know what 'management software' means do you? Look up the term ITIL or ASL once ;) With such a setup I suggest you outsource your "ISP" to the real ISP or plan ahead and become real good friends with your current ISP. You need a /28 and want "Provider Independence". I use a /28 at home. Lets say that I want "PI" too, that would mean I am going to get, pay for and maintain: - Multiple Redundant Routers - Multiple Redundant Links - Multiple Redundant Transits - Own 24/7 NOC (things will fail) - and a lot more... You are willing to do and pay for all that, but don't want to become an LIR? Nah, I rather let some real ISP handle all of that, they have the time to fiddle with peering and transit agreements, billing and all kinds of other time consuming things. Elmar K. Bins wrote:
Even to the risk of upsetting you...
How can you calling yourself a 'fat-fingered jerk' upset me ? :)
These filters do not exist to blind out small PI assignments, they are in place to remove accidental leakage of IGP prefixes caused by some fat-fingered jerk like myself...
So you filter on a /24 because of IGP, thus you will leak out a /23? Adding 8 or so prefixes doesn't really get noticed by many people, but adding 10k does. Filtering based on routing-DB information is thus much better than doing it based on some arbitrary limit. Greets, Jeroen
jeroen@unfix.org (Jeroen Massar) wrote:
Elmar K. Bins wrote: How can you calling yourself a 'fat-fingered jerk' upset me ? :)
;-)
These filters do not exist to blind out small PI assignments, they are in place to remove accidental leakage of IGP prefixes caused by some fat-fingered jerk like myself...
So you filter on a /24 because of IGP, thus you will leak out a /23?
Wrong train of thought. I am of course not leaking anything from my network (first, I train my fingers every day, so they don't get fat, second, I do not redistribute IGP prefixes). The /24 filters we are talking about here are filtering other people's longer-than-/24s out. The /24 filter is just a partly brain-damaged, partly geniously simple way of removing a lot of fat-fingering from my routing table (I am not one of the big transit ISPs, so I'm very happy with that).
Adding 8 or so prefixes doesn't really get noticed by many people, but adding 10k does.
There are companies that run a /20 or bigger nicely sliced into small networks (hundreds or thousands), and sometimes their IGP prefixes leak.
Filtering based on routing-DB information is thus much better than doing it based on some arbitrary limit.
The effort of rebuilding an appropriate ACL every day, the length of the ACL and the router processing degradation or - even worse - running into hard limits, alongside the "update how often?" question prohibit that largely. Of course, having an up-to-date ACL in sync with the routing databases would be the ideal solution, or would it? How many people don't register? How many DBs are there to track? Well... But you have distracted me from the matter at hand, so I repeat again that the /24 filters are not in place to filter out small PI blocks. It's not nice, it's not perfect, but it's there. So any authority that gives out networks (hello RIPE!) should consider everything longer than a /24 as "non routable", and not give out such blocks as v4 PI. Cheers, Elmi.
Elmar K. Bins wrote: [ ... ]
But you have distracted me from the matter at hand, so I repeat again that the /24 filters are not in place to filter out small PI blocks. It's not nice, it's not perfect, but it's there. So any authority that gives out networks (hello RIPE!) should consider everything longer than a /24 as "non routable", and not give out such blocks as v4 PI.
From ripe-357 ( http://www.ripe.net/ripe/docs/pi-requestsupport.html ), Supporting Notes for the Provider Independent (PI) Assignment Request Form
"You must ensure that the End User understands and accepts that PI address space may be more difficult or more expensive to route than PA address space and then confirm this in the "confirmation:" field. You can find more details on the consequences and disadvantages of PI address space in the "IPv4 Address Allocation and Assignment Policy for the RIPE region" (see above for url)."
Cheers, Elmi.
woeber@cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) wrote:
From ripe-357 ( http://www.ripe.net/ripe/docs/pi-requestsupport.html ), Supporting Notes for the Provider Independent (PI) Assignment Request Form
(which I know quite well) Yes, of course nobody guarantees routeability. That's impossible. But even RIPE has changed PI assignment policy a couple of years ago and doesn't give out longer-than-/24 any more. That's not guaranteeing anything, but it raises the probability. Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <bu6o7e$e6v0p$2@ID-31.news.uni-berlin.de>) --------------------------------------------------------------[ ELMI-RIPE ]---
Hi Elmar, You wrote:
woeber@cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) wrote:
From ripe-357 ( http://www.ripe.net/ripe/docs/pi-requestsupport.html ), Supporting Notes for the Provider Independent (PI) Assignment Request Form
(which I know quite well)
Yes, of course nobody guarantees routeability. That's impossible. But even RIPE has changed PI assignment policy a couple of years ago and doesn't give out longer-than-/24 any more.
That's not quite right. There was no policy change introducing a minimum size for IPv4 PI assignments. PI assignments are made on the same basis as PA assignments. It's not unusual for people to request PI assignments longer than a /24 and we have made a couple of dozen so far this year. Regards, -- leo vegoda RIPE NCC Registration Services Manager
Oh, I overlooked that part of your email, but it shows part of your misconception... jeroen@unfix.org (Jeroen Massar) wrote:
You need a /28 and want "Provider Independence". I use a /28 at home. Lets say that I want "PI" too, that would mean I am going to get, pay for and maintain: - Multiple Redundant Routers - Multiple Redundant Links - Multiple Redundant Transits - Own 24/7 NOC (things will fail) - and a lot more...
You are willing to do and pay for all that, but don't want to become an LIR?
The point to this is, that with v6 it is not sufficient to be a LIR to get an independently routable block. You can have as many AS numbers as you want - you get them, when you need them - but you will simply not get a v6 block if you do not have 200 customers, prospective or not. That's the independently-networking end-user problem we have. PI would solve that. Removal of the 200 customer rule would solve that. One-block- per-LIR would solve that. Elmar.
On Thu, Dec 01, 2005 at 09:05:57PM +0100, Elmar K. Bins wrote:
That's the independently-networking end-user problem we have. [...] Removal of the 200 customer rule would solve that. One-block-per-LIR would solve that.
No, it wouldn't. IPv6 allocation policy excludes end-sites, no matter wether they are LIR or not. DENIC is clearly an end site. At least I'm not aware that it's in the business of providing Internet connectivity to other entities. Currently, it's not even enough to throw money at the problem (pay LIR fees for not being a LIR but getting IP space), you also have to be sufficiently large to claim being an enterprise-internal ISP. Then again, even some school in Switzerland and one/three-man living room consulting companies manage that, surprisingly. Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
dr@cluenet.de (Daniel Roesen) wrote:
No, it wouldn't. IPv6 allocation policy excludes end-sites, no matter wether they are LIR or not. DENIC is clearly an end site. At least I'm not aware that it's in the business of providing Internet connectivity to other entities.
Then you have skipped some press releases ;-) But you're right, the "no end user" thing has to go. I just forgot about that. Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <bu6o7e$e6v0p$2@ID-31.news.uni-berlin.de>) --------------------------------------------------------------[ ELMI-RIPE ]---
* Elmar K. Bins:
That's the independently-networking end-user problem we have. PI would solve that. Removal of the 200 customer rule would solve that. One-block- per-LIR would solve that.
Doesn't need DENIC two blocks, one for their production network, and one for anycast? Or would you be willing to subject yourself to an ISP for the production network? Why not for anycast service?
fw@deneb.enyo.de (Florian Weimer) wrote:
That's the independently-networking end-user problem we have. PI would solve that. Removal of the 200 customer rule would solve that. One-block- per-LIR would solve that.
Doesn't need DENIC two blocks, one for their production network, and one for anycast? Or would you be willing to subject yourself to an ISP for the production network? Why not for anycast service?
How come, it's always you who knows what other people need? Of course we are happy enough to connect our office to a potent ISP on a PA block, no hassle. If they let us advertise the assignment on some peering matrix and the partners take it, the better; but that's not really necessary for an office. Apart from that, we're working on solutions, both for registry services production and for the DNS problem, and I am sure we will find them. Elmar.
* Elmar K. Bins:
fw@deneb.enyo.de (Florian Weimer) wrote:
That's the independently-networking end-user problem we have. PI would solve that. Removal of the 200 customer rule would solve that. One-block- per-LIR would solve that.
Doesn't need DENIC two blocks, one for their production network, and one for anycast? Or would you be willing to subject yourself to an ISP for the production network? Why not for anycast service?
How come, it's always you who knows what other people need?
This was a real question, not a rhetorical one. I was genuinely wondering whether "one-block-per-LIR" would be enough. Not everything I wrote is intended to be provocative. 8-)
fw@deneb.enyo.de (Florian Weimer) wrote:
Doesn't need DENIC two blocks, one for their production network, and one for anycast? Or would you be willing to subject yourself to an ISP for the production network? Why not for anycast service?
How come, it's always you who knows what other people need?
This was a real question, not a rhetorical one. I was genuinely wondering whether "one-block-per-LIR" would be enough. Not everything I wrote is intended to be provocative. 8-)
Ok, then that's a misunderstanding (my memory has more than a week backlog or so). Actually, it's like I wrote - we're working on something. Not sure how to do it, though. Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <bu6o7e$e6v0p$2@ID-31.news.uni-berlin.de>) --------------------------------------------------------------[ ELMI-RIPE ]---
Hi, On Tue, Dec 06, 2005 at 02:58:50PM +0100, Florian Weimer wrote:
That's the independently-networking end-user problem we have. PI would solve that. Removal of the 200 customer rule would solve that. One-block- per-LIR would solve that.
Doesn't need DENIC two blocks, one for their production network, and one for anycast? Or would you be willing to subject yourself to an ISP for the production network?
That's what DENIC is doing right now, doing BGP-multihoming with a /48 from their upstream ISP. (Which is certainly something people *do* disagree upon - but as they seem to be happy with their ISPs reliability, it will still work even if someone filters out the /48).
Why not for anycast service?
It could certainly be done, but as there are going to be *many* instances, distributed all over the place, it would be a lot less hassle to have a network from a well-known block that people would know "hey, permit this through our filters, it's a TLD anycast network". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
On 30 nov 2005, at 17.16, Daniel Roesen wrote:
ISPs do exist for customers, not customers do exist to feed ISPs in the most convenient way for the ISPs. Some folks seem to forget that, looking at all the discussion trying to ignore the demand for real multihoming (and that includes TE and network-wide routing policy implementation, neither being delivered by things like shim6).
I think you are contradicting yourself here. Shim6 does give the end- user TE capability. It does not give the ISP the possibility to ignore it, as they could today. I am not sure what you mean with "network-wide routing policy implementation".... I have still to figure out what the "real multihoming" thing is, but I am sure it must be beautiful.
HOW the requirements are being delivered is another topic. multi6 has resulted in the decision to ignore many critical requirements. We're just asking for something that delivers on the targets. Wasting time with half-solutions is not productive. Halting any development because the magic bullet wasn't found yet ain't either.
If you have alternative ideas you know how it works - send text. - kurtis -
On Thu, 1 Dec 2005 09:11:48 +0100, "Kurt Erik Lindqvist" <kurtis@kurtis.pp.se> said:
On 30 nov 2005, at 17.16, Daniel Roesen wrote:
ISPs do exist for customers, not customers do exist to feed ISPs in the most convenient way for the ISPs. Some folks seem to forget that, looking at all the discussion trying to ignore the demand for real multihoming (and that includes TE and network-wide routing policy implementation, neither being delivered by things like shim6).
I think you are contradicting yourself here. Shim6 does give the end-
s/does/may ? ;)
user TE capability. It does not give the ISP the possibility to ignore it, as they could today.
Shim6 is work in progress and may be used as an argument to adjust adress-assignment policies sometime in the future. If we want ipv6 deployed today we have to provide a mechanism to support requirements about redundancy and independence from individual providers.
I am not sure what you mean with "network-wide routing policy implementation"....
I guess this relates to supporting infrastructure necessary for shim6 to support or replace current ipv4 technology like load-balancing, filtering etc. If standards are defined today and everyone agree to implement them asap it will still take years before such products are available and a commercially viable alternative. Shim6 has a potential to provide improved "granularity" in traffic management (individual path-selection for each source-destination HBA-pair) but that is irrelevant until the technology is actually there. Bottom line: it's fine to develop technology for the future, but operational procedures and policies must be supported by current technology. //per -- Per Heldal heldal@eml.cc
Per Heldal wrote:
Shim6 is work in progress and may be used as an argument to adjust adress-assignment policies sometime in the future. If we want ipv6 deployed today we have to provide a mechanism to support requirements about redundancy and independence from individual providers.
I think this hit the nail on the head. Providers (especially those non-LIR) will not accept something along the lines of SHIM6 or A.N.Other competing idea until it gives them just that -- INBOUND ROUTING INDEPENDENCE. The only way these people see achieving this is if they can announce their prefix (of whatever size or status) to each of their providers and have it form part of everybody's tables. Personally I don't have a view either way as whether it should be PI or Special Assignments or Become-A-LIR to achieve it, although everyones fees will drop with more LIRs (read: members). My view is relatively simple; either give everyone who wants one and has an AS-Number a /32 or allow /48s into the backbone table. This is of course if we actually want to give up using IPv4; without the above most providers will see it as a step backward and a bad thing (tm). I am fast gathering this is an unpopular position so I'll get the asbestos underwear ready, but in the smaller circles (read: Tier 3 and below) this is an absolute requirement. -- Best Regards, Cameron Gray Director, Netegral Limited www.netegral.co.uk | 0871 277 6845
The only way these people see achieving this is if they can announce their prefix (of whatever size or status) to each of their providers and have it form part of everybody's tables.
Why should it form part of EVERYBODY's tables? If we had geotop addressing then people could announce their prefix (of whatever size or status) to each of their providers and it would only form part of the tables in the same geotopological aggregate, i.e. the same city. The rest of the world will not see it at all. There is a REAL problem with assuming that there will be a *SINGLE* global routing table. We know that there are limits to the growth of the global routing table due to RAM capacity of routers, CPU capacity of routers and the time required to load a full set of announcements over the circuits connecting to peers. These are all hard limits that require cash, and business cases in order to extend them. We cannot assume that announcing a route will result in it being added to the global routing table. It is highly likely that ISPs will filter announcements on one basis or another in order to keep their copy of the global routing table small enough for their network to handle. The end result is fragmentation into many global routing tables, none of which are complete. And this equals fragmentation of the Internet with widespread inability to reach other sites. --Michael Dillon
Michael.Dillon@btradianz.com wrote:
The only way these people see achieving this is if they can announce their prefix (of whatever size or status) to each of their providers and have it form part of everybody's tables.
Why should it form part of EVERYBODY's tables?
If we had geotop addressing then people could announce their prefix (of whatever size or status) to each of their providers and it would only form part of the tables in the same geotopological aggregate, i.e. the same city. The rest of the world will not see it at all.
The huge problem with this is the costs model, who to charge for what. Next to that the person you quotes wants "full control" which is something he won't get when you do geo addressing, at least not with the proposals made so far. PS: Could you please keep attribution, looking into the archives or other mails to find out who you are quoting above is really annoying. <SNIP>
We cannot assume that announcing a route will result in it being added to the global routing table. It is highly likely that ISPs will filter announcements on one basis or another in order to keep their copy of the global routing table small enough for their network to handle.
There is a simple answer here: pay enough cash to people and they will route anything you like. At a certain point only "payed prefixes" will be accepted and the rest can be filtered. Maybe a model where one can get a /48 from the RIR's when they pay them say $1000 dollar/month, the RIR then marks this prefix as 'payed' in the registry so that ISP's can filter on it will become viable at a certain point. Not paying your fee will make you filtered. *dream of global fully automated setups*. But this might already come with hopefully the (BGP) certificates that APNIC (*) is introducing. When your payment period expires and one didn't renew you don't have a valid certificate and thus your announcements are not accepted anymore... IP's will then really start costing money, but hey if your business is doing good, and you need the addresses then you get revenue for them anyway, simple business 101. Greets, Jeroen * = http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51-address-c...
On 1 dec 2005, at 11.44, Cameron C. Gray wrote:
Per Heldal wrote:
Shim6 is work in progress and may be used as an argument to adjust adress-assignment policies sometime in the future. If we want ipv6 deployed today we have to provide a mechanism to support requirements about redundancy and independence from individual providers.
I think this hit the nail on the head. Providers (especially those non-LIR) will not accept something along the lines of SHIM6 or A.N.Other competing idea until it gives them just that -- INBOUND ROUTING INDEPENDENCE.
Now you are mixing two issues that Per separated though. Per pointed out that shim6 is work in progress while we need a policy now.
My view is relatively simple; either give everyone who wants one and has an AS-Number a /32 or allow /48s into the backbone table. This is of course if we actually want to give up using IPv4; without the above most providers will see it as a step backward and a bad thing (tm).
I think each LIR should get a /32 and we should drop the 200 "customer" rule. But that is just me... - kurtis -
Kurt Erik Lindqvist wrote:
I think this hit the nail on the head. Providers (especially those non-LIR) will not accept something along the lines of SHIM6 or A.N.Other competing idea until it gives them just that -- INBOUND ROUTING INDEPENDENCE.
Now you are mixing two issues that Per separated though. Per pointed out that shim6 is work in progress while we need a policy now.
Kurt, I agree with you they are separate concerns, however as I pointed out they must be addressed similarly if IPv6 is to be adopted on any meaningful scale. I think as far as possible policies should speak to the assumed use and be extensible rather than a stopgap - "we do it this way now, but we now its not good and will change". My point was that yes SHIM6 is a work-in-progress but is not a solution that non-LIR providers will accept willingly; many would rather welcome doomsday of no more address space than work with something that limits their independence. Addressing previous criticisms, As far as the recurring argument of investment to support growing routing tables and memory requirements - how many of you had this when specifying individual hosts? Why can't every server just have the 64K Bill Gates promised would be enough? And wait, didn't he also say the Internet wasn't worth worrying about? Routing equipment will grow and adapt to the technical needs and business will have to fund it or send their customers elsewhere, its an evolution not something we all have to be protected from. (Not that RIPE is a place to dictate business cases and budgets anyway...) Can anyone digest for me into simple bullet points the other arguments for not allowing end site multihoming (and possibly PI therefore), other than: a) routing table size and therefore equipment concerns b) growing/padding RIPE membership numbers c) other immature solutions which border on NAT-insanity which don't actually address the independence angle I see the a) and c) above as cosmetic and easy to work around, and i think that b) would only be a good thing (tm) as all our fees drop with more members. Otherwise I can't see any more limiting factors to running it almost the same way as v4, instead of multiple prefixes per applicant its one. -- Best Regards, Cameron Gray Director, Netegral Limited www.netegral.co.uk | 0871 277 6845
Kurt Erik Lindqvist wrote: <SNIP>
I think each LIR should get a /32 and we should drop the 200 "customer" rule. But that is just me...
A question which most likely only RIPE NCC can answer: has there ever been a LIR who requested an IPv6 allocation and got rejected? LIR's are usually already have 200+ customers, let alone in planning. The people who are complaining (and not proposing what could be done) on this list don't want to be an LIR in the first place. Removing the 200 rule thus would not have much effect in all those cases. Also, they are usually end-sites (eg companies) thus would not pass that rule of the current policy. ISP's with less than 200 customers would indeed. But does it make sense to assign a complete /32 to a company that would not even allocate 200 /48's out of 65k in that /32? Looks a lot like address waste to me. Indeed a /48 to a dailup is also exactly that, for that matter out of my /48 I also only use one single /64, as bridging is more convenient than routing, though I could make my network using a couple of /64's if I wanted, but why should I? Now I can move boxes around without having to renumber them, which I already did 3 times. Kurt Erik Lindqvist wrote:
On 1 dec 2005, at 12.01, Randy Bush wrote:
If you have alternative ideas you know how it works - send text.
draft-ietf-ipngwg-gseaddr-00.txt
same one the ietf has ignored and lied about for eight years now
I am looking forward to the BOF....:-)
The BOF or the WAR? :) Kidding aside, the distribution of address space doesn't have much to do with routing table size, which is where most people seem to be concerned over. Greets, Jeroen
On Mon, Dec 05, 2005 at 02:38:06PM +0100, Jeroen Massar wrote:
A question which most likely only RIPE NCC can answer: has there ever been a LIR who requested an IPv6 allocation and got rejected?
LIR's are usually already have 200+ customers, let alone in planning.
The people who are complaining (and not proposing what could be done) on this list don't want to be an LIR in the first place. Removing the 200 rule thus would not have much effect in all those cases.
There are certainly organisations that cannot meet the 200 rule that have a /32.. RIPE-NCC is not inflexible. Tim::/1
Hi Jeroen, Jeroen Massar wrote:
<SNIP>
I think each LIR should get a /32 and we should drop the 200 "customer" rule. But that is just me...
A question which most likely only RIPE NCC can answer: has there ever been a LIR who requested an IPv6 allocation and got rejected?
We analysed the requests and questions we have received and presented the details at RIPE 50. http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-ap-ipv6nu mbers.pdf mms://webcast.ripe.net/ripe-50/address-policy-1.wmv http://www.ripe.net/ripe/wg/address-policy/r50-minutes.html (section F) Basically, ~2% of requests did not end in address space being registered. We don't know how many requests are not sent in. Regards, -- leo vegoda RIPE NCC Registration Services Manager
On Tue, Dec 06, 2005 at 09:42:09AM +0100, leo vegoda wrote:
We analysed the requests and questions we have received and presented the details at RIPE 50.
http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-ap-ipv6nu mbers.pdf
mms://webcast.ripe.net/ripe-50/address-policy-1.wmv
http://www.ripe.net/ripe/wg/address-policy/r50-minutes.html (section F)
Basically, ~2% of requests did not end in address space being registered. We don't know how many requests are not sent in.
Thanks Leo, very interesting. We noted one knockon effect of RIPE policy. I don't know the full details, but essentially for a tunnel broker service we wanted to offer a /48 to end sites out of an existing /32, but were unable to do so because the 'paperwork' to be sent on to RIPE-NCC for each /48 was needed in advance for the ISP owning the /32 to allocate a (say) /40 to the broker service, and that added a notable hurdle. So we ended up using a /48 for the broker and allocating /56 and /64 blocks. Is this the way it's meant to be, or should the ISP owning the /32 only need to report usage when asking for more space itself? -- Tim/::1
Hi, On Tue, Dec 06, 2005 at 10:55:39AM +0000, Tim Chown wrote:
a /48 for the broker and allocating /56 and /64 blocks. Is this the way it's meant to be, or should the ISP owning the /32 only need to report usage when asking for more space itself?
Well, it depends. If you want to "ASSIGN" a /40 to the tunnel broker, it falls into the category "assignment of networks larger than a /48 to the end user", and that's paperwork. The way it was meant to be done is doing a sub-allocation (which never goes to "end-users", unlike an assignment), and IPv6 sub-allocations, as far as I understand the policy, don't need to be approved by the NCC beforehand. Of course, when you sub-allocate all of your space away, and the receipients don't use it, you won't be able to get more space for you - so use with care. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
Hi, On 6 Dec 2005, at 11:55, Tim Chown wrote: [...]
Basically, ~2% of requests did not end in address space being registered. We don't know how many requests are not sent in.
Thanks Leo, very interesting.
We noted one knockon effect of RIPE policy. I don't know the full details, but essentially for a tunnel broker service we wanted to offer a /48 to end sites out of an existing /32, but were unable to do so because the 'paperwork' to be sent on to RIPE-NCC for each /48 was needed in advance for the ISP owning the /32 to allocate a (say) /40 to the broker service, and that added a notable hurdle. So we ended up using a /48 for the broker and allocating /56 and /64 blocks. Is this the way it's meant to be, or should the ISP owning the /32 only need to report usage when asking for more space itself?
I think someone else mentioned that a sub-allocation would have worked quite nicely in a case like this. It's worth noting that the current policy does not require an LIR to get approval before making a sub-allocation of any size. Regards, -- leo vegoda Registration Services Manager RIPE NCC
leo vegoda wrote: [ Cut from the end, to reply on the former thread, replyers might want to snip this part ]
On 6 Dec 2005, at 11:55, Tim Chown wrote:
Is this the way it's meant to be, or should the ISP owning the /32 only need to report usage when asking for more space itself?
I think someone else mentioned that a sub-allocation would have worked quite nicely in a case like this. It's worth noting that the current policy does not require an LIR to get approval before making a sub-allocation of any size.
It's also the way SixXS gets assigned a prefix, usually a /40, for a PoP from an ISP to be used for that ISP's PoP and manages this for that ISP, allocating toward endusers. One could see this as if one is 'outsourcing tunneled IPv6 end-user connectivity'. [ New Thread ]
On 6 Dec 2005, at 11:55, Tim Chown wrote: <SNIP>
We noted one knockon effect of RIPE policy. I don't know the full details, but essentially for a tunnel broker service we wanted to offer a /48 to end sites out of an existing /32, but were unable to do so because the 'paperwork' to be sent on to RIPE-NCC for each /48 was needed in advance for the ISP owning the /32 to allocate a (say) /40 to the broker service, and that added a notable hurdle. So we ended up using a /48 for the broker and allocating /56 and /64 blocks.
/56's are most likely enough for most 'home end-site'. A single /56 provides 2^(64-56 = 8) = 256 /64's. Let's introduce some terms: end-site: a location where IP connectivity is delivered and managed by a single "IT/IS staff"/person. ISP: organization that provides connectivity to end-site. Then we get two types of endsites: 'home end-site': a location (residence) where living (fun,sleeping,eating) is the prime objective. 'work end-site': a location where work is the prime objective and no sleeping is done. Of course there are a couple of nice things like hotels or resthouses, but those are delivering work to let the people live there, people there are being serviced to get living conditions (internet is a a requirement for that don't you think? :) etc. Another one could be home-workers. Maybe the city planning could determine it better, in many buildings you are not allowed to spend the night as they where not planned to be used for that. Currently both kinds of end-sites get /48's. For the work end-site the /48 should suffice all those sites as defined by the current policy. For home end-sites I believe that a /48 really is way too much. I have to see, let alone dream up, a home where even 25 separate networks would be used. Personally(*) I even ditched the routed network thing completely even though I effectively could setup at least 4 links, separately routed, thus 4x /64. Bridging seemed much easier in my case. I personally don't home users ever go over the 256 /64's, thus a /56 should be sufficient. Of course future might change but still. Routing implies that people would configure it or that it would be autonomicly configured which is not available yet either. Prefix Delegation might work, but on 256 levels? There where before a couple of other people noting the change of HD ratio, though I haven't seen much about that discussion recently, Tim's note above reminded me of it. In SixXS we typically use a /40 for a PoP, after 255 subnets (the first /48 is for tunnels) this assignment is full. In Tim's case with the same amount of users he will only use a single /48, which is 1/256th of what we just "burned". As noted above I personally believe that a /48 for 'work' sites is good. They can then always easily move between sites, and this will for certain be enough for 99.99% (or so) of the endsites that fall in this category. For a home-site situation a full /48 is IMHO really overkill, as noted above. One of the reasons for saying 'all endsites a /48' was that all ISP's would give everybody a /48, renumbering would then not involve replanning onces network because one didn't get enough IP space. Creating a difference for home and work sites could only cause a problem when a work site becomes a home site, but I don't see that happening. Home to work, in case that happens, would get more address space at that point, thus that is not an issue either (except for the renumbering but let's not think about that, that is a different ballpark ;) Is it maybe time to look at this /48 policy and change it in the direction of the above that home endsites get a /56 instead of a full blown /48 which they will never use. Or do people think that it is fine and that we should not bother here at all? Greets, Jeroen * = http://unfix.org/~jeroen/network/ in case one is wondering.
quite sure there was a discussion about this some months back and most people could agree on that a /56, maybe even /52 was a better size than /48. But maybe it was on ipv6-wg@ripe.net ? On Wed, 7 Dec 2005, Jeroen Massar wrote:
leo vegoda wrote:
[ Cut from the end, to reply on the former thread, replyers might want to snip this part ]
On 6 Dec 2005, at 11:55, Tim Chown wrote:
Is this the way it's meant to be, or should the ISP owning the /32 only need to report usage when asking for more space itself?
I think someone else mentioned that a sub-allocation would have worked quite nicely in a case like this. It's worth noting that the current policy does not require an LIR to get approval before making a sub-allocation of any size.
It's also the way SixXS gets assigned a prefix, usually a /40, for a PoP from an ISP to be used for that ISP's PoP and manages this for that ISP, allocating toward endusers. One could see this as if one is 'outsourcing tunneled IPv6 end-user connectivity'.
[ New Thread ]
On 6 Dec 2005, at 11:55, Tim Chown wrote: <SNIP>
We noted one knockon effect of RIPE policy. I don't know the full details, but essentially for a tunnel broker service we wanted to offer a /48 to end sites out of an existing /32, but were unable to do so because the 'paperwork' to be sent on to RIPE-NCC for each /48 was needed in advance for the ISP owning the /32 to allocate a (say) /40 to the broker service, and that added a notable hurdle. So we ended up using a /48 for the broker and allocating /56 and /64 blocks.
/56's are most likely enough for most 'home end-site'. A single /56 provides 2^(64-56 = 8) = 256 /64's.
Let's introduce some terms:
end-site: a location where IP connectivity is delivered and managed by a single "IT/IS staff"/person. ISP: organization that provides connectivity to end-site.
Then we get two types of endsites:
'home end-site': a location (residence) where living (fun,sleeping,eating) is the prime objective.
'work end-site': a location where work is the prime objective and no sleeping is done.
Of course there are a couple of nice things like hotels or resthouses, but those are delivering work to let the people live there, people there are being serviced to get living conditions (internet is a a requirement for that don't you think? :) etc. Another one could be home-workers. Maybe the city planning could determine it better, in many buildings you are not allowed to spend the night as they where not planned to be used for that.
Currently both kinds of end-sites get /48's. For the work end-site the /48 should suffice all those sites as defined by the current policy.
For home end-sites I believe that a /48 really is way too much. I have to see, let alone dream up, a home where even 25 separate networks would be used. Personally(*) I even ditched the routed network thing completely even though I effectively could setup at least 4 links, separately routed, thus 4x /64. Bridging seemed much easier in my case. I personally don't home users ever go over the 256 /64's, thus a /56 should be sufficient. Of course future might change but still. Routing implies that people would configure it or that it would be autonomicly configured which is not available yet either. Prefix Delegation might work, but on 256 levels?
There where before a couple of other people noting the change of HD ratio, though I haven't seen much about that discussion recently, Tim's note above reminded me of it. In SixXS we typically use a /40 for a PoP, after 255 subnets (the first /48 is for tunnels) this assignment is full. In Tim's case with the same amount of users he will only use a single /48, which is 1/256th of what we just "burned". As noted above I personally believe that a /48 for 'work' sites is good. They can then always easily move between sites, and this will for certain be enough for 99.99% (or so) of the endsites that fall in this category. For a home-site situation a full /48 is IMHO really overkill, as noted above.
One of the reasons for saying 'all endsites a /48' was that all ISP's would give everybody a /48, renumbering would then not involve replanning onces network because one didn't get enough IP space. Creating a difference for home and work sites could only cause a problem when a work site becomes a home site, but I don't see that happening. Home to work, in case that happens, would get more address space at that point, thus that is not an issue either (except for the renumbering but let's not think about that, that is a different ballpark ;)
Is it maybe time to look at this /48 policy and change it in the direction of the above that home endsites get a /56 instead of a full blown /48 which they will never use. Or do people think that it is fine and that we should not bother here at all?
Greets, Jeroen
* = http://unfix.org/~jeroen/network/ in case one is wondering.
-- ------------------------------ Roger Jorgensen | rogerj@stud.cs.uit.no | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no -------------------------------------------------------
On Wed, Dec 07, 2005 at 08:02:41PM +0100, Roger Jorgensen wrote:
quite sure there was a discussion about this some months back and most people could agree on that a /56, maybe even /52 was a better size than /48. But maybe it was on ipv6-wg@ripe.net ?
I guess you mean this: http://www.ietf.org/internet-drafts/draft-narten-ipv6-3177bis-48boundary-00.... Tim
On Wed, Dec 07, 2005 at 07:54:13PM +0100, Jeroen Massar wrote:
/56's are most likely enough for most 'home end-site'. A single /56 provides 2^(64-56 = 8) = 256 /64's.
...
For home end-sites I believe that a /48 really is way too much.
...
One of the reasons for saying 'all endsites a /48' was that all ISP's would give everybody a /48, renumbering would then not involve replanning onces network because one didn't get enough IP space. Creating a difference for home and work sites could only cause a problem when a work site becomes a home site, but I don't see that happening. Home to work, in case that happens, would get more address space at that point, thus that is not an issue either (except for the renumbering but let's not think about that, that is a different ballpark ;)
Is it maybe time to look at this /48 policy and change it in the direction of the above that home endsites get a /56 instead of a full blown /48 which they will never use. Or do people think that it is fine and that we should not bother here at all?
So I guess people should comment on Thomas' IETF I-D... I was just surprised that policy seemed to adversely affect the 'ease of deployment' of a broker service. I personally would be fine with a /56 for home use. I do think it's important that ISPs have a common reference for sizes to allocate, though inevitably there will be different offerings (ISPs will look for ways to charge more, as they do by 'selling' IPv4 addresses today). -- Tim/::1
----- Original Message ----- From: "Tim Chown" <tjc@ecs.soton.ac.uk> Sent: Wednesday, December 14, 2005 1:26 PM
Is it maybe time to look at this /48 policy and change it in the direction of the above that home endsites get a /56 instead of a full blown /48 which they will never use. Or do people think that it is fine and that we should not bother here at all?
So I guess people should comment on Thomas' IETF I-D...
I'd like, I see it is that time of the year again when we try to (re)define magic constants because the standard deviation is out of the dynamic "most people" scope. Can't we just respect the physical upper and lower limit instead of trying to decide what the mean value should be? I know it is only a recomendation, but we are still trying to alter it. There are no good reasons for having predefined inner boundaries unless you argue that your software/hardware would better support a,b,c,d and not a-z because the author didn't assume you would use anything else. The reason for that again might just be because they followed previous recomendations in the past for what these numbers usually should be. I would rather see recomendations more like "make sure you assign a subnet which is large enough to handle at least NN times the userbase in two years" than "use prefixlength 48". Jørgen Hovland
On Mon, Dec 05, 2005 at 02:17:25PM +0100, Kurt Erik Lindqvist wrote:
I think each LIR should get a /32 and we should drop the 200 "customer" rule. But that is just me...
That would be too easy :) -- Tim/::1
Hi, On Mon, Dec 05, 2005 at 02:17:25PM +0100, Kurt Erik Lindqvist wrote:
I think each LIR should get a /32 and we should drop the 200 "customer" rule. But that is just me...
Actually I like the "every AS should get a <network>" approach (with a yearly recurring fee for AS and network, to guarantee return of the resources as soon as the importance of having a slot in the global routing table doesn't outweigh the costs anymore). "Every LIR gets a /32 (upon request), no questions asked" is a concept that I'm also happy with - as I have said before. For those that are afraid of the landrush: limit that policy to 5.000 LIRs per region. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
On Mon, Dec 05, 2005 at 06:06:48PM +0100, Gert Doering wrote:
On Mon, Dec 05, 2005 at 02:17:25PM +0100, Kurt Erik Lindqvist wrote:
I think each LIR should get a /32 and we should drop the 200 "customer" rule. But that is just me...
Actually I like the "every AS should get a <network>" approach (with a yearly recurring fee for AS and network,
That sounds good, if the fee is reasonable (means: covers the cost of this only, and not subsidizing LIR operations of others).
"Every LIR gets a /32 (upon request), no questions asked" is a concept that I'm also happy with - as I have said before. For those that are afraid of the landrush: limit that policy to 5.000 LIRs per region.
Those kind of ideas can only come from folks who are already in the business and have their own allocation already. *shaking head* "Sorry, you're to late in the game - the market already has 5000 players, but we have this nice transit offering with PA space here...". Brilliant. Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
"Every LIR gets a /32 (upon request), no questions asked" is a concept that I'm also happy with - as I have said before. For those that are afraid of the landrush: limit that policy to 5.000 LIRs per region. Those kind of ideas can only come from folks who are already in the business and have their own allocation already. *shaking head*
actually, they usually come from non-op idealists who have never met a lawyer. remember TLAs? randy
Hi, On Mon, Dec 05, 2005 at 06:27:24PM +0100, Daniel Roesen wrote:
Those kind of ideas can only come from folks who are already in the business and have their own allocation already. *shaking head*
Unlike some other participants on this list, I'm actually aiming for something that could reach consensus. Otherwise, all this is wasted time, and we could directly go to ITU and ask them to fix the Internet. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
took me the liberty to change the subject line yet again... On Tue, 6 Dec 2005, Gert Doering wrote: <snip>
Unlike some other participants on this list, I'm actually aiming for something that could reach consensus.
Otherwise, all this is wasted time, and we could directly go to ITU and ask them to fix the Internet.
After this quite long but interesting discussion on the two working group mailing lists involved I guess the above sums it up quite well, where do we want to go tomorrow and the day after tomorrow? The future of Internet to put it short... and I'm not sure any of the above are the right place for that discussion. so what sort of consensus are we aiming for, and about what? A new policy for AS, a net block, routing policy, multihoming, or just IPv6 in general? This entire discussion have been sidetracked alot, not a bad thing either, quite alot of topics have been discussed and interesting thoughts brought forward.. but what are our goal with all this? -- ------------------------------ Roger Jorgensen | rogerj@stud.cs.uit.no | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no -------------------------------------------------------
Hi, On Tue, Dec 06, 2005 at 09:43:56AM +0100, Roger Jorgensen wrote:
so what sort of consensus are we aiming for, and about what? A new policy for AS, a net block, routing policy, multihoming, or just IPv6 in general? This entire discussion have been sidetracked alot, not a bad thing either, quite alot of topics have been discussed and interesting thoughts brought forward.. but what are our goal with all this?
The basic policy issue seems to me: - who can get a (globally routeable [1]) IPv6 prefix it might affect the policy "who can get an AS number". The basic technical issue seems to be: - is "IPv4-style" BGP multihoming the correct way to do in IPv6 [1] globally routeable in the sense of "the majority of the participants in the global IPv6 routing system will be able to send packets that way". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
I am seeing a lot of crosspostings on the ipv6 wg and address policy wg list. Before replying to a message, please consider who your intended audience is: <ipv6-wg@ripe.net> is interested in technical topics related to the deplyment of ipv6 <address-policy-wg@ripe.net> is concerned about the policies related to ip allocations and assignments in the RIPE region Please remove a working group list from the CC list if your message is not on topic for that particular working group. Thanks, David Kessens Chairperson ipv6 working group ---
Gert, On Tue, Dec 06, 2005 at 09:56:04AM +0100, Gert Doering wrote:
The basic policy issue seems to me:
- who can get a (globally routeable [1]) IPv6 prefix
it might affect the policy "who can get an AS number".
It seems a really bad idea to connect this to AS number assignments. Currently, the policy for getting AS # assignments is quite clear (one has to multihome to get an AS #!) I don't believe it is smart to change IP number allocation policies in such a way that people are going to multihome (or lie that they are multihoming) so that they can get an AS # (that they don't need) and a PI address allocation. These things are two separate things and should stay separate.
The basic technical issue seems to be:
- is "IPv4-style" BGP multihoming the correct way to do in IPv6
No. The RIPE policies should not make any assumptions on what is "correct" or not. Operators run the Internet and they will decide how to do multihoming. It does not matter whether anybody thinks it is correct or not, it matters whether operators decide to honor your route announcement. Multihoming has in fact very little to do with this whole PI discussion. One can multihome with PI or PA space. However, the most important underlying reason for PI address space allocations is number independance of one's provider. In fact the so called PA blocks are exactly the same: how many ISPs who have a PA block want to be dependant on their transit providers IPs ? Basically, all blocks that a RIR gives out are PI. It is only the customers of the LIRs who get PA address space. I believe that it is much better to drop this whole discussion on PI. The discussion should focus on who can get an IP address space allocation from the RIR and how large. As somebody else mentioned, the Internet is a collection of connected networks and it does not matter whether one is a business, non-profit or ISP. As an example, I don't believe we can justify that a very large entity has (perceived) difficulties in obtaining ipv6 addresses while a tiny ISP that has plans for 200 customers but doesn't quite have that many customers yet and in total has less users than the large entity will get a /32 without any problem. Basically, we don't need additional policies, we need a modification of the current policy to make sure that users of address space of similar size will get and can get similar sized blocks of address space. David Kessens ---
Hi, On Tue, Dec 06, 2005 at 11:02:57AM -0800, David Kessens wrote:
On Tue, Dec 06, 2005 at 09:56:04AM +0100, Gert Doering wrote:
The basic policy issue seems to me:
- who can get a (globally routeable [1]) IPv6 prefix
it might affect the policy "who can get an AS number".
It seems a really bad idea to connect this to AS number assignments.
This wasn't my intention, just an observation. If it's easy to get a "prefix that can be used for BGP multihoming", then the customer will also quite likely need an AS number. This is why the "prefix policy" will inevitably have some effect on the way AS numbers are allocated - maybe not on the AS# policy itself, but at least on the going rate.
Currently, the policy for getting AS # assignments is quite clear (one has to multihome to get an AS #!)
Yes, and this is a Good Thing.
I don't believe it is smart to change IP number allocation policies in such a way that people are going to multihome (or lie that they are multihoming) so that they can get an AS # (that they don't need) and a PI address allocation. These things are two separate things and should stay separate.
They are not the same thing, but not fully separable either... [..]
independance of one's provider. In fact the so called PA blocks are exactly the same: how many ISPs who have a PA block want to be dependant on their transit providers IPs ? Basically, all blocks that a RIR gives out are PI. It is only the customers of the LIRs who get PA address space.
I believe that it is much better to drop this whole discussion on PI. The discussion should focus on who can get an IP address space allocation from the RIR and how large.
Sure, in the end, there the IPv6 address looks the same, whether you tag it PI or PA. They differ only when it comes to giving part of your address space to third parties (and still want to keep the aggregate together) -> PA. [..]
As an example, I don't believe we can justify that a very large entity has (perceived) difficulties in obtaining ipv6 addresses while a tiny ISP that has plans for 200 customers but doesn't quite have that many customers yet and in total has less users than the large entity will get a /32 without any problem.
Basically, we don't need additional policies, we need a modification of the current policy to make sure that users of address space of similar size will get and can get similar sized blocks of address space.
Partly I agree, and to some extent I disagree - the *size* of the block isn't what people seem to be worrying about. The sheer fact that someone can get (or not) an "independent BGP routing table slot" - which is always "one", no matter how big the network is - seems to be. Starting to hand out different sizes might lead people to connecting "importance" to "network size", which would be a wrong signal. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
Gert, On Tue, Dec 06, 2005 at 08:38:40PM +0100, Gert Doering wrote:
As an example, I don't believe we can justify that a very large entity has (perceived) difficulties in obtaining ipv6 addresses while a tiny ISP that has plans for 200 customers but doesn't quite have that many customers yet and in total has less users than the large entity will get a /32 without any problem.
Basically, we don't need additional policies, we need a modification of the current policy to make sure that users of address space of similar size will get and can get similar sized blocks of address space.
Partly I agree, and to some extent I disagree - the *size* of the block isn't what people seem to be worrying about. The sheer fact that someone can get (or not) an "independent BGP routing table slot" - which is always "one", no matter how big the network is - seems to be.
Starting to hand out different sizes might lead people to connecting "importance" to "network size", which would be a wrong signal.
I didn't say that sizes have to be different. I said that an organization with X number of users should get a similar amount of address space as another organization that has X number of users whether it is an ISP or not. As it is however, we currently do give out different sizes as a /32 is the minimum. My personal opinion is that we should keep this minimum as is if we decide to only give out address space to organizations with a very large number of users. My opinion is different if it is decided that organizations with a fairly small numbers of users can get address space directly from the RIPE NCC. A /32 is already extremely generous and at some point it just gets completely ridiculous. David Kessens ---
On Tue, Dec 06, 2005 at 11:02:57AM -0800, David Kessens wrote:
The discussion should focus on who can get an IP address space allocation from the RIR and how large.
And at which price. It's ridiculous to ask the same price from someone who does a single request for IP space and ~never come back, and from someone who starts as a real LIR (you [not you personally] remember? Local Internet REGISTRY!) which does subassigments to hundreds of end users, have those requests validated by NCC hostmasters, take part in LIR trainings etc. pp. You have an AS and do multihome? Pay a small one-time fee (reg effort) and small annual fee (to verify that you still do exist care for the prefix to stay registered, and to cover costs for the database entries for your prefix) and be done with it.[1] But that would be too simple, too fair, too non-discriminating, offer too much independency to mere mortal entities. All those folks who question the right of ASses (AUTONOMOUS systems) to have their own IP space and a routing table slot (in lieu of a better, sufficiently!capable replacement architecture) for technical reasons ("but our routers will break!") should ask themselves one question: are YOU ready to return YOUR prefix(es) because you are NOT in the routing tier 1 club? If not, SHUT UP. Thanks. All but the real routing Tier 1s don't have any TECHNICAL need to announce their own allocations. All other non-upstream-free ISPs only have ECONOMIC reasons to do so. You want to tell others that they are not entitled to that as well? Interesting. In which way are you special? I hereby ask anyone who publicly denies the right for PI to others to explain why THEY are entitled to PI themselves (PA is as David correctly explained nothing else than PI for ISPs, with the allowance to use parts of the address space for customers). And check twice that you aren't deploying double standards and split tongue. Best regards, Daniel [1] Perhaps I'll be annoyed enough by this topic over the christmas/new year's holidays to draft something up... but with the current policy finding process I see almost no chance to get the so-call "consensus" [of a few vocal folks], so it's prolly just wasted time. All those enterprises, non-commercial organizations and clubs who want/need PI aren't really represesented here. -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Daniel Roesen wrote:
On Tue, Dec 06, 2005 at 11:02:57AM -0800, David Kessens wrote:
The discussion should focus on who can get an IP address space allocation from the RIR and how large.
And at which price.
It's ridiculous to ask the same price from someone who does a single request for IP space and ~never come back, and from someone who starts as a real LIR (you [not you personally] remember? Local Internet REGISTRY!) which does subassigments to hundreds of end users, have those requests validated by NCC hostmasters, take part in LIR trainings etc. pp.
You have an AS and do multihome? Pay a small one-time fee (reg effort) and small annual fee (to verify that you still do exist care for the prefix to stay registered, and to cover costs for the database entries for your prefix) and be done with it.[1]
Note that the billing should then still be 'more' expensive than a LIR's individual allocation otherwise most LIR's will convert into independents which gives one more power over prefixes than the above. A LIR should know the procedures which should make requests very easy to process, at least that is the idea, which lowers load on the RIR's. Also, what is your equipment budget? At least 2 routers, 2 uplinks, man-power and a lot of other things. What is ~2K EUR then anyway? Or are you already saving for a bigger fatter router?
But that would be too simple, too fair, too non-discriminating, offer too much independency to mere mortal entities.
But isn't a RIR, or IANA/ICANN then not directly monopolitic? They are the only ones you can get address space from "and ruled by the US" etc.
All those folks who question the right of ASses (AUTONOMOUS systems) to have their own IP space and a routing table slot (in lieu of a better, sufficiently!capable replacement architecture) for technical reasons ("but our routers will break!") should ask themselves one question: are YOU ready to return YOUR prefix(es) because you are NOT in the routing tier 1 club? If not, SHUT UP. Thanks. All but the real routing Tier 1s don't have any TECHNICAL need to announce their own allocations. All other non-upstream-free ISPs only have ECONOMIC reasons to do so. You
With a too large routing table (which are indeed far from there) for the currently deployed routers it will indeed be very economical as they need to be upgraded. But this does depend on landrush. Running out of 65k ASN's is the first thing that will happen. Though I wonder if some smaller routers still deployed at endsites will like to handle that. Economics, that is people who won't be able to update their routers, will then figure out who can have a slot there or not. RIR's fortunately do not guarantee routability, thus them giving out /48's from a single global /16 or so, to sites 'that desperately need them', allows people who don't want them to filter when table pressure become tight. Adding some geography in that big block might even allow one to at least carry the traffic to a 'local' IX to hand it off.
All those enterprises, non-commercial organizations and clubs who want/need PI aren't really represesented here.
Very simple answer: find them and let them speak up. Setup a union to represent them if you want etc. This is politics crap: if you don't raise your voice, don't complain that you are not heard. Same in real 'technical' places, which are usually downright political also and usually the big buck is what matters. Unfortunately that will always be the case, but that is the world of politics. Just ask around how many of your neighbors voted for Miss Merkel, does that match the national German votes? Not even asking who voted for Bush :) Greets, Jeroen (Who still thinks what I wrote up at http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2005/msg01269.... can work fine, then the economy, that is other ASN's will limit what they will accept at a certain point) (And who doesn't want his own "PI" space, I'll let other people take care of all, who can do it much better :)
On Wed, Dec 07, 2005 at 08:31:43AM +0100, Jeroen Massar wrote:
You have an AS and do multihome? Pay a small one-time fee (reg effort) and small annual fee (to verify that you still do exist care for the prefix to stay registered, and to cover costs for the database entries for your prefix) and be done with it.[1]
Note that the billing should then still be 'more' expensive than a LIR's individual allocation otherwise most LIR's will convert into independents which gives one more power over prefixes than the above.
Nonsense. PI doesn't let the LIR assign IP space to their customers. End site PI ain't an option for real LIRs. Then again, IPv6 PA allocations are extremely easy on NCC workload as the LIR doesn't have to get back to hostmasters for each assignment below the AW (which is 0 in the beginning). So perhaps the cost (score) for IPv6 PA allocations should be SIGNIFICANTLY lower than IPv4 PA allocations. Which would also mean that in relation there should be a XXXXS membership category for folks with only ASN and IPv6 PA alloc which fits the actual workload level... which is almost zero until this LIR comes back and asks for more than the initial no-questions-asked /32 allocation.
A LIR should know the procedures which should make requests very easy to process, at least that is the idea, which lowers load on the RIR's.
Should. Please come back with some hard data from NCC to explain to us that PI holders place a higher workload on NCC staff than any real LIR. Good luck.
Also, what is your equipment budget? At least 2 routers, 2 uplinks, man-power and a lot of other things. What is ~2K EUR then anyway?
You mean "you invested already, so throw some more money out the window, it doesn't hurt too much more"? Especially for non-commercial orgs routers can be donations too, e.g. because they got phased out.
All those folks who question the right of ASses (AUTONOMOUS systems) to have their own IP space and a routing table slot (in lieu of a better, sufficiently!capable replacement architecture) for technical reasons ("but our routers will break!") should ask themselves one question: are YOU ready to return YOUR prefix(es) because you are NOT in the routing tier 1 club? If not, SHUT UP. Thanks. All but the real routing Tier 1s don't have any TECHNICAL need to announce their own allocations. All other non-upstream-free ISPs only have ECONOMIC reasons to do so. You
With a too large routing table (which are indeed far from there) for the currently deployed routers it will indeed be very economical as they need to be upgraded. But this does depend on landrush. Running out of 65k ASN's is the first thing that will happen. Though I wonder if some smaller routers still deployed at endsites will like to handle that.
There is no need for that. Read again. Noone except the real Tier 1s have the _technical_ _necessity_ to run default-free. All others can filter as much as they want, and use default route(s) for all else.
Economics, that is people who won't be able to update their routers, will then figure out who can have a slot there or not.
No, they will start to default as they still need to access the content.
RIR's fortunately do not guarantee routability, thus them giving out /48's from a single global /16 or so, to sites 'that desperately need them', allows people who don't want them to filter when table pressure become tight. Adding some geography in that big block might even allow one to at least carry the traffic to a 'local' IX to hand it off.
Hand it off to whom? You need paid transit for that. That complicates things enormously. That's the whole can-of-worms related to geographic/ geopolitic addressing+routing. I won't delve into that here as it was discussed at length elsewhere. Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Daniel Roesen wrote:
On Wed, Dec 07, 2005 at 08:31:43AM +0100, Jeroen Massar wrote:
You have an AS and do multihome? Pay a small one-time fee (reg effort) and small annual fee (to verify that you still do exist care for the prefix to stay registered, and to cover costs for the database entries for your prefix) and be done with it.[1] Note that the billing should then still be 'more' expensive than a LIR's individual allocation otherwise most LIR's will convert into independents which gives one more power over prefixes than the above.
Nonsense. PI doesn't let the LIR assign IP space to their customers. End site PI ain't an option for real LIRs.
This is not what I meant. But why would endsite PI not be an option for 'real LIR's? What is a 'real LIR' actually according to you and what isn't? They all are in it for the money in the end. If their business is renting out "address space" (like the RIR's do effectively) then so be it, that is their business.
Then again, IPv6 PA allocations are extremely easy on NCC workload as the LIR doesn't have to get back to hostmasters for each assignment below the AW (which is 0 in the beginning). So perhaps the cost (score) for IPv6 PA allocations should be SIGNIFICANTLY lower than IPv4 PA allocations. Which would also mean that in relation there should be a XXXXS membership category for folks with only ASN and IPv6 PA alloc which fits the actual workload level... which is almost zero until this LIR comes back and asks for more than the initial no-questions-asked /32 allocation.
This is indeed what I meant with 'more expensive'. There are maybe some LIR's now though who don't want to be a LIR, but only did so to get address space. These might want to drop to the xxxxxs membership category to reduce cost at a certain point.
A LIR should know the procedures which should make requests very easy to process, at least that is the idea, which lowers load on the RIR's.
Should. Please come back with some hard data from NCC to explain to us that PI holders place a higher workload on NCC staff than any real LIR. Good luck.
There might not be one, but you can expect it to be this way. Maybe add a 'failed request' 'extra work' 'number of requests' etc to the scoring scheme to take care of this? One time requesters most likely don't know the policy, while LIR's do as they should be doing it way more often. Of course some independent contractor could do a lot of PI requests for independent organisations, but then that entity is sort of working like a LIR, but then differently.
Also, what is your equipment budget? At least 2 routers, 2 uplinks, man-power and a lot of other things. What is ~2K EUR then anyway?
You mean "you invested already, so throw some more money out the window, it doesn't hurt too much more"? Especially for non-commercial orgs routers can be donations too, e.g. because they got phased out.
Then let them donate a bit of money too. There seems to be a lot of 'free money' floating around on the web. Just for your enjoyment, getting $430 US to smash up a brand new Xbox 360 seems possible: http://www.lapblog.com/xbox-360-smash-up/151/ Getting 2k EUR for something you apparently desperately want, call critical and useful is not a problem then anymore I would assume.
All those folks who question the right of ASses (AUTONOMOUS systems) to have their own IP space and a routing table slot (in lieu of a better, sufficiently!capable replacement architecture) for technical reasons ("but our routers will break!") should ask themselves one question: are YOU ready to return YOUR prefix(es) because you are NOT in the routing tier 1 club? If not, SHUT UP. Thanks. All but the real routing Tier 1s don't have any TECHNICAL need to announce their own allocations. All other non-upstream-free ISPs only have ECONOMIC reasons to do so. You
With a too large routing table (which are indeed far from there) for the currently deployed routers it will indeed be very economical as they need to be upgraded. But this does depend on landrush. Running out of 65k ASN's is the first thing that will happen. Though I wonder if some smaller routers still deployed at endsites will like to handle that.
There is no need for that. Read again. Noone except the real Tier 1s have the _technical_ _necessity_ to run default-free. All others can filter as much as they want, and use default route(s) for all else.
I thought you needed PI because you wanted to do "traffic engineering", how are you going to do traffic engineering with the following in your tables: ::/0 fe80::2 eth0 ::/0 fe80::1 eth1 Or you only want "Inbound TE" ($world to you) and not "Outbound TE"? Some people might want to do it differently.
Economics, that is people who won't be able to update their routers, will then figure out who can have a slot there or not.
No, they will start to default as they still need to access the content.
Thus add extra prefixes to the routing tables, let everybody upgrade their routers, but don't do it yourself. Nice. Letting others pay for your dirt.
RIR's fortunately do not guarantee routability, thus them giving out /48's from a single global /16 or so, to sites 'that desperately need them', allows people who don't want them to filter when table pressure become tight. Adding some geography in that big block might even allow one to at least carry the traffic to a 'local' IX to hand it off.
Hand it off to whom? You need paid transit for that.
You want everything for free? :) I know the OCCAID folks are getting close to a global free transit network, but they also only arrive at IX's, your equipment still needs to be there to use those resources. People are not coming to you. But hey you know that very well :) Also note the 'might' in the above block of text, it is an idea for helping out the people who want things for free.
That complicates things enormously. That's the whole can-of-worms related to geographic/ geopolitic addressing+routing. I won't delve into that here as it was discussed at length elsewhere.
Oh don't worry, I don't see that working either. Too much politics. Greets, Jeroen PS: where are all those companies who are in desperate need for this?
On Wed, Dec 07, 2005 at 03:51:30PM +0100, Jeroen Massar wrote:
Daniel Roesen wrote:
On Wed, Dec 07, 2005 at 08:31:43AM +0100, Jeroen Massar wrote:
You have an AS and do multihome? Pay a small one-time fee (reg effort) and small annual fee (to verify that you still do exist care for the prefix to stay registered, and to cover costs for the database entries for your prefix) and be done with it.[1] Note that the billing should then still be 'more' expensive than a LIR's individual allocation otherwise most LIR's will convert into independents which gives one more power over prefixes than the above.
Nonsense. PI doesn't let the LIR assign IP space to their customers. End site PI ain't an option for real LIRs.
This is not what I meant. But why would endsite PI not be an option for 'real LIR's? What is a 'real LIR' actually according to you and what isn't?
A "real LIR" is a Local Internet Registry. A Local Internet Registery assigns resources they got allocated by a RIR to hand out to end users. As PI space isn't subassignable, PI is not an option for LIRs.
They all are in it for the money in the end. If their business is renting out "address space" (like the RIR's do effectively) then so be it, that is their business.
But we're talking about independent IP space for "end users", not for LIRs.
There are maybe some LIR's now though who don't want to be a LIR, but only did so to get address space. These might want to drop to the xxxxxs membership category to reduce cost at a certain point.
Yep. XXXXXS membership (not "LIR" - there's no registry operation involved) with a small basic fee for the essential one-off tasks of assigning and maintaining the records for an ASN, an IPv4 PI and an IPv6 PI block (read: a basic multihomer setup).
A LIR should know the procedures which should make requests very easy to process, at least that is the idea, which lowers load on the RIR's.
Should. Please come back with some hard data from NCC to explain to us that PI holders place a higher workload on NCC staff than any real LIR. Good luck.
There might not be one, but you can expect it to be this way.
Sorry, cannot believe that. I was hoping that NCC folks would chime in and add some statistics to this point.... any takers?
Maybe add a 'failed request' 'extra work' 'number of requests' etc to the scoring scheme to take care of this?
Difficult. Who decides what incidents are actually extra-billed?
One time requesters most likely don't know the policy, while LIR's do as they should be doing it way more often.
*cough*
Of course some independent contractor could do a lot of PI requests for independent organisations, but then that entity is sort of working like a LIR, but then differently.
I cannot follow this analogy, sorry. This contractor isn't responsible for the assigned resources in the future, but the receiving end user is. Unlike LIR PA space where the LIR is in charge.
All those folks who question the right of ASses (AUTONOMOUS systems) to have their own IP space and a routing table slot (in lieu of a better, sufficiently!capable replacement architecture) for technical reasons ("but our routers will break!") should ask themselves one question: are YOU ready to return YOUR prefix(es) because you are NOT in the routing tier 1 club? If not, SHUT UP. Thanks. All but the real routing Tier 1s don't have any TECHNICAL need to announce their own allocations. All other non-upstream-free ISPs only have ECONOMIC reasons to do so. You
With a too large routing table (which are indeed far from there) for the currently deployed routers it will indeed be very economical as they need to be upgraded. But this does depend on landrush. Running out of 65k ASN's is the first thing that will happen. Though I wonder if some smaller routers still deployed at endsites will like to handle that.
There is no need for that. Read again. Noone except the real Tier 1s have the _technical_ _necessity_ to run default-free. All others can filter as much as they want, and use default route(s) for all else.
I thought you needed PI because you wanted to do "traffic engineering", how are you going to do traffic engineering with the following in your tables:
::/0 fe80::2 eth0 ::/0 fe80::1 eth1
Or you only want "Inbound TE" ($world to you) and not "Outbound TE"?
I want to do both. Read again. You're in the camp denying all but ISPs the "right" to do BGP, because it's technically not necessary. Of course it isn't if you ignore all requirements put forward, but then it's also not necessary for the ISPs - except the real Tier 1s. Outbound TE is the easy part anyway, inbound TE is the tricky one. But I know that you understood BGP, so I'm not telling news here. :-)
Economics, that is people who won't be able to update their routers, will then figure out who can have a slot there or not.
No, they will start to default as they still need to access the content.
Thus add extra prefixes to the routing tables, let everybody upgrade their routers, but don't do it yourself. Nice. Letting others pay for your dirt.
Who are the others who NEED to upgrade? Only real Tier 1s. Only they NEED to have a "full table". All others can default to various degree, even to the extremes. Don't ignore that fact.
RIR's fortunately do not guarantee routability, thus them giving out /48's from a single global /16 or so, to sites 'that desperately need them', allows people who don't want them to filter when table pressure become tight. Adding some geography in that big block might even allow one to at least carry the traffic to a 'local' IX to hand it off.
Hand it off to whom? You need paid transit for that.
You want everything for free? :)
No, I just want costs that aren't artificially inflated costs in order to push some political/economical agenda put forward by an (at large) ISP lobby. Regarding your mentioned scenario: this kind of routing structure would definately need a complete redesign of how money flows in the global Internet, aligning more to the POTS interconnection fee model. That'll be bureaucracy unseen yet in the Internet, even with the most telcoish peering heavyweights.
I know the OCCAID folks are getting close to a global free transit network, but they also only arrive at IX's, your equipment still needs to be there to use those resources. People are not coming to you. But hey you know that very well :)
Uhm, I'm not OCCAID, I'm just a random invited technical advisor to them. I'm for sure not representing OCCAID in any fashion. How do you get to this connection?!? I didn't even think of them in this whole discussion.
That complicates things enormously. That's the whole can-of-worms related to geographic/ geopolitic addressing+routing. I won't delve into that here as it was discussed at length elsewhere.
Oh don't worry, I don't see that working either. Too much politics.
:-) I'm not sure wether we won't arrive there anyway. The current pretty much strictly tree-like money flow (with small artefacts like paid peering) will prolly have to adapt to a much more interconnected, meshed structure in the future... which will also allow things like geo-routing to have a chance of working at all.
PS: where are all those companies who are in desperate need for this?
Not here. And my POV is more the non-commercial organization. Those had a respected place in the Internet once and weren't seen as a "nuisance who don't want to spend VC money left and right". Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Hi Daniel, Daniel Roesen wrote: [...]
Yep. XXXXXS membership (not "LIR" - there's no registry operation involved) with a small basic fee for the essential one-off tasks of assigning and maintaining the records for an ASN, an IPv4 PI and an IPv6 PI block (read: a basic multihomer setup).
A LIR should know the procedures which should make requests very easy to process, at least that is the idea, which lowers load on the RIR's.
Should. Please come back with some hard data from NCC to explain to us that PI holders place a higher workload on NCC staff than any real LIR. Good luck.
There might not be one, but you can expect it to be this way.
Sorry, cannot believe that. I was hoping that NCC folks would chime in and add some statistics to this point.... any takers?
I'm not sure exactly which statistics you'd like us to provide. I've attached a graph showing the number of PI prefixes assigned over the last few years, plotted against the PA prefixes we allocated. However, as has been stated, outcomes are not the always a good measure of energy expended. For instance, the assignment window policy means LIRs with PA allocations often need to submit a number of requests for approval to make PA assignments. However, the workload in handling these requests has been reduced in the last couple of years by improved documentation, training and tools like the PA Wizard on the LIR Portal. If you would like a specific set of statistics then please let me know and we will do our best to provide them for you. Regards, -- leo vegoda RIPE NCC Registration Services Manager
Hi @all, first: thanks @Carlos for your response. I've read a lot of statements and position herein, some making sense to me, some hinting a way to go on and some simply sounding like 'ground-keeping'. I'd like to try to sum up the problems (real, possible future, self-made) and add a few thoughts myself. Currently there're ~35.000 AS'es handed out with ~180.000 prefixes carried in the v4 table. The v6 table houlds about 500-600 prefixes now. According RIPE-353 about 1/4 to 1/3 of the ASN handed out aren't seen in the forwarding paths. This leads to the first (and I think most urgent problem) taking a look at the rate ASN's a assigned nowadays. In rough numbers there're about 10.000 ASN not being visible in the routing table. And like someone else already mentioned in the 'multi-homing v6' discussion, how many of the newly handed out ASN are really required for multihoming ? I don't want to open a discussion about 'proper' way to multihome (again), but how many of the 'corporate' ASN handed out are really going to connect to more than one upstream provider ? (I know of LIR's operating their network with dual uplinks for the same upstream and a 'fake' secondary. Before someone starts shouting how to know: one of our aligned companies had been on of these.) During my years in ISP networking bussiness I've more than once come upon a network with fake entries and customers/potential customers multihoming to one upstream and asking for an ASN request with a second upstream being 1/50th to 1/10th of the primary bandwidth to satisfy requirements. These setups I'm almost sure don't need an ASN. And how about the non-visible ASN ? They may be hoarded, used for confed's after mergers & takeovers, a few for test networks (if reasonable argumented I agree here) or simply not returned to the pool after removal due to laziness. So first point to consider when talking 'needless' resources is: how to possibly limit the number of multihoming-ASN handed out to the ones really needed and how to move people to hand them back when no longer needed ? In case of PI space this is a bit more complicated. Adresses hasn't to be visible in the global routing tables to satisfy a need for globally unique adresses. Although in v4 world, RFC1918 & NAT are a fine thing to conserve address space, but forcing their use would be dictating others how to operate their network. This gets me to the assumption not every PI address space will get through to the routing tables. Surely PI space mostly not being aggregatable is filling up the tables with prefixes. But don't the de-aggregated PA's also do ? And what about invalid announcements (take a look to your table and search for ASN >=65512 !) ? What about the (IMHO) pollution of the table with nonsene of entries longer - let's say - /24 ? Did you ever take a look about your table in regard to prefix sizes ? There's a lot of /28 - /30 flowing around. At least for the /30 I think there're guys messing up their redist and BGP filters. Before we - the LIR admins - aren't able to agree on senseful filters and what's mess not to be announced (prefix length) and behave ourselves (de-aggregates) where's the right to discussing other peoples needs ? (just a comment: I've read someone here stating something like: do what you want, but not in my table. Hopefully there's no flaw to find in YOUR announcements ....) I've written in my previous (messy) post, but again: are we the ones entitled to decide how a customer has to run it's network and what he needs and what not ? Let me ask a simple question: how many of you do work directly in first line on your customers (in means of consulting your sales guys) ? Customers (especially corporate) nowadays are striving for redundant / multihomed connectivity and - the Level3/Cogent de-peer a few months ago showed this - how can you be 100% sure connectivity even by multiple links to one ISP won't take you offline ? There could be a serious network issue, a de-peer, the network could be blown by one of those nasty bot-nets etc. Many companies are moving ever more bussiness towards their internet access and therefore they reasonably ask for best connectivity possible (at reasonable cost). You can shake your head as furiously you like, but the primary target won't change: customer's demand. Did you always try to tell your boss that you wouldn't submit a PI or ASN request for a potential customer ? I bet you wouldn't do that often - maybe more than once, but you'd soon be looking for a job. Often a solution can be worked out together with the customer but not always. The customer will simply move on to another ISP willing to - at least try to - fulfil his wishes. PI space in v6 in demanded by customers the same way it is for v4. Either there'll be a way to satisfy this need or a solution to the multihoming dilemma with globally unique adresses SHORTLY or IPv6 can be dropped RIGHT NOW. This get's the second and third thing to consider: how do we get people to hand back no longer needed PI space and how will we handle IPv6 PI ? On side of the ISP's there're worries about size of the routing tables and the costs to replace your routers. But did you take a look at the growth rate of utilized bandwidth ? All these 'high-bandwidth' consumer links like DSL and such are driving bandwidth requirements up and up steadily. How long do you think your routers can keep with the traffic volume ? With number and bandwidth of consumer internet access increasing also the risk of floods and the basic 'trash' flowing around increases. On customers side there're worries about stablility and cost also, but maybe taken in another perspective. Corporate customers are willing (at least most of them) to pay more for a stable setup lowering (or at least pinning) their TCO. This includes not having to renumber regularly and/or being dependent on one ISP. But even if they are willing to pay more for true multihoming I'd like to hear how you sell them becoming a LIR themselves although they will never provide internet services to others but would have to care for a lot rules and administrative work in addition. PI as it's administrative nature is now is exactly what the want and need. So regardless where you put your eyes upon, it always comes back to money. So why not take (try) a simple approach. - get IPv6 (corporate-)ready by handing out PI space out of a well-known address space in chunks of /40 to /48 - limit the routing table size by agreeing on 'best practice' filters for prefix-length - limit the routing table size by bashing de-aggregators --- just kidding ... --- - limit routing table size and assigned resources by creating a motivation to hand resourced back. The last item is IMHO the crucial. RIPE-330 charging scheme states: Note: For AS Numbers and PI IPv4 allocations, only the allocations from the past 12 months dating back from the 30 September 2004 are taken into account as these resources are allocated or assigned on behalf of third parties. WHY ??? Let non-LIR's pay for their resources as well, but without requiring them to become a LIR. I'd propose something like: Add a new member category 'corporate' for those who don't provide internet services to others but are in need of resources and assign a charging scheme without any time variable. One-time: 500 EUR yearly: 250 EUR per ASN: 250 EUR (per year) per PI assignment: 150 EUR (per year) With at least 650 EUR a year people would think twice about their needs. In addition remove the ASN's for ISP's from this charging scheme and also charged fixed 250 EUR per ASN/year. This would hopefully push at least some people to hand back no longer used ASN or 'official' ASN used for confed's. regards, Marcus ---------------------------------------------------------- Tropolys Rhein-Main GmbH Network Engineering and Administration Fon: +49-(0)6131/129343 | Fax: +49-(0)6131/129321 Mombacher Str. 40, 55122 Mainz, Germany ---------------------------------------------------------- AS15837 | AS8638 | MG3031-RIPE ----------------------------------------------------------
A thought just crossed my mind: those of you striving to deny slots in the routing tables to non-LIRs, what do you think about splitting a PA and announcing parts out of different AS'es ? This isn't really a de-aggregate, serves the 'address conservation' constraint but is utilizing routing table space. Wasn't the 'sub-allocation' type intended for this and must have had some consensus to become implemented ? Maybe there should be added a PA allocation rule that each PA has to be announced only out of one AS. No ? We can't do this ? Why not ? Be splitting PA's this way the LIR create a address space type that can be moved along very similar to PI, just without being handed out directly to the customer. Would be an idea: I split one of our PA into /24's and lend them to enterprise customers free for announcement via their favourite ISP charging a yearly fee (obvisously the fee only for administering the RIPE data, as charging for addresses isn't allowed.). Marcus ---------------------------------------------------------- Tropolys Rhein-Main GmbH Network Engineering and Administration Fon: +49-(0)6131/129343 | Fax: +49-(0)6131/129321 Mombacher Str. 40, 55122 Mainz, Germany ---------------------------------------------------------- AS15837 | AS8638 | MG3031-RIPE ---------------------------------------------------------- ----- Original Message ----- From: "Marcus Gerdon" <marcus.gerdon@mainz-kom.de> To: <address-policy-wg@ripe.net> Sent: Wednesday, December 07, 2005 1:13 PM Subject: Re: [address-policy-wg] Re: Re: a consensus, about what?
Hi! As I can see, the main idea of these threads is large carriers trying to implement a kind of trust agreement policy (monopoly) that deny non-carriers (ideally small carriers too) to be the independent part of the Internet, but only their end-users. Like it is now in PSTN. If the community accept that, your though will be denied too. The main question is Internet is for carriers (' profit) or carriers is for Internet (community). What is the main thing?
A thought just crossed my mind:
those of you striving to deny slots in the routing tables to non-LIRs, what do you think about splitting a PA and announcing parts out of different AS'es ? This isn't really a de-aggregate, serves the 'address conservation' constraint but is utilizing routing table space. Wasn't the 'sub-allocation' type intended for this and must have had some consensus to become implemented ?
Maybe there should be added a PA allocation rule that each PA has to be announced only out of one AS.
No ? We can't do this ? Why not ? Be splitting PA's this way the LIR create a address space type that can be moved along very similar to PI, just without being handed out directly to the customer.
Would be an idea: I split one of our PA into /24's and lend them to enterprise customers free for announcement via their favourite ISP charging a yearly fee (obvisously the fee only for administering the RIPE data, as charging for addresses isn't allowed.).
Marcus
---------------------------------------------------------- Tropolys Rhein-Main GmbH
Network Engineering and Administration
Fon: +49-(0)6131/129343 | Fax: +49-(0)6131/129321 Mombacher Str. 40, 55122 Mainz, Germany ---------------------------------------------------------- AS15837 | AS8638 | MG3031-RIPE ----------------------------------------------------------
----- Original Message ----- From: "Marcus Gerdon" <marcus.gerdon@mainz-kom.de> To: <address-policy-wg@ripe.net> Sent: Wednesday, December 07, 2005 1:13 PM Subject: Re: [address-policy-wg] Re: Re: a consensus, about what?
-- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
Marcus Gerdon wrote:
A thought just crossed my mind:
those of you striving to deny slots in the routing tables to non-LIRs, what do you think about splitting a PA and announcing parts out of different AS'es ? This isn't really a de-aggregate, serves the 'address conservation' constraint but is utilizing routing table space. Wasn't the 'sub-allocation' type intended for this and must have had some consensus to become implemented ?
See my message about "De-aggregation of assigned IPv6 prefixes?" and Gert's response on it. ISP's are already doing this in IPv6. The only thing to 'stop' it is to have "most" ISP's filter those announcements. But even if you filter then the prefix is still reachable through the aggregate, thus connectivity isn't lost.
Maybe there should be added a PA allocation rule that each PA has to be announced only out of one AS.
This rule can be configured on your the router(s) in your network. It's called filters and that is up to you to configure or not.
No ? We can't do this ? Why not ? Be splitting PA's this way the LIR create a address space type that can be moved along very similar to PI, just without being handed out directly to the customer.
Cool huh :)
Would be an idea: I split one of our PA into /24's and lend them to enterprise customers free for announcement via their favourite ISP charging a yearly fee (obvisously the fee only for administering the RIPE data, as charging for addresses isn't allowed.).
You have a mostly valid business case here (IANAManager/Banker :) Instead of an end-site going to the RIRs for IP space, let them come to you, you being LIR. You as a LIR give them a /48 (or more) and say they can use their own ASN to announce it to their peers and transits. As long as those parties accept it they are fine. This also means you will have a plan for 200 potential customers :) The first side-effect is that your customers are (partially) dependent of you, you as LIR disappears, then they don't have squat. Then again if RIPE disappears, what then? :) Also they depend on you to carry the PA of their prefix in case their PI breaks, but they can see that as 'extra service. When their /48 gets filtered with normal PI they would not have anything at all, now their packets can still be delivered. Note also that there is no need for requirement that you as a LIR actually carry packets for them as long as their route is available. Good thing: LIR costs/members = low costs :) WARNING: Also note that there are a number of places where there is quite some strict filtering happening. This might result that your small /48 gets filtered out by fast/good "transits", but accepted by slow/bad "transits", thus causing you to be pretty unreachable over those ASN's. This has already been seen a couple of times in IPv6 routing tables! Greets, Jeroen
On Wed, Dec 07, 2005 at 03:12:02PM +0100, Jeroen Massar wrote:
ISP's are already doing this in IPv6. The only thing to 'stop' it is to have "most" ISP's filter those announcements. But even if you filter then the prefix is still reachable through the aggregate, thus connectivity isn't lost.
Wrong. It's lost if your link to the aggregate provider is down at that time, or this network having BGP/IGP problems. The more-specific multihoming idea works only if noone filters, and then you lose the only advantage that scheme has: the ability to filter. Doesn't work, next try... ;)
Instead of an end-site going to the RIRs for IP space, let them come to you, you being LIR. You as a LIR give them a /48 (or more) and say they can use their own ASN to announce it to their peers and transits. As long as those parties accept it they are fine. This also means you will have a plan for 200 potential customers :) The first side-effect is that your customers are (partially) dependent of you, you as LIR disappears, then they don't have squat.
Not only then, but also for things like IRR and DNS reverse delegations. Again, only a half-solution.
Then again if RIPE disappears, what then? :)
Then we have other problems, as has each and every LIR.
WARNING: Also note that there are a number of places where there is quite some strict filtering happening. This might result that your small /48 gets filtered out by fast/good "transits", but accepted by slow/bad "transits", thus causing you to be pretty unreachable over those ASN's.
Luckily this situation is actually changing, and the good networks nowadays tend to ACCEPT /48s and the bad networks still try to keep some weird classful filtering concepts alive. Not the prefix length makes an announcement valid or not... the prefix length can only be some kind of heuristic for that. In IPv4 /24 is the common stop-gap for IBGP leaks, for IPv6 it should be /48.
This has already been seen a couple of times in IPv6 routing tables!
Yep, but times are a-a-changing. :-) Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Daniel Roesen wrote:
On Wed, Dec 07, 2005 at 03:12:02PM +0100, Jeroen Massar wrote:
ISP's are already doing this in IPv6. The only thing to 'stop' it is to have "most" ISP's filter those announcements. But even if you filter then the prefix is still reachable through the aggregate, thus connectivity isn't lost.
Wrong. It's lost if your link to the aggregate provider is down at that time, or this network having BGP/IGP problems.
Why would that impact your connectivity when you are properly announcing your prefix? Except of course when there are ISP's that filter your prefix out. But hey that is their choice. They can also filter out a /32 if they like to do that. Their network. You can ask them to not do it. Or we can have a single block that contains all these prefixes so that they basically have to do it. Isn't the idea of having a more specific prefix that you actually make sure that your more-specific prefix actually get announced properly. If you have a IPv4 /24 and you cut it up in /28's and start announcing those at the moment, isn't it then your own responsibility to make sure those /28's actually get propagated properly? Indeed this requires asking people to lift their filters. This is the same as for IPv6 with /48's. As long as your more-specific /48 is correctly in the routing tables you get reached over those. When it is not, well you are not.
The more-specific multihoming idea works only if noone filters, and then you lose the only advantage that scheme has: the ability to filter.
It also works when there is a clear defined block that is used for this purpose so that ISP's can filter less strictly for that block.
Doesn't work, next try... ;)
Indeed doesn't work for folks who don't want to read and can only complain but can't come up with their own solutions or think along.
Instead of an end-site going to the RIRs for IP space, let them come to you, you being LIR. You as a LIR give them a /48 (or more) and say they can use their own ASN to announce it to their peers and transits. As long as those parties accept it they are fine. This also means you will have a plan for 200 potential customers :) The first side-effect is that your customers are (partially) dependent of you, you as LIR disappears, then they don't have squat.
Not only then, but also for things like IRR and DNS reverse delegations.
Again, only a half-solution.
What is the difference of going to "Organisation X", who are a LIR, or "Organisation Y", who are a RIR ?
Then again if RIPE disappears, what then? :)
Then we have other problems, as has each and every LIR.
What is the difference of a RIR disappearing with whom you do business or a LIR with whom you do business?
What is a 'real LIR' actually according to you and whatisn't?
A "real LIR" is a Local Internet Registry. A Local Internet Registery assigns resources they got allocated by a RIR to hand out to end users. As PI space isn't subassignable, PI is not an option for LIRs.
If you haven't noticed, current LIR's get an IPv6 PA prefix. You are trying to get address space for an end-site (you don't subassign, if you did you could become a LIR, okay at 200 customers). Thus my suggestion is that you can go to a LIR and get a part of their PA prefix and announce that. Simple.
They all are in it for the money in the end. If their business is renting out "address space" (like the RIR's do effectively) then so be it, that is their business.
But we're talking about independent IP space for "end users", not for LIRs.
Apparently my description of what I meant was too difficult to understand, thus I'll try to make it more clear: *) IANA has all the address space *) RIR's get address space from IANA *) LIR's get address space from RIR's *) end-sites get address space from LIR's Thus a LIR has a PA prefix. This LIR acts as a "PI provider for ISP's". Then an endsite comes to them (eg you) and asks for a /48. LIR gives you a /48, you announce that /48 as it being PI. You make sure that you announce that prefix properly, maintain multiple links and generally don't care about the PA prefix that is getting announced. The LIR might not even announce the PA prefix. The only reason left for having a link to the LIR would be because some people filter out the more specifics. Indeed the "PI prefix" is not registered as such at the RIR's, but you can still insert route6 objects in the RIR's db (if they support that :) and you can route it. WOW surprise: this is already being done today! PS: see Gert's anwer to my very related question and then wonder why I asked it in the first place: http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2005/msg01272.... </repeat for x'th time> [..]
Of course some independent contractor could do a lot of PI requests for independent organisations, but then that entity is sort of working like a LIR, but then differently.
I cannot follow this analogy, sorry. This contractor isn't responsible for the assigned resources in the future, but the receiving end user is. Unlike LIR PA space where the LIR is in charge.
The employees at a LIR never change jobs/functions/roles? LIR's don't sometimes actually hire a contractor to do their work? The contractor also knows how to fill in the paperwork. As you didn't notice the above was in defense for non-LIR's doing requests. [..]
I thought you needed PI because you wanted to do "traffic engineering", how are you going to do traffic engineering with the following in your tables:
::/0 fe80::2 eth0 ::/0 fe80::1 eth1
Or you only want "Inbound TE" ($world to you) and not "Outbound TE"?
I want to do both. Read again.
You only claimed to be wanting to do "Traffic Engineering", never stated what kind of direction.
You're in the camp denying all but ISPs the "right" to do BGP, because it's technically not necessary.
Currently it is technically necessary, as there is no alternative. Which is why I suggest a big block where these "endsite PI" assignments can come from, or a special LIR which handles these blocks. So that in the future we can see 'those blocks are actually "endsite PI"' and let them solve their problems with the new technologies that have risen. Note that the 'camp' I am in is my very own little private club where I am the sole member and nobody else can join. There is nobody giving me any money for this stuff either.
Of course it isn't if you ignore all requirements put forward, but then it's also not necessary for the ISPs - except the real Tier 1s.
If you would actually *read* what I am writing, summed up for the xth time again above, maybe I need to add pictures or something; I have already suggested a number of times that ISP's should be able to get a /48 or whatever prefix from either a LIR or directly from the RIR's so that they can announce it into BGP, just like that is already currently happening...
Outbound TE is the easy part anyway, inbound TE is the tricky one. But I know that you understood BGP, so I'm not telling news here. :-)
Economics, that is people who won't be able to update their routers, will then figure out who can have a slot there or not. No, they will start to default as they still need to access the content. Thus add extra prefixes to the routing tables, let everybody upgrade their routers, but don't do it yourself. Nice. Letting others pay for your dirt.
Who are the others who NEED to upgrade? Only real Tier 1s. Only they NEED to have a "full table". All others can default to various degree, even to the extremes. Don't ignore that fact.
If you don't have a full table, you can't do much Traffic Engineering either. Or are you going to say "2003::/16 is europe that goes over Transit X" ? Then you should not have a problem with a chunk of space from a PA provider either.
RIR's fortunately do not guarantee routability, thus them giving out /48's from a single global /16 or so, to sites 'that desperately need them', allows people who don't want them to filter when table pressure become tight. Adding some geography in that big block might even allow one to at least carry the traffic to a 'local' IX to hand it off. Hand it off to whom? You need paid transit for that. You want everything for free? :)
No, I just want costs that aren't artificially inflated costs in order to push some political/economical agenda put forward by an (at large) ISP lobby.
The only lobby gaining money with this are Vendor X, Y and Z they need to build the bigger iron, not the ISP's nor the Tier1's or any other of those folks who pay those vendors...
Regarding your mentioned scenario: this kind of routing structure would definately need a complete redesign of how money flows in the global Internet, aligning more to the POTS interconnection fee model. That'll be bureaucracy unseen yet in the Internet, even with the most telcoish peering heavyweights.
There is a relatively simple charging scheme: x EUR or US$ per Gigabytes Of course you can add a wild variety of special cases like "US traffic", "Asian Traffic" etc. But this all has nothing to do with address policy, that is financial politics which you need to take care of with your upstreams.
I know the OCCAID folks are getting close to a global free transit network, but they also only arrive at IX's, your equipment still needs to be there to use those resources. People are not coming to you. But hey you know that very well :)
Uhm, I'm not OCCAID,
That was not the reason I mentioned them. The reason I mentioned it was because it demonstrates that you as an endsite still need to get a link to the IX's or some other place where to interconnect with some transit providers. These links and equipment still costs money. [..]
PS: where are all those companies who are in desperate need for this?
Not here. And my POV is more the non-commercial organization. Those had a respected place in the Internet once and weren't seen as a "nuisance who don't want to spend VC money left and right".
If they are not here, and this is the place where policies are made they apparently don't give much about all of this. If they don't know about this list: invite them. If they don't care: then there is no problem. Greets, Jeroen
This leads to the first (and I think most urgent problem) taking a look at the rate ASN's a assigned nowadays. In rough numbers there're about 10.000 ASN not being visible in the routing table. And like someone else already mentioned in the 'multi-homing v6' discussion, how many of the newly handed out ASN are really required for multihoming ?
There are a thousand ways in which an ASN used for multihoming between two upstreams will fail to appear in RIS or routeviews. If anybody is really serious about figuring out what is going on, then they will do a REAL research project using telephone and email to contact the human beings who know the facts behind the use of these ASNs. No doubt some of those human beings will confirm that an ASN is no longer in use, but many others will point out how their ASN is in use even if it is invisible to crude 3rd party probing technology.
During my years in ISP networking bussiness I've more than once come upon a network with fake entries and customers/potential customers multihoming to one upstream and asking for an ASN request with a second upstream being 1/50th to 1/10th of the primary bandwidth to satisfy requirements.
Sounds to me like a live circuit plus a failover circuit. Some people call this good engineering.
These setups I'm almost sure don't need an ASN.
If they were engineered to use BGP then they definitely do NEED an ASN. If you are saying that they should be engineered differently, then I have to ask you to move your discussion to RIPE's "ISP Engineering rules" working group because you have gone beyond IP addressing policy.
So first point to consider when talking 'needless' resources is: how to possibly limit the number of multihoming-ASN handed out to the ones really needed and how to move people to hand them back when no longer needed ?
No, actually the first point to consider is whether or not recovering every last "missing" ASN will solve the ASN shortage problem. People did consider this and the answer was NO. Therefore, the focus has been on making longer ASNs rather than recovering the few missing ones.
Although in v4 world, RFC1918 & NAT are a fine thing to conserve address space, but forcing their use would be dictating others how to operate their network.
I suppose that you don't believe in dictating how people should operate their networks? What about how people should engineer their networks? --Michael Dillon
Hi, Gert Doering wrote:
Hi,
On Mon, Dec 05, 2005 at 06:27:24PM +0100, Daniel Roesen wrote:
Those kind of ideas can only come from folks who are already in the business and have their own allocation already. *shaking head*
Unlike some other participants on this list, I'm actually aiming for something that could reach consensus.
Otherwise, all this is wasted time, and we could directly go to ITU and ask them to fix the Internet.
yes, please, fix the internet. I'd say we elect an Internet king which gives out all the rules! Worked for some hundret years. ...joke aside. The problem with consensus is, that it won't be reached with discussions, because in the internet world there is no "tie-breaker" who will finally make the descision about the outcome of the discussion ("no king"). The only way is to post some detailed policy suggestions and have some kind of voting about it, either in public (e.g. usenet-wise) or on RIPE/RIR level. That will give you at least some more exact numbers on the majority for or against a certain suggestion. I can't really tell about what's the most favoured policy for IPv6 Allocations and PI Address Assignments at the moment. It's not nescessarily the policy favoured by the ones who bark the loudest during the discussions. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ========================================================================
Hi, On Tue, Dec 06, 2005 at 11:09:12AM +0100, Sascha Lenz wrote:
The only way is to post some detailed policy suggestions and have some kind of voting about it, either in public (e.g. usenet-wise) or on RIPE/RIR level.
OK, so now we need to find consensus on how we want to do voting. - does every LIR get one vote (I hear Daniel Roesen yelling)? - does every person on the Internet get one vote? - How do you prevent abuse due to "ok, all employees of $big_carrier vote X" (by coprorate order)? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
Hi, Gert Doering wrote:
Hi,
On Tue, Dec 06, 2005 at 11:09:12AM +0100, Sascha Lenz wrote:
The only way is to post some detailed policy suggestions and have some kind of voting about it, either in public (e.g. usenet-wise) or on RIPE/RIR level.
OK, so now we need to find consensus on how we want to do voting.
. o O(...)
- does every LIR get one vote (I hear Daniel Roesen yelling)?
- does every person on the Internet get one vote?
- How do you prevent abuse due to "ok, all employees of $big_carrier vote X" (by coprorate order)?
actually, it's a RIR Policy. So it would be quite quite logical to follow the RIR policy process and only let RIR-members ("LIR" or whatever it's called outside RIPE) vote. Don't really know if Daniel would yell on that. But actually that's what i was thinking about (we're exclusively on RIPE WG Mailinglists here anyways). Don't know why i added the "in public" part in first place. No real reason. It would be stupid to think about a "at large" vote on that issue, ICANN failed trying to establish such things :-) -- ======================================================================== = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ========================================================================
Hi Sascha, On 12/6/05, Sascha Lenz <slz@baycix.de> wrote:
actually, it's a RIR Policy. So it would be quite quite logical to follow the RIR policy process and only let RIR-members ("LIR" or whatever it's called outside RIPE) vote.
LIRs in the RIPE region vote only on RIPE NCC activities/budget/association stuff. The Policy Development Process is open to all. This is true in other regions as well. But actually that's what i was thinking about (we're exclusively on RIPE
WG Mailinglists here anyways).
I am not an LIR, and I can play in this sandbox! BTW, I live in Africa now, (that's why you don't see me @ meetings anymore), but I can still participate on the lists. -- Cheers, McTim $ whois -h whois.afrinic.net mctim
Hi, On Tue, Dec 06, 2005 at 12:09:59PM +0100, Sascha Lenz wrote:
- does every LIR get one vote (I hear Daniel Roesen yelling)?
- does every person on the Internet get one vote?
- How do you prevent abuse due to "ok, all employees of $big_carrier vote X" (by coprorate order)?
actually, it's a RIR Policy. So it would be quite quite logical to follow the RIR policy process and only let RIR-members ("LIR" or whatever it's called outside RIPE) vote.
Don't really know if Daniel would yell on that.
Sure, because it's "the ISP monopoly deciding things that hurt all the poor end users". Also, in the RIPE land, it has *never* been the way that "only LIRs decide" - to the contrary, all RIPE processes are open to anyone to come to meetings (or subscribe to mailing lists) and enter discussions.
But actually that's what i was thinking about (we're exclusively on RIPE WG Mailinglists here anyways). Don't know why i added the "in public" part in first place. No real reason. It would be stupid to think about a "at large" vote on that issue, ICANN failed trying to establish such things :-)
Doing it in a non-open way would directly play into ITUs hands. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
Gert Doering wrote:
Hi,
On Mon, Dec 05, 2005 at 02:17:25PM +0100, Kurt Erik Lindqvist wrote:
I think each LIR should get a /32 and we should drop the 200 "customer" rule. But that is just me...
Actually I like the "every AS should get a <network>" approach (with a yearly recurring fee for AS and network, to guarantee return of the resources as soon as the importance of having a slot in the global routing table doesn't outweigh the costs anymore).
"Every LIR gets a /32 (upon request), no questions asked" is a concept that I'm also happy with - as I have said before. For those that are afraid of the landrush: limit that policy to 5.000 LIRs per region.
You can't use this kind of arbitrary limit. Doing it this way is seriously hot water in terms of anti-trust law. In general some of the discussed (and the current) IPv6 policy has troublesome aspects from an EU anti-trust point of view. To be on the safe side all policy must be on pure technical, equality and justifyable terms. RIPE NCC and its membership system may be deemed to be an illegal monopoly under certain circumstances if equality rules are not strictly followed and requests for membership are treated selectively. Also the current IPv6 policy that only ISPs can get independently routeable address space is a fine line into anti-competitive behaviour which may be illegal according to EU anti-trust law. I think is very important that RIPE NCC conducts a legal assertion through some EU anti-trust specialized law firm to assert the problematic aspects of any current and future IPv6 policy or policy proposal. With IPv4 there are no anti-trust problems because everyone may get any justifyable amount of address space. AS numbers are equally available too and only bound on the actual use of them. All this is deemed fair under EU anti-trust law. -- Andre
Hi, On Mon, Dec 05, 2005 at 06:34:50PM +0100, Andre Oppermann wrote:
"Every LIR gets a /32 (upon request), no questions asked" is a concept that I'm also happy with - as I have said before. For those that are afraid of the landrush: limit that policy to 5.000 LIRs per region.
You can't use this kind of arbitrary limit. Doing it this way is seriously hot water in terms of anti-trust law.
It depends on how you handle it. My line of reasoning is "we don't have enough experience to judge how things will evolve, but there are some serious doubts on whether we can handle unreasonably large number of BGP routes - so we put a limit in there, and then reconsider in a few years whether our strategy is useful or not". I don't really expect the "5000" number to be a serious issue - but if it turns out to be, policy needs changing, of course. In whatever direction. [..]
Also the current IPv6 policy that only ISPs can get independently routeable address space is a fine line into anti-competitive behaviour which may be illegal according to EU anti-trust law.
As nobody is preventing you from becoming an ISP, this line of argument is completly cr**. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
On Tue, Dec 06, 2005 at 09:31:53AM +0100, Gert Doering wrote:
[..]
Also the current IPv6 policy that only ISPs can get independently routeable address space is a fine line into anti-competitive behaviour which may be illegal according to EU anti-trust law.
As nobody is preventing you from becoming an ISP, this line of argument is completly cr**.
That's true. It didn't take much effort, and 'only' maybe 1,500 Euros p.a. for our site to in effect become an LIR. I guess for some people the fee is an issue, but the old argument is if PI is that important to you as a corporate organisation, that money is small change. So who exactly are these people calling for their IPv4 equivalent PI space? Are they all corporate enterprise networks? If not, who represents the other major consumers? And how many PI prefixes are in use today for IPv4? 10,000? 30,000? More? -- Tim/::1
On Mon, Dec 05, 2005 at 06:34:50PM +0100, Andre Oppermann wrote:
Also the current IPv6 policy that only ISPs can get independently routeable address space is a fine line into anti-competitive behaviour which may be illegal according to EU anti-trust law.
Not only that, the billing scheme too. Every year it becomes more expensive to receive resources. See the time factor in the score algo. Given that this scheme is not a community-based decision, but a membership decision, this may (or may not, IANAL) subject to anti-trust laws as well. I think that RIPE needs a means to poll for votes in the RIPE region in an open manner, and base policy decisions on the outcome of those, not on the opinions of a few vocal folks who have the time and money to invest in mailing lists and RIPE meetings to bring forward their agenda, with someone then concluding "rough consensus" (or not). At least on a membership level that should be easy to achieve. Mail policy proposals to LIR contacts and ask to vote. Without having to read hundreds of mailing list postings and voicing opinions there. Of course the current policy discussion does affect members (LIRs) the least - they do already have their addresses (most of them), so asking only the membership to vote would be again the wrong thing to do. Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
On 1 dec 2005, at 11.37, Per Heldal wrote:
user TE capability. It does not give the ISP the possibility to ignore it, as they could today.
Shim6 is work in progress and may be used as an argument to adjust adress-assignment policies sometime in the future. If we want ipv6 deployed today we have to provide a mechanism to support requirements about redundancy and independence from individual providers.
Ok, that I agree with. - kurtis -
If you have alternative ideas you know how it works - send text.
draft-ietf-ipngwg-gseaddr-00.txt same one the ietf has ignored and lied about for eight years now randy
At 10:01 PM 1/12/2005, Randy Bush wrote:
If you have alternative ideas you know how it works - send text.
draft-ietf-ipngwg-gseaddr-00.txt
same one the ietf has ignored and lied about for eight years now
I was not directly involved here, so when I looked into this a little, then I found the document draft-ietf-ipngwg-esd-analysis-05.txt was the ultimate version of a draft responding to the GSE approach. The observation that neither the GSE document, nor this response, ever made it past drafts could be an indicator that there may be more to this story than can be found in the IETF drafts from the period 1997 - 2000. I certainly found it interesting to review these two documents side by side, and others who may also be wondering what happened to GSE may find it useful to read the ESD analysis Geoff
I was not directly involved here, so when I looked into this a little, then I found the document draft-ietf-ipngwg-esd-analysis-05.txt was the ultimate version of a draft responding to the GSE approach. The observation that neither the GSE document, nor this response, ever made it past drafts could be an indicator that there may be more to this story than can be found in the IETF drafts from the period 1997 - 2000. I certainly found it interesting to review these two documents side by side, and others who may also be wondering what happened to GSE may find it useful to read the ESD analysis
and that was the lie. in fact, the gse proposal was not reviewed for security and found wanting. many of the authors of the second document have since recanted. you also may want to read http://www.cs.columbia.edu/~smb/papers/esd-secure.txt randy
I might totaly missunderstand you, but I get the feeling you want us to go back to the root of the IPv6 discussion when it all was started and use some of the stuff that was done before instead of trying to figure it all out again? On Thu, 1 Dec 2005, Randy Bush wrote:
and that was the lie. in fact, the gse proposal was not reviewed for security and found wanting. many of the authors of the second document have since recanted.
you also may want to read
-- ------------------------------ Roger Jorgensen | rogerj@stud.cs.uit.no | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no -------------------------------------------------------
On 1 dec 2005, at 12.01, Randy Bush wrote:
If you have alternative ideas you know how it works - send text.
draft-ietf-ipngwg-gseaddr-00.txt
same one the ietf has ignored and lied about for eight years now
I am looking forward to the BOF....:-) - kurtis -
On Thu, Dec 01, 2005 at 09:11:48AM +0100, Kurt Erik Lindqvist wrote:
ISPs do exist for customers, not customers do exist to feed ISPs in the most convenient way for the ISPs. Some folks seem to forget that, looking at all the discussion trying to ignore the demand for real multihoming (and that includes TE and network-wide routing policy implementation, neither being delivered by things like shim6).
I think you are contradicting yourself here. Shim6 does give the end- user TE capability.
It doesn't. Unless I'm missing on how I can influence e.g. inbound routing like I can do with BGP announcements, tagged with special communities to tweak announcement properties (yes/no, prepending etc.) and things like routing preference ("local-pref" in BGP semantics) in my upstream's network or even more far reaching than that. I cannot. And as far as I hear, folks at NANOG (IESG BoF on IPv6 multihoming) have clearly laid out why shim6 is NOT what we're looking for - and why. [this is hearsay, I didn't get around to check minutes and/or slides yet]
I am not sure what you mean with "network-wide routing policy implementation"....
As a network administrator I want to define routing properties for my whole network in a consistent way, not to tweak each policy decision in each IPv6 stack on each host. The routing policy of a network is a network property, not a host property. I don't want to HAVE to control (read: administer!) each and every end device on the network just to provide proper global routing to it. That's just ridiculous.
I have still to figure out what the "real multihoming" thing is,
That's the basic problem. The IETF folks either don't understand, or chose to ignore the requirements. There is a nice 6NET document detailing all requirements and showing a matrix outlining requirements against proposed solutions. Outcome: NONE except BGP offer a solution to ALL requirements. I'm happy to look into any solution proposed that fulfils the needs. Unfortunately that's not there yet. I'm sure we all would be happy to get rid of the latent possible danger of BGP.
HOW the requirements are being delivered is another topic. multi6 has resulted in the decision to ignore many critical requirements. We're just asking for something that delivers on the targets. Wasting time with half-solutions is not productive. Halting any development because the magic bullet wasn't found yet ain't either.
If you have alternative ideas you know how it works - send text.
I don't, as stated. Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
* Roger Jorgensen:
The absolute max global routing table would by this be 40bits, of course the real one are alot smaller. That one is closer to 32bits, and that is STILL A huge number, probably more close to 20bits of entries.
Only 20 bits? IPv4 already has more than 17 bits of entries. I still don't see the problem. To the contrary, your numbers suggest that IPv6 is very similar to IPv4 in this regard.
On Mon, 21 Nov 2005 17:10:10 +0100 (CET), Roger Jorgensen wrote:
Can't we all just drop using the word multihoming and IPv6 PI?
The better solution is the enemy of the good solution. If IPv4 offers PI = provider _independence_ and multihoming and IPv6 doesn't, then IPv4 is obviously the better solution for those who requires this functionallity. Thus they won't use IPv6. Please keep in mind: The _customer_ votes, not you, not me. And as the majority of the large and a significant portion of medium size businesses are obviously not willing to accept an IP protocol not providing this functionallity, IPv6 will remain at it's current status: A technical playground for technically interested people.
They all reflect back to how thing was done with IPv4 and those ways are doomed to fail with IPv6 simply due to the size of the IP space.
Could you please explain this a bit more in detail ? To me this sounds like "engines will never fly".
Last I checked around there were some promissing new proposal on the way for how to solve this very basic problem.
Could you please be a bit more verbose.
And in the meantime, drop the thought about multihoming and PI space, start to think about other ways to use the possibility IPv6 give us.
Hmm, please let me translate: "Even if the car doesn't drive and the engine doesn't deliver a single horse power at the wheels, drop the thought about driving, start to think about other way to use the possibility this great car gives us." Sound like newspeak: If we _think_ we can't solve the problem, drop discussing the problem. Best Regards Oliver Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver@bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0
Sorry for cross-posting but not sure where it really belong... ----------- Hi, First, the question is more, what is the correct way of dealing with situation like this? I work for a entity with a big and closed network where security and being closed came first. We're not governement but we have our mandate defined by them. Our only connection to Internet are through several uplinks with few public IP where we run proxy solution for the little traffic that are allowed to hit internet. Are in reality no incoming routes to us, and none out. Internal we use RFC1918 IP space,(private IP) and we for now have enough IP space but we are experience conflicts between IP space when connecting to other big closed network. Not to forget the size, we will probably run out of IP space to... (and I know others have run out of RFC1918 space on their internal network) Most would suggest request a /48 or bigger from your uplink right now and that's not going to work for several reasons: * size, just one of bigger sites connected probably need more than a /48 just for themself, and we have several of them, and alot of smaller sites/network. We're probably talking /32 or more if I have to guess. * scalability, we could of course get /48 and break the /64 boundary, a thought I seriously hate. But that will give us other kind of problems, sites needing a /64 or more due to some equipment or so... * there are other BIGGER network of the same type. * control over who is using what IP and where etc... as said above, security and being closed are probably the two most important factors for us. * need global unique IP's since we're connecting to other network of the same type, and NAT are not really the way we want to go with IPv6 ... and probably more I can't remember right now. The solutions aren't really that tricky but let me mention a few options... * Site local would have solved our problem BUT it's obsolite, quite stupid really. * just take a prefix and use it... this will give us problem in the future due to not being unique. * extensiv usage of NAT, eh do we really want to even consider THAT for IPv6? * become LIR and request the needed IP space. * let one of our uplinks request the IP space for us. I'm in favour of the last two options, any of them... and they are as I see it the really two options as things are now. Any thoughts? comments? -- ------------------------------ Roger Jorgensen | rogerj@stud.cs.uit.no | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no -------------------------------------------------------
Hi, On Fri, Nov 25, 2005 at 10:12:35AM +0100, Roger Jorgensen wrote:
The solutions aren't really that tricky but let me mention a few options... * Site local would have solved our problem BUT it's obsolite, quite stupid really.
That's why there are ULA ("unique local addresses") now. They should fit your needs pretty well - as much addresses as you want, and the guarantee to be not officially assigned to anyone. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
On Fri, 25 Nov 2005, Gert Doering wrote:
Hi,
On Fri, Nov 25, 2005 at 10:12:35AM +0100, Roger Jorgensen wrote:
The solutions aren't really that tricky but let me mention a few options... * Site local would have solved our problem BUT it's obsolite, quite stupid really.
That's why there are ULA ("unique local addresses") now. They should fit your needs pretty well - as much addresses as you want, and the guarantee to be not officially assigned to anyone.
what about the other part about globaly unique when we connect to other network of the same type? -- ------------------------------ Roger Jorgensen | rogerj@stud.cs.uit.no | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no -------------------------------------------------------
Hi, On Fri, Nov 25, 2005 at 11:25:07AM +0100, Roger Jorgensen wrote:
On Fri, Nov 25, 2005 at 10:12:35AM +0100, Roger Jorgensen wrote:
The solutions aren't really that tricky but let me mention a few options... * Site local would have solved our problem BUT it's obsolite, quite stupid really.
That's why there are ULA ("unique local addresses") now. They should fit your needs pretty well - as much addresses as you want, and the guarantee to be not officially assigned to anyone.
what about the other part about globaly unique when we connect to other network of the same type?
The idea is that ULAs are random-generated in a way that makes it "fairly unlikely" that you end up in an address collision. But there is no guarantee, of course. There is also a second sort of ULAs that are globally unique but still private, but as far as I know, there is no registry yet that will hand them out. So these can't be used yet. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
At 09:38 PM 25/11/2005, Gert Doering wrote:
Hi,
On Fri, Nov 25, 2005 at 11:25:07AM +0100, Roger Jorgensen wrote:
On Fri, Nov 25, 2005 at 10:12:35AM +0100, Roger Jorgensen wrote:
The solutions aren't really that tricky but let me mention a few options... * Site local would have solved our problem BUT it's obsolite, quite stupid really.
That's why there are ULA ("unique local addresses") now. They should fit your needs pretty well - as much addresses as you want, and the guarantee to be not officially assigned to anyone.
what about the other part about globaly unique when we connect to other network of the same type?
The idea is that ULAs are random-generated in a way that makes it "fairly unlikely" that you end up in an address collision. But there is no guarantee, of course.
There is also a second sort of ULAs that are globally unique but still private, but as far as I know, there is no registry yet that will hand them out. So these can't be used yet.
This is an area that has not gone completely dormant. The "unlikeliness" that Gert refers to is the classic birthday problem, and the probability that 2 parties have chosen the same number rises above 0.5 once the candidate population exceeds 1.24 million. So some form of central or coordinated registry action is necessary to ensure that there are no collisions in these numbers. At APNIC we've been looking at how such a system could be supported. Geoff
On Fri, 25 Nov 2005, Gert Doering wrote: <snip>
The idea is that ULAs are random-generated in a way that makes it "fairly unlikely" that you end up in an address collision. But there is no guarantee, of course.
There is also a second sort of ULAs that are globally unique but still private, but as far as I know, there is no registry yet that will hand them out. So these can't be used yet.
Who would know more about this? I'm in the process of writing down some startup thoughts about how we can (and maybe should) implement IPv6 here where I work. It's a closed national network where security is prio 1 and we might also have to work/connect to other network of the same type in other countries... in short, we need to be globaly unique so we actually need that registrary to be there:) -- ------------------------------ Roger Jorgensen | rogerj@stud.cs.uit.no | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no -------------------------------------------------------
Hi, On Fri, Dec 23, 2005 at 12:03:06PM +0100, Roger Jorgensen wrote:
[ globally unique ULAs ] Who would know more about this?
Geoff Houston mentioned that APNIC is researching this topic. As for implementing it, the NRO/RIR structure sounds like a logical candidate for me. They just need to make sure that it's adequately lightweight so people won't need to pay thousands of Euro/Dollars to get a ULA prefix. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
At 10:03 PM 23/12/2005, Roger Jorgensen wrote:
On Fri, 25 Nov 2005, Gert Doering wrote: <snip>
The idea is that ULAs are random-generated in a way that makes it "fairly unlikely" that you end up in an address collision. But there is no guarantee, of course.
indeed. The chances of collision exceed 0.5 once the pool of random;y drawn numbers exceeds 1.24 million.
There is also a second sort of ULAs that are globally unique but still private, but as far as I know, there is no registry yet that will hand them out. So these can't be used yet.
Who would know more about this? I'm in the process of writing down some startup thoughts about how we can (and maybe should) implement IPv6 here where I work. It's a closed national network where security is prio 1 and we might also have to work/connect to other network of the same type in other countries... in short, we need to be globaly unique so we actually need that registrary to be there:)
the original ULA document combined both self-selected ULAs and registry-selected ULAs. Over the period of a year of IETF consideration they were split in two, and the random self-selction method became RFC 4193 and the so-called centrally assigned IDs draft expired . Some URLS: - the history of the drafts: http://smakd.potaroo.net/ietf/idref/draft-ietf-ipv6-unique-local-addr/index.... - the centrally assigned drafts: http://smakd.potaroo.net/ietf/idref/draft-ietf-ipv6-ula-central/index.html There was a long discussion on the IPv6 list about the issues with the operation of a registry. I've forgotten when, but around May - July 2003 sounds familiar for some reason. The concept of a central register of unique 40bit sequences is not completely dead. At RIPE 51 I described some current work at APNIC that includes a certificate identity scheme that uses this same concept (http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51-address-c... (see page 14 of the presentation). I also did some maths of the collision probability of random 40bit long numbers (the so-called "birthday problem" in an expired draft (http://smakd.potaroo.net/ietf/idref/draft-huston-ipv6-local-use-comments/ind...). It _may_ be the case that a form of centrally assigned unique 40 bit strings for use in the context of the original model of centrally-assigned unique local addresses may be a useful by-product of the certification work - but if it proceeds that this is likely to be some time away yet from becoming part of the service portfolio associated with certification. regards, Geoff
On Sat, Dec 24, 2005 at 08:01:32AM +1100, Geoff Huston wrote:
At 10:03 PM 23/12/2005, Roger Jorgensen wrote:
On Fri, 25 Nov 2005, Gert Doering wrote: <snip>
The idea is that ULAs are random-generated in a way that makes it "fairly unlikely" that you end up in an address collision. But there is no guarantee, of course.
indeed. The chances of collision exceed 0.5 once the pool of random;y drawn numbers exceeds 1.24 million.
presuming random generation... wearing a black hat tells me that random selection is not what i want or need to attack some other machine, not when i can hijack its number and then claim plausable deniability ..
Geoff
--bill
Roger Jorgensen wrote:
* become LIR and request the needed IP space.
From a couple projects I have done in the past - this is the path I
would follow. The reasoning would be that your network will connect to the Internet or networks connected to the Internet. That you TODAY use firewalls or NATs sould not prevent you from getting address space. -hph
On Thu, 24 Nov 2005, Oliver Bartels wrote:
On Mon, 21 Nov 2005 17:10:10 +0100 (CET), Roger Jorgensen wrote: <snip> If IPv4 offers PI = provider _independence_ and multihoming and IPv6 doesn't, then IPv4 is obviously the better solution for those who requires this functionallity.
Thus they won't use IPv6.
Please keep in mind: The _customer_ votes, not you, not me.
And as the majority of the large and a significant portion of medium size businesses are obviously not willing to accept an IP protocol not providing this functionallity, IPv6 will remain at it's current status:
A technical playground for technically interested people.
a very true point in one way but that is again as I see it, we're still thinking IPv4 when talking IPv6. Why do they need multihoming and PI? They don't trust the ISP and vendors to deliver them uptime and freedom... isn't this a problem the ISP and vendors should try to solve? Of course, the idea of easy renumbering was suppose to solve this but again, we're thinking IPv4 so it's not easy to understand. Again, we don't need PI space and multihoming, what we need are a way to give the users and GOOD connectivity (uptime, speed etc) and make it easy for them to switch providers as they see fit. <snip>
Hmm, please let me translate: "Even if the car doesn't drive and the engine doesn't deliver a single horse power at the wheels, drop the thought about driving, start to think about other way to use the possibility this great car gives us."
Sound like newspeak: If we _think_ we can't solve the problem, drop discussing the problem.
for several years this discussion have been going on, still no real solution. IPv6 give us the freedom todo ALOT of things, USE those possibilities, if we have to change how IP are done, some TCP headers etc, then do it... propose a good idea and prove it. That could give us multihoming. Actually there is a master thesis about howto create connectivity for TCP session even if one of the links went down, the session just used another IP (1)... the user don't notice anything either and it have zero problem working with standard tcp-stacks since it use the extended header of IPv6. That's just ONE of many possible ways... (1) it's a master thesis writting by a student related to University of Tromsø as part of the Pasta project, www.pasta.cs.uit.no -- ------------------------------ Roger Jorgensen | rogerj@stud.cs.uit.no | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no -------------------------------------------------------
Roger Jorgensen wrote:
On Thu, 24 Nov 2005, Oliver Bartels wrote:
On Mon, 21 Nov 2005 17:10:10 +0100 (CET), Roger Jorgensen wrote: <snip> If IPv4 offers PI = provider _independence_ and multihoming and IPv6 doesn't, then IPv4 is obviously the better solution for those who requires this functionallity.
Thus they won't use IPv6.
Please keep in mind: The _customer_ votes, not you, not me.
And as the majority of the large and a significant portion of medium size businesses are obviously not willing to accept an IP protocol not providing this functionallity, IPv6 will remain at it's current status:
A technical playground for technically interested people.
a very true point in one way but that is again as I see it, we're still thinking IPv4 when talking IPv6.
We're thinking Real World(TM).
Why do they need multihoming and PI? They don't trust the ISP and vendors to deliver them uptime and freedom... isn't this a problem the ISP and vendors should try to solve? Of course, the idea of easy renumbering was suppose to solve this but again, we're thinking IPv4 so it's not easy to understand.
Again, we don't need PI space and multihoming, what we need are a way to give the users and GOOD connectivity (uptime, speed etc) and make it easy for them to switch providers as they see fit.
That's only part of the reasoning. Customers don't want to be locked in to any one ISP. They want to have bargaining power which only comes with the ability to switch ISPs at will.
<snip>
Hmm, please let me translate: "Even if the car doesn't drive and the engine doesn't deliver a single horse power at the wheels, drop the thought about driving, start to think about other way to use the possibility this great car gives us."
Sound like newspeak: If we _think_ we can't solve the problem, drop discussing the problem.
for several years this discussion have been going on, still no real solution. IPv6 give us the freedom todo ALOT of things, USE those possibilities, if we have to change how IP are done, some TCP headers etc, then do it... propose a good idea and prove it. That could give us multihoming. Actually there is a master thesis about howto create connectivity for TCP session even if one of the links went down, the session just used another IP (1)... the user don't notice anything either and it have zero problem working with standard tcp-stacks since it use the extended header of IPv6.
Yea, that's known as SCTP.
That's just ONE of many possible ways...
You're only handwaiving and saying "no". We are looking for ways to fit IPv6 to the reality of how millions of people and corporations use and want to use the Internet, technically and commercially. -- Andre
Andre Oppermann wrote:
Roger Jorgensen wrote: <SNIP>
for several years this discussion have been going on, still no real solution. IPv6 give us the freedom todo ALOT of things, USE those possibilities, if we have to change how IP are done, some TCP headers etc, then do it... propose a good idea and prove it. That could give us multihoming. Actually there is a master thesis about howto create connectivity for TCP session even if one of the links went down, the session just used another IP (1)... the user don't notice anything either and it have zero problem working with standard tcp-stacks since it use the extended header of IPv6.
Yea, that's known as SCTP.
I am always wondering why SCTP is not taking off. From the few tests I did it works perfectly well, the location/identifier separation is pretty cleanly handled in DNS and inside the protocol for quick updates. Unfortunately not much software supports it at the moment. One way to fix that is to add a small proxy/BIA tool which changes TCP+UDP into SCTP. This works for server and client side. But nobody wants to do this for some mysterious reason. Greets, Jeroen
You seem to be far away from the ground realities. Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these real issues for a good reason. Regards, Salman At 10:55 AM 11/25/2005 +0100, Roger Jorgensen wrote:
On Thu, 24 Nov 2005, Oliver Bartels wrote:
On Mon, 21 Nov 2005 17:10:10 +0100 (CET), Roger Jorgensen wrote: <snip> If IPv4 offers PI = provider _independence_ and multihoming and IPv6 doesn't, then IPv4 is obviously the better solution for those who requires this functionallity.
Thus they won't use IPv6.
Please keep in mind: The _customer_ votes, not you, not me.
And as the majority of the large and a significant portion of medium size businesses are obviously not willing to accept an IP protocol not providing this functionallity, IPv6 will remain at it's current status:
A technical playground for technically interested people.
a very true point in one way but that is again as I see it, we're still thinking IPv4 when talking IPv6.
Why do they need multihoming and PI? They don't trust the ISP and vendors to deliver them uptime and freedom... isn't this a problem the ISP and vendors should try to solve? Of course, the idea of easy renumbering was suppose to solve this but again, we're thinking IPv4 so it's not easy to understand.
Again, we don't need PI space and multihoming, what we need are a way to give the users and GOOD connectivity (uptime, speed etc) and make it easy for them to switch providers as they see fit.
<snip>
Hmm, please let me translate: "Even if the car doesn't drive and the engine doesn't deliver a single horse power at the wheels, drop the thought about driving, start to think about other way to use the possibility this great car gives us."
Sound like newspeak: If we _think_ we can't solve the problem, drop discussing the problem.
for several years this discussion have been going on, still no real solution. IPv6 give us the freedom todo ALOT of things, USE those possibilities, if we have to change how IP are done, some TCP headers etc, then do it... propose a good idea and prove it. That could give us multihoming. Actually there is a master thesis about howto create connectivity for TCP session even if one of the links went down, the session just used another IP (1)... the user don't notice anything either and it have zero problem working with standard tcp-stacks since it use the extended header of IPv6.
That's just ONE of many possible ways...
(1) it's a master thesis writting by a student related to University of Tromsø as part of the Pasta project, www.pasta.cs.uit.no
--
------------------------------ Roger Jorgensen | rogerj@stud.cs.uit.no | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no -------------------------------------------------------
Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these real issues for a good reason.
i gather that the message that leslie daigle was given at the last nanog was not well-transmitted to the ietf. no big surprise. you may want to look at http://nanog.org/mtg-0510/real/ipv6-bof.ram randy
Salman Asadullah wrote:
You seem to be far away from the ground realities.
Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these real issues for a good reason.
Neither Multi6 nor SHIM6 are even in an draft RFC state yet and to be workable they'd have to be implemented on every end-host out there. That is every operating system in sufficient existence. That puts IPv6 even further in the already distant future considering common OS upgrade and replacement cycles. Second this doesn't solve the renumbering problem. Renumbering is not just giving hosts new IP addresses but alost managing DNS and Firewalls. No even remotely workable and scaleable solution has been presented yet. So nice try but no cookie. -- Andre
Regards, Salman
At 10:55 AM 11/25/2005 +0100, Roger Jorgensen wrote:
On Thu, 24 Nov 2005, Oliver Bartels wrote:
On Mon, 21 Nov 2005 17:10:10 +0100 (CET), Roger Jorgensen wrote: <snip> If IPv4 offers PI = provider _independence_ and multihoming and IPv6 doesn't, then IPv4 is obviously the better solution for those who requires this functionallity.
Thus they won't use IPv6.
Please keep in mind: The _customer_ votes, not you, not me.
And as the majority of the large and a significant portion of medium size businesses are obviously not willing to accept an IP protocol not providing this functionallity, IPv6 will remain at it's current status:
A technical playground for technically interested people.
a very true point in one way but that is again as I see it, we're still thinking IPv4 when talking IPv6.
Why do they need multihoming and PI? They don't trust the ISP and vendors to deliver them uptime and freedom... isn't this a problem the ISP and vendors should try to solve? Of course, the idea of easy renumbering was suppose to solve this but again, we're thinking IPv4 so it's not easy to understand.
Again, we don't need PI space and multihoming, what we need are a way to give the users and GOOD connectivity (uptime, speed etc) and make it easy for them to switch providers as they see fit.
<snip>
Hmm, please let me translate: "Even if the car doesn't drive and the engine doesn't deliver a single horse power at the wheels, drop the thought about driving, start to think about other way to use the possibility this great car gives us."
Sound like newspeak: If we _think_ we can't solve the problem, drop discussing the problem.
for several years this discussion have been going on, still no real solution. IPv6 give us the freedom todo ALOT of things, USE those possibilities, if we have to change how IP are done, some TCP headers etc, then do it... propose a good idea and prove it. That could give us multihoming. Actually there is a master thesis about howto create connectivity for TCP session even if one of the links went down, the session just used another IP (1)... the user don't notice anything either and it have zero problem working with standard tcp-stacks since it use the extended header of IPv6.
That's just ONE of many possible ways...
(1) it's a master thesis writting by a student related to University of Tromsø as part of the Pasta project, www.pasta.cs.uit.no
--
------------------------------ Roger Jorgensen | rogerj@stud.cs.uit.no | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no -------------------------------------------------------
At 08:13 PM 29/11/2005, Andre Oppermann wrote:
Salman Asadullah wrote:
You seem to be far away from the ground realities.
Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these real issues for a good reason.
Neither Multi6 nor SHIM6 are even in an draft RFC state yet
Multi6 produced 5 WG drafts, all of which have been published as RFCs You can (and probably should) read through RFCs 3582, 4116, 4177, 4219, and 4218 SHIM6 is working on the following drafts - again I would recommend that you read though all of them:... draft-ietf-shim6-app-refer, draft-ietf-shim6-applicability, draft-ietf-shim6-arch, draft-ietf-shim6-failure-detection, draft-ietf-shim6-hba, draft-ietf-shim6-proto, and draft-ietf-shim6-reach-detect.
and to be workable they'd have to be implemented on every end-host out there. That is every operating system in sufficient existence. That puts IPv6 even further in the already distant future considering common OS upgrade and replacement cycles.
yep - any form of locator / identity split is such a basic shift in the architectural model used by IP that changes to the stack are required. This is the case in mobility, nomadism, ad-hoc networking and this form of multi-homing. If you want agile locators and any form of persistence in endpoint identifiers then you are not going to get that without changes to the stack. Now if you are arguing that the deployed base of IPv6 is so large that further changes are impossible in this particular technology due to the inertia of the deployed IPv6 base, then that's certainly an interesting perspective, and not one I've heard all that often so far. If you are saying that this will take time to develop and deploy, then you are probably right, and a model that can use incremental deployment using a conventional initial context followed by a capability exchange to explore if there is mutual support for this form of communication capability, then you may well be onto something interesting. Although I'd hasten to add that this is the approach being taken within the SHIM6 architecture.
Second this doesn't solve the renumbering problem. Renumbering is not just giving hosts new IP addresses but alost managing DNS and Firewalls. No even remotely workable and scaleable solution has been presented yet.
I'm not sure I agree with you about the DNS and renumbering - its not a clearly defined space, and the implications relating to the DNS are not clearly understood in communication models where feasible locator sets are dynamically exchanged rather than always loaded into third party rendezvous points, as in the DNS model.
So nice try but no cookie.
Thank you, Geoff
On Mon, 28 Nov 2005 15:55:16 -0800, "Salman Asadullah" <sasad@cisco.com> said:
You seem to be far away from the ground realities.
Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these real issues for a good reason.
Regardless of the efforts, from a provider POV it's only "work in progress". Make sure your preferred technology is implemented across all platforms and accompanied by solutions for traffic-engineering, filtering and other issues. Then you may have a viable alternative to present to the operators community. Don't expect anybody to adopt new technologies unless they represent some progress. I'm not saying that shim6 is DOA. It *may become* an alternative, but it *is not*. Unless you can convince content-providers to trust their upstream to provide redundancy and thus eliminate the need for end-site multihoming you have the following realistic short-term alternatives: * Keep ipv6 experimental and postpone operational deployment until there's a good technical solution to the multi-homing problem or a way to eliminate the DFZ and the related concerns about routing- table size. * Adopt a PI policy for v6 similar to the current v4-policy, and hope that moore can keep up with the growth of the routing-table.
From there policies will have to evolve, along with the development of new technology. Evolution is a perpetual process, not a project with a finite deadline.
PS! am I missing something, or is IETF/IAB trying to copy the ITU in the way they produce paper-standards? Is that really such a good idea? //per -- Per Heldal heldal@eml.cc
Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these real issues for a good reason. Regardless of the efforts, from a provider POV it's only "work in progress".
one of the key points from the nanog session was that shim6 is the *wrong* work in progress. what is needed is _site_ multi-homing, not host multi-homing. randy
At 03:17 AM 30/11/2005, Randy Bush wrote:
Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these real issues for a good reason. Regardless of the efforts, from a provider POV it's only "work in progress".
one of the key points from the nanog session was that shim6 is the *wrong* work in progress. what is needed is _site_ multi-homing, not host multi-homing.
"wrong"? "right"? Usual response - if you believe that there is a better way of doing this work through the issues here, then write up an approach, gather support, get peer review etc etc. As I said at NANOG, part of the problem with distributed models where there is action at a distance is to understand and clearly identify instances of gratuitous packet header rewriting by hostile agents as compared to packet rewriting by agents who believe that they are doing this in a friendly and helpful fashion. This becomes a challenging problem,of course. I don't think any single approach today is the one true right approach at this point, but unless we explore this space with some diligence, allow for experimentation and keep an open mind on this work then you are going to get intractably wedged between the desire for greater flexibility in the use of addresses as a form of semi-persistent endpoint identifiers and the desire for reduced flexibility in the use of addresses as forwarding tokens in order to keep the routing space confined to readily computable dimensions. But of course _all_ this will be solved in MPLS - right? :-) Geoff
On Wed, 30 Nov 2005, Geoff Huston wrote:
At 03:17 AM 30/11/2005, Randy Bush wrote:
Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these real issues for a good reason. Regardless of the efforts, from a provider POV it's only "work in progress".
one of the key points from the nanog session was that shim6 is the *wrong* work in progress. what is needed is _site_ multi-homing, not host multi-homing.
Yes, well if it goes forward, it may well end up being used for setting up site-multihoming: http://www.ietf.org/mail-archive/web/architecture-discuss/current/msg00095.h... and will be seen as friendly and right solution (on what "friendly" and "right" can mean seen below).
"wrong"? "right"?
Usual response - if you believe that there is a better way of doing this work through the issues here, then write up an approach, gather support, get peer review etc etc.
As I said at NANOG, part of the problem with distributed models where there is action at a distance is to understand and clearly identify instances of gratuitous packet header rewriting by hostile agents as compared to packet rewriting by agents who believe that they are doing this in a friendly and helpful fashion. This becomes a challenging problem,of course.
If its hostile or friendly behavior is in the eye of the beholder - but in fact it may not even be only one side or the other for the same person. If I sit under a NAT and it prevents my application from running, I'm hostile to that behavior. But same NAT box may well be protecting my home network from intrusion and allowing me to have multiple computers connected through the same dsl/cable/wireless connection, so I'd view it as a friendly. Since most people don't notice its hostile behavior (due to kind of applications they run) and all notice its friendly behavior it will overall be seen as a friend and "right" solution. So is there better way to do it and without NAT? Of course there is - have real firewall and have block of ips - but NAT is winning as a business case because it can do those several friendly things well for almost everyone and without dependence on network provider and those few users who are inconvenienced and their application are viewed as minor percentage and not a problem in the overall business case. So business case won but IETF end-end tcp/ip architecture broken ...
I don't think any single approach today is the one true right approach at this point, but unless we explore this space with some diligence,
Diligence is the right word. But is it really the size of the routing table that we're being most concerned (considering #of routes in ipv6 will most definitely be smaller then with ipv4 because of less fragmentation - generally one ip block per ASN) or business case of users who do not want to be dependent on IP provider and RIR to be able to multihome? And should due diligence be applied so that proposed solution both makes sense to do for those who will use it (i.e. small businesses in case of shim6) an does not break applications when that is done? -- William Leibzon Elan Networks william@elan.net
participants (28)
-
Andre Oppermann -
bmanning＠vacation.karoshi.com -
Cameron C. Gray -
Daniel Roesen -
David Kessens -
Elmar K. Bins -
Florian Weimer -
Geoff Huston -
Gert Doering -
Hans Petter Holen -
Jeroen Massar -
Jørgen Hovland -
Kurt Erik Lindqvist -
Lea Roberts -
leo vegoda -
Marcus Gerdon -
Masataka Ohta -
Max Tulyev -
McTim -
Michael.Dillon＠btradianz.com -
Oliver Bartels -
Per Heldal -
Randy Bush -
Roger Jorgensen -
Salman Asadullah -
Sascha Lenz -
Tim Chown -
Wilfried Woeber, UniVie/ACOnet -
william(at)elan.net