RE: IPv6 uptake (was: The Reg does 240/4)

[Howard, Lee via NANOG]

Bottom-posted with old school formatting by hand.

-Original Message-
From: NANOG  On Behalf 
Of William Herrin
Sent: Friday, February 16, 2024 8:05 PM
To: Michael Thomas 
Cc: nanog@nanog.org
Subject: Re: IPv6 uptake (was: The Reg does 240/4)

> On the firewall, I program it to do NAT translation from
> 192.168.55.0/24 to 199.33.225.1 when sending packets outbound, which also has 
> the effect of disallowing 
> inbound packets to 192.168.55.0/24 which are not part of an established 
> connection.
> 
> Someone tries to telnet to 192.168.55.4. What happens? The packet never even 
> reaches my firewall because 
> that IP address doesn't go anywhere on the Internet.

Most NATs I've seen in the last 10-15 years are "full cone" NATs: they are 
configured so that once there is an 
outbound flow, and inbound datagram to that address+port will be forwarded to 
the inside address, regardless
of source.

Most devices now have a more or less constant flow of heartbeats or updates to 
somewhere on the Internet.
In practice, NAPT just increases the size of the space to scan: just dump your 
crafted packets to every address
+ every port at your target.

If that increased scanning target is your security, you're better off with the 
increased target of IPv6.

IT administrators don't usually know what kind of NAT they have deployed.

FWIW, the other enterprise IT security hole I often see: if your VPN is 
IPv6-unaware, but your users have IPv6
at home (like most in the U.S.), your VPN is now split-tunnel, regardless of 
policy. You may think all your
packets are going through the VPN to be inspected by the corporate firewall, 
but any web site with IPv6
(about half) will use the local residential route, not the VPN.

Lee

RE: IPv6 uptake (was: The Reg does 240/4)

[Howard, Lee via NANOG]

If you ever want to know which providers in a country are lagging, Geoff Huston 
is here to help:

https://stats.labs.apnic.net/ipv6/US

In the U.S., the largest operators without IPv6 are (in order by size):
Verizon FiOS (they deployed to 50%, discovered a bug, and rolled back)
Frontier
Lumen (CenturyLink)
CableVision
CableOne
Suddenlink
Windstream
US Cellular
Brightspeed

Comcast, Charter, and Cox each have fully deployed IPv6, along with AT and 
all of the mobile carriers.

Lee

-Original Message-
From: NANOG  On Behalf 
Of Michael Thomas
Sent: Sunday, February 18, 2024 3:29 PM
To: nanog@nanog.org
Subject: Re: IPv6 uptake (was: The Reg does 240/4)

