- Test - lists.nanog.org

RE: IP adresss management verification
by Howard, W. Lee 14 Nov '06

14 Nov '06

> -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On > Behalf Of David Hubbard > Sent: Monday, November 13, 2006 11:42 AM > To: nanog(a)merit.edu > Subject: RE: IP adresss management verification > > What I meant was we require a technical justification to > give a dedicated IP to a customer but many hosts do not, > or they use it as a revenue add by charging for having > a dedicated IP when there's no technical reason for it. > Previously, or maybe still, there was no mandate that web > hosts only assign dedicated IP's when it can be justified. > > David This was the topic of one of the most interesting policies ARIN ever adopted. In 2000, there was a proposal to require web hosting organizations to use virtual hosting (roughly defined as many FQDNs on one IP address), unless indidivual IP addresses were required for documented technical reasons. This proposal predates the online proposal archive, but you can track it on its progression through the Board meetings. http://www.arin.net/meetings/minutes/bot/bot2000_0612.html http://www.arin.net/meetings/minutes/bot/bot2000_1002.html There was community support for the proposal, but strong debate. The Advisory Council found consensus, the Board adopted the proposal, then a few months later suspended the policy. I think this is the only time the Board used its emergency power to set or suspend a policy. http://www.arin.net/meetings/minutes/ARIN_VI/ppm_minutes.html#webhosting On the mailing list, and at the next public policy meeting there was extensive discussion. The Advisory Council took input from the community, and decided that the best policy would be to make it a recommendation. The current policy now reads: When an ISP submits a request for IP address space to be used for IP-based web hosting, it will supply (for informational purposed only) its technical justification for this practice. ARIN will analyze this data continuously, evaluating the need for future policy changes. http://www.arin.net/policy/nrpm.html#four25 To my mind, this is a good example of the ARIN process working well: the community favored a proposal, so it was adopted, but there were significant problems. The Board suspended the policy so the AC could get community feedback, and the policy was changed based on experience. If you have an opinion on this policy, you should say so on the Public Policy Mailing List. http://lists.arin.net/mailman/listinfo/ppml Lee

1 0

RE: IP adresss management verification
by David Hubbard 14 Nov '06

14 Nov '06

From: Michael.Dillon(a)btradianz.com > > SSL is a technical justification for separate IP > addresses for web hosts. Virtual servers is another > technical justification for assigning multiple IP > addresses to a single physical server. What I meant was we require a technical justification to give a dedicated IP to a customer but many hosts do not, or they use it as a revenue add by charging for having a dedicated IP when there's no technical reason for it. Previously, or maybe still, there was no mandate that web hosts only assign dedicated IP's when it can be justified. David

6 6

Re: IP adresss management verification
by Bill Stewart 14 Nov '06

14 Nov '06

On 11/13/06, chuck goolsbee <chucklist(a)forest.net> wrote: > It pisses me off to no end when a sales guy comes to me with a > request from a customer for a /20 for a half-rack of web servers. The > justification ALWAYS comes down to this inane "search engine > optimization" pipe dream. =\ No, no, it's absolutely true, and you can tell them so, and of course you can't provision the space without the customer filling out the ARIN paperwork to justify it and sending you a copy so you know what they're really trying to do. The one customer in 32768 who actually needs it will have enough clue to be able to fill out the forms, and the rest of them will spend a month trying to figure out why they' keep getting rejected. Meanwhile, get them some IPv6 address space, so they'll be cutting edge... once Google starts crawling the IPv6 web. [Sorry - I just get really annoyed when I'm trying to look for some topic for which the SEOs and phishers have polluted the web space with bogus material trying to drag traffic to their site by pretending to offer the real content.] ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.

1 0

RE: MCI < - > Savvis in Chicago
by Wallace Keith 13 Nov '06

13 Nov '06

