Re: DNS Issue with proofpoint.com

[bmanning]

On Wed, Apr 16, 2014 at 10:49:24AM -0400, William Herrin wrote:
> On Wed, Apr 16, 2014 at 10:45 AM, TGLASSEY  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: 
> 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 blah blah blah blah....

[bmanning]

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: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]

[bmanning]

On Mon, Apr 14, 2014 at 03:59:21PM -0400, Patrick W. Gilmore wrote:
> On Apr 14, 2014, at 15:47 , Scott Howard  wrote:
> > On Sun, Apr 13, 2014 at 9:52 AM, Niels Bakker 
> > wrote:
> 
> >> At least one vendor, Akamai is helping out now:
> >> http://marc.info/?l=openssl-users&m=139723710923076&w=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: Yahoo DMARC breakage

[bmanning]

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 
 is a single human and not a list?

/bill

Re: Serious bug in ubiquitous OpenSSL library: "Heartbleed"

[bmanning]

On Tue, Apr 08, 2014 at 11:46:31PM -0400, Rob Seastrom wrote:
> 
> Me  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: Serious bug in ubiquitous OpenSSL library: "Heartbleed"

[bmanning]

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: .
> >
> >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: Recommendation on NTP appliances/devices

[bmanning]

 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  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  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

[bmanning]

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

[bmanning]

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: misunderstanding scale

[bmanning]

On Sun, Mar 23, 2014 at 04:27:16PM -0500, Timothy Morizot wrote:
> On Mar 23, 2014 11:27 AM, "Paul Ferguson"  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: [dns-wg] Global Vs local node data in www.root-servers.org

[bmanning]

On Mon, Mar 17, 2014 at 11:11:40AM -0400, Joe Abley wrote:
> 
> On 17 Mar 2014, at 10:27, manning bill  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.

[bmanning]

RFC 2182



On Mon, Mar 10, 2014 at 02:57:06PM -0400, Rob Seastrom wrote:
> 
> Larry Sheldon  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.

[bmanning]

On Thu, Mar 06, 2014 at 08:07:55AM -0500, Rob Seastrom wrote:
> 
> Nick Hilliard  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.

[bmanning]

On Wed, Mar 05, 2014 at 07:52:10AM -0500, Rob Seastrom wrote:
> 
> "Paul S."  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]

[bmanning]

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

[bmanning]

On Fri, Nov 08, 2013 at 08:37:32AM -0500, William Herrin wrote:
> On Sun, Nov 3, 2013 at 11:39 AM,   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: 
> Falls Church, VA 22042-3004

[pfsi...@gmail.com: [APRICOT-INFO] APRICOT 2014 call for papers]

[bmanning]

of possible interest.

/bill

- Forwarded message from Philip Smith  -

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

[bmanning]

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.

[bmanning]

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:
> 
> 
> 
> 2009 - 2011 Arbor WISRs:
> 
> 
> 
> Current Arbor WISR:
> 
> 
> 
> ---
> Roland Dobbins  // 
> 

and this gem...

http://technology.ie/digital-attack-map-shows-ddos-attacks/

Re: comcast ipv6 PTR - DNSSEC

[bmanning]

On Mon, Oct 14, 2013 at 10:18:15PM -0500, Jimmy Hess wrote:
> On Mon, Oct 14, 2013 at 10:01 PM, Barry Shein  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

[bmanning]

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  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

[bmanning]

On Mon, Sep 30, 2013 at 11:27:26AM -0400, William Herrin wrote:
> On Mon, Sep 30, 2013 at 10:46 AM, TJ  wrote:
> > On Mon, Sep 30, 2013 at 9:32 AM, William Herrin  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

[bmanning]

 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 
> >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: minimum IPv6 announcement size

[bmanning]

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

[bmanning]

 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  
> 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: DNS Reliability

[bmanning]

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?

[bmanning]

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

[bmanning]

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

[bmanning]

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

[bmanning]

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?

[bmanning]

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?

[bmanning]

On Thu, Aug 15, 2013 at 12:19:38AM -0400, Sean Donelan wrote:
> 
> Either there is a lot of traffic missing, or market concentration is much 
> greater than assumed.
> 

I'd argue that its both.

/bill

Re: How big is the Internet?