[You don't often get email from m...@mtcc.com. Learn why this is important at 
https://aka.ms/LearnAboutSenderIdentification ]

This message is from an EXTERNAL SENDER - be CAUTIOUS, particularly with links 
and attachments.



On 2/18/24 8:47 AM, Greg Skinner via NANOG wrote:
> On Feb 17, 2024, at 11:27 AM, William Herrin  wrote:
>> On Sat, Feb 17, 2024 at 10:34?AM Michael Thomas  wrote:
>>
>>> Funny, I don't recall Bellovin and Cheswick's Firewall book 
>>> discussing NAT.
>> And mine too, since I hadn't heard of "Firewalls and Internet
>> Security: Repelling the Wily Hacker" and have not read it.
> For what it's worth, both editions of Bellovin and Cheswick's 
> Firewalls book are online. [1]  Also, there are discussions about NAT 
> and how it influenced IPng (eventually IPv6) on the big-internet list. 
> [2]

FWIW, while at Cisco I started to get wind of some NAT-like proposal being 
floated by 3COM at Packetcable back in the late 90's, early 2000's (sorry, I 
have no memory of the specifics now). That was pretty horrifying to me and 
others as the implication was that we'd have to implement it in our routers, 
which I'm sure 3COM viewed as a feature, not a bug. We pushed back that 
implementing IPv6 was a far better option if it came down to that. That sent me 
and Steve Deering off on an adventure to figure out how we might actually make 
good on that alternative in the various service provider BU's. Unsurprisingly 
the BU's were not very receptive not just because of the problems with v6 vs 
hardware forwarding, but mostly because providers weren't asking for it.
They weren't asking for CGNAT like things either though so it was mostly the 
status quo. IOS on the other hand was taking IPv6 much more seriously so that 
providers could at least deploy it in the small for testing, pilots, etc even 
if it was a patchwork in the various platforms.

The problem with v6 uptake has always been on the provider side. BU's wouldn't 
have wanted to respin silicon but if providers were asking for it and it gave 
them a competitive advantage, they'd have done it in a heartbeat. It's 
heartening to hear that a lot of big providers and orgs are using IPv6 
internally to simplify management along with LTE's use of v6. I don't know 
what's happening in MSO land these days, but it would be good to hear if they 
too are pushing a LTE-like solution. I do know that Cablelabs pretty early on 
-- around the time I mentioned above -- has been pushing for v6. Maybe Jason 
Livingood can clue us in. Getting cable operators onboard too would certainly 
be a good thing, though LTE doesn't have to deal with things like brain dead 
v4-only wireless routers on their network.

Mike

RE: The Reg does 240/4

[Howard, Lee via NANOG]

It seems we’re the marketplace of record.

We do have some private transactions, that is, sales that take place outside of 
our marketplace and therefore don’t appear on the prior-sales page. That’s 
generally for /16 or larger, where one or both parties want custom terms that 
differ from our standard Terms of Use.

It’s true that prices for /16 and larger have held steadier than smaller 
blocks. My guess is that there has been a lot more supply of smaller blocks 
than /16+, driving prices down for the smaller blocks. Supply for /16s and 
larger is fine, but not enormous. I don’t assume that prices will remain the 
same.

So, what about 240/4?  The IPv4 market moves about 40 million addresses per 
year. A /4 is 268 million addresses, so if that supply became available (IETF 
telling IANA to distribute it to the RIRs, I assume) it would definitely affect 
the market for a long time. The RIRs would have to look at their 
post-exhaustion policies and figure out whether they still applied, or if 
pre-exhaustion policies should be used. I don’t have a strong opinion on this, 
and give credit to the authors of the proposal for working to identify any 
places where 240/4 would not work.

I still think the Internet works better when everyone uses the same protocol, 
so everyone should deploy IPv6. At this point, the consumer electronics and 
corporate IT sectors are the major holdouts. There are still ISPs and web sites 
that don’t have IPv6, but it’s no longer reasonable to assert that those are 
failures as a group, IMHO.


Lee Howard | Senior Vice President, IPv4.Global
[Inline image]

t: 646.651.1950
email: leehow...@hilcostreambank.com<mailto:leehow...@hilcostreambank.com>
web: www.ipv4.global<http://www.ipv4.global/>
twitter: twitter.com/ipv4g<https://twitter.com/ipv4g/>





From: NANOG  On Behalf 
Of Mike Hammett
Sent: Friday, February 16, 2024 10:28 AM
To: Tom Beecher 
Cc: nanog@nanog.org
Subject: Re: The Reg does 240/4

This message is from an EXTERNAL SENDER - be CAUTIOUS, particularly with links 
and attachments.


Evidence to support Tom's statement:

https://auctions.ipv4.global/prior-sales


-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com


From: "Tom Beecher" mailto:beec...@beecher.cc>>
To: "Brian Knight" mailto:m...@knight-networks.com>>
Cc: nanog@nanog.org<mailto:nanog@nanog.org>
Sent: Thursday, February 15, 2024 5:31:42 PM
Subject: Re: The Reg does 240/4
$/IPv4 address peaked in 2021, and has been declining since.

On Thu, Feb 15, 2024 at 16:05 Brian Knight via NANOG 
mailto:nanog@nanog.org>> wrote:
On 2024-02-15 13:10, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote:
> I've said it before, and I'll say it again:
>
>   The only thing stopping global IPv6 deployment is
>   Netflix continuing to offer services over IPv4.
>
> If Netflix dropped IPv4, you would see IPv6 available *everywhere*
> within a month.

As others have noted, and to paraphrase a long-ago quote from this
mailing list, I'm sure all of Netflix's competitors hope Netflix does
that.

I remain hopeful that the climbing price of unique, available IPv4
addresses eventually forces migration to v6. From my armchair, only
through economics will this situation will be resolved.

> --lyndon

-Brian

RE: NANOG 90 Attendance?

[Howard, Lee via NANOG]

From: Tom Beecher 
Sent: Thursday, February 15, 2024 10:53 AM
To: Howard, Lee 
Cc: Warren Kumari ; nanog 
Subject: Re: NANOG 90 Attendance?

This message is from an EXTERNAL SENDER - be CAUTIOUS, particularly with links 
and attachments.



Maybe this should have gone to the members mailing list, but I couldn’t find 
one.


memb...@nanog.org<mailto:memb...@nanog.org>


Thank you, Tom. I was unable to find that piece of information to find by:

  *   Searching “Member list” on the NANOG web page
  *   Browsing the options under “Members” on the site
  *   Reading the list of mailing lists at 
https://nanog.org/nanog-mailing-list/nanog-mailing-lists/
  *   Googling “NANOG members mailing list”

Lee

RE: NANOG 90 Attendance?

[Howard, Lee via NANOG]

I'm jumping on an earlier part of the thread.

Based on what I heard at the Members Meeting and several follow up hallway 
conversations, I think:

  *   NANOG needs a focus group on attendees. A survey won't do it, we need a 
deep dive into roles, interests, career level, and why they attend.
  *   Somebody or somebodies should be specifically tasked with following up 
with every one of the 120 newcomer attendees to ask what it would take to get 
them to come back. Our conversion rate to repeat attendee is a key performance 
indicator. There's a great Newcomer Orientation just before conference opening; 
let's have a Newcomer Lessons Learned at the end.
  *   Poll attendees on relative importance of location, registration fee, 
programming, side meeting space. Iterate based on comments (location = airport? 
Hotel? Nearby amenities? Proximity to home?)
  *   Survey sponsors. I give feedback to staff and occasional board members, 
but there's no clear way to gather information.
  *   These should be sent to the Members in advance of a Members Meeting to 
discuss. Needs more than 20 minutes of a 45 minute meeting before main 
programming.
  *   Consider empaneling a Mission Committee to review NANOG's mission and how 
to fulfill it.

Other thoughts, which I couldn't submit in a survey or find another way to send 
to the board or staff:

  *   I suggested in San Diego and now bring to the list: the last item on the 
agenda should be 15-30 minutes of "What are you taking home from this NANOG?"
 *   Helps remind people what value they got
 *   Lets us know what people found most valuable (Specific sessions? deals 
done? Trends in hallway topics?)
 *   Solidifies for people what they can offer their boss as the value of 
sending them to NANOG
  *   We should look into cooperating with other network organizations for 
meetings. WISPAmerica, NRECA, NTCA, Fiber Connect, SCTE, IETF
  *   ARIN has a help desk in the main hall. Allow other sponsors to put up a 
Help Desk. Put up a sign showing which company will be there for which half-day 
increment. I think a lot of attendees would find value in the ability to sit 
down with a senior sales engineer at their favorite router, optical, or 
intelligence vendor to say, "Here's my problem," even if many of those 
conversations resulted in "Let's schedule time to discuss in more depth."
 *   Price it like BnG-you're getting ½ day of visibility, less distraction 
than meal/break sponsors
 *   Require swag to be incidentals like pens and stickers-if you're 
getting a mad rush of people, you're missing the point


This can't all be done in time for Kansas City, but maybe some of it can be. 
Given that hotel contracts are negotiated two years in advance, I figure we 
have about two years to get this right before it's too late to steer the ship 
away from the rocks.

Let me close with: I think we have an excellent board, all of whom love this 
community and have spent years thinking about this. The lack of a CEO is a 
problem soon to be resolved, and that will help support the already excellent 
staff. There are themes we've been hearing for several meetings in a row, and I 
know the board is giving them a lot of thought, and I'm just trying to support 
those efforts from outside the board.

Maybe this should have gone to the members mailing list, but I couldn't find 
one.

Lee


From: NANOG  On Behalf 
Of Warren Kumari
Sent: Sunday, February 11, 2024 2:50 PM
To: Mike Hammett 
Cc: nanog 
Subject: Re: NANOG 90 Attendance?

You don't often get email from war...@kumari.net<mailto:war...@kumari.net>. 
Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
This message is from an EXTERNAL SENDER - be CAUTIOUS, particularly with links 
and attachments.






On Sun, Feb 11, 2024 at 8:31 AM, Mike Hammett 
mailto:na...@ics-il.net>> wrote:
I haven't been to a NANOG meeting in a while. While going through the attendee 
list for NANOG 90 to try to book meetings with people, I noticed a lack of (or 
extremely minimal) attendance by several organizations that have traditionally 
had several employees attend. I've also noticed that some organizations I had 
an interest in were only sending sales people, not technical people.


There have been a few changes - part of this is driven by post-pandemic 
decreased travel budget in many organizations, part by industry changes and 
consolidation, but also a fair bit seems to be because the tone of NANOG has 
changed and become much more of a polished, sales-y feeling event than it used 
to be

Here is the current NANOG agenda:
https://www.nanog.org/events/nanog-90/agenda/

Here is the agenda from 20 years ago:
https://www.nanog.org/events/nanog-30/nanog-30-agenda-2/

This time I've received at least 6 phone calls along this line of "Hi, I'm 
[person] from [company]. We are a NANOG sponsor and we'd like to personally 
invite you to a very special [bre

RE: what is acceptible jitter for voip and videoconferencing?

[Howard, Lee]

I think it all goes back to the earliest MOS tests ("Hold up the number of 
fingers for how good the sound is") and every once in a while somebody actually 
does some testing to look for correlations.

Thought it's 15 years old, I like this thesis for the writer's reporting: 
https://scholarworks.gsu.edu/cgi/viewcontent.cgi?article=1043=cs_theses

In particular, this table shows the correlation, and is consistent with what I 
would expect.
[cid:image001.png@01D9EBA9.A25944E0]

Lee


From: NANOG  On Behalf 
Of Dave Taht
Sent: Tuesday, September 19, 2023 8:12 PM
To: NANOG 
Subject: what is acceptible jitter for voip and videoconferencing?

This message is from an EXTERNAL SENDER - be CAUTIOUS, particularly with links 
and attachments.


Dear nanog-ers:

I go back many, many years as to baseline numbers for managing voip networks, 
including things like CISCO LLQ, diffserv, fqm prioritizing vlans, and running
voip networks entirely separately... I worked on codecs, such as oslec, and 
early sip stacks, but that was over 20 years ago.

The thing is, I have been unable to find much research (as yet) as to why my 
number exists. Over here I am taking a poll as to what number is most correct 
(10ms, 30ms, 100ms, 200ms),

https://www.linkedin.com/feed/update/urn:li:ugcPost:7110029608753713152/

but I am even more interested in finding cites to support various viewpoints, 
including mine, and learning how slas are met to deliver it.

--
Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
Dave Täht CSO, LibreQos

Re: Caribnog email list

[Stephen Lee]

Thanks Biil, David. This has been sorted.

Best,
Stephen

On Sat, 4 Feb 2023 at 13:30, Bill Woodcock  wrote:
>
> Forwarded to the maintainers.
>
> -Bill
>
>
>
> > On Feb 4, 2023, at 6:44 PM, David Bass  wrote:
> >
> > Anyone on here run it?  The URL to sign up on the website doesn’t seem to 
> > work at the moment.
>
>

Re: is ipv6 fast, was silly Redeploying

[John Lee]

Cisco and Juniper routers have had v6 functionality for over 10 years.
Lucent/Nokia, and others. Check UNL list at
https://www.iol.unh.edu/registry/usgv6 for v6 compliant routers and
switches.

John Lee

On Fri, Nov 19, 2021 at 5:48 PM John Levine  wrote:

> It appears that Michael Thomas  said:
> >And just as impossible since it would pop it out of the fast path. Does
> >big iron support ipv6 these days?
>
> My research associate Ms. Google advises me that Juniper does:
>
>
> https://www.juniper.net/documentation/us/en/software/junos/routing-overview/topics/concept/ipv6-technology-overview.html
>
> As does Cisco:
>
>
> https://www.cisco.com/c/en/us/products/collateral/switches/catalyst-9600-series-switches/nb-06-cat9600-ser-sup-eng-data-sheet-cte-en.pdf
>
> R's,
> John
>

Questions about IRR best practices

[Lee Fawkes]

 Good morning Operators;

I have a couple of questions about best practices for Internet Routing
Registries. I'm able to find lots of documentation about *how* to do
things, but not a lot of documentation about when I *should* do things. I
work for a medium-sized ISP in the US, and we are currently using both RADb
and the ARIN IRR. We peer all over the place, but my main concern is how
Cogent and Hurricane Electric build prefix filters from our IRRs.

1. Netflix is asking us to add the AS of a downstream customer of one of
our customers to our customer AS-SET. We have a direct relationship with
this organization's provider, but not with this organization itself. Is
this appropriate?

2. On the ARIN side, when ARIN-NONAUTH goes away next year, does that do
away with our ability to do proxy route objects? Do we need to require all
of our BGP customers to set up their own IRRs?

3. On the RADb side, if we're turning up a new customer that doesn't have
an IRR, and another ISP already has a proxy registration for that customer,
is it sufficient for us to add that customer's AS to our customer AS-SET?

I've been getting around the fact that RADb doesn't allow multiple proxy
registrations by registering proxy route objects in ARIN-NONAUTH, but that
won't be an option much longer, and I can't really experiment with our
customers' route objects to see what works.

Thanks!
-Lee Fawkes

Re: facebook outage

[John Lee]

I was seeing NXDOMAIN errors, so I wonder if they had a DNS outage of some
sort??

On Mon, Oct 4, 2021 at 5:14 PM Bill Woodcock  wrote:

> They’re starting to pick themselves back up off the floor in the last two
> or three minutes.  A few answers getting out.  I imagine it’ll take a while
> before things stabilize, though.
>
> -Bill
>
>

Re: Google IP Geolocation

[MunFai Lee]

We're also having similar issues - Google is detecting our Singapore IP range 
as coming from HK, and our HK Ip range as coming from Vietnam

Just applied for access to Google's ISP portal - let's see what happens.

If anyone else have any more ideas how to get Google to fix this, please do 
share - my users are getting fed up!


From: NANOG  on behalf of Benjamin 
Hatton 
Sent: Tuesday, March 30, 2021 9:47 PM
Cc: NANOG Mailing List 
Subject: Re: Google IP Geolocation

Just as another viewpoint on this.

We do not peer or have GGC Cache servers, but I put in a request for a portal 
account after seeing this thread, and it was approved in less than 24h, so YMMV.

The only thing I can think of that is different, is that we do move enough 
traffic for Google to have us flagged as 'Your traffic levels qualify for 
Google Peering' (~2.5Gbps) and are an eyeball network.

Ben Hatton

Network Engineer | Haefele Connect
d:(607)589-8000 | b...@haefeleconnect.com

[https://drive.google.com/a/haefeletv.com/uc?id=1elvqOtC6cqyJTls2CwD9UAQt9tMCT8Bf=download]


On Tue, Mar 30, 2021 at 9:15 AM Troy Kelly via NANOG 
mailto:nanog@nanog.org>> wrote:
We've also been denied access to the ISP portal.

When we replied as to why, we were told to not open another ticket. They aren't 
interested in conversation.


Sent from ProtonMail mobile



 Original Message 
On 30 Mar 2021, 6:53 am, Mike Hammett < 
na...@ics-il.net> wrote:

I've had others at Google specifically say that portal should be used for that 
purpose, so maybe they need to make sure right and left hands know what the 
other is doing.



-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com


From: "Josh Luthman" 
mailto:j...@imaginenetworksllc.com>>
To: "Christopher Morrow" 
mailto:morrowc.li...@gmail.com>>
Cc: nanog@nanog.org
Sent: Monday, March 29, 2021 1:52:48 PM
Subject: Re: Google IP Geolocation

https://isp.google.com

I signed up for an account there and they said:

"Currently, the Google ISP portal is designed for our partners of GGC, PNI or 
IX programs.

The access to portal is granted on request only to our partners."

Josh Luthman
24/7 Help Desk: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373


On Mon, Mar 29, 2021 at 2:08 PM Christopher Morrow 
mailto:morrowc.li...@gmail.com>> wrote:


On Mon, Mar 29, 2021 at 1:59 PM Josh Luthman 
mailto:j...@imaginenetworksllc.com>> wrote:
Google ISP specifically told me they didn't want to do deal with geolocation on 
the ISP portal.


unsure who 'google isp' is here, but ... I think if you point at a properly 
formed geo-location data file it'll get eaten and produce proper results for 
you.
you do have to add that in your isp portal:
   tri-pipe-thingy -> configuration -> IP geolocation
and /register feed/ button on that page.

Josh Luthman
24/7 Help Desk: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373


On Sat, Mar 27, 2021 at 3:28 PM Christopher Morrow 
mailto:morrowc.li...@gmail.com>> wrote:
As a note, on the ISP portal there's a place to put a link to your RFC8805 
format geolocation feed...
these are scraped out 'regularly' and help keep things oriented better for 
folks.

the ietf noc folk use this method to tell google (and other folk who scrape out 
our data) where meetings are before the meetings get there:
  https://noc.ietf.org/geo/google.csv

-chris
volunteer noc persona

On Fri, Mar 26, 2021 at 6:43 PM Michael K. Spears 
mailto:mich...@spears.io>> wrote:

Awesome, I think I’ve figured out the Google ISP portal signup, but it 
definitely seems semi-complicated in a way, notably finding the link…



Thank you,

Michael K. Spears

727.656.3347



From: Mike Hammett mailto:na...@ics-il.net>>
Sent: Friday, March 26, 2021 6:30 PM
To: Michael K. Spears mailto:mich...@spears.io>>
Cc: nanog@nanog.org
Subject: Re: Google IP Geolocation



We're working on a video to show people how to sign up for the ISP portal and 
get to that part of the portal once signed up. We'll drop a link to it near the 
Google section of our geolocation page.


-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com





From: "Michael K. Spears" mailto:mich...@spears.io>>
To: nanog@nanog.org
Sent: Friday, March 26, 2021 5:10:23 PM
Subject: Google IP Geolocation

Anyone have a good contact at Google who can help with IP geolocation? I have a 
/24 where anything related to Google is in the wrong language.



Thank you,

Michael K. Spears

Re: Google Fiber abuse address does not exist

[Louie Lee via NANOG]

Hey Chris,

Thanks for reporting this. We had an issue that caused emails to addresses
in that domain to not be recognized.

The email is no longer bouncing back, and emails to other googlefiber.net
addresses are confirmed working.

Louie


On Thu, Feb 18, 2021 at 1:58 PM Chris Boyd  wrote:

> Can someone at ARIN tell them they need to fix this?
>
> From whois 136.32.164.64:
> OrgAbuseHandle: GFA32-ARIN
> OrgAbuseName:   Google Fiber Abuse
> OrgAbusePhone:  +1-650-253- <(650)%20253->
> OrgAbuseEmail:  ab...@googlefiber.net
> OrgAbuseRef:https://rdap.arin.net/registry/entity/GFA32-ARIN
>
> Email response:
>   - The following addresses had permanent fatal errors -
> 
>(reason: 550-5.1.1 The email account that you tried to reach does not
> exist. Please try)
>
>   - Transcript of session follows -
> ... while talking to gmr-smtp-in.l.google.com.:
> >>> DATA
> <<< 550-5.1.1 The email account that you tried to reach does not exist.
> Please try
> <<< 550-5.1.1 double-checking the recipient's email address for typos or
> <<< 550-5.1.1 unnecessary spaces. Learn more at
> <<< 550 5.1.1  https://support.google.com/mail/?p=NoSuchUser
> kk5si203161pjb.1 - gsmtp
> 550 5.1.1 ... User unknown
> <<< 503 5.5.1 RCPT first. kk5si203161pjb.1 - gsmtp
> Reporting-MTA: dns; lenny.gizmopartners.com
> Received-From-MTA: DNS; 136-49-160-191.googlefiber.net
> Arrival-Date: Thu, 18 Feb 2021 21:52:38 GMT
>
> Final-Recipient: RFC822; ab...@googlefiber.net
> Action: failed
> Status: 5.1.1
> Remote-MTA: DNS; gmr-smtp-in.l.google.com
> Diagnostic-Code: SMTP; 550-5.1.1 The email account that you tried to reach
> does not exist. Please try
> Last-Attempt-Date: Thu, 18 Feb 2021 21:52:39 GMT
>
>

Re: DoD IP Space

[John Lee]

It is the DISA DOD NIC at:

https://disa.mil/About/Contact

Which will give you the DISA help desk phone number.

John Lee

On Mon, Nov 4, 2019 at 3:57 AM Chris Knipe  wrote:

> Hi Guys,
>
> Except for the email on ARIN's details, does anyone else have a contact
> for the DoD?
>
> We are experiencing a situation with a 3rd party (direct peer), wanting to
> advertise DoD address space to us, and we need to confirm whether they are
> allowed to do so or not.
>
> Range in question is the 22.0.0.0/8 network, which according to ARIN is
> actively assigned to the DoD (US).
>
> --
>
> Regards,
> Chris Knipe
>

Re: Parler

[Lee]

On 1/12/21, Kevin McCormick  wrote:
> Imagine if Tier 1 ISPs had a censorship free clause that required companies
> like Twitter, Facebook, and Amazon to provide services free of censorship or
> have IP blocks blackholed. They would lose hundreds of millions of dollars
> per day. I bet they would reverse their tone in a hurry.
>
> https://www.seattletimes.com/seattle-news/idaho-internet-provider-to-block-facebook-twitter-over-their-trump-bans/

Clickbait title.
  "The company said Monday it decided to block Facebook and Twitter
for customers who request that starting next Wednesday after the
company received several calls from customers about both websites."

The way I read it, they aren't blocking Facebook/Twitter for everyone
- the customer has to request the filter for their service.

Regards,
Lee

>
> Thank you,
>
> Kevin McCormick
>
> From: NANOG  On Behalf Of mark
> seery
> Sent: Sunday, January 10, 2021 8:06 PM
> To: K. Scott Helms 
> Cc: NANOG Operators' Group 
> Subject: Re: Parler
>
> I assume multiple networks/ ISPs that have acceptable use policies that call
> out criminality and incitement to violence, for example:
>
> https://www.xfinity.com/support/articles/comcast-acceptable-use-policy
>
> Have these AUPs been invoked previously for these reasons, or would that be
> new territory?
> Sent from Mobile Device
>
>
> On Jan 10, 2021, at 2:52 PM, K. Scott Helms
> mailto:kscott.he...@gmail.com>> wrote:
> 
> Right, it's not a list for content hosting.
>
> Scott Helms
>
> On Sun, Jan 10, 2021, 5:42 PM
> mailto:sro...@ronan-online.com>> wrote:
> No, this is a list for Network Operators.
> Sent from my iPhone
>
>
> On Jan 10, 2021, at 5:32 PM, K. Scott Helms
> mailto:kscott.he...@gmail.com>> wrote:
> 
> This is a list for pushing bits.  The fact that many/most of us have other
> businesses doesn't make this an appropriate forum for SIP issues (to use my
> own work as an example).
>
> On Sun, Jan 10, 2021, 4:52 PM
> mailto:sro...@ronan-online.com>> wrote:
> This is a list for Network Operators, AWS certainly operates networks.
> Sent from my iPhone
>
>
> On Jan 10, 2021, at 4:27 PM, K. Scott Helms
> mailto:kscott.he...@gmail.com>> wrote:
> 
> No,
>
> It really does not.  Section 230 only applies to publishers, and not to
> network providers.  If this were a cloud hosting provider list then you'd be
> correct, but as a network provider's list it does not belong here.
>
>
> Scott Helms
>
>
> On Sun, Jan 10, 2021 at 3:21 PM Lady Benjamin PD Cannon
> mailto:b...@6by7.net>> wrote:
> As network operations and compute/cloud/hosting operations continue to
> coalesce, I very much disagree with you.  Section 230 is absolutely
> relevant, this discussion is timely and relevant, and it directly affects me
> as both a telecom and cloud compute/services provider.
>
>
> —L.B.
>
> Lady Benjamin PD Cannon, ASCE
> 6x7 Networks & 6x7 Telecom, LLC
> CEO
> b...@6by7.net<mailto:b...@6by7.net>
> "The only fully end-to-end encrypted global telecommunications company in
> the world.”
> FCC License KJ6FJJ
>
>
> 
> 
>
>
> On Jan 10, 2021, at 12:13 PM, K. Scott Helms
> mailto:kscott.he...@gmail.com>> wrote:
>
> It's not, and frankly it's disappointing to see people pushing an agenda
> here.
>
>
> Scott Helms
>
>
> On Sun, Jan 10, 2021 at 9:37 AM
> mailto:sro...@ronan-online.com>> wrote:
>
>
> NANOG is a group of Operators, discussion does not have to be about
> networking. I have already explained how this represents a significant issue
> for Network Operators.
>
> On Jan 10, 2021, at 9:09 AM, Mike Bolitho
> mailto:mikeboli...@gmail.com>> wrote:
>
> 
> It has nothing to do with networking. Their decision was necessarily
> political. If you can specifically bring up an issue, beyond speculative, on
> how their new chosen CDN is somehow now causing congestion or routing issues
> on the public internet, then great. But as of now, that isn't even a thing.
> It's just best to leave it alone because it will devolve into chaos.
>
> - Mike Bolitho
>
> On Sun, Jan 10, 2021, 6:54 AM
> mailto:sro...@ronan-online.com>> wrote:
>
>
> Why? This is extremely relevant to network operators and is not political at
> all.
>
> On Jan 10, 2021, at 8:51 AM, Mike Bolitho
> mailto:mikeboli...@gmail.com>> wrote:
>
> 
> Can we please not go down this rabbit hole on here? List admins?
>
> - Mike Bolitho
>
> On Sun, Jan 10, 2021, 1:26 AM William Herrin
> mailto:b...@herrin.us>> wrote:
>
>
> Anybody looking for a new customer opportunity? It seems Parler is in
> search of a new service provider. Vendors need only provide all the
> proprietary AWS APIs that Parler depends upon to function.
>
> https://www.washingtonpost.com/technology/2021/01/09/amazon-parler-suspension/
>
> Regards,
> Bill HErrin
>
>

Re: Bottlenecks and link upgrades

[Louie Lee via NANOG]

Beyond a pure percentage, you might want to account for the time it takes
you stay below a certain threshold. If you want to target a certain link to
keep your 95th percentile peaks below 70%, then first get an understanding
of your traffic growth and try to project when you will reach that number.
You have to decide whether you care about the occasional peak, or the
consistent peak, or somewhere in between, like weekday vs weekends, etc.
Now you know how much lead time you will have.

Then consider how long it will take you to upgrade that link. If it's a
matter of adding a couple of crossconnects, then you might just need a
week. If you have to ship and install optics, modules, a card, then add
another week. If you have to get a sales order signed by senior management,
add another week. If you have to put it through legal and finance, add a
month. (kidding) If you are doing your annual re-negotiation, well...good
luck.

It's always good to ask your circuit vendors what the lead times are, then
double it and add 5.

And sometimes, if you need a low latency connection, traffic utilization
levels might not even be something you look at.

Louie
Peering Coordinator at a start-up ISP


On Fri, Aug 14, 2020 at 4:13 PM Radu-Adrian Feurdean <
na...@radu-adrian.feurdean.net> wrote:

> On Wed, Aug 12, 2020, at 09:31, Hank Nussbacher wrote:
> > At what point do commercial ISPs upgrade links in their backbone as
> > well as peering and transit links that are congested?  At 80% capacity?
> >  90%?  95%?
>
> Some reflections about link capacity:
> At 90% and over, you should panic.
> Between 80% and 90% you should be (very) scared.
> Between 70% and 80% you should be worried.
> Between 60% and 70% you should  seriously consider speeding up the
> upgrades that you effectively started at 50%, and started planning since
> 40%.
>
> Of course, that differs from one ISP to another. Some only upgrade after
> several months with at least 4 hours a day, every day (or almost) at over
> 95%. Others deploy 10x expected capacity, and upgrade well before 40%.
>

Re: Has virtualization become obsolete in 5G?

[John Lee]

The short answer is that the "Cloud Native Computing" folks need to talk to
the Intel Embedded Systems Application engineers to discover that micro
services have been running on Intel hardware in (non-standard) containers
for years. We call it real time computing, process control,... Current
multi Terabit Ethernet interfaces require specialized hardware and
interfaces that will connect fiber optics to clouds but cannot be run on
clouds.

Some comments on Software Controlled Telecomm (/datacom) networking. When
DTMF was invented the telco used in band signaling for call control. Kevin
Mitnick et. al. designed red and black boxes to control the telco systems
so the telcos moved call control out of band. They created SIgnal Control
Points which managed the actual circuit switch hardware to route calls or
eventually 64kbps digital paths and this protocol was SS#7. There were six
to seven volumes of CLASS services that were enabled by SS#7 which ran on
UNIX systems developed by Bell Labs. In the mid seventies, I worked on VM
systems from DEC and Apollo of which Apollo had the better virtualization
that worked across the network and was the first "cloud" system that I
worked on.

In the mid nineties, I had worked on large Gigabit/Terabit routers but
again the control plane was part of the data plane until ATM based
networks  could use out of band control to setup a SVC between input port
and output port and switch the IP packets instead of routing them achieving
network end to end delays of less than milliseconds. VLAN and MPLS
protocols were developed to switch packets in the backbone of the networks
and not to route them.

In 2000 we put our first pre-standard cloud together with multi Gigabit
routers and Sun workstations at 45 PoPs in the US, 3 in Asia and 6 in
Europe and implemented a "cloud" O/S. Our fastest links were 10 Gbps. Now
we can have 2-50 Tbps per fiber using Superchannel DWDM technology between
PoP, data centers or cell towers. Network control functions can dynamically
change by using Dynamic Reprogrammable EPROMs from companies like Xilinx
and Intel to repurpose firmware control and device functions.

Embedded systems have implemented "micro services" for years as that is how
you handle interrupt driven real time control. We call this a context
switch which is still hardware CPU dependent. As far as I know, current
standard containers do not handle real time CPU interrupts or do they allow
very tight timing reponse loops within the standard containers?

Certain 5G proposals are discussing network slicing et al to virtualize
control functions that can work better without virtualization. Current 5G
protocol submissions that I have reviewed are way too complex to work out
in the real world on real networks, maintained by union labor. (This is not
a dig at union labor, as they are some of the best trained techs.) :)

On Sat, Aug 1, 2020 at 8:35 AM Mark Tinka  wrote:

>
>
> On 1/Aug/20 11:23, Etienne-Victor Depasquale wrote:
>
> Over the past few weeks, I've attended webinars and watched videos
> organized by Intel.
> These activities have centred on 5G and examined applications (like
> "visual cloud" and "gaming"),
> as well as segment-oriented aspects (like edge networks, 5G RAN and 5G
> Core).
>
> I am stunned (no hyperbole) by the emphasis on Kubernetes in particular,
> and cloud-native computing in general.
> Equally stunning (for me), public telecommunications networks have been
> portrayed
> as having a history that moved from integrated software and hardware,
> to virtualization and now to cloud-native computing.
> See, for example Alex Quach, here
> 
>  @10:30).
> I reason that Intel's implication is that virtualization is becoming
> obsolete.
>
> Would anyone care to let me know his thoughts on this prediction?
>
>
> In the early dawn of SDN, where it was cool to have the RP's in Beirut and
> the line cards in Lagos, the industry quickly realized that was not
> entirely feasible.
>
> If you are looking at over-the-top services, so-called cloud-native
> computing makes sense in order to deliver that value accordingly, and with
> agility. But as it pertains to actual network transport, I'm not yet sure
> the industry is at the stage where we are confident enough to decompose
> packet forwarding through a cloud.
>
> Network operators are more likely to keep using kit that integrates
> forwarding hardware as well as a NOS, as no amount of cloud architecting is
> going to rival a 100Gbps purpose-built port, for example.
>
> Suffice it to say, there was a time when folk were considering running
> their critical infrastructure (such as your route reflectors) in AWS or
> similar. I'm not quite sure public clouds are at that level of confidence
> yet. So if some kind of cloud-native infrastructure is to be considered for
> critical infrastructure, I highly suspect it will be 

Re: dot-org TLD sale halted by ICANN

[Lee]

On 5/1/20, Bill Woodcock  wrote:
>
>
>> On May 1, 2020, at 6:19 AM, Andy Ringsmuth  wrote:
>> https://www.theregister.co.uk/2020/05/01/icann_stops_dot_org_sale/
>> I know this has been bantered about on the list in the past. Great (IMHO)
>> to see this happen.
>
> Yeah, this is an excellent result in the first-half of the fight. Now that
> we know who won’t be acting AGAINST non-profits, we need ICANN to run the
> competitive process again to find who will act FOR non-profits.

Wasn't the price cap removal what started this mess in for first place?

Put the price cap back on for .org domains and then start the process
for finding a new home for .org

Regards,
Lee

Re: Practical guide to predicting latency effects?

[Lee]

On 4/7/20, Adam Thompson  wrote:
> I’m looking for a practical guide – i.e. specifically NOT an academic paper,
> thanks anyway – to predicting the effect of increased (or decreased) latency
> on my user’s applications.
>
> Specifically, I want to estimate how much improvement there will be in
> {bandwidth, application XYZ responsiveness, protocol ABC goodput, whatever}
> if I decrease the RTT between the user and the server by 10msec, or by
> 20msec, or by 40msec.
>
> My googling has come up with lots of research articles discussing
> theoretical frameworks for figuring this out, but nothing concrete in terms
> of a calculator or even a rule-of-thumb.

There used to be network simulators that claimed to figure that out for you - eg
https://opnetmodeler.wordpress.com/
  "Predict application performance using real traffic in a simulated mode"

I suspect all that died after encryption became the norm, since you
have to be able to see and understand what's going on before you can
predict what will happen after changing the network.  Take a look at
https://www.cse.wustl.edu/~jain/cse567-08/ftp/simtools/index.html
  the date is 2008 and all the references are http://xxx  (or maybe I
can't search worth beans & missed all the current references)

Or maybe simulation just got too expensive?  I vaguely recall sitting
through a few OPNET sales pitches in the early 2000s & people getting
excited about the product until they found out how much it cost :(

Regards,
Lee


>
> Ultimately, this goes into MY calculator – we have the usual north-american
> duopoly on last-mile consumer internet here; I’m connected directly to only
> one of the two.  There’s a cost $X to improve connectivity so I’m peered
> with both, how do I tell if it will be worthwhile?
>
> Anyone got anything at all that might help me?
>
> Thanks in advance,
> -Adam
>
> Adam Thompson
> Consultant, Infrastructure Services
> [[MERLIN LOGO]]<https://www.merlin.mb.ca/>
> 100 - 135 Innovation Drive
> Winnipeg, MB, R3T 6A8
> (204) 977-6824 or 1-800-430-6404 (MB only)
> athomp...@merlin.mb.ca<mailto:athomp...@merlin.mb.ca>
> www.merlin.mb.ca<http://www.merlin.mb.ca/>
>
>

Re: Google Fiber (KC) NOC contact

[Louie Lee via NANOG]

Hey Blake,

Thanks for reaching out. I’m the IP Address Manager. Since this is more a
matter of the CPE or local gateway router configuration, I’ve referred the
matter to our Operation team to follow up on.

FYI, our frontline call center does escalate matters rather promptly after
a report is taken. They have very clear guidelines to escalate everything
that they cannot correct on their own.

Louie

P.S. Yes, I know I CC'ed the NANOG list. I trust y'all not to abuse things.

-- 

Louie Lee, 李景雲

Peering Coordinator (AS16591 <https://as16591.peeringdb.com/>)

Network Capacity Manager

IP Numbers Administrator

Google Fiber

lou...@google.com

(650) 253-2847

*There are 10 types of people in the world: Those who understand binary,
and those who don't.*


On Wed, Mar 18, 2020 at 7:51 AM Blake Hudson  wrote:

> Does someone from Google Fiber hang out on this list? I've contacted
> arin-cont...@google.com (the WHOIS tech and admin contact), but not
> gotten any response and I suspect contacting a frontline callcenter
> would be fruitless. It appears that some portion of customers in KC are
> being provided with a lame/broken NTP server address and it's causing
> some VPN/Telephony problems for those affected. If someone has a better
> POC please let me know so we can get this cleared up for us and other
> businesses in the KC area.
>
> --Blake
>

Re: Short-circuited traceroutes on FIOS

[Lee]

On 12/10/19, Christopher Morrow  wrote:
> On Tue, Dec 10, 2019 at 5:36 PM Nimrod Levy  wrote:
>>
>> Is that unique to the FiOS gateway device? I don't use their router and my
>> traces go right out.
>>
>
> I also don't use their device  and:
> $ traceroute 205.132.109.90
> traceroute to 205.132.109.90 (205.132.109.90), 30 hops max, 60 byte packets
>  1  _gateway (192.168.100.1)  3.085 ms  2.990 ms  2.795 ms
> 
> 15  * 12.250.138.90 (12.250.138.90)  65.970 ms *^C
>
> -chris
> (perhaps this is location specific? I'm in the ashburn-ish-area-ish)

It's protocol specific.  Windows tracert uses icmp instead of udp.
On a linux box try
  ping -t 2 205.132.109.90

You should get a time to live exceeded but the Verizon router gives
you an echo reply instead.

Regards,
Lee


>> On Tue, Dec 10, 2019 at 3:08 PM Joe Maimon  wrote:
>>>
>>> Apparently Verizon FIOS is a red herring, terminating ICMP traceroutes
>>> right on their gateways.
>>>
>>> More internet breakage. Thanks for the information to all who responded.
>>>
>>> Random control test.
>>>
>>> C:\Users\Home>tracert -d 1.4.5.6
>>>
>>> Tracing route to 1.4.5.6 over a maximum of 30 hops
>>>
>>>115 ms 5 ms<1 ms  172.18.24.1
>>>2 3 ms23 ms24 ms  192.168.2.33
>>>3 3 ms 6 ms 3 ms  1.4.5.6
>>>
>>> Trace complete.
>>>
>>>
>>> Joe
>>>
>>> Joe Maimon wrote:
>>> > Anyone have an idea why there are some destinations that on
>>> > residential verizon fios here in NY area terminate right on first
>>> > external hop?
>>> >
>>> > There seems to be a CDN common denominator here. On other networks
>>> > with more typical BGP paths and traceroutes, users are reporting
>>> > issues accessing these sites.
>>> >
>>> > C:\Users\Home>tracert www.usfoods.com
>>> >
>>> > Tracing route to statics.usfoods.com [205.132.109.90]
>>> > over a maximum of 30 hops:
>>> >
>>> >   1 3 ms<1 ms<1 ms  172.18.24.1
>>> >   2 4 ms 3 ms 3 ms  192.168.2.33
>>> >   317 ms 6 ms 3 ms  statics.usfoods.com [205.132.109.90]
>>> >
>>> > Trace complete.
>>> >
>>> > C:\Users\Home>tracert atworkhp.americanexpress.com
>>> >
>>> > Tracing route to atworkhp.americanexpress.com.akadns.net
>>> > [139.71.19.87]
>>> > over a maximum of 30 hops:
>>> >
>>> >   1 2 ms<1 ms<1 ms  172.18.24.1
>>> >   2 3 ms 4 ms23 ms  192.168.2.33
>>> >   321 ms11 ms 5 ms atworkhomepage2.americanexpress.com
>>> > [139.71.19.87]
>>> >
>>> > Trace complete.
>>> >
>>> > C:\Users\Home>tracert portal.discover.com
>>> >
>>> > Tracing route to e14577.x.akamaiedge.net [23.51.172.254]
>>> > over a maximum of 30 hops:
>>> >
>>> >   1 3 ms 1 ms18 ms  172.18.24.1
>>> >   221 ms 7 ms 6 ms  192.168.2.33
>>> >   3 4 ms 2 ms 2 ms
>>> > a23-51-172-254.deploy.static.akamaitechnologies.com [23.51.172.254]
>>> >
>>> > Trace complete.
>>> >
>>> >
>>> >
>>>
>

Re: IPv4 and Auctions

[Lee Howard]

On 10/27/19 12:47 PM, Michel Py wrote:



Michel Py wrote :
What I like with Hilco is that it brings transparency to the market. I think 
that each transfer should list the amount of the
transaction between parties. For example, I would like to know for how much 
44.192/10 went.


The parties to transactions probably protect that data in the same way 
they protect how much they paid for their routers, software licenses, 
and payroll.




Owen DeLong wrote :
If you really feel that this should be data the RIRs collect during transfers 
and that it should be published, I suggest you submit a proposal
for this into the ARIN policy development process. If you need help doing so, 
feel free to ask me or any other member of the AC.

I think the result should be simple, a .csv file containing an entry for each 
prefix transferred :
Date, size, price, origin RIR, resulting RIR.
Something like https://auctions.ipv4.global/prior-sales but covering all 
transactions, not only ipv4.global ones.
Transparency on transfer prices.


Other than price, each of the RIRs publishes all of that information in 
a daily transfers report. Maybe JSON instead of CSV, and they don't all 
use the same dictionary, but it's public.


Anyone can list blocks on auctions.ipv4.global, and the transaction will 
be included in our prior-sales report. Even private transactions can be 
run through the site, with the side benefit of including the transaction 
in that report.


Some brokers use the platform when they have a buyer who needs space and 
they don't have the right block, or they have a seller and want broader 
reach. If other brokers, buyers, or sellers were interested in 
publishing their transaction data, we'd happily do it.





What do you think about it ? a two-prong question :

- As yourself ? is it desirable for the community  in your opinion ?

- As AC member ? Does it have any chance to be approved by the AC ?

I would submit a proposal if it has some chances to pass; I don't want to lose 
the time of the AC if it's going to be deep-sixed right away.


This Thursday afternoon, at the end of the ARIN public policy meeting, 
is open mic time. If you want to float an idea to get the community's 
first impression, that's a pretty good time.


Lee

Re: IPv4 and Auctions

[Lee Howard]

Since you mentioned Hilco specifically. . .

IPv4.Global is the IPv4 address brokerage operated by Hilco Streambank. 
We match organizations who have more IPv4 address space than they need 
with organizations who need more IPv4 address space than they have. This 
is consistent with ARIN's Number Resource Policy Manual sections 8.3. 
and 8.4 
https://www.arin.net/participate/policy/nrpm/#8-3-transfers-between-specified-recipients-within-the-arin-region


I was on the ARIN Board when we approved this policy in 2008. The 
compelling argument to me was that this market would improve overall 
utilization of address space, and would be more efficient than ARIN 
trying to reclaim unused or lightly used address blocks. There are a lot 
of cases where pre-RIR, the justification was minimal, and 
organizational needs may change over the intervening 20-40 years.


Part of the interest, to me, was that many organizations who had 
received their allocations prior to ARIN's existence did not recognize 
ARIN's authority to reclaim their space. Even if ARIN prevailed in 
court, it would have been costly.


Not only that, but there's no minimum utilization requirement to keep 
addresses. You must show 50-80% utilization to get more, but what if you 
aren't asking for more? Would ARIN reclaim a block that was only 45% 
used? 25%? 1%?


In each of the more than 1500 transfers IPv4.Global has handled, the 
recipient has had to satisfy their need under the rules of the RIR in 
which they operate.


ARIN's policies are established by community consensus. ARIN's Public 
Policy Mailing List (ppml) is open, and there's a designated open 
microphone time at the end of the meeting next Thursday. If you won't be 
there in person, remote participation is pretty good.


I'm always happy to talk about this, either one on one, or if there are 
other folks at NANOG/ARIN next week who want to get together to chat, 
I'd be happy to facilitate.


Lee


On 10/24/19 8:08 AM, Matt Hoppes wrote:

A thought crossed my mind the other day as I was having a discussion with 
someone.

Every entity is suppose to justify their need for IPv4 address space from ARIN. 
This was always (in recent history) the case.

No entity is suppose to be given more IPv4 space until they have nearly 
exhausted their previous space.

How is it, then, that we daily for the last 2-3 years have places like Hilco 
that have sometimes 15-20 large IPv4 blocks up for auction?

Supposedly we are completely out of IPv4 space, yet every day large blocks are 
being sold for money, yet they were never returned because they weren’t needed.

Another thought: being that IPv4 address space is essentially leased to you 
from ARIN, can you even legally auction your space to someone else? I know it’s 
happening, but it would almost be like me auctioning my apartment to another 
random person.

Re: MAP-E

[Lee Howard]

On 8/9/19 1:32 AM, Vincent Bernat wrote:

  ❦  8 août 2019 16:18 -04, Lee Howard :


NAT64. IPv6-only to users. DNS resolver given in provisioning
information is a DNS64 server. When it does a lookup but there's no
, it invents one based on the A record (e.g., 2001:db8:64::). The IPv6 prefix in the invented  is actually a NAT64
translator. Pro: no CPE support required, well understood. Con: No
support for IPv4-only stuff in the prem, breaks DNSSEC.

Is there a known deployment for a medium/large ISP?


Not a fixed/wireline ISP.

The "con" that consumers' game consoles, smart TVs, and IoT things won't 
work is a pretty big "con." I was working with a small ISP that was 
running out of IPv4 addresses, and they kept saying "NAT64." I warned 
them that while NAT64 would solve their runout problem, it would drive a 
lot of unhappy customer calls.


It would be interesting if someone offered a NAT64 service (maybe for a 
reduced price). Buyers could tell consumer electronics companies, "I 
can't use your device without IPv6." But qualifying the customer who 
would do that would be more expensive, I think, than just buying IPv4 
addresses. Also but, would that be a Net Neutrality problem, charging 
less for a service that has arguably worse access to Amazon, Reddit, 
Twitter, etc.?


Lee



Thanks.

Re: MAP-E

[Lee Howard]

On 8/8/19 9:00 PM, Masataka Ohta wrote:

Lee Howard wrote:

MAP-T, MAP-E. IPv6-only between CE and Border Relay (BR). CPE is 
provisioned with an IPv4 address and a range of ports. It does basic 
NAT44, but only uses the reserved ports. Then it translates to IPv6 
(MAP-T) or encapsulates in IPv6 (MAP-E) and forwards to the 
configured Border Relay (BR), which changes it to IPv4. Pro: 
Stateless, very efficient. Con: Very little CPE support in home routers.


So, all we need is NAT44 CPE, which only uses a reserved block of ports,
which is (semi) statically configured by ISP operated gateway.


How would you route from the provider edge?

If CPE A has 192.0.2.15 port 1000-2999

and CPE B has 192.0.2.15 port 3000-4999,

how does your BRAS or CMTS or edge router know whether to forward a 
packet to A or B?


You could do policy routing or similarly do deep packet inspection, but 
you'd need a mechanism to provision that information into the provider 
edge router; you wouldn't manually configure match/set policy for each 
customer.



Pro: Stateless, very efficient, no IPv6 necessary Con: No current
CPE support.

As for protocol, assuming port mapping on UPnP gateway is statically
configured by ISPs not changable from CPE side, GetListOfPortMappings()
of UPnP should be useful for CPEs to know range of ports to be used
by them.


Do CPEs do this now, or is this another feature to ask vendors for?

Lee



    Masataka Ohta

Re: MAP-E

[Lee Howard]

On 8/2/19 11:39 AM, Jay Hanke wrote:

Is there a summary presentation someplace laying out the options that
are active in the wild with some deployment stats?


I can't think of a public presentation off the top of my head that 
explains how each major transition technology works, and the pros and 
cons of each. There must be one, but it's hard to cover the major 
options in an hour.


If you want to know who is using any given transition technology, 
there's this crowd-sourced list:


https://docs.google.com/spreadsheets/d/1ksOoWOaRdRyjZnjLSikHf4O5L1OUTNOO_7NK9vcVApc/edit#gid=0

Very brief summary of options:

NAT444. Your basic NAT, plus NAT again. You really need to deploy IPv6, 
too, or all your traffic will go through a translator (everything else 
below assumes native IPv6 is deployed). State information can get 
expensive. Well understood.


Dual-stack Lite. CPE sends IPv4 traffic through an IPv6 tunnel 
(softwire) to a pre-configured DS-Lite box, which does NAT44. Works 
fine, deployed at scale (see sheet above), but keeping state on lots of 
NAT44 can get expensive at scale.


NAT64. IPv6-only to users. DNS resolver given in provisioning 
information is a DNS64 server. When it does a lookup but there's no 
, it invents one based on the A record (e.g., 2001:db8:64::address>). The IPv6 prefix in the invented  is actually a NAT64 
translator. Pro: no CPE support required, well understood. Con: No 
support for IPv4-only stuff in the prem, breaks DNSSEC.


464xlat. IPv6-only between CE and NAT64. Any IPv4 traffic the CPE 
receives, it translates to IPv6 and forwards to a destination that's the 
NAT64 server, which translates again. Pro: widely deployed at scale on 
mobile networks. Con: Very little CPE support in home routers.


MAP-T, MAP-E. IPv6-only between CE and Border Relay (BR). CPE is 
provisioned with an IPv4 address and a range of ports. It does basic 
NAT44, but only uses the reserved ports. Then it translates to IPv6 
(MAP-T) or encapsulates in IPv6 (MAP-E) and forwards to the configured 
Border Relay (BR), which changes it to IPv4. Pro: Stateless, very 
efficient. Con: Very little CPE support in home routers.


Jordi is going to tell me there's plenty of support for 464xlat. 
However, you can't go into any old electronics store in North America 
and buy a home gateway with support for 464xlat or MAP. You can't buy 
them directly from a vendor, unless you're large enough to request a 
specific firmware build. Yes, you can get support from OpenWRT, but 
that's probably not how you want your support team spending their time.


CPE support is the next big frontier in IPv6 deployment.

Lee



On Fri, Aug 2, 2019 at 10:34 AM JORDI PALET MARTINEZ via NANOG
 wrote:

I understand that, but the inconvenient is the fix allocation of ports per 
client, and not all the clients use the same number of ports. Every option has 
good and bad things.



MAP is less efficient in terms of maximizing the “use” of the existing IPv4 
addresses.



https://datatracker.ietf.org/doc/draft-lmhp-v6ops-transition-comparison/





Regards,

Jordi

@jordipalet







El 2/8/19 17:25, "NANOG en nombre de Baldur Norddahl"  escribió:



Hi Jordi



My alternative to MAP-E is plain old NAT 444 dual stack. I am trying to avoid 
the expense and operative nightmare of having to run a redundant NAT server 
setup with thousands of users. MAP is the only alternative that avoids a 
provider run NAT server.



Regards,



Baldur





On Fri, Aug 2, 2019 at 3:38 PM JORDI PALET MARTINEZ via NANOG  
wrote:

Ask the vendor to support RFC8585.



Also, you can do it with OpenWRT.



I think 464XLAT is a better option and both of them are supported by OpenWRT.



You can also use OpenSource (Jool) for the NAT64.



Regards,

Jordi

@jordipalet







El 2/8/19 14:20, "NANOG en nombre de Baldur Norddahl"  escribió:



Hello



Are there any known public deployments of MAP-E? What about CPE routers with 
support?



The pricing on IPv4 is now at USD 20/address so I am thinking we are forced to 
go the CGN route going forward. Of all the options, MAP-E appears to be the 
most elegant. Just add/remove some more headers on a packet and route it as 
normal. No need to invest in anything as our core routers can already do that. 
No worries about scale.



BUT - our current CPE has zero support. We are too small that they will make 
this feature just for us, so I need to convince them there is going to be a 
demand. Alternatively I need to find a different CPE vendor that has MAP-E 
support, but are there any?



What is holding MAP-E back?  In my view MAP-E could be the end game for IPv4. 
Customers get full IPv6 and enough of IPv4 to be somewhat compatible. The ISP 
networks are not forced to do a lot of processing such as CGN otherwise 
requires.



I read some posts from Japan where users are reporting a deployment of MAP-E. 
Anyone know about that?



Regards,



Baldur

Re: MAP-E

[Lee Howard]

On 8/2/19 1:10 PM, JORDI PALET MARTINEZ via NANOG wrote:


The cost of sharing IPs in a static way, is that services such as Sony 
Playstation Network will put those addresses in the black list, so you 
need to buy more addresses. This hasn’t been the case for 
464XLAT/NAT64, which shares the addresses dynamically.


Furthermore, if some users need less ports than others, you 
“infra-utilize” those addresses, which again is not the case for 
464XLAT/NAT64. Each user gets automatically as many ports as he needs 
at every moment.


So, you save money in terms of addresses, that you can invest in a 
couple of servers running a redundant NAT64 setup 
(https://www.jool.mx/en/session-synchronization.html). Those servers 
can be actually VMs, so you don’t need dedicated hardware, especially 
because when you deploy IPv6 with 464XLAT, typically 75% (and going 
up) of you traffic will be IPv6 and only 25% will go thru the NAT64.


You work on much smaller networks than I do if a "couple of servers 
running Jool" can handle your load.  Jool is great, and the team that 
built it is great, but a couple of 10Gbps NICs on a pizza box doesn't go 
very far. I've tried 100Gbps and can't get the throughput with any 
normal CPU. Hoping to get back to it and run some actual measurements.


Lee


Regards,

Jordi

@jordipalet

El 2/8/19 18:24, "NANOG en nombre de Baldur Norddahl" 
mailto:nanog-boun...@nanog.org> en nombre de 
baldur.nordd...@gmail.com <mailto:baldur.nordd...@gmail.com>> escribió:


The goal is to minimize cost. Assuming 4 bits for the MAP routing (16 
users sharing one IPv4), leaving 12 bits for customer ports (4096 
ports) and a current price of USD 20 per IPv4 address, this gives a 
cost of USD 1.25 per user for a fully redundant solution. For us it is 
even cheaper as we can recirculate existing address space.


Regards,

Baldur

On Fri, Aug 2, 2019 at 5:32 PM JORDI PALET MARTINEZ 
mailto:jordi.pa...@consulintel.es>> wrote:


I understand that, but the inconvenient is the fix allocation of
ports per client, and not all the clients use the same number of
ports. Every option has good and bad things.

MAP is less efficient in terms of maximizing the “use” of the
existing IPv4 addresses.

https://datatracker.ietf.org/doc/draft-lmhp-v6ops-transition-comparison/

Regards,

Jordi

@jordipalet

El 2/8/19 17:25, "NANOG en nombre de Baldur Norddahl"
mailto:nanog-boun...@nanog.org> en
nombre de baldur.nordd...@gmail.com
<mailto:baldur.nordd...@gmail.com>> escribió:

Hi Jordi

My alternative to MAP-E is plain old NAT 444 dual stack. I am
trying to avoid the expense and operative nightmare of having to
run a redundant NAT server setup with thousands of users. MAP is
the only alternative that avoids a provider run NAT server.

Regards,

Baldur

On Fri, Aug 2, 2019 at 3:38 PM JORDI PALET MARTINEZ via NANOG
mailto:nanog@nanog.org>> wrote:

Ask the vendor to support RFC8585.

Also, you can do it with OpenWRT.

I think 464XLAT is a better option and both of them are
supported by OpenWRT.

You can also use OpenSource (Jool) for the NAT64.

Regards,

Jordi

@jordipalet

El 2/8/19 14:20, "NANOG en nombre de Baldur Norddahl"
mailto:nanog-boun...@nanog.org> en
nombre de baldur.nordd...@gmail.com
<mailto:baldur.nordd...@gmail.com>> escribió:

Hello

Are there any known public deployments of MAP-E? What about
CPE routers with support?

The pricing on IPv4 is now at USD 20/address so I am thinking
we are forced to go the CGN route going forward. Of all the
options, MAP-E appears to be the most elegant. Just add/remove
some more headers on a packet and route it as normal. No need
to invest in anything as our core routers can already do that.
No worries about scale.

BUT - our current CPE has zero support. We are too small that
they will make this feature just for us, so I need to convince
them there is going to be a demand. Alternatively I need to
find a different CPE vendor that has MAP-E support, but are
there any?

What is holding MAP-E back?  In my view MAP-E could be the end
game for IPv4. Customers get full IPv6 and enough of IPv4 to
be somewhat compatible. The ISP networks are not forced to do
a lot of processing such as CGN otherwise requires.

I read some posts from Japan where users are reporting a
deployment of MAP-E. Anyone know about that?

Regards,

Baldur


**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic messa

Re: any interesting/useful resources available to IPv6 only?

[Lee Howard]

On 5/6/19 12:45 PM, Brian J. Murrell wrote:


But the came I am making is to PHBs, not engineers and I am trying to
find a path of least resistance.


IPv6 is, on average, 20ms faster than IPv4. I don't know why, I just 
know that the evidence is diverse and compelling that it's true. 
https://www.retevia.net/fast


A faster web site means people find it earlier in Google search, stay on 
it longer, and buy more stuff from it. https://www.retevia.net/seo


If you're an ISP, it would be nice to give your customers that extra speed.

IPv6 in your data center also means your security team has an easier 
time tracking down miscreants than if they were behind CGN. Any security 
tool without IPv6 is blind to 54% of US traffic, 24% of CA traffic, 27% 
of global traffic.


Renumbering into IPv6 might mean you can make addresses available for 
sale, and prices are approaching the point where that makes sense. 
https://www.retevia.net/address-pricing-2019-and-beyond/


For ISPs, you should absolutely figure out your IPv4 run rate, i.e., 
when you'll run out of IPv4 addresses. Then the PHBs have to decide what 
to do about that: deploy IPv6 and hope it's a viable alternative (with 
translation?), buy IPv4 addresses (at today's prices or tomorrow's, and 
how many addresses?), or deploy NAT44 and hope customers are okay with it.


For ISPs, consider how many of your customers are medium to large 
companies. These customers may need IPv6, either to sell their own 
addresses, or to connect with branches or partners who are out of IPv4. 
There are ISPs in the world who only support native IPv4 because some of 
their customers can't get approval for IPv4 from US corporate HQ. Of 
course, they pay more for that. For that matter, consider how much you 
charge for additional IPv4 addresses, and the rate at which customers 
could decline that service.


(But wait, you say, PHBs don't want to lose the IPv4 revenue! Depends on 
whether the competition is likely to offer the cheaper alternative)


Finally, the Rabobank argument: Maybe there aren't important sites, 
tools, or architectures that are only available over IPv6 right now. 
When will there be? Five years? Ten? (Seven? 
https://www.retevia.net/ipv6-growth/) How long will it take you to be 
completely IPv4-independent, and will it be done in time?


So there's an 8-slide deck for you. Good luck with that pitch! I'm 
interested in what feedback/pushback you get.


Lee




b.

Re: Widespread Firefox issues

[Lee]

On 5/4/19, Mark Foster  wrote:
> Official update from Mozilla:
>
> https://blog.mozilla.org/addons/2019/05/04/update-regarding-add-ons-in-firefox/
where they say
  Please note: The fix does not apply to Firefox ESR
which is what I'm running, so
  about:config
change
  xpinstall.signatures.required
to false, restart and all my extensions now show
  xxx could not be verified for use in Firefox.  Proceed with caution.
but at least they're all enabled again :)

Lee

Re: who attacks the weather channel?

[Lee]

On 4/18/19, John Sage  wrote:
> On 4/18/19 8:26 AM, Stephane Bortzmeyer wrote:
>> On Thu, Apr 18, 2019 at 03:16:34PM +,
>>   Kain, Rebecca (.)  wrote
>>   a message of 69 lines which said:
>>
>>> https://www.cnn.com/2019/04/18/media/weather-channel-hack/index.html
>>
>> May be these people?
>>
>> https://en.wikipedia.org/wiki/Weather_Underground
>>
>
> umm...
>
> Thinking this was a joke that, by the replies I've seen, most people are
> too young to get the reference to radical 60's politics
>
> Also it seems no one actually clicked through on the link, which would
> have suggested this
>
> *sigh*
>
Look on the bright side - if this type of thing still prompts a *sigh*
you're not all that old.

Best Regards,
Lee

Re: AS4134/AS4847 - Appear to be hijacking some ip space.

[Louie Lee via NANOG]

Hey folks,

I'm on it for solving both immediate issue and long term "fix".

Louie
-- 

Louie Lee, 李景雲

Peering Coordinator (AS16591 <https://as16591.peeringdb.com/>)

Network Capacity Manager

IP Numbers Administrator

Google Fiber

lou...@google.com

(650) 253-2847

*There are 10 types of people in the world: Those who understand binary,
and those who don't.*


On Fri, Apr 5, 2019 at 11:17 AM Christopher Morrow 
wrote:

> On Fri, Apr 5, 2019 at 12:29 PM Jay Borkenhagen  wrote:
> >
> > Hi Chris,
>
> yes!
>
> > It would be great if the Google Fiber / AS16591 folks could publish a
> > ROA in ARIN's hosted RPKI authorizing exactly 136.32.0.0/11 to be
> > originated only in AS16591.  That ROA would have addressed this matter
> > from AS7018's point of view.
> >
>
> ok, cool. This is sort of on my plate, at least from the internal
> viz/evangelizing perspective, and I'll go spend time chatting up the
> folk in fiber-land.
> having a: "See, doing this would prevent this" is helpful.
>
> > In the interim, I have added a temporary whitelist (slurm) entry into
> > our RPKI caches, causing the AS7018 network to disregard the
> > more-specific /24s under 136.32.0.0/11.
>
> thanks!
>
> > Good luck.
> > Jay B.
> >
> >
> > Christopher Morrow writes:
> >  > Howdy gentle folks:
> >  >
> >  > It looks like AS4847 - "China Networks Inter-Exchange"
> >  >
> >  > Is taking some time to announce reachability for at least:
> >  >   136.38.33.0/24
> >  >
> >  > which they ought not, given that this /24 is part of a /11 assigned to
> >  > AS16591 (google fiber)... Looking at routeviews data, I see the
> >  > following as-paths for this one /24:
> >  > $ grep -A1 Refresh /tmp/x | grep 4847
> >  >   1239 174 4134 4847
> >  >   3549 3356 174 4134 4847
> >  >   701 174 4134 4847
> >  >   4901 6079 3257 4134 4847
> >  >   20912 174 4134 4847
> >  >   1221 4637 4134 4847
> >  >   1351 11164 4134 4847
> >  >   6079 1299 4134 4847
> >  >   6079 3257 4134 4847
> >  >   7018 4134 4847
> >  >   6939 1299 4134 4847
> >  >   3561 209 4134 4847
> >  >   3303 4134 4847
> >  >   3277 39710 9002 4134 4847
> >  >   2497 4134 4847
> >  >   4826 1299 4134 4847
> >  >   54728 20130 23352 2914 4134 4847
> >  >   19214 3257 4134 4847
> >  >   101 101 11164 4134 4847
> >  >   1403 6453 4134 4847
> >  >   852 6453 4134 4847
> >  >   1403 6453 4134 4847
> >  >   286 4134 4847
> >  >    1273 4134 4847
> >  >   57866 3491 4134 4847
> >  >   3267 1299 4134 4847
> >  >   49788 174 4134 4847
> >  >   53767 3257 4134 4847
> >  >   53364 3257 4134 4847
> >  >   8283 57866 3491 4134 4847
> >  >   7660 2516 4134 4847
> >  >
> >  > >From that I think the following AS should have filtered this prefix
> and are not:
> >  > $ grep -A1 Refresh /tmp/x | grep 4847 | sed 's/ 4134 4847//' | awk
> >  > '{print $NF}' | sort -n | uniq
> >  >
> >  > 174  - Cogent
> >  > 209 - Qwest
> >  > 286 - KPN
> >  > 1273 - Vodafone
> >  > 1299 - Telia
> >  > 2497 - IIJ
> >  > 2516 - KDDI
> >  > 2914 - NTT
> >  > 3257 - GTT
> >  > 3303 - Swisscom
> >  > 3491 - PCCW
> >  > 4637 - Telstra
> >  > 6453 - TATA
> >  > 7018 - ATT
> >  > 9002 - RETN
> >  > 11164 - Internet2
> >  >
> >  > It'd be great if the listed folk could filter AS4134 :)
> >  >
> >  > -Chris
>

Re: modeling residential subscriber bandwidth demand

[Louie Lee via NANOG]

Certainly.

Projecting demand is one thing. Figuring out what to buy for your backbone,
edge (uplink & peer), and colo (for CDN caches too!), for which
scale+growth is quite another.

And yeah, Jim, overall, things have stayed the same. There are just the
nuances added with caches, gaming, OTT streaming, some IoT (like always-on
home security cams) plus better tools now for network management and
network analysis.

Louie
Google Fiber.



On Tue, Apr 2, 2019 at 12:00 PM Jared Mauch  wrote:

>
>
> > On Apr 2, 2019, at 2:35 PM, jim deleskie  wrote:
> >
> > +1 on this. its been more than 10 years since I've been responsible for
> a broadband network but have friends that still play in that world and do
> some very good work on making sure their models are very well managed, with
> more math than I ever bothered with, That being said, If had used the
> methods I'd had used back in the 90's they would have fully predicted per
> sub growth including all the FB/YoutubeNetflix traffic we have today. The
> "rapid" growth we say in the 90's and the 2000' and even this decade are
> all magically the same curve, we'd just further up the incline, the
> question is will it continue another 10+ years, where the growth rate is
> nearing straight up :)
>
>
> I think sometimes folks have the challenge with how to deal with aggregate
> scale and growth vs what happens in a pure linear model with subscribers.
>
> The first 75 users look a lot different than the next 900.  You get
> different population scale and average usage.
>
> I could roughly estimate some high numbers for population of earth
> internet usage at peak for maximum, but in most cases if you have a 1G
> connection you can support 500-800 subscribers these days.  Ideally you can
> get a 10G link for a reasonable price.  Your scale looks different as well
> as you can work with “the content guys” once you get far enough.
>
> Thursdays are still the peak because date night is still generally Friday.
>
> - Jared

Re: modeling residential subscriber bandwidth demand

[Louie Lee via NANOG]

+1 Also on this.

>From my viewpoint, the game is roughly the same for the last 20+ years. You
might want to validate that your per-customer bandwidth use across your
markets is roughly the same for the same service/speeds/product. If you
have that data over time, then you can extrapolate what each market's
bandwidth use would be when you lay on a customer growth forecast.

But for something that's simpler and actionable now, yeah, just make sure
that your upstream and peering(!!) links are not congested. I agree that
the 50-75% is a good target not only for the lead time to bring up more
capacity, but also to allow for spikes in traffic for various events
throughout the year.

Louie
Google Fiber


On Tue, Apr 2, 2019 at 11:36 AM jim deleskie  wrote:

> +1 on this. its been more than 10 years since I've been responsible for a
> broadband network but have friends that still play in that world and do
> some very good work on making sure their models are very well managed, with
> more math than I ever bothered with, That being said, If had used the
> methods I'd had used back in the 90's they would have fully predicted per
> sub growth including all the FB/YoutubeNetflix traffic we have today. The
> "rapid" growth we say in the 90's and the 2000' and even this decade are
> all magically the same curve, we'd just further up the incline, the
> question is will it continue another 10+ years, where the growth rate is
> nearing straight up :)
>
> -jim
>
> On Tue, Apr 2, 2019 at 3:26 PM Mikael Abrahamsson 
> wrote:
>
>> On Tue, 2 Apr 2019, Tom Ammon wrote:
>>
>> > Netflow for historical data is great, but I guess what I am really
>> > asking is - how do you anticipate the load that your eyeballs are going
>> > to bring to your network, especially in the face of transport tweaks
>> > such as QUIC and TCP BBR?
>>
>> I don't see how QUIC and BBR is going to change how much bandwidth is
>> flowing.
>>
>> If you want to make your eyeballs happy then make sure you're not
>> congesting your upstream links. Aim for max 50-75% utilization in 5
>> minute
>> average at peak hour (graph by polling interface counters every 5
>> minutes). Depending on your growth curve you might need to initiate
>> upgrades to make sure they're complete before utilization hits 75%.
>>
>> If you have thousands of users then typically just look at the statistics
>> per user and extrapolate. I don't believe this has fundamentally changed
>> in the past 20 years, this is still best common practice.
>>
>> If you go into the game of running your links full parts of the day then
>> you're into the game of trying to figure out QoE values which might mean
>> you spend more time doing that than the upgrade would cost.
>>
>> --
>> Mikael Abrahamssonemail: swm...@swm.pp.se
>>
>

Contact at Spectrum/Charter (LA area)

[Lee Burton]

Looking for a contact re: an event we are running.

Thanks in advance,
Lee Burton
lbur...@mrow.org
lee.bur...@lfest.org

Re: Auto-configuring IPv6 transition mechanisms on customer devices

[Lee Howard]

On 1/2/19 7:59 AM, Brandon Martin wrote:

On 1/2/19 7:37 AM, Mikael Abrahamsson wrote:


Yes, we're buying devices from a vendor that uses OpenWrt as base for 
their operating system. We're using this one currently:


https://www.intenogroup.com/products/gateways/eg400/

We remotely manage it using Netconf/YANG from our NMS so we can do 
software upgrades (and other management). If you have low volume you 
can of course use SSH and script it if that's what you want. They 
also have TR-69 based management, and perhaps others.


If only Ubiquiti had so many (documented) options for management...


DHCPv6 is fine.

Jordi did a panel a year ago at APNIC where he browbeat vendors about 
supporting transition mechanisms. The summary is that they said they 
have code, they just don't want to ship everything, because it's more to 
maintain. 
https://blog.apnic.net/2017/11/09/ce-vendors-share-thoughts-ipv6-support/


This led to the draft he mentioned upthread, requiring support. OpenWRT 
is still the only thing I've seen that wasn't a customer-specific build.





Get in touch with them, tell them I said hi. They might be able to 
accomodate your low volume by sending you gateways with their default 
software on it and you'd have to upgrade it to whatever image you 
want on it, yourself. It only takes a few minutes per box so should 
be perfectly doable with your low volume

That could work.  I'll give them a shout.  Thanks for the pointer.

Out of curiosity, what do you use to terminate the MAP/LW4o6 
tunnels/encaps to the public Internet?  Plenty of options here, of 
course, especially at the traffic rates I'm moving.  I'm just curious 
what others' experiences have been as these are still somewhat new in 
SP deployments, I think.


Open source software. For stateless transition mechanisms (MAP/LW4o6) it 
can be really fast. We have a build I'd be happy to share, if you want.


Lee

Re: CenturyLink RCA?

[Lee]

On 12/31/18, Keith Medcalf  wrote:
>> It could have been worse:
>>   https://www.cio.com.au/article/65115/all_systems_down/
>
> "Make network changes only between 2am and 5am on weekends."
>
> Wow.  Just wow.

yeah.  out of all the possible lessons they could have learned..

>  I suppose the IT types are considerably different than
> Process Operations.  Our rule is to only make changes scheduled at 09:00 (or
> no later than will permit a complete backout and restore by 15:00) Local
> Time on "Full Staff" day that is not immediately preceded or followed by a
> reduced staff day, holiday, or weekend-day.

Do you get paid differently based on time of day?  I used to be at a
place where they were drifting into a 'no changes until midnight' mode
except for one group; the rumor I heard was they got overtime pay
after 6PM which is why they got to do all their changes during the
day.

Lee

Re: CenturyLink RCA?

[Lee]

On 12/31/18, Aaron1  wrote:
> Yeah, could have been one of those...gone from bad to worse things like Dave
> mentioned... initial problem and course of action perhaps led to a worse
> problem.
>
> I’ve had DWDM issues that have taken down multiple locations far apart from
> each other due to how the transport guys hauled stuff
>
> A few years back I had about 15 routers all reboot suddenly... they were all
> far apart from each other, turned out to be one of the dual bgp sessions to
> rr cluster flapped and all 15 routers crash rebooted.
>
> But ~50 hours of downtime !?

It could have been worse:
  https://www.cio.com.au/article/65115/all_systems_down/

Re: Should ISP block child pornography?

[John Lee]

It is my understanding that ISPs block IP addresses and domains under court
order now for copyright violations, criminal activity which would include
CP. They require a court order as they cannot ascertain if it is CP or not,
that is a Law Enforcement decision. The US Supreme Court decision's was
just being nude is not lewd, also with aging software which can regress
photos, LEOs in the US have to ascertain if this is CP or photo shopped.

On Tue, Dec 11, 2018 at 12:54 PM Max Tulyev  wrote:

> ...and you will see the TOR exit nodes instead of crime home IP if
> censorship is implemented.
>
> 11.12.18 19:35, Aaron1 пише:
> > ... The only thing I can think of is the idea that I’ve heard before is
> > the way to catch someone is to watch them well they are accessing, the
> > concept of honeypots comes to mind
> >
> > Aaron
> >
> > On Dec 11, 2018, at 10:43 AM, Larry Allen  > > wrote:
> >
> >> I can't imagine a single rational argument against this.
> >>
> >> On Tue, Dec 11, 2018, 10:56 William Anderson  >>  wrote:
> >>
> >> On Fri, 7 Dec 2018 at 06:08, Lotia, Pratik M
> >> mailto:pratik.lo...@charter.com>> wrote:
> >>
> >> Hello all, was curious to know the community’s opinion on
> >> whether an ISP should block domains hosting CPE (child
> >> pornography exploitation) content? Interpol has a ‘worst-of’
> >> list which contains such domains and it wants ISPs to block it.
> >>
> >>
> >> This already happens in the UK, and has done for years.
> >>
> >> https://en.wikipedia.org/wiki/Child_abuse_image_content_list
> >>
> >>
> >> -n
> >>
>

Re: Verizon: Extremely Strange CPE Routing in NYC/NJ Area

[Lee]

On 11/29/18, Nick Zurku  wrote:
> Can anyone from Verizon take a look at this behavior for us?
>
> We’re having multiple Verizon FiOS users in the NYC/NJ area appear to
> teleport from their FiOS router to our IP in the Pittsburgh region.

Verizon is doing something seriously weird to windows traceroute:
C:\Users\Lee>tracert www.yahoo.com

Tracing route to atsv2-fp-shed.wg1.b.yahoo.com [98.138.219.232]
over a maximum of 30 hops:

  1<1 ms<1 ms<1 ms  fw.home.net
  2 1 ms<1 ms<1 ms  vbz-router.home.net [192.168.1.1]
  3 8 ms 3 ms 6 ms
media-router-fp2.prod1.media.vip.ne1.yahoo.com [98.138.219.232]

Trace complete.

C:\Users\Lee>ping -i 12 www.yahoo.com.

Pinging atsv2-fp-shed.wg1.b.yahoo.com [98.138.219.232] with 32 bytes of data:
Reply from 98.138.0.87: TTL expired in transit.
Reply from 98.138.0.87: TTL expired in transit.
Reply from 98.138.0.87: TTL expired in transit.
Reply from 98.138.0.87: TTL expired in transit.

Ping statistics for 98.138.219.232:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

C:\Users\Lee>ping -i 13 www.yahoo.com.

Pinging atsv2-fp-shed.wg1.b.yahoo.com [98.138.219.232] with 32 bytes of data:
Reply from 98.138.219.232: bytes=32 time=32ms TTL=54
Reply from 98.138.219.232: bytes=32 time=31ms TTL=54
Reply from 98.138.219.232: bytes=32 time=33ms TTL=54
Reply from 98.138.219.232: bytes=32 time=33ms TTL=54

Ping statistics for 98.138.219.232:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 31ms, Maximum = 33ms, Average = 32ms

C:\Users\Lee>

traceroute from a linux box works as expected..

Lee

> Users
> are seeing extreme slowness with TCP traffic, but ping times seem
> reasonable.
>
> User 1:
>  1  fios_quantum_gateway (192.168.1.1)  1.575 ms  2.426 ms  3.193 ms
>  2  204.16.244.8 (204.16.244.8)  2.269 ms  3.055 ms  2.727 ms
>
> User 2:
>  1  fios_quantum_gateway (192.168.1.1)  1.565 ms  1.048 ms  0.947 ms
>  2  204.16.244.8 (204.16.244.8)  2.162 ms  3.588 ms  3.048 ms
>
> I can provide end-user NYC/NJ IPs off-list if desirable.
>
>
> Here's a normal looking trace from an FiOS line locally in the Pittsburgh
> region:
>
>
> IP:  108.39.229.34
> Tracing route to four.libsyn.com [204.16.244.8]
> over a maximum of 30 hops:
>
>  1<1 ms<1 ms<1 ms  192.168.1.1
>  2 5 ms 2 ms 7 ms  lo0-100.PITBPA-VFTTP-301.verizon-gni.net
> <http://lo0-100.pitbpa-vfttp-301.verizon-gni.net/> [108.39.229.1]
>  3 5 ms 6 ms 6 ms  B3301.PITBPA-LCR-22.verizon-gni.net
> <http://b3301.pitbpa-lcr-22.verizon-gni.net/> [100.41.223.244]
>  4 *** Request timed out.
>  5 *** Request timed out.
>  613 ms12 ms13 ms  0.et-7-1-5.BR1.IAD8.ALTER.NET
> <http://0.et-7-1-5.br1.iad8.alter.net/> [140.222.226.17]
>  710 ms10 ms10 ms  verizon.com.customer.alter.net
>  [152.179.50.110]
>  812 ms12 ms13 ms  be3084.ccr42.dca01.atlas.cogentco.com
>  [154.54.30.65]
>  922 ms22 ms22 ms  be2820.rcr21.pit02.atlas.cogentco.com
>  [154.54.83.54]
> 1022 ms22 ms21 ms  38.104.120.90
> 1126 ms21 ms19 ms  204.16.241.133
> 12 *** Request timed out.
> 1321 ms21 ms21 ms  204.16.244.8
>
> Is this a possible traffic engineering blip? I can’t say we’ve ever
> seen trace routes return such sparse results and actually make it to the
> destination.
>
> --
> Nick Zurku
> Systems Engineer
> TeraSwitch, Inc.
> Cell: 412-953-0481
> Office: 412-945-7048
> nzu...@teraswitch.com
>

Re: bloomberg on supermicro: sky is falling

[Lee]

On 10/10/18, Mike Hale  wrote:
> To be fair, the idea that your security costs shouldn't outweigh
> potential harm really shouldn't be controversial.  You don't spend a
> billion dollars to protect a million dollars worth of product.

The problem with that idea is that it's almost always implemented as
  your security costs shouldn't outweigh _your_ potential harm

Regards,
Lee

> On Wed, Oct 10, 2018 at 10:54 AM Naslund, Steve 
> wrote:
>>
>> Mr Herrin, you are asking us to believe one or all of the following :
>>
>> 1.  You believe that it is good security policy to NOT have a default DENY
>> ALL policy in place on firewalls for DoD and Intelligence systems handling
>> sensitive data.
>>
>> 2.  You managed to convince DoD personnel of that fact and actually got
>> them to approve an Authorization to Operate such a system based on cost
>> savings.
>>
>> 3.  You are just trolling to start a discussion.
>>
>> The reason I asked what system it is would be to question the authorities
>> at DoD on who and why this was approved.  If you don't want to disclose
>> that then you are either trolling or don't want anyone to look into it.
>> It won't be hard to determine if you actually had any government contracts
>> since that is public data.  There are very few systems whose EXISTENCE is
>> actually classified, but you were the one that cited it as an example
>> supporting your policy.  If you cannot name the system then it doesn't
>> support your argument very well does it.  Completely unverifiable.
>>
>> In any case I believe the smart people here on NANOG can accept or reject
>> your security advice based on the factors above.  I'm done talking about
>> this one.
>>
>> Steven Naslund
>>
>>
>> >> Want to tell us what system this is?
>>
>> >Yes, I want to give you explicit information about a government system
>> >in this public forum and you should encourage me to do so. I thought
>> >you said you had some skill in the security field?
>> >
>> >Regards,
>> >Bill Herrin

Re: Buying IPv4 blocks

[John Lee]

If is a new US business and you are working internationally why not go
simple and use IPv6 addresses?

John Lee

On Thu, Oct 4, 2018 at 10:59 AM Ross Tajvar  wrote:

> Thanks everyone who replied. I got many responses off-list, including a
> lot of positive endorsements for several different vendors. It's good to
> know there are so many reputable options.
>
> -Ross
>
> On Mon, Oct 1, 2018 at 9:57 PM, Ross Tajvar  wrote:
>
>> Hi all,
>>
>> My US-based employer will be starting a new business unit soon that will
>> require IPv4 addresses (aiming for a /22 to start with). I know ARIN has a
>> waitlist (though I'm not sure where they're getting new IPs from), but the
>> faster way is to buy blocks from people who already have them. I'm aware of
>> Hilco Streambank - are there any other auctions? If I want to buy via
>> private sale, does anyone know of ways to find sellers?
>>
>> Thanks,
>> Ross
>>
>
>

Re: Oct. 3, 2018 EAS Presidential Alert test

[Lee Brown]

I work underground so I'm in airplane mode with WiFi calling enabled.
Nothing on Verizon Android.

RE: overages for power usage

[Lee Pallat]

We see lots of different approaches to this, depending on the datacenter 
operator:


  1.  Customer pays for power overage at an agreed to rate that is usually the 
same as their committed rate (but could be more). This could be based on a:
 *   Per KW consumed
 *   Per KWh consumed
 *   Per Amp consumed


  1.  Customer is notified that they are over their committed draw, and asked 
to increase their commitment. Could be:
 *   Immediately
 *   After a few months of repeated overages



  1.  Nothing happens (operator is not monitoring)

From: NANOG  On Behalf Of Alan Hannan
Sent: Thursday, September 20, 2018 7:12 PM
To: Unknown 
Subject: overages for power usage

What kind of typical overage costs have you seen when a customer/you use more 
than you've committed to?

I'm especially interested in datacenter power situations, where maybe you sign 
up for 5kw or 500kw and use more than that in a given month.  Is it billed at 
the same rate?  Is it billed at a higher rate?  What's the % increase of the 
higher rate versus the regular rate?

Thanks!

Re: OpenDNS CGNAT Issues

[Lee Howard]

On 09/11/2018 09:31 AM, Matt Hoppes wrote:

So don't CGNat?  Buy IPv4 addresses at auction?


Buy IPv4 addresses until CGN is cheaper. If a customer has to call, and 
you have to assign an IPv4 address, you have to recover the cost of that 
call and address.
While ((CostOfCall + CostOfAddress)*NumberOfCalls) > 
(CostOfAddress*NumberOfNewCustomers):

 BuyAddresses(NumberOfNewCustomers)

Meanwhile, deploy IPv6, and move toward IPv4aaS, probably 464xlat or 
MAP, but your religion may vary. That way your "CGN" is an IPv6-IPv4 
translator, and that's easier than managing dual-stack.


At the very least, dual-stack your web sites now, so the rest of us can 
get to it without translation.


Lee



On 9/11/18 9:28 AM, Ca By wrote:



On Tue, Sep 11, 2018 at 6:04 AM Matt Hoppes 
<mailto:mattli...@rivervalleyinternet.net>> wrote:


    That isn’t a solution. He still will need to dual stack and CGNat 
that.



But the flows that can support ipv6, will go ipv6 and not be subject 
to these abuse triggers.


Look, this list has monthly reports from some small network operator 
hurting their customers with CGN NAT. Meanwhile, the big guys like 
Comcast / Charter / ATT / Cox have moved onto ipv6.


Where does that leave the little guy with CGN?

Right here. Screaming into the avoid begging for help. Some special 
exception.


And, me, saying you had 10+ years of not deploying ipv6.  Here’s to 
the next 10 years of you email this list about your own failure to 
keep up with the times.


We will have this discussion again and again.  Not sure your 
customers will stick around, all they know is your CGN space got 
black listed from yet another service


#realtalk


    On Sep 11, 2018, at 08:54, Ca By mailto:cb.li...@gmail.com>> wrote:




    On Mon, Sep 10, 2018 at 9:12 PM Darin Steffl
    mailto:darin.ste...@mnwifi.com>> wrote:

    Hello,

    I have a ticket open with OpenDNS about filtering happening on
    some of our CGNAT IP space where a customer has "claimed" the
    IP as theirs so other customers using that same IP and OpenDNS
    are being filtered and not able to access sites that fall
    under their chosen filter.

    I have a ticket open from 6 days ago but it's not going
    anywhere fast.

    Can someone from OpenDNS contact me or point me to a contact
    there to help get this resolved? I believe we need to claim
    our CGNAT IP space so residential users can't claim IP's of
    their own.

    Thank you!


    You should provide your users ipv6, opendns supports ipv6 and
    likely will not have this issue you see

    https://www.opendns.com/about/innovations/ipv6/

    I am sure it may cost you time / money / effort. But this old
    thing we call ipv4 is in a death spiral, and it will just get
    worse and worse for you without ipv6.




    --     Darin Steffl
    Minnesota WiFi
    www.mnwifi.com <http://www.mnwifi.com/>
    507-634-WiFi
    <http://www.facebook.com/minnesotawifi> Like us on Facebook
    <http://www.facebook.com/minnesotawifi>

Re: Service provider story about tracking down TCP RSTs

[Lee]

On 9/1/18, William Herrin  wrote:
> On Sat, Sep 1, 2018 at 6:11 PM, Lee  wrote:
>> On 9/1/18, William Herrin  wrote:
>>> On Sat, Sep 1, 2018 at 4:00 PM, William Herrin  wrote:
>>>> Better yet, do the job right and build an anycast TCP stack as
>>>> described here: https://bill.herrin.us/network/anycasttcp.html
>>
>> An explosion in state management would be the least of my worries :)
>> I got as far as your Third hook: and thought of this
>>   https://www.jwz.org/doc/worse-is-better.html
>
> Hi Lee,
>
> On a brief tangent: Geographic routing would drastically simplify the
> Internet core, reducing both cost and complexity. You'd need to carry
> only nearby specific routes and a few broad aggregates for
> destinations far away. It will never be implemented, never, because no
> cross-ocean carriers are willing to have their bandwidth stolen when
> the algorithm decides it likes their path better than a paid one. Even
> though the algorithm gets the packets where they're going, and does so
> simply, it does so in a way that's too often incorrect.
>
> Then again, I don't really understand the MIT/New Jersey argument in
> Richard's worse-is-better story.

The "New Jersey" description is more of a caricature than a valid description:
  "I have intentionally caricatured the worse-is-better philosophy to
   convince you that it is obviously a bad philosophy and that the
   New Jersey approach is a bad approach."

I mentally did a 's/New Jersey/Microsoft/' and it made a lot more sense.

> The MIT guy says that a routine
> should handle a common non-fatal exception. The Jersey guy says that
> it's ok for the routine to return a try-again error and expect the
> caller to handle it. Since its trivial to build another layer that
> calls the routine in a loop until it returns success or a fatal error,
> it's more a philosophical argument than a practical one. As long as a
> correct result is consistently achieved in both cases, what's the
> difference?

That it's not always a trivial matter to build another layer.
That your retry layer needs at least a counter or timeout value so it
doesn't retry forever & those values need to be user configurable, so
the re-try layer isn't quite as trivial as it appears at first blush.

> Richard characterized the Jersey argument as, "It is slightly better
> to be simple than correct." I just don't see that in the Jersey
> argument. Every component must be correct. The system of components as
> a whole must be complete. It's slightly better for a component to be
> simple than complete. That's the argument I read and it makes sense to
> me.

Yes, I did a lot of interpreting also.  Then I hit on s/New
Jersey/Microsoft/ and it made a lot more sense to me.

> Honestly, the idea that software is good enough even with known corner
> cases that do something incorrect... I don't know how that survives in
> a world where security-conscious programming is not optional.

Agreed.  I substituted "soft-fail or fail-closed: user has to retry"
for doing something incorrect.

>> I had it much easier with anycast in an enterprise setting.  With
>> anycast servers in data centers A & B, just make sure no site has an
>> equal cost path to A and B.  Any link/ router/ whatever failure & the
>> user can just re-try.
>
> You've delicately balanced your network to achieve the principle that
> even when routing around failures the anycast sites are not
> equidistant from any other site. That isn't simplicity. It's
> complexity hidden in the expert selection of magic numbers.

^shrug^ it seemed simple to me.  And it was real easy to explain,
which is why I thought of that "worse is better" paper.  I took the
New Jersey approach & did what was basically a hack. You took the MIT
approach and created a general solution .. which is not so easy to
explain :)

> Even were that achievable in a network as chaotic as the Internet, is it 
> simpler
> than four trivial tweaks to the TCP stack plus a modestly complex but
> fully automatic user-space program that correctly reroutes the small
> percentage of packets that went astray?

Your four trivial tweaks to the TCP stack are kernel patches - right?
Which seems not at all trivial to me, but if you've got a group of
people that can support & maintain that - good for you!

Regards
Lee

Re: Service provider story about tracking down TCP RSTs

[Lee]

On 9/1/18, William Herrin  wrote:
> On Sat, Sep 1, 2018 at 4:00 PM, William Herrin  wrote:
>> On Sat, Sep 1, 2018 at 2:51 PM,   wrote:
>>> pointing out that a
>>> single traceroute to a Fastly site was hitting two of their POPs (they
>>> use
>>> anycast) and because they don’t sync state between POPs the second POP
>>> would
>>> naturally issue a TCP RST (sidebar: fascinating blog article on Fastly’s
>>> infrastructure here:
>>> https://www.fastly.com/blog/building-and-scaling-fastly-network-part-2-balancing-requests).
>>
>> Better yet, do the job right and build an anycast TCP stack as
>> described here: https://bill.herrin.us/network/anycasttcp.html
>
> BTW, for anyone concerned about an explosion in state management
> overhead, the TL;DR version is: the anycast node which first accepts
> the TCP connection encodes its identity in the TCP sequence number
> where all the other nodes can statelessly find it in the subsequent
> packets. The exhaustive details for how that actually works are
> covered in the paper at the URL above, which you'll have to read
> despite its length if you want to understand.

An explosion in state management would be the least of my worries :)
I got as far as your Third hook: and thought of this
  https://www.jwz.org/doc/worse-is-better.html

I had it much easier with anycast in an enterprise setting.  With
anycast servers in data centers A & B, just make sure no site has an
equal cost path to A and B.  Any link/ router/ whatever failure & the
user can just re-try.

Lee

Re: using expect to log into devices

[Lee]

On 7/20/18, Scott Weeks  wrote:
>
> I have looked extensively on the web for an answer
> and cannot find one, so I come to you guys.  I am
> not allowed to use modules in PERL or Python or I
> wouldn't have to do it this way.  I have to do this
> all in Expect and I am a newbie at it.
>
> Also, maybe I'm having the Friday afternoon "I want
> to go home" mental block and the answer is right in
> front of my nose.
>
> I have a file with 1000s of devices and another file
> with a list of commands.  The program issues all
> commands for a device and then moves on to the next
> one using nested loops.  In the debug I see the
> "spawn_id expNN" (where NN is a number that, I
> believe is representative of the number of file
> descriptors used in the system) increment only when
> a device does not respond.  As long as a device
> responds before the timeout period I see the expNN
> number does not increase.  As soon as a device
> doesn't respond the expNN count goes up and I can't
> figure out why.  Once I hit a certain expNN the
> program exits ungracefully; usually somewhere between
> 2500 and 3500 devices because our FD is set to 256
> and that's how long it takes for 256 devices to not
> respond before the timeout period.  Can anyone tell
> me why?  Here is the relevant config snippet.  I've
> tried every iteration of close and wait I found and
> no love...

'close $spawn_id' is wrong, so maybe that's it?

man expect
  close [-slave] [-onexec 0|1] [-i spawn_id]
closes  the  connection to the current process.  ...  The -i
flag declares the
process to close corresponding to the named spawn_id.
  <.. snip ..>
No  matter  whether  the connection is closed implicitly or
explicitly, you
should call wait to clear up the corresponding kernel process
slot.  close
does not call wait since there is no guarantee that closing a process
connection will cause it to exit.  See wait below for more info.

get rancid from here
  ftp://ftp.shrubbery.net/pub/rancid/

and take a look at clogin
  (which allows you to do 'clogin -x fileName dev1 dev2 ... devN' to
run the commands
   in 'fileName' on the list of devices)

The eof and timeout cases are basically
  { catch {close}; catch {wait}; }

Regards,
Lee


>
> You'll want to put this into a fixed width font like
> Courier New or it'll just be a mess.
>
>
> foreach element $device {
>
> send_user "\n\n"
>
> send_user "#\n"
> send_user "##  BEGIN $element  ###\n"
> send_user "#\n"
>
>spawn ssh -q -o StrictHostKeyChecking=no $username@$element
>
> expect {
>   timeout { send_user "\nfailed to get password prompt\n\n"
> send_user "#\n"
> send_user "###  END $element  \n"
> send_user "#\n"
> send_user "\n\n\n"; continue
> close $spawn_id
> wait
>   }
>   eof { send_user "\nssh failure for $element\n\n"
> send_user "#\n"
> send_user "###  END $element  \n"
> send_user "#\n"
> send_user "\n\n\n"; continue
> close $spawn_id
> wait
>   }
>   "assword" {
>   send "$password\n"
> }
>}
>
>
> expect {
>   timeout { send_user "\npassword did not work or enable mode not
> achieved\n\n"
> send_user "#\n"
> send_user "###  END $element  \n"
> send_user "#\n"
> send_user "\n\n\n"; continue
> close $spawn_id
> wait
>   }
>   eof { send_user "\npassword failure for $element\n\n"
> send_user "#\n"
> send_user "  END $element  #\n"
> send_user "#\n"
> send_user "\n\n\n"; continue
> close $spawn_id
> wait
>   }
> "" {
>   send "term len 0\n"
> # send "skip-page-display\n"
>
>   foreach command $commands {
> expect "#"
> send "$command\n"
> send_user "\n\n"
> }
> }
>}
>
> send "exit\n"
> send "exit\n"
>
> send_user "#\n"
> send_user "###  END $element  \n"
> send_user "#\n"
> send_user "\n\n\n"
>
> close
> wait
> }
>
>
> Thanks!
> scott
>
> ps; I realize my indenting of the curly braces and other
> things are not standard...  :)
>
>

Re: at business ipv6

[Lee Howard]

On 06/21/2018 12:07 PM, Nick Hilliard wrote:

Randy Bush wrote on 21/06/2018 16:35:


Static addresses don't fit into this paradigm because you if you 
configure your static customers from a single broadcast domain, then 
they are glued to a particular CMTS and can't be moved from that CMTS 
unless you renumber them.


Completely agree with all you've said here about how DOCSIS works. 
Several cable operators (at least) are working to make it so that DHCPv6 
assigns business customers  the same IPv6 prefix every time. Yes, it's 
DHCPv6 instead of static configuration, but I think it works.


Additional question, though:
Randy said "at business 1g fiber going into an Arris"
As fiber, it'll be PON. If it were a traditional cable company, I'd 
guess DPOE (DOCSIS Provisioning Over Ethernet).
Except it's AT, and I don't know if they're provisioning DOCSIS over 
their fiber; I would think it's GPON, using the same infrastructure as 
their U-Verse product (fiber to the curb, DSL to the home). That used to 
be PPPoE and not DHCP, but my information may be out of date.



Lee

Re: Impacts of Encryption Everywhere (any solution?)

[Lee Howard]

On 06/17/2018 02:53 PM, Brad wrote:

While I agree there are unintended consequences every time advancements are 
made in relation to the security and stability of the Internet- I disagree we 
should be rejecting their implementations. Instead, we should innovate further.


I look forward to your innovations.

Just because end to end encryption causes bandwidth issues for a very small 
number users - then perhaps they could benefit the most by these changes with 
additional capacity.


I encourage you to invest billions of dollars in rural broadband 
capacity worldwide. The rest of us will thank you for your sacrifice.


Lee


-Brad

 Original message From: Michael Hallgren  Date: 
6/17/18  11:14  (GMT-07:00) To: na...@jack.fr.eu.org Cc: Matthew Petach 
, nanog@nanog.org Subject: Re: Impacts of Encryption Everywhere (any 
solution?)
Le 2018-06-17 12:40, na...@jack.fr.eu.org a écrit :

Well, yes, there is, you simply have to break the end to end encryption

Yes, (or) deny service by Policy (remains to evaluate who's happy with
that).

Cheers,
mh


On 06/17/2018 03:09 AM, Matthew Petach wrote:

Except that if websites are set to HTTPS only, there's no option for
disabling encryption on the client side.

Matt


On Sat, Jun 16, 2018, 14:47  wrote:


On 06/16/2018 10:13 PM, Mike Hammett wrote:

Sadly, it's just falling on deaf ears. Silicon Valley will continue
to

think they know better than everyone else and people outside of that
bubble
will continue to be disadvantaged.

What, again ?
Encryption is what is best for the most people.
The few that will not use it can disable it.

No issue then.

Re: IPv6 faster/better proof? was Re: Need /24 (arin) asap

[Lee Howard]

On 06/11/2018 05:16 PM, Scott Weeks wrote:


--- cb.li...@gmail.com wrote:
From: Ca By 


Meanwhile, FB reports that 75% of mobiles in the USA
reach them via ipv6

And Akaimai reports 80% of mobiles

And they both report ipv6 is faster / better.


Let me grab a few more for you:

https://blogs.akamai.com/2016/06/preparing-for-ipv6-only-mobile-networks-why-and-how.html 



https://blogs.akamai.com/2016/10/ipv6-at-akamai-edge-2016.html

https://www.theregister.co.uk/2016/07/28/ipv6_now_faster_a_fifth_of_the_time 
which cites an academic paper 
http://dl.acm.org/citation.cfm?doid=2959424.2959429 by Vaibhav Bajpai 
and Jürgen Schönwälder


https://www.linkedin.com/pulse/ipv6-measurements-zaid-ali-kahn/

https://community.infoblox.com/t5/IPv6-CoE-Blog/Can-IPv6-Rally-Be-Faster-than-IPv4-Part-1/ba-p/6419 



https://www.nanog.org/meetings/abstract?id=2281


I'd sure like to see how they came up with these
numbers in a technically oriented paper.

Most of the above links explain how they got the numbers.
Facebook, in particular, did A/B testing using Mobile Proxygen, which is 
to say that they configured their mobile app to report performance over 
both IPv4 and IPv6 from the same handset at the same time.
Others, including APNIC's https://stats.labs.apnic.net/v6perf have a 
browser fetch two objects with unique URLs, one from an IPv4-only server 
and one from an IPv6-only server, and compare them.





  There
should be no difference, except for no CGN or Happy
Eyeballs working better or something similar.  Am I
missing something?  Same routers; same links; same
RTTs; same interrupt times on servers; same etc, etc
for both protocols.


From time to time somebody says, "Okay, maybe it works in practice, but 
does it work in *theory*?"


Busy engineers hardly ever investigate things going inexplicably right.

My hypothesis is that the observed difference in performance relates to 
how mobile networks deploy their transition mechanisms. Those with a 
dual-stack APN take a native path for IPv6, while using a CGN path for 
IPv4, which, combined with the Happy Eyeballs head start, might add 
501microseconds, which is a ms, which is 15% of 7ms. Those with an 
IPv6-only APN use a native path for IPv6, while using either a NAT64 for 
IPv4 (identical performance to CGN) or 464xlat, which requires 
translation both in the handset and the NAT64; handsets may not be 
optimized for header translation.


However, I have a dozen other hypotheses, and the few experiments I've 
been able to run have not confirmed any hypothesis. For instance, when 
one protocol is faster than another on a landline network, hop count is 
not a correlation (therefore, shorter paths, traffic engineering, etc., 
are not involved).


Lee



Hmm...  Faster and better?

The links seem to be an IPv6 cheerleader write up.
I looked at the URLs and the URLs one pointed to and
pulled out everything related to IPv6 being
faster/better.


Akamai URL:

"For dual-stacked hostnames we typically see higher
average estimated throughput over IPv6 than over IPv4.
Some of this may be due to IPv6-connected users being
correlated with better connectivity, but over half of
dual-stacked hostnames (weighted by daily bytes
delivered) have IPv6 estimated throughput at least 50%
faster than IPv4, and 90% of these hostnames have the
IPv6 estimated throughput at least 10% faster than
IPv4."



FB URL:

"People using Facebook services typically see better
performance over IPv6..."

and it points to
https://code.facebook.com/posts/1192894270727351/ipv6-it-s-time-to-get-on-board
which says:

"We’ve long been anticipating the exhaustion of IPv
in favor of the speed and performance benefits of
IPv6."

"We’ve observed that accessing Facebook can be 10-15
percent faster over IPv6."


I'd sure like to see how they came up with these
numbers in a technically oriented paper.  There
should be no difference, except for no CGN or Happy
Eyeballs working better or something similar.  Am I
missing something?  Same routers; same links; same
RTTs; same interrupt times on servers; same etc, etc
for both protocols.

scott

Re: Need /24 (arin) asap

[Lee Howard]

Assuming IPv6+translation, yes, you need IPv4 addresses of Good Repute 
for the outside; that might requiring constant monitoring, and notifying 
various content that it's shared address space. It's the same 
operational problem as CGNAT44, but reduced because half (or more) of 
your traffic is using unshared IPv6. Among other things, that means you 
don't need as many IPv4 addresses.


"But wait!" you say, because you're clever, "The original poster only 
wanted a /24. Surely you're not saying you could put less than a /24 
outside your CGN (44 or 64) and have it routed?"


Maybe the /28 is part of your larger aggregate. Or maybe it's a shared 
translator, handling, say, eight small companies who only need a /28 
each. And yes, you want very careful reputation monitoring in that case, 
and maybe some effort to prevent things that get one placed on Lists of 
Addresses of Ill Repute.


Sales pitch available on demand.

Lee Howard
Retevia.net


On 06/11/2018 12:56 PM, Michael Crapse wrote:

Never do i suggest to not have ipv6! Simply that no matter what, You still
have to traverse to ipv4 when you exit your ipv6 network onto ipv4 only
services. What IPv4 addresses are you going to use for the NAT64, or
464xlat, or even the business customers that require static IPv4 addresses?
Someone made a statement that getting more ipv6 would solve OP's problem of
finding more clean ipv4 space


On 11 June 2018 at 10:50, Ca By  wrote:



On Mon, Jun 11, 2018 at 9:27 AM, Michael Crapse 
wrote:


For an eyeball network, you cannot count on an IPv6 only network. Because
all of your "customers" will complain because they can't get to hulu, or
any other ipv4 only eyeball service. You still need the ipv4s to operate a
proper network, and good luck figuring out which services are blacklisting
your new /24 because the ipv4 space used to be a VPN provider, and the "in"
thing to do for these services is to block VPNs.


There are many IPv6-only eyeball networks.  Definitely many examples in
wireless (T-Mobile, Sprint, BT ) and wireline (DT with DS-Lite in Germany,
Orange Poland ...) and even more where IPv4 NAT44 + IPv6 is used.  Just
saying, having ipv6 hedges a lot of risk associate with blacklisting and
translation related overhead and potentially scale and cost of IPv4
addresses.




On 11 June 2018 at 09:21, Ca By  wrote:


On Sun, Jun 10, 2018 at 8:43 AM Stan Ouchakov 
Hi,

Can anyone recommend transfer market brokers for ipv4 addresses? Need
clean /24 asap. ARIN's waiting list is too long...

Thanks!


-Stan

Meanwhile, FB reports that 75% of mobiles in the USA reach them via

ipv6

https://code.facebook.com/posts/635039943508824/how-ipv6-dep
loyment-is-growing-in-u-s-and-other-countries/


And Akaimai reports 80% of mobiles

https://blogs.akamai.com/2018/06/six-years-since-world-ipv6-
launch-entering-the-majority-phases.html


And they both report ipv6 is faster / better.

Re: Impacts of Encryption Everywhere (any solution?)

[Lee Howard]

On 05/28/2018 10:23 AM, Mike Hammett wrote:

Has anyone outside of tech media, Silicon Valley or academia (all places wildly 
out of touch with the real world) put much thought into the impacts of 
encryption everywhere?

See "Effects of Pervasive Encryption on Operators."
https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/?include_text=1

TLS1.3 uses ephemeral keys, so even if you own both endpoints and 
everything in the middle, you can't decrypt a flow without some 
yet-to-be-developed technology.

QUIC encrypts everything, and of course, HTTPS.




So often we hear about how we need the best modern encryption on all forms of 
communication because of whatever scary thing is trendy this week (Russia, NSA, 
Google, whatever). HTTPS your marketing information and generic education 
pieces because of the boogeyman!

However, I recently came across a thread where someone was exploring getting a 
one megabit connection into their village and sharing it among many. The crowd 
I referenced earlier also believes you can't Internet under 100 megabit/s per 
home.


Yeah. Too many people forget that most of the Internet is mobile, and 
mobile != LTE. People also assume packet loss < 0.1%, latency <100ms, 
and power reliability >99%.

However, this could be wildly improved with caching ala squid or something 
similar. The problem is that encrypted content is difficult to impossible for 
your average Joe to cache. The rewards for implementing caching are greatly 
mitigated and people like this must suffer a worse Internet experience because 
of some ideological high horse in a far-off land.

Some things certainly do need to be encrypted, but encrypting everything means 
people with limited Internet access get worse performance OR mechanisms have to 
be out in place to break ALL encryption, this compromising security and privacy 
when it's really needed.

To circle back to being somewhat on-topic, what mechanisms are available to 
maximize the amount of traffic someone in this situation could cache? The 
performance of third-world Internet depends on you.

A proxy is all I've thought of. But it means everything is dependent on 
the proxy, and it's even in-path for things that really should be 
encrypted, like email and messaging.
I can't imagine why the weather should be encrypted, when everyone in a 
location wants to know the forecast.


Lee

Re: New DNS Service

[Lee]

On 4/3/18, Rod Beck <rod.b...@unitedcablecompany.com> wrote:
> And any consensus regarding the service? My layman question is how does this
> provide privacy?

You have to look for it & know what you're looking for:
https://developers.cloudflare.com/1.1.1.1/dns-over-https/
https://developers.cloudflare.com/1.1.1.1/dns-over-tls/

> The routers still need to know the IP address of the far
> end point. I would assume that it would be easy to deduce the domain name
> from the IP address.

It depends.  If the web site is hosted on.. let's say cloudflare,
there could be hundreds of names pointing to the same IP address.

Lee

Re: IPv4 smaller than /24 leasing?

[Lee Howard]

ARIN's fee for a /24 is $250 https://www.arin.net/fees/fee_schedule.html

That's about 1/15th of the price of a /24 on the market.

Of course, they don't have any /24s.

Unless, of course, you're deploying IPv6 and just need the /24 for your 
NAT64 box, DS-Lite AFTR, or MAP-T BR. 
https://www.arin.net/policy/nrpm.html#four10


Lee

PS: Let me know if you're considering this; I'll help.


On 03/13/2018 01:19 PM, Justin Wilson wrote:

On the consulting side, I do smaller than /24 blocks to customers over tunnels. 
 So far this is the only option we have found that works for the smaller ISP. 
We all know the routing table is bloated. We all know everyone *should* be 
moving toward IPV6.  A whole different discussion.  But, for now you have a 
subset of operators that are big enough to do BGP, maybe join an exchange, but 
not big enough to afford buying v4 space for each of their customers.  So they 
are utilizing a full /24 just to utilize it.  Things such as doing 1:many nat 
at each tower, doing Carrier Grade nat, and other things make it where they 
don’t necessarily need an IP per customer.  We all know that is ideal, but it’s 
not practical for the small to medium ISP.   Folks have brought up the argument 
that buying IPS is just the cost of doing business these days.  I argue that it 
isn’t.  I see networks with 2000 users and only a /24 running along very happy.

I agree that the global routing table is pretty bloated as is.  But what kind 
of a solution for providers who need to participate in BGP but only need a /25? 
I can’t see going below that.


Justin Wilson
j...@mtin.net

www.mtin.net
www.midwest-ix.com


On Mar 13, 2018, at 10:56 AM, Naslund, Steve <snasl...@medline.com> wrote:


Yes, exactly right.  You would probably have to tunnel the /27 back to where the >/24 
lives.  That's the only way I can see of it working "anywhere".  That's a 
technically valid solution but maybe not so hot if you are looking for high 
redundancy/availability since you are dependent on the tunnel being up and working.

As always the reputation of the aggregate is going to be critical as to how well this 
works for you.  It seems to me that increasingly these "portable" blocks have 
murky histories as spam and malware sources.  I would rather have a block assigned by a 
reputable upstream provider than to do this.

Steven Naslund
Chicago IL


Le 2018-01-04 20:16, Job Snijders a écrit :

On Thu, 4 Jan 2018 at 20:13, Filip Hruska <f...@fhrnet.eu> wrote:


I have stumbled upon this site [1] which seems to offer /27 IPv4
leasing.
They also claim "All of our IPv4 address space can be used on any
network in any location."

I thought that the smallest prefix size one could get routed
globally is /24?


Yes

So how does this work?
Probably with GRE, IPIP or OpenVPN tunnels.

Kind regards,

Job

IPv4 /24 is commonly the minimal chunk advertised to (and accepted by)
neighbors. If I run a global (or regional) network, I may advertise this
/24 -- or rather an aggregate covering it -- over my diverse
interconnection with neighbors, your /27 being part of the chunk and
routed to you internally (if you're va customer)-- no need for
encapsulation efforts. Similar scenario may be multi-upstream, subject
to acceptance of "punching holes in aggregates"... Am I missing
something? What's the trigger for doing tunneling here?

Happy New Year '18, by the way !

mh

Re: cgnat - how do you handle customer issues

[Lee Howard]

On 02/27/2018 12:52 PM, Aaron Gould wrote:

Thanks

  


For #2 – what if the ports allocated aren’t enough for the amount of inet 
traffic the customer site uses ?  …is the customer denied service based on 
insufficient port range ?  …or are they assigned another block within that some 
ip’s range of I think it’s 0-64k or 1025-64k… but how far can you take that 
before there aren’t anymore port blocks left on that single ip ?  …and if you 
have to allocate that customer another port block from a *different* ip, then 
we are in the situation of the bank website not liking the fact that the 
session is bouncing to a different ip maybe ?



Yes, common problem, and the session just fails (TCY SYN dropped) 
because of insufficient ports.
Most CGNs allow you to configure a range of ports for a customer, and 
reserve an additional range if they need more ports. Yes, if you 
allocate 1000 ports for one IPv4 address to each of 50 customers and 
they all need hundreds more ports than that, you're going to run out of 
ports and connections fail.


This is why you have IPv6. Even while many web sites and apps don't 
support IPv4, enough do that it relieves some pressure on your CGN.


Lee
  


- Aaron

  


From: Michael Crapse [mailto:mich...@wi-fiber.io]
Sent: Tuesday, February 27, 2018 11:19 AM
To: Mike Hammett
Cc: Aaron Gould; NANOG list
Subject: Re: cgnat - how do you handle customer issues

  


For number 2, I'm a fan of what mike suggests. I believe the technical term is 
MAP-T.
For number 1, anyone who wants one, gets one. We provide free public static IP 
to any customer who asks for one. Another solution, using above solution is to 
ask them which ports they need, and forward those to them using a port within 
their assign range. i.e. teach them how to access their home web server using a 
different port(say 32424, or similar). This won't solve all the issues, which 
is why we use solution 1.

  


On 27 February 2018 at 09:32, Mike Hammett <na...@ics-il.net> wrote:

I'm a fan of nailing each customer IP to a particular range of ports on a given 
public IP. Real easy to track who did what and to prevent shifting IPs.




-
Mike Hammett
Intelligent Computing Solutions

Midwest Internet Exchange

The Brothers WISP

- Original Message -

From: "Aaron Gould" <aar...@gvtc.com>
To: Nanog@nanog.org
Sent: Tuesday, February 27, 2018 10:30:21 AM
Subject: cgnat - how do you handle customer issues


Couple questions please. When you put thousands of customers behind a cgnat
boundary, how do you all handle customer complaints about the following.



1 - for external connectivity to the customers premise devices, not being
able to access web servers, web cameras, etc, in their premises?



2 - from the premise natted device, when customers go to a university or
bank web site, how do you handle randomly changing ip addresses/ports that
may occur due to idle time and session tear-down in nat table such that the
bank website has issues with seeing your session ip change?





-Aaron



  

Re: cgnat - how do you handle customer issues

[Lee Howard]

On 02/27/2018 11:30 AM, Aaron Gould wrote:

Couple questions please. When you put thousands of customers behind a cgnat
boundary, how do you all handle customer complaints about the following.

  


1 - for external connectivity to the customers premise devices, not being
able to access web servers, web cameras, etc, in their premises?

For web servers, you gently remind them of their ToS, and offer to 
upgrade them to a business account.


You offer to upgrade them to native IPv4, for a fee, and suggest they 
contact the manufacturer to see why it doesn't support IPv6.

I've heard of PCP for this, but never seen it in production on CPE.

I saw an early prototype of DS-Lite that included a customer portal that 
would allow the customer to enable port forwarding, but I can't imagine 
trying to walk a customer through two layers of port forwarding.


Most of these consumer electronics devices long ago started using 
ICE/TURN/STUN, and/or the company's web portal as their external 
communication platform. Doesn't mean all of them do.




2 - from the premise natted device, when customers go to a university or
bank web site, how do you handle randomly changing ip addresses/ports that
may occur due to idle time and session tear-down in nat table such that the
bank website has issues with seeing your session ip change?

  



You can extend your idle timers, of course, but only so much before 
you're squatting on all your ports.
After that, it's down to explaining to the university, bank, etc. that 
they need IPv6 if they want their web site to be reachable. Or at least 
they need to extend their idle timers.


Lee



  


-Aaron

IPv6 operations discussions

[Lee Howard]

The IETF v6ops working group is chartered to improve the operation of IPv6.
We have several active documents right now that would benefit from broader
operator feedback. For instance, there is current active discussion on:

Requirements for IPv6 Routers
<https://tools.ietf.org/html/draft-ietf-v6ops-ipv6rtr-reqs>
This document provides a list of requirements for operators’ routers. Is
it clear and exhaustive?

Basic Requirements for IPv6 Customer Edge Routers
<https://tools.ietf.org/html/draft-ietf-v6ops-rfc7084-bis>
What transition technologies should all CPE vendors put in their devices?
The current version proposes all of: 464xlat, DS-Lite, lw4o6, MAP-E, MAP-T,
6in4, and 6rd, as well as IPv4 multicast over IPv6.
There are related documents that split out some requirements for further
discussion.

Happy Eyeballs Version 2: Better Connectivity Using Concurrency
<https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis>
Is this a useful update to the existing Happy Eyeballs specification
(rfc6555)? Should we update Happy Eyeballs?
  
Considerations For Using Unique Local Addresses
<https://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-considerations>
Are ULAs useful, or are they a natural and risky predecessor to IPv6 NAT?


It would help future IPv6 operations if current operators would read these
documents and comment on them on the mailing list:
https://www.ietf.org/mailman/listinfo/v6ops
Note Well that comments become part of the IETF record, and thank you for
them.


Lee
v6ops co-chair

Re: Leasing /22

[Lee Howard]

From:  Michael Crapse <mich...@wi-fiber.io>
Date:  Monday, January 22, 2018 at 5:27 PM
To:  Mark Andrews <ma...@isc.org>
Cc:  Lee Howard <l...@asgard.org>, NANOG list <nanog@nanog.org>
Subject:  Re: Leasing /22

> Customers on ps4s and xboxes will hate you. They will always get "strict" nat,
> and it's your fault not mega corporation X's fault for not releasing IPv4s

Maybe. You don’t have to configure strict NAT on your translator (DS-Lite’s
pretty good at this, and although I’m a few weeks away from testing consoles
through 464xlat and MAP, they should work, too). And their NAT workarounds
are pretty sophisticated now.

There comes a point when winning your customers’ love isn’t profitable. I
don’t know if that point is $16/address for you, or $30, or $40, or $90.
Maybe it varies, depending on the customer.

That’s why I suggested in “TCO of CGN”[1] that everyone figure out for
themselves how much money you might lose to unhappy customers via CGN, and
compare it to how much addresses cost, and at what price point you might
turn around and sell addresses. My findings then, based on assumptions that
almost certainly are not true for any particular network, and which may have
changed, suggest that buying addresses still makes sense.


Lee

[1] http://ipv6.nanog.org/meetings/abstract?id=2025


> 
> On 22 January 2018 at 15:23, Mark Andrews <ma...@isc.org> wrote:
>> Add to that CGN from RFC 6598 addresses (100.64/10) + IPv6 though that
>> reaches its limit at ~4M customers.
>> 
>> Native IPv4 with a GUA to customers is essentially unavailable for new
>> ISPs.  It’s a matter of picking which flavour of NAT you and your
>> customers are going to use.  The sooner ALL ISP’s provide IPv6 to their
>> customers the sooner we restore delivering the Internet to the customers.
>> 
>> Mark
>> 
>>> > On 23 Jan 2018, at 9:05 am, Lee Howard <l...@asgard.org> wrote:
>>> >
>>> > IPv6 still solves your problem if you add any of NAT64, DS-Lite, 464xlat,
>>> > MAP-T, MAP-E.
>>> >
>>> > Yes, you’re NATing, but only the traffic to places like Hulu, and it will
>>> > decrease over time. And while you need addresses for the outside of the
>>> > translator, you don’t need as many (or to get more as frequently).
>>> >
>>> > Lee
>>> >
>>> > On 1/20/18, 10:20 AM, "NANOG on behalf of Mike Hammett"
>>> > <nanog-boun...@nanog.org on behalf of na...@ics-il.net> wrote:
>>> >
>>>> >> It's not really scraping the bottom of the barrel if your customers are
>>>> >> using Hulu and they're complaining because Hulu isn't responsive to
>>>> >> fixing their problems (geo-location, v6, etc.).
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> -
>>>> >> Mike Hammett
>>>> >> Intelligent Computing Solutions
>>>> >> http://www.ics-il.com
>>>> >>
>>>> >> Midwest-IX
>>>> >> http://www.midwest-ix.com
>>>> >>
>>>> >> - Original Message -
>>>> >>
>>>> >> From: "Ca By" <cb.li...@gmail.com>
>>>> >> To: "Michael Crapse" <mich...@wi-fiber.io>
>>>> >> Cc: "NANOG list" <nanog@nanog.org>
>>>> >> Sent: Friday, January 19, 2018 9:54:23 PM
>>>> >> Subject: Re: Leasing /22
>>>> >>
>>>> >> On Fri, Jan 19, 2018 at 5:48 PM Michael Crapse <mich...@wi-fiber.io>
>>>> >> wrote:
>>>> >>
>>>>> >>> Has Hulu, or a thousand other content distributors considered IPv6?
>>>>> >>> Because
>>>>> >>> you can't even tunnel to ipv4 without setting off VPN alarms with
>>>>> HULU.
>>>>> >>>
>>>> >>
>>>> >> Hulu? Really scraping the bottom of the barrel of content providers that
>>>> >> dont use ipv6 these days.
>>>> >>
>>>> >> Netflix and Youtube support v6 ... and thousand of others (thousands
>>>> just
>>>> >> on Cloudflare where v6 is default on)
>>>> >>
>>>> >> About 80% of my traffic is native e2e v6, mostly google / youtube / fb /
>>>> >> netflix / apple / amazon — but your mix may vary.
>>>> >>
>>>> >>
>>>> >>
>>>>> >>>
>>>>> >>>
>>>>> >>> On 19 January 2018 at 18:38, Andrew Kirch <trel...@trelane.net> wrote:
>>>>> >>>
>>>>>> >>>> On Fri, Jan 19, 2018 at 4:59 PM Ryan Gard <ryang...@gmail.com>
>>>>>> wrote:
>>>>>> >>>>
>>>>>>> >>>>> We're on the hunt yet again for an additional /22 to lease, and
are
>>>>>>> >>>>> wondering what the best options are out there?
>>>>>>> >>>>>
>>>>>>> >>>>> Our usual suspects that we've reached out to in the past seem to
be
>>>>> >>> plum
>>>>>>> >>>>> out... Any recommendations?
>>>>>>> >>>>>
>>>>>>> >>>>> Thanks!
>>>>>>> >>>>>
>>>>>>> >>>>> --
>>>>>>> >>>>> Ryan Gard
>>>>>>> >>>>>
>>>>>> >>>> Have you considered IPv6?
>>>>>> >>>>
>>>>> >>>
>>>> >>
>>>> >>
>>> >
>>> >
>> 
>> --
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742 <tel:%2B61%202%209871%204742>   INTERNET:
>> ma...@isc.org
>> 
> 

Re: Leasing /22

[Lee Howard]

IPv6 still solves your problem if you add any of NAT64, DS-Lite, 464xlat,
MAP-T, MAP-E. 

Yes, you’re NATing, but only the traffic to places like Hulu, and it will
decrease over time. And while you need addresses for the outside of the
translator, you don’t need as many (or to get more as frequently).

Lee

On 1/20/18, 10:20 AM, "NANOG on behalf of Mike Hammett"
<nanog-boun...@nanog.org on behalf of na...@ics-il.net> wrote:

>It's not really scraping the bottom of the barrel if your customers are
>using Hulu and they're complaining because Hulu isn't responsive to
>fixing their problems (geo-location, v6, etc.).
>
>
>
>
>- 
>Mike Hammett 
>Intelligent Computing Solutions
>http://www.ics-il.com
>
>Midwest-IX 
>http://www.midwest-ix.com
>
>- Original Message -
>
>From: "Ca By" <cb.li...@gmail.com>
>To: "Michael Crapse" <mich...@wi-fiber.io>
>Cc: "NANOG list" <nanog@nanog.org>
>Sent: Friday, January 19, 2018 9:54:23 PM
>Subject: Re: Leasing /22
>
>On Fri, Jan 19, 2018 at 5:48 PM Michael Crapse <mich...@wi-fiber.io>
>wrote: 
>
>> Has Hulu, or a thousand other content distributors considered IPv6?
>>Because 
>> you can't even tunnel to ipv4 without setting off VPN alarms with HULU.
>> 
>
>Hulu? Really scraping the bottom of the barrel of content providers that
>dont use ipv6 these days.
>
>Netflix and Youtube support v6 ... and thousand of others (thousands just
>on Cloudflare where v6 is default on)
>
>About 80% of my traffic is native e2e v6, mostly google / youtube / fb /
>netflix / apple / amazon — but your mix may vary.
>
>
>
>> 
>> 
>> On 19 January 2018 at 18:38, Andrew Kirch <trel...@trelane.net> wrote:
>> 
>> > On Fri, Jan 19, 2018 at 4:59 PM Ryan Gard <ryang...@gmail.com> wrote:
>> > 
>> > > We're on the hunt yet again for an additional /22 to lease, and are
>> > > wondering what the best options are out there?
>> > > 
>> > > Our usual suspects that we've reached out to in the past seem to be
>> plum 
>> > > out... Any recommendations?
>> > > 
>> > > Thanks! 
>> > > 
>> > > -- 
>> > > Ryan Gard 
>> > > 
>> > Have you considered IPv6?
>> > 
>> 
>
>

Re: Waste will kill ipv6 too

[Lee Howard]

From:  <christopher.mor...@gmail.com> on behalf of Christopher Morrow
<morrowc.li...@gmail.com>
Date:  Wednesday, December 20, 2017 at 6:07 PM
To:  Lee Howard <l...@asgard.org>
Cc:  Mike <mike-na...@tiedyenetworks.com>, nanog list <nanog@nanog.org>
Subject:  Re: Waste will kill ipv6 too

> 
> 
> On Wed, Dec 20, 2017 at 2:16 PM, Lee Howard <l...@asgard.org> wrote:
>> 
>> I’ve tried several times to come up with a scenario that leads to
>> depletion in less than 200 years, and I haven’t managed it. Can you do it?
> 
> during some ARIN discussions that revolved around Transition Technologies and
> allocations to large ISPs, there were more than a few folk batting around the
> idea that they may need to allocate a /24 or a /20 even to a single provider.
> 
> I believe DT has a /19 assigned to them currently? how many /19's are there in
> the v6 space? (524288-ish)
> That's only ~100x the current number of active ASN in the field. It's unclear
> (to me) how many of those could/would justify a /19 equivalent, and how fast
> the ASN field is growing over time.

DT is one of the largest ISPs in the world, isn’t it?

Can you devise a scenario in which there are 524,288 ISPs the size of DT?
Or one where every currently active ASN, times 100X, needs/justifies a /19?

> 
> 200 years seems optomistic, 20 years seems easy to imagine surpassing though.
> What's the sweet spot?
>  

200 years seems pessimistic to me. Every scenario I run uses ridiculously
profligate assumptions, and usually multiplies those by a few orders of
magnitude. Even extrapolating from your math above, I don’t get less than
CE.

Lee

Re: Waste will kill ipv6 too

[Lee Howard]

On 12/20/17, 1:23 PM, "NANOG on behalf of Mike" <nanog-boun...@nanog.org
on behalf of mike-na...@tiedyenetworks.com> wrote:

>On 12/17/2017 08:31 PM, Eric Kuhnke wrote:
>> some fun examples of the size of ipv6:
>>
>> https://samsclass.info/ipv6/exhaustion-2016.htm
>>
>> 
>>https://www.reddit.com/r/theydidthemath/comments/2qxgxw/self_just_how_big
>>_is_ipv6/
>>
>
>
>Every time I see these "Look how many more addresses we have now with
>IPv6", I just shake my head.
>
>  Yes, the address space is very large. But, all of the protocols, all
>of the addressing guides, all of the operational 'best practices', ALL
>OF IT, increases by orders of magnitude the amount of waste along with
>it. Call this the 'shavings', in IPv4 for example, when you assign a P2P
>link with a /30, you are using 2 and wasting 2 addresses. But in IPv6,
>due to ping-pong and just so many technical manuals and other advices,
>you are told to "just use a /64' for your point to points. So, the
>actual waste is dilutes the actual implementable size of the total ipv6
>address space due to the waste component. And I have not yet seen any
>study or even proposed theory to explore what the IPv6 Internet would
>look like, if used in place of all IPv4 in all the places and ways that

Okay, so do the thought experiment.

Let’s say 10 billion people in the world.
Let’s say each of them has 10 devices, each with a /64, and to be
ridiculous, each with a p2p link to the others, so we have 100 /64 per
person.
That’s 1 trillion /64s.
Oh, dear, I’ve used up the first /27 of IPv6 space.

What if we try giving ten /48s to each of 10 billion people, one for each
of the ten providers they’ll have? Sure, I’m handwaving the p2p links, but
that’s why we assign that /48.
That’s 100 billion /48s, which is something like a /11.

I’ve tried several times to come up with a scenario that leads to
depletion in less than 200 years, and I haven’t managed it. Can you do it?

> why is
>nobody thinking or talking about the looming exhaustion of ieee OUI
>addresses?



> Network cards made 15 years ago and since consigned to the
>electronics scrap heap in the sky, take with them their addresses never
>to be reused again (unless you are a freak like me and keep some for
>'positively never assigned anywhere'). And old dead companies that were
>assigned OUIs, they get 24 bits of address space to take to their
>graves. We should be re-thinking mac addressing altogether too.

Like EUI-64?  https://standards.ieee.org/develop/regauth/tut/eui.pdf

Lee

Re: Companies using public IP space owned by others for internal routing

[Lee Howard]

On 12/19/17, 8:50 PM, "NANOG on behalf of Owen DeLong"
<nanog-boun...@nanog.org on behalf of o...@delong.com> wrote:

>
>> On Dec 19, 2017, at 07:39 , Livingood, Jason
>><jason_living...@comcast.com> wrote:
>> 
>> On 12/18/17, 2:36 PM, "NANOG on behalf of Harald Koch"
>><nanog-boun...@nanog.org on behalf of c...@pobox.com> wrote:
>>> They could use IPv6. I mean, if the mobile phone companies can figure
>>>it out, surely an ISP can...
>> 
>> Except for cases when it is impossible or impractical to update
>>software on a great number of legacy devices…
>> 
>> JL
>> 
>> 
>Yeah, in those cases, they should use IPv6 + NAT64 or similar mechanism.

I’m a fan of IPv6-only plus translation, but not in this case.
If I have a functioning management network that’s mostly in IPv6 and
partly in rfc1918 space (or even squatted space), I don’t get much out of
NAT64. Renumbering the servers that actually touch/manage devices gets,
what, a /29 of IPv4 addresses? Better to focus on evolving to whatever
will replace those legacy devices.

Lee 

>
>Owen
>
>

Re: Companies using public IP space owned by others for internal routing

[Lee Howard]

On 12/19/17, 11:52 PM, "NANOG on behalf of Mark Andrews"
<nanog-boun...@nanog.org on behalf of ma...@isc.org> wrote:

>
>> On 20 Dec 2017, at 2:39 am, Livingood, Jason
>><jason_living...@comcast.com> wrote:
>> 
>> On 12/18/17, 2:36 PM, "NANOG on behalf of Harald Koch"
>><nanog-boun...@nanog.org on behalf of c...@pobox.com> wrote:
>>> They could use IPv6. I mean, if the mobile phone companies can figure
>>>it out, surely an ISP can...
>> 
>> Except for cases when it is impossible or impractical to update
>>software on a great number of legacy devices…
>> 
>> JL
>
>You mean devices where the manufacture ignore IPv6 and shipped you a dud.
> Even devices with a 15 year life cycle should be IPv6 capable today.

“should” doesn’t buy developer cycles, especially for EOL products or from
bankrupt vendors.

You deal with the network you have, upgrade what you can, and replace the
rest as fast as you can while doing what it takes to stay in business.

Lee

Re: Free access to measurement network

[Lee]

On 12/16/17, Mike Hammett <na...@ics-il.net> wrote:
> That project was paid for by ARRA funds and ran out.
>
> The FCC picked up the ball by expanding the scope of its 477 program. That
> data is available directly on their site or via some sites like
> broadbandnow.com

I didn't know about that - thanks.  But it just confirms what I
thought; my choices are comcast & verizon.   There is another
possibility, but $350/mo for 10Mb/s with a 24 month contract is too
steep.

> There are also many service providers available that aren't filing because
> either A) they don't know about it or B) government stuff.
>
> My point was that consumers voted out thousands of independents by taking
> service from incumbents instead of independents. Thousands have closed up
> shop. Where independents are available, it's still tough getting customers
> if the incumbents have a service that mostly works (over say 5 to 10 megs),
> even if the independent offers service comparable to the incumbent's
> advertisements.

As a consumer, how much extra are you willing to pay for good service?
 Because I'm guessing that's about all a small independent can offer
that's better than the local (mono|duo)poly.  So while I think I get
your point, I see it more as consumers voting with their wallets
rather than voting out independents.

Regards,
Lee

>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
>
> Midwest Internet Exchange
>
> The Brothers WISP
>
> - Original Message -
>
> From: "Lee" <ler...@gmail.com>
> To: "Mike Hammett" <na...@ics-il.net>
> Cc: nanog@nanog.org
> Sent: Saturday, December 16, 2017 2:16:38 PM
> Subject: Re: Free access to measurement network
>
> On 12/16/17, Mike Hammett <na...@ics-il.net> wrote:
>> It's a consumer thing. If consumers wanted more options, they would be
>> supporting those options with their wallets. They don't.
>
> As far as I know, my options for >50Mb/s are comcast and verizon.
>
> https://www.broadbandmap.gov/ sez
> Please note: National Broadband Map data is from June 30, 2014 and is
> no longer being updated.
>
> How do I find out what my other options are?
>
> Thanks,
> Lee
>
>>
>> -
>> Mike Hammett
>> Intelligent Computing Solutions
>>
>> Midwest Internet Exchange
>>
>> The Brothers WISP
>>
>> - Original Message -
>>
>> From: "Max Tulyev" <max...@netassist.ua>
>> To: nanog@nanog.org
>> Sent: Saturday, December 16, 2017 4:43:54 AM
>> Subject: Re: Free access to measurement network
>>
>> So for my point of view, better solution is to push some law that ease
>> access to the buildings for ISPs.
>>
>> 15.12.17 19:40, valdis.kletni...@vt.edu пише:
>>> On Fri, 15 Dec 2017 07:47:42 -0500, Dovid Bender said:
>>>> What kind of internet are these devices on? With Net Neutrality gone
>>>> here
>>>>
>>>> in the US it would be a good way to measure certain services such as SIP
>>>>
>>>> to
>>>> see which ISP's if any are tampering with packets.
>>>
>>> Given previous history, the answer will probably be "most of them".
>>>
>>> "The results are not inspiring. More than 129 million people are limited
>>>
>>> to a
>>> single provider for broadband Internet access using the FCC definition of
>>>
>>> 25
>>> Mbps download and 3 Mbps upload. Out of those 129 million Americans,
>>> about
>>> 52
>>> million must obtain Internet access from a company that has violated
>>> network
>>> neutrality protections in the past and continues to undermine the policy
>>>
>>> today.
>>>
>>> In locations where subscribers have the benefit of limited competition,
>>> the
>>> situation isn't much better. Among the 146 million Americans with the
>>> ability
>>> to choose between two providers, 48 million Americans must choose between
>>>
>>> two
>>> companies that have a record of violating network neutrality."
>>>
>>> https://muninetworks.org/content/177-million-americans-harmed-net-neutrality
>>>
>>>
>>>
>>
>>
>
>

Re: Free access to measurement network

[Lee]

On 12/16/17, Mike Hammett <na...@ics-il.net> wrote:
> It's a consumer thing. If consumers wanted more options, they would be
> supporting those options with their wallets. They don't.

As far as I know, my options for >50Mb/s are comcast and verizon.

https://www.broadbandmap.gov/ sez
 Please note: National Broadband Map data is from June 30, 2014 and is
no longer being updated.

How do I find out what my other options are?

Thanks,
Lee

>
> -
> Mike Hammett
> Intelligent Computing Solutions
>
> Midwest Internet Exchange
>
> The Brothers WISP
>
> - Original Message -
>
> From: "Max Tulyev" <max...@netassist.ua>
> To: nanog@nanog.org
> Sent: Saturday, December 16, 2017 4:43:54 AM
> Subject: Re: Free access to measurement network
>
> So for my point of view, better solution is to push some law that ease
> access to the buildings for ISPs.
>
> 15.12.17 19:40, valdis.kletni...@vt.edu пише:
>> On Fri, 15 Dec 2017 07:47:42 -0500, Dovid Bender said:
>>> What kind of internet are these devices on? With Net Neutrality gone here
>>>
>>> in the US it would be a good way to measure certain services such as SIP
>>> to
>>> see which ISP's if any are tampering with packets.
>>
>> Given previous history, the answer will probably be "most of them".
>>
>> "The results are not inspiring. More than 129 million people are limited
>> to a
>> single provider for broadband Internet access using the FCC definition of
>> 25
>> Mbps download and 3 Mbps upload. Out of those 129 million Americans, about
>> 52
>> million must obtain Internet access from a company that has violated
>> network
>> neutrality protections in the past and continues to undermine the policy
>> today.
>>
>> In locations where subscribers have the benefit of limited competition,
>> the
>> situation isn't much better. Among the 146 million Americans with the
>> ability
>> to choose between two providers, 48 million Americans must choose between
>> two
>> companies that have a record of violating network neutrality."
>>
>> https://muninetworks.org/content/177-million-americans-harmed-net-neutrality
>>
>>
>
>

Re: F Y I

[Lee Howard]

 


On 10/17/17, 5:33 PM, "NANOG on behalf of Christopher Morrow"
<nanog-boun...@nanog.org on behalf of morrowc.li...@gmail.com> wrote:

>you know, the Sci-Hub folk could fix this themselves... with some
>authentication requirements... and probably by just unplugging from the
>intertubes?

"Sci-Hub’s founder, has previously told The Scientist the site plans to
ignore the lawsuit.” How would Sci-Hub consider this a “fix”?

What enforcement mechanism would the Court have against Sci-Hub?

The idea of making third parties (ISPs) incur costs (updating ACLs or
poisoning DNS) to enforce the order is pretty bad, and doesn’t stop Tor
access. Sorry I didn’t have a chance to file an amicus before the ruling
tomorrow.



Lee


>
>On Tue, Oct 17, 2017 at 5:04 PM, Robert Mathews (OSIA)
><math...@hawaii.edu>
>wrote:
>
>>
>> Judge Recommends Ruling to Block Internet Access to Sci-Hub
>> The American Chemical Society seeks a broad order that includes millions
>> of dollars in damages and demands action from Internet service providers
>> and search engines.
>> By Diana Kwon | October 4, 2017
>>
>> http://www.the-scientist.com/?articles.view/articleNo/50563/
>> title/Judge-Recommends-Ruling-to-Block-Internet-Access-to-Sci-Hub/
>> http://www.the-scientist.com/?articles.view/articleNo/50361/
>> title/Publishers--Legal-Action-Advances-Against-Sci-Hub/
>>
>

Re: 4 or smaller digit ASNs

[Lee Howard]

> On Oct 12, 2017, at 1:01 AM, James Breeden <ja...@arenalgroup.co> wrote:
> 
> Hello NANOG...
> 
> I have a client interested in picking up a new AS number but they really want 
> it to be 3 or 4 digits in length.
> 
> Is there a process to request this from ARIN, or doss anyone know of unused 
> ASns fitting this that anyone is looking to sell for some quick cash?
> 

It's part of the ARIN transfer process, 
https://www.arin.net/policy/nrpm.html#eight specific 8.3, "IPv4 numbers 
resources and ASNs may be transferred according to the following conditions."

ARIN has a Specified Transfer Listing Service, 
https://www.arin.net/resources/transfer_listing/index.html so you could check 
there.
I didn't see any ASNs listed, so you may need to call a broker, such as one 
listed under 
https://www.arin.net/resources/transfer_listing/facilitator_list.html

A list of ASNs that have been transferred policy can be found at 
https://www.arin.net/public/transferLog.xhtml#NRPM-8.3ASNs



> Thanks!
> James
> 

Hope that helps,

Lee

> 
> 
> 
> Sent via the Samsung Galaxy S7 active, an AT 4G LTE smartphone

Re: DHCPv6-PD -> Lack of route injection in RFC

[Lee Howard]

On 9/23/17, 1:51 AM, "nanog-boun...@nanog.org on behalf of
valdis.kletni...@vt.edu" <nanog-boun...@nanog.org on behalf of
valdis.kletni...@vt.edu> wrote:

>On Sat, 23 Sep 2017 08:47:32 +1000, Mark Andrews said:
>> You know CPE devices are routers.  They can tell you what routes
>> DHCP has given them.  That annoucement could be cryptographically
>> authenticated.
>
>This is, of course, a lot easier if the CPE already has onboard the needed
>software to do that, or you have the ability to push it out.

Right. How many residential market gateways support any routing protocol
at all? How many support RIPv2? How many support RIPng. Being routers does
not mean they support any dynamic routing protocol. If I were an ISP, I
would be very skeptical of the return on adding routing support to every
gateway I supported, plus an RPKI.

>
>Is anybody from Comcast or other eyeball network willing to say (even
>roughly)
>what percent of CPE is gear they supply, versus gear that people get at
>Best
>Buy or Walmart and just plug in, versus (if they can identify it) gear
>that's
>been reflashed by clued customers?

It varies 0-100% based on network, year, and the mood of whoever makes the
decision about how to handle CPE. Some ISPs provide a gateway to all of
their customers, and some of those customers then put them into bridged
mode. (I think Vz FiOS, for instance, always comes with a gateway). Some
provide a gateway for free, which may be worth much more or less than you
paid for it, depending on the philosophy of the ISP. Some assume you want
a gateway and charge you several dollars a month for it.

Lee

Re: IPv6 migration steps for mid-scale isp

[Lee Howard]

On 9/23/17, 7:14 AM, "NANOG on behalf of Fredrik Sallinen"
<nanog-boun...@nanog.org on behalf of fredrik.salli...@gmail.com> wrote:

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

Should work fine in landline networks, but (as Jordi says) it’s hard to
find support in retail CPE your customers are likely to own. Same is true
for MAP-T and MAP-E.

If anyone knows of retail CPE supporting any of those, or if you’re a
gateway vendor selling those, let me know, I’m interested.

Lee

>
>On Mon, Sep 18, 2017 at 10:28 PM, JORDI PALET MARTINEZ
><jordi.pa...@consulintel.es> 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-w
>>ith-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 <nanog-boun...@nanog.org> en nombre de Brock Tice
>><br...@bmwl.co>
>> Responder a: <br...@bmwl.co>
>> Fecha: viernes, 15 de septiembre de 2017, 17:14
>> Para: Fredrik Sallinen <fredrik.salli...@gmail.com>
>> CC: <nanog@nanog.org>
>> 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: DHCPv6-PD -> Lack of route injection in RFC

[Lee Howard]

On 9/22/17, 3:12 AM, "NANOG on behalf of Steve Teusch"
<nanog-bounces+lee=asgard@nanog.org on behalf of
steve.teu...@rtr.guru> wrote:

>I am running into venders that do not support injection of a delegated
>route when operating as a DHCPv6 relay (or server for that matter).
>Brocade supports this, but I am not finding this as part of any of the
>RFC's.  This is to deliver home ISP service, so it is very important or
>return packets won't go to the client unless the route is manually added
>as a routing protocol is not an option.  There should be a MUST activity
>for this somewhere.
>
>Anyone know what gives?


Well, it’s weird for a DHCPv6 relay process to inspect relayed Reply
messages and use them to update the routing table. Weird, but I’ve done it.
What origin type do you use for that route?  Static, really?

This behavior was requested by operators who needed it; I don’t remember
whether we even went to the IETF with it. I think descriptions exist in
CableLabs IPv6 docs; maybe in BBF docs, too.

Any vendor who doesn’t do it is in the process of shutting down their ISP
access router business.

Lee

Re: IPv6 migration steps for mid-scale isp

[Lee Howard]

On 9/13/17, 8:08 AM, "NANOG on behalf of Fredrik Sallinen"
<nanog-boun...@nanog.org on behalf of fredrik.salli...@gmail.com> 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?

Dual-stack is the best way to get to IPv6-only. You’ll need IPv6-only in
order to solve the IPv4 runout problem, though “only” is likely to include
translation.

>Where to start with IPv6? (core, edge or ...)

Web site.
Then core and peering.
Then push toward regional networks. You’ll need IPv6 into at least the
part of your data center does provisioning and monitoring.
Then start pushing to customers.

>What are the best practices for ISPs?

Lots of documents exist. Here’s one: https://tools.ietf.org/html/rfc6782


>What are the costs and return on investment?

Oh, I have so much to say on this topic. Search for “TCO of CGN” and “TCO
of IPv6” to find it.
You should have very little incremental capital cost; that is, you
shouldn’t have to buy new hardware, because practically anything less than
ten years old can support IPv6. Whether it *does* is a question.
You’ll have some opex network engineering costs in testing and deployment,
which might be high(ish) if you have a lot of different equipment in your
network. Your biggest cost is likely to be the development labor to update
your IPAM, provisioning systems, management, logging, and tech support
tools to be able to store and use the new address format. Development is
likely to be what takes longest, so that’s really the place to start.

The return on investment is that you don’t have to spend $15 to buy an
IPv4 address for every new user you have to sign up. Or $25 per address in
2019, if trends continue. [1]
Depending on how happy you are with your transition mechanism (NAT64,
464xlat, MAP, etc.) you could, instead, sell off those IPv4 addresses.
“Hey, boss, we’ll turn up 10,000 new customers in 2019, right? We can
either spend $250,000 to buy addresses, or we can put 10% of our customers
behind NAT64 (or whatever) and sell their IPv4 addresses for $25 each.”
(Dozens of NANOGers laugh, a few cock their heads and think “maybe…”).

>How to identify address CPE and legacy application issues?

How do you do it now?
I’m guessing you test CPE that you provide, at least for basic
functionality. 
Some bugs still get past you. A few customers call, you notice a trend
among customers with X CPE that they have a problem in the area where you
just rolled out IPv6. You roll back IPv6 in that area or (hopefully) just
from those devices, and put that CPE in the lab and test the heck out of
it.

For legacy applications, it depends on the application. If you can update
it, that’s the best answer. Or you can put a NAT64 box in front of it (on
a VM, router, firewall, or load balancer—you don’t necessarily need new
hardware). But there’s also the entire rest of the old Internet: you will
probably want to have some kind of transition mechanism in place.

I know folks who specialize in transition mechanisms; I’ll follow up
privately so this doesn’t look like a sales pitch on the list.


>
>Fredrik
>

Lee


[1] Charts, using IPv4auctions.com (Hilco Streambank) data:
http://www.wleecoyote.com/blog/2017prices.htm

Re: IPv6 Loopback/Point-to-Point address allocation

[Lee Howard]

On 9/9/17, 12:06 PM, "NANOG on behalf of Kody Vicknair"
<nanog-boun...@nanog.org on behalf of kvickn...@reservetele.com> wrote:

>All,
>
>I’ve been doing some reading in preparation of IPv6 deployment and
>figuring out how we will break up our /32. I think I’m on the right track
>in thinking that each customer will be allocated a /48 to do whatever
>they wish with it.

Yes.

>
>I’ve read recent BCOP drafts that have been approved by the IETF:
>https://www.ripe.net/publications/docs/ripe-554

BCOP isn’t an IETF BCP. But that’s a really minor detail; BCOPs much
better operator input than most IETF activities (IMHO, as an active IETF
participant).

>It looks like the smallest subnet that should ever be assigned is a /64
>on a particular link.
>
>
>Some questions that come to mind with IPv6:
>
>In regards to Point to point links my thinking is this:
>Assign a unique /64 to each point to point link with these addresses
>being Globally routable. This seems to be what our IX providers do when
>assigning us an IPv6 address. Am I correct in this train of thought?
>Why/Why not?

Yes, the general guidance is to reserve a /64 for the link and configure a
very small subnet (like /127) on the interfaces, to avoid a ping-pong
attack.

>
>In regards to core loopback addressing my initial thoughts are as follows:
>Assign a single /64 encompassing all /128’s planned for loopback
>addressing schemes. Should I be using Unique Local addressing for
>loopbacks instead of going with a Globally routeable addressing scheme?
>Should each interface IP configuration have a /64 or a /128?

You can use ULAs for this; I know of a moderately sized network that does.
I think most people still use GUA. You’re not wrong either way, though I
know some people get emotional about ULA.

>
>Also when talking about CPE mgmt addresses what do you think is a
>practical way of going about assigning “Private” addressing schemes for
>cpe management purposes.

Reserve another block from your /32 and route it separately.
As somebody else said, if you find you’re running out of address space in
IPv6, there’s no shame in requesting more than a /32.

>
>I’m sure some of these questions will be answered when I dive deeper into
>how OSPFv6 works as well as BGP in regards to IPv6.

Maybe, but don’t panic. It’s not significantly harder in IPv6 than in
IPv4. 

>
>Are any of you currently running IPv6 and wished you had done something
>differently during the planning phase that may have prevented headaches
>down the road?

I always tell people: you’re going to rewrite your address plan three
times. Do what you can with it, then start deploying through the network.
You’ll see what changes you need to make once you know how your network is
unique.

I wish I’d pushed harder for /48s for customers from the beginning, even
though we would’ve needed more address space. I wish I’d started sooner,
but more than that I wish my vendors had started sooner, especially CPE
vendors.

I wish I had just replaced broken equipment rather than working around it.

I wish I had had better monitoring of both IPv4 and IPv6 specific systems,
so I could tell when one address family failed.

I wish I had been able to plan my transition technology earlier, so I
could move from dual-stack to IPv6.


Lee



>
>
>
>
>Kody Vicknair
>Network Engineer
>
>
>[cid:imagebf3343.JPG@c9d2fbd2.4db10e0d] <http://www.rtconline.com>
>
>Tel:985.536.1214
>Fax:985.536.0300
>Email:  kvickn...@reservetele.com
>Web:www.rtconline.com
>
>Reserve Telecommunications
>100 RTC Dr
>Reserve, LA 70084
>
>
>
>
>
>Disclaimer:
>The information transmitted, including attachments, is intended only for
>the person(s) or entity to which it is addressed and may contain
>confidential and/or privileged material which should not disseminate,
>distribute or be copied. Please notify Kody Vicknair immediately by
>e-mail if you have received this e-mail by mistake and delete this e-mail
>from your system. E-mail transmission cannot be guaranteed to be secure
>or error-free as information could be intercepted, corrupted, lost,
>destroyed, arrive late or incomplete, or contain viruses. Kody Vicknair
>therefore does not accept liability for any errors or omissions in the
>contents of this message, which arise as a result of e-mail transmission.
>

Re: ISP billing - data collection, correlation, and billing

[Lee Howard]

On 7/14/17, 2:47 PM, "NANOG on behalf of Luke Guillory"
<nanog-boun...@nanog.org on behalf of lguill...@reservetele.com> wrote:

>On the HFC / CMTS side of things we have IPDR which I believe has some
>open source collectors out there. I'm not sure that IPDR is used much
>outside of the HFC world though.

IPDR was my first thought as an alternative to SNMP. Is its accuracy
comparable? It’s been included into TR-069, so it’s theoretically
available to telcos, too. And usage-based billing is part of it’s purpose.


Not sure I’d want to use NetFlow/IPFIX, since by nature it tracks flows,
not bits, and I don’t want to record flows. But I’d be interested in
hearing others’ experience.


Lee

Re: Some advice on IPv6 planning and ARIN request, please

[Lee Howard]

On 7/7/17, 1:07 PM, "NANOG on behalf of Oliver O'Boyle"
<nanog-boun...@nanog.org on behalf of oliver.obo...@gmail.com> wrote:

> We're currently in the planning stage and can make
>whatever changes we need to.

I always say to just expect you’ll change your address plan three times.
Some people say, “I’ve only changed the address plan twice. . . so far.”

>
>Situation:
>
>We're an end-user org and qualify for a /40 assignment because we operate
>over 60 sites and some of those are/will be multihomed. We manage hotels
>in
>Canada only, but from coast to coast to coast and everywhere in between.
>Our corporate network and org structure is optimized for three regions. We
>also have, and continue to grow into, cloud infrastructure and foresee
>wanting to bring our own addresses (.e.g., to AWS VPC when that option
>becomes available). As such, an obvious design strategy would be to break
>the /40 into 4 x /42's. However, due to an imbalance in national site
>distribution, 50% of our sites are located in one region (Region A).
>Additionally, historical and forecasted growth indicates that it's
>perfectly reasonable for us to expect growth of an additional 16 sites in
>that same region over the next 3-5 years.

Even assuming, as you said: a /48 per hotel, it sounds like you’re
planning for:
Region A, 45 sites, minimum /42
Region B, <20 sites, minimum /44
Region C, <20 sites, minimum /44
Cloud stuff, minimum /48, but that might need more

However, as others have suggested, you might want to start from the
bottom, deciding the allocations within each hotel. It may be that you
need multiple /48s for HotelGuest, HotelLobby, HotelConference, and
HotelStaff SSIDs. 
A /64 per WiFi AP is an aboslute minimum, but a prefix per room (or guest)
would be better, and there are reasons to consider /56 and /48 per “end
user” in the hotel. Even if you can’t assign it with current WiFi
technology, your address plan should allow for an evolution to a better
way of doing things.
If my math works right, and you have between 127 and 255 rooms in a hotel:
255 * /56 = /48 just for HotelGuest. You may need a /44 per hotel, if
there are four separate networks.
Or:
255 * /48 = /40 just for HotelGuest. You may need a /36 per hotel.

As others have said, I’m assuming you treat guests to whom you provide
Internet service as customers.


>
>I think the ideal situation is out as ARIN policy wouldn't allow them to
>assign us a /36 at this time. Unless someone knows something that can help
>us here.

Try calling ARIN. Ask a hostmaster whether the End User or ISP category
makes more sense in your case. It’s also possible they’ll say “slow start”
and give you a /40 for your first hotel, and tell you to return in a week
when you need more.

But also, take into account [NRPM 6.5.8.2] "Requests forlarger
initial assignments, reasonably justified with supporting
documentation, will be evaluated based on the number of sites in an
organization’s network and the number of subnets needed to support any
   extra-large sites defined below.” There’s a lot of room within
policy to do sensible things with IPv6.

>
>Assuming we can't get a /36, my feeling is that less ideal situation #2 is
>better than #3 is better than #1 is better than #4, assuming we're
>following the following design best-practices:
>
>a) assign top-level aggregations evenly (which we'd be breaking a bit with
>option #2)
>b) reduce global routes as much as possible
>c) stay on the nibble boundary as much as possible
>d) default to /48 per site