Similar- Boston to Chicago MCI- seeing high latency 6 3 ms 3 ms 3 ms 544.at-5-0-0.xr1.bos4.alter.net [152.63.24.222] 7 3 ms 3 ms 3 ms 0.so-4-0-0.xl1.bos4.alter.net [152.63.16.121] 8 91 ms 95 ms 95 ms 0.so-7-0-0.XL1.CHI6.ALTER.NET [152.63.65.161] 9 93 ms 95 ms 92 ms pos6-0.gw6.chi6.alter.net [152.63.68.97] 10 94 ms 81 ms 83 ms netlogic-gw.customer.alter.net [157.130.101.2] 11 87 ms 80 ms 89 ms 206-80-93-67.chi.netlogic.net [206.80.93.67] Trace complete. H:\> ________________________________ From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Mike Hammett Sent: Monday, November 13, 2006 3:14 PM To: nanog(a)nanog.org Subject: MCI < - > Savvis in Chicago Anyone else seeing this? [root@ds00209 mhammett]# tcptraceroute 206.80.93.67 4569 Selected device eth0, address 205.218.65.34, port 54461 for outgoing packets Tracing the path to 206.80.93.67 on TCP port 4569, 30 hops max 1 205.138.198.193 0.444 ms 0.322 ms 0.319 ms 2 bpr2-ge-6-2-0-302.chicagoequinix.savvis.net (208.174.225.201) 0.411 ms 0.348 ms 0.330 ms 3 bpr1-ae0.ChicagoEquinix.savvis.net (208.174.226.85) 0.370 ms 0.403 ms 0.403 ms 4 208.174.226.26 30.460 ms 30.159 ms 29.601 ms 5 0.so-5-3-0.XL2.CHI2.ALTER.NET (152.63.64.58) 29.147 ms 28.063 ms 30.176 ms 6 0.so-6-0-0.XL2.CHI6.ALTER.NET (152.63.65.126) 32.394 ms 35.813 ms 35.976 ms 7 POS7-0.GW6.CHI6.ALTER.NET (152.63.68.189) 37.018 ms 36.800 ms 37.723 ms 8 netlogic-gw.customer.alter.net (157.130.101.2) 38.169 ms 41.228 ms 37.870 ms 9 206-80-93-67.chi.netlogic.net (206.80.93.67) [closed] 35.334 ms 33.460 ms 34.075 ms ---- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com

2 1

MCI < - > Savvis in Chicago
by Mike Hammett 13 Nov '06

13 Nov '06

Anyone else seeing this? [root@ds00209 mhammett]# tcptraceroute 206.80.93.67 4569 Selected device eth0, address 205.218.65.34, port 54461 for outgoing packets Tracing the path to 206.80.93.67 on TCP port 4569, 30 hops max 1 205.138.198.193 0.444 ms 0.322 ms 0.319 ms 2 bpr2-ge-6-2-0-302.chicagoequinix.savvis.net (208.174.225.201) 0.411 ms 0.348 ms 0.330 ms 3 bpr1-ae0.ChicagoEquinix.savvis.net (208.174.226.85) 0.370 ms 0.403 ms 0.403 ms 4 208.174.226.26 30.460 ms 30.159 ms 29.601 ms 5 0.so-5-3-0.XL2.CHI2.ALTER.NET (152.63.64.58) 29.147 ms 28.063 ms 30.176 ms 6 0.so-6-0-0.XL2.CHI6.ALTER.NET (152.63.65.126) 32.394 ms 35.813 ms 35.976 ms 7 POS7-0.GW6.CHI6.ALTER.NET (152.63.68.189) 37.018 ms 36.800 ms 37.723 ms 8 netlogic-gw.customer.alter.net (157.130.101.2) 38.169 ms 41.228 ms 37.870 ms 9 206-80-93-67.chi.netlogic.net (206.80.93.67) [closed] 35.334 ms 33.460 ms 34.075 ms ---- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com

2 1

RFC2827-bis comments solicitation
by Fergie 13 Nov '06

13 Nov '06

