April 2014 - Test - lists.nanog.org

Re: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post
by Larry Sheldon 25 Apr '14

25 Apr '14

On 4/24/2014 10:44 PM, Patrick W. Gilmore wrote: > On Apr 24, 2014, at 23:38 , Larry Sheldon <LarrySheldon(a)cox.net> > wrote: >> On 4/24/2014 10:23 PM, Patrick W. Gilmore wrote: > >>> The invisible hand of the market cannot fix problems when there >>> is a monopoly. >>> >>> Put in economic terms, a player with Market Power is extracting >>> Rents. (Capitalization is intentional.) >>> >>> Regulating monopolies allows a market to work, not the opposite. >> >> Regulating monopolies protects monopolies from competition. >> >> Monopolies can not persist without regulation. > > You are confused. No. I am not. > Unless you are talking about "persist" on a time horizon spanning > generations. A monopoly can persist, as a maximum, as long as regulation protects it. Just look at the words! "Regulated Monopoly" has no definition without a monopoly. If so, then nothing can persist, with or without > regulation. And more importantly, I am not willing to wait that long > for a fix. "fix" is another monopoly preserver. >> A regulated monopoly is a monopoly, with all of the powers granted >> to monopolies by regulation. > > Regulations can work to ensure monopolies do not form. This is not > supposition, but historical fact. There is no case where regulation of monopolies prevented monopolies. The sentence doesn't even make any sense. If that were actually true, there couldn't be any "regulated monopolies" could there? > It is an open question whether our current regulator regime is > capable of repeating that feat, however. There are a number of cases in history where the absence of regulation has prevented monopolies. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)

3 2

Re: Phase 4.
by Don Brearley 24 Apr '14

24 Apr '14

This thread pulled a good chuckle out of me... thanks guys :) Bryan, cheers. :) - Don >>> Warren Bailey 04/24/14 9:21 AM >>> Bryan is accepting bloody Mary donations this morning. Sent from my T-Mobile 4G LTE Device -------- Original message -------- From: Jim Popovitch Date: 04/24/2014 6:30 AM (GMT-07:00) To: Clayton Zekelman Cc: nanog list Subject: Re: Phase 4. On Thu, Apr 24, 2014 at 8:23 AM, Clayton Zekelman wrote: > > Can someone please check the NANOG mailing list Universal Translator? I > think it is broken. I think you mean a NANOG liver is broken. -Jim P.

1 0

IPv4 Address transfer after company acquisition
by John Jackson 24 Apr '14

24 Apr '14

I have a customer who previously didn't have any IPv4 address space. They recently acquired a competitor that has a /24. Are there any special ARIN rules for this type of transfer? Any pointers, or 'gotchas'? Thanks John

4 3

Re: Phase 4.
by Clayton Zekelman 24 Apr '14

24 Apr '14

Can someone please check the NANOG mailing list Universal Translator? I think it is broken. At 01:54 AM 24/04/2014, Bryan Socha wrote: >Whats the big deal???? If your just arin, dont panic. Akamai and >digitalocean has been the only people aquire fair priced v4 putside >arin. So arin is ending. It doesnt stop anything. be smart 3 usd >per ip is fair if dirty. F the auct8ons they are fake and we get the ips >lower than op3ning. > >Icann is the mast 8 class as real? Distribute them >, --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409

3 2

nanong list spam filtering
by Michael DeMan 24 Apr '14

24 Apr '14

Hi All, Sorry being a bit off-topic and having a boring subject, but we really should clean up whatever has been going on with so much spam hitting this mailing list. NO - I am complaining about people who post things I disagree with or on topics I have little interest in, I am tired of the stuff like... subject: Top rated...wireless security cameras--for both indoor & outdoor subject: Save on: Hawaii, vacation packages (classic) subject: Compare: the best, email marketing services subject: Cards reward plans\rates compared(MC-Capital1-Venture-ChaseFreedom-Citicard-BankAmericard-Discover-Visa) ...and what not. Has it always been the policy perhaps that this mailing list does no spam filtering whatsoever? If so that would be understandable. Meanwhile I think would be better for the community if at least some of the most egregious and obvious stuff did not have cpu and network cycles spent forwarding it onwards? As always, I could imagine that although I think this is simple it could be a politically charged debate. Cheers and please fix if possible, - Michael DeMan

2 2

ARIN Enters Phase Four of the IPv4 Countdown Plan
by John Curran 23 Apr '14

23 Apr '14

