May 1998 - Test - lists.nanog.org

Re: The Great Exchange
by Vadim Antonov 01 Jun '98

01 Jun '98

Deepak Jain <deepak(a)ai.net> wrote: > Since most of this distance stuff is being calculated by IP address or ASN, > why wouldn't the edge routers have SRC IP, DST IP, and "MY IP." And why > couldn't a collector make any other adjustments necessary? Neither ASNs nor network prefixes (particularly aggregated prefixes) correspond to geographical locales. To evaluate cost of end-to-end transmission one has to collect information about state of the things along the path. That information is typically totally unavailable to end-nodes and only partially available to backbones. >> Distance-insensitive per-bit charging is certainly feasible and >> is being practiced by some ISPs (typically as "burstable" T-1 >> or T-3 service). >> >> In fact, even those charges aren't likely to stand against close legal >> scrunity. Example of a scenario of a rationale for action against >> ISP X - they count received and transmitted packets on a user link. >> Unfortunalely, they also count packets they didn't deliver due >> to some packet loss in their backbone. Bingo - they charge >> customers for service not provided. This is fraud, pure and simple. >> Sorry if i gave the idea to lawyers... > A lot of people like the word fraud. I am not sure many ISP contracts > guarantee delivery of packets to their final destination, but most seem > to say that the burstable rate is based on how many packets enter your > connection port, or "enter the ISP's backbone." Even service level > agreements are generally based on link loss to the customer and not > end-to-end backbone loss. There's such thing as implied contract. Delivery of packets to destination is a primary venue of business for ISPs, and they are reasonably expected to carry it on. When you provide flat-rate pricing it is understood that some of them won't be delivered, and customers won't be charged more for retransmission. On the other hand, when you explicitly bill for all packets, and then fail to carry on your service and then proceed to bill for a service not provided you've got a problem. I didn't see a contract language yet which would explicitly and clearly state that customers will be charged for arbitrarily high percentage of non-delivered packets. It's like a food store which sells boxes of some stuff, and some of those are empty - but you have to pay for each one and cannot return the bad ones, and have no way of knowing what your odds are. It may be legal, but not in US. --vadim

3 2

Re: Why does Sprint have address filters again?
by Sean Donelan 31 May '98

31 May '98

>5. One is financed by the government out of your taxes and is merely an >accounting formality much like a customer ID number. The other is funded >by a corporation that has no government funding and must support itself >not unlike most businesses and the number is a critical infrastructure >identifier something like an NPA-NXX. Technically, the USF is an industry-funded fund (sic? redundant). The SLC is an independent not-for-profit entity (gosh sounds like ARIN). The Universal Service Administrative Company, a subsidary of NECA collects the USF fees and distributes them to the various funds. The money does not come from the US Treasury, nor even 'taxpayers.' The USF money comes from subscribers of interstate telecommunications services, much like the money for ARIN comes from the subscribers of IP addresses and AS numbers. I couldn't find a budget on the ARIN website; but I wouldn't be pointing to the SLC as an example of a well-run organization. Even ARIN at its worst doesn't match the SLC for insanity. (Yes, Kim that was a compliment). Maybe if the president of ARIN was paid $300,000/year like the president of the SLC, things would be different. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

4 3

Why does Sprint have address filters again?
by Sean Donelan 31 May '98

31 May '98

For some unknown reason, although IHETS has been allocated the entire traditional class B 165.138.0.0, they are announcing it as a partial 165.138.0.0/20. They could announce the entire /16. But they've chosen not too. If IHETS wants to ensure they can reach as much as the Internet as possible, they could follow Sprint's filtering policy, and announce their network as a 165.138.0.0/16. IHET could check http://www.sprint.net/filter.htm for a description of the policy. Since IHETS seems to be a SPRINT customer, I sure would appreciate it if the SPRINT NOC could explain to IHETS why such address filters exist, and if Sprint thinks its a good idea to apply them to other ISPs, why the reciprocal argument would also be true. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

16 40

2q98 in-addr walk starting soon
by Bill Manning 30 May '98