Yes, all good goals. But none is critical to the success of your network
(except c, only if you plan to delegate reverse DNS). “As much as
possible” also implies “and no more than is possible.”

>
>Thanks in advance,
>Oliver


btw, I can’t wait to stay in your hotels once they have IPv6! I hope
you’ll be able to tweet or post here when it’s deployed, so we can
congratulate you, and maybe get some conferences to consider you as a
venue.

Lee

Re: IPv6 traffic percentages?

[Lee Howard]

On 6/22/17, 3:00 AM, "NANOG on behalf of Radu-Adrian Feurdean"
<nanog-boun...@nanog.org on behalf of na...@radu-adrian.feurdean.net>
wrote:

>On Thu, Jun 22, 2017, at 08:18, Mukom Akong T. wrote:
>> 
>> On 18 June 2017 at 17:36, Radu-Adrian Feurdean <nanog@radu-
>> adrian.feurdean.net> wrote:>> so for the record, business customers are
>>much more active in
>>>  *rejecting* IPv6, either explictely (they say they want it
>>>  disabled) or>>  implicitly (they install their own router, not
>>>configured for
>>>  IPv6). The>>  bigger the business, the bigger the chance of rejection.
>> 
>> 
>> Did they per chance state their reasons for rejecting it?
>
>Not explicitly. But when we get something like "turn off that IPv6 crap
>!" we take it for: - they don't have a clearly defined need for it
> - they don't know how to deal with it
> - they don't want to deal with things they don't need (see the
>   irst point)... usually all of them at the same time.

