- NANOG - lists.nanog.org

Re: Policy Statement on Address Space Allocations
by Paul Ferguson 07 Feb '96

07 Feb '96

At 01:11 PM 2/5/96 -0600, Alan Hannan wrote: > > Learn how to renumber. It really is possible, you know. > > -alan > So, Alan, are you volunteering to help us out in PIER? ;-) - paul

1 0

Re: Policy Statement on Address Space Allocations
by Paul Ferguson 07 Feb '96

07 Feb '96

Hocus Pocus. A NAT solves this problem. :-) - paul At 08:12 AM 2/5/96 -0700, Tan Chang Hu wrote: >> >> If you have a class B and use a firewall, then a /27 should be more >> than is needed on the global Internet and they should use an address >> from RFC1597 internally and return the /16. >> >> Hank >> >Hank, > Depending on the firewall design, hosts located behind firewalls >can conceivably access the Internet directly for certain services and in >this case unique addresses are required. Your assumption would be valid >when all traffic for that site is handled by proxy servers. > >-- >T. C. Hu | tchu(a)sandia.gov >Sandia National Laboratories | Tel: (505) 845-8936 >P.O.Box 5800 | FAX: (505) 844-2067 >Albuquerque, NM 87111-0807 | > > > -- Paul Ferguson || || Consulting Engineering || || Reston, Virginia USA |||| |||| tel: +1.703.716.9538 ..:||||||:..:||||||:.. e-mail: pferguso(a)cisco.com c i s c o S y s t e m s

1 0

Re: Policy Statement on Address Space Allocations
by Vince Fuller 05 Feb '96

05 Feb '96

In message <199602021946.AA16364(a)mail.crl.com>, George Herbert writes: > > >> How do Pipex and Dante get global routes right now? > > > >Oh.. from a whole bunch of different places. > > > > ANS customer routes from ANS > > MCI customer routes from MCI > > SprintLink customer routes from Sprint > > Alternet customer routes from Alternet > > AUNET routes from EUNET > > ... > > > >You get the idea. > > How do they get to Barrnet? SURAnet? Etc? Suranet is at MeaEast. Barrnet is presently an MCI transit customer. Actually, the situation is a bit more complicated than this (in case anyone really wants to know). It is the case that each of the BBN Planet regions are MCI transit customers, but BBN Planet also has presence at MAE-East, FIX-East, MAE-West, and the Pennsauken NAP. We are in the process of finalizing the peering policy for BBN Planet as an integrated whole. In the near future, we will send a notice to the provider community that describes our policy and invites others to establish bi-lateral peering agreements with us. Vince Fuller, BBN Planet Network Engineering

1 0

Re: Policy Statement on Address Space Allocations
by Alex.Bligh 05 Feb '96

05 Feb '96