30 May '98

Hi, I appologize for duplicates. Its almost time for the next quarterly walk of the inverse tree of the DNS. For the last few quarters, I've been walking the in-addr tree looking for numbers of delegations, accurate delegations, and types and styles of error conditions. So... this is a heads up that you will be seeing zone transfers being generated by a couple of the collecter machines here. For those of you who utilize BINDs access controls, I'd appreciate your inclusion of the collector machines in allowed transfers. The expectation is that they will be the following IP addresses: 128.9.160.57 and 198.32.4.13 If there are any questions or concerns, I'd be happy to talk about them. Past data has been presented at IEPG, Apricot and RIPE meetings. The expectation is that future data will be presented in the same and similar forums. --bill

1 0

RE: ingress filtering
by John Fraizer 30 May '98

30 May '98

>>Might I recommend that you actually drag out a packet sniffer and look at a >>REAL network to see it for yourself? We all know that MS of ALL companies >>believes that RFC means Request For Compliance and since it's only a >>request and not a mandate, they often opt NOT to conform to standard. >> > >Packet sniffer shows no NetBIOS over IP traffic at all. Sorry. Try again. You must have a lame sniffer. I show encapsulated packets with ours just fine. I guess it could be the silly operator and not the silly sniffer that has the problem though. >The packet sniffer shows nothing wrt port 137. I admit when I'm wrong, but >since I'm not, I won't > >Have a nice day. Will do. Please give me directions to Utopia though. Since you live there and don't see any netbios traffic with your sniffer, I would like to vacation there. ------- 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

The Great Exchange
by Pickett, David 30 May '98

30 May '98

It's evident, from reading through all of the responses to my questions on exchange of Internet traffic, that there are a lot of problems in this space, but not a lot of agreement on how to address them. Here are some summary observations based on group-wide communication, and notes sent to me directly. 1) More needs to be done to leverage locality of traffic Some great examples were given wherein simple cross-state connections were accomplished via an exchange point some one thousand miles away, a clearly sub-optimal arrangement. Fixing this problem was a point of some contention. Some said to forget about national exchange points, and just make private peering arrangements. Others noted that local exchange points are springing up in the areas that need them. Often these exchange points are the product of local ISPs working cooperatively, sometimes with the assistance of a corporate sponsor. Still others noted some commercial enterprises that are building an infrastructure and business model around the need for decent peering arrangements. To add complexity to this issue, differences arose over implementation details of a national peering system that preserved locality of traffic. Some advocated a hierarchical model, tiered if you will, that frankly sounded a lot like 5-level PSTN switching model. Others advocated a flatter model, although how that model relieves traffic at the core, and leverages locality remains to be seen. 2) Who dropped the packet? You can't fit 20 gallons of water in a ten gallon hat, at least not all at once. Oversubscription generated some heated comments from various factions. It is clear that one person's oversubscription is another person's unethical business practice. So, just how do we handle the delicate topic of oversubscription? Where is it okay to oversubscribe? Where can it absolutely not be tolerated? Oversubscription is fundamental to the design of many network switches, and is an essential aspect of many network technologies, and business plans. It's here. It's reality. How does one use it responsibly? A lot of finger pointing was done in the area of highly asymmetric and grossly underprovisioned connections to the Internet. What policies might mitigate such problems? Thoughts? 3) Internet SLAs and customer verification There was a modest amount of chest beating around verifiable levels of service. Nobody came right out and proposed Internet SLAs, but some did suggest that it would be nice to give the customer the tools for verifying the level of performance delivered by their access provider. This is an interesting angle, and we've seen evidence in the industry of some providers giving the customer limited ability to access this kind of information. NDAs seems to be at the heart of this problem. What tools do the ISPs need to provide this kind of information to the customer? Do the ISPs even want to provide this information? Is it pointless to provide this information since so much of the customer's total performance picture is dependent on factors that can't be controlled by the ISP? dp David R. Pickett Northchurch Communications Inc 5 Corporate Drive Andover, MA 01810 978-691-4649

13 14