That is my experience, too. When I was in IT, my response was to block
IPv6 at the firewall (until I learned my firewall was incapable of
examining IPv6 packets and therefore allowed ALL IPv6; I wasn’t allowed to
change firewalls so I used a router ACL to block it while I reviewed our
IPv6 security policy and looked for another job). When I was at an ISP, we
could route IPv6 to the customer, but until they enabled it, no traffic
would follow.

>
>To make it short : education. And we as as small ISP we have neither the
>resources, nor the motivation (because $$$ on the issue is negative) to
>do it (the education).

I think you’re talking about business education, not technical IPv6
education, right?
I recently posted my suggested technical reading list:
http://www.wleecoyote.com/blog/IPv6reading.html

But I think you’re asking for a business education series that goes:
1. Enterprise business consideration of IPv6
   a. It’s already on your network. All computers, tablets and phones have
at least Link Local, and some set up tunnels. Plus, if your employees have
dual-stack at home but single—stack VPN, you may not like your split
tunnel.
   b. Lower latency.
   c. Using IPv6 in interesting ways, like Segment Routing, Terastream bit
masking, IPv6 address as process ID.
   d. IPv4 runout doesn’t matter much to most enterprises. They only need
a couple of addresses for new branch offices. Those enterprises who have
their own IPv4 address block (from RIR, not ISP/LIR) should consider how
much they could sell it for. At $15/address, a /16 approaches US$1
million, which is real money to most CTOs.
http://www.wleecoyote.com/blog/2017prices.htm