[bmanning]

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)
> AT&T Big Petabyte report (AT&T 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: How big is the Internet? - about the size of a strawberry

[bmanning]

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: On topic of domains

[bmanning]

On Fri, Jul 12, 2013 at 08:45:50AM +1000, Mark Andrews wrote:
> 
> In message , 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?

[bmanning]

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"  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

[bmanning]

On Thu, May 23, 2013 at 11:39:12PM -0700, Owen DeLong wrote:
> 
> On May 23, 2013, at 23:17 , David Conrad  wrote:
> 
> > On May 23, 2013, at 10:53 PM, Andreas Larsen  
> > 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

[bmanning]

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  and i'll
forward them on for you.

Cheers,
Emma
-

Re: someone from Sprint

[bmanning]

 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 -
> > 
> > (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

[bmanning]

 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 -

(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 ?

[bmanning]

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

[bmanning]

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: Tier 2 ingress filtering

[bmanning]

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: BCP38 - Internet Death Penalty

[bmanning]

 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  wrote:
> 
> > Can't we get homeland security into this? Threat to US national security if 
> > people can spoof? :P
> 

Re: ORP

[bmanning]

On Tue, Mar 26, 2013 at 08:07:22AM -0400, Patrick W. Gilmore wrote:
> On Mar 26, 2013, at 08:01 , "Dobbins, Roland"  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: Why are there no GeoDNS solutions anywhere in sight?

[bmanning]

On Thu, Mar 21, 2013 at 12:23:02AM -0700, Constantine A. Murenin wrote:
> On 20 March 2013 21:29, Masataka Ohta  
> wrote:
> > Constantine A. Murenin wrote:
> >
> >> Why even stop there:  all modern browsers usually know the exact
> >> location of the user, often with street-level accuracy.
> >
> > If you think mobile, they don't, especially because "often" is
> > not at all "enough times".
> 
> Are you suggesting that geolocation is inaccurate enough to misplace
> Europe with Asia?


last month, while in western australia, geoloc pegged me in utah.
this morning, geoloc pegged me in Kansas, while resident in Maryland.


> >> Why is there no way to do any of this?
> >
> > Because it is impractical to assume an IP address can be mapped
> > uniquely to a geolocation.
> 
> Why is it impractical?  If I have a server in Germany and in Quebec,
> why would it be impractical to have the logic in place such that
> European visitors would be contacting the server in Germany, and
> visitors from US/Canada -- the one in Quebec?
> 
> C.

secure dynamic update works.  waht is TWC's incentive to allow clients to update
tjheir reverse DNS delegations, esp when clients are leaving them for T-Mobile?


your sugesting the cretion and deployment of something that already exists
in the LOC RR.  Your rational is that LOC isn't used.  If thats the case,
why would your proposal be any more successful?

/bill

Re: Why are there no GeoDNS solutions anywhere in sight?

[bmanning]

On Wed, Mar 20, 2013 at 11:55:41PM -0700, Constantine A. Murenin wrote:
> On 20 March 2013 20:43, Andrew Sullivan  wrote:
> > On Wed, Mar 20, 2013 at 08:28:23PM -0700, Constantine A. Murenin wrote:
> >> Any plans to make DNS itself GeoDNS-friendly?
> >
> > No.  And I say this as someone working for a vendor that provides that
> > service.
> >
> > Any sort of "Geo" DNS is what protocol people would call a "stupid DNS
> > trick".  It works in particular, narrowly-scoped ways because of the
> > loose coherence of the DNS.  But as a matter of protocol, you can't
> > really standardize it, because it's actually taking advantage of
> > certain flexibilities in the DNS and its interaction with the routing
> > system.  Turning that operational fact into a protocol feature would
> > be a bad idea.
> 
> You are coming to this from the perspective of the existing
> conventions, and the current way that GeoDNS is done through a
> Split-Horizon DNS hack.
> 
> But this is not what I want.
> 
> What I want is an ability to specify multiple A and  records, and
> their locations, and make it possible for the web-browser to
> automatically select the best location based on the presumed location
> of the user.  Browsers might have a couple of rules, e.g. that Europe
> and parts of Asia are currently not directly connected to Asia, but NA
> is, and such rules would influence browser's decision to choose a
> Quebec server for a user in Japan, since it'll likely be much closer
> than the one in Moscow.
> 
> Does it sound too complicated and pointy?  Yes, it's not exactly
> trivial, and not as good as BGP, but better than having 300ms latency
> from a simple round-robin.
> 
> C.


peice of cake.   add loc records to your rrset.

/bill

Re: can you share ipv6 addressallo cation

[bmanning]

 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 therebs
> 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 bIPv6 has 340 undecillion unique addresses (thatbs a
> 39-digit number). If IPv4 is a golf ball IPv6 is the sun.b Trust me,
> donbt 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  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  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?

[bmanning]

 
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 reaso

Re: De-funding the ITU

[bmanning]

On Sat, Jan 12, 2013 at 10:49:59PM -0800, Bill Woodcock wrote:
> 
> On Jan 12, 2013, at 9:04 PM, "Fred Baker (fred)"  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

[bmanning]

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.

[bmanning]

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.

[bmanning]

On Fri, Dec 14, 2012 at 08:48:07PM -0800, David Conrad wrote:
> On Dec 14, 2012, at 11:02 AM, Joe Abley  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: Advisory — D-root is changing its IPv4 address on the 3rd of January.

[bmanning]

On Fri, Dec 14, 2012 at 03:10:44PM -0600, Joe Antkowiak wrote:
> On Fri, Dec 14, 2012 at 2:13 PM, Jason Castonguay  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.

[bmanning]

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: btw, the itu imploded - NOT

[bmanning]

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.

[bmanning]

On Fri, Dec 14, 2012 at 02:25:43PM -0500, Jay Ashworth wrote:
> - Original Message -
> > From: "Joe Abley" 
> 
> > >> Quite so: UMD: Where will the old IP route after the 6 month period
> > >> is complete? Somewhere safe?
> 
> > As I understand it (but ask UMD!)
> > 
> > - D-Root is currently numbered out of a general-purpose UMD /16 into a
> > dedicated, specifically-assigned /24
> > - the UMD /16 is not going anywhere
> > 
> > The announcement is that D-Root is being renumbered, not that UMD is
> > renumbering its whole network.
> 
> 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?)
> 
> Cheers,
> -- jra

But how do you know the Renesys allocations haven't been hijacked??

/bill

Re: Advisory — D-root is changing its IPv4 address on the 3rd of January.

[bmanning]

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: Advisory — D-root is changing its IPv4 address on the 3rd of January.

[bmanning]

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:

[bmanning]

On Wed, Dec 12, 2012 at 07:57:11AM -0800, Randy Bush wrote:
> flower tailor  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

[bmanning]

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

[bmanning]

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

[bmanning]

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

[bmanning]

 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
> 

Re: IP tunnel MTU

[bmanning]

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: IP tunnel MTU

[bmanning]

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

the little ssh that (sometimes) couldn't

[bmanning]

corruption!


http://mina.naguib.ca/blog/2012/10/22/the-little-ssh-that-sometimes-couldnt.html


/bill

Re: Issues encountered with assigning .0 and .255 as usable addresses?

[bmanning]

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: Is a /48 still the smallest thing you can route independently?

[bmanning]

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: Another LTE network turns up as IPv4-only

[bmanning]

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: ESR muses on, among other things, the early IETF

[bmanning]

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: ESR muses on, among other things, the early IETF

[bmanning]

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: RIRs give out unique addresses (Was: something has a /8! ...)

[bmanning]

 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"  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 m

Re: RIRs give out unique addresses (Was: something has a /8! ...)

[bmanning]

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"  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 
> > 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), 
> >>>  -
> >>> 
> >>> "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: guys & dolls (a film motif)

[bmanning]

 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: guys & dolls (a film motif)

[bmanning]

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

Are NAT'ed networks part of the Internet?

[bmanning]

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: Optical network simulator

[bmanning]

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

[bmanning]

On Fri, Aug 03, 2012 at 08:47:30PM +, John Curran wrote:
> On Aug 3, 2012, at 2:06 PM, "Patrick W. Gilmore"  wrote:
> 
> > [Feels operational to me.]
> > 
> > 
> > 
> > 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

[bmanning]

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

[bmanning]

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

[bmanning]

 
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!

[bmanning]

 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  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

[bmanning]

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.

[bmanning]

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

[bmanning]

On Wed, May 23, 2012 at 04:33:28PM -0400, Christopher Morrow wrote:
> On Wed, May 23, 2012 at 1:40 AM,   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

[bmanning]

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.
> >> 
> >>
> >> 
> >> 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: Vixie warns: DNS Changer ‘blackouts’ inevitable

[bmanning]

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.
> 
>   
> 
> 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

[bmanning]

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: International Transit Provider - Delivered locally to Melbourne Australia

[bmanning]

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.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 ?

[bmanning]

On Thu, Apr 05, 2012 at 10:26:11AM -0700, George B. wrote:
> On Thu, Mar 29, 2012 at 4:32 AM, Matt Ryanczak  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 ?

[bmanning]

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

[bmanning]

 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
> >>  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-
> 
> 

Re: SSL Certificates

[bmanning]

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

and now for something completely different

[bmanning]

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: Dear RIPE: Please don't encourage phishing

[bmanning]

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

[bmanning]

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 
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

[bmanning]

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

[bmanning]

On Fri, Jan 27, 2012 at 10:20:08PM -0500, Martin Hannigan wrote:
> On Fri, Jan 27, 2012 at 1:32 PM, Randy Epstein  wrote:
> >
> >
> > On 1/27/12 1:23 PM, "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?

[bmanning]

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