Re: Hurricane Maria: Summary of communication status - and lack of

[Sean Donelan]

According to PREPA Net, the fiber subsidary of the Electric Power 
Authority, the power system for the Punta las Marías submarine cable 
station is back in service after flooding.  I think Isla Verde and Punta 
las Marias refer to the same landing point.


I don't know the status of individual submarine cable systems using that 
landing station.


The Miramar and San Juan cable landing stations are also in service.

Re: Hurricane Maria: Summary of communication status - and lack of

[Sean Donelan]

Reportedly most (All?) operational cellular carriers on Puerto Rico have 
activated "universal roaming" service.  All working towers will accept 
roaming connections from any phone from any carrier (or no service 
provider). You may need to turn the phone off & on so it scans for a 
working signal.


Roaming still requires a working cell tower. 48 counties and 
county-equivalents in Puerto Rico have 0% cell sites working. Less than 
25% of cell sites in the remaining counties are working. Capacity is 
extremely limited, so use SMS/Text rather than voice or data.


A side-effect of universal roaming is lack of billing, so expect carriers 
to announce they are waiving charges and overages in Puerto Rico.

Re: Hurricane Maria: Summary of communication status - and lack of

[Javier J]

T-Mobile PR on twitter just posted that two of it's submarine cables are
out of service.

Claro PR Wireless (this is the ILEC in PR) website can't even be reached.

I am assuming this is due to power and submarine cable issues since I'm
sure t-mobile and many other providers are using the same cables.

Link to the post on twitter:
https://twitter.com/tmobilepr/status/911644083155869697

- Javier

On Fri, Sep 22, 2017 at 10:43 AM, Sean Donelan  wrote:

>
> Following up - there are three cable landing stations and 9 submarine
> cable systems connecting Puerto Rico.
>
> One of the cable landing stations experienced flooding, and shutdown its
> power system affecting some circuits.  I haven't been able to determine how
> many submarine cable systems are affected, since they share cable landing
> stations.
>
>

Re: Application Layer Gateways

[Jean-Francois Mezei]

What you do with the CPE  "firewall" settings depends on what sort of
ISP you are. Do you cater to geeks or aunts/grand mothers?

Whatever you do, I would suggest that you document in a place that is
easy for customers to find exactlyt what apps/protocols are open/closed
with the settings you've decided on (especially if it deviates from any
documentation available on the net for that device)


You could consider configuring it by default to protect the aunts and
grand mothers, but make sure geeks get the info on how to easily open
ports for their apps.

Also depends on what you block at the network level. If you block all
incoming calls to port 25, then blocking it at the CPE router won't add
much resilience against attacks as it is already blocked.

Re: Application Layer Gateways

[Stephen Satchell]

On 09/23/2017 07:47 AM, Ca By wrote:
> On Sat, Sep 23, 2017 at 7:13 AM Colton Conor  wrote:
>> Just not sure why big vendors like Alcatel and Comtrend would have them
>> enabled by default if they do more harm than good?
> Turns out vendors focus on building and selling gear but are not
> experienced in running networks

I don't have any quarrel with your statement about experience with
running networks, but I would surmise the real reason is that same one
that caused Microsoft to turn on so much Bad Stuff(tm) in Windows by
default:  reduction in tech support calls.

How many times have you read a manual cover-to-cover for a new piece of
equipment before doing ANYTHING with it?  Especially when the manual is
on CD-ROM, and the PDFs take up about 500 MB of the 700 MB of available
space.

I have yet to find a piece of network gear that has a "cheat sheet" that
bullet-lists all the options (and perhaps a 25-word description) and
where in the manual to find how to turn it on/off.

Even better would be a collection of canned configuration files, from
"absolute minimum" (EVERYTHING turned off) to "all the bells and
whistles enabled".  Note that this corresponds to the concept of "mostly
closed" firewalls and "mostly open" firewalls.

I've seen model configuration files in Unix/Linux where all the defaults
(which constitutes an absolute minimum of turned-on options) are shown
in comments, so that you can just go through the config and turn on
exactly what you need.

Re: Application Layer Gateways

[Ca By]

On Sat, Sep 23, 2017 at 7:13 AM Colton Conor  wrote:

> So you do recommend we disable them all?
>

Yes. A good rule of thumb is to turn off any feature you do not need.  If
you find customers complain, you can turn it on one by one.

The reverse is not true, once the ALG is on you will be affraid you might
break something if you turn it off


Just not sure why big vendors like Alcatel and Comtrend would have them
> enabled by default if they do more harm than good?
>

Turns out vendors focus on building and selling gear but are not
experienced in running networks


> On Thu, Sep 21, 2017 at 11:02 PM, Ca By  wrote:
>
>>
>> On Thu, Sep 21, 2017 at 8:12 PM Colton Conor 
>> wrote:
>>
>>> Working with an ISP, we recently deployed Comtrend VDSL routers, and
>>> Alcatel-Lucent GPON ONTs. Both of these devices uses chipsets made by
>>> Broadcom, and as such probably use the same underlying Broadcom operating
>>> system if I had to guess. They are different chipsets though as one is
>>> from
>>> VDSL2, and the other for GPON
>>>
>>> By default, the Comtrend had the following Firewall -- ALG/Pass-Throughs
>>> enabled:
>>>
>>> FTP
>>> H323
>>> IPSec
>>> IRC
>>> PPTP
>>> RTSP
>>> SIP
>>> TFTP
>>>
>>> On the Acatel-Lucent (Nokia) ONT, the following came enabled by default
>>> from the factory:
>>>
>>> FTP
>>> H323
>>> IPSEC
>>> L2TP
>>> PPTP
>>> RTSP
>>> SIP
>>> TFTP
>>>
>>>
>>> The only difference between these two is the Comtrend has an IRC as a
>>> ALG,
>>> and Acatel has L2TP as a protocol type. The other seven ALG protocols as
>>> the same.
>>>
>>> My question is in general, is it a good idea to disable all Application
>>> Layer Gateways?
>>>
>>
>> Yes. ALG are frequently too smart for their own good.
>>
>>
>>
>>> The only ALG I have had experience with was a SIP ALG. Almost all SIP
>>> providers strongly recommend you disable SIP ALGs as it does more harm
>>> and
>>> breaks more things than it does good, so we always disable SIP ALG. But
>>> what about the other protocols on these two? Do you think they should be
>>> enabled or disabled by default?
>>>
>>> I am leaning towards disabling them all for our standard config.
>>>
>>
>

Re: Application Layer Gateways

[Colton Conor]

So you do recommend we disable them all? Just not sure why big vendors like
Alcatel and Comtrend would have them enabled by default if they do more
harm than good?

On Thu, Sep 21, 2017 at 11:02 PM, Ca By  wrote:

>
> On Thu, Sep 21, 2017 at 8:12 PM Colton Conor 
> wrote:
>
>> Working with an ISP, we recently deployed Comtrend VDSL routers, and
>> Alcatel-Lucent GPON ONTs. Both of these devices uses chipsets made by
>> Broadcom, and as such probably use the same underlying Broadcom operating
>> system if I had to guess. They are different chipsets though as one is
>> from
>> VDSL2, and the other for GPON
>>
>> By default, the Comtrend had the following Firewall -- ALG/Pass-Throughs
>> enabled:
>>
>> FTP
>> H323
>> IPSec
>> IRC
>> PPTP
>> RTSP
>> SIP
>> TFTP
>>
>> On the Acatel-Lucent (Nokia) ONT, the following came enabled by default
>> from the factory:
>>
>> FTP
>> H323
>> IPSEC
>> L2TP
>> PPTP
>> RTSP
>> SIP
>> TFTP
>>
>>
>> The only difference between these two is the Comtrend has an IRC as a ALG,
>> and Acatel has L2TP as a protocol type. The other seven ALG protocols as
>> the same.
>>
>> My question is in general, is it a good idea to disable all Application
>> Layer Gateways?
>>
>
> Yes. ALG are frequently too smart for their own good.
>
>
>
>> The only ALG I have had experience with was a SIP ALG. Almost all SIP
>> providers strongly recommend you disable SIP ALGs as it does more harm and
>> breaks more things than it does good, so we always disable SIP ALG. But
>> what about the other protocols on these two? Do you think they should be
>> enabled or disabled by default?
>>
>> I am leaning towards disabling them all for our standard config.
>>
>

