- NANOG - lists.nanog.org

Re: When IPv6 ... if ever?
by smd＠clock.org 02 Sep '00

02 Sep '00

| At some point, when ARIN just stops issueing IPv4 address space, | I would say it would be in a {I,N}SPs best intrest to switch. This is not "soon". | As an ASP, if my uplinks offered ipv6 address space/routing, | I'd get it and start working with it _now_ rather then later. How much extra are you willing to pay? Sean.

1 0

When IPv6 ... if ever?
by Roeland M.J. Meyer 02 Sep '00

02 Sep '00

> From: Nathan Lane [mailto:nathan@terminus.com] > Sent: Friday, September 01, 2000 3:54 PM > > "Roeland M.J. Meyer" wrote: > > > > The real issue is getting all those routers and switches > deployed. We > > can then turn up the clients and servers as needed. > > The need for v6, at least for me, is in the deployment of mass > quantities of end nodes. That I can nearly support today > with existing > infrastructure. I see little compelling need to upgrade my existing > routers to v6 now; I do see a need for 4000 wireless end nodes at each > of our sites - those could be serviced with a few app servers in the > home office that knew v6 and v4-v6 tunnels [yes, technically > these would be "routers"] at the remote sites. > At six to eight weeks for each > router software release for the bug scrub and six months to roll out > said code, we only have time to do it twice a year. Adding a new > protocol would be formiddable unless tunelling were used to virtualize > the infrastructure. 1) if one is using tunneling, then we really haven't gone over to IPv6. 2) if one is using tunneling, for leaf-nodes, then how is the core going to know those leaves are using IPv6? 3) Conservatively, every recent linux node has IPv6 kernel support and every Windoze box can do IPv6 (not to mention what we have just heard from the BSD camp <g>). This is over 50% of the leaves out there (conservatively). At what point is there sufficient market penetration of the technology to consider rolling IPv4/IPv6 interoperability/capability on the core routers and switches (something short of 100%, I would hope)? 4) Is it maybe that Sun, HP, Intel, Cisco, IBM, and the telco's, aren't all quite ready yet? 5) Admittedly, I haven't had the bandwidth to follow IPv6 all that closely. But, IPv6 has been pregnent quite a long time.

1 0

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

02 Sep '00

Gentle readers who might happen to be using unique IP addresses for your Web hosting customers, or for other virtualized services such as FTP, POP3/IMAP, SSL, etc, you need to be aware of ARIN's recent policy change. Basically, they won't give you addresses anymore. They're accepting comments. A lively discussion has begun, as usual. Kevin >Date: Tue, 29 Aug 2000 14:46:37 -0400 (EDT) >From: Member Services <memsvcs(a)arin.net> >To: arin-announce(a)arin.net, ppml(a)arin.net >Subject: ARIN Web Hosting Policy >Message-ID: <Pine.SOL.4.05.10008291437410.19186-100000(a)ops.arin.net> >Sender: owner-arin-announce(a)arin.net > >ARIN's new web hosting policy has recently been under discussion on the >ARIN IP allocations policy mailing list. >See http://www.arin.net/members/mailing.htm. > >The policy is described at > > http://www.arin.net/announcements/policy_changes.html > >Some individuals have expressed their disagreement with this new policy. >Should the ARIN web hosting policy be changed? > >ARIN would like your feedback on this issue. Please post your comments >and suggestions to the public policy mailing list (ppml(a)arin.net) Your >feedback will be included in the discussions at the upcoming public >policy meeting. > >Information about the meeting can be found at >http://www.arin.net/announcements/memmeet.html

37 68

predicted customer support conversation
by smd＠clock.org 02 Sep '00

02 Sep '00

<ring ring> Operator: Hello, networknet NOC, can I help you? Customer: Yes, I'm having trouble surfing microsoft.com. Operator: Oh, dear. Are you using IPv4 or IPv6? Customer: Huh? What? Sean.

3 2

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

02 Sep '00

A converted bell-shaped-head writes: | HMM. Change is good. Otherwise evolution and innovation is not possible. Yes, and IPv6 is an evolutionary dead-end, and is about as useful as polyploidy is to a happily diploid organism whose growth is constrained by its external surface area. What is out-evolving IPv6? NAT, probably eventually leaning towards CATNIP. Hint: lots of change is happening in that space too, and you don't have to quadruple the amount of genes your poor transcriptase-like proteins have to deal with. Sean.

1 0

Re: IPv6 allocatin (was Re: ARIN Policy on IP-based Web Hosting)
by Michael Shields 02 Sep '00