More smurf networks. FIX YOUR ROUTERS.
by Dalvenjah FoxFire 30 May '98

30 May '98

Hi folks, I found a small list of smurf relays in a hacked account today and managed to mail all those folks privately asking that they fix their routers. I was reasonably proud of myself. Then I found this list, full of 175 different networks. Nearly all the ones I tried work, and the ones that didn't work didn't respond on other IPs either, so I'm assuming unreachability. This is a fresh list from an active smurfer, however, so it does work. (Boy, does it work. }:P ) Since it would take me upwards of two weeks just to mail these folks - unless I put off work, school, and the like - I determined it would be much better to post the list to nanog and see what doesn't work after a few weeks. (Translation: there is no way in hell I'm mailing all these folks, not even with a script to try and parse all the internic/apnic/ whatever whois outputs.) Yes, I realize this means that The Scum will start smurfing like crazy; however, this also means that those networks will get fixed quicker when they realize their outbound link is completely saturated with ECHO_REPLY. Please pass this around, call folks you know, call folks you don't know, do whatever it takes to get these folks to fix their routers. I have spent the past week dealing with various smurfs taking down ISPs, and I am getting extremely sick of it. (Note, if you're fixed, and you're on this list, I apologize; again, I don't have the time to check each and every address.) -dalvenjah 141.161.19.0 141.164.240.0 142.3.0.0 168.198.79.255 168.208.21.255 168.216.14.255 168.84.3.255 168.84.7.255 193.190.1.255 193.190.10.255 193.190.4.255 193.190.8.255 193.190.9.255 193.226.100.255 193.38.83.255 193.38.84.255 193.38.85.255 193.64.68.255 193.76.0.255 194.111.55.255 194.152.36.255 194.215.85.255 194.251.75.255 194.28.6.255 199.171.110.255 199.171.198.255 200.0.166.255 200.19.104.255 200.23.51.255 200.230.142.255 200.230.143.255 200.38.168.255 200.5.128.255 200.5.129.255 202.184.18.255 202.184.25.255 202.45.53.255 202.45.59.255 202.45.61.255 203.108.227.255 203.11.118.255 203.150.240.255 203.22.70.255 203.64.170.255 204.101.117.255 204.115.171.255 204.116.248.255 204.141.218.255 204.147.235.255 204.155.99.255 204.161.118.255 204.161.61.255 204.166.161.255 204.166.161.255 204.167.48.255 204.17.178.255 204.171.179.255 204.177.145.255 204.187.84.255 204.191.160.255 204.191.212.255 204.199.101.255 204.199.102.255 204.199.106.255 204.199.107.255 204.208.154.255 204.208.155.255 204.216.139.255 204.216.139.255 204.216.86.255 204.222.194.255 204.222.195.255 204.228.161.255 204.229.220.255 204.229.221.255 204.229.222.255 204.229.43.255 204.229.45.255 204.233.137.255 204.235.79.255 204.235.79.255 204.242.172.255 204.242.172.255 204.244.155.255 204.249.16.255 204.249.16.255 204.26.102.255 204.26.102.255 204.26.103.255 204.26.104.255 204.26.109.255 204.29.160.255 204.29.160.255 204.30.35.255 204.30.35.255 204.31.135.255 204.31.137.255 204.31.137.255 204.33.249.255 204.34.141.255 204.34.141.255 204.64.182.255 204.64.22.255 204.71.176.255 204.71.179.255 204.71.179.255 204.71.180.255 204.71.180.255 204.71.191.255 204.71.243.255 204.80.124.255 204.96.225.255 205.136.165.255 205.148.1.255 205.172.3.255 205.178.8.255 205.184.109.255 205.197.176.255 205.203.72.255 205.211.168.255 205.218.18.255 205.232.119.255 205.232.191.255 205.232.8.255 205.252.144.255 205.67.128.255 206.110.105.255 206.129.95.255 206.170.24.255 206.186.126.255 206.204.56.255 206.219.101.255 206.219.102.255 206.31.88.255 206.39.100.255 206.39.101.255 206.39.72.255 206.39.75.255 206.39.76.255 206.39.77.255 206.39.78.255 206.39.79.255 206.39.81.255 206.39.91.255 206.39.92.255 206.39.93.255 206.39.98.255 206.39.99.255 206.72.47.255 207.65.122.255 208.128.161.255 208.128.185.255 208.132.236.255 208.132.69.255 208.145.80.255 208.154.16.255 208.154.18.255 208.154.23.255 208.193.238.255 208.20.149.255 208.202.212.255 208.24.87.255 209.160.26.255 209.206.19.255 209.206.21.255 209.206.22.255 209.49.157.255 209.63.185.255 209.66.101.255 209.7.76.255 209.81.151.255 209.84.61.255 209.88.144.255 -- Dalvenjah FoxFire (aka Sven Nielsen) Fundamentalist Agnostic: "I don't Founder, the DALnet IRC Network know, and neither do you!" e-mail: dalvenjah(a)dal.net WWW: http://www.dal.net/~dalvenjah/ whois: SN90 Try DALnet! http://www.dal.net/

7 6

INTERNIC Question
by Al Reuben 29 May '98

29 May '98

I've got a quickie, and I am not sure where to ask it. I am in the process of writing a domain-name registration tracking system, and I want to put some stuff in the Headers so that I can add our internal tracking numbers on it so that when we get a response, I can have a process look it over and decide what do do with it. In specific, I put X-NAC-DTS-Number: [a alex-generated number] in the header, and it didn't get returned. So, my questions are: 1) Should the Internic be retaining this X Headers? 2) Why can't the Internet put interesting things in the header so that we could unifiy the way we look at them to automatically process them? Like: X-Internic-Response: Registered or X-Internic-Response: Not-Registered-Already-taken etc? Comments welcome. -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Atheism is a non-prophet organization. I route, therefore I am. Alex Rubenstein, alex(a)nac.net, KC2BUO, ISP/C Charter Member Father of the Network and Head Bottle-Washer Net Access Corporation, 9 Mt. Pleasant Tpk., Denville, NJ 07834 Don't choose a spineless ISP! We have more backbone! http://www.nac.net -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