Daniel Karrenberg <Daniel.Karrenberg(a)ripe.net> wrote: > If you insist on prefix-length filtering I have proposed a soloution > for future address space allocated via the RIPE NCC several times: > > - set your inbound prefix length filter to /19. > > - The RIPE NCC will *guarantee* that we will not make more than > 1024 non-aggregateable allocations from each /8. > > - The RIPE NCC will continue to work with the providers to > maximise aggregation. Our goal is a maximum of 1024 routes > per /8 visible at major exchange points. Incidentally this > is the same goal that you seem to have. You are not distinguishing (initial) allocation from announcement. Your guarantee is worthless in the sense that it only gurantees that the announcements (as opposed to allocations) can be aggregated if each window allocation is tied to a single AS, and thus, for instance that none of the allocation is for PI space, or for allocation to customers who aren't local-IRs but have their own AS etc. etc. You also have the problem that currently it is impossible for local-IRs to allocate blocks of IP numbers that wouldn't be filtered out to multihomed customers (with their own AS - thus almost inevitably requiring a separate announcement) where that customer under the RIPE rules isn't 'justified' in getting a /19 (too small, for instance). Conservation vs. aggregation again. What is your recommendation on this? Alex Bligh Xara Networks PS: Here's Sprint's sister company's current announcement of routes *originating* in its AS as I see them - I do hope Sprint takes the honest path if it does refuse to carry short announcements and not route all bar 4 of these nets, as well as a similar long list from AS1239 :-) I'm not convinced Sprint has the moral highground here.... Network Next Hop Metric LocPrf Weight Path *> 160.214.0.0 194.68.130.50 0 4000 ? *> 163.164.0.0 194.68.130.50 0 4000 ? *> 194.41.63.0 194.68.130.50 0 4000 ? *> 194.106.0.0/19 194.68.130.50 0 4000 ? *> 194.106.32.0 194.68.130.50 0 4000 ? *> 194.106.33.0 194.68.130.50 0 4000 ? *> 194.106.34.0 194.68.130.50 0 4000 ? *> 194.126.64.0/19 194.68.130.50 0 4000 ? *> 194.133.0.0/19 194.68.130.50 0 4000 i *> 194.133.4.0/23 194.68.130.50 0 4000 ? *> 194.133.6.0 194.68.130.50 0 4000 ? *> 194.133.7.0 194.68.130.50 0 4000 ? *> 194.133.8.0 194.68.130.50 0 4000 ? *> 194.133.15.0 194.68.130.50 0 4000 ? *> 194.133.24.0 194.68.130.50 0 4000 ? *> 194.133.28.0 194.68.130.50 0 4000 ? *> 194.140.128.0/19 194.68.130.50 0 4000 ? *> 194.140.224.0/21 194.68.130.50 0 4000 ? *> 194.149.192.0/18 194.68.130.50 0 4000 ? *> 194.158.0.0/20 194.68.130.50 0 4000 ? *> 194.176.96.0/19 194.68.130.50 0 4000 ? *> 194.204.96.0/23 194.68.130.50 0 4000 ? *> 196.27.0.0 194.68.130.50 0 4000 ? *> 196.27.1.0 194.68.130.50 0 4000 ? *> 198.169.26.0 194.68.130.50 0 4000 ? *> 204.59.0.0/16 194.68.130.50 0 4000 i *> 204.83.37.0 194.68.130.50 0 4000 ? *> 204.83.237.0 194.68.130.50 0 4000 ? *> 204.83.254.0 194.68.130.50 0 4000 ? *> 206.49.64.0/18 194.68.130.50 0 4000 i *> 206.49.65.0 194.68.130.50 0 4000 ?

9 13

Re: Policy Statement on Address Space Allocations
by Hank Nussbacher 05 Feb '96

05 Feb '96

On Fri, 2 Feb 1996 14:29:09 -0500 (EST) you said: >On Fri, 2 Feb 1996, Howard Berkowitz wrote: > >> > > We are working on the 192.x.x.x swamp right now. >> > > Rough estimates (with much more accurate data @ NANOG) >> > > >> > > 60% - invalid or missing contact information >> > >> > This is interesting. How about a policy that says if nobody can contact >you >> > and none of your addresses are reachable, then after some period, your >> > addresses get recycled. >> > >> > >> By addresses not being reachable, are you effectively saying that any >> enterprise that does not want to connect to the Internet must use >> RFC1597 address space? >> >> Anyone have an idea how much of the address space is used for >> registered addresses of organizations that do not connect to the Internet? > >I would also be curious how the 60% missing is counted. > >If an organization places 99% of their addresses behind a firewall do all >those not count? If you have a class B and use a firewall, then a /27 should be more than is needed on the global Internet and they should use an address from RFC1597 internally and return the /16. > >Unfortunately, I don't think we can base much policy on whether or what % >of addresses are reachable from the internet. > >--- David Miller >---------------------------------------------------------------------------- > It's *amazing* what one can accomplish when > one doesn't know what one can't do! > Hank

2 1

number seven
by bmanning＠ISI.EDU 05 Feb '96

05 Feb '96