02 Sep '00

In article <39B0343B.7FECFB0E(a)nominum.com>, "David R. Conrad" <David.Conrad(a)nominum.com> wrote: > Christian, > > > The point was a NAT'ed (masqueraded) network attempting to > > communicate with another NAT'ed (masqueraded) network. That > > does NOT work for the vast majority of people on the Internet. > > Hmmm. If you never try something, can it be said to not work? > > Until such a scenario becomes _far_ more commonplace that it is today, I > doubt anyone (other than end-to-end purists and the folks who have been > bitten) will care. It is a basic principle often used in both protocol design and ethics that one cannot endorse a course of action that, if all were to follow it, causes undesirable consequences. If NAT is really the future, we must prepare for a world where NAT is carried to its logical conclusion; all sites use NAT. If that ultimate future is undesirable, then we should not even start down the road; we must conclude that NAT is not the future. It can, then, be at best an expedient hack. If we accept that peer-to-peer communication is a design goal of the Internet, then to make a convincing argument that NAT is the future, you must outline how two sites behind a NAT can communicate with each other conveniently. Otherwise: "That does not scale." -- Shields.

1 0

Re: ARIN Policy on IP-based Web Hosting
by Alec H. Peterson 02 Sep '00

02 Sep '00

"John A. Tamplin" wrote: > > Well, if the policy is that you have to use name-based hosting everywhere > feasible and do something different for those customers that need > something different, that can be quite a hardship on existing setups. > For example, re-engineering all the tools to create and maintain vdom > services, changing existing customer setups, etc. It is certainly easier > to treat all hosting customers alike, rather than have completely > separate setups and then have to change a customer from one to the other > when they add or delete services (including downtime). That was also brought up at the meeting, however it was generally agreed that the address savings were worth the work. > > Another issue nobody has mentioned is security between virtual servers. > Under name-based hosting, they all run as the same user-id and thus to get > the same security you have with separate IP-based servers you have to put > all the access conrol checks in all the tools that can be used. This can be > hard if not impossible to do when you allow full shell access to the files > used by the server. Not if you chroot() the user into their file space. That may not be ideal, but there are ways to deal with it. Alec -- Alec H. Peterson - ahp(a)hilander.com Staff Scientist CenterGate Research Group - http://www.centergate.com "Technology so advanced, even _we_ don't understand it!"

22 42

Re: ARIN Policy on IP-based Web Hosting
by Danny McPherson 01 Sep '00

01 Sep '00

I agree with Alec here. If you've got complaints or want to be involved, use the ppml list - whether or not you make it to the meetings. Though the meetings indeed have a significant impact on policies, I'm pretty certain that if valid points are made on the mailing list they'll be considered at the meetings, and if they're not - whine about it on the ppml list -- that's what it's for... -danny > Certainly. That's what ppml(a)arin.net is for.

3 2

Re: IPv6 allocatin (was Re: ARIN Policy on IP-based Web Hosting)
by Vadim Antonov 01 Sep '00

01 Sep '00

On Fri, 1 Sep 2000, Scott Francis wrote: > > Are we building production networks or doing experiments? IPv6 exhibits > > no added functionality over IPv4 + NAT, so why bother? > > what? > > *scratches head* > > that's odd, I was under the impression that an order of magnitude more > address space, all of it PUBLICLY ROUTEABLE, If that was of any importance, a trivial addition of an "extra bits" IPv4 option would suffice. In fact, majority of network hosts are not "Publicly Routeable" for the simple reason that they're sitting behind firewalls, or have dynamic addresses. > without any translation > bottlenecks (and yes, there *are* translation bottlnecks on a setup > with several thousands IPs running through a single NAT box), Are you trying to do NAT at OC-3? :) Actually, a newer faster PCs can, probably, do that at even higher bitrates :) It is _very_ easy to install as many NATs in parallel as you wish, simply by segmenting private address space, and routing different segments through different NAT boxes. (And any application-level firewall is already a "NAT" :) > with support for encryption in the packet format, constituted 'added > functionality'. Mmmm... I apparenty have a delusion of having a working IPSEC in my box... > Apparently I was mistaken. No, I agree that having these things available in the initial design is nice; but that alone does not justify redoing the entire network from scratch, since pretty much the same effect can demonstrably be achieved using the already-deployed technology. --vadim

1 0

MYDOMAIN.COM faking auth on COM.BR zone
by Frederico A C Neves 01 Sep '00

01 Sep '00

