May 1998 - Test - lists.nanog.org

Re: The Great Exchange
by Hal Murray 29 May '98

29 May '98

> In short, I see no economic basis for such metering, and no moves > towards such metering. Maybe I'm wrong, but I doubt that we're going > to see any change in this any time soon. There is another reason why some people don't like metering - it makes predicting costs much more difficult. Imagine your local library or university dept trying to budget for internet access. I think I saw a comment that half the cost of a long distance call was collecting the data and processing the billing. Can anybody verify that? > I think it's a North American view of the world, unsurprising on NANOG > :-) Traffic metering is the dominant charging mechanism for permanent > connections in Oz and Connect differentiate traffic based on its > source (domestic/cache/external). How much trouble is it to collect the billing data? What are the relative rates for domestic/cache/external?

2 1

Re: ingress filtering
by shields＠crosslink.net 29 May '98

29 May '98

In article <19980528145744.B1561(a)puck.nether.net>, Jared Mauch <jared(a)puck.nether.net> wrote: > The great thing about the CC images released by cisco > (as long as you're running with ip cef or ip cef dist), you can turn > this neato command on your interfaces to your customers: > > ip verify unicast reverse-path It is neato, but be careful not to turn it on without CEF or it will silently drop all packets on the interface. Just a tip. Not that I did that or anything. -- Shields, CrossLink.

1 0

Re: PC Bozo's World bites again (CNN, too)
by Vern Paxson 29 May '98

29 May '98

> Has anyone done an analysis of how having a smaller MTU affects > slow-start? It seems to me that a TCP session would come up to speed > about 3 times faster with a mtu of ~500 vs a mtu of ~1500. It doesn't, because the smaller MTU doesn't mean you get more acks per unit time, just that you get more acks overall. So you still get the same slow start increase pattern, only your segments are 1/3 the size they could be, so your data rate is 1/3 what it could otherwise be (until cwnd is big enough to consume the available bandwidth). The improved-performance-with-low-MTU is a puzzle I'd certainly like to understand better. It seems step 1 is to eliminate the possibility that the 1500 MTU is leading to fragmentation. Vern

1 0

Re: PC Bozo's World bites again (CNN, too)
by Darrell Fuhriman 29 May '98

29 May '98

Michael Dillon <michael(a)memra.com> writes: > I don't think so. They even said in their article that the technical > details are based upon this URL > http://www.sns-access.com/%7Enetpro/maxmtu.htm > and this guy says stuff like: > > And, it turns out, depending on how your ISP and other routers > encountered on the Internet handle your TCP/IP requests, that a MaxMTU > setting of 576, often referred to as the "Internet Standard", will in > many cases avoid the fragmentation of packets of data and the slow > transfer speeds which result. He used to be one of my users, at two different ISPs, in fact. I had a long drawn out disagreement about how this was wrong, and mathematically didn't make any sense. However, lots of people have confirmed that it really does help... which leads me to accept Karl's explanation. We shouldn't expect anymore from microsoft, really. Darrell

3 2

Re: 165.138.0.0
by Sean Donelan 28 May '98

28 May '98

>I got two nice replies from Sprint. They won't change their filtering >policy overnight but they are at least considering it. I think they're >interested in listening to customers on the issue, but please don't spamm >or rant......hey if they do change it I might resubscribe to nanog :) >I removed their email addresses because they didn't post it to nanog. I got almost an identical message from Sprint last year when this issue came up with another sprint customer. I think you are correct in one aspect, they won't change their filtering policy overnight. Individually, most sprint employees are always nice. Collectively as a corporation, they seem to have tremendous difficulty moving from the 'considering it' stage to the 'do something' stage. I'm in Missouri, the Show-Me state. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

RE: 165.138.0.0
by Sean Donelan 28 May '98

28 May '98

>Sean, when I look at a full BGP table from MCI/Sprint/UUnet/and ANS I see >a lot of /16 - /24's on the 12.0.0.0 (which also has a /8), 24.0.0.0 >(which has no /8), 53.0.0.0, 62.0.0.0, etc.....Some of these have the >classic /8 covering them and some don't. It's the same story for >several /16's (class b networks) I see 132.155.204.0/23 (without a /16 >anywhere), 134.128.52.0/24 (without a /16). Do you have problems >getting to all of these? The filters I use have existed for several years. I make lots of exceptions for networks which supply at least an interesting reason for doing it. We ask the person to contact their upstream NOC, and for most providers work something out quickly. There is one, and only one reason I won't make an exception. When someone says the policy doesn't apply to them because they are a sprint customer. After that happens they are directed to call the Sprint NOC for assistance. It would be nice if sprint accepted trouble reports directly from non-customers, then it would not be necessary to broadcast general appeals for help on lists like nanog. But when the Sprint network declines to contact the sprint NOC for assistance, it simply delays the whole problem resolution process. I'm sorry you had difficulty doing this. Contacting the Sprint NOC should put you in touch with someone to help you come up with a useful routing policy that meets the conditions Sprint says are good rules for controlling the growth of the global routing table. After all you are paying sprint, not me. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

ARIN Advisory Council recommendations I have made
by Karl Denninger 28 May '98

28 May '98

As promised, here is my list of agenda items I believe are important for ARIN to "fix" within the immediate timeframe. All of these have been previously posted to the Advisory Council mailing list by myself. This is on the general topic of governance and transparency. My next message will be my repost on the topics of operational policy (ie: who can get PI address space, what justification is required, etc). I am expanding the discussion list to NANOG and the ARIN Members mailing lists. Please post comments PUBLICALLY, or if you feel you cannot do so without "cloaking" yourself, through someone else (who you trust to strip the attribution). High Level TOPIC #1 - Governance of ARIN ======================================== 1. Modification of the bylaws to provide for removal of trustees and officers by vote of the membership (currently lacking). I would like to recommend that the AC be required to carry a motion to be put to the membership for such an action, which then requires a vote by the membership within 30 days. Majority consent of the membership constitutes removal. (The "AC filter" is there to prevent someone from "buying" the membership - by getting 50 memberships, for example, and then using that to "take over" the board). 2. Modification of the bylaws to provide for the removal of AC members by direct membership vote. Procedure to be a majority consensus of the membership, initiated by the members directly. A simple majority of all members may remove an AC member by vote through this procedure. 3. The motion currently on the table from the last BoT meeting to give Kim Hubbard a vote as a Trustee should be, IMHO, defeated. This repairs the complete lack of accountability currently present in the bylaws. It is currently impossible for the members or the AC to remove a trustee or officer of the corporation; this is contrary to any other corporation I have ever worked for; the shareholders (who are, in this case, the membership - since the members fund the operation) always have the right to remove the board and, indirectly, the officers (by firing the board and replacing it). High Level Topic #2 - Accountability of Decisions made by ARIN ============================================================== 1. Modification of the bylaws to provide that the following acts are reportable to the public via web dissemination: a. All "executive decisions" made by ARIN's President and Board of Trustees outside of a regular meeting which affect one or more person(s) or organization(s). Exempt are statuatory privileged decisions (ie: employment related issues) ONLY. b. All "ex officio" actions taken by the Board of Trustees, including Board approval of any action taken or contemplated by a corporate officer. c. All ARIN Board and AC meeting minutes must be published within 7 days of the meeting or other administrative action which took place. d. (a) through (c) are retroactive to the formation of ARIN, and all documentation related to same are to be produced within 7 days following passage. 2. Modification of the bylaws to provide that the following items are considered to be publically reportable in the performance of ARIN's duties as a public trustee: a. All incoming address allocation requests. b. All document production requests made by ARIN persuant to (a), identifying the type of request, the time given for response, the scope and purpose of the request. c. The outcome of the allocation request, whether granted or turned down. d. An accounting of the amount of manpower used in processing the request (calculated in man/hours). (a) through (d) are to be reported within 7 days of closure of each request, and ARIN should produce a report weekly showing the number of requests currently in queue, new arrivals during that period, and dispositions. e. All actions taken by ARIN, its officers, staff members, or any individual under color of authority of ARIN in an attempt to reclaim, repossess, or interfere in any way with the peaceful enjoyment of address space held by entities which were granted prior to the adoption of RFC2008 (October 1996). These changes will fix the transparency problems which I believe exist today within the structure of ARIN. You have the other two (the address allocation policy changes and pricing changes) as well. Would you like me to write these up formally? -- -- Karl Denninger (karl(a)MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost

2 1

First proposal - all who need space get it (fwd)
by Karl Denninger 28 May '98

28 May '98

This was proposal number one for OPERATIONAL changes to ARIN's functional allocation policies. Note that this gets us to an objective, neutrally-verified criteria that allows, IMHO, all organizations with a legitimate use for PI space to have it. I am expanding the discussion list to NANOG and the ARIN Members mailing lists. Please post comments PUBLICALLY, or if you feel you cannot do so without "cloaking" yourself, through someone else (who you trust to strip the attribution). FIRST PROPOSAL: 1) The allocation policy of ARIN should be changed to reflect that any organization which can demonstrate that it can constructively use PI space should be able to receive it. "Constructively demonstrate" is stated to mean: a) The organization is multi-homed, possesses an ASN, and two or more independant T1-or-above rate connections to more than one backbone or other carrier (ie: to an exchange, to a NSP, to other ISPs). Documentation in the form of a signed connectivity agreement for a period of at least one year, or connectivity provable via existing network tools (ie: treno) is sufficient to satisfy this requirement. b) The ASN is visible at industry-accepted peering points and shows multiple paths available (ie: "nitrous.digex.net") c) The organization is EITHER: 1) Engaged in the business of selling connectivity to the general public, or can otherwise document a REASONABLE expectation that at least 75% of the /19 will be fully utilized at some point in the future during the expected lifetime of the IPv4 space (defined as 10 years). The firm must be able to prove this without resorting to a claim of confidentiality; in other words, you must be able to show that you're in the business of doing this from your public, visible, documentable actions. OR 2) The firm contains enough employees, staff members, and EXTERNALLY ADDRESSABLE infrastructure equipment within its boundaries to qualify for efficient use of a /19 on its own (ie: more than 5,000 staff members). 2) To receive MORE space, regardless of the size of the organization, the requestor must document that more than <X>% of the existing space allocated to it is either; a) In use internally; OR b) Delegated to actively visible customers who actually use said IP address space. An IP address shall be deemed to be "constuctively used" if any of the following apply to it at the /32 level: a) It responds to a PING or other network packet addressed to it when queried. b) It is properly referenced in both forward and reverse DNS files, and the hostname is traceable and billable to a customer who has ongoing revenue associated with same. (ie: an ISDN connectivity provider sells a class of service which has a /29 associated with it; they generate hostnames for all 8 addresses, and the customer is routed behind those addresses). c) It is a member of a operational DCHP or other dynamic pool, and is properly referenced in both forward and reverse DNS maps. d) It is delegated to a dedicated circuit or other routed business customer, and is part of a block of no more than 64 addresses assigned to that customer. Network broadcast addresses (defined as "all ones" host components) are excluded from these requirements, as are "all zeros", since some equipment demands that the "zeros" address remain). The value for "X%" shall be set by discussion within the AC and ratified by vote. All organizations must prove up use in all blocks delegated to or through them in order to receive any further delegation of space. I recommend that the value of "X" be set somewhere between 50 and 70%. This provides for some "slop", particularly in dedicated circuit customer situations (which are going to have some slop). However, it also prevents the practice of assigning a /24 to a customer who has five computers in their office - a practice which is extremely common! 3) A delegate producing documentation for classes of service (a - c) above may not claim privilege for these classes of information, as such is discernable from an external connection. 4) A delegate producing documentation for classes of service (d) may claim privilege as to the identities of the organizations involved, and may redact that information from their submissions, however, the actual allocations themselves must be documented. 5) All submitted documentation and prove-up performed under these policies are public information and subject to challenge by any member of the Internet community. -- -- Karl Denninger (karl(a)MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost

1 0

None
by John Fraizer 28 May '98

28 May '98

------- John Fraizer (root) | __ _ | The System Administrator | / / (_)__ __ ____ __ | The choice mailto:root@EnterZone.Net | / /__/ / _ \/ // /\ \/ / | of a GNU http://www.EnterZone.Net/ | /____/_/_//_/\_,_/ /_/\_\ | Generation A 486 is a terrible thing to waste...

1 0

Re: ingress filtering
by prue＠ISI.EDU 28 May '98

28 May '98

>Who *does* do ingress filtering? I have it on our border routers >and customer connect ports. We have transit from MCI and UUNET. >Neither has ingress filters -- see below message from MCI on >this. I have dealt with this in a different way. I have been figuring out interesting things to do with netflow data for a while now. I recently debugged a program which uses a file which has what looks like access lists associated with particular ports on my 7500's. The program then looks at the netflow data and dumps any record which is explicily denyed or implicitely denyed (implied deny any at end, like Cisco). It looks at the source addresses, uses the supplied mask and applies it only to the interface(s) in question. So I look at data from our backbone providers and see if there is any data being sent with my networks source address ranges. I look for packets from the backbones destined for x.x.x.255 to look for smurf type attacks. I have it looking at my customers data to make sure that they are only sending from address ranges that I expect and they aren't spoofing data against someone else. The nice thing about this is that it doesn't slow down the router by causing it to do compares on potentially long access lists real time while the data is comming in. I have netflow turned on and I dump the data to my unix host for the analysis. My sun workstation seems to have no problem keeping up with the traffic load. Since most data is legitimate, the workstation doesn't need to dump that much data. For interfaces on my router I have no concern for spoofed data I build no access lists for the netflow analysis program and it just ignores data comming in those interfaces. If I see something particularly henious I can put in an explicit filter to clobber it, in the router when it hits the router. Netflow records are still cut even if I do filter the stuff too. I can then complain to my service provider saying kill that spoof attack comming from your network. Or to my customers I can tell them cut out that spoof attack or I'll have to turn your line down. I can then monitor the progress to see if it has stopped yet. Great stuff and all at no extra work to the router. If there is enough interest I can write up some documentation on it and make it available via ftp. It again is based on the example tools Cisco built to demonstrate netflow capablities like the last tool I posted. Walt Prue Los Nettos

1 0