Renumbering - What, Why and How. v.007 05feb96 ftp.isi.edu:/pub/bill/renumbering Bill Manning Sent to: inet-access(a)earth.com IAP(a)VMA.CC.ND.EDU sun-managers-relay(a)ra.mcs.anl.gov pier(a)isi.edu nanog(a)merit.edu Kudos: Don Rolph - TI Piet Beertema - Brian Carpenter - CERN Michael Patton - BBN Jeff Schiller - MIT Matt Holdridge - DECUS What: Renumbering is the action of changing the IP addresses (i.e. the prefix and/or netmask) for an administrative domain and all the machines in it. This can be as small as a single lan with a few hosts through an International Internet Service provider and all its downstream providers/clients. Why: Due to the extensive growth of the publicly visible IP (IPv4) structure, (the Internet) there has been pressure placed on both the total number of addresses in use, but also the abilities of the global routing system to handle them all. Some providers are asking their clients to help alleviate this situation by utilizing addresses already delegated to the provider. This reduces the number of prefixes that are injected into the Internet routing system[1]. Remember that Internet wide connectivity is something that -NO- provider can guarantee or control. The registries which delegate address space attempt to make the address space last as long as possible[2]. To facilitate management of high traffic/mobility environments, the use of dynamic addressing eases the burden of the support staff. A reasonable paradigm is that the network should appear flat to the user but should appear rigidly hierarchical to the network administrator. Among the tradeoffs between fully manual/static management and fully dynamic configuration is the concept of traceability or the ability to retain the identity of an end to end connection. Many network operators want to know, consistently "who" a machine really is. So, collecting techniques and tools for supporting renumbering IP hosts can be a very valuable activity and should be considered as part of ongoing network design. What follows are some tips and techniques for renumbering and designing for renumbering support. How: - basic philosophy Deciding to renumber because you have to, or because you want to Use of a "majik" line in through the address space to delineate who/where renumbering should occur is a function of time and tools.[5] The two worst case environments are: - flat routing of 32bit prefixes. Good in the hw/sw design cycle. - periodic, dynamic renumbering across the entire address space. Route flaps, name conflicts, etc. Plan for the worst case and hope for the best. - developing good designs to facilitate renumbering - Use Discovery protocols (Router, DHCP, dynamic routing etc) - Centralized services/services (DHCP Servers & Routers) - Weigh tradeoffs between full dynamic support and manual support of a small number of machines/files. (Note that this is more than just deploying DHCP et.al. This is changing the range over which DHCP et.al. will operate!) - Keep total changes to a minimum - avoid classful routing protocols (RIP, IGRP, EGP etc.) - Build robust software distribution methods - rdist (UNIX) - sms (MicroSoft) - Catalog all files that require hardcoded addresses - DNS zone files - NNTP configurations - NTP configurations - AFS servers - static host lists /etc/hosts - ROUTER configurations - NMS databases - Firewalls and Access control lists - Use names instead of numbers where ever possible. It is possible to reorganize procedures to generate most/all configuration files that require hardcoded addresses from the files that map names to addresses. (Use a network managment database) - Channels to update external databases (DNS, IRR, NNTP etc) - techniques to renumber legacy infrastructure/hosts Convince Managment with good cost/benefit arguments Give yourself plenty of time. A year or more may be required. In some situations, it may be required to renumber fairly large sections of a network in 3-6 months!! Evaluate the trade offs of incremental vs flag-day migration Decide on a new numbering policy bigger or smaller or differnet media layers changing subnet masks consider broadcast and multicast scope Consider re-architechting the topology security implications Deploy DHCP/Bootp and other dynamic discovery protocols Use routers and secondary addresses Run two subnets on the same media layer Use DNS as a migration tool Notify your secondaries Change timeouts to facilitate rapid updates Update local zone generation scripts Get the Dynamic DNS code deployed Prepare recipies for chaning each type of end-user system Can you isolate "misbehaved" hosts with ancient code? Identify software that may use IP addresses for use licenses. - ways to avoid renumbering [3],[4] - Public Relations - as viewed inside an organization - Identify which organizations you must work with - Clear and realistic timetables must be set - Publication of the changes to the user community - User community feedback and buyin - Managment acceptance - viewed outside an organization - Coordination with offsite support services (DNS Secondaries, NNTP Feeds, NTP servers etc.) Legacy tools Some predictions indicate a planned 20-30yr life expectancy for IPv4 Thats a -long- legacy. How to change to a DHCP/bootp environment. The DHCP FAQ is a really good place to start. http://web.syr.edu/~jmwobus/comfaqs/dhcp.faq.html Router secondary addresses Ensure your routers have the new prefixes as secondary or primary addresses. You may find that deletion of a primary address will delete the secondary. How to turn back addresses Generally, Email to Hostmaster(a)InterNIC.net, indicating a desire to return address space is enough. There is an appeal document that may come out of the CIDRd working group which has more to say on this topic. Virtual interfaces Use of virtual interfaces can provide a migration aid. http://inet.nttam.com/HMP/PAPER/131/ ugle.unit.no:/pub/unix/network/vif-1.0.tar.gz for SunOS4.1.4 Ensure route advertisements are done Serious Problems: Security - watch your access lists when addresses change. Managability - SNMP configurations - Passive DHCP vs Dynamic DHCP Index: [1] CIDR FAQ - anonymous FTP: ftp.ibm.net.il/pub/docs/cidr.faq [2] RFC 1466 [3] RFC 1597 & RFC 1627 [4] RFC 1631 [5] draft-ietf-cidrd-ownership-01.txt RFC 1631 - Network Address Translators RFC 1715 - "H" ratio RFC 1775 - To be on the Internet RFC 1812 - IPv4 router requirements RFC 1817 - Classful routing ------====== EOF =====----- -- --bill

