- NANOG - lists.nanog.org

Re: MAE-West et al.
by howland＠Priss.com 08 Dec '98

08 Dec '98

...or that the MAE has two seperate physical installations, one at NASA Ames, also with full power backup... --------------- > > Any word if the major power problems near San Fransisco are affecting > > MAE-West or any carriers in that area? > > The MAE West facilities are 20 miles or so south of the affected > areas (SF, San Mateo County) so no problems here. Not to mention that there are 4 emergency generators in the building. ---------------

1 0

Re: comments please
by Bill Manning 08 Dec '98

08 Dec '98

> > On Tue, 8 Dec 1998, Bill Manning wrote: > > > 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 are the prefixes called out > > in RFC 1918. They are only for use in private networks that wish to use > > the IP protocols. Network operations and End System administrators should > > ensure that these prefixes is not coded into systems or routed through any > > Internet infrastructure. Since they have the appearance of "normal" prefixes, > > special precautions should be taken to ensure that they are not propagated > > in the Internet. > > What about instances where an I/NSPs extends its use of these addresses to > the customer's boundary router? This becomes epseically important if the > customer happens to have been doing its homework and using RFC1918 > addresses only to find (after signing the contract) that they collide with > the provider's addresses. Who wins in that case? > > Mohamad Eljazzar > EET Data Communications Well, RFC 1918 says these prefixes should not be propogated over the Internet but can be used on/in Intranets. I occasionally find it tough to discriminate between the two ideas. -- --bill

2 1

Re: MAE-West et al.
by Bill Woodcock 08 Dec '98

08 Dec '98

We're seeing power-down on our CPE at about 10% of our SF Bay Area customers, almost all in San Francisco and the upper peninsula, San Mateo, South San Francisco, Burlingame, et cetera. Peak was about 25%, at about 7:30am local time. My understanding was that some parts of Oakland were effected as well, I didn't see any of that directly. We didn't see any problems in teh south bay or south end of the peninsula. -Bill

1 0

Help with identifying a kind of attack.
by Thom Youngblood 08 Dec '98

08 Dec '98

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've been tracking an attack all day long, and have been frustrated trying to figure out both what was being attacked, and how. Finally, I realized it was *not* ICMP, UDP, or TCP. #sh access-lists 151 Extended IP access list 151 permit icmp any 20.0.0.0 0.255.255.255 (1023 matches) permit udp any 20.0.0.0 0.255.255.255 (4347 matches) permit tcp any 20.0.0.0 0.255.255.255 (86444 matches) deny ip any 20.0.0.0 0.255.255.255 (5547308 matches) permit ip any any (4450563 matches) In the above, notice the disparity? So, my question is... What the hell kind of packet is it if it's not ICMP, UDP, or TCP? -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.0 for non-commercial use <http://www.pgp.com> iQA/AwUBNm2jB2fkezbzToVaEQIQQQCgllupf+cmax8w5n/RgYhlATz+BuQAn38r Di2Ec9bI2Prrahm9yKp5rohS =/qOm -----END PGP SIGNATURE-----

6 5

comments please
by Bill Manning 08 Dec '98

08 Dec '98