Re: IPv6 migration steps for mid-scale isp

[Mikael Abrahamsson]

On Sat, 23 Sep 2017, Fredrik Sallinen wrote:


Please correct me If I'm wrong, AFAIK 464XLAT works best with mobile
networks and its not suitable for fixed broadband. right?


It's most widely deployed in mobile networks, yes. There is nothing that 
says it couldn't work anywhere else.


However, in fixed networks with PPPoE the most commonly used model is dual 
stack with RFC7084 style routers.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: IPv6 migration steps for mid-scale isp

[Fredrik Sallinen]

Please correct me If I'm wrong, AFAIK 464XLAT works best with mobile
networks and its not suitable for fixed broadband. right?

On Mon, Sep 18, 2017 at 10:28 PM, JORDI PALET MARTINEZ
 wrote:
> Fully agree, 464XLAT is the way to go.
>
> We have tested this in many IPv6-only access deployments, non-cellular 
> networks (cellular is well tested by T-Mobile and others, that have got it in 
> production for years).
>
> We always have the issue of the CPEs support, but this is the same problem if 
> you want to go to lw4o6, MAP, etc. In general, newer transition mechanisms, 
> aren’t well supported.
>
> So, you either use OpenWRT if you can re-flash the CPEs, or you push your 
> vendors to make sure they provide a firmware upgrade.
>
> This is the reason I started to work on an update of the RFC7084 
> (https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc7084-bis/ and 
> https://datatracker.ietf.org/doc/draft-palet-v6ops-rfc7084-bis-transition/) 
> and see also the related discussion in v6ops.
>
> Also, I run a panel with CPE vendors in the last week APNIC meeting, and the 
> interesting thing is that they confirmed there is no any technical issue to 
> support those (hardware is ok), and they have already developed it, just 
> waiting for customers to ask for it.
>
> https://conference.apnic.net/44/program/schedule/#/day/6/bof-discussion-with-ipv6-ce-vendors
>
> I will compile a report out of this panel ASAP.
>
> So please, keep pushing your vendors for it!
>
> Regards,
> Jordi
>
>
> -Mensaje original-
> De: NANOG  en nombre de Brock Tice 
> Responder a: 
> Fecha: viernes, 15 de septiembre de 2017, 17:14
> Para: Fredrik Sallinen 
> CC: 
> Asunto: Re: IPv6 migration steps for mid-scale isp
>
> 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
>
>
>
>
> **
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.consulintel.es
> The IPv6 Company
>
> This electronic message contains information which may be privileged or 
> confidential. The information is intended to be for the exclusive use of the 
> individual(s) named above and further non-explicilty authorized disclosure, 
> copying, distribution or use of the contents of this information, even if 
> partially, including attached files, is strictly prohibited and will be 
> considered a criminal offense. If you are not the intended recipient be aware 
> that any disclosure, copying, distribution or use of the contents of this 
> information, even if partially, including attached files, is strictly 
> prohibited, will be considered a criminal offense, so you must reply to the 
> original sender to inform about this communication and delete it.
>
>
>

Re: IPv6 migration steps for mid-scale isp

[Fredrik Sallinen]

CPE's are owned by our customers but we have control over ~60% of them
using TR069.



On Sun, Sep 17, 2017 at 9:43 PM, Max Tulyev  wrote:
> Hello,
>
> for my point of view, the start question is do you control CPEs (can
> re-configure and re-flash it), or users buy and own CPEs themself?
>
> On 13.09.17 15:08, Fredrik Sallinen wrote:
>> Hello,
>>
>> Recently we have decided to start IPv6 migration in our network. We
>> have ~1K BNGs and connecting our customers to network using PPPoE.
>> I'd be interested in hearing from the technical community about their
>> experiences and recommendations on this process. I'm wondering:
>>
>> Shall I go for IPv6-only deployment or dual stack?
>> Where to start with IPv6? (core, edge or ...)
>> What are the best practices for ISPs?
>> What are the costs and return on investment?
>> How to identify address CPE and legacy application issues?
>>
>> Fredrik
>>
>