Re: Issues with deliverability to hotmail -- any Microsoft contacts?

2020-07-21 Thread Brock Tice
Many times. I get a weird auto-response after a couple days that doesn't
make any sense and then nothing else happens.

On Mon, Jul 20, 2020 at 1:51 PM Tony Wicks  wrote:

> Have you used this form? I feel your pain.
>
>
>
>
> https://support.microsoft.com/en-us/supportrequestform/8ad563e3-288e-2a61-8122-3ba03d6b8d75
>
>
>
> *From:* NANOG  *On Behalf Of *Brock
> Tice
> *Sent:* Tuesday, 21 July 2020 4:11 am
> *To:* nanog@nanog.org
> *Subject:* Issues with deliverability to hotmail -- any Microsoft
> contacts?
>
>
>
> We have been having issues delivering email to hotmail users again, no
> bulk mail, just various personal emails from a server on our network. We
> have signed up for SNDS, only identified one mail server of a customer on
> our network that was flagged as an issue, and it has been remedied, no
> longer showing in SNDS.
>
> We have repeatedly requested removal of our subnet from their block list
> and it has not worked. MS has done a great job of making it impossible to
> contact anyone about this. Does anyone have pointers on what else can be
> done or whom we should contact to get this resolved?
>
>
>
> Thanks,
>
>   --Brock
>
>
>
> --
>
> Brock M. Tice
>
> Co-Owner and President
>
> Black Mesa Wireless LLC
>
> 505-852-5101
>
> br...@bmwl.co
>


-- 
Brock M. Tice
Co-Owner and President
Black Mesa Wireless LLC
505-852-5101
br...@bmwl.co


Issues with deliverability to hotmail -- any Microsoft contacts?

2020-07-20 Thread Brock Tice
We have been having issues delivering email to hotmail users again, no bulk
mail, just various personal emails from a server on our network. We have
signed up for SNDS, only identified one mail server of a customer on our
network that was flagged as an issue, and it has been remedied, no longer
showing in SNDS.

We have repeatedly requested removal of our subnet from their block list
and it has not worked. MS has done a great job of making it impossible to
contact anyone about this. Does anyone have pointers on what else can be
done or whom we should contact to get this resolved?

Thanks,
  --Brock

-- 
Brock M. Tice
Co-Owner and President
Black Mesa Wireless LLC
505-852-5101
br...@bmwl.co


Technical Contact at Yahoo

2018-11-09 Thread Brock Tice
Yahoo have done a very good job of locking down their contact info. We
have an issue where they seem to be blocking one of our CGN public
addresses.

Does anyone know how I can get in touch with an appropriate person there?


Technical Contact at Yahoo

2018-11-09 Thread Brock Tice
Yahoo have done a very good job of locking down their contact info. We
have an issue where they seem to be blocking one of our CGN public
addresses.

Does anyone know how I can get in touch with an appropriate person there?


Re: new(ish) ipv6 transition tech status on CPE

2018-10-12 Thread Brock Tice
On 10/11/2018 09:39 PM, Tom Ammon wrote:
> What did you experience with the dual-stack/CGN approach that keeps you
> from recommending it?

Nothing, sorry if my writing was confusing. It was the 464XLAT that I
don't recommend at this time, lack of vendor support by the brands we
currently use (especially Mikrotik and Ubiquiti) was the main issue.


Re: new(ish) ipv6 transition tech status on CPE

2018-10-10 Thread Brock Tice
On 10/09/2018 06:24 PM, Philip Loenneker wrote:
> I have asked several vendors we deal with about the newer technologies
> such as 464XLAT, and have had some responses indicating they will
> investigate internally, however we have not made much progress yet. One
> vendor suggested their device supports NAT46 and NAT64 so may support
> 464XLAT, but since it is incidental rather than an official feature, it
> may not support the full CLAT requirements. I have been meaning to do
> some tests but haven’t had a chance yet. It is also a higher price point
> than our current CPEs.
> 
>  
> 
> I have spoken to people who have looked into options such as OpenWRT
> (which supports several of these technolgoies), however the R and
> ongoing support is a significant roadblock to overcome.
> 

We looked into this somewhat intently ~6 months ago and had not much
luck from vendors. Barely on their radar if at all.

We used our own custom OpenWRT build on a few select, tested consumer
routers to do 464XLAT. In the end we went to dual-stack with CGN on
IPv4. I wrote up some documentation on how we did it on my blog, but in
the end I can't recommend the setup we used.

