- Test - lists.nanog.org

IPV6, IPV4, and NAT
by David Hares 01 Sep '00

01 Sep '00

Since the current threads have brought up the issues with NAT ... A couple of years ago, Bob Moskowitz presented a paper at IETF outlining the issues with multiple layers of NAT. I've lost the URL. Anyone know what it is? Dave ----------- David Hares Director of Network Engineering NetworkTwo Communications Phone: 734.827.3620 650 KMS Place FAX: 734.827.3690 Ann Arbor, MI 48108 Email: dhares(a)networktwo.net

1 0

Re: ARIN Policy on IP-based Web Hosting
by J. Scott Marcus 01 Sep '00

01 Sep '00

At 19:29 08/31/2000 -0400, dan(a)netrail.net wrote: >On Thu, 31 Aug 2000, Daniel Senie wrote: > >> dan(a)netrail.net wrote: >> > >> > In a democratic process, which ARIN is, refusal to participate in the >> > voting process, when eligible, usually removes one's standing to complain. >> >> Cough up your $500 as an individual and you can buy a vote. Sounds >> democratic... > >The vast majority of the participants here work for ARIN member companies. >They get a vote. It's democratic... Yup. :-) Furthermore, this measure was discussed (and other issues of interest to folks on the NANOG list are routinely discussed) at ARIN Public Policy meetings, which are _not_ restricted to ARIN members. The next one is in Washington, DC, which is convenient to many of you. (See http://www.arin.net/announcements/memmeet.html) Show up! Be heard! Furthermore, ARIN pays a great deal of attention to its public policy e-mail list, as was previously noted. That list is also open to the general public. Sign up at http://www.arin.net/members/mailing.htm ! There are a number of opportunities and mechanisms to democratically influence ARIN policies. It exists to serve its members and the Internet community. I for one would welcome seeing the broader community take more advantage of those mechanisms. Cheers, - Scott (speaking only for himself)

2 1

The Cidr Report
by Tony Bates 01 Sep '00

01 Sep '00

This is an auto-generated mail on Fri Sep 1 12:00:00 PDT 2000 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 01Sep00 0) General Status Table History ------------- Date Prefixes 250800 85144 260800 91672 270800 91299 280800 91282 290800 85417 300800 85709 310800 85345 010900 85543 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 6240 Number of ASes announcing only one prefix: 3082 (1039 cidr, 2043 classful) Largest number of cidr routes: 589 announced by AS705 Largest number of classful routes: 1076 announced by AS701 1) Gains by aggregating at the origin AS level --- 01Sep00 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS10476 2 1 1 50.0% Sinfonet,S.A Panama AS10039 2 1 1 50.0% mire.net AS9983 1 1 0 0.0% Australian Bureau of Statistics. AS9982 1 1 0 0.0% PAICHAI UNIVERSITY AS9981 1 1 0 0.0% Iworld Networking, Inc. AS9979 1 1 0 0.0% KOREA EXCHANGE BANK AS9978 1 1 0 0.0% The University of Seoul AS9977 1 1 0 0.0% IOSYSTEM AS9974 1 1 0 0.0% KOREA SECURITIES COMPUTER CORP. B AS9973 1 1 0 0.0% KEB Futures Co. AS9968 1 1 0 0.0% Kyobo Life Insurance AS9966 1 1 0 0.0% KORAMBANK AS9962 1 1 0 0.0% Sunchon National University AS9960 1 1 0 0.0% NEW C&C CO.,LTD. AS9954 1 1 0 0.0% Kunsan National University AS9953 1 1 0 0.0% Hyundai Eng. & Const. Co., Ltd. AS9951 1 1 0 0.0% D3C Net AS9950 1 1 0 0.0% INT Co.,Ltd. AS9935 1 1 0 0.0% AGNS-Customer-KW AS9927 1 1 0 0.0% A Multihomed ISP Company AS9912 1 1 0 0.0% Quality Internet Services AS9891 1 1 0 0.0% iGreatLink.com AS9879 1 1 0 0.0% OGILVY ASIA/PACIFIC AS9877 1 1 0 0.0% Ngee Ann Polytechnic Computer Cen AS9871 1 1 0 0.0% JC Entertainment Co. AS9868 1 1 0 0.0% Catholic University of TAEGU HYOS AS9866 1 1 0 0.0% LGCAPITAL AS9862 1 1 0 0.0% YES24 CO. LTD AS9859 1 1 0 0.0% ChungCheong College AS9856 1 1 0 0.0% ec-Bank co., Ltd. For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