2. Enterprise IPv6 implementation guidance
  a. https://tools.ietf.org/html/rfc7381  “Enterprise IPv6 Deployment
Guidelines” 
  b. Cost to Renumber and Sell IPv4
http://retevia.net/Downloads/EnterpriseRenumbering.pdf


I’ll see if I can write up #1 into a single paper or blog post in the next
few days. Anything else I should add?

Lee

>

Re: 10G switch drops traffic for a split second

[Lee]

On 11/30/16, Mikael Abrahamsson <swm...@swm.pp.se> wrote:
> On Tue, 29 Nov 2016, TJ Trout wrote:
>
>> Is it possible to over run the buffers of a 320gbps backplane switch
>> with only 1.5gbps traffic? I think the switch is rated for 140m PPS and
>> I'm only pushing 100k PPS
>
> If your switch is the typical small-buffered-switch that has become more
> and more common the past few years, then the entire switch might have
> buffer to keep packets for 0.1ms or less. So if someone says "flow control
> off" for 0.1ms, depending on the implementation, you might then start
> seeing packet drops on all ports until that device turns flow control
> back on.

I always disabled flow control on the theory that VoIP & flow control
are incompatible.
just out of curiosity - anyone have it enabled?  if so, why?

Lee

Re: Oracle buys... Dyn.

