Re: Netflix banning HE tunnels

[Mark Andrews]

In message <0e36af3e-9781-4f2b-1080-af915fff3...@blakjak.net>, Mark Foster writ
es:
> 
> 
> On 10/06/2016 4:38 p.m., Mark Andrews wrote:
> >> It would be nice to live in a world where that were the case. However, the
> >> world we live in is run my bean counters, and the marketing department.
> >> IPv6 is a huge project that is seen by them as an unnecessary expense.
> > Absolute BS.  IPv6 has never needed to be a huge project for a ISP
> > compared to everything else a ISP does.  It required some research
> > and ensuring that you bought compatible equipement and things fell
> > due for replacement.  If you failed to do the research and therefore
> > needed to do everthing in a rush then it might seem like a huge
> > project.
> 
> Router-jockeys and purists often cite this. I've done it myself.
> But there are a lot more moving parts in most service providers than 
> simply the ones and zeros.
> Bandwidth Accounting, Billing, Provisioning systems in particular - and 
> the developers/maintainers of these who have little or no knowledge of 
> IPv6 and perhaps not a lot more than that of IPv4, except that it's more 
> easily human-read and digested?

And the same applies to those systems.
 
> This was very much my experience in more than one ISP job over recent 
> years - the network kit is more than capable, it's the bits around the 
> outside that need work.
> Even if routing and switching kit was subject to lifecycle-replacement 
> every 5 years or so, software components that are in the background, 
> 'just work' and suddenly are very black-boxy because the author has long 
> since left the organisation and noone left behind knows how to make it 
> IPv6ready... sometimes the forklift approach is what is left.

For most things conversion to support IPv6 is trivial.  The hardest
thing is getting someone to signoff on someone looking under the
hood.

> Sorry this is tangental to the thread's focus but every time I see this 
> particular argument trotted out I feel like it's overlooking the 
> obvious; lack of sufficient forethought 10 years ago turns into 
> significant piece of work today. A lesson? Yes, but hindsight is 20:20.

And people were arguing 10+ years ago to start now so you don't
need to do everything in a rush.  What we got back then was "IPv6
won't take off".  This isn't 20:20 hindsite.  It's we told you so.

> Mark.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Netflix banning HE tunnels

[Mark Foster]

On 10/06/2016 4:38 p.m., Mark Andrews wrote:

It would be nice to live in a world where that were the case. However, the
world we live in is run my bean counters, and the marketing department.
IPv6 is a huge project that is seen by them as an unnecessary expense.

Absolute BS.  IPv6 has never needed to be a huge project for a ISP
compared to everything else a ISP does.  It required some research
and ensuring that you bought compatible equipement and things fell
due for replacement.  If you failed to do the research and therefore
needed to do everthing in a rush then it might seem like a huge
project.


Router-jockeys and purists often cite this. I've done it myself.
But there are a lot more moving parts in most service providers than 
simply the ones and zeros.
Bandwidth Accounting, Billing, Provisioning systems in particular - and 
the developers/maintainers of these who have little or no knowledge of 
IPv6 and perhaps not a lot more than that of IPv4, except that it's more 
easily human-read and digested?


This was very much my experience in more than one ISP job over recent 
years - the network kit is more than capable, it's the bits around the 
outside that need work.
Even if routing and switching kit was subject to lifecycle-replacement 
every 5 years or so, software components that are in the background, 
'just work' and suddenly are very black-boxy because the author has long 
since left the organisation and noone left behind knows how to make it 
IPv6ready... sometimes the forklift approach is what is left.


Sorry this is tangental to the thread's focus but every time I see this 
particular argument trotted out I feel like it's overlooking the 
obvious; lack of sufficient forethought 10 years ago turns into 
significant piece of work today. A lesson? Yes, but hindsight is 20:20.


Mark.

Re: Netflix banning HE tunnels

[Mark Andrews]

In message , "Ricky Beam" writes:
> On Thu, 09 Jun 2016 19:17:37 -0400, Mark Andrews  wrote:
> > The average consumer wants a "internet connection".
> 
> And sadly, they haven't a clue what that means. They plug the thing into  
> the other thing, and they can click on things in their web browser.  
> They're why we have boxes with color coded connectors and cables.
> 
> > What will happen is that as CGN starts to break things for people
> > like gamers they will start asking for IPv6, like us network geeks
> > ask for IPv6.
> 
> Correction: after much lamenting and whining to their gaming buddies via  
> various forums until someone boils it all down to one word "IPv6". And  
> then were back to ape mentality... they don't know what it is, but they  
> now know that's what they need. They have, thus, been "educated" -- to a  
> microscopic level only a physicist can measure, but they will now demand  
> "IPv6 (whatever that is.)"
> 
> > That being said, those who know what a internet connection should
> > be delivering should be advocating for the real deal.  It is our
> > ethical responsability to do this for our customers.
> 
> It would be nice to live in a world where that were the case. However, the  
> world we live in is run my bean counters, and the marketing department.  
> IPv6 is a huge project that is seen by them as an unnecessary expense.  

Absolute BS.  IPv6 has never needed to be a huge project for a ISP
compared to everything else a ISP does.  It required some research
and ensuring that you bought compatible equipement and things fell
due for replacement.  If you failed to do the research and therefore
needed to do everthing in a rush then it might seem like a huge
project.

> Everything works right now, right? CGN is easy; it's just one big box. 6RD  
> is just one more box, and then it's the customers problem to use it (etc.)  
> Companies do what makes them money without costing them money. IPv6 is the  
> exact opposite, it costs a lot and generates nothing.

6rd is a joke the way most ISP's deploy it.  One /64 per customer?
What the hell are they thinking.  6rd also introduces PMTUD issues
and rapid address renumbering that is necessary especially when
also providing native IPv4.  6rd is nothing but a stopgap solution
the same as a HE tunnel is a stopgap solution.  But you can ignore
that reality if you wish.  A ISP that thinks 6rd is the end point
when deploying IPv6 is doing their customers a disservice.