Re: ARIN Policy on IP-based Web Hosting
by sigma＠pair.com 01 Sep '00

01 Sep '00

>It's been a long time since I've seen so many people get so upset over >what strikes me as an obvious step which others took a long time ago >and has a policy which makes room for worthy exceptions. Because some hosts are providing other virtualized services which are nowhere near being ready for use without per-IP allocations. I'll grant that it's not such a big issue for HTTP anymore, except of course for bandwidth shapers, network analysis tools, load-balancing switches, kernel-based virtualizations, etc etc etc. Kevin

3 2

Re: ARIN Policy on IP-based Web Hosting
by smd＠clock.org 01 Sep '00

01 Sep '00

Hm, this is vaguely about the tension in how network-friendly to make applications... Jim Mercer writes: | just think how crippled make(1) would be without extensions. Hm, let's see, in NetBSD's make(1) regime, the current sys.mk has the declarations below. What stops you from using a different suffix convention than <foo>".c" and friends? I see no reason why make(1) couldn't be extended to deal with arbitrary prefix/infix/suffix identifiers, or even something complicated like a set of regexps. COMPILE.c?= ${CC} ${CFLAGS} ${CPPFLAGS} -c LINK.c?= ${CC} ${CFLAGS} ${CPPFLAGS} ${LDFLAGS} CXX?= c++ CXXFLAGS?= ${CFLAGS} COMPILE.cc?= ${CXX} ${CXXFLAGS} ${CPPFLAGS} -c LINK.cc?= ${CXX} ${CXXFLAGS} ${CPPFLAGS} ${LDFLAGS} OBJC?= ${CC} OBJCFLAGS?= ${CFLAGS} COMPILE.m?= ${OBJC} ${OBJCFLAGS} ${CPPFLAGS} -c LINK.m?= ${OBJC} ${OBJCFLAGS} ${CPPFLAGS} ${LDFLAGS} ... # C .c: ${LINK.c} -o ${.TARGET} ${.IMPSRC} ${LDLIBS} .c.o: ${COMPILE.c} ${.IMPSRC} .c.a: ${COMPILE.c} ${.IMPSRC} ${AR} ${ARFLAGS} $@ $*.o rm -f $*.o .c.ln: ${LINT} ${LINTFLAGS} ${CPPFLAGS:M-[IDU]*} -i ${.IMPSRC} # C++ .cc .cpp .cxx .C: ${LINK.cc} -o ${.TARGET} ${.IMPSRC} ${LDLIBS} .cc.o .cpp.o .cxx.o .C.o: ${COMPILE.cc} ${.IMPSRC} etc. Finally, compared to the equivalents in, for example, the Common LISP universe, make(1) *IS* crippled, suffix-convention or not. The assumption many network people have that "everything is an X", for varous values of X (endianness, VAXishness, Microsoftishness, UNIXish) has always been a real problem, and has led to interesting problems (e.g., taking a file froma TENEX machine, changing directories on a VMS server). HTTP for its sins does abstract away some of the worst user-visible problems (e.g. do you need to care what platform the web server is running on?) The major problem I have with ftp, from the perspective of someone trying to build networks, is that most clients generally do not do passive-mode ftp by default, despite many years of harranguing going waaaaay back to Vadim Antonov's argument for that here. Another plug: NetBSD's ftp(1) man page says: epsv4 Toggle the use of the extended EPSV and EPRT commands on IPv4 connections; first try EPSV / EPRT, and then PASV / PORT. This is enabled by default. [with fallback to active on fail -smd] This is, in my opinion, Doing The Right Thing. Sean.

2 1

RE: ARIN Policy on IP-based Web Hosting (fwd)
by sigma＠pair.com 01 Sep '00