[Lee Fuller]

Yes false. Amazon do use dyn + others for their own domains in addition to
their own Route 53 but Route 53 itself is a completely separate service.

Kind Regards

Lee Fuller (mobile)
PGP: 4F58 D91E 3886 2AAA 26F5 17BD FA12 7914 8308 45D0

On 21 Nov 2016 6:16 pm, "Eli Lindsey" <e...@siliconsprawl.com> wrote:

> > On Nov 21, 2016, at 11:22, Akshay Kumar <aks...@mongodb.com> wrote:
> >
> > Route53 just uses Dyn and Ultra. I would expect AWS to roll out their
> own soon.
>
> This is completely false.
>
> -eli
>

Re: pay.gov and IPv6

[Lee]

On 11/17/16, Carl Byington <c...@five-ten-sg.com> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On Thu, 2016-11-17 at 15:32 -0500, Lee wrote:
>> That's fine, but until someone is willing to work with them don't
>> expect it to get fixed.
>
> I am working with pay.gov.c...@clev.frb.org, trying to explain the
> problem. They seem to think I should provide "application name and ID"
> before they can research this.

They probably want that so they know where to route the ticket.  I
pointed them at
  https://tools.ietf.org/html/rfc4890#page-14
and suggested they have someone on the network team use ipv6 to
connect to pay.gov over a 1280 byte MTU link.  Hopefully that's enough
to get the ticket routed to the correct group.