> I agree, we should've turned this shit on a decade ago (or more.)
> 
> Of course, the whole mess is exactly what you get out of "designed by  
> committee". With zero interoperability, and no viable migration paths,  
> it's a Forklift Upgrade(tm).

Hey you do better.  I've seen lots of people complain but I've yet
to see anyone come up with a better solution.  Talk is cheap.

> People don't do Forklift Upgrades(tm). "So  
> you want me to rip out all the token-ring gear and replace it with  
> ethernet?" That was a hard sell, and there was interoperability and  
> bridging technology. "So you want me to throw away by Novell IPX network  
> and replace it with TCP/IP?" While Novell did work over IP in the later  
> years, people hung on to their "works perfectly for our needs" IPX  
> infrastructure for decades -- IPX WANs, even. (some still exists to this  
> day. In fact, the massive kyocera printer here still supports IPX. And  
> Appletalk! Holy crap, my horse isn't dead; they still don't talk to each  
> other.)

No, we wanted you to enable IPv6 in parallel with IPv6 15+ years
ago.  It's not like it was that hard back then.

I've not replaced a single piece of equipement to get IPv6 yet I
have running IPv6 on most devices by being selective in my purchasing
decisions as things needed replacing.  There was no forklift upgrade.
Everything was done piecemeal.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Netflix banning HE tunnels

[Ca By]

On Thursday, June 9, 2016, Randy Bush  wrote:

> >> zero interoperability, and no viable migration paths, it's a Forklift
> >> Upgrade(tm).
> >
> > You say that with such confidence! Doesn't make it true.
>
> https://archive.psg.com/120206.nanog-v4-life-extension.pdf
>
> randy, who works for the first isp to deploy ipv6 to customers
>


The PDF is not good advice IMHO.

First is seldom as good as the last.

Re: Netflix banning HE tunnels

[Karl Auer]

On Thu, 2016-06-09 at 20:57 -0700, Randy Bush wrote:
> > > zero interoperability, and no viable migration paths, it's a
> > > Forklift
> > > Upgrade(tm).
> > 
> > You say that with such confidence! Doesn't make it true.
> 
> https://archive.psg.com/120206.nanog-v4-life-extension.pdf

Zero interoperability is technically true. However the two protocols
can live very happily side by side, NOT interfering with each other.
Ricky saying "zero interoperability" is technically true - but not
really relevant.

As to "no viable upgrade paths" you seem to be a good example of NOT
that. Did you replace all your equipment in one great and costly spasm
to achieve IPv6 delivery to customers?

Getting IPv6 up and running is not a simple thing, but nor is it
leaking-blood-from-the ears territory.

"It's a forklift upgrade! There are no viable upgrade paths! Zero
interoperability!" - this is just Chicken Little stuff.

Regards, K.