NANOGers - ARIN's regional IPv4 free pool has reached the equivalent of one /8 of IPv4 space, which means we are approaching runout of IPv4 space availability in this region. (See attached announcement from ARIN regarding occurrence of this event) There are some changes to processing of requests as we enter this final phase, and obviously service providers ought to be thinking about IPv6-based services, if not already in deployment. FYI, /John John Curran President and CEO ARIN Begin forwarded message: From: ARIN <info(a)arin.net<mailto:info@arin.net>> Subject: [arin-announce] ARIN Enters Phase Four of the IPv4 Countdown Plan Date: April 23, 2014 at 10:00:20 AM GMT-3 To: arin-announce(a)arin.net<mailto:arin-announce@arin.net> ARIN is down to its final /8 of available space in its inventory and has moved into Phase Four of its IPv4 Countdown Plan. All IPv4 requests are now subject to Countdown Plan processes, so please review the following details carefully. All IPv4 requests will be processed on a "First in, First out" basis, and all requests of any size will be subject to team review, and requests for /15 or larger will require department director approval. ARIN's resource analysts will respond to tickets as they appear chronologically in the queue. Each ticket response is treated as an individual transaction, so the completion time of a single request may vary based on customer response times and the number of requests waiting in the queue. Because each correspondence will be processed in sequence, it is possible that response times may exceed our usual two-day turnaround. The hold period for returned, reclaimed, and revoked blocks is now reduced to 60 days. All returned, revoked, and reclaimed IPv4 address space will go back into the available pool when the 60 day period has expired. Staff will continue to check routing/filtering on space being reissued and will notify recipients if there are issues. When a request is approved, the recipient will have 60 days to complete payment and/or an RSA. On the 61st day, the address space will be released back to the available pool if payment and RSA are not completed. We encourage you to visit the IPv4 Countdown Phase Four page at: https://www.arin.net/resources/request/countdown_phase4.html ARIN may experience situations where it can no longer fulfill qualifying IPv4 requests due to a lack of inventory of the desired block size. At that time, the requester may opt to accept the largest available block size or they may ask to be placed on the Waiting List for Unmet Requests. Full details about this process are available at: https://www.arin.net/resources/request/waiting_list.html Please contact hostmaster(a)arin.net or our Help Desk +1.703.227.0660 if you have questions about these procedural changes. Regards, Leslie Nobile Director, Registration Services American Registry for Internet Numbers (ARIN) _______________________________________________ ARIN-Announce You are receiving this message because you are subscribed to the ARIN Announce Mailing List (ARIN-announce(a)arin.net) Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-announce Please contact info(a)arin.net if you experience any issues.

5 5

Re: AOL Mail updates DMARC policy to 'reject'
by Larry Sheldon 23 Apr '14

23 Apr '14

On 4/23/2014 12:45 AM, Grant Ridder wrote: > Thought i would throw this out there. > http://postmaster-blog.aol.com/2014/04/22/aol-mail-updates-dmarc-policy-to-… Bet THAT will get Yahoo's attention! -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)

2 1

Someone with IP clue @Suddenlink please contact me
by Charles N. Wyble 22 Apr '14

22 Apr '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello all, Anyone from Suddenlink on this list? If so, please contact me unicast. I'm seeing some very significant issues originating in your network core and want to get them sorted out. The normal channels haven't been helpful. Yes I'm a downstream customer. Thanks! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTVwDvAAoJEMvvG/TyLEAtS7wQAJeK2dnSlelTM5uL7FiUHzxN bKIMXgGdcT4rbP1vvNnLH9kRTUQC7gTHAUbhCxaTjEhhNJKEzlsRR9b1d7nxCaKv 2m1knsb793CI/AbaRG0WUBxpXOvYoQicRMjht5ynoL5jSVzL+HmgMUF7LBdFBH8g 8MnS+3LVb1B120NvPobuzMGdcz4reg4L78MHJFUDVRWKp47u0adKpEacGHMcahz8 CJzECfD8Z7gQfLpup8kIpl/ZzxlQwvfdR4oUBSaaqVK0OBILE0TXZ5erqxn2zlCx 4KJMF8jhVNNs54KBSpXo+qCCcRCCZ663EVaSnSAzT6ODJwk+QpLua/NZXWstn2AS 9e8bMpa10yjbzlXSLYYjaAgvHeRUJ/CFm3pZR8iitYNUt8yU5Br38R3RZFKRFUBB ionEmuMU4XjdhYSJrtbZ+Ag2CDEOidOP7LXTt+Wf7GMeII+kE18LJX03QE1/cxxu ErWPaWDTb7fl4RkUcQ6E+QUSzR6ib+WCgFj7SZ41jm8HXr9U09FkXYTnU2AcJULn y0PI1/9x66kCi64mZE03qBC5nv+M/vaFT/w9y1kL8KJxXCkY/4Qz8tdilB2SsBvc R1gVDnyjWzNN0p7mqM4ZlruSPQlJyENzF8Zf/ksPM/DFY19bxE6pH4RKMmz6kpIf i4cU78SeVaa7ETXm7auO =lhNi -----END PGP SIGNATURE-----

1 0