........................................................................ INTERNET-DRAFT draft-manning-dsua-00.txt Bill Manning ISI November 24, 1998 Documenting Special Use IPv4 Address Blocks Copyright (C) The Internet Society (1998). All Rights Reserved. 1. Status of this Memo This draft, file name draft-manning-dsua-00.txt, is intended to become something that might be of use to those who are interested in the operational requirements of an IPv4 based network. Distribution of this document is unlimited. Comments should be sent to the author. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). This Internet-Draft expires six months from the date of publication in the Internet Drafts directories. 2. PREAMBLE: This document lists the existent special use prefixes from the IPv4 space and provides some suggestions for operational procedures when these prefixes are encountered. This document does not address IPv4 space that is reserved for future delegation in the operational Internet. The current list of special use prefixes: 0.0.0.0/8 127.0.0.0/8 192.0.2.0/24 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 169.254.0.0/16 2.1 Prefix Discussion: 0.0.0.0/8 has a number of unique properties, many of which were built into the protocol stacks used throughout the Internet. 0.0.0.0/32 or the all-zeros address has been used and is still recognized as the historical broadcast address. This use or restriction is depricated and modern code will treat broadcast correctly as an all-ones value within the subnet. Also, many stacks will allow the system administrator to encode IP addresses of the form 0.0.160.57, with the presumption that historical, "natural" masks apply and so this would represent a host that carries the local value of 160.57 within the /16 netblock that is in use on that media. These properties suggest that a prudent network manager & system admin will treat 0.0.0.0/8 as a special use netblock. Router and Host requirements documents and implementations treat this range with special use constraints. 127.0.0.0/8 is earmarked for what is called "loopback". This construct is to allow a node to test/validate its IP stack. Most software only uses a single value from this range, 127.0.0.1/32 for loopback purposes. It is treated with the same levels of restriction by router and host requirements and implementations so it is difficult to use any other addresses within this block for anything other than node specific applications, generally bootstraping. All in all a tremendous waste of IP space. Good thing we'll not likely need it. 192.0.2.0/24 is listed as the TEST-NET. This prefix is earmarked for use in documentation and example code. Network operations and End System administrators should ensure that this prefix is not coded into systems or routed through any infrastructure. Since it has the appearance of a "normal" prefix, special precautions should be taken to ensure that this prefix is not propagated in either the Internet or any private networks that use the IP protocols. Often used in conjunction with example.com or example.net in vendor and protocol documentation. 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 are the prefixes called out in RFC 1918. They are only for use in private networks that wish to use the IP protocols. Network operations and End System administrators should ensure that these prefixes is not coded into systems or routed through any Internet infrastructure. Since they have the appearance of "normal" prefixes, special precautions should be taken to ensure that they are not propagated in the Internet. 169.254.0.0/16 has been ear-marked as the IP range to use for end node autoconfiguration when a DHCP server may not be found. As such, network operations and administrators should be VERY aggressive in ensuring that neither route advertisements nor packet forwarding should occur across any media boundaries. This is true for the Internet as well as any private networks that use the IP protocols. End node administrators should be aware that some vendors will autoconfigure and add this prefix to the nodes forwarding table. This will cause problems with sites that run router discovery or depricated routing protocols such as RIP. As a side note, at least one vendor has hijacked an address range for use by its printservers. That range is 192.0.0.0/24 and the specific address that they use is 192.0.0.192/32. This is not a valid delegation to this vendor and its use argues for reconstitution of this service into the link-local range or configurable with site delegated space. 3. DNS considerations: None of these address prefixes is to be used or visible on the public Internet. In fact, some of these prefixes must not appear outside the machine. To encourage honesty, most of these prefixes have been mapped into the DNS. This encourages people to ensure that when used, these prefixes are coded with local-scope DNS and there will be no "leakage" to the global Internet. 4. Access Control suggestions: In todays network, it is prudent to control access. In the case of these special use prefixes, it is generally a good idea to filter them so they do not propagate. After all, you don't want someone else's use of these prefixes to taint your environment. An example of one form of access control is listed below: ... access-list 100 deny ip host 0.0.0.0 any access-list 100 deny ip 127.0.0.0 0.255.255.255 255.0.0.0 0.255.255.255 access-list 100 deny ip 10.0.0.0 0.255.255.255 255.0.0.0 0.255.255.255 access-list 100 deny ip 172.16.0.0 0.15.255.255 255.240.0.0 0.15.255.255 access-list 100 deny ip 192.168.0.0 0.0.255.255 255.255.0.0 0.0.255.255 access-list 100 deny ip 192.0.2.0 0.0.0.255 255.255.255.0 0.0.0.255 access-list 100 deny ip 169.254.0.0 0.0.255.255 255.255.0.0 0.0.255.255 access-list 100 permit ip any any ... 5. Security Considerations: Use of most of these special use prefixes open up significant opportunities for anonymity and ambiguity. People being what they are, will hide behind ambiguous or nebulous identities to do things that are antisocial and downright hostile. It would be nice to have better authentication methods in play than an IP address which has lost its global uniqueness. 6. References: [DHC-IPV4-AUTOCONFIG] - R. Troll, Automaticly Choosing an IP Address in an Ad-Hoc IPv4 Network, Internet draft, draft-ietf-dhc-ipv4-autoconfig-01.txt, October 1998 [RFC1918] Y. Rekhter et.al., Address Allocation for Private Internets, February 1996, RFC 1918 [RFC1122] R. Braden, Requirements for Internet Hosts -- Communication Layers, October 1989, RFC 1122 [RFC1812] F. Baker, Requirements for IP Version 4 Routers, June 1995, RFC 1812 [RFC2267] P. Ferguson, D. Senie, Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing, January 1998, RFC 2267 [NET-TEST] Netname: IANA, Netnumber: 192.0.2.0, Coordinator: Internet Assigned Numbers Authority, 1993 [LOOPBACK] Netname: LOOPBACK, Netnumber: 127.0.0.0, Coordinator: Internet Assigned Numbers Authority, 1972 [RESERVED-1] Netname RESERVED-1, Netblock: 0.0.0.0 - 0.255.255.255, Coordinator: Internet Assigned Numbers Authority, 1972 7. Copyright Notice This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 8. Author's Address Bill Manning USC/ISI 4676 Admiralty Way, #1001 Marina del Rey, CA. 90292 USA bmanning(a)isi.edu 310.822.1511 -- --bill

1 0

Re: More Sidgemore on per-bit pricing (fwd)
by Pushpendra Mohta 08 Dec '98

08 Dec '98