-- 
~~~
Karl Auer (ka...@biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B
Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4

Re: Netflix banning HE tunnels

[Randy Bush]

>> zero interoperability, and no viable migration paths, it's a Forklift
>> Upgrade(tm).
> 
> You say that with such confidence! Doesn't make it true.

https://archive.psg.com/120206.nanog-v4-life-extension.pdf

randy, who works for the first isp to deploy ipv6 to customers

Re: Netflix banning HE tunnels

[Randy Bush]

>> The average consumer wants a "internet connection".
> And sadly, they haven't a clue what that means.

no; happily.  this is not 1904 where you have to be a mechanic to drive
a car.  i just want my mtv; shut up and make it work.

Re: Netflix banning HE tunnels

[Karl Auer]

On Thu, 2016-06-09 at 22:54 -0400, Ricky Beam wrote:
> zero interoperability, and no viable migration paths,  
> it's a Forklift Upgrade(tm).

You say that with such confidence! Doesn't make it true. Plenty of
people around the world have upgraded, and I bet you couldn't find ONE
that did it as a "forklift upgrade" - or at least not for that purpose
alone.

Of course, the longer you leave it the more likely you will be forced
to do it that way.

All you have to do is some basic design work, get your engineers on
board, make IPv6 part of your normal equipment replacement cycle, and
within three to five years you will be IPv6 capable. Oh wait - you
didn't start doing that fifteen years ago? Ten years ago? Five years
ago? Every year since then? When everyone was telling you you should?
Oh dear...

FX off: "Charlie! Fire up the forklifts! We're gonna need all you got!"

Regards, K.

-- 
~~~
Karl Auer (ka...@biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B
Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4

Re: Netflix banning HE tunnels

[Ricky Beam]

On Thu, 09 Jun 2016 21:41:05 -0400, Baldur Norddahl  
 wrote:



Then he reads on NANOG that since he has IPv6
he can just connect to the camera with that.

...

Only to find the built-in stateful firewall blocks unsolicited inbound  
connections. Now he has to figure out how to manipulate ACLs. Or (more  
likely) he turns that "pesky firewall" off. (followed by the eventual  
hacking of every device he owns.)


NAT may not be security, yet it's the only thing securing billions of  
people.

Re: Netflix banning HE tunnels

[Ricky Beam]

On Thu, 09 Jun 2016 19:17:37 -0400, Mark Andrews  wrote:

The average consumer wants a "internet connection".


And sadly, they haven't a clue what that means. They plug the thing into  
the other thing, and they can click on things in their web browser.  
They're why we have boxes with color coded connectors and cables.



What will happen is that as CGN starts to break things for people
like gamers they will start asking for IPv6, like us network geeks
ask for IPv6.


Correction: after much lamenting and whining to their gaming buddies via  
various forums until someone boils it all down to one word "IPv6". And  
then were back to ape mentality... they don't know what it is, but they  
now know that's what they need. They have, thus, been "educated" -- to a  
microscopic level only a physicist can measure, but they will now demand  
"IPv6 (whatever that is.)"



That being said, those who know what a internet connection should
be delivering should be advocating for the real deal.  It is our
ethical responsability to do this for our customers.


It would be nice to live in a world where that were the case. However, the  
world we live in is run my bean counters, and the marketing department.  
IPv6 is a huge project that is seen by them as an unnecessary expense.  
Everything works right now, right? CGN is easy; it's just one big box. 6RD  
is just one more box, and then it's the customers problem to use it (etc.)  
Companies do what makes them money without costing them money. IPv6 is the  
exact opposite, it costs a lot and generates nothing.


I agree, we should've turned this shit on a decade ago (or more.)

Of course, the whole mess is exactly what you get out of "designed by  
committee". With zero interoperability, and no viable migration paths,  
it's a Forklift Upgrade(tm). People don't do Forklift Upgrades(tm). "So  
you want me to rip out all the token-ring gear and replace it with  
ethernet?" That was a hard sell, and there was interoperability and  
bridging technology. "So you want me to throw away by Novell IPX network  
and replace it with TCP/IP?" While Novell did work over IP in the later  
years, people hung on to their "works perfectly for our needs" IPX  
infrastructure for decades -- IPX WANs, even. (some still exists to this  
day. In fact, the massive kyocera printer here still supports IPX. And  
Appletalk! Holy crap, my horse isn't dead; they still don't talk to each  
other.)

Participation IEEE R8 | TSP 2016 39th Int. Conf. on Telecommunications and Signal Processing | June 27-29, 2016 Vienna, Austria

[TSP 2016]

 


*** CALL FOR PARTICIPATION ***
 



2016 39th International Conference on Telecommunications and Signal 
Processing (TSP)
June 27-29, 2016, Hilton Garden Inn Vienna South, 
Hertha-Firnberg-Strasse 5, 1100 Vienna, Austria

http://tsp.vutbr.cz/

Technically co-sponsored by IEEE Region 8 , EEE 
Austria Section , IEEE Czechoslovakia 
Section , IEEE Czechoslovakia Section SP/CAS/COM 
Joint Chapter , and IEEE Croatia Section 
Communications Chapter 
.


The TSP 2016 Proceedings, containing presented papers at the Conference, 
will be sent for indexing in the IEEE Xplore® 
 digital library registered under _IEEE 
Conference Record #38642 
_, 
SCOPUS , Conference Proceedings Citation Index 
(CPCI) of Thomson Reuters , DBLP 
, and Google 
Scholar  databases.



Dear Colleague,

On behalf of the organizing committee of the conference, we would like 
to invite you to participate in the *2016 39th International Conference 
on Telecommunications and Signal Processing (TSP - 
*http://tsp.vutbr.cz/*)*, which will be held on *June 27-29, 2016, in 
Vienna, Austria*. Continuing the tradition of TSP, the 2016 edition of 
the conference will be an excellent opportunity for networking with 
international experts and to experience a rich mix of excellent 
technical and social programs.


The TSP Conference serves as a premier annual international forum to 
promote the exchange of the latest advances in telecommunication 
technology and signal processing. The aim of the Conference is to bring 
together both novice and experienced scientists, developers, and 
specialists, to meet new colleagues, collect new ideas, and establish 
new cooperation between research groups from universities, research 
centers, and private sectors from the whole Europe, America, Asia, 
Australia, and Africa.


*CONFERENCE PROGRAMME:
*
TSP 2016 programme includes outstanding plenary talks, superb technical 
sessions, and wonderful networking and social events.


*/_Conference highlights include:
_/*
_Invited Keynotes:
_
- /Professor Ray-Guang Cheng/ (Department of Electronic and Computer 
Engineering, National Taiwan University of Science and Technology 
(NTUST), Taipei, Taiwan)

- /Title/: Machine Type Communications: Challenges and Perspectives

- /Professor Ram M. Narayanan/ (Department of Electrical Engineering, 
The Pennsylvania State University, USA)
- /Title/: Sensing and Communications Using Ultrawideband Random Noise 
and Chaotic Waveforms


- /Professor Ahmed Elwakil/ (Department of Electrical and Computer 
Engineering, College of Engineering, University of Sharjah, UAE)
- /Title/: Fractional-Order Circuits and Systems: An Emerging 
Interdisciplinary Research Topic


_Technical Program:
_
23 technical sessions consisting of oral lecture and poster sessions

_Special Sessions:
_*
*/Special Session 1/: Fractional-Order Systems: Theory, Design and 
Applications
/Special Session 2/: Signal and Image Processing for Biometric Human 
Recognition: Theory, Methods, Applications and Systems

/Special Session 3/: Monitoring and Control Based on Image Processing
/Special Session 4/: Photonic Networks and Services: Theory, Design, 
Modeling, and Applications


_Social and Networking Events_:

One per each day.

*CONFERENCE TOPICS:

*Topics of TSP 2016 Conference include:

/AREA 1: Telecommunications
/
1. Information Systems
2. Network Services
3. Network Technologies
4. Telecommunication Systems
5. Modelling, Simulation and Measurement

/AREA 2: Signal Processing
/
6. Analog Signal Processing
7. Audio, Speech and Language Processing
8. Biomedical Signal Processing
9. Digital Signal Processing
10. Image and Video Signal Processing

*COMMITTEES:
*
- Karol Molnár, Honeywell International, s.r.o., Czech Republic, IEEE 
Member - General Chair
- Norbert Herencsár, Brno University of Technology, Czech Republic, IEEE 
Senior Member – IEEE Czechoslovakia Section CAS/COM/SP Joint Chapter 
Chair - Deputy Chair
- Philipp Svoboda, Vienna University of Technology, Austria, IEEE Senior 
Member - Local Arrangement Chair
- Jiří Hošek, Brno University of Technology, Czech Republic, IEEE Member 
- Industrial & Exhibition Chair
- Jaroslav Koton, Brno University of Technology, Czech Republic, IEEE 
Senior Member - Publication Chair

- Nándor Mátrai, Asszisztencia Congress Bureau, Hungary - Finance Chair

/Steering 

Telia

[Anthony Francis - Handy Networks LLC]

Hello All,

  It looks like they resolved the issue:


“Dear Customer,

Our core team has resolved an issue on our backbone causing U.S. customers 
packet loss. The root cause analysis will follow and we expect no further 
packet loss due to this issue.”


—
Anthony Francis  // Handy Networks LLC
Hosting Support Manager
Providing Dedicated Server, IaaS and Colocation Hosting Solutions
Tel: 303-414-6904  |  Fax: 303-414-6912
www.handynetworks.com

Telia

[Anthony Francis - Handy Networks LLC]

Hello All,

   Telia is having a major outage and they have confirmed with us the same. If 
you are peering with Telia you may wish to shut down your session until the 
issue is resolved.

—
Anthony Francis  // Handy Networks LLC
Hosting Support Manager
Providing Dedicated Server, IaaS and Colocation Hosting Solutions
Tel: 303-414-6904  |  Fax: 303-414-6912
www.handynetworks.com

Extra Fairmont Rooms

[Brandon Ross]

I've ended up with some extra room reservations at the Fairmont Chicago. 
If you can make use of any of these reservations, send me a direct email 
with the name you'd like me to put on the room.  First come, first served, 
so if your primary choice(s) aren't available, let me know if you have a 
second choice.  I'll reply with the confirmation number so you can call 
the hotel and guarantee the room with your credit card.


6/16-17 $242 Fairmont Room with King Bed
6/11-17 $299 Deluxe Room with King Bed
6/15-16 $278 Fairmont PURE Room King NS
6/15-16 $260 Fairmont Double/Double NS

--
Brandon Ross  Yahoo & AIM:  BrandonNRoss
+1-404-635-6667ICQ:  2269442
 Skype:  brandonross
Schedule a meeting:  http://www.doodle.com/bross

Re: Netflix banning HE tunnels

[Baldur Norddahl]

On 10 June 2016 at 01:17, Mark Andrews  wrote:

> The average consumer wants a "internet connection".  They don't
> care if it is IPv4, IPv6 or IPvX.  They just want the bits to move.
> What will happen is that as CGN starts to break things for people
> like gamers they will start asking for IPv6, like us network geeks
> ask for IPv6.
>

The use case is a user that got a CGN solution plus IPv6. He wants to view
images from his home surveillance camera, so that he can tell that the cat
is still doing ok. His friends tells him to do a port forward, but that is
not possible due to the CGN. Then he reads on NANOG that since he has IPv6
he can just connect to the camera with that.

Except few to none cameras come with IPv6.

This is the sad state of things currently :-(.

Regards,

Baldur

Re: Netflix banning HE tunnels

[Mark Andrews]

In message , "Ricky Beam" writes:
> On Thu, 09 Jun 2016 13:32:24 -0400, Adam Rothschild   
> wrote:
> > How can we, as a community, help move the needle
> > on v6 deployment on broadband networks, in cases where competitive
> > forces and market pressure don't exist?
> 
> You left out "consumer demand". And I would add consumer knowledge as well  
> -- there won't be any demand until one knows to ask (it's cablecards all  
> over again.) There are 7 billion people on Earth. I suspect it's a stretch  
> to say even 100,000 of them understand IPv6. While there are a few ISPs  
> who "have" IPv6, many of them have done so mostly for show -- World IPv6  
> Day marketing ploy[*].

The average consumer wants a "internet connection".  They don't
care if it is IPv4, IPv6 or IPvX.  They just want the bits to move.
What will happen is that as CGN starts to break things for people
like gamers they will start asking for IPv6, like us network geeks
ask for IPv6.

The average consumer doesn't know what they have been sold does not
deliver a real internet connection where every every machine is
addressable.

That being said, those who know what a internet connection should
be delivering should be advocating for the real deal.  It is our
ethical responsability to do this for our customers.

> For now, we'll have to continue the policy of public shaming...
> 
> Despite TWC's claims ("IPv6 has been enabled on 100% of our cable Internet  
> network.")  
> [http://www.timewarnercable.com/en/support/faqs/faqs-internet/ipv6/why-don_t-
> i-have-ipv6-yet-.html]  
> there's a very long list of exceptions... like: it's not been enabled on  
> *your* headend, or *your* modem doesn't have it enabled, or we turned if  
> off on that modem due to firmware bugs for which we've had fixes for over  
> a year, or you're a business account that hasn't had it enabled, or you're  
> a "powered by" customer for whom the banner ISP hasn't bothered to assign  
> a prefix (*cough* f'ing Earthlink *cough*)
> 
> In fact, Earthlink's only IPv6 presence, ever, was the pet project of a  
> single engineer. He was kicked out in 2008. The kludge ("auto-tunnel")  
> continued to function for a few years before the hardware was turn off,  
> recycled, etc. And then the entire research site disappear around 2010.  
> Btw, they're still announcing that prefix  
> [http://bgp.he.net/net/2001:4840::/32#_irr]
> 
> --Ricky
> 
> [*] I know my company did. Our "IPv6 Presence" was a VM somewhere running  
> nginx to proxy to the (amazon hosted) IPv4 sites. And it was gone the next  
> day.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Netflix banning HE tunnels

[Ricky Beam]

On Thu, 09 Jun 2016 13:32:24 -0400, Adam Rothschild   
wrote:

How can we, as a community, help move the needle
on v6 deployment on broadband networks, in cases where competitive
forces and market pressure don't exist?


You left out "consumer demand". And I would add consumer knowledge as well  
-- there won't be any demand until one knows to ask (it's cablecards all  
over again.) There are 7 billion people on Earth. I suspect it's a stretch  
to say even 100,000 of them understand IPv6. While there are a few ISPs  
who "have" IPv6, many of them have done so mostly for show -- World IPv6  
Day marketing ploy[*].


For now, we'll have to continue the policy of public shaming...

Despite TWC's claims ("IPv6 has been enabled on 100% of our cable Internet  
network.")  
[http://www.timewarnercable.com/en/support/faqs/faqs-internet/ipv6/why-don_t-i-have-ipv6-yet-.html]  
there's a very long list of exceptions... like: it's not been enabled on  
*your* headend, or *your* modem doesn't have it enabled, or we turned if  
off on that modem due to firmware bugs for which we've had fixes for over  
a year, or you're a business account that hasn't had it enabled, or you're  
a "powered by" customer for whom the banner ISP hasn't bothered to assign  
a prefix (*cough* f'ing Earthlink *cough*)


In fact, Earthlink's only IPv6 presence, ever, was the pet project of a  
single engineer. He was kicked out in 2008. The kludge ("auto-tunnel")  
continued to function for a few years before the hardware was turn off,  
recycled, etc. And then the entire research site disappear around 2010.  
Btw, they're still announcing that prefix  
[http://bgp.he.net/net/2001:4840::/32#_irr]


--Ricky

[*] I know my company did. Our "IPv6 Presence" was a VM somewhere running  
nginx to proxy to the (amazon hosted) IPv4 sites. And it was gone the next  
day.

Re: intra-AS messaging for route leak prevention

[Sriram, Kotikalapudi (Fed)]

This is great...the kind of inputs/insights I was hoping for.
Thank you :)

Sriram


From: Mark Tinka 
Sent: Wednesday, June 8, 2016 9:24 AM
To: nanog-p...@rsuc.gweep.net; Sriram, Kotikalapudi (Fed)
Cc: Job Snijders; nanog@nanog.org
Subject: Re: intra-AS messaging for route leak prevention

On 8/Jun/16 14:48, Joe Provo wrote:

>
> "There are more routing policies in heavan and earth, Sriram
>  Than are dreamt of in your draft."
>
> But in my experience, community tagging is by far the widest
> deployment due to the broad support and extent of information
> which can be carried.  It is useful to note that AS_PATH if
> often also involved on egress decisions.

Agree.

We use BGP communities extensively on all eBGP sessions to identify
upstreams, peers, customers, special partners, e.t.c., on the inbound
routing policy.

Outbound routing policies will depend on the type of neighbor, i.e.,
upstream, peer, customer, special partner, e.t.c. At any rate, we use
communities to determine what routes will be announced to what eBGP
neighbor. Those communities will need to match the intended source of
the route at some other point in the network.

The only time we look at prefix lists is to ensure we send (or accept)
nothing longer than a /24 (IPv4) or a /48 (IPv6) to (and from) an eBGP
neighbor of any kind. That said, further granularity in the outbound
routing policy toward upstreams will allow for transmission of
longest-match (/32 IPv4 and /128 IPv6) to support RTBH requirements.
This is a co-ordinated routing policy, so it is not harmful to us, our
upstreams or the wider Internet. We'd also accept these prefix lengths
from BGP customers as part of their standard RTBH capability they get
when they buy IP Transit from us; again, highly controlled and
co-ordinated to never cause any harm to us, the customer or the wider
Internet, while still being 100% functional for the customer.

Ultimately, once a routing policy is in place on a specific router, we
are never touching that router again as the edge moves around, i.e.,
customers, peers, special partners, e.t.c., come on-board, move around,
e.t.c. This creates natural safe guards against cock-ups, although the
goal is always to eliminate cock-ups from the get-go (automation of
repetitive provisioning tasks makes this goal easier to attain).

Coupled with our insistence on creating matching prefix and AS_PATH
filters for all customers (after being checked against the relevant RIR
WHOIS database to avoid hijack), we've been fortunate to never be in a
position where our network is leaking routes, unintentionally or
otherwise. Work continues to further harden this so that it never happens.

Mark.

Re: Netflix banning HE tunnels

[Cryptographrix]

I suspect we should just accept that IPv6 is never actually happening with
all this infighting of its own very vocal proponents.

On Thu, Jun 9, 2016 at 2:49 PM Steve Mikulasik 
wrote:

> https://i.imgur.com/LvVHJZf.png
>
> I had to make this, talking about IPv6 or geo-ip in nanog is like throwing
> blood in the water :)
>
>
>
>
>

novell.com

[John Zettlemoyer]

Could someone from Novell / Attachmate Corporation contact me off list.
We are showing high latency getting to  www.novell.com and dropped traffic.  
Currently, we are unable to reach anything at novell.com
 
15   156 ms   371 ms   229 ms  tg9-1.ar10.lsvlnv23.integra.net [209.63.100.146]
1687 ms86 ms86 ms  67.138.209.58
17   468 ms   486 ms * 192.94.118.247
18 * ** Request timed out.
19   100 ms   100 ms   100 ms  vibe.novell.com [130.57.66.5]
 
Thank you
 
 
John Zettlemoyer 
Sr. Director of I.T. Infrastructure ::  WCiT - West-Canaan LLC
856.310.1375 x221 :: j...@wcit.net :: www.wcit.net
Colocation, Cloud, Dedicated, Email, Backups, Access, Networks, etc.
 
"I keep the lights blinking out of sequence!"
 
 

RE: Netflix banning HE tunnels

[Steve Mikulasik]

https://i.imgur.com/LvVHJZf.png

I had to make this, talking about IPv6 or geo-ip in nanog is like throwing 
blood in the water :)

Re: Netflix banning HE tunnels

[Adam Rothschild]

I think tunnelbroker.net is an great community service, and a
significant factor in global IPv6 adoption.  For one, it's allowed me
to experiment with v6 from my home ~5 miles from NYC, where there are
still no options for native connectivity.  Hats off to Mike and the
entire HE team for maintaining this excellent resource, without much
thanks or compensation.

With that said, it's not perfect.  Licensing restrictions aside, I can
appreciate a content provider prohibiting some tunneled connections,
out of basic QoE concern.  Even if they're able to manage their path
to the tunnel endpoint, they have no visibility into the connection
between the broadband eyeball and the endpoint, which could
be/commonly is a point of saturation.  As best I can tell, there isn't
even a direct adjacency between 2906 and 6939, further obfuscating
things.  While Happy Eyeballs (carefully not abbreviating as "HE" to
add to confusion :-) certainly helps, it's not a panacea for dealing
with intermittent loss issues, nor is it fully supported on a broad
spectrum of client implementations.

Rather than debate the relative merits and production-readiness of a
free tunneling service, we should ask ourselves why this is still a
thing, here in 2016.  How can we, as a community, help move the needle
on v6 deployment on broadband networks, in cases where competitive
forces and market pressure don't exist?

$0.02,
-a


On Thu, Jun 9, 2016 at 11:35 AM, Sander Steffann  wrote:
> Hi,
>
>> Op 8 jun. 2016, om 23:39 heeft John Lightfoot  het 
>> volgende geschreven:
>>
>> How about:
>>
>> Dear Netflix network engineer who’s on the NANOG list.  Could you please get 
>> Netflix to fall back to ipv4
>
> Just for geolocation please, the streaming works fine over IPv6 :)
>
>> if you block your customer’s ipv6 because it’s in an HE tunnel?  Lots of 
>> people who want to watch Netflix, be able to reach the whole internet, and 
>> have Verizon FiOS would really appreciate it.
>
> Cheers,
> Sander
>

Re: Monitoring system recommendation

[Dan Lacey]

Yes, but depends on HW. They support some pretty huge environments.
You have to have "enough" IOPs to keep up with the polling, DB and RRD data.
Then there will never be a "heavy" load...

I would contact them and based on your needs ask them what HW you will 
need for your implementation.
You can get real world info from the mailing list: 
https://sourceforge.net/p/opennms/mailman/

I would suggest the opennms-discuss list.

On 6/8/16 4:39 PM, Jeff wrote:

On 06/06/2016 10:18 AM, Manuel Marín wrote:

Dear Nanog community

[...snipped...]

Your input is really appreciated it

Thank you and have a great day

Regards


I have not used openNMS in production.. does it work well under heavy load?

regards,
J

Re: Netflix banning HE tunnels

[Sander Steffann]

Hi,

> Op 8 jun. 2016, om 23:39 heeft John Lightfoot  het 
> volgende geschreven:
> 
> How about:
> 
> Dear Netflix network engineer who’s on the NANOG list.  Could you please get 
> Netflix to fall back to ipv4

Just for geolocation please, the streaming works fine over IPv6 :)

> if you block your customer’s ipv6 because it’s in an HE tunnel?  Lots of 
> people who want to watch Netflix, be able to reach the whole internet, and 
> have Verizon FiOS would really appreciate it.

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail

RE: Netflix banning HE tunnels

[Matthew Huff]

Your correct. I misread your email. Not enough blood in my caffeine stream yet. 
I think your idea of a button and/or a daily/weekly update to maxmind based on 
the source IPv4 address would be a good idea regardless of Netflix.


Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff| Fax:   914-694-5669

From: Michael Still [mailto:stillwa...@gmail.com]
Sent: Thursday, June 9, 2016 10:33 AM
To: Matthew Huff 
Cc: John Lightfoot ; North American Network Operators' 
Group 
Subject: Re: Netflix banning HE tunnels

Uhm I think you misunderstood me. What you describe matches what I described. I 
never suggested the user can override it with it another value, I am suggesting 
that a user may want to keep it to whatever default value it is as a matter of 
privacy concerns. Otherwise use the IPv4 tunnel end point IP.

As for the point about people moving around frequently I would consider that a 
pretty far reaching use case and most likely not worth considering any action 
for.


On Thu, Jun 9, 2016 at 10:19 AM, Matthew Huff 
> wrote:
I think you are missing the point. The problem is not that the GeoIP info is 
missing, the problem with the HE.tunnel is that the GeoIP is not set by the 
provider by verifiable means. Letting end-users set their GeoIP information is 
a non-starter for the content provider and they would still require a ban.

A solution would be for HE to automatically set the IPv6 geoip based on the 
geoip of the IPv4 source address with no user overrides. Since the whole 
process would be fragile (people change their IPv4 source address frequently 
when travelling, etc...) and the delay it takes to put the GeoIP into maxmind's 
database, etc..., I don't know how well it would work, but it would probably be 
the best bet.


Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff| Fax:   914-694-5669


> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] 
> On Behalf Of Michael Still
> Sent: Thursday, June 9, 2016 10:10 AM
> To: John Lightfoot >
> Cc: North American Network Operators' Group 
> >
> Subject: Re: Netflix banning HE tunnels
>
> I wonder how hard it would be for HE to implement some button on their
> tunnel portal that when selected will update Maxmind's (or whatever)
> geolocation for their allocated IPv6 prefixes to match the results
> returned
> when querying for their IPv4 tunnel end point address...
>
> I would suggest to make it optional since some may not want to have
> this
> functionality by default but if you are dying for netflix and are in
> whatever geolocation netflix deems acceptable this may solve the issue.
>
>
>
> On Wed, Jun 8, 2016 at 5:39 PM, John Lightfoot 
> >
> wrote:
>
> > How about:
> >
> > Dear Netflix network engineer who’s on the NANOG list.  Could you
> please
> > get Netflix to fall back to ipv4 if you block your customer’s ipv6
> because
> > it’s in an HE tunnel?  Lots of people who want to watch Netflix, be
> able to
> > reach the whole internet, and have Verizon FiOS would really
> appreciate it.
> >
> > Thanks,
> > John
> >
> > John Lightoot
> >
> >
> >
>
>
> --
> [stillwa...@gmail.com ~]$ cat .signature
> cat: .signature: No such file or directory
> [stillwa...@gmail.com ~]$



--
[stillwa...@gmail.com ~]$ cat .signature
cat: .signature: No such file or directory
[stillwa...@gmail.com ~]$

Re: Netflix banning HE tunnels

[Michael Still]

Uhm I think you misunderstood me. What you describe matches what I
described. I never suggested the user can override it with it another
value, I am suggesting that a user may want to keep it to whatever default
value it is as a matter of privacy concerns. Otherwise use the IPv4 tunnel
end point IP.

As for the point about people moving around frequently I would consider
that a pretty far reaching use case and most likely not worth considering
any action for.


On Thu, Jun 9, 2016 at 10:19 AM, Matthew Huff  wrote:

> I think you are missing the point. The problem is not that the GeoIP info
> is missing, the problem with the HE.tunnel is that the GeoIP is not set by
> the provider by verifiable means. Letting end-users set their GeoIP
> information is a non-starter for the content provider and they would still
> require a ban.
>
> A solution would be for HE to automatically set the IPv6 geoip based on
> the geoip of the IPv4 source address with no user overrides. Since the
> whole process would be fragile (people change their IPv4 source address
> frequently when travelling, etc...) and the delay it takes to put the GeoIP
> into maxmind's database, etc..., I don't know how well it would work, but
> it would probably be the best bet.
>
> 
> Matthew Huff | 1 Manhattanville Rd
> Director of Operations   | Purchase, NY 10577
> OTA Management LLC   | Phone: 914-460-4039
> aim: matthewbhuff| Fax:   914-694-5669
>
>
> > -Original Message-
> > From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Michael Still
> > Sent: Thursday, June 9, 2016 10:10 AM
> > To: John Lightfoot 
> > Cc: North American Network Operators' Group 
> > Subject: Re: Netflix banning HE tunnels
> >
> > I wonder how hard it would be for HE to implement some button on their
> > tunnel portal that when selected will update Maxmind's (or whatever)
> > geolocation for their allocated IPv6 prefixes to match the results
> > returned
> > when querying for their IPv4 tunnel end point address...
> >
> > I would suggest to make it optional since some may not want to have
> > this
> > functionality by default but if you are dying for netflix and are in
> > whatever geolocation netflix deems acceptable this may solve the issue.
> >
> >
> >
> > On Wed, Jun 8, 2016 at 5:39 PM, John Lightfoot 
> > wrote:
> >
> > > How about:
> > >
> > > Dear Netflix network engineer who’s on the NANOG list.  Could you
> > please
> > > get Netflix to fall back to ipv4 if you block your customer’s ipv6
> > because
> > > it’s in an HE tunnel?  Lots of people who want to watch Netflix, be
> > able to
> > > reach the whole internet, and have Verizon FiOS would really
> > appreciate it.
> > >
> > > Thanks,
> > > John
> > >
> > > John Lightoot
> > >
> > >
> > >
> >
> >
> > --
> > [stillwa...@gmail.com ~]$ cat .signature
> > cat: .signature: No such file or directory
> > [stillwa...@gmail.com ~]$
>



-- 
[stillwa...@gmail.com ~]$ cat .signature
cat: .signature: No such file or directory
[stillwa...@gmail.com ~]$

RE: Netflix banning HE tunnels

[Matthew Huff]

I think you are missing the point. The problem is not that the GeoIP info is 
missing, the problem with the HE.tunnel is that the GeoIP is not set by the 
provider by verifiable means. Letting end-users set their GeoIP information is 
a non-starter for the content provider and they would still require a ban.

A solution would be for HE to automatically set the IPv6 geoip based on the 
geoip of the IPv4 source address with no user overrides. Since the whole 
process would be fragile (people change their IPv4 source address frequently 
when travelling, etc...) and the delay it takes to put the GeoIP into maxmind's 
database, etc..., I don't know how well it would work, but it would probably be 
the best bet.


Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-694-5669


> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Michael Still
> Sent: Thursday, June 9, 2016 10:10 AM
> To: John Lightfoot 
> Cc: North American Network Operators' Group 
> Subject: Re: Netflix banning HE tunnels
> 
> I wonder how hard it would be for HE to implement some button on their
> tunnel portal that when selected will update Maxmind's (or whatever)
> geolocation for their allocated IPv6 prefixes to match the results
> returned
> when querying for their IPv4 tunnel end point address...
> 
> I would suggest to make it optional since some may not want to have
> this
> functionality by default but if you are dying for netflix and are in
> whatever geolocation netflix deems acceptable this may solve the issue.
> 
> 
> 
> On Wed, Jun 8, 2016 at 5:39 PM, John Lightfoot 
> wrote:
> 
> > How about:
> >
> > Dear Netflix network engineer who’s on the NANOG list.  Could you
> please
> > get Netflix to fall back to ipv4 if you block your customer’s ipv6
> because
> > it’s in an HE tunnel?  Lots of people who want to watch Netflix, be
> able to
> > reach the whole internet, and have Verizon FiOS would really
> appreciate it.
> >
> > Thanks,
> > John
> >
> > John Lightoot
> >
> >
> >
> 
> 
> --
> [stillwa...@gmail.com ~]$ cat .signature
> cat: .signature: No such file or directory
> [stillwa...@gmail.com ~]$

Re: Netflix banning HE tunnels

[Michael Still]

I wonder how hard it would be for HE to implement some button on their
tunnel portal that when selected will update Maxmind's (or whatever)
geolocation for their allocated IPv6 prefixes to match the results returned
when querying for their IPv4 tunnel end point address...

I would suggest to make it optional since some may not want to have this
functionality by default but if you are dying for netflix and are in
whatever geolocation netflix deems acceptable this may solve the issue.



On Wed, Jun 8, 2016 at 5:39 PM, John Lightfoot  wrote:

> How about:
>
> Dear Netflix network engineer who’s on the NANOG list.  Could you please
> get Netflix to fall back to ipv4 if you block your customer’s ipv6 because
> it’s in an HE tunnel?  Lots of people who want to watch Netflix, be able to
> reach the whole internet, and have Verizon FiOS would really appreciate it.
>
> Thanks,
> John
>
> John Lightoot
>
>
>


-- 
[stillwa...@gmail.com ~]$ cat .signature
cat: .signature: No such file or directory
[stillwa...@gmail.com ~]$

RE: Webmail / IMAPS software for end-user clients in 2016

[Coy Hile]

I like horde (with dove cot doing imaps) because it speaks ActiveSync  
natively. 



Sent via the Samsung GALAXY S® 5, an AT 4G LTE smartphone

 Original message 
From: alvin nanog 
Date: 6/8/2016  21:37  (GMT-05:00)
To: eric.kuh...@gmail.com
Cc: nanog@nanog.org
Subject: Re: Webmail / IMAPS software for end-user clients in 2016



hi ya

On 06/08/16 at 06:06pm, Eric Kuhnke wrote:

If you had to put up a public facing webmail interface for people to use,
and maintain it for the foreseeable future (5-6 years), what would you use?

Roundcube?
https://roundcube.net/

- good


Rainloop?
http://www.rainloop.net/

- never used
- w/o db support, how you maintain a (real) list of x,000 users and pwd


Something else?


http://squirrlemail.org
- good

http://openwebmail.org/
- least effort to get webmail running ( esp if time is limited )

http://horde.org
- possibly confusing install process

-
imaps from doveocot.org
( note differences between dovecot-1.x vs dovecot-2.x )


Requirements:
Needs to be open souce and GPL, BSD or Apache licensed

Email storage will be accessed via IMAP/TLS1.2

Runs on a Debian based platform with apache2 or nginx

Desktop browser CSS and mobile device CSS/HTML functionality on 4" to 7"
size screens with Chrome and Safari


- you probably want support for your favorite sql app
- you probably want support for your favorite anti-virus app
- you probably want support for your favorite anti-spam app

http://networknightmare.net/WebMail/

magic pixie dust
alvin
# DDoS-Mitigator.net
#

Re: Netflix VPN detection - actual engineer needed

[Antonio Querubin]

On Wed, 8 Jun 2016, Baldur Norddahl wrote:

A start would be blocking 2620:108:700f::/64 as discovered by a simple DNS 
lookup on netflix.com. I am not running a HE tunnel (I got native IPv6) and I 
am not blocked from accessing Netflix over IPv6 so can't really try it. I am


I sent some email earlier that that does work using a host firewall on an 
affected client.  For some reason my email is in hold state - not sure 
what's up with that.


Antonio Querubin
e-mail:  t...@lavanauts.org
xmpp:  antonioqueru...@gmail.com

Re: Netflix VPN detection - actual engineer needed

[Antonio Querubin]

On Wed, 8 Jun 2016, Mark Andrews wrote:


And which set of prefixes is that?  How often do they change? etc.


Apparently there's only 2620:108:7000::/44 and I doubt it'll change often. 
An associate actually reported this problem to me today.  I ended up just 
installing a host firewall rule on his Netflix viewer and made the problem 
go away.


Antonio Querubin
e-mail:  t...@lavanauts.org
xmpp:  antonioqueru...@gmail.com

Re: Bogon ASN Filter Policy

[Thomas King]

Hi all,

a quick update from the DE-CIX side: we see in total 25 routes containing bogon 
ASNs at all the route servers at all DE-CIX IXPs (so far we just filtered the 
private ASN space). We directly contacted the customers sending the routes to 
inform them about the upcoming change in filtering.

Best regards,
Thomas


> On 08 Jun 2016, at 15:56, Michael Hare  wrote:
> 
> I'm not against the theory of what is being proposed, but I was surprised to 
> see little discussion of this announcement on list.
> 
> Upon examination on my view of the DFZ from AS3128 I see over 400 upstream 
> routes falling into this category, mostly in the 64512 - 65534 range.  Based 
> on our flow bandwidth stats we chose to reach out to several origin ASN, two 
> fairly well known, as a courtesy.
> 
> For the *TT's who are planning on implementing shortly, have you went through 
> a similar diagnostic effort and what might you share or report on such 
> endeavors?
> 
> -Michael



smime.p7s
Description: S/MIME cryptographic signature

Re: Netflix banning HE tunnels

[John Lightfoot]

How about:

Dear Netflix network engineer who’s on the NANOG list.  Could you please get 
Netflix to fall back to ipv4 if you block your customer’s ipv6 because it’s in 
an HE tunnel?  Lots of people who want to watch Netflix, be able to reach the 
whole internet, and have Verizon FiOS would really appreciate it.

Thanks,
John

John Lightoot

Re: Monitoring system recommendation

[Jeff]

On 06/06/2016 10:18 AM, Manuel Marín wrote:
> Dear Nanog community
[...snipped...]
> Your input is really appreciated it
> 
> Thank you and have a great day
> 
> Regards
> 

I have not used openNMS in production.. does it work well under heavy load?

regards,
J

Re: Webmail / IMAPS software for end-user clients in 2016

[Gavin Henry]

> On Wed, Jun 8, 2016 at 8:55 PM, William Herrin  wrote:
>
> > On Wed, Jun 8, 2016 at 9:37 PM, alvin nanog
> >  wrote:
> > >> Rainloop?
> > >> http://www.rainloop.net/
> > > - never used
> > > - w/o db support, how you maintain a (real) list of x,000 users and
pwd
> >
> > "Direct access to mail server is used (mails are not stored locally on
> > web server)."

I never see LDAP mentioned much. Dovecot has excellent support for it and
many other ways to authenticate a "user".

Squirelmail can too. Plus you can use all the nss/pam options instead of
native support.

Sogo is a nice option https://sogo.nu/

We're loving the dovecot replication too. A long time user.

--
Kind Regards,
Gavin Henry.

Winner of the Best Business ITSP (Medium Enterprise) 2016!
http://www.surevoip.co.uk/2016-best-provider