Re: Internic address allocation policy
At 22:05 3/19/95, Vadim Antonov wrote:
You may like it or dislike it but nation-wide backbone providers effectively run the Internet nowadays. It is a rare case when big businesses actually introduced some common sense in the way things are done architecture-wise. Why not to do the same with the address allocation?
Speaking from a (large) user organization. I am very concerned about having the ISPs performing address allocation, particularly aggregating addresses. As a user, I want to be able to change my service provider if I get a better deal from a competitor or am having service difficulties with my current provider. Today's technology for managing addresses on individual computers makes it very hard for an organization to renumber. Literally every computer administrator needs to be in the loop. This can be a large loop when you have 13,000+ independently managed machines (like we do). How do we users get our say to ensure that an addressing architecture doesn't come into existence which tends to lock us into a particular provider? -Jeff
Speaking from a (large) user organization. I am very concerned about having the ISPs performing address allocation, particularly aggregating addresses. As a user, I want to be able to change my service provider if I get a better deal from a competitor or am having service difficulties with my current provider. Today's technology for managing addresses on individual computers makes it very hard for an organization to renumber. Literally every computer administrator needs to be in the loop. This can be a large loop when you have 13,000+ independently managed machines (like we do).
How do we users get our say to ensure that an addressing architecture doesn't come into existence which tends to lock us into a particular provider?
The entire point behind CIDR was to allow flexible sized blocks of address announcements via BGP. The method of sending CIDR blocks to a provider should not have any direct relation to the provider's ability to handle "defections" of individual networks within the block. I understand your concern, but it really is pretty orthogonal to the problem of getting enough CIDR blocks to providers to start with... -george william herbert gherbert@crl.com
At 22:05 3/19/95, Vadim Antonov wrote:
You may like it or dislike it but nation-wide backbone providers effectively run the Internet nowadays. It is a rare case when big businesses actually introduced some common sense in the way things are done architecture-wise. Why not to do the same with the address allocation?
Speaking from a (large) user organization. I am very concerned about having the ISPs performing address allocation, particularly aggregating addresses. As a user, I want to be able to change my service provider if I get a better deal from a competitor or am having service difficulties with my current provider. Today's technology for managing addresses on individual computers makes it very hard for an organization to renumber. Literally every computer administrator needs to be in the loop. This can be a large loop when you have 13,000+ independently managed machines (like we do).
How do we users get our say to ensure that an addressing architecture doesn't come into existence which tends to lock us into a particular provider?
-Jeff
In THEORY, once an address range is delegated to you it is YOURS. CIDR permits "holes", that is, more-specific routes. Yes, this eventually will cause CIDR to fail due to entropy. What is new about that? This was known and understood when CIDR was developed and deployed. Some providers try to force you to "give back" the address(es) when you leave. MCSNet, and most others, do not. My view on this is that once you receive an address consisting of at least a Class "C" block (ie: the last octet is yours) then it is yours to keep -- period. For sub-C allocations there is no good way to delegate those, and as such at present we view sub-C allocations as belonging to us, and I suspect most other providers who are as aggressive as we are in delegating small pieces of address space also view things in this fashion. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity Modem: [+1 312 248-0900] | (shell, PPP, SLIP, leased) in Chicagoland Voice: [+1 312 248-8649] | 6 POPs online through Chicago, all 28.8 Fax: [+1 312 248-9865] | Email to "info@mcs.net" for more information ISDN: Surf at Smokin' Speed | WWW: http://www.mcs.net, gopher: gopher.mcs.net
In THEORY, once an address range is delegated to you it is YOURS. CIDR permits "holes", that is, more-specific routes.
Some providers try to force you to "give back" the address(es) when you leave. MCSNet, and most others, do not. My view on this is that once you receive an address consisting of at least a Class "C" block (ie: the last octet is yours) then it is yours to keep -- period.
For sub-C allocations there is no good way to delegate those, and as such at present we view sub-C allocations as belonging to us, and I suspect most other providers who are as aggressive as we are in delegating small pieces of address space also view things in this fashion.
Looks like a double standard to me... The same argument could be placed for any subnet not on an 8,16, or 24 bit bound. Remember that consistant policy is a "Good Thing"(tm?) and something that works, -across the board- will last us longer than some simple haq that deals w/ current, broken hardware/software. (Will this policy work in 24 months?) -- --bill
Looks like a double standard to me... The same argument could be placed for any subnet not on an 8,16, or 24 bit bound.
Yes and no. Technical limitations in things like in-addr name service make moving things with any boundary in the last byte very difficult, but things with any boundary before it possible (and a boundary on a byte much easier). -george
Looks like a double standard to me... The same argument could be placed for any subnet not on an 8,16, or 24 bit bound.
Yes and no. Technical limitations in things like in-addr name service make moving things with any boundary in the last byte very difficult, but things with any boundary before it possible (and a boundary on a byte much easier).
But there are ways to do this -now-. Folks are just not willing to do it. (Ever look at how TPC.INT works? How about NSAP in-addrs?) Look, the in-addr argument is just that. -- --bill
Yes and no. Technical limitations in things like in-addr name service make moving things with any boundary in the last byte very difficult, but things with any boundary before it possible (and a boundary on a byte much easier).
But there are ways to do this -now-. Folks are just not willing to do it. (Ever look at how TPC.INT works? How about NSAP in-addrs?) Look, the in-addr argument is just that.
I'm not familiar with NSAP's setup. I have looked at tpc.int, and it looks to me like they could have done it with just a largeish standard named configuration. Nothing fancy, no new technology, just a little thinking about the configuration. You'd either have to have a lot of huge manually maintained files, a hacked named, or some sort of build script and intermediate db format to do the in-addr maps for sub-C nets. Ok, I can see how you can do it (a few days work at most), but it's still a hack. Wasn't that your criticism of the buy-and-sell-blocks-of-C's fix? 8-) Has anyone tested to see if all the BGP-using hardware out there will actually deal with advertising nybbles as opposed to Cs? -george
From: George Herbert <gherbert@crl.com> Subject: Re: Internic address allocation policy Has anyone tested to see if all the BGP-using hardware out there will actually deal with advertising nybbles as opposed to Cs? Any BGP-4 using hardware must, or is severly broken.
In THEORY, once an address range is delegated to you it is YOURS. CIDR permits "holes", that is, more-specific routes.
Some providers try to force you to "give back" the address(es) when you leave. MCSNet, and most others, do not. My view on this is that once you receive an address consisting of at least a Class "C" block (ie: the last octet is yours) then it is yours to keep -- period.
For sub-C allocations there is no good way to delegate those, and as such at present we view sub-C allocations as belonging to us, and I suspect most other providers who are as aggressive as we are in delegating small pieces of address space also view things in this fashion.
Looks like a double standard to me... The same argument could be placed for any subnet not on an 8,16, or 24 bit bound.
Remember that consistant policy is a "Good Thing"(tm?) and something that works, -across the board- will last us longer than some simple haq that deals w/ current, broken hardware/software. (Will this policy work in 24 months?)
-- --bill
Got a better idea Bill? I'm all ears. Forcing customers to give back addresses is not workable in any enterprise of reasonable size. Application gateways may work out for some applications, but not all. Forcing people to renumber isn't workable. Portability is the only real answer to this, and I agree that IPv4 isn't great in that fashion, and CIDR is a botch and will degenerate over entropy. But its what we're stuck with right now, Bill, so we make do with what we have. BTW, coddling vendors with broken architectures in the process isn't a solution either. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity Modem: [+1 312 248-0900] | (shell, PPP, SLIP, leased) in Chicagoland Voice: [+1 312 248-8649] | 6 POPs online through Chicago, all 28.8 Fax: [+1 312 248-9865] | Email to "info@mcs.net" for more information ISDN: Surf at Smokin' Speed | WWW: http://www.mcs.net, gopher: gopher.mcs.net
In THEORY, once an address range is delegated to you it is YOURS. CIDR permits "holes", that is, more-specific routes.
Some providers try to force you to "give back" the address(es) when you leave. MCSNet, and most others, do not. My view on this is that once you receive an address consisting of at least a Class "C" block (ie: the last octet is yours) then it is yours to keep -- period.
For sub-C allocations there is no good way to delegate those, and as such at present we view sub-C allocations as belonging to us, and I suspect most other providers who are as aggressive as we are in delegating small pieces of address space also view things in this fashion.
Looks like a double standard to me... The same argument could be placed for any subnet not on an 8,16, or 24 bit bound.
Remember that consistant policy is a "Good Thing"(tm?) and something that works, -across the board- will last us longer than some simple haq that deals w/ current, broken hardware/software. (Will this policy work in 24 months?)
-- --bill
Sure, Bill, as soon we all fix in-addr.arpa and the other botches which are required to route these things, then we're happy to maintain that for a customer and allow them to take a sub-C allocation with them. What was that about core routers running out of memory again? Until then such a policy imposes indefinite costs on an organization which is no longer deriving revenue from that customer who is imposing the costs. That's unworkable, and you and the rest of the community know it, which is why we draw the line where we do. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity Modem: [+1 312 248-0900] | (shell, PPP, SLIP, leased) in Chicagoland Voice: [+1 312 248-8649] | 6 POPs online through Chicago, all 28.8 Fax: [+1 312 248-9865] | Email to "info@mcs.net" for more information ISDN: Surf at Smokin' Speed | WWW: http://www.mcs.net, gopher: gopher.mcs.net
participants (5)
-
bmanning＠ISI.EDU -
George Herbert -
jis＠mit.edu -
karl＠mcs.com -
Paul Traina