Folks: While cost of a service and price extended to users dont have to be correlated, it helps to understand what the costs are. The cost of carrying Internet services is very destination and origination specific. Destination/Origination in this context includes the distance traveled which affects the raw cost of transport, but also the specific destination/origination country/region where regulation might affect the cost of doing business. The argument about billing based on destination being very expensive is not entirely true. Whether on not they bill on this data, most any one planning a global IP backbone measures traffic distributions very carefully, not only for network engineering but also to understand the cost of business. The granularity required to bill on this data may have to improve -but it is not a big leap to make. Lot of what pricing you see is a reflection of the fact that large portions of the total IP traffic is within the US. It has also been cheaper for non US ISPs to backhaul to the US and use the US as a hubbing node rather than build in region networks because of the monopoly environments. This has also contributed to the US being the location where the majority of the traffic has been switched. Both of these trends are changing. In this new world, the share of costs so far being borne by non US ISPs and people building global IP backbones will need to be re-examined. Many of the arbitrage based opportunities that build on this "share of cost" or distance insensitive pricing disparity will vanish. The cost models will reflect new global realities. Also, based on the basic wisdom -if the cost of travel is distance sensitive, you try not to travel large distances- people will start paying more attention to elegant content distribution architectures which include caching/mirroring and use of multicast. (Before anyone picks on this, I understand the win on performance is much larger with these techniques than any spectacular bandwidth savings. Because the speed of light is what it is, some of these techniques may be the only way to fill broadband consumer pipes etc.) Finally, as to the other discussion in this thread about flat rate vs metered pricing. If you buy into the basic notion of IP connectivity becoming a commodity service and look for parallels in other industries you find that many of the mature ones are indeed metered usage priced. Many appliances tap into the electricity service in our homes, and we pay for them aggregated roughly on a metered basis. Within physical limits, one can use all one wants .. i.e the electricity service has a "burstable" component. Even the postal service offers a flat rate (hence the term "postalized rates") within a region and a different one for inter-region packages. This is further modulated by the cost of small packages vs big packages that have different service costs. Why does then paying for many "information appliances" that tap into an "IP service pipe" in a similar fashion seem so outlandish ? --pushpendra Pushpendra Mohta pushp(a)cerf.net +1 619 812 3908 Vice President Internet and Advanced Data Services TCG CERFnet http://www.cerf.net +1 619 812 3995 (FAX)

5 5

Re: More Sidgemore on per-bit pricing (fwd)
by Vadim Antonov 08 Dec '98

08 Dec '98

Eric Dean wrote: > > One could use something like MPLS to determine the Ingress and Egress > points of the network if it had a robust enough MIB. Goodbye scalability. Please tell me what happens when a link carrying a million MPLS-ed flows does flap. --vadim

1 0

Excellent article on Internet Peering Issues (fwd)
by howland＠Priss.com 07 Dec '98

07 Dec '98

Since the issue of charging for peering has come up again, I thought the following article might be interesting. I do not agree with the government as benevolent angel of mercy that the writer seems to, but that doesn't fault either his data, nor the validity of his conclusions based on that data. To vastly over-summerize, he states that the ignorance of charging for peering brings the arbitrary hammer of government regulation closer sooner than would otherwise likely happen. I agree with his view that telecommunications is rapidly merging, thus his idea that common-carrier regulations will be applied to IP providers. Curt- ----- Begin Included Message ----- >Date: Fri, 04 Dec 1998 12:00:03 -0500 >From: Rob Frieden <rmf5(a)psu.edu> >Subject: Article on Internet Peering > >Colleagues: > > You may find interesting an article I wrote entitled "Without Public Peer: >The Potential Regulatory and Universal Service Consequences of Internet >Balkanization." It appears in the current edition of the Virginia Journal >of Law and Technology >http://vjolt.student.virginia.edu/graphics/vol3/home_art8.html. > > I examine the development of private peering with an eye toward assessing >whether smaller ISPs, especially ones in rural areas, will face reduced and >more expensive access opportunities. I note the maturation of the Internet >and the use of alternatives to Sender Keep All settlements has established >a more hierarchical network of networks operating much like today's >telecommunications network. If this has occurred and if universal access >to the Internet becomes a public policy mission, then the goal may have >become more challenging and more expensive. This dilemma arises at the >same time as we face challenges on how to fund a more expansive universal >telecommunications mission. >Rob Frieden >Professor of Telecommunications >Penn State University >105-c Carnegie Building >University Park, PA 16802 >

1 0

IOS Rev?
by Jason Weisberger 07 Dec '98

07 Dec '98

What seems to be the most popular IOS rev these days - I'm looking at moving to 11.1.22CA from 11.1.19CC1 - any good arguements for or against it or to any of the other images? -- Jason Weisberger Chief Technology Officer SoftAware, Inc. 310/305-0275 Even in laughter the heart is sorrowful; and the end of that mirth is heaviness. -- Proverbs 14:13

2 2

prefix dampening w/mae-e next-hop
by Bradley Reynolds 07 Dec '98

07 Dec '98

I am seeing a lot of prefixes being dampened with mae-e next hops. Can someone comment on what is going on? most of the nitrous dampened table is mae-e next hops. (one of about 20 similar). *>i204.38.74.0 165.117.1.61 4294967294 100 0 3561 1225 10330 i * i 198.32.136.11 4294967294 100 0 1239 1225 10330 i *d 192.41.177.241 73 0 1239 1225 10330 i *d 192.41.177.127 32 0 3561 1225 10330 i BR

1 0