First, sorry for any duplicates, but we wanted to reach all interested parties. After several discussions with many different folks last week at IETF 67 in San Diego, as well as various people over the course of the past few months, Dan Senie and I have decided to undertake an effort to "update" RFC2827/BCP38 [1]. I know that I'm not the only person who has heard various discussions in the past couple of years that concluded that (paraphrased), "BCP38 needs to be updated." Now is your chance to speak up. :-) We would very much like to solicit comments & suggestions from the community-at-large on areas where you feel BCP38 is lacking, or in areas where you feel it does not properly address with regards to prohibiting source-spoofed traffic from any given administrative network boundary, given that some technical aspects of the Internet may have changed since it's publication. While we acknowledge that a uniform application of a source address verification architecture/ingress filtering scheme will not mitigate _all_ "unwanted traffic" [2] in the Internet, it will most certainly address the issue of hosts which attempt to source-spoof traffic into the Internet. I have not set up a mailing list for this yet, but if there is enough discussion/input, I will make an effort to do so (or perhaps the SAVA mailing list [3] might be a good place for discussion). In the interim, you can contact me or Dan directly: Paul Ferguson: fergdawg(at)netzero.net Dan Senie: dts(at)senie.com Thanks, fergie & dan p.s. Also, for anyone who might be interesting in related work, there is an effort to bring some additional work into the IETF called SAVA, or Source Address Validation Architecture [4]. [1] http://www.rfc-editor.org/rfc/rfc2827.txt [2] http://www.iab.org/about/workshops/unwantedtraffic/index.html [3] http://www.nrc.tsinghua.edu.cn/mailman/listinfo/sava [4] http://www.nrc.tsinghua.edu.cn/pipermail/sava/2006-September/000004.html -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/

1 0

RE: IP adresss management verification
by David Hubbard 13 Nov '06

13 Nov '06

From: chuck goolsbee > > ** I assume it is myth, but I've never heard anyone from Google make > any statements that definitively debunks it. Debunking this pervasive > among webmasters and "SEO Experts" myth sure would be a very UN-evil > thing to do if true (Hint hint you Google-folk!) > Actually they did, once, in an obscure place: http://interviews.slashdot.org/interviews/02/07/03/1352239.shtml Whenever I refer customers to that, they just tell me oh, that's from 2002, my SEO person knows that Google penalizes for sharing IP's now. I guess Google needs a time stamped banner on their site that says "As of <time>, we do not penalize for sharing IP's." so SEO 'experts' can't argue it. David

1 0

Re: IP adresss management verification
by Kanagaraj Krishna 13 Nov '06

13 Nov '06

Hi, I'm curious on how regional RIR which allocates ip address, verifies the usage pattern info provided by their members in their application process. Especially ISP requesting for additional allocations (80% utilization, adhered policies etc). Thanks. Regards, Kana

7 6

RE: IP adresss management verification
by David Hubbard 13 Nov '06

13 Nov '06

From: Michael.Dillon(a)btradianz.com > > It's quite simple, really. > > They ask for it. > > If the iformation that you provided with your application > does not answer their questions, they ask you for more > information. I assume that all the RIRs will sign an > NDA with you, certainly ARIN does this. ARIN may also > ask for corporate confidential information in order to > verify your application so they have strict internal > security policies to keep it confidential. > > Some people send detailed network diagrams, purchase > orders for routers/switches/circuits, sales history > data with projected trends, customer lists, etc. > > If you need specific details, just ask your RIR. > Is the policy still that dedicated IP addresses for web hosts *should* only be used when technical justification exists? I really wish it would change to a requirement as we very frequently get new hosting customers who get angry when they find their site that doesn't have SSL or any other technical reason for a dedicated IP ends up on a shared IP when their old host didn't do that or would sell them a dedicated IP for $5/month, etc. David

2 1

Re: The Cidr Report
by Fergie 12 Nov '06

12 Nov '06

Indeed -- it apears to have flaked out a bit this (IETF) week. :-) Date Prefixes CIDR Aggregated 04-11-06 199323 129829 05-11-06 199330 129854 06-11-06 199273 129854 07-11-06 -1077937252 129854 08-11-06 -1077936760 129854 09-11-06 672037797 129854 10-11-06 -1077937324 129854 11-11-06 134555024 129854 - ferg -- Simon Leinen <simon(a)limmat.switch.ch> wrote: cidr-report writes: > Recent Table History > Date Prefixes CIDR Agg > 03-11-06 199409 129843 [...] > 10-11-06 134555024 129854 Growth of the "global routing table" really picked up pace this week! (But maybe I'm just hallucinating for having heard the report from the IAB Routing Workshop report three times in a week :-) Or the CIDR Report software has an R200K problem? -- Simon. -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/

3 3