From danny at tcb.net Thu Jul 13 11:01:53 2000 From: danny at tcb.net (Danny McPherson) Date: Thu, 13 Jul 2000 09:01:53 -0600 Subject: FYI: 31-bits draft Message-ID: <200007131501.JAA19327@tcb.net> [] To: IETF-Announce: ; From: Internet-Drafts at ietf.org Reply-to: Internet-Drafts at ietf.org Subject: I-D ACTION:draft-retana-31bits-01.txt Date: Thu, 13 Jul 2000 06:28:35 -0400 Sender: nsyracus at cnri.reston.va.us - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Using 31-Bit Prefixes on IPv4 Point-to-Point Links Author(s) : A. Retana, R. White, V. Fuller, D. McPherson Filename : draft-retana-31bits-01.txt Pages : 9 Date : 12-Jul-00 With ever-increasing pressure to conserve IP address space on the Internet, it makes sense to consider where relatively minor changes can be made to fielded practice to improve numbering efficiency. One such change, proposed by this document, is to halve the amount of address space assigned to point-to-point links (common throughout the Internet infrastructure) by allowing the use of 31-bit subnet masks in a very limited way. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-retana-31bits-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-retana-31bits-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-retana-31bits-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv at ietf.org" Content-Type: text/plain Content-ID: <20000712140550.I-D at ietf.org> ENCODING mime FILE /internet-drafts/draft-retana-31bits-01.txt - --OtherAccess Content-Type: Message/External-body; name="draft-retana-31bits-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000712140550.I-D at ietf.org> - --OtherAccess-- - --NextPart-- From andy at XECU.NET Mon Jul 31 17:21:21 2000 From: andy at XECU.NET (Andy Dills) Date: Mon, 31 Jul 2000 17:21:21 -0400 (EDT) Subject: Address block problem In-Reply-To: <200007311831.LAA00950@roo.greatbasin.net> Message-ID: On Mon, 31 Jul 2000, Bruce Robertson wrote: > It was my understanding that 216.82.160.0/19 was reserved for our future > expansion past the end of 216.82.128.0/19. I find that this block has > been assigned to someone else. Why was this allowed to happen without > any notification? > > Once again I find that I am penalized for being frugal with IP addresses. All > of the ARIN policies are such that people who waste IP addresses are > rewarded for that behavior, and people who manage to slow their address > consumption to almost zero are penalized. On top of that, this action just > added to fragmentation, since when I need another /19, it will now no longer > be contiguous with an existing block. While I'm happy to note that my contiguous /19 is still available for me to grab (which will be happening pretty soon), I fail to see what the big deal is. What does having the contiguous /19 really get you? I mean, 7 times out of 10 there will be two routes for the given CIDR block...different prefix lengths for managing inbound traffic, multi-homed customers, etc. So number of routes isn't a large consideration, at least to me. Is it just an annoyance thing? Andy xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Andy Dills 301-682-9972 Xecunet, LLC www.xecu.net xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Dialup * Webhosting * E-Commerce * High-Speed Access From bruce at greatbasin.net Mon Jul 31 17:43:22 2000 From: bruce at greatbasin.net (Bruce Robertson) Date: Mon, 31 Jul 2000 14:43:22 -0700 Subject: Address block problem In-Reply-To: Message from Andy Dills of "Mon, 31 Jul 2000 17:21:21 EDT." Message-ID: <200007312143.OAA01210@roo.greatbasin.net> > I mean, 7 times out of 10 there will be two routes for the given CIDR > block...different prefix lengths for managing inbound traffic, multi-homed > customers, etc. So number of routes isn't a large consideration, at least > to me. Hmmm, I must be one of the 3 out of 10... I would never use anything but a single advertisement for the entire block. All of my inbound traffic is considered equivalent, and I force my multihomed customers to get their own address space. > Is it just an annoyance thing? Mostly, yes. -- Bruce Robertson, President/CEO +1-775-348-7299 Great Basin Internet Services, Inc. fax: +1-775-348-9412 For PGP key: finger bruce at greatbasin.net From andy at XECU.NET Mon Jul 31 18:06:46 2000 From: andy at XECU.NET (Andy Dills) Date: Mon, 31 Jul 2000 18:06:46 -0400 (EDT) Subject: Address block problem In-Reply-To: <200007312143.OAA01210@roo.greatbasin.net> Message-ID: On Mon, 31 Jul 2000, Bruce Robertson wrote: > > I mean, 7 times out of 10 there will be two routes for the given CIDR > > block...different prefix lengths for managing inbound traffic, multi-homed > > customers, etc. So number of routes isn't a large consideration, at least > > to me. > > Hmmm, I must be one of the 3 out of 10... I would never use anything but > a single advertisement for the entire block. Here's an example of why one would do this: we have transit with UUnet and Abovenet. We service some customers from our colo'ed pop at Abovenet. Thus, I announce an additional /22 to get traffic to return directly to our customers via Abovenet, instead of UUnet-us-Abovenet. BTW, my 7 out of 10 figure was wildly OOMA. I just remember seeing the number of needless routes leaked by UUnet (over 200), and at that point I realized that as long as all of my routes have a purpose, things will be ok. You need 128MB to reliably take 2 full views nowadays anyhow... > All of my inbound traffic is considered equivalent, and I force my > multihomed customers to get their own address space. Why do you force multihomed customers to get their own address space? You need to be using 8 /24's to get PI space. None of my multihomed customers come anywhere near qualifying. De-aggregate routes are not an implication of sloppy routing, but sloppy routing will often utilize de-aggregate routes. > > Is it just an annoyance thing? > > Mostly, yes. That's cool, I can feel for you. I certainly can imagine that finding out this information would put a sour note onto the end of your day... Andy xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Andy Dills 301-682-9972 Xecunet, LLC www.xecu.net xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Dialup * Webhosting * E-Commerce * High-Speed Access From bruce at greatbasin.net Mon Jul 31 18:19:51 2000 From: bruce at greatbasin.net (Bruce Robertson) Date: Mon, 31 Jul 2000 15:19:51 -0700 Subject: Address block problem In-Reply-To: Message from Andy Dills of "Mon, 31 Jul 2000 18:06:46 EDT." Message-ID: <200007312219.PAA01251@roo.greatbasin.net> > Why do you force multihomed customers to get their own address space? You > need to be using 8 /24's to get PI space. None of my multihomed customers > come anywhere near qualifying. Hmmm... mine do. A couple have single /24s from the swamp that I'm advertising under protest, but the rest have large blocks. -- Bruce Robertson, President/CEO +1-775-348-7299 Great Basin Internet Services, Inc. fax: +1-775-348-9412 For PGP key: finger bruce at greatbasin.net From hostmaster at verant.com Mon Jul 31 18:34:30 2000 From: hostmaster at verant.com (Hostmaster, Verant) Date: Mon, 31 Jul 2000 15:34:30 -0700 Subject: Address block problem Message-ID: <51EC05AE2DD6D111A0CF00805F6F410B01CFC01C@mail-la.station.sony.com> Yeah, /24's are fine as long as you're not a recent recipient of address space, like us. We have a block from the 64.0.0.0/8 space, but we can't advertise /24's out of that block because some stick-in-the-mud ISPs out there still consider them from the "class A" address space, and filter them out. ---- Dani Roisman Verant Interactive hostmaster at verant.com > -----Original Message----- > From: Bruce Robertson [SMTP:bruce at greatbasin.net] > Sent: Monday, July 31, 00 3:20 PM > To: Andy Dills > Cc: arin-discuss at arin.net > Subject: Re: Address block problem > > > Why do you force multihomed customers to get their own address space? > You > > need to be using 8 /24's to get PI space. None of my multihomed > customers > > come anywhere near qualifying. > > Hmmm... mine do. A couple have single /24s from the swamp that I'm > advertising under protest, but the rest have large blocks. > > -- > Bruce Robertson, President/CEO > +1-775-348-7299 > Great Basin Internet Services, Inc. fax: +1-775-348-9412 > For PGP key: finger bruce at greatbasin.net > From mury at goldengate.net Mon Jul 31 18:40:07 2000 From: mury at goldengate.net (Mury) Date: Mon, 31 Jul 2000 17:40:07 -0500 (CDT) Subject: Address block problem In-Reply-To: Message-ID: I'll tell you why it's annoying. If you are managing multiple routers and multiple IP blocks every time you have to make a global change (for example in an access-list) it just gets to be that much more work. I know there are a ton of ISPs that do not filter traffic, and I don't want to get into a discussion on why you should or should not filter traffic. The point is there are a lot of ISPs and many more companys that do filter traffic on their core routers. If I need to make a change to my access-lists in general it causes my list to be a multiple of however many blocks I have longer than it needs to be. And for the person who is going to say just do a "permit any", that doesn't work because I do have one small chunk that I treat differently, even at the core. Everything is more difficult to manage. You have to put more blocks into your network statements. You have that many more blocks to change contact info for, and I for one have never found dealing with Arin's contact info templates the easiest thing in the world. You have more lines for sendmail to check through to allow or deny mail relay. The examples could go on for quite awhile. No, it's not going to cost me $10K more money to deal with it, but it is a pain. And to Bruce, I was told by Arin that they no longer do any block reservations. And if someone else out there is able to reserve IP space, and I wasn't able to, I'm going to be incredibly unhappy with Arin. I don't think any court of law would take kindly to them playing favorites. Mury GoldenGate Internet Services On Mon, 31 Jul 2000, Andy Dills wrote: > On Mon, 31 Jul 2000, Bruce Robertson wrote: > > > It was my understanding that 216.82.160.0/19 was reserved for our future > > expansion past the end of 216.82.128.0/19. I find that this block has > > been assigned to someone else. Why was this allowed to happen without > > any notification? > > > > Once again I find that I am penalized for being frugal with IP addresses. All > > of the ARIN policies are such that people who waste IP addresses are > > rewarded for that behavior, and people who manage to slow their address > > consumption to almost zero are penalized. On top of that, this action just > > added to fragmentation, since when I need another /19, it will now no longer > > be contiguous with an existing block. > > While I'm happy to note that my contiguous /19 is still available for me > to grab (which will be happening pretty soon), I fail to see what > the big deal is. > > What does having the contiguous /19 really get you? > > I mean, 7 times out of 10 there will be two routes for the given CIDR > block...different prefix lengths for managing inbound traffic, multi-homed > customers, etc. So number of routes isn't a large consideration, at least > to me. > > Is it just an annoyance thing? > > Andy > > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > Andy Dills 301-682-9972 > Xecunet, LLC www.xecu.net > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > Dialup * Webhosting * E-Commerce * High-Speed Access > From horman at novell.com Mon Jul 31 18:57:53 2000 From: horman at novell.com (Hilarie Orman) Date: Mon, 31 Jul 2000 16:57:53 -0600 Subject: Address block problem Message-ID: ARIN policies are based, in large part, on the principle of avoiding fragmentation. The question is, what led to the expectation of reserved space for the block in question, did the holder of it meet the conditions for holding the space? There's no secrecy about the policies, so it should be easy to resolve the question. Hilarie Orman ARIN AC