> I responded as below. I will let you know
> if there is any progress on this.

I'd appreciate that.
And thanks for being willing to work with them to fix the problem.

Lee


> It is 100% reproducible here - and
> should be reproducible from anywhere with a slightly smaller than normal
> MTU.
>
>
>
> We try to get to https://www.pay.gov/public/home - which fails. I
> presume that is before there is any application name or ID.
>
> Try to reach that page from a browser on a machine with ipv6
> connectivity that goes thru a tunnel with a 1300 byte MTU. It will fail.
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.14 (GNU/Linux)
>
> iEYEAREKAAYFAlguP8oACgkQL6j7milTFsFgrQCfY2QLE0njiSRIILTzR4Fjpk3c
> F3AAnjZj8+3W51Qr9e1oGWAxrUC8Pnf3
> =UpN0
> -END PGP SIGNATURE-
>
>
>

Re: pay.gov and IPv6

[Lee]

On 11/17/16, Matthew Kaufman <matt...@matthew.at> wrote:
> I sent email there and to another contact I had at the time.

and the response was?

> And I'm not going to break my users by turning IPv6 back on, so someone
> else will need to work with them.

That's fine, but until someone is willing to work with them don't
expect it to get fixed.

Regards,
Lee


>
> Matthew Kaufman
>
> On Thu, Nov 17, 2016 at 9:48 AM Lee <ler...@gmail.com> wrote:
>
>> On 11/16/16, Matthew Kaufman <matt...@matthew.at> wrote:
>> > The good news is that I reported this particular site as a problem two
>> and
>> > three years ago, both, and it isn't any worse.
>>
>> did you contact Pay.gov Customer Service at:
>> 800-624-1373 <(800)%20624-1373> (Toll free, Option #2)
>> or send an email to
>> pay.gov.c...@clev.frb.org
>>
>> I just called, but I can't duplicate the problem and they need to work
>> with someone that is having a problem reaching the site.
>>
>> Regards,
>> Lee
>>
>>
>> >
>> > Matthew Kaufman
>> > On Wed, Nov 16, 2016 at 6:29 PM Mark Andrews <ma...@isc.org> wrote:
>> >
>> >>
>> >> In message <cc8936b2-1396-4375-85aa-a0247fd78...@consulintel.es>,
>> >> JORDI
>> >> PALET M
>> >> ARTINEZ writes:
>> >> > I think it is not just a matter of testing behind a 1280 MTU, but
>> about
>> >> makin
>> >> > g sure that PMTUD is not broken, so it just works in any
>> circumstances.
>> >> >
>> >> > Regards,
>> >> > Jordi
>> >>
>> >> If you don't do MSS fix up a 1280 link in the middle will find PMTUD
>> >> issues
>> >> provided the testing host has a MTU > 1280.
>> >>
>> >> Mark
>> >>
>> >> > -Mensaje original-
>> >> > De: NANOG <nanog-boun...@nanog.org> en nombre de Mark Andrews <
>> >> ma...@isc.org>
>> >> > Responder a: <ma...@isc.org>
>> >> > Fecha: jueves, 17 de noviembre de 2016, 9:26
>> >> > Para: Lee <ler...@gmail.com>
>> >> > CC: <nanog@nanog.org>
>> >> > Asunto: Re: pay.gov and IPv6
>> >> >
>> >> >
>> >> > In message
>> >> <cad8gwsvetsmn1ssfk_adttkheog0e1zfxrld11fpkbpjghm...@mail.gmai
>> >> > l.com>
>> >> > , Lee writes:
>> >> > > On 11/16/16, Mark Andrews <ma...@isc.org> wrote:
>> >> > > >
>> >> > > > In message <1479249003.3937.6.ca...@ns.five-ten-sg.com>,
>> >> > Carl
>> >> Byingto
>> >> > n
>> >> > > > writes
>> >> > > > :
>> >> > > >> -BEGIN PGP SIGNED MESSAGE-
>> >> > > >> Hash: SHA512
>> >> > > >>
>> >> > > >> Following up on a two year old thread, one of my clients
>> >> > just
>> >> hit th
>> >> > is
>> >> > > >> problem. The failure is not that www.pay.gov is not
>> reachable
>> >> over i
>> >> > pv6
>> >> > > >> (2605:3100:fffd:100::15). They accept (TCP handshake) the
>> port
>> >> 443
>> >> > > >> connection, but the connection then hangs waiting for the
>> >> > TLS
>> >> handsh
>> >> > ake.
>> >> > > >>
>> >> > > >> openssl s_client -connect www.pay.gov:443
>> >> > > >>
>> >> > > >> openssl s_client -servername www.pay.gov -connect
>> >> 199.169.192.21:443
>> >> > > >>
>> >> > > >> Browsers (at least firefox) see that as a very slow site,
>> >> > and
>> >> it doe
>> >> > s
>> >> > > >> not trigger their happy eyeballs fast failover to ipv4.
>> >> > > >
>> >> > > > Happy eyeballs is about making the connection not whether
>> >> > TCP
>> >> > > > connections work after the initial packet exchange.
>> >> > > >
>> >> > > > I would send a physical letter to the relevent Inspector
>> >> > General
>> >

Re: pay.gov and IPv6

[Lee]

On 11/16/16, Matthew Kaufman <matt...@matthew.at> wrote:
> The good news is that I reported this particular site as a problem two and
> three years ago, both, and it isn't any worse.

did you contact Pay.gov Customer Service at:
800-624-1373 (Toll free, Option #2)
or send an email to
pay.gov.c...@clev.frb.org

I just called, but I can't duplicate the problem and they need to work
with someone that is having a problem reaching the site.

Regards,
Lee


>
> Matthew Kaufman
> On Wed, Nov 16, 2016 at 6:29 PM Mark Andrews <ma...@isc.org> wrote:
>
>>
>> In message <cc8936b2-1396-4375-85aa-a0247fd78...@consulintel.es>, JORDI
>> PALET M
>> ARTINEZ writes:
>> > I think it is not just a matter of testing behind a 1280 MTU, but about
>> makin
>> > g sure that PMTUD is not broken, so it just works in any circumstances.
>> >
>> > Regards,
>> > Jordi
>>
>> If you don't do MSS fix up a 1280 link in the middle will find PMTUD
>> issues
>> provided the testing host has a MTU > 1280.
>>
>> Mark
>>
>> > -Mensaje original-
>> > De: NANOG <nanog-boun...@nanog.org> en nombre de Mark Andrews <
>> ma...@isc.org>
>> > Responder a: <ma...@isc.org>
>> > Fecha: jueves, 17 de noviembre de 2016, 9:26
>> > Para: Lee <ler...@gmail.com>
>> > CC: <nanog@nanog.org>
>> > Asunto: Re: pay.gov and IPv6
>> >
>> >
>> > In message
>> <cad8gwsvetsmn1ssfk_adttkheog0e1zfxrld11fpkbpjghm...@mail.gmai
>> > l.com>
>> > , Lee writes:
>> > > On 11/16/16, Mark Andrews <ma...@isc.org> wrote:
>> > > >
>> > > > In message <1479249003.3937.6.ca...@ns.five-ten-sg.com>, Carl
>> Byingto
>> > n
>> > > > writes
>> > > > :
>> > > >> -BEGIN PGP SIGNED MESSAGE-
>> > > >> Hash: SHA512
>> > > >>
>> > > >> Following up on a two year old thread, one of my clients just
>> hit th
>> > is
>> > > >> problem. The failure is not that www.pay.gov is not reachable
>> over i
>> > pv6
>> > > >> (2605:3100:fffd:100::15). They accept (TCP handshake) the port
>> 443
>> > > >> connection, but the connection then hangs waiting for the TLS
>> handsh
>> > ake.
>> > > >>
>> > > >> openssl s_client -connect www.pay.gov:443
>> > > >>
>> > > >> openssl s_client -servername www.pay.gov -connect
>> 199.169.192.21:443
>> > > >>
>> > > >> Browsers (at least firefox) see that as a very slow site, and
>> it doe
>> > s
>> > > >> not trigger their happy eyeballs fast failover to ipv4.
>> > > >
>> > > > Happy eyeballs is about making the connection not whether TCP
>> > > > connections work after the initial packet exchange.
>> > > >
>> > > > I would send a physical letter to the relevent Inspector
>> > General
>> > > > requesting that they ensure all web sites under their
>> juristiction
>> > > > that are supposed to be reachable from the public net get
>> > audited
>> > > > regularly to ensure that IPv6 connections work from public IP
>> space.
>> > >
>> > > That will absolutely work.
>> > >
>> > > NIST is still monitoring ipv6 .gov sites
>> > >   https://usgv6-deploymon.antd.nist.gov/cgi-bin/generate-gov
>> >
>> > Which show green which means that the tests they are doing are not
>> > sufficient.  They need to test from behind a 1280 mtu link.
>> >
>> > The DNSSEC testing is also insufficient.  9-11commission.gov shows
>> > green for example but if you use DNS COOKIES (which BIND 9.10.4 and
>> > BIND 9.11.0 do) then servers barf and return BADVERS and validation
>> > fails.  QWEST you have been informed of this already.
>> >
>> > Why the hell should validating resolver have to work around the
>> > crap you guys are using?  DO YOUR JOBS which is to use RFC
>> > COMPLIANT
>> > servers.  You get PAID to do DNS because people think you are
>> > compentent to do the job.  Evidence shows otherwise.
>> >
>> > https://ednscomp.isc.org/compliance

Re: pay.gov and IPv6

[Lee]

On 11/16/16, Mark Andrews <ma...@isc.org> wrote:
>
> In message <1479249003.3937.6.ca...@ns.five-ten-sg.com>, Carl Byington
> writes
> :
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>>
>> Following up on a two year old thread, one of my clients just hit this
>> problem. The failure is not that www.pay.gov is not reachable over ipv6
>> (2605:3100:fffd:100::15). They accept (TCP handshake) the port 443
>> connection, but the connection then hangs waiting for the TLS handshake.
>>
>> openssl s_client -connect www.pay.gov:443
>>
>> openssl s_client -servername www.pay.gov -connect 199.169.192.21:443
>>
>> Browsers (at least firefox) see that as a very slow site, and it does
>> not trigger their happy eyeballs fast failover to ipv4.
>
> Happy eyeballs is about making the connection not whether TCP
> connections work after the initial packet exchange.
>
> I would send a physical letter to the relevent Inspector General
> requesting that they ensure all web sites under their juristiction
> that are supposed to be reachable from the public net get audited
> regularly to ensure that IPv6 connections work from public IP space.

That will absolutely work.

NIST is still monitoring ipv6 .gov sites
  https://usgv6-deploymon.antd.nist.gov/cgi-bin/generate-gov
so the IG isn't going to do anything there & pay.gov has a contact us page
  https://pay.gov/public/home/contact
that I'd bet works much better than a letter to the IG

Regards,
Lee

Re: A perl script to convert Cisco IOS/Nexus/ASA configurations to HTML for easier comprehension

[Lee]

On 10/13/16, Jesse McGraw <jlmcg...@gmail.com> wrote:
> Lee,
>
>Check out the setup.sh script, hopefully it does everything necessary
> to get the script working on a Debian-derived Linux system

I'm using Windows + Cygwin; maybe it's just that I don't have them
installed, but there is no sudo or apt so setup.sh isn't going to work
for me.  So while I was interested in seeing what this bit looked like
> If you run it against multiple configuration files at once it will also 
> attempt to link
> between them when applicable (e.g. BGP neighbors, route next hops, interfaces
> on the same subnet etc).
I'm not willing to take any more time on this.

I appreciate all the people who've tried to help but at least for now, I'm done.

Thanks,
Lee


>
> I've attempted to make the only globally-installed dependencies be cpanm
> and carton.  Once those are installed it uses carton to install the
> dependencies locally
>
>
> On 10/12/2016 07:59 PM, Lee wrote:
>> On 10/12/16, Jason Hellenthal <jhellent...@dataix.net> wrote:
>>> Give these a shot. https://github.com/jlmcgraw/networkUtilities
>>>
>>> I know J could use a little feedback on those as well but all in all
>>> they
>>> are pretty solid.
>> Where does one get Modern/Perl.pm ?
>>
>> Can't locate Modern/Perl.pm in @INC (you may need to install the
>> Modern::Perl module) (@INC contains: /tmp/local/lib/perl5
>> /usr/lib/perl5/site_perl/5.22/i686-cygwin-threads-64int
>> /usr/lib/perl5/site_perl/5.22
>> /usr/lib/perl5/vendor_perl/5.22/i686-cygwin-threads-64int
>> /usr/lib/perl5/vendor_perl/5.22
>> /usr/lib/perl5/5.22/i686-cygwin-threads-64int /usr/lib/perl5/5.22 .)
>> at /tmp/iosToHtml.pl line 87.
>> BEGIN failed--compilation aborted at /tmp/iosToHtml.pl line 87.
>>
>> Lee
>>
>>
>>
>>>> On Oct 11, 2016, at 08:48, Lee <ler...@gmail.com> wrote:
>>>>
>>>> On 10/10/16, Jay Hennigan <j...@west.net> wrote:
>>>>> On 10/6/16 1:26 PM, Jesse McGraw wrote:
>>>>>> Nanog,
>>>>>>
>>>>>> (This is me scratching an itch of my own and hoping that sharing
>>>>>> it
>>>>>> might be useful to others on this list.  Apologies if it isn't)
>>>>>>
>>>>>>   When I'm trying to comprehend a new or complicated Cisco router,
>>>>>> switch or firewall configuration an old pet-peeve of mine is how
>>>>>> needlessly difficult it is to follow deeply nested logic in
>>>>>> route-maps,
>>>>>> ACLs, QoS policy-maps etc etc
>>>>>>
>>>>>> To make this a bit simpler I’ve been working on a perl script to
>>>>>> convert
>>>>>> these text-based configuration files into HTML with links between the
>>>>>> different elements (e.g. To an access-list from the interface where
>>>>>> it’s
>>>>>> applied, from policy-maps to class-maps etc), hopefully making it
>>>>>> easier
>>>>>> to to follow the chain of logic via clicking links and using the
>>>>>> forward
>>>>>> and back buttons in your browser to go back and forth between command
>>>>>> and referenced list.
>>>>> Way cool. Now to hook it into RANCID
>>>> It looks like what I did in 2.3.8 should still work - control_rancid
>>>> puts the diff output into $TMP.diff so add this bit:
>>>> grep "^Index: " $TMP.diff | awk '/^Index: configs/{
>>>> if ( ! got1 ) { printf("/usr/local/bin/myscript.sh "); got1=1; }
>>>> printf("%s ", $2)
>>>> }
>>>> END{ printf("\n") }
>>>> ' >$TMP.doit
>>>> /bin/sh $TMP.doit >$TMP.out
>>>> if [ -s $TMP.out ] ; then
>>>>.. send mail / whatever
>>>> rm $TMP.doit $TMP.out
>>>> fi
>>>>
>>>> Regards,
>>>> Lee
>>>
>>> --
>>>   Jason Hellenthal
>>>   JJH48-ARIN
>> .
>>
>
>

Re: A perl script to convert Cisco IOS/Nexus/ASA configurations to HTML for easier comprehension

[Lee]

On 10/12/16, Jason Hellenthal <jhellent...@dataix.net> wrote:
> Give these a shot. https://github.com/jlmcgraw/networkUtilities
>
> I know J could use a little feedback on those as well but all in all they
> are pretty solid.

Where does one get Modern/Perl.pm ?

Can't locate Modern/Perl.pm in @INC (you may need to install the
Modern::Perl module) (@INC contains: /tmp/local/lib/perl5
/usr/lib/perl5/site_perl/5.22/i686-cygwin-threads-64int
/usr/lib/perl5/site_perl/5.22
/usr/lib/perl5/vendor_perl/5.22/i686-cygwin-threads-64int
/usr/lib/perl5/vendor_perl/5.22
/usr/lib/perl5/5.22/i686-cygwin-threads-64int /usr/lib/perl5/5.22 .)
at /tmp/iosToHtml.pl line 87.
BEGIN failed--compilation aborted at /tmp/iosToHtml.pl line 87.

Lee



>
>> On Oct 11, 2016, at 08:48, Lee <ler...@gmail.com> wrote:
>>
>> On 10/10/16, Jay Hennigan <j...@west.net> wrote:
>>> On 10/6/16 1:26 PM, Jesse McGraw wrote:
>>>> Nanog,
>>>>
>>>>(This is me scratching an itch of my own and hoping that sharing it
>>>> might be useful to others on this list.  Apologies if it isn't)
>>>>
>>>>  When I'm trying to comprehend a new or complicated Cisco router,
>>>> switch or firewall configuration an old pet-peeve of mine is how
>>>> needlessly difficult it is to follow deeply nested logic in route-maps,
>>>> ACLs, QoS policy-maps etc etc
>>>>
>>>> To make this a bit simpler I’ve been working on a perl script to
>>>> convert
>>>> these text-based configuration files into HTML with links between the
>>>> different elements (e.g. To an access-list from the interface where
>>>> it’s
>>>> applied, from policy-maps to class-maps etc), hopefully making it
>>>> easier
>>>> to to follow the chain of logic via clicking links and using the
>>>> forward
>>>> and back buttons in your browser to go back and forth between command
>>>> and referenced list.
>>>
>>> Way cool. Now to hook it into RANCID
>>
>> It looks like what I did in 2.3.8 should still work - control_rancid
>> puts the diff output into $TMP.diff so add this bit:
>> grep "^Index: " $TMP.diff | awk '/^Index: configs/{
>> if ( ! got1 ) { printf("/usr/local/bin/myscript.sh "); got1=1; }
>> printf("%s ", $2)
>> }
>> END{ printf("\n") }
>> ' >$TMP.doit
>> /bin/sh $TMP.doit >$TMP.out
>> if [ -s $TMP.out ] ; then
>>   .. send mail / whatever
>> rm $TMP.doit $TMP.out
>> fi
>>
>> Regards,
>> Lee
>
>
> --
>  Jason Hellenthal
>  JJH48-ARIN

Re: A perl script to convert Cisco IOS/Nexus/ASA configurations to HTML for easier comprehension

[Lee]

On 10/10/16, Jay Hennigan <j...@west.net> wrote:
> On 10/6/16 1:26 PM, Jesse McGraw wrote:
>> Nanog,
>>
>> (This is me scratching an itch of my own and hoping that sharing it
>> might be useful to others on this list.  Apologies if it isn't)
>>
>>   When I'm trying to comprehend a new or complicated Cisco router,
>> switch or firewall configuration an old pet-peeve of mine is how
>> needlessly difficult it is to follow deeply nested logic in route-maps,
>> ACLs, QoS policy-maps etc etc
>>
>> To make this a bit simpler I’ve been working on a perl script to convert
>> these text-based configuration files into HTML with links between the
>> different elements (e.g. To an access-list from the interface where it’s
>> applied, from policy-maps to class-maps etc), hopefully making it easier
>> to to follow the chain of logic via clicking links and using the forward
>> and back buttons in your browser to go back and forth between command
>> and referenced list.
>
> Way cool. Now to hook it into RANCID

It looks like what I did in 2.3.8 should still work - control_rancid
puts the diff output into $TMP.diff so add this bit:
grep "^Index: " $TMP.diff | awk '/^Index: configs/{
 if ( ! got1 ) { printf("/usr/local/bin/myscript.sh "); got1=1; }
 printf("%s ", $2)
 }
 END{ printf("\n") }
' >$TMP.doit
/bin/sh $TMP.doit >$TMP.out
if [ -s $TMP.out ] ; then
   .. send mail / whatever
rm $TMP.doit $TMP.out
fi

Regards,
Lee

Re: A perl script to convert Cisco IOS/Nexus/ASA configurations to HTML for easier comprehension

[Lee]

On 10/8/16, Hank Nussbacher <h...@efes.iucc.ac.il> wrote:
> On 07/10/2016 17:59, Lee wrote:
>> On 10/7/16, Hank Nussbacher <h...@efes.iucc.ac.il> wrote:
>>> On 07/10/2016 00:33, Lee wrote:
>>>> dunno about creating web pages, but
>>>> https://www.nanog.org/meetings/abstract?id=785
>>>> has a section on showing filters that are defined but not referenced &
>>>> referenced but not defined
>>> In IOS-XR it is one command "sho rpl unused ?"
>>> RP/0/RSP0/CPU0:petach-tikva-gp#show rpl unused ?
>>>   as-path-set   Display as-path-set objects
>>>   community-set Display community-set objects
>>>   extcommunity-set  Display extended community objects
>>>   prefix-setDisplay prefix-set objects
>>>   rd-setDisplay rd-set objects
>>>   route-policy  Display route-policy objects
>>>   tag-set   Display tag-set objects
>>>
>>> RP/0/RSP0/CPU0:petach-tikva-gp#show rpl unused prefix
>>> Fri Oct  7 08:24:53.237 IDT
>>>
>>> ACTIVE -- Referenced by at least one policy which is attached
>>> INACTIVE -- Only referenced by policies which are not attached
>>> UNUSED -- Not attached (directly or indirectly) and not referenced
>> I'm actually starting to miss being out of the game.  I'm retired, so
>> don't have access to anything running IOS-XR.  Just out of curiosity,
>> how does the output of 'show rpl unused prefix' compare to the output
>> of the script at  http://pastebin.com/pem7tHAJ
>>
>> Thanks,
>> Lee
>>
> Samples:
>
   <.. snip samples ..>
  interesting.. thanks!

> Note the sloppy code - sometimes they state UNUSED and sometimes
> (UNUSED).  Or "the following policies are"... rather than "the following
> routing policies are".  Just plain sloppy Cisco coding and poor QA.  And
> once you delete these unreferenced objects, "show rpl unused" will still
> show them since there is a bug in Cisco code (CSCuy07932/CSCug9153). See:
> http://www.gossamer-threads.com/lists/cisco/nsp/192481
> for details.

Which is why I like having the source code -- there's the possibility
of fixing whatever myself instead of having to wait for the vendor to
fix it :)

Thanks,
Lee

Re: A perl script to convert Cisco IOS/Nexus/ASA configurations to HTML for easier comprehension

[Lee]