I would love RouterOS and (various mfgr) CPE support for 464XLAT, then I
would be ready to give it another shot.


Re: Blockchain and Networking

2018-01-23 Thread Brock Tice

On 1/23/2018 6:17 AM, Jimmy Hess wrote:

The potential is there to go a step beyond replacing RPKI,   as a blockchain
could be the AS number authority itself,  thus eliminating the need to
have any centralized organizations for  tracking and managing
number resource assignments.
I am a long-time follower and fan of Bitcoin and I have a lot of 
skepticism of most of the ideas for using blockchain tech for other 
things. They seem like ill-thought-out solutions in search of a problem.


HOWEVER, various Internet/number authorities are sometimes a big point 
of contention, subject to government pressure, etc, and this is one case 
where I can see a trustless, distributed blockchain architecture 
actually improving things.


I think your email (not just the quoted part) was a good insight on the 
subject.


--Brock


Re: 48vDC Output UPS

2017-12-29 Thread Brock Tice
On December 29, 2017 5:58:02 PM MST, "Lewis,Mitchell T." 
 wrote:
>Greetings again, 
>I have been looking for a Rack Mount UPS that accepts AC power input
>but has 48vdc output(telco voltage). Anyone have any recommendations? 
>
>
>
>Regards, 
>
>Mitchell T. Lewis 
>
>[ mailto:mle...@techcompute.net | mle...@techcompute.net ] 
>
>
>[ http://linkedin.com/in/mlewiscc ] |203-816-0371 
>
>PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E [
>https://pgp.mit.edu/pks/lookup?op=get=0x2AFA805732A1394E |
>Public PGP Key ] 
>   

Samlex makes a nice one. 25A output.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.


Re: Waste will kill ipv6 too

2017-12-28 Thread Brock Tice
Hi Lyndon, thanks for taking the time to address my questions. Responses
below.

On 2017-12-28 17:57, Lyndon Nerenberg wrote:
>> On Dec 28, 2017, at 3:28 PM, Brock Tice <br...@bmwl.co> wrote:
>> We are currently handing out /52s to customers. Based on a reasonable
>> sparse allocation scheme that would account for future growth that
>> seemed like the best option.
> Could you detail the reasoning behind your allocation scheme?  I.e., what are 
> the assumptions you're making about customers deploying hardware? How will 
> they need those devices isolated?  What data fed the model you used to come 
> up with those numbers?

I am going to address a bunch of these together below.

> I ask because I have seen many ISPs advocate for smaller than /48 customer 
> allocations, but I haven't seen anyone present the model they used to come up 
> with those numbers.  I really am curious to know the assumptions and 
> rationale behind the various allocation schemes ISPs are coming up with.
> 
>> I can't really see how /52 is too small for a residential customer. I
>> know originally it was supposed to be /48 but after doing a bit of
>> reading I think many people have admitted there is room for nuance.
> What reading?  Can you provide pointers to the documents you were reading?  
> Again, I'm curious to understand how and why ISPs are making these decisions.
> 
> Also, the fact that you "can't see it" doesn't mean they (or someone else) 
> can't or won't.  An ISP's job is to shovel packets around.  No more, no less.

I think with a little more nuance, an ISP's job is to manage resources
properly in order to shovel packets around as well as possible. In this
case, IP address space.

>> Do you think I could go to ARIN and say, well, we haven't used hardly
>> any of this but based on such-and-such allocation scheme, it would be
>> much better if you gave us a /32 instead of a /36?
> Hardly used any of what?  Are you talking about density of the customer hosts 
> inside each of these /64 subnets?  This is where I think the biggest 
> misunderstandings of the IPv6 allocation strategy comes from.

No, see below. I'm talking about the fact that we've got a sparse
allocation scheme and even within that most of the subnets we've
allocated for towers don't have towers attached to them. They certainly
could in the next decade, though.

> Ask yourself this: do you think the intention was to have 2^64 hosts on a 
> single LAN segment?  

No

>> Also, does anyone know whether ARIN is using sparse allocation, such
>> that if we go back later and ask for more they will just increase the
>> size of our allocation starting from the same point?
> You could just ask them.  But the policies for ISP allocations (last time I 
> read them) makes it pretty straight forward for you to get a block that fits 
> your growth needs for the foreseeable future.†
> 
> But really, if you are worried about having to advertise, say, eight IPv6 
> prefixes to the DFZ for all your allocations, haven't you just argued against 
> the fragmented /52 allocations to your downstream customers?

I'm just wondering if I'm likely to have to renumber just to go to a
more generous allocation scheme. I guess better now than in 5 years if so.

> You need to treat IPv6 addresses as being 64 bits long.  Those extra 64 bits 
> on the right are just noise – ignore them.  Instead, think about how we can 
> carve up a 2^61 address space (based on the current /3 active global 
> allocation pool) between 2^32 people (Earth's current population), each 
> having 2^16 devices, needing their own network.  That makes for a densely 
> allocated /48 for each person on the planet.  (Coincidence?)  But when we get 
> to the point of filling up that /3, we still have five more /3s to work with.

OK addressing all of the rest of this here. I'm admittedly no expert on
IPv6, I've been forced to learn it in a hurry. I did read most of
"Migrating to IPv6" by Marc Blanchet and "IPv6 Address Planning" by Tom
Coffeen. I believe I read quite a few things about deciding on subnet
sizing there.

>From those books I basically learned to think in /64s (generally one per
router interface). I'm not very concerned with the number of hosts in a
/64 for obvious reasons.

Most of our customers only have 2-5 devices. I know this is not the case
in most of America but we are quite rural and for many people they've
never had better than 1.5Mbps DSL until we install service at their
location. Most of them have no idea what a subnet is. Let us say that
over the next ten years they get quite savvy and decide to isolate their
wireless clients, some public servers, their IoT devices, and their
security cameras. We have given them a /52 which contains 4096 /64s. So,
most likely, they will use one of

Re: Waste will kill ipv6 too

2017-12-28 Thread Brock Tice
On 12/28/2017 03:44 PM, James R Cutler wrote:
> There is no prohibition of requesting an allocation which matches your 
> network. That is, simply request what is needed with suitable data for 
> justification and get your /40 or whatever.

We are currently handing out /52s to customers. Based on a reasonable
sparse allocation scheme that would account for future growth that
seemed like the best option.

I can't really see how /52 is too small for a residential customer. I
know originally it was supposed to be /48 but after doing a bit of
reading I think many people have admitted there is room for nuance.

Do you think I could go to ARIN and say, well, we haven't used hardly
any of this but based on such-and-such allocation scheme, it would be
much better if you gave us a /32 instead of a /36?

Also, does anyone know whether ARIN is using sparse allocation, such
that if we go back later and ask for more they will just increase the
size of our allocation starting from the same point?

--Brock



Re: Implementing 464XLAT at a small WISP

2017-12-28 Thread Brock Tice
On 2017-12-28 04:11, JORDI PALET MARTINEZ wrote:
> Thanks for sharing. It's interesting to see enterprise customers
> adopting OpenWRT/LEDE despite no official support from CPE vendors for
> 3rd party firmware on their products.

One reason we are using Linksys so far is their nominal support for
"open source" on their routers. I started testing with the WRT 1900ACS,
which is a bit expensive for us to be handing out to everyone. We will
be using those for customers on higher-speed plans.

Honestly, given the number of bugs we've dealt with from our other
vendors, and the lack of ability to fix (or even find) them ourselves,
I'm at least as comfortable with OpenWRT/LEDE as I am with, say AirOS or
RouterOS deployed in our network.


Implementing 464XLAT at a small WISP

2017-12-27 Thread Brock Tice
We recently deployed our first half-dozen IPv6-only customers after 6+ 
months of testing, using 464XLAT.


It took me ages to sort all this out, so I hope someone finds this 
helpful. Feedback very much welcome.


https://blog.brocktice.com/2017/12/27/deploying-464xlat-for-ipv6-only-clients-on-a-small-wisp-network-with-mikrotik-routers/


Re: Geolocation: IPv4 Subnet blocked by HULU, and others

2017-12-27 Thread Brock Tice
On 12/27/2017 04:11 PM, Jima wrote:
> On 2017-12-27 15:50, William Herrin wrote:
>> Net 196/8 is part of the swamp. Just speculating, but perhaps the
>> original registration of 196.53.96.0/22 
>> pre-dated the reassignment of 196/8 to AfriNIC?
> 
> Maybe? This snippet from WHOIS kind of nags at me, though:
> 
> inetnum:    196.52.0.0 - 196.55.255.255
> netname:    LogicWeb-Inc
> descr:  LogicWeb Inc.
> descr:  3003 Woodbridge Ave
> descr:  Edison, NJ 08837
> country:    ZA
> 
> Why South Africa if it's a legacy block? It looks like that stems from
> delegated-afrinic-extended, though:
> 
> afrinic|ZA|ipv4|196.52.0.0|262144|19951009|allocated|F36E02F6

We are leasing a /24 from that block as well, it's caused us similar
issues but they are mostly resolved now.

Luckily we've now deployed our first ipv6 customers with 464xlat and
it's working well, so I hope to be able to stop leasing that subnet in 2018.

It's hard for small ISPs that can't afford to buy IPv4 blocks, now that
ARIN is not handing them out. We're lucky we got a /23, if we'd started
a few years later we'd have nothing.

--Brock



Subnet being blocked by Level3 due to prior owner's misuse

2017-11-29 Thread Brock Tice
We have a subnet that used to belong to someone else. One of our
business customers that was recently moved to that subnet is being
blocked from accessing one of their supplier's web site that's hosted by
Level3.

Our attempts to work through the supplier to resolve the issue have not
worked as they are not aware of what's happening at that level. Our
other attempts to resolve this have not worked.

Would someone from Level3 be able to help resolve this off-list, or does
someone have the appropriate contact information?

Thanks,
  --Brock


Re: Google DNS64 misconfigured?

2017-09-27 Thread Brock Tice
On 09/26/2017 11:00 PM, Joel Whitehouse wrote:
> A forum topic [0] suggests this behavior might be intermittent but no
> official response from google there.

I have seen intermittent issues with IPv6 queries to google's
nameservers as well. Some sites simply would not load, which is what
caused me to notice it.

--Brock



Re: IPv6 migration steps for mid-scale isp

2017-09-15 Thread Brock Tice
We are small but we are just about out of IPv4 and aren't going to get
or buy any more. We have been testing for a while.

> Shall I go for IPv6-only deployment or dual stack?

You should plan for adding customers eventually that are IPv6-only,
unless you have all the v4 you will ever need, and you will need to
reserve IPv4 address blocks for translation.

> How to identify address CPE and legacy application issues?

Legacy application issues can be solved (for the most part) with
464XLAT, which also solves IP-literal-in-HTML problems. You need PLAT at
the core and CLAT at the client. Unfortunately so far the only good way
we've found to do CLAT is OpenWRT on the CPE or router. We are getting
ready to bundle Linksys routers flashed with OpenWRT.

For PLAT at the core we are running jool. It's actually quite simple to
set up and we are currently using OSPF to do anycast, but we will
probably be migrating to a single set of HA servers in the core. The
good news is that even if it goes down, Netflix and Facebook will still
work as they are fully functional on v6.

We have tested this in my home and at my office with IPv6-only
VLANs/wireless SSIDs, mostly without a hitch.

If you run this setup without the CLAT on the client side you get NAT64
so it still will work for most things.

I would be very, very happy if larger ISPs would put pressure on router
manufacturers to support CLAT, we have no clout. I would also love to
hear if any of this is stupid or if there's a better way.

--Brock


Re: Admiral Hosting in London

2017-08-09 Thread Brock Tice
On August 8, 2017 6:25:56 PM MDT, Mike Hammett  wrote:
>I've heard of some people that don't have the capital to purchase their
>own block yet, but want PI space so they can move away from whomever is
>providing their transit + IP space now. I'm sure the discussed reason
>is much more prevalent, though. 
>
>
>
>
>- 
>Mike Hammett 
>Intelligent Computing Solutions 
>http://www.ics-il.com 
>
>Midwest-IX 
>http://www.midwest-ix.com 
>
>- Original Message -
>
>From: "Chris Woodfield"  
>To: "Randy Bush" , "Michael Wayne"  
>Cc: "NANOG list"  
>Sent: Monday, July 31, 2017 11:31:47 AM 
>Subject: Re: Admiral Hosting in London 
>
>And I’d *love* to hear the story they come up with when you ask why
>they only want to rent space vs buy it… 
>
>-C 
>
>> On Jul 27, 2017, at 9:22 PM, Randy Bush  wrote: 
>> 
>>> We were contacted by Admiral Hosting in London to rent some our 
>>> unused IP space. 
>> 
>> anyone wanting to rent/lease space is 99% sure to be not nice folk. 
>> if you get your space back, it will be radioactive with an amazingly 
>> long half life. 
>> 
>> if you are willing to let go of the space, just tell them the price 
>> for which you are willing to sell it. 
>> 
>> randy 
>> 

We are renting space to supplement our ARIN IPv4 allocation until we get 
464xlat going. Some of the IPs had bad reputations but we sorted them out.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.