Re: DNS Issue with proofpoint.com
On Wed, Apr 16, 2014 at 10:49:24AM -0400, William Herrin wrote: On Wed, Apr 16, 2014 at 10:45 AM, TGLASSEY tglas...@earthlink.net wrote: Wouldn't it make sense if we created a specific mail alias for requesting DNS flushes? This seems to happen statistically often enough it might be a valuable service to bundle under the NANOG umbrella. What would make sense is some sort of attribute on the DNS record which instructed servers not to cache it for so long that mistakes have a lasting impact. PEBKAC, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004 per RFC 1035: example.com.INSOA ns.example.com. hostmaster.example.com. ( 2003080800 ; sn = serial number 172800 ; ref = refresh = 2d 900; ret = update retry = 15m 1209600; ex = expiry = 2w 3600 ; nx = nxdomain ttl = 1h )
Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
On Mon, Apr 14, 2014 at 03:59:21PM -0400, Patrick W. Gilmore wrote: On Apr 14, 2014, at 15:47 , Scott Howard sc...@doc.net.au wrote: On Sun, Apr 13, 2014 at 9:52 AM, Niels Bakker niels=na...@bakker.netwrote: At least one vendor, Akamai is helping out now: http://marc.info/?l=openssl-usersm=139723710923076w=2 I hope other vendors will follow suit. Although it appears they may now be regretting doing so... http://www.techworld.com.au/article/542813/akamai_admits_its_openssl_patch_faulty_reissues_keys/ (Of course, the end result is positive, but...) [NOTE: I'll just remind everyone up front that I worked at Akamai for a very long time, so take my comments with however many grains of salt you feel appropriate.] If the only thing that happens when a large company steps up to help the open source community is ridicule and/or derision, one should probably not in the same breath ask why no companies are publishing any code. I applaud Akamai for trying, for being courageous enough to post code, and for bucking the trend so many other companies are following by being more secretive every year. Or we can flame anyone who tries, then wonder why no one is trying. -- TTFN, patrick well, if $vendor publishes code frags, the code must have been vetted and ready for _my_ environment so i'll just cut/paste and then when it doesn't work, its their fault for leading me down the primrose path... $vendor, that why I pay you... to read my mind! darn it. /bill
Re: [[Infowarrior] - NSA blah blah blah blah....
On Mon, Apr 14, 2014 at 07:47:46PM -0700, Doug Barton wrote: It must be quite a while. Unix systems have routinely cleared the RAM and disk allocated to programs since the earliest days. When you say clear the disk allocated to programs what do you mean exactly? On a clear disc, you can seek forever - with apologies to Barbara S. /bill
Re: Yahoo DMARC breakage
On Wed, Apr 09, 2014 at 05:49:27PM -0400, Jeff Kell wrote: The most sane out-of-mind response should only be sent *if* the out-of-mind person is named explicitly as a recipient in the RFC822 header. Anything To: somelist@somehost does not qualify :) Jeff and just how is an algorithm supposed to detect that jeff-k...@utc.edu is a single human and not a list? /bill
Re: Serious bug in ubiquitous OpenSSL library: Heartbleed
On Tue, Apr 08, 2014 at 05:56:45PM -0600, Me wrote: On 04/08/2014 10:16 AM, Patrick W. Gilmore wrote: Lots of tools available. I'm with ferg, surprised more haven't been mentioned here. Tools to check for the bug: • on your own box: https://github.com/musalbas/heartbleed-masstest/blob/master/ssltest.py • online: http://filippo.io/Heartbleed/ (use carefully as they might log what you check) • online: http://possible.lv/tools/hb/ • offline: https://github.com/tdussa/heartbleed-masstest --- Tobias Dussa, also Takes a CSV file with host names for input and ports as parameter • offline: http://s3.jspenguin.org/ssltest.py • offline: https://github.com/titanous/heartbleeder List of vulnerable Linux distributions: http://www.circl.lu/pub/tr-21/. Anyone have any more? Thanks for the expanded list, I had some of these already. I'm not comfortable in letting some online code that I can't see test my site though. --John or, there is this: http://git.openssl.org/gitweb/?p=openssl.git /bill
Re: Serious bug in ubiquitous OpenSSL library: Heartbleed
On Tue, Apr 08, 2014 at 11:46:31PM -0400, Rob Seastrom wrote: Me jsch...@flowtools.net writes: Thanks for the expanded list, I had some of these already. I'm not comfortable in letting some online code that I can't see test my site though. If that's true, you might want to consider immediately disconnecting your systems from the Internet and never re-connecting them. After all, theres a lot of online unseen code testing your site already whether you like it or not. -r Diodes /bill
Re: Recommendation on NTP appliances/devices
Loves my old Heathkit WWVB unit. Keeps drift in check most days. Pairs nicely with the Spectracom 9383. Looking at the Microsemi TP-5000 w/ rubidium oscillator. /bill On Thu, Apr 03, 2014 at 10:25:07PM -0400, Rob Seastrom wrote: On a tangential note, it's all very nice to say We have brand X and like them, but I'd be curious to hear from folks who have deployed at least four divergent brands with non-overlapping GPS chip sets and software [*] to keep a conspiracy of errors from causing the time to suddenly be massively incorrect. Not that this has ever happened in the past in a single vendor configuration [cough]. Along the same lines I'm troubled by the lack of divergent sources these days - everything seems slaved to GPS either directly or indirectly (might be nice to have stuff out there that got its time exclusively via Galileo or Glonass). The sole exception that I can think of offhand is that I have an office within ground wave of WWVB, which would be a tasty ingredient. GOES is gone. LORAN is defunded. And so it goes; all our eggs are in one basket. I've thought about posting this request to the NTP developers list, but maybe someone who's an operator and actually cares about keeping the byzantine generals sequestered from each other has solved this problem recently. Clues? -r [*] to the extent possible; I'm sure that there's a lot of reference implementation DNA floating around out there) Berry Mobley be...@gadsdenst.org writes: We have symmetricom (now microsemi) and are very happy with them, but we use the roof mounted gps antennas. They will peer with public ntp severs if that would work for you. David Hubbard dhubb...@dino.hostasaurus.com wrote: Anyone have recommendations on NTP appliances; i.e. make, model, gps vs cell, etc.? Roof/outdoor/window access not available. Would ideally need to be able to handle bursts of up to a few thousand simultaneous queries. Needs IPv6 support. Thanks!
Re: real-world data about fragmentation
I can send you a copy of an invited presentation at AINTEC from 2009. /bill On Wed, Apr 02, 2014 at 02:14:22PM -0400, Joe Abley wrote: Hi all, It's common wisdom that a datagram that needs to be fragmented between endpoints (because it is bigger than the path MTU) will demonstrate less reliable delivery and reassembly than a datagram that doesn't need to be fragmented, because math, firewall, other, take your pick. Is anybody aware of any wide-scale studies that examine the probability of fragmentation of datagrams of different sizes? For example, I could reasonable expect an IPv4 packet of 576 bytes not to be fragmented very often (to choose a size not at random). The probability of a 10,000 octet IPv4 packet getting fragmented seems likely to be 100%, if we're talking about arbitrary paths across the Internet. What does the curve look like between 576 bytes and 10,000 bytes? I might expect exciting curve action around 1500 bytes (because ethernet), 1492 (PPPoE), 1480 (GRE), etc. But I'm interested in actual data. Anybody have any pointers? IPv4 and IPv6 are both interesting. Joe
Re: misunderstanding scale
On Sun, Mar 23, 2014 at 04:27:16PM -0500, Timothy Morizot wrote: On Mar 23, 2014 11:27 AM, Paul Ferguson fergdawgs...@mykolab.com wrote: Also, IPv6 introduces some serious security concerns, and until they are properly addressed, they will be a serious barrier to even considering it. And that is pure FUD. The sorts of security risks with IPv6 are mostly in the same sorts of categories as those with IPv4 and have appropriate mitigations available. Moreover, by not enabling and controlling IPv6 on their networks, an operator is actually markedly more vulnerable to IPv6 attacks, not less. Scott Yo, Tim/Scott. Seems you have not been keeping up. http://go6.si/wp-content/uploads/2011/11/DREN-6-Slo-IPv6Summit-2011.pdf points out several unique problems w/ IPv6 and in deployments where there are ZERO IPv4 equivalents. Ferg is paranoid, but it doesn;t mean they are not out to get him/IPv6. /bill
Re: misunderstanding scale
On Sun, Mar 23, 2014 at 10:31:57PM +, Nick Hilliard wrote: On 23/03/2014 21:02, Mark Andrews wrote: Actually all you have stated in that printer vendors need to clean up their act and not that one shouldn't expect to be able to expose a printer to the world. It isn't hard to do this correctly. perish the thought - and I look forward to the day that vendors write secure software which is impregnable to all vulnerabilities past and present. When that happens, I'll cast away my default deny configurations and advise other people to do the same. Until then, though, I hope you understand why I suggest that default deny is no less sensible a precaution than locking the front door in a busy city. Nick Hum.. perhaps a poor analogy. Tokyo is a busy city, yet I know quite a few people who don;t lock their doors there. Redondo Beach is quite a bit less busy, but -everyone- locks their doors and anything else of value. Its the culture of ethics of the individiual, not the density of individuals. /bill
Re: [dns-wg] Global Vs local node data in www.root-servers.org
On Mon, Mar 17, 2014 at 11:11:40AM -0400, Joe Abley wrote: On 17 Mar 2014, at 10:27, manning bill bmann...@isi.edu wrote: alas, our service predates Joe’s marvelous text. “B” provides its services locally to its upstream ISPs. We don’t play routing tricks, impose routing policy, or attempt to influence prefix announcement. In the taxonomy I just shared, that makes the origin nodes of B all global nodes. To clarify though, I certainly wasn't trying to suggest that the things I described were new or original when I was writing in 2003. Anycast had already been in use for quite some time by a variety of people at that time. It's specifically the terms local and global in a DNS anycast context that I was apologising for :-) Joe No apology needed. I was clarifying why B is listed as a local node. That it doesn't fit you taxonomy is fine - but it does need an explaination. /bill
Re: DNS Resolving issues. So for related just to Cox. But could be larger.
RFC 2182 On Mon, Mar 10, 2014 at 02:57:06PM -0400, Rob Seastrom wrote: Larry Sheldon larryshel...@cox.net writes: On 3/7/2014 5:03 AM, Rob Seastrom wrote: for decades. i have a vague recollection of an rfc that said secondary nameservers ought not be connected to the same psn (remember those?) but my google fu fails me this early in the morning. Packet Switch Node? Not sure what would be in this context. Not on the same router? How about two routers away with both THEM on the same router (a third one)? A PSN or IMP was an ARPANET/MILNET core router. Some sites had more than one. A reasonable carry-forward of the concept would be that nameservers ought to be geographically and topologically diverse so as to avoid fate-sharing. Different upstreams, different coasts (maybe different continents?), different covering prefixes, and certainly not on the same IPv4 /32... would be the intelligent thing to do particularly if one wants to query nanog@ about operational hinkiness and not be on the receiving end of derisive chuckles. Not on a host that does anything else? Both of those actually make some sense to me, the first from a single point of failure consideration, the second regarding unrelated failures (I have to re-boot my windows PC at least once a day, most days because Firefox, the way I use it, gets itself tangled about that often and a reboot is the quickest way to clear it). Can't hurt to have authoritative nameservers on dedicated VMs (enterprise guys running AD have my sympathies), but that's not what we're talking about here. -r
Re: DNS Resolving issues. So for related just to Cox. But could be larger.
On Thu, Mar 06, 2014 at 08:07:55AM -0500, Rob Seastrom wrote: Nick Hilliard n...@foobar.org writes: haven't you heard about anycast?? rs probably has. The owner of 199.73.57.122, probably not. indeed. there are many pieces of evidence that this is not an anycast prefix. proof is left as an exercise to those who can perform traceroutes from multiple continents, run nmap -sP, log into route-views, or do some combination of the above. -r sorry for the poor attempt at humour... it was ancient practice to hang many names (not cnames) off a single IP address. all perfectly legal from a DNS POV. rs.example.org. in a 10.10.10.53 nick.example.com. in a 10.10.10.53 bbss.isc.org. in a 10.10.10.53 the punchline here was anycasting the address across multiple names. nary a routing trick in sight or in play. Lame I know. as a tool to defeat the autobots who insist on two nameservers for a delegation - its kind of a clever poke in the eye w/ a sharp stick. Back to my oubliette /bill
Re: DNS Resolving issues. So for related just to Cox. But could be larger.
On Wed, Mar 05, 2014 at 07:52:10AM -0500, Rob Seastrom wrote: Paul S. cont...@winterei.se writes: For all it's worth, it might be Cox ignoring TTLs and enforcing their own update times instead. Wait 24-48 hours, and it should probably fix it all up. Possibly. I'm not seeing anything majorly broken with your system except the SOA EXPIRE being ridiculously large. Nowhere even close to ridiculously large. 360 (1 hours, 41 days) is the historical example value in RFC 1035. It's a bit larger than current recommended practices (2-4 weeks) but I wouldn't fault anyone for using that value nor would I expect any nameserver software to malfunction when confronted it. Besides, that value only matters to secondary nameservers. Speaking of that... ;; ADDITIONAL SECTION: ns1.nineplanetshosting.com. 172800 IN A 199.73.57.122 ns2.nineplanetshosting.com. 172800 IN A 199.73.57.122 I think OP ought to approach his hoster with a cluebat. Not just on the same subnet but the same address? Really. -r haven't you heard about anycast?? /bill
[5350-5470 MHz]
if you have comments or feedback - Forwarded message from Julie N - Date: Wed, 19 Feb 2014 21:34:51 + Subject: 5350-5470 MHz Dear Members, As you know, we have been actively engaged in the International Telecommunication Union's (ITU) Joint Task Group (JTG) studies to consider additional spectrum allocations to the mobile service for terrestrial mobile broadband applications and identification of frequency bands for International Mobile Telecommunications (IMT) at the 2015 World Radiocommunication Conference (WRC-15). The United States is currently considering 5350-5470 MHz for Unlicensed National Information Infrastructure (U-NII) devices radio local area networks (RLANs). We are working with NTIA, FCC, federal agencies and industry to ensure that the necessary analyses are completed and interference avoidance or mitigation techniques are developed and demonstrated in time to resolve concerns and to develop international support for a U.S. position. I am attaching a letter from Ambassador Sepulveda containing important information about this band and our commitment to working with you to mobilize spectrum for wireless broadband. I look forward to working with you on this and many other important WRC-15 issues. Best regards, Julie This email is UNCLASSIFIED. - End forwarded message -
Re: Email Server and DNS
On Fri, Nov 08, 2013 at 08:37:32AM -0500, William Herrin wrote: On Sun, Nov 3, 2013 at 11:39 AM, rw...@ropeguru.com wrote: I am looking for some info on current practice for an email server and SMTP delivery. It has been a while since I have had to setup an email server and I have been tasked with setting up a small one for a friend. My question centers around the server sending outgoing email and the current practices requirements for other servers to accept email Things like rDNS, SPF records, etc... Hi Robert, Current best practices are: don't run your own email server unless you're willing to spend the ongoing time and effort it takes to keep up with the current solutions to the spam, hacking and abuse problems. Corollary: when you get bored of doing so for a tiny mail server, stop running it and buy a service. and yet, at the IETF this week, in the technical plenary, a call to diffuse the target space by running your own services. much harder to have your mail scrapped from your servers than from your providers. /bill Other than that, the _changes_ of note in the last decade are: 1. The blacklist aggregators and IP reputation services have changed so you have to find the new ones, 2. There are email whitelist services now, some free others for a nominal cost. Use them. 3. Phishing and spear phishing are relatively sophisticated now, so your spam solution has to deal reasonably with it. 4. Relay from and to an external address without changing the envelope sender no longer functions reliably due to things like SPF enforcement and no mail servers I've noticed have such a translator built in. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
[pfsi...@gmail.com: [APRICOT-INFO] APRICOT 2014 call for papers]
of possible interest. /bill - Forwarded message from Philip Smith pfsi...@gmail.com - X-Mailman-Approved-At: Tue, 05 Nov 2013 19:37:41 +1000 Subject: [APRICOT-INFO] APRICOT 2014 call for papers Hi everyone, We have just released the call for presentations for APRICOT 2014. Please consider presenting at APRICOT, or encourage a colleague or friend to do so. Also we'd really appreciate it if you would help inform members of your local operations community about this CfP. Many thanks! Philip, Mark, Dean APRICOT PC Chairs -- Asia Pacific Regional Internet Conference on Operational Technologies (APRICOT) 18 - 28 February 2014, Bangkok, Thailand https://2014.apricot.net CALL FOR PAPERS === The APRICOT 2014 Programme Committee is now seeking contributions for Presentations and Tutorials for APRICOT 2014. We are looking for presenters who would: - Offer a technical tutorial on an appropriate topic; - Participate in the technical conference sessions as a speaker; - Convene and chair panel sessions of relevant topics. Please submit on-line at: http://papers.apricot.net/user/login.php?event=6 CONFERENCE MILESTONES - Call for Papers Opens: 1 November 2013 First Draft Programme Published: 6 December 2013 Final Deadline for Submissions:7 February 2014 Final Programme Published:14 February 2014 Final Slides Received:21 February 2014 PROGRAMME MATERIAL -- The APRICOT Programme is organised in three parts, including workshops, tutorials and the conference. Topics for tutorials and the conference must be relevant to Internet Operations and Technologies: - IPv4 / IPv6 Routing and operations - IPv6 deployment and transition technologies - Internet backbone operations - ISP and Carrier services - IXPs and Peering - Research on Internet Operations and Deployment - Thai Internet - Network security issues (NSP-SEC, DDoS, Anti-Spam, Anti-Malware) - DNS / DNSSEC - Internet policy (Security, Regulation, Content Management, Addressing, etc) - Access and Transport Technologies, including Cable/DSL, 3G/LTE, wireless, metro ethernet, fibre, MPLS - Content Service Delivery (Multicast, Voice, Video, telepresence, Gaming) and Cloud Computing CfP SUBMISSION -- Draft slides for both tutorials and conference sessions MUST be provided with CfP submissions otherwise the Programme Committee will be unable to review the submission. For work in progress, the most current information available at time of submission is acceptable. All draft and complete slides must be submitted in PDF format only. Final slides are to be provided by the specified deadline for publication on the APRICOT website. Prospective presenters should note that the majority of speaking slots will be filled well before the final submission deadline. The PC will retain a limited number of slots up to the final submission deadline for presentations that are exceptionally timely, important, or of critical operational importance. Please submit on-line at: http://papers.apricot.net/user/login.php?event=6 Any questions or concerns should be addressed to the Programme Committee by e-mail at: pc-chairs at apricot.net We look forward to receiving your presentation proposals. Dean Pemberton, Mark Tinka Philip Smith Co-Chairs, APRICOT Programme Committee pc-cha...@apricot.net -- ___ Apricot-info mailing list apricot-i...@apricot.net http://mailman.apnic.net/mailman/listinfo/apricot-info - End forwarded message -
Re: Email Server and DNS
On Sun, Nov 03, 2013 at 08:49:32AM -0800, Private Sender wrote: On 11/3/2013 8:39 AM, rw...@ropeguru.com wrote: I am looking for some info on current practice for an email server and SMTP delivery. It has been a while since I have had to setup an email server and I have been tasked with setting up a small one for a friend. My question centers around the server sending outgoing email and the current practices requirements for other servers to accept email Things like rDNS, SPF records, etc... I am pretty much set on the issue of incoming spam and virus. Probably overkill but it is checked at the Sophos UTM firewall and at the email server itself. Thanks, Robert MX, PTR, and SPF are really all you need. I would recommend you go a step further and use DKIM, ADSP, and DMARC. It will help keep asshat spammers from flaming your domain all over the internet. I use http://www.unlocktheinbox.com/ to verify my configuration. - -- - -Bret Taylor small - so you likely want to avoid the problems of SMTP with thyroid problems. simple is good. practically, you don't need DKIM, ADSP, DMARC or really any quasi reputation systems in play. For that matter you don't need SPF either... PTR's are good to have and an MX can be more useful than not - BUT - none of them are required for a host to received and process SMTP. /bill
Re: Repost: links to DDoS-related press reports.
On Mon, Oct 28, 2013 at 03:29:07PM +, Dobbins, Roland wrote: A couple of folks have asked me privately for links to some presos on DDoS, BCPs, et. al., so I'm re-posting the links here, for future citation: DDoS BCP presos: https://app.box.com/s/4h2l6f4m8is6jnwk28cg 2009 - 2011 Arbor WISRs: https://app.box.com/s/llwlaowbthppliyze2uw Current Arbor WISR: http://www.arbornetworks.com/report --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com and this gem... http://technology.ie/digital-attack-map-shows-ddos-attacks/
Re: comcast ipv6 PTR - DNSSEC
On Mon, Oct 14, 2013 at 10:18:15PM -0500, Jimmy Hess wrote: On Mon, Oct 14, 2013 at 10:01 PM, Barry Shein b...@world.std.com wrote: This would be a lot of work, so nobody does it. If someone asks for the rdns for: 2001:0db8:85a3:0042:1000:8a2e:0370:7334 it's a lot of work for example.com to return something like: 2001-0db8-85a3-0042-1000-8a2e-0370-7334.example.com ? No... it's not a lot of work; the problem is, it's maybe worth even less than the amount of work involved though. What piece of information is being expressed there that would not be expressed by a NXDOMAIN response? Assuming the user is residential .example.com pertains to the ISP, not the hostname at that IP address. The ISP's infois accessible via services such as WHOIS-RWS How about some wildcard PTR record ? *.3.a.5.8.8.b.d.0.1.0.0.2.ip6.arpa PTR unnamedhost.example.com. It's equally useless; and conveys equally limited information about the host. However, at least it doesn't generate spurious records that are just (IP repeated).(domain) -- -JH Forward domains and Reverse domains are often managed by different organizations - so if you were a paranoid validator, wanting to check that the name was from the correct place, you'd want to do DNSSEC validation on both the name and the address. Not going to weigh in on the value proposition. /bill
Re: minimum IPv6 announcement size
back in the good o'l days when we would hand out 24 bits for the number of hosts in a network. It was too many bits then and is too many bits now a /64 is just overkill. /bill On Tue, Oct 01, 2013 at 03:11:39PM -0400, Ryan McIntosh wrote: I'd love to be able to turn the microwave and oven on with my phone.. maybe ten years from now lol.. In all seriousness though (and after skimming some of the other responses), I absolutely understand the ideals and needs amongst conserving memory on our routers for the sake of the future of bgp and internal routing. The problem I described has nothing to do with that however, I was mearly pointing out the fact that the basis of the larger allocations are based upon the fact we're handing over /64's to each vlan/point to point/lan/etc that we're turning up. In practice, I understand, a /64 means that 64 bits can handle a unique ip for every host without having to worry about numbering them, but how many hosts do we truly think will be sitting on one network? Surely not a /64's worth, that alone would cause havoc on a neighbor table's maximum memory limit. Maybe I'm missing the connection here, but I still don't see how a /64 is justified for each individual user/host/server/etc sitting on the edge of the internet that's getting ip's from an upstream provider (not arin/ripe/etc). It's those smaller blocks that justify handing over larger ones, which I do understand there's plenty of, but how long are we going to patch the same problem and not try to fix it right? Ryan On Mon, Sep 30, 2013 at 8:37 PM, Larry Sheldon larryshel...@cox.net wrote: On 9/27/2013 1:10 AM, Ryan McIntosh wrote: I don't respond to many of these threads but I have to say I've contested this one too only to have to beaten into my head that a /64 is appropriate.. it still hasn't stuck, but unfortunately rfc's for other protocols depend on the blocks to now be a /64.. It's a waste, even if we're planning for the future, no one house needs a /64 sitting on their lan.. or at least none I can sensibly think of o_O. Are you accounting for connections to your refrigerator, water heater, razor, vibrator, and on down to list so the gubermint can tell they when you can use power for them? -- 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)
Re: minimum IPv6 announcement size
On Mon, Sep 30, 2013 at 11:27:26AM -0400, William Herrin wrote: On Mon, Sep 30, 2013 at 10:46 AM, TJ trej...@gmail.com wrote: On Mon, Sep 30, 2013 at 9:32 AM, William Herrin b...@herrin.us wrote: IPv4 jumped from 8 bits to 32 bits. Which when you think about it is the same ratio as jumping from 32 bits to 128 bits. Only insofar as the jump from 1 to 1000 is the same as the jump from 1000 is to 100 ... :) If we're on an exponential growth curve, it's the same ratio. Are we? Regards, Bill Herrin sure... and I appreciate you advertizing all that unused dark space for me to hide my spam return addresses in. grateful you have enough bandwidth to absorb the incoming DDoS packets for non-existent hosts. profound thanks. /bill
Re: minimum IPv6 announcement size
sounds just like folks in 1985, talking about IPv4... /bill On Wed, Sep 25, 2013 at 06:45:02AM -0700, Owen DeLong wrote: Each site should get at least a /48. Stop worrying about dense-packing the IP space in IPv6. This is IPv4-think. IPv6 is intended to be sparsely allocated. Owen On Sep 24, 2013, at 8:10 PM, Nathanael C. Cariaga nccari...@stluke.com.ph wrote: Hi, I raised actually this concern during our IP resource application. On a personal note, I think /48 IPv6 allocation is more than enough for our organization to use for at least the next 5-10 years assuming that this can be farmed out to our multiple sites. What makes this complicated for us is that we are operating on a multiple sites (geographically) with each site is doing multi-homing and having a /48 in each site would be very big waste of IP resources. -nathan On 9/25/2013 2:36 AM, Bryan Socha wrote: Everyone is following the same policies. a /48 PER SITE.did you request enough addresses from your RIR? Bryan Socha
Re: minimum IPv6 announcement size
On Thu, Sep 26, 2013 at 12:29:17PM -0700, Darren Pilgrim wrote: On 9/26/2013 1:52 AM, bmann...@vacation.karoshi.com wrote: sounds just like folks in 1985, talking about IPv4... The foundation of that, though, was ignorance of address space exhaustion. IPv4's address space was too small for such large thinking. IPv6 is far beyond enough to use such allocation policies. when concevied, IPv4 was unimaginably large ... /8's were handed out to networks with fewer than 10 devices.Hindsight is 20/20. those who ignore teh past are doomed to repeat it /bill
Re: minimum IPv6 announcement size
Yup. Seen/Heard all that. Even tooted that horn for a while. /64 is an artifical boundary - many/most IANA/RIR delegations are in the top /32 which is functionally the same as handing out traditional /16s. Some RIR client are bigger and demand more, so they get the v6 equvalent of /14s or smaller. Its the _exact_ same model as v4 in the previous decade. With the entire waste in the bottom /64. Its tilting at windmills, but most of the community has drunk the koolaide on wasteful /v6 assignment. What a horrific legacy to hand to our children (and yes, it will hit that soon) /bill On Thu, Sep 26, 2013 at 01:18:50PM -0700, Darren Pilgrim wrote: On 9/26/2013 1:07 PM, joel jaeggli wrote: On Sep 26, 2013, at 12:29 PM, Darren Pilgrim na...@bitfreak.org wrote: On 9/26/2013 1:52 AM, bmann...@vacation.karoshi.com wrote: sounds just like folks in 1985, talking about IPv4... The foundation of that, though, was ignorance of address space exhaustion. IPv4's address space was too small for such large thinking. The first dicussion I could find about ipv4 runnout in email archives is circa 1983 IPv6 is far beyond enough to use such allocation policies. There are certain tendencies towards profligacy that might prematurely influence the question of ipv6 exhaustion and we should be on guard against them allocating enough /48s as part of direct assignments is probably not one of them. That's just it, I really don't think we actually have an exhaustion risk with IPv6. IPv6 is massive beyond massive. Let me explain. We have this idea of the /64 boundary. All those nifty automatic addressing things rely on it. We now have two generations of hardware and software that would more or less break if we did away with it. In essence, we've translated an IPv4 /32 into an IPv6 /64. Not great, but still quite large. Current science says Earth can support ten billion humans. If we let the humans proliferate to three times the theoretical upper limit for Earth's population, a /64 for each human would be at about a /35's worth of /64's. If we're generous with Earth's carrying capacity, a /36. If we handed out /48's instead so each human could give a /64 to each of their devices, it would all fit in a single /52. Those /48's would number existance at a rate of one /64 per human, one /64 per device, and a 65535:1 device:human ratio. That means we could allocate 4000::/3 just for Earth humans and devices and never need another block for that purpose. That's assuming a very high utilisation ratio, of course, but really no worse than IPv4 is currently. The problem isn't allocation density, but router hardware. We need room for route aggregation and other means of compartmentalisation. Is a 10% utilisation rate sparse enough? At 10% utilisation, keeping the allocations to just 4000::/3, we'd need less than a single /60 for all those /48's. If 10% isn't enough, we can go quite a bit farther: - 1% utilisation would fit all those /48's into a /62. - A full /64 of those /48's would be 0.2% utilisation. - 0.1%? We'd have to steal a bit and hand out /47's instead. - /47 is ugly. At /52, we'd get .024% (one per 4096). That's while maintaining a practice of one /64 per human or device with 65535 devices per human. Introduce one /64 per subnet and sub-ppm utilisation is possible. That would be giving a site a /44 and them only ever using the ::/64 of it. Even with sloppy, sparse allocation policies and allowing limitless human and device population growth, we very likely can not exhaust IPv6.
Re: DNS Reliability
On Mon, Sep 16, 2013 at 06:36:22PM +0200, Niels Bakker wrote: * bmann...@vacation.karoshi.com (bmann...@vacation.karoshi.com) [Fri 13 Sep 2013, 22:16 CEST]: from where? to where? what % of the Internet is _not_ reachable from my DNS service at any given time? why is that acceptable? and more importantly, who's job is it to fix/stablize the net so these remote locations can reach my DNS service? we will answer 100% of the valid DNS queries we receive. Is this thread even about authoritative or recursive DNS? -- Niels. Does it matter? /bill
Re: anybody from Amsterdam Internet Exchange (ams-ix) to help?
there is a huge amount of information on the net. have you done any homework? brief summary, an exchange is a shared fate transport where an ISP can exchange traffic with two or more other participants on the exchange. most of the traffic exchange is done via peering with the BGP protocol. Bill Norton has written about peering. Bill Woodcock has built on the old EP.NET data and has a fairly comprehensive set at PCH.NET Current discussion is being held in the OpenIX forums. IXPs are even a part fo the next ITU framework. Care to refine your question a bit? /bill On Thu, Sep 19, 2013 at 08:35:18AM +0330, Shahab Vahabzadeh wrote: Hello Everybody, Is there anybody from Amsterdam IX here? I have some questions about concept of IXP. If anybody else have enough information about IXP's please give me message off the list. Thanks -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator Cell Phone: +1 (415) 871 0742 PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90
Re: DNS Reliability
On Fri, Sep 13, 2013 at 04:01:51PM -0400, Jean-Francois Mezei wrote: On 13-09-12 21:53, Larry Sheldon wrote: I expect 100.000% I'll accept 99.999% or better. At these numbers, one has to start to count failover time. A system can be disaster tolerant but take 2 hours to recover fully, or it could also recover within a couple of seconds. It depends on architecture and available services. And in networking, you also need to consider internal and external routing update propagation times. from where? to where? what % of the Internet is _not_ reachable from my DNS service at any given time? why is that acceptable? and more importantly, who's job is it to fix/stablize the net so these remote locations can reach my DNS service? we will answer 100% of the valid DNS queries we receive. /bill
Re: Internet Surveillance and Boomerang Routing: A Call for Canadian Network Sovereignty
On Sun, Sep 08, 2013 at 04:58:52PM +0900, Randy Bush wrote: Quite frankly, all this chatter about technical 'calls to arms' and whatnot is pointless and distracting (thereby calling into question the motivations behind continued agitation for technical remedies, which clearly won't have any effect whatsoever). cool. then i presume you will continue to run using rc4 and rsa 1024. smart folk over there at arbor. randy nothing better than clear text. pesky crypto just slows things down. /bill`
Re: Vancouver IXP - VanTX - BCNet
On Wed, Aug 21, 2013 at 12:10:32PM -0400, William F. Maton Sotomayor wrote: On Wed, 21 Aug 2013, Clayton Zekelman wrote: Just wondering aloud if an ISP that did have commercial interest could run a non-member driven exchange point successfully as long as they had pricing and policies that were similar to member driven exchange points. Vey interesting that you raise that. IIRC, Albuquerque has NMIX which I think was setup as for-profit. (John Brown are you still here?) Well over a decade ago now, my recollection is fuzzy. I don't recall the reasoning in choosing for-profit over nont-for-profit. [NMIX couldn't pay its bills so it lost a lot of support/clients] /bill wfms
Re: How big is the Internet?
On Fri, Aug 16, 2013 at 12:37:20AM -0400, Sean Donelan wrote: Even the researchers at the Library of Congress, if you give them enough beer and beg them enough, will eventually give you an estimate about the Library collection size as of the end of the last year. What so special about the Internet that it can't be measured? The problem is that is can be measured, along a large number variables. The LOC question, How Big? Might be linear shelf space, sqft, number of items, number of warehouses, number of employees, budget, etc. The base question, How Big needs a qualifier or two. Same with the Internet. How big makes no sense. How much traffic begs the question of measured from where. A unique attribute of IP based transport is that -as far as I know- there is no measurement point between -every- pair of nodes that might exchange traffic. And since the instrumentation does not exist, you'll never get the numbers. Select other vectors and the problem remains, the instrumentation is poor or non-existant. Any numbers that are derived are incomplete and/or estimates. Pick your poision. /bill
Re: How big is the Internet? - about the size of a strawberry
On Wed, Aug 14, 2013 at 10:32:13AM -0400, Sean Donelan wrote: Researchers have complained for years about the lack of good statistics about the internet for a couple fo decades, since the end of NSFNET statistics. What are the current estimates about the size of the Internet, all IP networks including managed IP and private IP, and all telecommunications including analog voice, video, sensor data, etc? CAIDA, ITU, Telegeography and some vendors like Cisco have released forecasts and estimates. There are occasional pieces of information stated by companies in their investor documents (SEC 10-K, etc). thats easy... the number of allocated IPv4 /32s and the number of allocated IPv6 /64s. By definition, private networks (RFC 1918) space is not part of the Internet. Or, is your question actually the absolute number of globally reachable IP addresses at any given instant? (reachable from where?) Or do you mean anything that might have an IP address associated with it at some time in its existance? Clarity would be helpful if you want a repeatable answer. /bill
Re: How big is the Internet?
On Wed, Aug 14, 2013 at 03:00:51PM -0400, Sean Donelan wrote: I should have remembered, NANOG prefers to correct things. So here are several estimates about how much IP/Internet traffic is downloaded in a month. Does anyone have better numbers, or better souces of numbers that can be shared? Arbor/Merit/Michigan Internet Observatory: 9,000 PB/month (2009) Minnesota Internet Traffic Studies: 7,500-12,000 PB/month (2009) Cisco Visual Network Index: Total IP: 55,553 PB/month (2013) Fixed IP: 39,295 PB/month (2013) Managed IP: 14,679 PB/month (2013) Mobile Data: 1,578 PB/month (2013) Telegeography via ITU report: 44,000 PB/month (2012) National Security Agency: 55,680 PB/month (2013) Individual providers/countries Australian Bureau of Statistics (AU only) : 184 PB/month (2012) ATT Big Petabyte report (ATT only): 990 PB/month (2013) CTIA mobile traffic (US only): 69 PB/month (2011) London School of Economics (Europe only): 3,600 PB/month (2012) TATA Communications: 1,600 PB/month (2013) Historical: NSFNET: 0.015 PB/month (1994) Well, the NSFnet numbers did not reflect CSnet or the DoD/ARPA follow on networks, of any of the other IPbased transmission systems of the era. And each of the sources you cite are undoubtedly correct and the best available. Two bits of missing data prevent you from reaching your goal of traffic loading, across all IPbased transmission systems. a) duplicate suppression in the existing datasets. b) access to datasets for unrepresented IPbased transmission systems. You seem to be asking for b. Not sure how to correct for a without direct access to the raw data (and even then, there are issues). Other than more datasets, are you looking at traffic loading graphs, wiht the idea of projecting future loading trends? If so, I'd be interested in your methods since there is some interest in what might be called the southern hemisphere challange. /bill
Re: On topic of domains
On Fri, Jul 12, 2013 at 08:45:50AM +1000, Mark Andrews wrote: In message krmkg2$flc$1...@ger.gmane.org, Chris Hills writes: On 11/07/2013 15:27, Jon Mitchell wrote: After .nyc thread, thought this IAB announcement may be of interest. http://www.iab.org/documents/correspondence-reports-documents/2013-2/iab-st atement-dotless-domains-considered-harmful/ -Jon Whilst I am not a fan of dotless domains, as long as one uses the fully qualified domain name (e.g. http://ac./), there should not be any trouble using it in any sane software. It seems that most people aren't aware these days that a fqdn includes the trailing period (by definition). No it does not. Period at the end is a local convention to stop searching on some platforms. It is not syntactically legal. Note the words 'a sequence of domain labels separated by .'. Periods at the end are NOT legal. RFC 1738 host The fully qualified domain name of a network host, or its IP address as a set of four decimal digit groups separated by .. Fully qualified domain names take the form as described in Section 3.5 of RFC 1034 [13] and Section 2.1 of RFC 1123 [5]: a sequence of domain labels separated by ., each domain label starting and ending with an alphanumerical character and possibly also containing - characters. The rightmost domain label will never start with a digit, though, which syntactically distinguishes all domain names from the IP addresses. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org which explains domains like 3com.net. the trailing dot is not illegal. /bill
Re: Paetec PI space?
f the assignment predated ARIN, then its not clear if current ARIN policy is applicable. On Wed, Jun 26, 2013 at 02:18:54PM -0400, Joe Abley wrote: On 2013-06-26, at 13:52, Adam Greene maill...@webjogger.net wrote: We have a customer who was assigned some PI IPv4 space by Paetec back in mid-90's I think it's correct to say that the only entities that can assign PI IPv4 space are RIRs and the IANA. If I'm right, what you're talking about is PA space, regardless of claims made by your customer or Paetec. Joe
Re: Geoip lookup
On Thu, May 23, 2013 at 11:39:12PM -0700, Owen DeLong wrote: On May 23, 2013, at 23:17 , David Conrad d...@virtualized.org wrote: On May 23, 2013, at 10:53 PM, Andreas Larsen andreas.lar...@ip-only.se wrote: The whole idea of Geoip is flawed. Sure, but pragmatically, it's an 80% solution. IP dosen't reside in countries, True, according to (at least some of) the RIRs they reside in regions... Really? Which ones? I thought they were only issued to organizations that had operations in regions. Owen Just because I have operations in one region does not preclude me from having operations in other regions. YMMV of course. /bill
ISOC item of interest
ISOC - the folks who bring you IETF standards, is seeking public input. This from Emma: Hi all, In case it is of interest there is currently a public consultation on the Internet Society's mission now and in the future, you can voice your opinions by filling in the form at: https://www.internetsociety.org/form/strategic-and-business-planning-2014 If you have any questions you can mail me at fr...@isoc.org and i'll forward them on for you. Cheers, Emma -
Re: someone from Sprint
paging Softbank/Sony. /bill On Thu, Apr 18, 2013 at 11:50:57AM -0400, Jay Ashworth wrote: - Original Message - From: bmann...@vacation.karoshi.com your not alone... (Sprint is the upstream for this email) The original message was received at Wed, 17 Apr 2013 14:21:10 GMT from localhost.localdomain [127.0.0.1] - The following addresses had permanent fatal errors - tom.a.sch...@sprint.com (reason: 501 5.5.4 Invalid domain name) And that wasn't all; Sprint transparent proxies for their WiMAX 4g service were horking connections to Google and eBay (probably among others) for about half an hour, about an hour ago. It was fun to get No service configured at this address from Google. :-) Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: someone from Sprint
your not alone... (Sprint is the upstream for this email) The original message was received at Wed, 17 Apr 2013 14:21:10 GMT from localhost.localdomain [127.0.0.1] - The following addresses had permanent fatal errors - tom.a.sch...@sprint.com (reason: 501 5.5.4 Invalid domain name) /bill On Wed, Apr 17, 2013 at 02:38:47PM -0600, Miguel Mata wrote: Hi, we are having some problems reaching some of the sprint.com sites. If someone around that can help us, it'll be very appreciated. We are AS16592. Please off list. -- Miguel Mata Gerente de Operaciones Comunicaciones IBW El Salvador tel.: ++(503) 2278-5068 fax: ++(503) 2207-1310 mm...@ibw.com La confianza es la mejor conexion
Re: Quad-A records in Network Solutions ?
On Tue, Apr 09, 2013 at 08:13:49PM -0700, Eric Brunner-Williams wrote: On 4/9/13 5:47 PM, Jared Mauch wrote: Can you point is at the right address or form to submit regarding this? Seems like its time for both on and DS. Jared, Joe is an employee of the corporation, a rather high ranking one. As I mentioned in my response to Mark, he _may_ be in a position to encourage both legal to develop new language for future addition to the RAA, and the Registrar Liaison to socialize the issue to those RAA parties who are members of the Registrar Stakeholder Group within the Contracted Parties House of the GNSO, and the Compliance team. As a matter of policy development you should expect that Registrars (recall hat) have been presented with ... proposed new terms and conditions that ... are not universally appreciated, and so one must either (a) impose new conditions unilaterally upon counter-parties, arguing some theory of necessity, or (b) negotiate a mutually agreeable modification. There is a lot of heat lost in the ICANN system, so to re-purpose the off-hand observation of John Curran made recently, operators having some rough consensus on desirable features of RRSet editors may be a necessary predicate to policy intervention. As I observed to John, the ISP Constituency within the ICANN GNSO has been an effective advocate of trademark policy, and no other policy area, since the Montevideo General meeting, in 2001. Eric P.S. I may be turning in my Registrar hat in the near future. From the Beijing mtg of ICANN - There is a real concern about the disparity of requirement; the pre 2009 contracts, the 2009 contracts, the proposed 2013 contracts. unfortunately the 2013 contract language is pretty much baked and the only wiggle room is bringing the old contracts into compliance with the 2013 text. The trigger for the change now is the introduction of new TLDs. the one other avenue is to take this ti the ATRT2 folks and get this included as a matter of ICANN perfomance. OR - just move to a registrar who gives you what you want and not empower ICANN with the ability to set/control operational choice. YMMV of course. /bill
Re: Tier 2 ingress filtering
is there a clear understanding of the edge in the network operations community? in a simpler world, it was not that difficult, but interconnect has blossomed and grown all sorts of noodly appendages/extentions. I fear that edge does not mean what you think it means anymore. /bill On Thu, Mar 28, 2013 at 01:07:24PM -0400, Jay Ashworth wrote: In the current BCP38/DDoS discussions, I've seen a lot of people suggesting that it's practical to do ingress filtering at places other than the edge. My understanding has always been different from that, based on the idea that the carrier to which a customer connects is the only one with which that end-site has a business relationship, and therefore (frex), the only one whom that end-site could advise that they believe they have a valid reason to originate traffic from address space not otherwise known to the carrier; jack-leg dual-homing, for example, as was discussed in still a third thread this week. The edge carrier's *upstream* is not going to know that it's reasonable for their customer -- the end-site's carrier -- to be originating traffic with those source addresses, and if they ingress filter based on the prefixes they route down to that carrier, they'll drop that traffic... which is not fraudulent, and has a valid engineering reason to exist and appear on their incoming interface. Fixing that will require the construction of an entirely new tracking system at the Tier 2, which is not really the case for the Tier 3 edge carrier, as I see it - you generally just turn unicast-rpf on for everyone's port, unless you have a signed waiver in your file cabinet, in which case you turn it off. Am I missing something? Or is the overarching problem large enough that people are willing to throw the baby out with the bathwater? Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: Tier 2 ingress filtering
On Thu, Mar 28, 2013 at 01:47:45PM -0400, valdis.kletni...@vt.edu wrote: On Thu, 28 Mar 2013 17:16:48 -, bmann...@vacation.karoshi.com said: is there a clear understanding of the edge in the network operations community? in a simpler world, it was not that difficult, but interconnect has blossomed and grown all sorts of noodly appendages/extentions. I fear that edge does not mean what you think it means anymore. For 5 9's worth of eyeball networks hanging off consumer-grade ADSL and cable connections, it's still the edge and still trivially filterable.If that's a problem, the ISP can upsell a business-class connection that doesn't filter. ;) 5 9s? I'll go w/ big, but this seems a stretch to me. if true (it might be), then filtering ought be done and catch the delta. I still posit a baseline that does not fit this lowhanging fruit... (trill networks, L2 transparent bridging, L2-L3-VPNs, etc.) /bill
Re: ORP
On Tue, Mar 26, 2013 at 08:07:22AM -0400, Patrick W. Gilmore wrote: On Mar 26, 2013, at 08:01 , Dobbins, Roland rdobb...@arbor.net wrote: On Mar 26, 2013, at 6:50 PM, Jamie Bowden wrote: let's suppose I just happen to have, or have access to, a botnet comprised of (tens of) millions of random hosts all over the internet, and I feel like destroying your DNS servers via DDoS; DNS reflection/amplification attacks aren't intended as attacks against the DNS, per se; they're intended to crush any/all targeted servers and/or fill transit pipes. To be more clear, the point of DNS reflection attacks is to amplify the amount of bandwidth the botnet can muster (and perhaps hide the true source). If you have 10s of millions of bots, you don't need to amplify. You can crush any single IP address on the 'Net. TTFN, patrick You are the Brut Squad!
Re: BCP38 - Internet Death Penalty
but they are paying attention /bill On Tue, Mar 26, 2013 at 09:25:09AM -0700, Jared Mauch wrote: I'm not sure you want this regulated. Jared Mauch On Mar 26, 2013, at 9:20 AM, Mikael Abrahamsson swm...@swm.pp.se wrote: Can't we get homeland security into this? Threat to US national security if people can spoof? :P
Re: can you share ipv6 addressallo cation
don't think of this in terms of waste (v6 has an unthinkable number of numbers) and think of security. by announceing more space than you are actually using, you create dark-space that attackers can hide in-plain-sight. so, for example, in your P2P links, you can use tools that lazy developers picked a near random number, a /64 as a constant, or you can reduce your attack surface by a) only announcing what your are actually using, in this case /126 for p2p links your call, your network, your inducced vulnerabilities. Your LIABILITY. /bill On Sun, Feb 24, 2013 at 12:00:58PM -0500, Deric Kwok wrote: Hi Owen and all Thank you so much for all info. I do have question about /126 or /64 as link to link After getting this http://www.clarksys.com/blog/2010/08/18/howto-subnet-ipv6-for-network-links/ Can I know what do you think? Can we say that to use /64 to replace /126 for network link? and what do you think the problem to use /64? The website said: If you refer back to the presentation I mentioned earlier thereb s notes about the potential dangers of /64s on network links and why people intuitively want to subnet to a /127 or a /126. We ended up splitting the difference and actually subnetting the /64 for the network link to a /126. IPv6 is a very large pool of IP space b to paraphrase my favorite quote so far b IPv6 has 340 undecillion unique addresses (thatb s a 39-digit number). If IPv4 is a golf ball IPv6 is the sun.b Trust me, donb t try to over think this. Just follow what all the RFCs say and use /64s for your network links. If you want to read more I found the following links to be very helpful in understanding how to properly subnet IPv6: Thank you so much On Wed, Feb 20, 2013 at 9:00 PM, Owen DeLong o...@delong.com wrote: First, if you are starting from a /32 and deciding how to carve it up from there, you are already approaching the problem backwards. The correct approach (general broad strokes) is to: 1. Identify your subnetting needs. A. Infrastructure addressing B. Internal IT needs within the company C. Customer network needs (usually best to count the Infrastructure and Internal IT as n*customers at this point when rolling this all up into a total number of subnets needed). D. Decide on a customer end-site subnet size (unless this is an exceptional case, /48 is a good number to use) 2. Identify the natural aggregation points in your network. 3. Identify the number of /48s (or whatever other size you decided in D) needed in your largest aggregation site. (This should be the sum of all subordinate end-user networks as well as any infrastructure networks, etc. Round that up to a nibble boundary ensuring at least a 25% free space. 4. Identify the total number of aggregation points at the hierarchy level identified in (3) above. 5. Round that up to a nibble boundary as well. 6. Make a request for the prefix size determined by taking the number in 1D (/48) and subtracting the number of bits identified in (3) and (5). e.g. your largest aggregation point serves 50,000 customer end sites and you have 196 such aggregation points. Each customer end-site is to receive a /48. 50,000 customer end-sites is 16-bits. To get a 25% min free, we must round up to 20. This count includes 2 customer end-sites to support ISP infrastructure and internal IT needs, respectively. 196 aggregation points is 8-bits. To get a 25% min free, we must round up to 12. 48-20=28-12=16 -- This network should request a /16 from their RIR. Notes: This is a severe oversimplification. Obviously more details will be required and the process must be adapted to each individual ISP's network topology and other considerations. Your first several iterations of addressing plan will be wrong. Accept it, deploy it, and expect to redo it a few times before you're completely happy with it. Plan big, deploy small the first few times so that you can learn lessons about the big plan while the deployments are still small. Owen On Feb 20, 2013, at 14:44 , Deric Kwok deric.kwok2...@gmail.com wrote: Hi all I am searching information about ipv6 addressallocation for /32 Any experience and advice can be shared eg: loopback. peer to peer, Thank you so much
Re: Level3 worldwide emergency upgrade?
ah - those were the days of glory... :) On Wed, Feb 06, 2013 at 06:06:39PM -0700, Brett Watson wrote: Hell, we used to not have to bother notifying customers of anything, we just fixed the problem. Reminds me a of a story I've probably shared on the past. 1995, IETF in Dallas. The big ISP I worked for at the time got tripped up on a 24-day IS-IS timer bug (maybe all of them at the time did, I don't recall) where all adjacencies reset at once. That's like, entire network down. Working with our engineering team in the *terminal* lab mind you, and Ravi Chandra (then at Cisco) we reloaded the entire network of routers with new code from Cisco once they'd fixed the bug. I seem to remember this being my first exposure to Tony Li's infamous line, ... Confidence Level: boots in the lab. Good times. -b On Feb 6, 2013, at 5:41 PM, Brandt, Ralph wrote: David. I am on an evening shift and am just now reading this thread. I was almost tempted to write an explanation that would have had identical content with yours based simply on Level3 doing something and keeping the information close. Responsible Vendors do not try to hide what is being done unless it is an Op Sec issue and I have never seen Level3 act with less than responsibility so it had to be Op Sec. When it is that, it is best if the remainder of us sit quietly on the sidelines. Ralph Brandt -Original Message- From: Siegel, David [mailto:david.sie...@level3.com] Sent: Wednesday, February 06, 2013 12:01 PM To: 'Ray Wong'; nanog@nanog.org Subject: RE: Level3 worldwide emergency upgrade? Hi Ray, This topic reminds me of yesterday's discussion in the conference around getting some BCOP's drafted. it would be useful to confirm my own view of the BCOP around communicating security issues. My understanding for the best practice is to limit knowledge distribution of security related problems both before and after the patches are deployed. You limit knowledge before the patch is deployed to prevent yourself from being exploited, but you also limit knowledge afterwards in order to limit potential damage to others (customers, competitors...the Internet at large). You also do not want to announce that you will be deploying a security patch until you have a fix in hand and know when you will deploy it (typically, next available maintenance window unless the cat is out of the bag and danger is real and imminent). As a service provider, you should stay on top of security alerts from your vendors so that you can make your own decision about what action is required. I would not recommend relying on service provider maintenance bulletins or public operations mailing lists for obtaining this type of information. There is some information that can cause more harm than good if it is distributed in the wrong way and information relating to security vulnerabilities definitely falls into that category. Dave -Original Message- From: Ray Wong [mailto:r...@rayw.net] Sent: Wednesday, February 06, 2013 9:16 AM To: nanog@nanog.org Subject: Re: Level3 worldwide emergency upgrade? OK, having had that first cup of coffee, I can say perhaps the main reason I was wondering is I've gotten used to Level3 always being on top of things (and admittedly, rarely communicating). They've reached the top by often being a black box of reliability, so it's (perhaps unrealistically) surprising to see them caught by surprise. Anything that pushes them into scramble mode causes me to lose a little sleep anyway. The alternative to what they did seems likely for at least a few providers who'll NOT manage to fix things in time, so I may well be looking at longer outages from other providers, and need to issue guidance to others on what to do if/when other links go down for periods long enough that all the cost-bounding monitoring alarms start to scream even louder. I was also grumpy at myself for having not noticed advance communication, which I still don't seem to have, though since I outsourced my email to bigG, I've noticed I'm more likely to miss things. Perhaps giving up maintaining that massive set of procmail rules has cost me a bit more edge. Related, of course, just because you design/run your network to tolerate some issues doesn't mean you can also budget to be in support contract as well. :) Knowing more about the exploit/fix might mean trying to find a way to get free upgrades to some kit to prevent more localized attacks to other types of gear, as well, though in this case it's all about Juniper PR839412 then, so vendor specific, it seems? There are probably more reasons to wish for more info, too. There's still more of them (exploiters/attackers) than there are those of us trying to keep things running smoothly and transparently, so anything
Re: De-funding the ITU
On Sat, Jan 12, 2013 at 10:49:59PM -0800, Bill Woodcock wrote: On Jan 12, 2013, at 9:04 PM, Fred Baker (fred) f...@cisco.com wrote: ITU-D and ITU-R do a lot of good work. Care to try to cite an example? R we can't pull out of because NRO needs its slots. I'm not sure that constitutes good work. It's minor ledger-keeping, and that's why it's excluded from the petition. beside the NRO (the real one), DoD and the FCC and NTIA are all invested in a working ITU-R - there is something to be said for products that work outside the US borders as well as within. Shutting down the ITU would be in effect discarding the baby with the bathwater. You're being awfully naive, Fred. It's a 147-year-old, $180M/year baby with a serious corruption problem, that wants to shut the Internet down so that it can go back to doing things the way it was before we all showed up. I expect you think you're being sophisticated and taking a nuanced view or some such, but you aren't. Note that the _entire_ congress disagrees with you. Not a single vote in favor of the ITU in S. Con. Res. 50 or H. Con. Res. 127. And if you think that any of the Internet agrees with you, you should take a look at Reddit sometime. it is true that among the public, congress has a lower approval rating than cockroaches (at least according to NPR). I understand a little of your vitriol, but since it is possible to fund -by sector-, there is no good reason to tar the entire Union with the same brush. -Bill /bill
Re: De-funding the ITU
its not that black/white. The ITU-R is actually -very- useful and does a really good job of coordinating spectrum use and has for many years. The ITU-T, however is questionable. It is possible to fund by sector, so a blanket defunding for the entire ITU, as outlined in this petition, is a huge mistake. /bill On Sat, Jan 12, 2013 at 07:03:57PM -0800, Bill Woodcock wrote: Please consider signing this petition: http://DeFundTheITU.org biotic fight. Note that if the U.S. pulls its funding from the ITU, that's 10%, and if all of the countries that stood with us at the WCIT do so, that would be 74% of the ITU's member revenue. Those of us who support the Internet are paying for three-quarters of the fight against the Internet. As Smokey the Bear would say, only WE can prevent stupidity. As Pogo Possum said, We have met the enemy, and the enemy is us! Time to correct that. Redirect $11M/year from the ITU to Internet governance organizations like the IETF. -Bill
Re: Advisory — D-root is changing its IPv4 address on the 3rd of January.
On Sun, Dec 16, 2012 at 12:45:32AM +, Nick Hilliard wrote: On 15/12/2012 23:07, David Conrad wrote: The handwringing over this issue is a bit over the top. It's a question of what's procedurally sensible. Sensible things would include longer notice of the impending change to the root zone, more widespread notice of what's happening and generally not poking around with really important bits of the Internet at times which are well known for having configuration freezes and/or when many people are going to be on holidays. There are many bits of the internet where changes will only affect small areas, but this change will affect everyone even if they people don't realise it (and yes, it probably won't affect them visibly because of root cache repriming). how much notice would you like? Other sensible things might include: - liaising with operating system vendors and recurser servers code authors and providing them with extra advance notice so that they can roll these changes into their code in a structured way. Software update release cycles often take many months to roll out, particularly for non OSS code. its not clear this has not been done. nor is it clear that it would be needed, given the bootstrap methods that have been current for more than a decade. - perhaps some targeted localisation of the d.root-servers.org notice so that more than 15% of the world population can read it (english == 5% native speakers, 10% second language)? its not clear this has not been done. where you you localise this notice and what methods would you use? Lots of people are aware that resolver dns servers will automatically reprime their root cache without manual intervention. However, not everyone will realise it and a random punter who looks at this notice and doesn't understand root cache mechanics may well think that they need to start updating their DNS configuration files on Jan 3. It's not clear from the change notification that you don't necessarily need to do this. true - there is an expectation that the reader has a basic understanding of the DNS. My grandmother would be confused, but would clearly understand from the notice that there were many months before the existing system would change. Perhaps the notice should suggest talking with your service provider if you don't understand or have questions. This change wasn't planned over a coffee last thursday morning. It's obviously been on the cards for several years, so asking for more carefully structured notice in a procedurally sensible sort of way isn't an unreasonable thing to expect as part of the migration plan. are these all the points that concern you? are there others? lets get them all on the table. Nick
Re: Advisory — D-root is changing its IPv4 address on the 3rd of January.
On Fri, Dec 14, 2012 at 08:59:19AM -0800, Michael Thomas wrote: Matthew Newton wrote: On Fri, Dec 14, 2012 at 04:42:46PM +, Nick Hilliard wrote: On 13/12/2012 22:54, Jason Castonguay wrote: Advisory You've just given 3 weeks notice for a component change in one of the few critical part of the Internet's infrastructure, at a time when most I think that /was/ the advance notification - you've got 6 months :) The old address will continue to work for at least six months after the transition, but will ultimately be retired from service. So really stupid question, and hopefully it's just me, do I need to do something on my servers? Second question: I know that renumbering is important in the abstract, but is there really an overwhelming reason why renumbering the root servers is critical? Shouldn't they all be in PI space for starters? Mike you might want to pick up the new belt/suspenders file aka root.hints, named.ca, et.al. and install it on your servers in the course of the next two years. if you can't reach D, then you should be able to reach the other 12. i beleive that D has not changed its IP address since before the RIR system came into existance and therefore had no idea what PI space means. Some of this stuff is really old/stable and making changes to foundational/stable systems is fraught with peril. Being careful is just being prudent. Perhaps of real interest to the NANOG community is the ability to see this prefix in their routing tables. /bill
Re: Advisory — D-root is changing its IPv4 address on the 3rd of January.
On Fri, Dec 14, 2012 at 12:45:00PM -0500, Joe Abley wrote: These changes have happened before (other root servers have renumbered). I have never heard of an operational problem caused by such an exercise, and I guarantee there are resolvers running happily today with hints files that are *ancient*. Joe i had one, back last century, when B renumbered. the old address of B was the last working address in the bootstrap file from 1986. :) i'm fairly confident that 99.% of all the existant bootstrap files on the Internet today contain at least 9 working IP addresses for root nameservers. That said, its -very- important to ensure (at each ISP, worldwide) that you have reachability to the new prefix. (wrt notification, I'm persuaded its valid and that the notice will be sent to many more groups as the hours/days progress ... remember, its not a flash change) /bill
Re: btw, the itu imploded - NOT
not at all... the WCIT 2012 concluded without agreement. Hardly the same thing. /bill
Re: Advisory — D-root is changing its IPv4 address on the 3rd of January.
On Fri, Dec 14, 2012 at 02:46:49PM -0500, Jay Ashworth wrote: - Original Message - From: bmann...@vacation.karoshi.com So, in short, UMD will still own the losing allocation, and be able to make relatively sure nothing else is placed at that IP (though of course they won't necessarily be able to make sure no one hijacks that entire prefix -- does Renesys have a pay-special-attention list?) But how do you know the Renesys allocations haven't been hijacked?? I know you're being a smartass, Bill, but you're right: I assume Renesys has made provisions for that, but I don't know what they are. No doubt they'll pop in and post a link to a blog post they wrote 5 years ago which explains. ;-) Cheers, -- jra the smart-ass answer to the nagging question on prefix reuse is: Top Men are working on it A more reasoned (maybe) response might be: To my knowledge, there is tension between creating golden addresses and address flexablity/reuse. I'd really like to swing back toward address flexability/reuse, but there is a whole lot of inertia behind the golden address crowd. Of the six renumbering events that come to mind, four of the prefixes are sequestered. The two that are not were in net 10. I am unaware of -anyone- who still points at the old addresses in net 10 space. I think there were other renumbering events, but have not kept track of the old prefix use. /bill
Re: Advisory — D-root is changing its IPv4 address on the 3rd of January.
On Fri, Dec 14, 2012 at 03:10:44PM -0600, Joe Antkowiak wrote: On Fri, Dec 14, 2012 at 2:13 PM, Jason Castonguay casto...@umd.edu wrote: The old address, which is in the middle of UMD's network, is going to be black-holed once the change is over. Nothing will be on that IP once we move the root off. The rest of UMD's network is staying put. This move is part of UMD's commitment to improve the service, so we can support DNS anycast. Just a quick questionif the old block is going to be black-holed but kept allocated...why does it need to be changed in the first place, or why does the existing have to be disabled? (just have both addresses active/responding?) Forgive me if I'm missing something. because you would not accept a /30 cutout of the UMD /16 coming from some random IX in Singapore. (see Joe Ableys post earlier today on why legacy nodes are / have renumbered.) /bill
Re: Advisory — D-root is changing its IPv4 address on the 3rd of January.
On Fri, Dec 14, 2012 at 08:48:07PM -0800, David Conrad wrote: On Dec 14, 2012, at 11:02 AM, Joe Abley jab...@hopcount.ca wrote: Other root servers have renumbered out of institutional, general-purpose networks into dedicated networks in the past. I think the last one was B-Root in 2004, Actually, it was L in 2007... :) Regards, -drc SOME people have very long memories. /bill
Re:
On Wed, Dec 12, 2012 at 07:57:11AM -0800, Randy Bush wrote: flower tailor samba...@hotmail.com wrote: Delete me though possibly merciful, it is illegal in most cultures Montenegrins would be sad with the unilateral removal of thier TLD. /bill
Re: Big day for IPv6 - 1% native penetration
2013 - the year of the NAT. (the only way a single stacked address family is going to be able to talk to a single stacked member of a different address family... and unless we start agressive reuse of v4, this will happen sooner than later (dual-stack is rate limited to the smaller of the address families -UNLESS- NAT makes reuse possible... :) But since NAT is going to be required -anyway- 2013 will be the year of the NAT. /bill On Tue, Nov 27, 2012 at 06:32:27AM +0100, Mikael Abrahamsson wrote: On Tue, 27 Nov 2012, Dobbins, Roland wrote: Yet everyone (except you) insist that it does work with everything, and that all this CGN and 444 stuff and 644 stuff isn't necessary, and that I'm a fool for doubting all these (to me) wildly overoptimistic assertions about the coming ubiquity of native IPv6, end-to-end, heh. Dual stack works with everything. IPv6 only access does not (with 464XLAT it might). However, people are complaining that operators are focusing more on CGN and NAT44(4) than they are on IPv6. Which I can understand, but I believe we're getting closer to getting out of the dead lock. My hope is that 2013 is going to be the year we're going to see widespread IPv6 (dual stack) adoption on mobile devices outside of the US. It's looking good so far. People are advocating dual stack now (at least that's what I do), for a future goal of IPv6 only. The main problem with IPv6 only is that most app developers (most programmers totally) do not really have access to this, so no testing is being done. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Big day for IPv6 - 1% native penetration
Dr. Frederick Frankenstein: LIFE! DO YOU HEAR ME? GIVE MY CREATION... LIFE! On Tue, Nov 20, 2012 at 10:14:18AM +0100, Tomas Podermanski wrote: It seems that today is a big day for IPv6. It is the very first time when native IPv6 on google statistics (http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some might say it is tremendous success after 16 years of deploying IPv6 :-) And given the rate on that graph, we'll hit 2% before year-end 2013.
Re: dhcpy6d - a MAC address aware DHCPv6 server
On Tue, Nov 06, 2012 at 05:38:32AM -0800, Owen DeLong wrote: If you're on local subnet, why not pull the MAC address out of the received packet? Further, what happens to this when IPv4 goes away? Owen the cat came back ... IPv4 is going away like RIP is a dead routing protocol. give it another 20 years. /bill
Re: dhcpy6d - a MAC address aware DHCPv6 server
cool. this is the fifth version of a DHCP server modified to work with IPv4 and IPv6 in accord with the DHCP specs. a feature request... some sites run IVI, and so the have a MAC and and v6 address and need to be dynamically assigned a v4 address. My crude attempt uses the last 48bits of the v6 address asa proxy MAC. It works ok in my small network. It might be useful in larger nets that run IVI or carrier-grade NAT ... /bill On Mon, Nov 05, 2012 at 09:14:54AM +0100, Henri Wahl wrote: Hello World, like other people we had the problem that existing DHCPv6 servers do not evaluate the MAC address of clients, following RFC 3315. The IPv4 clients already are managed via their MAC addresses so we wanted to use these identifiers for IPv6 too for our dualstack network. At the end we had to write our own DHCPv6 server dhcpy6d which I want to present here to a larger audience. It runs on Linux, tested on Debian and CentOS. It gets the client MAC addresses from neighbor cache by calling ip -6 neigh and caches them itself, allowing to access the already working MAC-based IPv4 infrastructure. This obviously only works on the local subnet but might be worked around with several servers being connected via database storage of clients and leases. Features are: - identifies clients by MAC address, DUID or hostname - generates addresses randomly, by MAC address, by range or by given ID - filters clients by MAC, DUID or hostname - assignes more than one address per client - allows to organize clients in different classes - stores leases in MySQL or SQLite database - client information can be retrieved from database or textfile - dynamically updates DNS (Bind) We run it with ~500 clients without problems. I am interested if it would run in larger environments too. If not, how to make it running. Bugs and ideas how to improve it are welcome too. Packages are not yet available but the Python code should run as is. See further details at http://dhcpy6d.ifw-dresden.de Best regards Henri Wahl -- Henri Wahl IT Department Leibniz-Institut f|r Festkvrper- u. Werkstoffforschung Dresden tel. (03 51) 46 59 - 797 email: h.w...@ifw-dresden.de http://www.ifw-dresden.de Nagios status monitor for your desktop: http://nagstamon.ifw-dresden.de IFW Dresden e.V., Helmholtzstra_e 20, D-01069 Dresden VR Dresden Nr. 1369 Vorstand: Prof. Dr. Ludwig Schultz, Dr. h.c. Dipl.-Finw. Rolf Pfrengle
the little ssh that (sometimes) couldn't
corruption! http://mina.naguib.ca/blog/2012/10/22/the-little-ssh-that-sometimes-couldnt.html /bill
Re: IP tunnel MTU
On Mon, Oct 29, 2012 at 03:46:57PM -0400, Joe Maimon wrote: Templin, Fred L wrote: Yes; I was aware of this. But, what I want to get to is setting the tunnel MTU to infinity. Essentially, its time the network matured to the point where inter-networking actually works (again), seamlessly. I agree. Joe you mean its safe to turn off the VPNs? /bill
Re: IP tunnel MTU
On Mon, Oct 29, 2012 at 04:44:40PM -0400, Joe Maimon wrote: bmann...@vacation.karoshi.com wrote: On Mon, Oct 29, 2012 at 03:46:57PM -0400, Joe Maimon wrote: Templin, Fred L wrote: Yes; I was aware of this. But, what I want to get to is setting the tunnel MTU to infinity. Essentially, its time the network matured to the point where inter-networking actually works (again), seamlessly. I agree. Joe you mean its safe to turn off the VPNs? /bill Quite the reverse. Joe so its tunnels all the way down... maybe we should just go back to a circuit oriented network, eh? /bill
Re: Issues encountered with assigning .0 and .255 as usable addresses?
ok... so lets look at some space here. 98.32.0.0/22 98.32.0.0/32 is clearly on the unusable boundary. what about 98.32.0.255/32 98.32.1.0/32 ??? 98.32.4.255/32 is also clearly on the unusable boundary... UNTIL the delegation moves from a /22 to a /21. Then its usable. clear? thought so. /bill On Tue, Oct 23, 2012 at 10:00:53PM +0200, Tore Anderson wrote: * Job Snijders In the post-classfull routing world .0 and .255 should be normal IP addresses. CIDR was only recently defined (somewhere in 1993) so I understand it might take companies some time to adjust to this novel situation. Ok, enough snarkyness! Quite recently a participant of the NLNOG RING had a problem related to an .255 IP address. You can read more about it here: https://ring.nlnog.net/news/2012/10/ring-success-the-ipv4-255-problem/ AIUI, that particular problem couldn't be blamed on lack of CIDR support either, as 91.218.150.255 is (was) a class A address. It would have had to be 91.255.255.255 or 91.0.0.0 for it to be special in the classful pre-CIDR world. That said, it's rather common for people to believe that a /24 anywhere in the IPv4 address space is a +class C; so I'm not really surprised. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/
Re: Another LTE network turns up as IPv4-only
https://intelligence.businessinsider.com/facebook-is-adding-over-25000-mobile-users-an-hour-2012-10 dream big /bill On Thu, Oct 11, 2012 at 08:31:44AM +0200, Tore Anderson wrote: * Cameron Byrne FYI http://www.dslreports.com/forum/r27324698-LTE-access-early- So much for next generation technology ... Yesterday, Telenor launched LTE. So. With a green-field deployment, in their home market (supposed to be the first of their tree-digit million subscribers world-wide to get all the cool new tech), built on 3GPP specs that fully supports IPv6, already proven to work by other pioneers (^5 VzW), for which there are plenty of compatible devices (again, ^5 VzW), and plenty of compatible content (^5 ISOC, et al.), four months after World IPv6 Launch (in which they participated), and one month after their RIR ran out of IPv4 addresses...launching without IPv6 support was a perfectly natural and sensible thing for them to do, it seems. *sigh* -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/
Re: Is a /48 still the smallest thing you can route independently?
one of the downsides to v6 is the huge amnt of space the folks expect you to announce. lots of space to do nefarious things. that said. if you select your peers carefully and don't mind a bit of hand crafting, you can /96 and even /112 that said, get a /32 and assign/announce /48s... /bill On Thu, Oct 11, 2012 at 02:02:17PM -0700, Jo Rhett wrote: I've finally convinced $DAYJOB to deploy IPv6. Justification for the IP space is easy, however the truth is that a /64 is more than we need in all locations. However the last I heard was that you can't effectively announce anything smaller than a /48. Is this still true? Is this likely to change in the immediate future, or do I need to ask for a /44? -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects.
Re: ESR muses on, among other things, the early IETF
On Sat, Oct 06, 2012 at 10:14:41AM +0100, Nick Hilliard wrote: On 06/10/2012 03:20, Jay Ashworth wrote: Those who know Fred and knew Jon personally might want to throw an oar in the water on this blog posting from last month... http://esr.ibiblio.org/?p=4591 not sure if it's appropriate to associate some of the prime movers of the Internet with a cringingly self-aggrandising blog posting like that. Nick I -think- Jon and Fred were not contemporaries. Fred is closer to my age than Jon. /bill
Re: ESR muses on, among other things, the early IETF
On Sat, Oct 06, 2012 at 06:12:08PM -0400, Frank Kastenholz wrote: On Oct 6, 2012, at 6:39 AM, bmann...@vacation.karoshi.com wrote: On Sat, Oct 06, 2012 at 10:14:41AM +0100, Nick Hilliard wrote: On 06/10/2012 03:20, Jay Ashworth wrote: Those who know Fred and knew Jon personally might want to throw an oar in the water on this blog posting from last month.. ... I -think- Jon and Fred were not contemporaries. Fred is closer to my age than Jon. While I don't know how old either is/would be, Fred was active in the IETF before I joined the IESG, I appointed him chair of the pppwg in 95 or 96 or so (I think?) and he became IETF chair in 96 or so --- the last year I was on the IESG. And was at the nerds on the beach IETF in Hawaii in89 or 90 iirc --Jon. Passed away in 98. They certainly overlapped in their i* lives Frank Kastenholz going back another decade, Fred and I both worked on/with bridging technologies, before routing was popular. Jon had us beat by at least a decade - early 1970s. We cme to the party in the late 70's early 80s. /bill
Re: RIRs give out unique addresses (Was: something has a /8! ...)
not how i read that section Owen... ...networks require interconnectivity and the private IP address numbers are ineffective, globally unique addresses may be requested and used to provide this interconnectivity. One does not have to request RFC 1918 space from ARIN (or other RIR) and the NRPM is mute on legacy address assignments wrt connectivity. /bill On Thu, Sep 27, 2012 at 07:32:17PM -0700, Owen DeLong wrote: I believe that this section of NRPM says no. 4.3.5. Non-connected Networks End-users not currently connected to an ISP and/or not planning to be connected to the Internet are encouraged to use private IP address numbers reserved for non-connected networks (see RFC 1918). When private, non-connected networks require interconnectivity and the private IP address numbers are ineffective, globally unique addresses may be requested and used to provide this interconnectivity. Owen On Sep 20, 2012, at 7:56 AM, Naslund, Steve snasl...@medline.com wrote: I suppose that ARIN would say that they do not guarantee routability because they do not have operational control of Internet routers. However, Wouldn't you say that there is a very real expectation that when you request address space through ARIN or RIPE that it would be routable? I would think that what ARIN and RIPE are really saying is that they issue unique addresses and you need to get your service provider to route them. FWIW, the discussion of the military having addresses pulled back is pretty much a non-starter unless they want to give them back. When the management of IP address space was moved from the US DoD, there were memorandums of understanding that the military controlled their assigned address space and nothing would change that. I know this for a fact because I was around this discussion in the US Air Force. Steven Naslund -Original Message- From: John Curran [mailto:jcur...@arin.net] Sent: Thursday, September 20, 2012 9:40 AM To: Jeroen Massar Cc: NANOG list Subject: Re: RIRs give out unique addresses (Was: something has a /8! ...) On Sep 20, 2012, at 10:10 AM, Jeroen Massar jer...@unfix.org wrote: On 2012-09-20 16:01 , John Curran wrote: It's very clear in the ARIN region as well. From the ARIN Number Resource Policy Manual (NRPM), https://www.arin.net/policy/nrpm.html#four11 - 4.1. General Principles 4.1.1. Routability Provider independent (portable) addresses issued directly from ARIN or other Regional Registries are not guaranteed to be globally routable. While close, that is not the same. The RIPE variant solely guarantees uniqueness of the addresses. The ARIN variant states we don't guarantee that you can route it everywhere, which is on top of the uniqueness portion. Agreed - I called it out because ARIN, like RIPE, does not assert that the address blocks issued are publicly routable address space (i.e. which was Tim Franklin's original statement, but he did not have on hand the comparable ARIN reference for that point.) FYI, /John
Re: RIRs give out unique addresses (Was: something has a /8! ...)
ah... again the distinction between routed and routable. RFC 1918 space is clearly routeable and routed. one does not need ARIN to assign such space. what i -think- the NRPM section you refered to actually touches on (but does not state outright) the concept of uniqueness. In the dim mists of the past, the NIC (SRI) ran two sets of books, the connected database and the unconnected database. There was a lack of address block uniquenss between these two databases; e.g. 192.146.13.0/24 was assigned -TWICE-. This occured for hundreds of delegations I was responsible for - I can only assume there were thousands of sites affected (Impacted for the gramatically challanged). This was problematic when unconnected sites connected... and is why some of the admonitions in RFC 1918 exist. The section of the ARIN NRPM you quote was developed when there was: a) a shortage of globally unique IPv4 blocks available and b) NAT and RFC 1918 space was easy. Hence the admonishion to use RFC 1918 space if you were unconnected and when you decided to connect, ARIN would be willing to listen to your request. Two thing have changed: a) IPv4 is nearing equalibrium ... Most of it is fielded and so it is not clear ARIN can supply IPv4 on demand as it has in the past. Yes, please tell me the IPv6 story Grandpa, I've -never- heard it before... :( b) Many networks are not connected or unconnected (begs the question, from what PoV/ASN?) but are transients - with connections being sporadic either in time or by service. What this boils down to is global uniqueness - not routed (by whom) or routability (are the headers legal)... And that (IMHO) is a key attribute of what the RIRs are trying to protect. YMMV of course. /bill On Fri, Sep 28, 2012 at 07:04:43AM -0700, Owen DeLong wrote: Bill, I am unable to make sense of your reply. The question I was answering was: Wouldn't you say that there is a very real expectation that when you request address space through ARIN or RIPE that it would be routable? (Which I admit at the time I interpreted to also indicate an expectation that it would be routed, but I see now could be ambiguous). In that context, I believe that the policy section I quoted indicates that there is no expectation that numbers issued by ARIN or RIPE (or any other RIR) will be routed and other policy sections certainly convey that ARIN (and the other RIRs) have no control over routers, so I'm not sure it matters what they say about routability. As to your statement about legacy assignments, I fail to see any part of ARIN policy that distinguishes them from any other assignment with regards to the application of policy. However, other than the section quoted below (which essentially states that some level of connectivity is required to justify new resource allocations or assignments), I believe that the NRPM is mute with regards to connectivity on all addresses. Since there are, by definition, no new legacy allocations or assignments, I'm not sure how legacy is relevant to the discussion at hand. Owen On Sep 28, 2012, at 5:07 AM, bmann...@vacation.karoshi.com wrote: not how i read that section Owen... ...networks require interconnectivity and the private IP address numbers are ineffective, globally unique addresses may be requested and used to provide this interconnectivity. One does not have to request RFC 1918 space from ARIN (or other RIR) and the NRPM is mute on legacy address assignments wrt connectivity. /bill On Thu, Sep 27, 2012 at 07:32:17PM -0700, Owen DeLong wrote: I believe that this section of NRPM says no. 4.3.5. Non-connected Networks End-users not currently connected to an ISP and/or not planning to be connected to the Internet are encouraged to use private IP address numbers reserved for non-connected networks (see RFC 1918). When private, non-connected networks require interconnectivity and the private IP address numbers are ineffective, globally unique addresses may be requested and used to provide this interconnectivity. Owen On Sep 20, 2012, at 7:56 AM, Naslund, Steve snasl...@medline.com wrote: I suppose that ARIN would say that they do not guarantee routability because they do not have operational control of Internet routers. However, Wouldn't you say that there is a very real expectation that when you request address space through ARIN or RIPE that it would be routable? I would think that what ARIN and RIPE are really saying is that they issue unique addresses and you need to get your service provider to route them. FWIW, the discussion of the military having addresses pulled back is pretty much a non-starter unless they want to give them back. When the management of IP address space was moved from the US DoD, there were memorandums of understanding that the military controlled their assigned
Are NAT'ed networks part of the Internet?
On Thu, Sep 27, 2012 at 11:23:34AM +0200, Eugen Leitl wrote: I'm trying to figure out whether CERNET http://en.wikipedia.org/wiki/CERNET is part of the official Internet, or is behind the Great Firewall where access to invididual networks on the public Internet must be explicitly granted. Anyone in the know? Well, they are part of -my- Internet. I'm Bill Manning and I approved this message. (there, its offical too) Since you raise the issue of firewall - I'll raise you one and ask; Are networks behind NAT/ALG or that use RFC 1918 or the v6 equivalent address space, part of the 'Internet' or are they in networks where access to addresses/service ports must be explicitly granted? /bill
Re: guys dolls (a film motif)
http://en.wikipedia.org/wiki/Guys_and_Dolls_(film) i -think- the term we are looking for is: Troglodyte 1: A person considered to be reclusive, reactionary, out of date, or brutish. /bill (top posting like a civilized human...) On Thu, Sep 27, 2012 at 01:28:04PM -0700, Ray Van Dolson wrote: On Thu, Sep 27, 2012 at 02:57:36PM -0400, Andrew D Kirch wrote: I really wish people would get over themselves and get to work. Work is a place where things get done, not where people piss and moan about every single perceived slight they can come up with. Andrew I only wish you had used 'guys' instead of 'people' :) Ray
Re: guys dolls (a film motif)
thank you for your kind words and attempts to educate. clearly these items are critical for North American Network Operations (NANOG) and should be widely promoted and discussed ... But NOT, I think, here. may i humbly suggest that there exist other, better fora for discussion of these specific issues and ways/means to address them; Aleviating HUNGER Global Peace - where none take offense Exploitation of the helpless Definition of rights, both human and non-human. I would like to point you here: http://www.un.org/en/rights/ which actually has the charter to work on the issues that are so pressing in your mind. Can we kill this thread (oh dear, i'm advocating violence again...) and get back to Network Operations? Please? /bill On Thu, Sep 27, 2012 at 04:47:16PM -0400, Andrew D Kirch wrote: This isn't a real issue. HUNGER is a real issue. WAR is a real issue. 12 year old girls being sold for $20 into SLAVERY in India is a real issue. TERRORist attacks on embassies are real issues. Expansion of POLICE power is a real issue. Erosion of human and civil RIGHTS are real issues. This is window dressing. I've highlighted the important words for you, and for emphasis, because obviously you don't get it. Andrew On 9/27/2012 4:36 PM, bmann...@vacation.karoshi.com wrote: http://en.wikipedia.org/wiki/Guys_and_Dolls_(film) i -think- the term we are looking for is: Troglodyte 1: A person considered to be reclusive, reactionary, out of date, or brutish. /bill (top posting like a civilized human...) On Thu, Sep 27, 2012 at 01:28:04PM -0700, Ray Van Dolson wrote: On Thu, Sep 27, 2012 at 02:57:36PM -0400, Andrew D Kirch wrote: I really wish people would get over themselves and get to work. Work is a place where things get done, not where people piss and moan about every single perceived slight they can come up with. Andrew I only wish you had used 'guys' instead of 'people' :) Ray
Re: Optical network simulator
On Tue, Aug 28, 2012 at 12:35:57PM -0700, Robert Hajime Lanning wrote: On 08/28/12 12:12, Walter Keen wrote: Free is preferred Free is always preferred... ;) Free is too costly. Unless you have zero-cost labor... /bill
Re: US House to ITU: Hands off the Internet
On Fri, Aug 03, 2012 at 08:47:30PM +, John Curran wrote: On Aug 3, 2012, at 2:06 PM, Patrick W. Gilmore patr...@ianai.net wrote: [Feels operational to me.] http://www.pcworld.com/businesscenter/article/260299/us_house_to_itu_hands_off_the_internet.html The U.S. House of Representatives voted late Thursday to send a message to the United Nations' International Telecommunication Union that the Internet doesn't need new international regulations. The vote was unanimous: 414-0 Unanimous? I didn't think this congress could agree the earth is round unanimously. It is can be useful (particularly during an election year) to make certain that there is no doubt regarding the resolve of government with respect to positions being taken in international negotiations. In this case, I believe that the message is now quite clear... :-) /John John Curran President and CEO ARIN Its just the house :) But I suspect Terry delegation will take note. /bill
Re: Another LTE network turns up as IPv4-only squat space + NAT
On Wed, Jul 18, 2012 at 10:36:31PM -0400, Chuck Church wrote: I disagree. I see it as an extra layer of security. If DOD had a network with address space 'X', obviously it's not advertised to the outside. It never interacts with public network. Having it duplicated on the outside --- world adds an extra layer of complexity to a hacker trying to access it. It's not a be-all/end-all, but it's a plus. A hacker who's partially in the network may try to access network 'X', but it routes to the outside world, tripping IDSs... Chuck Never is a -very- long time. That said, -IF- DoD did authorize another party/contractor to utilize some DoD address blocks, its not clear if that LOA would be public. /bill
Re: using reserved IPv6 space
On Sun, Jul 15, 2012 at 09:50:39AM +0200, Laurent GUERBY wrote: Sorry if I wasn't clear in my first message. Is there an agreed upon definition of end site? Sincerely, Laurent this might help. seems like these folks have general agreement on terms. NANOG-critters might have different points of view. http://www.cio.gov/documents/2012_IPv6_Roadmap_FINAL_20120712.pdf /bill
Re: strat-1 gps
i've been using a earlier version of this: http://www.spectracomcorp.com/ProductsServices/TimingSynchronization/NetworkTimeServers/9483NetClockTimeServer/tabid/1439/Default.aspx On Tue, Jun 26, 2012 at 09:35:29PM -1000, Randy Bush wrote: my experience with cdma was kinda funky and there already is a fancy gps antenna randy
Re: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE!
Internet Regulator? /bill On Sun, Jun 17, 2012 at 10:43:26AM +0100, Roland Perry wrote: In article 20120616160738.eee09...@resin05.mta.everyone.net, Scott Weeks sur...@mauigateway.com writes What is going to make folks change their behavior? If all else fails, perhaps a regulator fining the ISP $1000 for every allocation (I agree that whether it's IPv4 or IPv6 isn't relevant) where the WHOIS information is shown to be false or significantly out of date. They could send compliance teams in to check, just like the IRS does for the accounts. -- Roland Perry
Re: IPv6 day and tunnels
On Sun, Jun 03, 2012 at 10:05:40PM -0400, Joe Maimon wrote: Joe Maimon wrote: Looks like a tunnel mtu issue. I have not as of yet traced the definitive culprit, who is (not) sending ICMP too big, who is (not) receiving them, etc. The culprit is the v6 tunnel, which wanders into v4 ipsec/gre tunnels, which means the best fix is ipv6 mtu 1280 on the tunnels, and possibly on the hosts. PMTUD works fine, just comes up with the wrong answer. 1280, the new 1500. Joe actually, to be safe, 1220. /bill
Re: NXDomain remapping, DNSSEC, Layer 9, and you.
On Tue, May 29, 2012 at 12:38:23PM +1000, Mark Andrews wrote: Putting it another way, the ISP doesn't want to be fooled even if it is fooling its customers. don't lie to us, but we lie to our customers. and you don't see a problem with this? /bill
Re: Vixie warns: DNS Changer ‘blackouts’ inevitable
On Wed, May 23, 2012 at 04:33:28PM -0400, Christopher Morrow wrote: On Wed, May 23, 2012 at 1:40 AM, bmann...@vacation.karoshi.com wrote: Paul will be there to turn things off when they no longer make money for his company. is the dns changer thingy making money for isc? pretty sure. a contract w/ the Feds, outsouring contracts w/ affected ISPs when the Fed deal runs out, development funding to code these kinds of fixes into future versions of software, any number of second and third order fallout. No telling how effective constent self-promotion is. One thing is clear, Paul is able to tell a great story. but its all speculation from here. ISC is well positioned to extract value from both ends of the spectrum. They have a great business model. The optics look pretty odd from here, at lesat to me however - I am very glad for: )open source )other vendors of DNS SW. /bill
Re: Vixie warns: DNS Changer ‘blackouts’ inevitable
On Tue, May 22, 2012 at 07:14:16PM -0700, Henry Linneweh wrote: http://www.theregister.co.uk/2012/05/17/dns_changer_blackouts/ -Henry Paul certainly knows how to manipulate the press. /bill
Re: Vixie warns: DNS Changer ‘blackouts’ inevitable
On Tue, May 22, 2012 at 08:52:52PM -0700, Michael J Wise wrote: On May 22, 2012, at 8:35 PM, Randy Bush wrote: father of bind? that's news. http://boingboing.net/2012/03/29/paul-vixies-firsthand-accoun.html He was there, and Put The Fix In, to down the network. Certainly news to Phil Almquist and the entire BIND development team at UCB. Paul was at DECWRL and cut his teeth on pre-existing code. While he (and ISC) have since revised, gutted, tossed all the orginal code, rebuilt it twice - and others have done similar for their DNS software, based on the BIND code base, implementation assumptions, and with little or no ISC code, and they call it BIND as well, it would be a HUGE leap of faith to call Paul Vixie the father of BIND - The Berkeley Internet Naming Daemon. As for being there and Put The Fix In... Makes for great PR but in actual fact, its a bandaid that is not going to stem the tide. An actual fix would really need to change the nature of the creaky 1980's implementation artifacts that this community loves so well. /bill
Re: Vixie warns: DNS Changer ‘blackouts’ inevitable
On Tue, May 22, 2012 at 10:07:52PM -0700, Michael J Wise wrote: On May 22, 2012, at 9:10 PM, bmann...@vacation.karoshi.com wrote: On Tue, May 22, 2012 at 08:52:52PM -0700, Michael J Wise wrote: On May 22, 2012, at 8:35 PM, Randy Bush wrote: father of bind? that's news. http://boingboing.net/2012/03/29/paul-vixies-firsthand-accoun.html He was there, and Put The Fix In, to down the network. Certainly news to Phil Almquist and the entire BIND development team at UCB. Paul was at DECWRL and cut his teeth on pre-existing code. While he (and ISC) have since revised, gutted, tossed all the orginal code, rebuilt it twice - and others have done similar for their DNS software, based on the BIND code base, implementation assumptions, and with little or no ISC code, and they call it BIND as well, it would be a HUGE leap of faith to call Paul Vixie the father of BIND - The Berkeley Internet Naming Daemon. Methinks we're talking at cross purposes. maybe... :) my comment was refering to the father of bind statement. As for being there and Put The Fix In... Makes for great PR but in actual fact, its a bandaid that is not going to stem the tide. An actual fix would really need to change the nature of the creaky 1980's implementation artifacts that this community loves so well. I don't think we're talking about the same thing at all. Paul was there to shut down the DNS changer system and replace it with something that restored functionality to the infected machines. And I gather Paul will be one of the people who will turn the lights out on it. He didn't shut down DNS Changer, he put up an equivalent system to hijack DNS traffic and direct it to the right place... SO folks didn't see any problem and the DNS Changer infection grew and got worse. When he is legally required to take his bandaide out of service, then the problem will resolve by folks who will have to clean their systems. As for turning the lights out - that will only happen when the value of DNS hijacking drops. As it is now, ISC has placed DNS hijacking code into their mainstream code base... because DNS hijacking is so valuable to folks. In a modestly favorable light, ISC looks like an arms dealer (DNS redirection) to the bad guys -AND- (via DNSSEC) the good guys. Either way, they make money. And yes, I think I agree with you. Paul will be there to turn things off when they no longer make money for his company. Your other comments are non-sequitur to the main issue. Perhaps I am not a member of the Paul Vixie cult of personality. When those servers are turned off, Customer Support folks at many ISPs will prolly want to take their accrued vacation. Amen. And there will be thousands more of them when the court order expires than existed when the Feds called him in. /bill Aloha, Michael. -- Please have your Internet License and Usenet Registration handy...
Re: International Transit Provider - Delivered locally to Melbourne Australia
unless you cross connect in the landing shack, there will -always- be a domestic local loop. (you don't like Telstra?) /bill On Fri, Apr 13, 2012 at 12:40:42PM +, James Braunegg wrote: Dear All Just wondering if I can get some recommendations for international transit providers who can provide international transit delivered in Melbourne Australia at 55 Crockford Street or 55 King street ie transit without any local domestic Australian routes. Looking forward to hearing from you / suggestions Kindest Regards James Braunegg W: 1300 769 972 | M: 0488 997 207 | D: (03) 9751 7616 E: james.braun...@micron21.commailto:james.braun...@micron21.com | ABN: 12 109 977 666 [Description: Description: Description: Description: Description: M21.jpg] This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer.
Re: Quad-A records in Network Solutions ?
On Thu, Apr 05, 2012 at 10:26:11AM -0700, George B. wrote: On Thu, Mar 29, 2012 at 4:32 AM, Matt Ryanczak ryanc...@gmail.com wrote: I too had with nesol years ago. It required special phone calls to special people to update. Customer support never knew what was going on regarding or IPvWhat?. I suspect all of the people there that know about these types of things have moved on. Netsol has been leaking people since their sale to web.com last year, from actual layoffs and fear of the same. ~matt How long did it take them? We have had a request in for records for a domain for over a week now, and nothing in whois yet. 2002, it took 3hrs. /bill
Re: Quad-A records in Network Solutions ?
On Wed, Mar 28, 2012 at 11:55:35AM -0700, David Conrad wrote: On Mar 28, 2012, at 11:47 AM, Carlos Martinez-Cagnazzo wrote: I'm not a fan of conspiracy theories, but, c'mon. For a provisioning system, an record is just a fragging string, just like any other DNS record. How difficult to support can it be ? Of course it is more than a string. It requires touching code, (hopefully) testing that code, deploying it, training customer support staff to answer questions, updating documentation, etc. Presumably Netsol did the cost/benefit analysis and decided the potential increase in revenue generated by the vast hordes of people demanding IPv6 (or the potential lost in revenue as the vast hordes transfer away) didn't justify the expense. Simple business decision. Regards, -drc once, years ago, Netsol -did- have a path for injecting records. It was prototype code with the engineering team. I had records registered with them. Have since sold the domains and they moved to other registries. But they did support it for a while. /bill
Re: BBC reports Kenya fiber break
we had an instance of B root there for a season. connectivity was a problem and we pulled the node in 2001. /bill On Wed, Feb 29, 2012 at 09:45:16PM -0800, Bill Woodcock wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, Feb 29, 2012 at 10:08 AM, Justin M. Streiner strei...@cluebyfour.org wrote: On Wed, 29 Feb 2012, Rodrick Brown wrote: There's about 1/2 a dozen or so known private and government research facilities on Antarctica and I'm surprised to see no fiber end points on that continent? This can't be true. Constantly shifting ice shelves and glaciers make a terrestrial cable landing very difficult to implement on Antarctica. Satellite connectivity is likely the only feasible option. There are very few places in Antarctica that are reliably ice-free enough of the time to make a viable terrestrial landing station. Getting connectivity from the landing station to other places on the continent is another matter altogether. There were INOC-DBA phones at several of the Antarctic stations, for quite a few years. We could see connectivity to them go up and down as the satellites rose above the horizon and set again. -Bill -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJPTwztAAoJEG+kcEsoi3+HpgwP/2wjrnyjCoBrLgQYC/rsjVYe uE8X9ZcnkAkBYI5Q3Aa3ZeVYNbUaX6OChgnsXlt+1v962Lja+V78QuthVDRCJ1Dp Z5T+XtiIQB4u11lhN55mx8cPXbAKubGCduyCzjBBi+QqE5ayqqCocBHAItxYOMd7 RRS5ijNUKVMtGIWWWHAdMFAdGuy3zOIt/9oWkq9jJo30RJkEVR6pi7b/sGmM7rjX XLVc1RPtCmtDkALohRyQOPrMJ2k7284fJ49t2P2Z/8yBbvJtGRmRBkTiUNis0wtx Ndxed96TaNwwF3snE/zAxu6xCZnjR5trzC586b3ULS2sGSSo2W63AjOqzpMtb8HG /hlK2GuaAe1vy9Qa+6XDwVJZqbkzPKzrNv7A3RjNvFkTapPGwk1FI7SBO46CUqHh y2xED78JrIcoKTbC927eWrrArFGRe4ujx+w2D5enlZJT/vGonDScsE/ISAxITbCx QHbtoAWIjVbraN1UZx+g9hvYOb3AT04zkTImQCj0Kj42COx729WvR7anrkwNNAJV uqQyLK2wyS9ItyG3U54tECeGVeK0nn9Gyuhp9wdIKI4Qs+JHxXb2eHFqzbn9OZHB O7PhbBTW3h+viNUkK2NnoiFbQP3E3ZzzNAKjTN9hWa15uGOKum5xUxSZFCD47BuD J2CjI8dx5PhmLTbcZS4C =M/np -END PGP SIGNATURE-
and now for something completely different
Control of ground-state pluripotency by allelic regulation of Nanog Nature advance online publication 12 February 2012. doi:10.1038/nature10807 Authors: Yusuke Miyanari Maria-Elena Torres-Padilla Pluripotency is established through genome-wide reprogramming during mammalian pre-implantation development, resulting in the formation of the naive epiblast. Reprogramming involves both the resetting of epigenetic marks and the activation of pluripotent-cell-specific genes such as Nanog and Oct4 (also known as Pou5f1). The tight regulation of these genes is crucial for reprogramming, but the mechanisms that regulate their expression in vivo have not been uncovered. Here we show that Nanog—but not Oct4—is monoallelically expressed in early pre-implantation embryos. Nanog then undergoes a progressive switch to biallelic expression during the transition towards ground-state pluripotency in the naive epiblast of the late blastocyst. Embryonic stem (ES) cells grown in leukaemia inhibitory factor (LIF) and serum express Nanog mainly monoallelically and show asynchronous replication of the Nanog locus, a feature of monoallelically expressed genes, but ES cells activate both alleles when cultured under 2i conditions, which mimic the pluripotent ground state in vitro. Live-cell imaging with reporter ES cells confirmed the allelic expression of Nanog and revealed allelic switching. The allelic expression of Nanog is regulated through the fibroblast growth factor–extracellular signal-regulated kinase signalling pathway, and it is accompanied by chromatin changes at the proximal promoter but occurs independently of DNA methylation. Nanog-heterozygous blastocysts have fewer inner-cell-mass derivatives and delayed primitive endoderm formation, indicating a role for the biallelic expression of Nanog in the timely maturation of the inner cell mass into a fully reprogrammed pluripotent epiblast. We suggest that the tight regulation of Nanog dose at the chromosome level is necessary for the acquisition of ground-state pluripotency during development. Our data highlight an unexpected role for allelic expression in controlling the dose of pluripotency factors in vivo, adding an extra level to the regulation of reprogramming.
Re: SSL Certificates
On Thu, Feb 16, 2012 at 12:17:00AM -, John Levine wrote: Almost everyone are basically just selling an activation with one of the SSL certificate authorities. I usually buy a RapidSSL (Verisign) certificate from https://www.sslmatrix.com/ -- they seem to have some of the best prices and the rapidssl enrollment process is very efficient (at least for the cheap automatically validated products). I get my RapidSSL and Comodo from these guys. Prices look about the same: http://www.cheapssls.com/ If you order a cert for example.com, Comodo's also work for www.example.com, no extra charge. R's, John Comodo ever get fixed ?? /bill
Re: Dear RIPE: Please don't encourage phishing
On Sun, Feb 12, 2012 at 09:36:54PM -0800, Randy Bush wrote: DNS is case-insensitive when you are talking about 7-bit ASCII pedantry dns itself is purely eight bit transparent. one can even have a dot as a non-separator. p.r.c could be a tld. it's strictly length/value. of course, everyone and their dog has placed restrictions on it for this use or that. randy ah, the good'ol days. ^g.net as an early attempt for the visually impaired lasted for a couple months. about the same time you received your IPv4 /33 /bill
[POLITICS] ICANN elections
There are four really good candidates. Please consider sending in a statement of support for one of them. /bill - Forwarded message - Date: Fri, 03 Feb 2012 09:38:06 +1000 To: Bill Manning bmann...@karoshi.com Subject: Comment Period for ICANN Board Seat 9 Election Consistent with the ASO Memorandum of Understanding and ICANN Bylaws, the Address Supporting Organization Address Council (ASO AC) is responsible for the appointment of a representative to serve on Seat Number 9 of the ICANN Board. The ASO AC is pleased to announce the following four candidates for its upcoming appointment. The Candidates are: - Thomas Eric Brunner-Williams - Martin J. Levy - William Manning - Raymond Alan Plzak In accordance with the ASO AC election procedures, a comment period is now open. A short biography is available and supporting comment facilities for each candidate may be found at: http://aso.icann.org/people/icann-board-elections/2012-elections/ The comment period will close at 23:59 UTC on 19 April 2012. Comments will be moderated. ASO Secretariat secretar...@aso.icann.org - End forwarded message -
Re: US DOJ victim letter
On Thu, Feb 02, 2012 at 05:57:23AM -0500, Robert E. Seastrom wrote: bmann...@vacation.karoshi.com writes: I missed the part where ARIN turned over its address database w/ associatedd registration information to the Fed ... I mean I've always advocated for LEO access, but ther has been significant pushback fromm the community on unfettered access to that data. As I recall, there are even policies and processes to limit/restrict external queries to prevent a DDos of the whois servers. And some fairly strict policies on who gets dumps of the address space. As far as I know (not very far) bundling the address database -and- the registration data are not available to mere mortals. So - just how DID the Fed get the data w/o violating ARIN policy? Hi Bill, In case you're not trolling here (occam's razor says I'm giving you too much credit), a few points: 1) There has been substantial involvement by Federal LE at ARIN PPMs in terms of pushing for policy that makes WHOIS data more accurate... including one person who served on the ARIN AC after he went to work in the private sector. 2) LE can type show ip bgp too and only needs to hit a whois server once per ASN. 3) There is a bulk whois policy. Whether hi, we now have the reins of a compromised botnet or whatever and want to reach out to let people know that they're pwn3d falls under the rubric of Internet operational or technical research purposes pertaining to Internet operations is left as an exercise to the reader. Section 3.1 of the NRPM says that Bulk Whois ... point of contact information will not include data marked as private. As I outlined in #2 above, a full or partial dump is not really something that's necessary. https://www.arin.net/resources/agreements/bulkwhois.pdf I'm pretty confident there were no policy violations here. -r sigh... will have to look elsewhere for the tri-lateral commission. /bill
Re: US DOJ victim letter
On Fri, Jan 27, 2012 at 10:20:08PM -0500, Martin Hannigan wrote: On Fri, Jan 27, 2012 at 1:32 PM, Randy Epstein na...@hostleasing.net wrote: On 1/27/12 1:23 PM, valdis.kletni...@vt.edu valdis.kletni...@vt.edu wrote: On Fri, 27 Jan 2012 13:16:27 EST, Bryan Horstmann-Allen said: Bit odd, if it's a phish. Even more odd if it's actually from the Fed. What if it's a phish from a compromised Fed box? :) We've spoken to folks at various FBI field offices and at 26 Plaza in New York which is handling this case. Further, John Curran (ARIN CEO) has confirmed it's real via their own liaison and Paul Vixie is actually working with them on this. It's definitely real. Best, -M I missed the part where ARIN turned over its address database w/ associatedd registration information to the Fed ... I mean I've always advocated for LEO access, but ther has been significant pushback fromm the community on unfettered access to that data. As I recall, there are even policies and processes to limit/restrict external queries to prevent a DDos of the whois servers. And some fairly strict policies on who gets dumps of the address space. As far as I know (not very far) bundling the address database -and- the registration data are not available to mere mortals. So - just how DID the Fed get the data w/o violating ARIN policy? /bill
is it -really- global?
anyone keeping track of their RTTs? i'm finishing up some work on latency and all i have are my numbers. its going to be highly variable based on where you are and where you go, but it would be nice to have other sets of numbers. roughly my targets are :: 43% are cloud oriented - CBN stuff that tried to place bits near me 22% are US/CA targets 14% are kcj 12% are eu 4% are africaan 5% are other and the source moves, East/Best coast of the US, Africa, Japan, NZ /bill
Re: LAw Enforcement Contact
On Sun, Jan 22, 2012 at 07:16:39PM -0600, A. Pishdadi wrote: Hello, We recently tracked down a botnet that attacked our network. We found the CC server, it has approximately 40-50 servers, consisting of mostly *nix machines with high speed connections, for example AWS servers or dedicated, attack capacity is 4-5Gb/s or more. Is there any contacts with law enforcement here that I can send over the info too? . Sure is. Check with your local FBI office. /bill
Re: Megaupload.com seized
On Fri, Jan 20, 2012 at 03:05:47AM -0800, Owen DeLong wrote: On Jan 20, 2012, at 2:25 AM, Robert Bonomi wrote: Mark Andrews ma...@isc.org wrote: I suspect most file sharing site don't have illegal content. Most would have some content that is there without the permission of the copyright holder. These are different things. nitpick Without the permission of the copyright holder _is_ contrary to statute, and thus 'against the law'. As such 'illegal' is _not_ an incorrect term to apply to the situation. It may not be a _criminal_ violation, but it is still proscribed by law. Illegal and criminal -- _these_ are different things. Junk faxing is illegal, Telemarketing calls to cell phones are illegal, Public distribution without the permission of the copyright owner is illegal. Except in special cases, none of those actions are _criminal_, but they are all violations of law, and thus _illegal_. Actually, they are all criminal violations. They may be infractions, or, they may not often get prosecuted, but, each is, in fact, a criminal violation. Owen depends on the jurisdiction me thinks. Do US laws apply in India? Nigeria? Mars? Your broad generlizations may not hold. /bill
Re: Whois 172/12
On Sun, Jan 15, 2012 at 06:36:12AM -0600, Robert Bonomi wrote: From nanog-bounces+bonomi=mail.r-bonomi@nanog.org Sun Jan 15 02:02:00 2012 Subject: Re: Whois 172/12 From: Patrick W. Gilmore patr...@ianai.net Date: Sun, 15 Jan 2012 02:58:11 -0500 To: NANOG list nanog@nanog.org Read RFC1918. Likely a machine on his local network (i.e. behind the same NAT box) is hitting him. Patrick, I'v read RFC-1918. I cannot find *any* reference to 172.0/12, as the OP was asking about. 172.16/12, yes. but not 172.0/12. Can you please clarify your advice? ZZ so as a stylistic point, 172/12 is supposed to equal 172.0.0.0/12? if memory serves, back in the day, there were records of allocations in this space, pre-ARIN. When RFC 1918 was settled on, there were some folks blocking 172.0.0.0/8 so there was talk of relocating those folks into other space. /bill
Re: In search of uplink vendor
On Thu, Jan 12, 2012 at 08:01:58AM -0500, Justin M. Streiner wrote: On Thu, 12 Jan 2012, Paul Kaminsky wrote: We are at a stage where we need an all-out uplink vendor to fuel our business endeavor. The bells and whistles we need are: 1. 1 Gbps link with complete block of UDP/ICMP protocol 2. BGP session with our AS 3. Ability to blackhole (no route to host) by /32 prefix 4. Presence in Equinix SV1 or SV5 (San Jose) DC's - this is not mandatory, we're open for suggestions If you feel your company measures up or is a cut above the rest, please get in touch with us to discuss the specific details. Note: I am not a vendor. One question: 1. Not knowing anything about your business, is there a specific reason that you want a complete block of UDP/ICMP protocol? That can be problematic with IPv4, and downright foolish with IPv6. jms perhaps we are walking around w/ incomplete notions of what constitutes a complete block of UDP/ICMP protocol... for me, literally,this makes no sense whatsoever. ratcheting back on my literal filter (be liberal in what you accept) I beleive what he is asking for is a contigious block of IP addresses for use in his network. am also making the inference that he is only looking for IPv4 (no route to host by /32 prefix). so the only remaining, burning question is - what size block? a /33? a /31? maybe a /28? or a /22? a /19? (the /33 is right out... filtering on /32 would block both hosts!) I think its quite reasonable to expect a contigious block of addresses, regardless of address family. Not at all downright foolish. It is rare to see someone -not- get a contigious block. ymmv of course. /bill