1 0

LIVE NUDE VIDEOCONFERENCING!
by kristina＠free.org 05 Feb '96

05 Feb '96

Hi, My name is Kristina. I'm a nude model and I'd love to take my clothes off and entertain you. You can watch me live and in color on your computer. We can type back and forth and I'll be happy to perform your erotic fantasy. If this sounds like fun, visit the website and download the software. The address is http://www.videofantasy.com or you can get the software from the BBS at 815-397-9877. I'll turn the camera on in my studio and wait to hear from you. I think you'll like what I have to show you. This isn't a movie...you make a request and I'll probably fulfill it for you. Look for my picture on the Website. Hope to see you soon! Love, Kristina

1 0

Re: Policy Statement on Address Space Allocations
by David Miller 04 Feb '96

04 Feb '96

On Sun, 4 Feb 1996, Hank Nussbacher wrote: > On Fri, 2 Feb 1996 14:29:09 -0500 (EST) you said: > > > >I would also be curious how the 60% missing is counted. > > > >If an organization places 99% of their addresses behind a firewall do all > >those not count? > > If you have a class B and use a firewall, then a /27 should be more > than is needed on the global Internet and they should use an address > from RFC1597 internally and return the /16. While that certainly sounds nice from the current context, there are other reasons for wanting unique address space. Things like mergers come to mind, as well as the expectation of better security in ipv6. --- David Miller ---------------------------------------------------------------------------- It's *amazing* what one can accomplish when one doesn't know what one can't do!

1 0

Re: Policy Statement on Address Space Allocations
by sob＠academ.com 03 Feb '96

03 Feb '96

> Furthermore, there an infinite number of views and ideas that are > inconsonant between peoples and organizations. Forcing a particular > philosophy on others in the style of a Crusade is *absolutely wrong* > and has been proven wrong for the entire span of human history. There cannot be an infinite number of views unless there is an infinite number of people with at least one view, or at least one person has an infinite number of views. The first is certainly not true. The latter is not likely to be true. -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

1 0

Re: Policy Statement on Address Space Allocations
by Tim Bass 03 Feb '96

03 Feb '96

A good and old friend writes: > Okay, I'll play along. > ......................... [ ..... ] .................... I have had this reply in my /tmp directory for a few hours to a NANOG post on the same subject matter...... and if we are just 'playing along' please allow the heretics in the 'rebel base camp' to play as well :-) ----------- A Rebuke Against the Crusade ---------- Back and forth: Bill: >> Hijacking has a number of interesting problems Curtis: > There is no need to call it hijacking. [ ... ] The Heretic Responds: Why not call it hijacking? That is exactly what it appears to be. NANOG nor the IETF has the right to judge the motives of address space holders and the holder of the address space has no legal nor moral obligation to contact the providers of services. Hijacking is actually a "kind and polite" term, it seems. What the "Self-proclaimed Omnipotent Crusaders and Saviors of the Fate of Routing" seem to forget is that they do not control the world IP address space; but they sure would like the world to believe have been "Blessed with the Right from the Holy Grail of IP" to act without remorse "for the cause". Furthermore, there an infinite number of views and ideas that are inconsonant between peoples and organizations. Forcing a particular philosophy on others in the style of a Crusade is *absolutely wrong* and has been proven wrong for the entire span of human history. ( I suggest a select few might be illuminated to read literature beyond FAQs, technical manuals, and IETF documents; a world history exists, believe-it-or-not! ) The "IP Routing Table Crusade" is just a modern example of the same tactics used by dioramic zealots during all human history. I'll stop here, especially to the pleasure of those who believe that providers of IP services and hardware vendors have dominion over the users of the technology. What is the most educational, in my opinion, is to watch and read as others are seduced into the "Ardor of the Crusade". The myth and perception of 'self-righteousness' is very dangerous; the world of IP and internetworking is not exempt from the causal results of crusaders. Tim

2 1