On 10/7/16, Hank Nussbacher <h...@efes.iucc.ac.il> wrote:
> On 07/10/2016 00:33, Lee wrote:
>> dunno about creating web pages, but
>> https://www.nanog.org/meetings/abstract?id=785
>> has a section on showing filters that are defined but not referenced &
>> referenced but not defined
>
> In IOS-XR it is one command "sho rpl unused ?"
> RP/0/RSP0/CPU0:petach-tikva-gp#show rpl unused ?
>   as-path-set   Display as-path-set objects
>   community-set Display community-set objects
>   extcommunity-set  Display extended community objects
>   prefix-setDisplay prefix-set objects
>   rd-setDisplay rd-set objects
>   route-policy  Display route-policy objects
>   tag-set   Display tag-set objects
>
> RP/0/RSP0/CPU0:petach-tikva-gp#show rpl unused prefix
> Fri Oct  7 08:24:53.237 IDT
>
> ACTIVE -- Referenced by at least one policy which is attached
> INACTIVE -- Only referenced by policies which are not attached
> UNUSED -- Not attached (directly or indirectly) and not referenced

I'm actually starting to miss being out of the game.  I'm retired, so
don't have access to anything running IOS-XR.  Just out of curiosity,
how does the output of 'show rpl unused prefix' compare to the output
of the script at  http://pastebin.com/pem7tHAJ

Thanks,
Lee

Re: A perl script to convert Cisco IOS/Nexus/ASA configurations to HTML for easier comprehension

[Lee]

On 10/6/16, Jesse McGraw <jlmcg...@gmail.com> wrote:
> Nanog,
>
>  (This is me scratching an itch of my own and hoping that sharing it
> might be useful to others on this list.  Apologies if it isn't)
>
>When I'm trying to comprehend a new or complicated Cisco router,
> switch or firewall configuration an old pet-peeve of mine is how
> needlessly difficult it is to follow deeply nested logic in route-maps,
> ACLs, QoS policy-maps etc etc
>
> To make this a bit simpler I’ve been working on a perl script to convert
> these text-based configuration files into HTML with links between the
> different elements (e.g. To an access-list from the interface where it’s
> applied, from policy-maps to class-maps etc), hopefully making it easier
> to to follow the chain of logic via clicking links and using the forward
> and back buttons in your browser to go back and forth between command
> and referenced list.
>
>
> I've put the script itself up here
> <https://github.com/jlmcgraw/network_configuration_navigator>:
> https://github.com/jlmcgraw/network_configuration_navigator
>
> See here
> https://github.com/jlmcgraw/network_configuration_navigator/blob/master/examples/html_test_case_1.cfg.html>
>
> for output examples
> http://htmlpreview.github.com/?https://github.com/jlmcgraw/network_configuration_navigator/blob/master/examples/html_test_case_1.cfg.html
>
> Here's a quick web demo <https://hidden-waters-8218.herokuapp.com/> on
> Heroku
> https://hidden-waters-8218.herokuapp.com/
>  (This is just a simple web front-end to the script.  I'm not a
> web-savvy guy so I'm sure it's poorly coded and terribly insecure.
>  Please don't upload anything sensitive to this, it's just for
> testing!)
>
> I know there is a lot of stuff that could be done better so let me know
> if you think of anything new or notice something I’ve done wrong.
>
> One unexpected thing that has come out of this script is the ability to
> catch items that are defined but never actually used, whether it's due
> to a fat-finger or just being leftover cruft. This has proven very
> valuable in catching mistakes that are otherwise hard to spot.
> Unfortunately the script can't currently catch the inverse (things that
> are called but never defined) due to the way the regexes are constructed
>
> Surely this has all been done before but I couldn't find anything in a
> few brief moments of searching so here we are.

dunno about creating web pages, but
https://www.nanog.org/meetings/abstract?id=785
has a section on showing filters that are defined but not referenced &
referenced but not defined

Regards,
Lee

Re: Handling of Abuse Complaints

[Lee Fuller]

It's quite possible to operate an open resolver while still making it very
difficult to use in an amplification attack - maybe coach your user into
using rate limiting if you are particularly keen not to 'shape' their
traffic at this stage. PowerDNS has a very powerful load balancer that can
be used effectively although it's name escapes me now. PowerDNS 3x and 4x
also has an effective anti spoofing mechanism.





*Kind Regards,Lee Fuller*

*PGP Fingerprint <https://leefuller.io/pgp/>: *
4ACAEBA4B9EE1B3A075034302D5C3D050E6ED55A

On 29 August 2016 at 18:04, Laszlo Hanyecz <las...@heliacal.net> wrote:

> I know this is against the popular religion here but how is this abuse on
> the part of your customer?  Google, Level3 and many others also run open
> resolvers, because they're useful services. This is why we can't have nice
> things.
>
>
>
> On 2016-08-29 15:55, Jason Lee wrote:
>
>> NANOG Community,
>>
>> I was curious how various players in this industry handle abuse
>> complaints.
>> I'm drafting a policy for the service provider I'm working for about
>> handing of complaints registered against customer IP space. In this
>> example
>> I have a customer who is running an open resolver and have received a few
>> complaints now regarding it being used as part of a DDoS attack.
>>
>> My initial response was to inform the customer and ask them to fix it. Now
>> that its still ongoing over a month later, I'd like to take action to
>> remediate the issue myself with ACLs but our customer facing team is
>> pushing back and without an idea of what the industry best practice is,
>> management isn't sure which way to go.
>>
>> I'm hoping to get an idea of how others handle these cases so I can
>> develop
>> our formal policy on this and have management sign off and be able to take
>> quicker action in the future.
>>
>> Thanks,
>>
>> Jason
>>
>
>

Handling of Abuse Complaints

[Jason Lee]

NANOG Community,

I was curious how various players in this industry handle abuse complaints.
I'm drafting a policy for the service provider I'm working for about
handing of complaints registered against customer IP space. In this example
I have a customer who is running an open resolver and have received a few
complaints now regarding it being used as part of a DDoS attack.

My initial response was to inform the customer and ask them to fix it. Now
that its still ongoing over a month later, I'd like to take action to
remediate the issue myself with ACLs but our customer facing team is
pushing back and without an idea of what the industry best practice is,
management isn't sure which way to go.

I'm hoping to get an idea of how others handle these cases so I can develop
our formal policy on this and have management sign off and be able to take
quicker action in the future.

Thanks,

Jason

Google compute engine private ASNs

[Lee Fuller]

Hey, first post so sorry if it's misguided. I'm curious about the BGP
implementation in Google compute engine that allows you to define routing
policy using private ASN numbers. How similar is it in terms of learning
about BGP as a broader concept, or is it all smoke and mirrors?

I'm not in a position where iBGP would benefit me in any other context than
learning so I'm keen not to bother if it's too abstracted from a real world
scenario.

Lee Fuller (mobile)

PGP Fingerprint: 4ACAEBA4B9EE1B3A075034302D5C3D050E6ED55A

Re: Operations task management software?

[Lee]

On 7/27/16, David Hubbard <dhubb...@dino.hostasaurus.com> wrote:
> Hi all, curious if anyone has recommendations on software that helps manage
> routine duties assigned to operations staff?

Have computers do the routine scut work - not people.

> For example, let’s say we have a P that says someone from the netops group
> must check that Rancid is successfully backing up all router configs
> bi-weekly.

You've got the source code for rancid, so change rancid-run to do something like
  LOGFILE=$LOGDIR/$GROUP.`date +%Y%m%d.%H%M%S`; export LOGFILE
change the
  ) >$LOGDIR/$GROUP.`date +%Y%m%d.%H%M%S` 2>&1
to
  ) >$LOGFILE 2>&1

and then in control_rancid do something like
  grep "clogin error:" $LOGFILE | sort | uniq -c >$TMP.fail
  if [ -s $TMP.fail ]; then
 # got some output, mail the report
 ...

Do the same type thing for checking on
> backup failures, backup internet circuit status, out of band interfaces, etc.

Automate the checks, put the scripts in crontab & mail out an
"OhNoes!" or "all clear" msg at the end.   At which point you're left
with the problem of making sure the managers are looking at the emails
& making sure whatever problems are found actually get fixed :)

Regards,
Lee



>  Ideally, it would send an email reminder to this pre-defined
> group of people saying hey, it’s Monday, someone needs to check this and
> come acknowledge the task as having been completed.  If that doesn’t occur,
> pre-defined manager X is notified on Tuesday.  If manager X doesn’t get
> someone to complete the task, director Y is notified, so on and so forth.
> Then, perhaps periodically it emails manager X anyway and says hey, it’s
> been three months, you need to audit netops to ensure they’re actually doing
> the Rancid audit and not just checking that it was done.  This could be
> applied to the staff who check on backup failures, backup internet circuit
> status, out of band interfaces, etc.
>
> A data center I looked at recently had QR code stickers on all of their
> infrastructure stuff and there were staff assigned to check and log certain
> displayed values each day.  The software would at least ensure they actually
> visited the equipment by requiring they scan the relevant QR code when in
> front of it.  So I figure something that does what I’m looking for properly
> already exists.
>
> Thanks,
>
> David
>

Re: MTU

[Lee]

On 7/22/16, Phil Rosenthal <p...@isprime.com> wrote:
>
>> On Jul 22, 2016, at 1:37 PM, Grzegorz Janoszka <grzeg...@janoszka.pl>
>> wrote:
>> What I noticed a few years ago was that BGP convergence time was faster
>> with higher MTU.
>> Full BGP table load took twice less time on MTU 9192 than on 1500.
>> Of course BGP has to be allowed to use higher MTU.
>>
>> Anyone else observed something similar?
>
> I have read about others experiencing this, and did some testing a few
> months back -- my experience was that for low latency links, there was a
> measurable but not huge difference. For high latency links, with Juniper
> anyway, there was a very negligible difference, because the TCP Window size
> is hard-coded at something small (16384?), so that ends up being the limit
> more than the tcp slow-start issues that MTU helps with.

I think the Cisco default window size is 16KB but you can change it with
ip tcp window-size NNN

Lee

>
> With that said, we run MTU at >9000 on all of our transit links, and all of
> our internal links, with no problems. Make sure to do testing to send pings
> with do-not-fragment at the maximum size configured, and without
> do-not-fragment just slightly larger than the maximum size configured, to
> make sure that there are no mismatches on configuration due to vendor
> differences.
>
> Best Regards,
> -Phil Rosenthal

Re: NAT firewall for IPv6?

[Lee]

On 7/5/16, Naslund, Steve <snasl...@medline.com> wrote:
> Did you get the impression that this person asking for help was going to be
> able to set that up?

Yes, I think the OP could create & apply the acl.  Which is why I said
it could break their network & suggested they get Cisco tech support
on the phone to figure out how to safely turn off IPv6.

I'm also giving them the benefit of the doubt that IPv6 really is the
malware infection vector.

>  I didn't (if he was he would probably already know
> what an ACL is).  I do not know if the Catalyst he is looking at is his or
> his service providers edge devices (or maybe the consultants didn't give
> them access to that either),  I don't know that that Catalyst is the primary
> router for their network (could be an L2 switch behind the firewall).  I
> also doubt the problem stems from ipv6 as much as it comes from having an
> out of control firewall. Given what I am hearing about this network I am
> kind of doubting that it is really ipv6 enabled in any case so your fix
> prevents ipv6 traffic that is probably not even being routed in the first
> place.  In my opinion not having control of your own firewall is the five
> alarm emergency in that network right now.

Maybe I wasn't clear that the call to Cisco tech support should be a
parallel effort?

> If the network is ipv6 enabled, blocking all ipv6 traffic at that router is
> probably not a good idea without knowing more.

Which is why I suggested getting Cisco tech support involved.  A
mailing list is not where they should be going for help right now.

Best Regards,
Lee


> ...  If it is not ipv6 enabled
> then it will have no effect on the reported issue (malware).
>
>
> Steven Naslund
> Chicago IL
>
>
>>Right.  But how long is it going to take to secure the Palo Alto firewall?
>>If the central Cisco Catalyst really is an IPv6 router, doing a conf t
>>ipv6 access-list denyIPv6
>>  deny ipv6 any any
>
>>interface [whatever connects to the ISP]
>> ipv6 traffic-filter denyIPv6 in
>> ipv6 traffic-filter denyIPv6 out
>>end
>>would be a quick fix for the firewall not doing any ipv6 filtering.
>>It could also break ipv6 enabled web sites or even internal connectivity,
>> so it'd be better to get someone on the phone w/ Cisco tech support and
>> have Cisco figure out the best way to block IPv6 for you.
>
>>True.  But they're in "stop the bleeding" mode and disabling ipv6 is just a
>> temp work-around until the firewall is fixed.
>
>
>

Re: NAT firewall for IPv6?

[Lee]

On 7/5/16, Naslund, Steve <snasl...@medline.com> wrote:
> Hard to know where to begin with this one, but let me take a shot at it.
>
> 1.  My top priority would be to get into that Palo Alto firewall.  Get Palo
> Alto on the phone and figure out password recovery with them.  Since you
> don’t have the password it is possible that firewall is compromised.  Do not
> be surprised if you have to jump through some hoops with Palo Alto to prove
> that you own it and what has happened.  Remember their job is to keep people
> out of your network.  They are probably also going to want you to be current
> on support.  If you have to pay to get current on support, do it.  You need
> that help right now badly.
>
> You could ask Palo Alto how to block the v6 while you are at it or even
> better set up a rules that mirror your v4 protection.   I cannot stress
> enough how big a security issue it is to not have access to your firewall
> and not know who does.
>
> 2.  There are lots of ways to shut off ipv6 but my suggestion would be to
> just secure the Palo Alto firewall,

Right.  But how long is it going to take to secure the Palo Alto firewall?
If the central Cisco Catalyst really is an IPv6 router, doing a
conf t
ipv6 access-list denyIPv6
  deny ipv6 any any

interface [whatever connects to the ISP]
 ipv6 traffic-filter denyIPv6 in
 ipv6 traffic-filter denyIPv6 out
end
would be a quick fix for the firewall not doing any ipv6 filtering.
It could also break ipv6 enabled web sites or even internal
connectivity, so it'd be better to get someone on the phone w/ Cisco
tech support and have Cisco figure out the best way to block IPv6 for
you.


>  ... to say that any legitimate service
> should have a ipv4 address is not quite true now and will definitely not be
> true in the near future.

True.  But they're in "stop the bleeding" mode and disabling ipv6 is
just a temp work-around until the firewall is fixed.

Regards,
Lee



> 3.  Just about any kind of firewall or router CPE device can block or
> firewall ipv4 and ipv6 as long as its firmware is fairly recent.  However,
> you would most likely have to replace the Palo Alto with it.  You DO NOT
> WANT THEM BOTH INLINE!  Most likely they are both configured to do ipv4 NAT
> out of the box and that will not work correctly to have them both inline
> together.  While it is possible to set up that sort of thing to work
> correctly, it’s a bad idea and pretty advanced configuration for a temporary
> network admin.  The interaction of one firewall fronting another can be very
> difficult to troubleshoot without a deep understanding of what is going on.
> Referring back to item 1, you are probably going to need to get the
> configuration of the current firewall if you seek to replace it (there will
> be rules in the Palo Alto that you would want to replicate if you are going
> to replace it).
>
> 4.  Cisco Catalyst as the router.there could be a lot of things going on
> in there.  The Catalyst is primarily a switch with routing functionality.
> It can definitely block ipv6 if configured to do so but we would need to
> know a lot more about its current configuration to give you the best way to
> do that.  It could just be a service providers switch on your premise in
> which case you can't do much with it.  Again, much easier to accomplish Item
> 1 with Palo Alto and let your firewall do what it is supposed to do.
>
> Steven Naslund
> Chicago IL
>
>
>
> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Edgar Carver
> Sent: Friday, July 01, 2016 9:29 PM
> To: nanog@nanog.org
> Subject: NAT firewall for IPv6?
>
> Hello NANOG community. I was directed here by our network administrator
> since she is on vacation. Luckily, I minored in Computer Science so I have
> some familiarity.
>
> We have a small satellite campus of around 170 devices that share one
> external IPv4 and IPv6 address via NAT for internet traffic. Internal
> traffic is over an MPLS.
>
> We're having problems where viruses are getting through Firefox, and we
> think it's because our Palo Alto firewall is set to bypass filtering for
> IPv6. Unfortunately, the network admin couldn't give me the password since a
> local consultant set it up, and it seems they went out of business. I need
> to think outside the box.
>
> Is there some kind of NAT-based IPv6 firewall I can setup on the router that
> can help block viruses? I figure that's the right place to start since all
> the traffic gets funneled there. We have a Cisco Catalyst as a router. Or,
> ideally, is there an easy way to turn off IPv6 completely? I really don't
> see a need for it, any legitimate service should have an IPv4 address.
>
> I'd really appreciate your advice. I plan to drive out there tomorrow, where
> I can get the exact model numbers and stuff.
>
> Regards,
> Dr. Edgar Carver
>

Tracking traffic usage at router or switch port?

[Jason Lee]

NANOG Community,

Typically where would you expect a service provider to monitor bandwidth
usage on your circuits? On the physical switch port interface or on the
vlan interface at the router? In some of the field testing I've been doing
there can be a difference in the bandwidth usage on the vlan interface at
the router vs the physical switch port. Is there any particular reason for
using one vs the other? Is there an industry best practice for this?

Thanks,

Jason

Re: Latency, TCP ACKs and upload needs

[Lee]

On 4/20/16, Leo Bicknell wrote:
>
> Others have already answered with the technical details.  Let me take a
> stab at some more, uh, variable items.

  [.. snip lots ..]

> 90%+ of the stacks deployed will be too small.  Modern Unix generally
> has "autotuning" TCP stacks, but I don't think Windows or OS X has
> those features yet (but I'd be very happy to be wrong on that point).

Windows has had an autotuning stack since at least Vista.

Regards,
Lee

Re: Latency, TCP ACKs and upload needs

[Lee]

On 4/19/16, Jean-Francois Mezei <jfmezei_na...@vaxination.ca> wrote:
> As part of the ongoing CRTC hearings, the incumbents' claim that
> continued implementation of the current 5/1 standard would make Canada a
> world leader for broadband in the future.
>
> A satellite company who currently can't even deliver its advertised 5/1
> now brags its next satellite will deliver 25/1.

Take a look at https://www.rfc-editor.org/rfc/rfc3449.txt
  TCP Performance Implications of Network Path Asymmetry

> So I have a few questions:
>
> Considering a single download TCP connection. I am aware that modern TCP
> stacks will rationalize ACKs and send 1 ACK for every x packets
> received, thus reducing upload bandwidth requirements. Is this basically
> widespread and assumed that everyone has that ?

The usual defaults are to ack every other packet & wait 200ms before
acking a single packet.


> Also, as you split available bandwidth between multiple streams, won't
> ack upload requirements increase because ACK rationalisation happens far
> less often sicne each TCP connection has its own context for ACKs?

Yes.  And multiple streams will interfere with each other.
It used to be popular to split a download into multiple streams but I
thought that went out of style now that tcp window scaling is
generally enabled by default.

> When one considers the added latency of satellite links, does 25/1 make
> sense ?  (I need a sanity check to distinguish between marketing spin
> presented to the regulator and real life)
>
> I noticed that in the USA, EXEDE Satellite advertises 12/3 plans and
> they are also on a VIA Sat satellite, presumably the same vehicle that
> Xplornet tries to deliver its measly 5/1 on. Would all beams be
> identical on a satellite or can they be configured differently with a
> ISP adjustable rate of upload/download inside the same spectrum ?
>
>
>
>
> Also, when you establish a TCP connection, do most stacks have a default
> window size that gives the sender enough "patience" to wait long enough
> for the ACK ?

There's an initial timeout that's on the order of 3-5 seconds.  Once
the xfer starts ... I've forgotten the details, but the retransmission
timer is based on the "smoothed round trip time" (srtt).

> If sender sends packet 457, doesn't get ACK in time and resends 457,
> doesn't that also result in reduction in window size (the very opposite
> of what would be needed in high latency links) ?

The window size is what the receiver advertises, the congestion window
(cwnd) is what the sender computes based on the advertised window size
& packet loss.  cwnd is what gets reduced when there's packet loss.
& yes, reducing cwnd is bad for thruput as is not having selective
acks (sack) enabled on the receiver.

> And when the first ACK finally arrives, won't the sender assume this ACK
> was for the resent 457 ?

The sender keeps track of the 'smoothed round trip time' (srtt).
Since it can't tell if the ack is for the original or retransmitted
pkt, it's not supposed to use that ack for updating the rtt

>   Or is satellite latency low enough that
> stacks all have enough default "patience" to wait for ACKs and this is a
> non issue ?

should be a non-issue

> (Note Xplornet refused to answer questions on whether they operate
> special proxies at their gound stations to manage TCP connections to
> appear "close").
>
>
>
> What i am trying to get at here is whether 25/1 on satellite, in real
> life with a few apps exchanging data, would actually be able to make use
> of the 25 download speed or whether the limited 1mbps upload would choke
> the downloads ?

dunno.  Assuming the bandwidth is available, I suspect you could get
25Mb/s doing something like downloading a movie from archive.org but
for anything interactive like web surfing / gaming I'd bet no - but
because of latency, not the 1Mb/s uplink speed.

Regards,
Lee

Colocation Server Lifts

[Jason Lee]

Hi NANOG community,

A few questions I have for the community regarding server lifts at colo
facilities.

1. Is a server lift something you would typically expect a colo facility to
provide?

if yes,

2. Do colo facilities typically allow customers to just use them or provide
an operator?
3. Is it a free offering or something they rent out?
4. What would be the typical device weight you would lift?
5. What would be the max device weight you would lift?

Thanks,

Jason

Re: Why the US Government has so many data centers

[Lee]

On 3/14/16, Sean Donelan wrote:
> On Mon, 14 Mar 2016, Lee wrote:
>> I doubt anyone really believes that having a server in the room makes
>> it a data center.  But if you're the Federal CIO pushing the cloud
>> first policy, this seems like a great bureaucratic maneuver to get the
>> decision making away from the techies that like redundant servers in
>> multiple locations, their managers who's job rating depends on
>> providing reliable services and even the agency CIOs.  Check the
>> reporting section of the memo where it says "each agency head shall
>> annually publish a Data Center Consolidation and Optimization
>> Strategic Plan".   I dunno, but I'm guessing agency heads are
>> political appointees that aren't going to spend much, if any, time
>> listening to techies whine about how important their servers are & why
>> they can't be consolidated, virtualized or outsourced.
>
> If your goal is to consolidate servers, call it a server consolidation
> initiative.

He did, didn't he?  "... consolidate inefficient infrastructure,
optimize existing facilities, achieve cost savings, and transition to
more efficient infrastructure".   But other than the ability to
embarrass people[1] - ie. make the reports public, how much actual
ability to effect change does he really have?

> You are correct political appointees won't understand why techies are
> perplexed by calling everything a data center.  Just remember that
> when you read the stories in the Washington Post about how many
> data centers the government has...
>
>
> http://www.datacenterdynamics.com/design-build/us-government-finds-2000-more-data-centers/95243.fullarticle
> New count of government facilities, and it looks like consolidation is going
> backwards

Yes, *sigh*, another what kind of people _do_ we have running the govt
story.  Altho, looking on the bright side, it could have been much
worse than a final summing up of "With the current closing having been
reported to have saved over $2.5 billion it is clear that inroads are
being made, but ... one has to wonder exactly how effective the
initiative will be at achieving a more effective and efficient use of
government monies in providing technology services."

Best Regards,
Lee


[1] 
http://archive.fortune.com/2011/07/13/news/companies/vivek_kundra_leadership.fortune/index.htm

For example, one of the first things I did was take the picture of
every CIO in the federal government. We set up an IT dashboard online,
and I put their pictures right next to the IT projects they were
responsible for. You could see on this IT dashboard whether that
project was on schedule or not. The President actually looked at the
IT dashboard, so we took a picture of that and put it online. Moments
later, I started getting many phone calls from CIOs who said, "For the
first time, my cabinet secretary is asking me why this project is red
or green or yellow." One agency ended up halting 45 IT projects
immediately. It was just the act of shining light and making sure you
focus on execution, not only policy.

Re: Why the US Government has so many data centers

[Lee]

On 3/13/16, Sean Donelan wrote:
> On Sun, 13 Mar 2016, Lee wrote:
>> Where does it say test/dev has to be done solely in a cloud data
>> center?  This bit
>>   For the purposes of this memorandum, rooms with at least one
>> server, providing
>>   services (whether in a production, test, stage, development, or any
>> other
>>   environment), are considered data centers.
>> seems to be more about trying to close the self-reporting loophole -
>> ie 'these aren't the droids you're looking for.'   for example -
>> https://github.com/WhiteHouse/datacenters/issues/9
>
> Sigh, read any Inspector General report for how memorandums are
> implemented by auditors.  If the memorandum says "or any other
> environment" the IG's will treat that as no exceptions.
>
> So IG's will "close the reporting loophole" by reporting that their are
> 100,000 "data centers" if a room contains  even a single server.
>
> Auditors like counting things, they don't like interpretations.  Inspector
> Generals are uber-auditors.

uhmmm.. yes - that's my point.  No more of the "Whut?  That box over
there??  Oh no, that's not a server, it's an _appliance_"
foot-dragging / circumvention of the cloud first policy.

I doubt anyone really believes that having a server in the room makes
it a data center.  But if you're the Federal CIO pushing the cloud
first policy, this seems like a great bureaucratic maneuver to get the
decision making away from the techies that like redundant servers in
multiple locations, their managers who's job rating depends on
providing reliable services and even the agency CIOs.  Check the
reporting section of the memo where it says "each agency head shall
annually publish a Data Center Consolidation and Optimization
Strategic Plan".   I dunno, but I'm guessing agency heads are
political appointees that aren't going to spend much, if any, time
listening to techies whine about how important their servers are & why
they can't be consolidated, virtualized or outsourced.

Lee

Re: Why the US Government has so many data centers

[Lee]

On 3/13/16, Sean Donelan <s...@donelan.com> wrote:
> On Sun, 13 Mar 2016, Roland Dobbins wrote:
>> On 13 Mar 2016, at 3:03, George Herbert wrote:
>>
>>> It's a symptom of trying to save a few cents at the risk of dollars.
>>
>> Concur 100%.
>>
>> Not to mention the related security issues.
>
> Just remember, no exceptions, no waivers.
>
> I understand why cloud vendors want 100% of government IT dollars.  But
> requiring all test and development to be done solely in cloud data
> centers...  there is your 100%

Where does it say test/dev has to be done solely in a cloud data
center?  This bit
   For the purposes of this memorandum, rooms with at least one
server, providing
   services (whether in a production, test, stage, development, or any other
   environment), are considered data centers.
seems to be more about trying to close the self-reporting loophole -
ie 'these aren't the droids you're looking for.'   for example -
https://github.com/WhiteHouse/datacenters/issues/9

Lee