Re: [ipv6-wg] IPv6 PI
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:
(deleted address-policy-wg from the cc:)
Done.
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?
40G line rate with small packets? Sounds neat. (n times 10G line rate with large packets on a signle router has been possible for quite some time now.) Previous router generations couldn't process packets on the fast path as soon as they contained IP options (IPv4) or extension headers (IPv6). Has this really changed? (The whole issue may not be a real problem, it only shows that the claim that IPv6 has been designed for efficient forwarding is crap.)
On 28 nov 2005, at 09.19, Florian Weimer wrote:
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?
40G line rate with small packets? Sounds neat. (n times 10G line rate with large packets on a signle router has been possible for quite some time now.)
Previous router generations couldn't process packets on the fast path as soon as they contained IP options (IPv4) or extension headers (IPv6). Has this really changed?
Not for previous version no...
(The whole issue may not be a real problem, it only shows that the claim that IPv6 has been designed for efficient forwarding is crap.)
Well...that argument goes both ways. You could also say that the hw vendors didn't follow the development as IPv6 was certainly defined when the current hw was designed. The real issue is the upgrade costs and how willing providers are to upgrade for _just_ ipv6 forwarding capacity. Probably not very as the revenue margin will stay the same. OTOH they will upgrade for faster line-rate over time anyway and the problem over time is non-existing. Personally I don't think v6 gives as much increased forwarding capacity as MPLS - none. OTOH there are v6 claims in the marketing and press that tends to make me more upset :-) The increased security is my favourite :-) - kurtis -
* Kurt Erik Lindqvist:
Previous router generations couldn't process packets on the fast path as soon as they contained IP options (IPv4) or extension headers (IPv6). Has this really changed?
Not for previous version no...
What do you mean? Do ASIS exist which can skip over an arbitrary number of IPv6 extension headers, at line rate?
(The whole issue may not be a real problem, it only shows that the claim that IPv6 has been designed for efficient forwarding is crap.)
Well...that argument goes both ways. You could also say that the hw vendors didn't follow the development as IPv6 was certainly defined when the current hw was designed.
Are you sure? The extension header concept seems to stem from SIPP (1994), which predates ASIC forwarding (flow-based forwarding was state of the art back then) and layer 4 filters: | 4.2 SIPP Options | | SIPP includes an improved option mechanism over IPv4. SIPP options | are placed in separate headers that are located between the SIPP | header and the transport-layer header in a packet. Most SIPP option | headers are not examined or processed by any router along a packet's | delivery path until it arrives at its final destination. This | facilitates a major improvement in router performance for packets | containing options. [...] (RFC 1710) To locate the transport layer header, you must perform limited processing for all options. With a chained header (like the one in SIPP and IPv6) of almost arbitrary length, this task can't really be parallelized in hardware. With IPv4, you can at least skip over all IP options in a single step (violating tons of RFCs, and perhaps your peering contract).
The real issue is the upgrade costs and how willing providers are to upgrade for _just_ ipv6 forwarding capacity. Probably not very as the revenue margin will stay the same. OTOH they will upgrade for faster line-rate over time anyway and the problem over time is non-existing.
I think there is also little demand for high worst-case line rate performance (aka "DoS resistance"), especially for IPv6.
Personally I don't think v6 gives as much increased forwarding capacity as MPLS - none.
But this is a pity because one of the explicit design goals was to use a simpler header format, permitting more efficient forwarding. 8-(
OTOH there are v6 claims in the marketing and press that tends to make me more upset :-) The increased security is my favourite :-)
Yes, this is a very good one, too. 8-)
On 28 nov 2005, at 12.25, Florian Weimer wrote:
* Kurt Erik Lindqvist:
Previous router generations couldn't process packets on the fast path as soon as they contained IP options (IPv4) or extension headers (IPv6). Has this really changed?
Not for previous version no...
What do you mean?
That deployed hardware is deployed hardware. It won't get magically upgraded.
Do ASIS exist which can skip over an arbitrary number of IPv6 extension headers, at line rate?
Yes.
(The whole issue may not be a real problem, it only shows that the claim that IPv6 has been designed for efficient forwarding is crap.)
Well...that argument goes both ways. You could also say that the hw vendors didn't follow the development as IPv6 was certainly defined when the current hw was designed.
Are you sure? The extension header concept seems to stem from SIPP (1994), which predates ASIC forwarding (flow-based forwarding was state of the art back then) and layer 4 filters:
Current hardware was designed in last 1-2 years so given the above my argument still holds.
To locate the transport layer header, you must perform limited processing for all options. With a chained header (like the one in SIPP and IPv6) of almost arbitrary length, this task can't really be parallelized in hardware.
With IPv4, you can at least skip over all IP options in a single step (violating tons of RFCs, and perhaps your peering contract).
I am certainly not an ASICs designer and will never pretend to be one, but AFAIK we can do deep packet inspection at 40G line rate, at an (extremely) high price. CRS-1 for example seem to claim just this.
Personally I don't think v6 gives as much increased forwarding capacity as MPLS - none.
But this is a pity because one of the explicit design goals was to use a simpler header format, permitting more efficient forwarding. 8-(
Look, IPv6 is longer (more) addresses. Nothing more nothing less. It' won't give you increased performance over v4, but it won't make it worse either. - 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!
1. No PI. _Only_ network operators get a prefix.
I am an operator of a network - do I get a prefix ? (we have lots of computers and need lots of IP addresses: currently the 5 PCs, 2 printers, a phone and some PDA and a server online)
I guess you need to define the criteria in some other way. Perhaps beeing registered with the national regulator
I'm looking at all of that and begin to think that all this discussion about PI vs PA (and only [large] operators can get a prefix) is just for implementing some unfair rules in ISP market. Wise customers wants to have PI because of to be multihoming and have stable and really _provider_independent_ (i.e. not depending on upstream's faults) connection. Small operators wants to have PI because of LIR is often too expensive for them. Large operators do NOT want PI because of they can hold a client with their address space ("if you are going to change ISP - you will have a large trouble with renumbering your network and changing domains" or even "if you do not do ... - we will immediately shut down your connection"). Large operators (can pay for LIR) do NOT want PI because of it makes the extra money barrier to be an operator (LIR cost). See more on. Imagine there is no PI. If somebody really-really-really needs to be multihoming - he will be a LIR and do the LIR initial request (/20 PA for IPv4 instead of /24 PI he really need for years). So in this case we do not conserve one row of route table, but slightly loss in conserving space (/20 instead of /24). Even more. Who is making the most noise about no PI? As I can see, large operators. People who have enough powerful routers to not to think about extra routes there. P.S. And please do not compare IP connectivity with global dynamic routing (it is a really BIG achievement of the Internet!) with PSTN and global static routing where switching routes to certain number plan can take several monthes. Of course, in PSTN we can't ever think about hot backup and upstream reservation (multihoming). -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
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
hiya, (removed address-policy-wg from the cc:) On 11/28/05, Jørgen Hovland <jorgen@hovland.cx> wrote:
-----Original Message----- From: McTim [mailto:dogwallah@gmail.com]
#2 sounds like PI to me. What have I missed?
Hello McTim, You are correct. That's why I wrote PI in the email:-).
I guess I misread the below wrong then ;-) Jørgen Hovland wrote:
- 1. No PI. _Only_ network operators get a prefix.
It is an attempt to suggest an alternative idea to the PI discussion. Don't get me wrong. I am for PI. This idea is perhaps a bit more hierarchical instead of the standard flat one. Just making sure we have thought of everything before we reach consensus
I am sure thiat consensus will take a very long tiime on this one! We will probably have to talk about grotopological v6 adressing (as they are doing on the ARIN ppml) and a host of other issues. I reckon we ought to wait for shim6 to do their work as well.
because this PI discussion is very important to ipv6.
v. true. -- Cheers, McTim $ whois -h whois.afrinic.net mctim
* 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
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
* 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
You need a /28 and want "Provider Independence". I use a /28 at home.
Hope you do not host thousands of websites at home ;)
Lets say that I want "PI" too, that would mean I am going to get, pay for and maintain: - Multiple Redundant Routers - Multiple Redundant Links - Multiple Redundant Transits - Own 24/7 NOC (things will fail) - and a lot more...
You are willing to do and pay for all that, but don't want to become an LIR?
In this example I'm providing hosting and no more than hosting. No telecoms, no transit channels, no ADSL. May be domain registration. To make that business success I need to be multihomed (no objections at this point, I think?). Also I need to be independent from carriers (especially when hosting grows up and I will ask for money for direct peering with me). But I do NOT need a lot of address space (thanks God and RFC, we have HTTP/1.1 this time). Look more. http://www.ripe.net/membership/benefits.html As a hosting provider, I do NOT want any of that services. So no reasons to be LIR, isn't it? It is only example for PI, but many other exists. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
Max Tulyev wrote:
You need a /28 and want "Provider Independence". I use a /28 at home.
Hope you do not host thousands of websites at home ;)
Some hosts have http/https/imaps and other services running. But all it takes to move them away is changing DNS. Nothing more.
Lets say that I want "PI" too, that would mean I am going to get, pay for and maintain: - Multiple Redundant Routers - Multiple Redundant Links - Multiple Redundant Transits - Own 24/7 NOC (things will fail) - and a lot more...
You are willing to do and pay for all that, but don't want to become an LIR?
In this example I'm providing hosting and no more than hosting. No telecoms, no transit channels, no ADSL. May be domain registration.
To make that business success I need to be multihomed (no objections at this point, I think?). Also I need to be independent from carriers (especially when hosting grows up and I will ask for money for direct peering with me).
But I do NOT need a lot of address space (thanks God and RFC, we have HTTP/1.1 this time).
RIR's "business" is about providing LOTS of address space. LIR's provide little address space to endusers and in the above you are an enduser. I suggest you start providing SSL based HTTP. Then you probably need 256 IP's in a sinch. And guess what 256 domains on HTTPS means you have 200 customers. Check the allocations list and see what kind of 'companies' already are LIR and are already
Look more. http://www.ripe.net/membership/benefits.html As a hosting provider, I do NOT want any of that services. So no reasons to be LIR, isn't it?
You don't want: 8<------------------- Registration Services As a member, you can request Internet Resources (IP address space, AS Numbers, Reverse Delegation) from the RIPE NCC. ------------------->8 ??? For your case the answer is simple: get your address space from an LIR. Otherwise draft a proposal for an "enduser-LIR" who can only get 1 AS and 1 prefix for themselves. Greets, Jeroen
Some hosts have http/https/imaps and other services running. But all it takes to move them away is changing DNS. Nothing more.
"Who said it is easy to take off a chocolate from baby's hand never tried to do that" ;-) Unfortunally, real users are not ideal case, and they use pure IPs even nobody asks them to do that.
You don't want: 8<------------------- Registration Services As a member, you can request Internet Resources (IP address space, AS Numbers, Reverse Delegation) from the RIPE NCC. ------------------->8
???
For your case the answer is simple: get your address space from an LIR. Otherwise draft a proposal for an "enduser-LIR" who can only get 1 AS and 1 prefix for themselves.
Yep. I want IP/AS, not IP/AS registration service. Look, you are really want to be a .com TLD registrar just to register your cooldomain.com? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
On Fri, 2 Dec 2005 12:34:10 +0300, "Max Tulyev" <president@ukraine.su> said: [snip]
In this example I'm providing hosting and no more than hosting. No telecoms, no transit channels, no ADSL. May be domain registration.
To make that business success I need to be multihomed (no objections at this point, I think?).
Try a different angle; assume you can get decent (redundant) connectivity to one provider and thus almost as reliable as if you're sitting in their core network. If you still require multihoming, don't your arguments implicitly disqualify your upstream as a hosting-provider too (regardless of them being multihomed and/or peering at any tier)? Who can then be trusted to run hosting-operations? Only multihomed as'es with no downstreams? (*duck*) //per -- Per Heldal heldal@eml.cc
Try a different angle; assume you can get decent (redundant) connectivity to one provider and thus almost as reliable as if you're sitting in their core network. If you still require multihoming, don't your arguments implicitly disqualify your upstream as a hosting-provider too (regardless of them being multihomed and/or peering at any tier)? Who can then be trusted to run hosting-operations? Only multihomed as'es with no downstreams?
Ok, 3 meters Ethernet from core of good network is enough to be technically stable. But still there is management questions because of connectivity from only one upstream and can't establish private (commerce) peerings. P.S. About DNS, many clients really want to have own DNS, more of that, domain is not the only hosting, often there is a lot of corporate and/or private subdomains, that's why people don't want to lose their DNS control. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
On Fri 02 Dec 2005 12:41, Per Heldal wrote:
Who can then be trusted to run hosting-operations?
And that, Ladies & Gentlemen, is exactly the point. No ISP/Telco/Hoster can be trusted. Hence, the requirement for multihoming in v4 today, and in v6 tomorrow. No amount of policy fiddling and idle discussion can change that fact. rgds, s.
On Fri, 2 Dec 2005 13:03:24 +0000, "Sascha Luck" <ripe-lst@eirconnect.net> said:
And that, Ladies & Gentlemen, is exactly the point. No ISP/Telco/Hoster can be trusted. Hence, the requirement for multihoming in v4 today, and in v6 tomorrow. No amount of policy fiddling and idle discussion can change that fact.
[thought my last post had sarcasm written all over it ... nevermind] I don't disagree there's a need for (business requirements) multihoming. Allocation policies however have to reflect reality. There's a reason why we don't accept v4 micro-PI-allocations today (which is what this thread diverted to). Despite endless arguments we've managed to define a balanced policy that works for ipv4 (no need to start those arguments again). To those who want ipv6 deployed *now*; What is their relation to the term "business requirements"? Do they understand the difference between fiction and reality? Shim6&friends belong to the future, as does routing technology able to cope with a fragmented v6 addresspace. The only alternative *today* is to define a policy that has a fair balance between what's practically doable (DFZ size) and connectivity needs. Is it the numbers that are confusing policy-makers? With current v4 policies it's fairly easy to justify the need for a certain size address-block, and equally easy to check utilisation of allocated block. Obliously, with V6 nobody is going to fill a /[whatever] and "utilisation" becomes an irrelevant term. Could it be an alternative to require that V6 PI-holders document their use of the allocated block, and apply some form of hostcount that reflect the current V4 policy to justify their V6 allocation. //per -- Per Heldal heldal@eml.cc
* Per Heldal:
If you still require multihoming, don't your arguments implicitly disqualify your upstream as a hosting-provider too
Indeed, large networks may have surprising characteristics. Router vendors apparently still do not provide technical means to confine IGP anomalies. That's part of the reason why a small AS with a few upstream ISPs can beat Tier-1s in terms of network availability.
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
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
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
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 ---
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
On 29 Nov 2005 14:26:53, Florian Weimer wrote:
* Geoff Huston:
Interesting - it will work for a while, and then you will get to the limit
of deployed capability of routing.
Then what?
You buy new routers.
So we'll just bypass this idiotic discussions, go buy new routers and deploy IPv6 multihoming in the straightforward way. -- Carlos Morgado - chbm(a)ma.ssive.net - http://chbm.net/0x1FC57F0A FP:0A27 35D3 C448 3641 0573 6876 2A37 4BB2 1FC5 7F0A
On 28 Nov 2005 16:37:47, Jørgen Hovland wrote:
1. No PI. _Only_ network operators get a prefix. 2. Customers of network operators can at any time change provider and take their assigned prefix with them. The new provider will announce it as a more specific overriding the aggregate. If the customer decides to get multiple providers, then the network operator with the /32 could also announce a more specific.
There's so wrong there i don't even know where to start. a) space costs money. who pays for hijacked space ? b) if the new ISP goes dark, why does the old ISP get hit with a DDoS destined at the former customer b.1) how does the old ISP protect itself from such a scenario ? c) if a customer multihomes to an ISP B that buys transit from original ISP A how exactly does that work ? d) why should I accept a more specific for a netblock I'm announcing ? e) why do I need to inject the internet into my IGP which is otherwise simple ?
In the country I live in I can change telecom provider and take my phone number with me to the new provider. Why shouldn't I be able to do that with internet providers? Yes, it will somehow create millions/billions of prefixes (atleasat with todays routing technology/protocols). Network operators should be able to handle that hence rule #1.
If you compare internet routing and PSTN "routing" seriously you've never worked with at least one of them. PSTN "routing" isn't, number portability takes days to deploy, PSTN doesn't have efective multipath and please do take a look at the portability mechanisms.
Joergen Hovland
-- Carlos Morgado - chbm(a)ma.ssive.net - http://chbm.net/0x1FC57F0A FP:0A27 35D3 C448 3641 0573 6876 2A37 4BB2 1FC5 7F0A
Hi, On Fri, Dec 02, 2005 at 06:50:05PM +0000, Carlos Morgado wrote:
If you compare internet routing and PSTN "routing" seriously you've never worked with at least one of them. PSTN "routing" isn't, number portability takes days to deploy, PSTN doesn't have efective multipath and please do take a look at the portability mechanisms.
Indeed - but playing the devil's advocate: if people want PI to avoid renumbering, they don't need millisecond switchover time - they want to move to a new ISP "in the time range it takes to setup a leased line"... A number portability scheme similar to what the Telcos have to do *would* work, but it would not be the "dynamic Internet of today". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
* 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
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
On 25 Nov 2005 09:55:54, Roger Jorgensen wrote:
Again, we don't need PI space and multihoming, what we need are a way to give the users and GOOD connectivity (uptime, speed etc) and make it easy for them to switch providers as they see fit.
No. We want to peer with whoever we see fit. If that means becoming a LIR and geting PA, so be it. -- Carlos Morgado - chbm(a)ma.ssive.net - http://chbm.net/0x1FC57F0A FP:0A27 35D3 C448 3641 0573 6876 2A37 4BB2 1FC5 7F0A
On 25 Nov 2005 09:55:54, Roger Jorgensen wrote:
Again, we don't need PI space and multihoming, what we need are a way to give the users and GOOD connectivity (uptime, speed etc) and make it easy for them to switch providers as they see fit.
No. We want to peer with whoever we see fit. If that means becoming a LIR and geting PA, so be it.
Need .com? Become a registrar and get it! Isn't it? ;) -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
participants (29)
-
Andre Oppermann -
bmanning＠vacation.karoshi.com -
Cameron C. Gray -
Carlos Morgado -
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 -
Masataka Ohta -
Max Tulyev -
McTim -
Oliver Bartels -
Per Heldal -
Randy Bush -
Roger Jorgensen -
Salman Asadullah -
Sascha Lenz -
Sascha Luck -
Tim Chown -
Wilfried Woeber, UniVie/ACOnet -
william(at)elan.net