01 Sep '00

>There is only a small number of services that currently really require >dedicated IPs. HTTPS and Anonymous FTP. Although, the HTTPS is a concern - >not that many customers actually use the Anonymous FTP service. We ended up >offering Anonymous FTP as a premium service (I like to think that this cuts >down on warez and script kiddie distribution). Aha, I was waiting for someone to say that. So it's going to be OK to use per-host IP addresses if it's sold as a "premium" service? So that business model is OK, but not another? What if we say all of our services are "premium"? What if too many of your customers start paying you for that "premium" service? Where's the threshold? Are you more justified in your IP usage because you charge your customers more for it? By what justification does this poorly-thought-out policy interfere with business models or competitive advantages between hosts? >A few customers will whine, but 98% don't know >the difference, understand and accept the limititations, or are just so damn >happy it works that they don't mind. Great for your customers, then. >Although I do agree that ARIN does tend to be anal, I believe some system >architects would have shot us all in the foot by now if they hadn't put >their foot down. We just have to be cleverer than them and I think that >shouldn't be too hard, right? Are you proposing to circumvent the policy? Kevin

4 3

Re: IPv6 allocatin (was Re: ARIN Policy on IP-based Web Hosting)
by smd＠clock.org 01 Sep '00

01 Sep '00

| When, do you think, will IPv6 come someywhere close to being | significantly deployed? When pigs fly and the devil invests in snow-removal equipment. Sean.

2 1

Re: ARIN Policy on IP-based Web Hosting
by David Charlap 01 Sep '00

01 Sep '00

David Greer wrote: > > I think you are confusing MAC's and DOS here. My recollection is that > DOS stored filenames in 11 contiguous characters without the ".". It > being assumed that the last three characters were the extension. No. It is an 8-byte field and a 3-byte field. The fact that these fields are adjacent to each other in the structure does not transform them into a single 11-byte field. Note that when the name is less than 8 characters, the name field is padded with NULLs, and the extension remains stored in the same place (bytes 9-11, relative to the first byte of the name). > Macintoshes did / do store the extension as a separate entity in the > structure. Macs don't have any concept of extensions whatsoever. File type information is stored completely separately and has nothing at all to do with filenames. The system shell (and most applications) do not give users the ability to view or alter the four-byte file-type codes. -- David

1 0

Re: ARIN Policy on IP-based Web Hosting
by David Charlap 01 Sep '00

01 Sep '00

"Roeland M.J. Meyer" wrote: > > everything to the right side of the final dot. Such as in > "/etc/named.conf" the extension is "conf". A better example is > "/usr/local/src/whois.1.9.0/readme.txt" where the extension is "txt". True, in a literal understanding. But in the sense of "a part of the filename used to identify the format or purpose of the file content", it's not always correct. "extension" is a term that stems from the DOS days, when it was actually stored separately in the directory structure of the file system. Today, however, you find this information encoded into filenames in a wide variety of ways. Type information may be in the form of a prefix, a suffix, multiple prefixes, or multiple suffixes. It may be delimited by periods, dashes, other characters, or even by no characters at all. For example: conf.modules myarchive.tar.gz libstdc++-2-libc6.1-1-2.9.0.a kernel-headers-2.2.16-3.i386.rpm An "extension" is only one specific subset of the infinite number of possible ways that type information can be, and often is, encoded into filenames. Unfortunately, this creates the reality that any code which tries to deduce a file type from a filename will require a huge (and ever increasing) set of parsing rules (probably some form of regular expressions) in order to to the job properly. Even more unfortunately, the Windows world hasn't figured this out yet, and only looks at strings that follow a period at the end of a name. -- David

1 0

Root zone change -- Informational message
by Verd, Brad 01 Sep '00

01 Sep '00

Informational Message: The IP for m.gtld-servers.net will be changed in the authoritative list for .com, .net, and .org. Changes will be reflected in the zone with serial number 2000083001 -------------------------------------- Brad Verd gTLD Operations Manager Network Solutions Registry Email - bverd(a)netsol.com ---------------------------------------

4 4