Dear Nanog Readers, As we have not yet received any response from our abuse request (attached) to MYDOMAIN.COM and more 10 phone calls we are looking for help of any kind here. COM.BR zone is populated with 280K zone delegations (92% of the .BR registered domain names). Mydomain.com DNS servers are delegated to 1361 domains inside the .BR zone. We don't known why but these servers are answering authoritatively to COM.BR zone and they are carrying a wild card record to. This is causing some confusion and trouble to buggy resolvers (notably NT). If someone knows a contact different of the whois and the web site information please let me known asap privately. Best Regards Frederico Neves .BR tech contact --begin bash> dig @a.root-servers.net br ns ; <<>> DiG 8.2 <<>> @a.root-servers.net br ns ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr rd; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 5 ;; QUERY SECTION: ;; br, type = NS, class = IN ;; ANSWER SECTION: br. 2D IN NS NS.DNS.br. br. 2D IN NS NS1.DNS.br. br. 2D IN NS NS2.DNS.br. br. 2D IN NS NS3.NIC.FR. br. 2D IN NS NS-EXT.VIX.COM. ;; ADDITIONAL SECTION: NS.DNS.br. 2D IN A 143.108.23.2 NS1.DNS.br. 2D IN A 200.255.253.234 NS2.DNS.br. 2D IN A 200.19.119.99 NS3.NIC.FR. 2D IN A 192.134.0.49 NS-EXT.VIX.COM. 2D IN A 204.152.184.64 ;; Total query time: 768 msec ;; FROM: clone.registro.br to SERVER: a.root-servers.net 198.41.0.4 ;; WHEN: Fri Sep 1 17:52:07 2000 ;; MSG SIZE sent: 20 rcvd: 209 bash> dig @NS.DNS.br. com.br ns ; <<>> DiG 8.2 <<>> @NS.DNS.br. com.br ns ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 3 ;; QUERY SECTION: ;; com.br, type = NS, class = IN ;; ANSWER SECTION: com.br. 1D IN NS NS2.DNS.br. com.br. 1D IN NS NS-EXT.VIX.COM. com.br. 1D IN NS NS.DNS.br. com.br. 1D IN NS NS1.DNS.br. ;; ADDITIONAL SECTION: NS2.DNS.br. 1D IN A 200.19.119.99 NS.DNS.br. 1D IN A 143.108.23.2 NS1.DNS.br. 1D IN A 200.255.253.234 ;; Total query time: 1 msec ;; FROM: clone.registro.br to SERVER: NS.DNS.br. 143.108.23.2 ;; WHEN: Fri Sep 1 17:52:24 2000 ;; MSG SIZE sent: 24 rcvd: 157 bash> dig @ns1.mydomain.com com.br any ; <<>> DiG 8.2 <<>> @ns1.mydomain.com com.br any ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr aa rd; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 7 ;; QUERY SECTION: ;; com.br, type = ANY, class = IN ;; ANSWER SECTION: com.br. 42m40s IN SOA ns1.mydomain.com. hostmaster.com.br. ( 967828523 ; serial 4h33m4s ; refresh 34m8s ; retry 1w5d3h16m16s ; expiry 42m40s ) ; minimum com.br. 3D IN NS ns1.mydomain.com. com.br. 3D IN NS ns2.mydomain.com. com.br. 3D IN NS ns3.mydomain.com. com.br. 3D IN NS ns4.mydomain.com. com.br. 1D IN A 208.184.130.40 com.br. 1D IN MX 10 a.mx.mydomain.com. com.br. 1D IN MX 10 b.mx.mydomain.com. com.br. 1D IN MX 10 c.mx.mydomain.com. ;; ADDITIONAL SECTION: ns1.mydomain.com. 3D IN A 208.184.130.51 ns2.mydomain.com. 3D IN A 208.184.130.52 ns3.mydomain.com. 3D IN A 208.184.130.53 ns4.mydomain.com. 3D IN A 208.184.130.55 a.mx.mydomain.com. 1D IN A 208.184.130.53 b.mx.mydomain.com. 1D IN A 208.184.130.51 c.mx.mydomain.com. 1D IN A 208.184.130.55 ;; Total query time: 1022 msec ;; FROM: clone.registro.br to SERVER: ns1.mydomain.com 208.184.130.51 ;; WHEN: Fri Sep 1 17:52:46 2000 ;; MSG SIZE sent: 24 rcvd: 340 --end -- ---------------------------------------------------------------- Frederico A C Neves Registro .br - ANSP <fneves(a)registro.br> R.Pio XI, 1500 Tel +55-11-3645-2418 Sao Paulo - SP - Brazil - 05468-901

1 0