11 11

Re: The Great Exchange
by shields＠crosslink.net 29 May '98

29 May '98

In article <19980528100840.19859(a)scfn.thpl.lib.fl.us>, "Jay R. Ashworth" <jra(a)scfn.thpl.lib.fl.us> wrote: > On Wed, May 27, 1998 at 10:34:18PM +0000, Michael Shields wrote: [...] > > Why are you assuming that the Internet will continue to have > > non-distance-sensitive pricing, when it clearly has distance- > > sensitive costs (ultimately)? > > Because that has been the primary driver to date of the kind of growth > the Internet has undergone. Mature markets and new markets behave differently. $19.95 unlimited dialup was a big factor in 1995 and much less so now. > That it has distance sensitive costs only > matters if you're trying to be a nationwide ultra-backbone. Actually I was thinking about international ultrabackbones. I don't see any theory or evidence that they are going away or being marginalized. You will always have to deal with them. It's in their interest to be sure that the pricing is fair. I think pricing based on the actual destination makeup of your traffic is more fair than pricing based on the assumption that your traffic is like everyone else's. I could be wrong, and I'd be happy to be shown why. But I think distance-pricing has a sound basis, even if it never materializes in the market. The major reason I see that it might not happen is that customers would tend to remain fairly similar to each other in terms of their locality; just as when customers have similar bandwidth usage, circuits tend to be sold unmetered. If I were an Australian ISP, I'd look very seriously at pricing transoceanic packets different from intracontinental packets. From what I understand the market there would be accepting; and unless there is a flaw in the reasoning of my message yesterday, you can collect that data cheaply with today's technology. > and the "big 5" would be _really_ pissed off. Good. You think ultrabackbones are doomed? Why? -- Shields, CrossLink.

3 3

RE: Cable & Wireless buys MCI Internet
by Goldstein_William＠bns.att.com 29 May '98

29 May '98

1 0