New RIPE NCC contribution to the IANA IPv4 Recovered Address Space registry
by Leo Vegoda 22 Apr '14

22 Apr '14

Hi, In April 2014, ICANN updated the IANA IPv4 Recovered Address Space registry to reflect the return of 14 /24 prefixes (5,376 IPv4 addresses) by the RIPE NCC. The updated registry can be found at: https://www.iana.org/assignments/ipv4-recovered-address-space Kind regards, Leo Vegoda ICANN IANA

1 0

Re: Requirements for IPv6 Firewalls
by Christopher Morrow 22 Apr '14

22 Apr '14

On Tue, Apr 22, 2014 at 3:41 PM, Matthew Huff <Matthew.Huff(a)ox.com> wrote: > I think some of the disconnect is the difference between a provider network and a corporate one. > > For example, www.foo.com if it is highly visible and has a high traffic rate would have load balancers and line rate routers, but no statefull firewalls. > > Corporate foo.com, on the other hand, where end-users, and internal servers reside, almost certainly has a statefull firewall. > doesn't this come down to design of the whole system though? or rather, I bet roland would point out that this comes down to the design of the whole system... and tradeoffs folk decide to make/break. watching a corporate mail server complex melt down because some 'well intentioned admin' put a stateful firewall (with a single rule; "permit smtp"!) in front of the mail servers ... Having to explain to them (and losing because 'policy') that 'permit tcp any any eq 25' was more effective and better for their systems health was quite painful. eventually the CIO didn't listen and he works elsewhere. > Personally, if I were told to use only host based security on a corporate network and no central administrated firewall, I'd be shopping my resume. why? sure there's a place for things like firewalls, but there's also a fine place for just 'drop packets with filters and don't maintain state'. it really comes down to the design goals of the whole system. -chris > > > ---- > Matthew Huff | 1 Manhattanville Rd > Director of Operations | Purchase, NY 10577 > OTA Management LLC | Phone: 914-460-4039 > > -----Original Message----- > From: Christopher Morrow [mailto:morrowc.lists@gmail.com] > Sent: Tuesday, April 22, 2014 3:18 PM > To: Brian Johnson > Cc: nanog(a)nanog.org > Subject: Re: Requirements for IPv6 Firewalls > > On Tue, Apr 22, 2014 at 2:55 PM, Brian Johnson <bjohnson(a)drtel.com> wrote: >> Eric, >> >> If you read what he posted and really believe that is what he is saying, you need to re-think your career decision. It is obvious that he is not saying that. >> > > Roland's saying basically: > 1) if you deploy something on 'the internet' you should secure that something > 2) the securing of that 'thing' should NOT be be placing a stateful device between your users and the 'thing'. > > In a simple case of: > "Put a web server on the internet" > > Roland's advice breaks down to: > 1) deploy server > 2) put acl on upstream router like: > permit tcp any any eq 80 > deny ip any any > 3) profit > > The router + acl will process line-rate traffic without care. > > -chris > >> I hate it when threads breakdown to this type of tripe and ridiculous restatement of untruths. >> >> - Brian >> >>> -----Original Message----- >>> From: Eric Wieling [mailto:EWieling@nyigc.com] >>> Sent: Tuesday, April 22, 2014 1:16 PM >>> To: Dobbins, Roland; nanog(a)nanog.org >>> Subject: RE: Requirements for IPv6 Firewalls >>> >>> It seems to me you are saying we should get rid of firewalls and rely >>> on applications network security. >>> >>> This is so utterly idiotic I must be misunderstanding something. There are a >>> few things we can count on in life, death, taxes, and application >>> developers leaving giant security holes in their applications. >>> >>> -----Original Message----- >>> From: Dobbins, Roland [mailto:rdobbins@arbor.net] >>> Sent: Saturday, April 19, 2014 12:10 AM >>> To: nanog(a)nanog.org >>> Subject: Re: Requirements for IPv6 Firewalls >>> >>> You can 'call' it all you like - but people who actually want to keep >>> their servers up and running don't put stateful firewalls in front of >>> them, because it's very easy to knock them over due to state >>> exhaustion. In fact, it's far easier to knock them over than to knock over properly-tuned naked hosts. >>> >>> Also, you might want to search the NANOG email archive on this topic. >>> There's lots of previous discussion, which boils down to the fact >>> that serious organizations running serious applications/services >>> don't put stateful firewalls (or 'IPS', or NATs, et. al.) in front of their servers. >>> >>> The only way to secure hosts/applications/service against compromise >>> is via those hosts/applications/services themselves. Inserting >>> stateful middleboxes doesn't actually accomplish anything to enhance >>> confidentiality and integrity, actually increases the attack surface >>> due to middlebox exploits (read the numerous security notices for >>> various commercial and open-source stateful firewalls for compromise >>> exploits), and has a negative impact on availability. >>> >>> >> >> >

5 5