Dear colleagues, below you find a contribution to the Provider Independent Address Space debate. I have written it from the point of view of a regional registrar taking into account public and private discussions with various people at the last IETF and the last RIPE meeting. It spells out what I personally consider sensible and most importantly practicable, read: implementable. The intention is to focus the discussion on the issue and get consensus for the work on the details e.g. RFC1466bis, ripe-104++ ... . Comments very welcome. If you agree, tell me too. Daniel PI vs PA Address Space Daniel Karrenberg ______________________________________________________ Provider Independent vs Provider Aggregatable Address Space Daniel Karrenberg RIPE NCC Version 1 Scope This memo is a contribution to the ongoing discussion about Provider Independent (portable) address space. It is intended to build consensus on practical address assignment policies to be (re)defined in RFC1466bis and regional policies, most concretely ripe-104++. Introduction One can currently distinguish two kinds of globally unique, unicast IPv4 addresses: provider independent (PI) and provider aggregatable (PA) addresses. There are also non globally unique e.g. private uni- cast addresses as described in RFC1597 which are suit- able for many applications. These are outside the scope of this memo as are multicast addresses. Provider Aggregatable Address Space With the introduction of classless interdomain routing (CIDR) [RFC1519] in the Internet, address space is typically assigned by an Internet service provider (ISP) to a customer. The service provider assigns this address space in such a way that routing information for many customers can be aggregated once it leaves the provider's routing domain. This keeps the number of routes in the interdomain routing system at an acceptable level. The number of aggregated routes is much lower than the number that would be needed if ______________________________________________________ pispas.txt Page 1 PI vs PA Address Space Daniel Karrenberg ______________________________________________________ each end-site's individual routes would need to be propagated throughout the whole interdomain routing system. After a customer leaves the service provider who assigned the address space, it can be assigned to another customer. As a consequence the customer will have to reconfigure all their hosts and routers if they continue to require globally unique address space. This requires a clear, preferably contractual, understanding between the assigning service provider and the customer, that the assignment of the address space ends when the provider no longer provides Inter- net connectivity to the customer or soon thereafter. The reason for this arrangement is the load on the interdomain routing system. If the customer used the address space assigned to and aggregatable by their previous service provider when connecting to another service provider, their routing information could not be aggregated and would have to be propagated sepa- rately throughout the whole interdomain routing sys- tem. Provider Independent Address Space Contrary to PA address space, PI address space remains assigned to its user as long as the criteria for the original assignment are met independently of the use of a particular provider's services. Frequently PI addresses are not even assigned by providers but by other Internet registries. The apparent advantage of PI address space is that the user does not have to reconfigure their hosts and routers if they decide to leave a particular service provider. However, PI addresses are expensive to route because no use can be made of aggregation. All early Internet address space assignments were provider independent. Many assign- ments made by ISPs are also formally provider indepen- dent because they lack the clear prior understanding between ISP and customer that the assignment will end with the termination of the service. Current Issues At the time of this writing there is growing concern among the operators of major transit routing domains in the Internet that the number of individual routes and their associated information is growing faster than the deployed routing technology will be able to handle. Parts of the interdomain routing system are already operating at capacity. ______________________________________________________ pispas.txt Page 2 PI vs PA Address Space Daniel Karrenberg ______________________________________________________ It has been argued that PI addresses will quickly become be totally useless since the Internet routing system will not be able to support them any longer. Consequently it has been suggested that the regional IRs should immediately stop allocating and assigning PI space and only allocate PA space to service providers. The regional IRs cannot do this because they would face determining who is a service provider and who is not as well as enforcing minimum sizes for address allocations. This would amount to nothing less than the registries regulating Internet service provision. So far no practical policies for these determinations have been suggested let alone met with community con- sensus. Recommended Policy We therefore suggest that the Internet Registries con- tinue to register both PA and PI address space to users until workable policies can be established. IRs will clearly warn users about the issues w.r.t. their choice of a particular type of address space. IRs will promote the use of private (RFC1597) and PA address space as much as possible. Assignment criteria for both kinds of address space will be exactly iden- tical w.r.t. the amount of address space assigned, the registration requirements etc.. This also implies that assigning PI space prefixes longer than 24 bits is perfectly acceptable if the request does not merit 24 bits of address space to be assigned. It should be clear from the address range itself whether the address concerned is PI or PA. Currently a registration of the fact at /16 level is deemed suffi- cient. It is then up to the service providers to decide whether they will route particular prefixes or not. The way this determination is made is beyond the scope of this document, but we expect that accepting and charging routing announcements based on whether or not they can be aggregated is a distinct possibility. We therefore urgently recommand that service providers shall inform their current and prospective customers as clearly as possible about the issues involved in using PI vs PA space with their service offerings. ______________________________________________________ pispas.txt Page 3 PI vs PA Address Space Daniel Karrenberg ______________________________________________________ Detailed Recommendation The remainder of this document spells out some of the details concerning the policy. All IRs IRs will give those requesting PA space the following warning: Assignment of this address space is valid as long as the criteria for the original assignment are still met and only for the duration of the service agreement between yourself and ISP XXXX who will have the right to re-assign the address space to another user upon termination of the agree- ment or an agreed period thereafter. This means that you will have to re-configure the addresses of all equipment using this address space if you continue to require global uniqueness of those addresses. Note that some Internet services do not require globally unique addresses if accessed through a NAT or application layer gate- way/firewall. IRs will give those requesting PI space the following warning: Assignment of this address space is valid as long as the criteria for the original assignment are still met. However, assign- ment of address space does NOT imply that this address space will be ROUTABLE ON ANY PART OF THE INTERNET. It is expected that users will have to pay a premium for actual routing of PI addresses as opposed to PA addresses. It may eventually become impos- sible to get relatively small amounts of PI space routed on most of the Internet. We strongly suggest you contact any prospective service provider for information about the possibility and pricing of service when using PI addresses. IRs will recommend that end-users use PA space as much as possible. ______________________________________________________ pispas.txt Page 4 PI vs PA Address Space Daniel Karrenberg ______________________________________________________ Regional IRs Regional IRs will introduce an address space type (PA/PI) attribute in their assignment/allocation databases. Regional IRs will from now on register clearly whether specific /16 blocks contain only PI or only PA space. Regional IRS will make sure local IRs understand the difference between address space types and support local IRs in this issue. Regional IRs will work to make both types of address space available to users. Local IRs Local IRs may decide which kind they of address space they will register: PA, PI or both. Local IRs will refer requesters to an appropriate IR for the address space type not offered by the IR. ISP IRs not offering PI space shall support the IR that does concerning assignments to their customers w.r.t. formatting request, furnishing background information, charging etc.. Local IRs which do not normally assign large amounts of a particular type of address space need not hold an allocation of that type of address space. They can get it as needed from their parent IR. Local IRs will make it clear to the user which type of address space is assigned. Clear contractual arrange- ments are recommended in general and mandatory for PA space. IRs have assigned address space in the past which is de-facto aggregated but not formally PA type because there are no clear contractual arrangements about ter- mination of the assignment. IRs will work to make the contractual arrangements for these addresses after the fact as much as possible. Local IRs will clearly mark all new assignments of address space in the assignment database(s) with either PA or PI as appropriate. Local IRs will work to mark all past assignments in the assignment database(s) with either PA or PI as appropriate. ______________________________________________________ pispas.txt Page 5 PI vs PA Address Space Daniel Karrenberg ______________________________________________________ ISPs It is recommended that ISPs clearly specify present and future differences in their service offerings w.r.t. usage of PI vs PA addresses. Availability ftp://ftp.ripe.net/ripe/drafts/pispas.txt (ASCII) ftp://ftp.ripe.net/ripe/drafts/pispas.ps (PostScript). Author's Addresses Daniel Karrenberg RIPE NCC Kruislaan 409 NL-1098 SJ Amsterdam +31 20 592 5065 <Daniel.Karrenberg@ripe.net> ______________________________________________________ pispas.txt Page 6
Daniel many thanks for your fine draft. I would suggest that you establish a clear linkage between the provision of IP addresses and the delivery of the basic service i.e. Internet connectivity. The assignment of PA addresses is as much a part of delivering that service as is the commissioning of a leased line or the setting up of a valid user account. The addresses themselves have no intrinsic value; it is only when combined with the other elements of the service, including the ability to aggregate them for onward advertising, that they have significance in providing an Internet service. If customers insist on using PI addresses, then they can hardly expect the same level of service, as their numbers are at odds with the way in which the basic service is delivered globally. If they are to be allowed to connect with PI addresses, then they must realise that in doing so they are penalising other (PA) users. This would imply that they might incur some penalty in terms of price or whatever. Cheers. Mike
"Mike Norris" <mnorris@dalkey.hea.ie> writes:
... The addresses themselves have no intrinsic value; it is only when combined with the other elements of the service, including the ability to aggregate them for onward advertising, that they have significance in providing an Internet service.
I fully agree with you. However we get a significan number of requests from enterprises who -at this point- do not want "Internet service" but want to build private internets with other enterprises. This demonstrates that there is an intrinsic value in the uniqueness of a number even without "Internet service" with a capital I. I believe that IRs should continue to provide this uniqueness for reasonable requests. I agree with your other remarks and will try to make them even clearer in future documents. Daniel
Daniel,
If you agree, tell me too.
Mainly. You don't mention one of the major arguments for PI space, i.e. customers with multiple service providers. Yakov has written about this in detail, but I think you should mention it.
IRs will give those requesting PA space the following warning:
Assignment of this address space is valid as long as the criteria for the original assignment are still met and only for the duration of the service agreement between yourself and ISP XXXX who will have the right to re-assign the address space to another user upon termination of the agree- ment or an agreed period thereafter. This means that you will have to re-configure the addresses of all equipment using this address space if you continue to require global uniqueness of those addresses. Note that some Internet services do not require globally unique addresses if accessed through a NAT or application layer gate- way/firewall.
I think you should lose the last sentence. It invites controversy.
IRs will give those requesting PI space the following warning:
Assignment of this address space is valid as long as the criteria for the original assignment are still met. However, assign- ment of address space does NOT imply that this address space will be ROUTABLE ON ANY PART OF THE INTERNET. It is expected that users will have to pay a premium for actual routing of PI addresses as opposed to PA addresses. It may eventually become impos- sible to get relatively small amounts of PI space routed on most of the Internet. We strongly suggest you contact any prospective service provider for information about the possibility and pricing of service when using PI addresses.
I don't think it is reasonable to give such a warning without including the counter-balancing warning about renumbering. This long-term risk is the price of avoiding the potentially high cost of occasionally re-configuring the addresses of all equipment using your address space if you had elected to use PA addresses. Regards, Brian Carpenter (CERN) (brian@dxcoms.cern.ch) voice +41 22 767 4967, fax +41 22 767 7155
This keeps the number of routes in the interdomain routing system at an acceptable level. The number of aggregated routes is much lower than the number that would be needed if each end-site's individual routes would need to be propagated throughout the whole interdomain routing system.
"Acceptable level" Hints at a technological weakness in current router hardware. May also be related to route propgation latencies.
The reason for this arrangement is the load on the interdomain routing system. If the customer used the address space assigned to and aggregatable by their previous service provider when connecting to another service provider, their routing information could not be aggregated and would have to be propagated sepa- rately throughout the whole interdomain routing sys- tem.
Again, hints at a technological weakness in current router hardware. May also be related to route propgation latencies. At no point does this address the scaling problems that IPv6 (or followons) will bring. (There are some who will retire before we need a replacment for IPv4, but I'm not one of them)
At the time of this writing there is growing concern among the operators of major transit routing domains in the Internet that the number of individual routes and their associated information is growing faster than the deployed routing technology will be able to handle. Parts of the interdomain routing system are already operating at capacity.
It has been argued that PI addresses will quickly become be totally useless since the Internet routing system will not be able to support them any longer.
A very clear indication that there is a problem in router technology.
Consequently it has been suggested that the regional IRs should immediately stop allocating and assigning PI space and only allocate PA space to service providers.
So there is the suggestion that policies be created/enforced to accomodate problem routing technology? Is this really what we want to do? --bill
bmanning@ISI.EDU writes:
... So there is the suggestion that policies be created/enforced to accomodate problem routing technology? Is this really what we want to do?
That is exactly what my contribution is arguing *against*. It is OK for service providers to not offer certain services, i.e. Internet service for customers using PI space, or charge more for them. It is not OK to enforce stringent policies through address space registration. Daniel
Daniel, I'm somewhat concerned about the text: The regional IRs cannot do this because they would face determining who is a service provider and who is not as well as enforcing minimum sizes for address allocations. This would amount to nothing less than the registries regulating Internet service provision. So far no practical policies for these determinations have been suggested let alone met with community consensus. There is a logical leap here that I'm just not following. Suppose that some organization requests space from an IR. How does knowing whether or not they are an ISP matter? I would submit that the IR must allocate PA (i.e., "leased") address space to the organization regardless of their business status. I suspect that the (faulty) thinking here is that folks who ARE an ISP _automatically_ get PI space. This is NOT the intent of what we've been doing, at least as far as I know. As to practical policies, RFC 1518 outlines some obvious cases (e.g., multihoming) which do deserve PI space. I would hope that this could be the basis of some well-thought out policies. I should also point out that no one is going to propose policies other than the IR's. Have fun writing... ;-) Tony
Tony Li <tli@cisco.com> writes:
Daniel,
I'm somewhat concerned about the text:
The regional IRs cannot do this because they would face determining who is a service provider and who is not as well as enforcing minimum sizes for address allocations. This would amount to nothing less than the registries regulating Internet service provision. So far no practical policies for these determinations have been suggested let alone met with community consensus.
There is a logical leap here that I'm just not following. Suppose that some organization requests space from an IR. How does knowing whether or not they are an ISP matter? I would submit that the IR must allocate PA (i.e., "leased") address space to the organization regardless of their business status.
You cite out of context. The preceeding paragraph reads: Consequently it has been suggested that the regional IRs should immediately stop allocating and assigning PI space and only allocate PA space to service providers. The word "this" refers to that suggestion which has been made more than once in CIDRD. RFC1518 can easily be interpreted this way too:
6.1 Recommendations for an address allocation plan
We anticipate that public interconnectivity between private routing domains will be provided by a diverse set of TRDs, including (but not necessarily limited to):
- backbone networks (Alternet, ANSnet, CIX, EBone, PSI, SprintLink);
- a number of regional or national networks; and,
- a number of commercial Public Data Networks.
...
For the proposed address allocation scheme, this implies that portions of IP address space should be assigned to each TRD (explicitly including the backbones and regionals). For those leaf routing domains which are connected to a single TRD, they should be assigned a prefix value from the address space assigned to that TRD.
Call them TRDs or large ISPs. I do not see any difference. In this scheme a regional IR will have to determine whether someone is a TRD, which gets their own chunk of PA space, or not. Criteria please! Even if you assume that you know who the TRDs are, and thus can determine who is connected to a single TRD only, you are not there yet: There is a problem with organisations who re-assign address space. Typically ISPs do this. If some of them, let's call them resellers for convenience, were *forced by policy* to use PA space of *their* provider for this, it would solidly lock them into that provider. Any move of provider would cause the reseller to require all its customers to renumber. This just will not fly *as a result of general policy*. Any policy that requires this will be perceived as too restrictive to trade and competition and therefore not be implementable. Of course it can fly if the reseller finds it reasonable for any reason (really small, few customers, much cheaper service from transit provider). The next suggestion then usually is the one you mark as faulty below:
I suspect that the (faulty) thinking here is that folks who ARE an ISP _automatically_ get PI space. This is NOT the intent of what we've been doing, at least as far as I know.
So how do we determine who gets a chunk of PA space *of their own* (note this is subtely different from PI space) and who gets locked into their transit ISP, TRD, ... .
As to practical policies, RFC 1518 outlines some obvious cases (e.g., multihoming) which do deserve PI space. I would hope that this could be the basis of some well-thought out policies.
It is flawed, see above.
I should also point out that no one is going to propose policies other than the IR's. Have fun writing... ;-)
The PIS/PAS draft is a contribution towards this. If we can get agreement about it in the operator's groups and IANA (with IAB etc. behind it) accepts this as a starting point I will be hapy to continue writing. Do not get me wrong: I fully understand the necessity for hierarchy. But there is a fundamental conflict here. Stronger hierarchy leads to: + easy routing + easy address allocation - strong regulation of ISPs - favours (currently) big ISPs - makes the Internet core oriented and more or less static - hinders competition - no incentive to solve difficult routing problems - leads to governmental regulation and control Weaker hierarchy leads to: - difficult routing - somewhat difficult address allocation + reglulation of ISPs not necessary + more dynamics and flexibility in topology + easier for new ISPs to establish themselves at any level + encourages competition + big incentive to solve difficult routing problems + no need for governmental regulation and control We have to find a workable compromise. Daniel
[cc list reduced] > The regional IRs cannot do this because they would face > determining who is a service provider and who is not as well as > enforcing minimum sizes for address allocations. This would > amount to nothing less than the registries regulating Internet > service provision. So far no practical policies for these > determinations have been suggested let alone met with community > consensus. > > There is a logical leap here that I'm just not following. Suppose > that some organization requests space from an IR. How does knowing > whether or not they are an ISP matter? I would submit that the IR > must allocate PA (i.e., "leased") address space to the organization > regardless of their business status. You cite out of context. The preceeding paragraph reads: Consequently it has been suggested that the regional IRs should immediately stop allocating and assigning PI space and only allocate PA space to service providers. Yes, exactly. But what is wrong with simply only allocating PA space? I still don't get this. RFC1518 can easily be interpreted this way too: > 6.1 Recommendations for an address allocation plan > > We anticipate that public interconnectivity between private > routing domains will be provided by a diverse set of TRDs, > including (but not necessarily limited to): > > - backbone networks (Alternet, ANSnet, CIX, EBone, PSI, > SprintLink); > > - a number of regional or national networks; and, > > - a number of commercial Public Data Networks. > > ... > > For the proposed address allocation scheme, this implies that > portions of IP address space should be assigned to each TRD > (explicitly including the backbones and regionals). For those leaf > routing domains which are connected to a single TRD, they should be > assigned a prefix value from the address space assigned to that TRD. Call them TRDs or large ISPs. I do not see any difference. In this scheme a regional IR will have to determine whether someone is a TRD, which gets their own chunk of PA space, or not. Criteria please! Simple: everyone gets a chunk of space out of their provider. What's so hard here? You know the (local) roots of the tree, correct? If you don't use the global roots and then truncate at your geographic boundary. Even if you assume that you know who the TRDs are, and thus can determine who is connected to a single TRD only, you are not there yet: There is a problem with organisations who re-assign address space. Typically ISPs do this. If some of them, let's call them resellers for convenience, were *forced by policy* to use PA space of *their* provider for this, it would solidly lock them into that provider. Same argument, same answer: they can renumber. I suspect that a provider can renumber MUCH more easily than any customer can. Any move of provider would cause the reseller to require all its customers to renumber. Correct. This just will not fly *as a result of general policy*. Well, turn off the net, 'cause nwe can't support it. That's simply address ownership by the ISP. No. Nyet. Rien. Nuts. Phooey. Any policy that requires this will be perceived as too restrictive to trade and competition and therefore not be implementable. Then renumbering customers is out the question too. Really, this is a unacceptable argument Daniel. You're saying that it's ok for customers to renumber, but if the provider has to renumber, that's a problem? How do you think the customers will feel about that? So how do we determine who gets a chunk of PA space *of their own* (note this is subtely different from PI space) and who gets locked into their transit ISP, TRD, ... . Who is providing _backbone_ connectivity? It is flawed, see above. Fine. The language is insufficiently recursive. I suspect you know that the intent was recursion. There are spelling errors in it too... ;-) Do not get me wrong: I fully understand the necessity for hierarchy. But there is a fundamental conflict here. Stronger hierarchy leads to: + easy routing + easy address allocation - strong regulation of ISPs - favours (currently) big ISPs - makes the Internet core oriented and more or less static - hinders competition - no incentive to solve difficult routing problems - leads to governmental regulation and control Weaker hierarchy leads to: - difficult routing - somewhat difficult address allocation + reglulation of ISPs not necessary + more dynamics and flexibility in topology + easier for new ISPs to establish themselves at any level + encourages competition + big incentive to solve difficult routing problems + no need for governmental regulation and control We have to find a workable compromise. It's called good "renumbering" technology. It solves all of these problems. Compromise means that each side has to give up something. I'm sure you're quite aware that the "easy routing" side has given just about everything that there is to give and then some. Tony
Tony Li <tli@cisco.com> writes:
[cc list reduced]
Why exclude nanog?
Simple: everyone gets a chunk of space out of their provider. What's so hard here? You know the (local) roots of the tree, correct? If you don't use the global roots and then truncate at your geographic boundary.
I do not understand what you mean by "roots of the tree".
Even if you assume that you know who the TRDs are, and thus can determin e who is connected to a single TRD only, you are not there yet: There is a problem with organisations who re-assign address space. Typically ISPs do this. If some of them, let's call them resellers for convenience, were *forced by policy* to use PA space of *their* provider for this, it would solidly lock them into that provider.
Same argument, same answer: they can renumber. I suspect that a provider can renumber MUCH more easily than any customer can.
The provider probably. But all their customers would have to renumber too!
Any move of provider would cause the reseller to require all its customers to renumber.
Correct.
This just will not fly *as a result of general policy*.
Well, turn off the net, 'cause nwe can't support it. That's simply address ownership by the ISP. No. Nyet. Rien. Nuts. Phooey.
Any policy that requires this will be perceived as too restrictive to trade and competition and therefore not be implementable.
Then renumbering customers is out the question too. Really, this is a unacceptable argument Daniel. You're saying that it's ok for customers to renumber, but if the provider has to renumber, that's a problem? How do you think the customers will feel about that?
A customer as a single organisation can decide unilaterally whether to move provider and renumber and plan accordingly. A reseller will have to coordinate a move with all customers. This is impossible to do unless renumebring is fully automatic and transparent. It is not at present and in the forseeable future. Therefore the reseller is solidly locked into their provider. No reseller of reasonable size will therefore agree to take address space from their provider. If they cannot get address space other than via their provider they will scream "restraint of trade" and/or seriously attack the regional registries and IANA who will have little defense. Government regulation will be called for and gladly provided by the world's governments.
So how do we determine who gets a chunk of PA space *of their own* (note this is subtely different from PI space) and who gets locked into their transit ISP, TRD, ... .
Who is providing _backbone_ connectivity?
What is the _backone_? I though we had just getten rid of the last ISP who claimed to be "the backbone". Everyone and their mother will claim that they are or want to be, on all levels.
It's called good "renumbering" technology. It solves all of these problems.
It does not exist. It is not deployed. It is not even defined. Daniel
> Simple: everyone gets a chunk of space out of their provider. What's > so hard here? You know the (local) roots of the tree, correct? > If you don't use the global roots and then truncate at your geographic > boundary. I do not understand what you mean by "roots of the tree". We know that the topology even in your part of the world is largely hierarchical, and is supported by several large backbones. If you assign PA space to these backbones and then have them in turn allocate space for their customers, then I think it no longer matters who is an ISP. Aggregation can happen. But all their customers would have to renumber too! Correct. Major topological shifts imply major amounts of renumbering. If they cannot get address space other than via their provider they will scream "restraint of trade" and/or seriously attack the regional registries and IANA who will have little defense. I think "no technical choice" is a pretty good defense. Government regulation will be called for and gladly provided by the world's governments. And the 'Net implodes again. Come on, be serious. > Who is providing _backbone_ connectivity? What is the _backone_? I though we had just getten rid of the last ISP who claimed to be "the backbone". Yes, we now no longer use the singular. It is quite clear who is in the default-free portion of the net. It does not exist. It is not deployed. It is not even defined. True. But it is not harder than the problem that you're asking me to solve: make much bigger, must faster hardware for free. Tony
=> It's called good "renumbering" technology. It solves all of these => problems. Compromise means that each side has to give up something. => I'm sure you're quite aware that the "easy routing" side has given => just about everything that there is to give and then some. Tony, Daniel's summary of the problem is excellent. As the "good renumbering technology" has yet to be widely deployed, his conclusion that we must find a compromise is absolutely correct. Then, I shall point out that we are going to see more and more multi-homed networks. If I have some business partners on Renater and others on Eunet, and if I observe that the interconnection between the two providers is less than satisfactory, I am going to buy a subscription to both so that I get correct response times with all of my business partners ("I" here is an hypothetical I, by no means INRIA's official policy). Guess what, there are quite a few providers out there with less than satisfactory peering... And the best of all renumbering technologies is not going to help in the multihomed case. Christian Huitema
If you agree, tell me too.
Looks basically sound to me. We will want to be able to assign PA space to potential customers in advance of them actually connecting, since it is common for companies to start renumbering their internal network some time before they finally commit to connecting. I guess there's no problem with having a "service" (with an annual fee) that consists only of assigning and holding PA address space. The notion that we can no longer say "here are your IP addresses, they are yours for ever, no matter where you connect to the Internet" will be unpopular with our customers, and thus with our sales and marketing department. It will therefore be helpful if this scheme is mandatory (both so we can tell S&M "we *have* to do this", and so there's no distinction between us and our competitors). Are there any timescales for implementation? Tim.
Tim Goodwin <tim@pipex.net> writes:
If you agree, tell me too.
Looks basically sound to me.
We will want to be able to assign PA space to potential customers in advance of them actually connecting, since it is common for companies to start renumbering their internal network some time before they finally commit to connecting. I guess there's no problem with having a "service" (with an annual fee) that consists only of assigning and holding PA address space.
Sure. The point is about the customer not being able to take address space with them, rather than receiveing Internet Service. I will take that into account.
The notion that we can no longer say "here are your IP addresses, they are yours for ever, no matter where you connect to the Internet" will be unpopular with our customers, and thus with our sales and marketing department. It will therefore be helpful if this scheme is mandatory (both so we can tell S&M "we *have* to do this", and so there's no distinction between us and our competitors).
That is why we have this discussion. The RIPE NCC will certainly apply the same guidelines to all European registries.
Are there any timescales for implementation?
It has been argued in CIDRD that global routing is about to collapse. On the other hand noone has yet come up with a consistent and implementable set of policies let alone established consensus. The NCC will propose a revised ripe-104 as soon as the dust settles on a global scale. Daniel
Sure. The point is about the customer not being able to take address space with them, rather than receiveing Internet Service. I will take that into account.
That is why we have this discussion. The RIPE NCC will certainly apply the same guidelines to all European registries.
This statement is very welcome to us. We have taken the precaution of writing into our Reseller Terms that we have the right to ask for the return of IP addresses allocated from our CIDR block in the event of the customer moving from us to another provider. This was done on technical grounds, against great resistance from our marketing people. We would have liked to write it into our standard customer terms as well. Unfortunately this is seen as "anti-competitive" behaviour, so being able to tell customers that all ISPs will be imposing the same conditions would make us feel a lot better. Otherwise, thanks very much for a good document Nigel -------------------------------------------------------------------- Nigel Titley --- BTnet E-mail: Nigel.Titley@bt.net Tel: +44 1442 237674 "Well I'm disenchanted too, we're all disenchanted." (James Thurber)
participants (8)
-
bmanning＠ISI.EDU -
Brian Carpenter CERN-CN -
Christian Huitema -
Daniel Karrenberg -
Mike Norris -
Nigel Titley -
Tim Goodwin -
Tony Li