Re: How to force rapid ipv6 adoption

[Wolfgang S. Rupprecht]

> (IPv6 ONLY insisting on manufacturers implementing 464XLAT is inferior
> in every way to dual stack,

There is one way it is superior; it rewards web and other content sites
that implement IPv6.  Unlike dual stack, it applies pressure where it is
needed, on the IPv4-only sites.   Grottiness can be a good thing.

-wolfgang

Re: AW: AW: AW: /27 the new /24

[James Jun]

On Sat, Oct 03, 2015 at 08:10:36AM -0500, Mike Hammett wrote:
> 
> People keep thinking I want Level 3 to replace a loaded 6500 with a CCR and 
> that's simply not what I'm saying at all. The point of rattling off the 
> newer\smaller hardware was to say that if the site doesn't require 40G\100G, 
> doesn't have the revenue to support an MX480, etc. you should put in a 
> smaller\cheaper box. 
> Cost is a non-issue at that point because the smaller gear that's all you 
> need will have far less operational cost. Someone thought a particular POP 
> was going to be a big hit... and wasn't. 

In an SP environment, there is an escalating operating cost and network 
complexity to having small full-featured routers (ie. MX80, ASR9001, CER2k, 
etc) at every data center, POP or anywhere you need to terminate customers.  
The reality is that small routers (even if you were to use ghetto routers) have 
poor economics in port density.  It's feasible for a startup ISP to spam MX80 
or equivalent anytime they need more ports, but there comes a point where 
plopping a big chassis is the way to go.

At my place, we started with MX80s to cheap out on router ports anytime we had 
to light a data center.  That only got us far and we ended up having to migrate 
to ASR 9010s and start phasing out small routers.  The increasing complexity of 
having dozens of small routers and managing LSP mesh to remainder of the 
network is ugly.  Moreover, full-table BGP routers are also the places where 
you exercise edge policy with complex routing policies.  Even with automation, 
managing dozens of those in a region that could have been served by only 2 
routers is annoying.  It's easier to haul IP customers to fewer, but more 
reliable large-chassis platforms and use packet-optical network to get to the 
customer premise.

Between the above and the lack of control-plane redundancy on most small 
routers, there are operational complexities & economic realities to keep in 
mind; it's not strictly about whether a site requires 40G/100G.  


> On the flip side, if there are 200 ports of customers chances are you need 
> the big interfaces that aren't on the old boxes. You have the bigger revenue. 
> Heck, the new big boxes probably still use less power than the old big boxes 
> anyway. 

The idea has its merits, however in practice, it isn't feasible.  People don't 
put in line cards into their router with expectation that they need to be 
replaced 2 years down the road because FIB TCAM ran out.  Even if you have the 
revenue to justify new line cards, constant migration of customer interfaces 
means disruptive maintenance for that customer.  We'd prefer IP network to be 
as reliable as dial-tone, if possible.

The global routing table is approaching 600k today.  Lot of line cards in 
installed base today only handle ~1.0/1.3 to ~1.8 million IPv4.  When you start 
replacing those line cards (and mind you, a 24x10GE line card has a list price 
running into $300k range), the next logical level is 4 million IPv4.  With all 
the deaggs with /24s, just how long of time are we going to have with /27 
explosion before 4 million FIB runs out of space?

I can see /25 being contemplated, but the cost of moving to /27 just isn't 
worth it at the moment.


> 
> What I learned from this thread: Once you mention MT\UBNT routers, people 
> assume you're using a MT\UBNT hammer everywhere. 

I'm not aware of any carrier-grade network that operates on these things.


Best,
james

Re: Inexpensive probes for automated bandwidth testing purposes

[Alan Buxey]

One of the small microPC solutions. Depending on what you want to test (eg 
bandwidth) you may find platforms like raspberrypi too limited. Intel NUC or 
LIVA platforms? 

https://www.perfsonar.net/deploy/hardware-selection/low-cost-hardware/

alan

Re: /27 the new /24

[Mel Beckman]

Keep in mind that IPv6 has IPSec VPN built into the protocol. It doesn't need 
to be in the router. 

Unlike IPv4, where the IPSec VPN protocol is an add-on, optional service, with 
IPv6 it's built into every device, because IPsec is a mandatory component for 
IPv6, and therefore, the IPsec security model is required to be supported for 
all IPv6 implementations. 

Thus it is a true end-to-end secure transport between two nodes -- even when 
those nodes are behind a firewall. You can still created IPv6 VPNs from 
site-to-site (called "tunnel mode"), but the idea with IPv6 is that since you 
can directly encrypt every TCP session, eventually the need for tunnels will 
diminish, if not go away completely. 

Interestingly, IPsec came out of funding from Clinton administration for 
securely hosting the whitehouse.gov email server. Trusted Information Systems 
software engineer Wei Xu started researching IP security methods in July 1994, 
and ultimately developed the first rendition of IPSec. He ported it to several 
server OSes of the time. 

 -mel beckman

> On Oct 4, 2015, at 6:41 AM, Matthias Leisi  wrote:
> 
> The built-in VPN which only supports IPv4 (that one specifically on an Asus 
> router).

Re: /27 the new /24

[Mel Beckman]

If it doesn't support IPSec, it's not really IPv6. Just as if it failed to 
support any other mandatory IPv6 specification, such as RA. 

There's really no excuse for not supporting IPSec, as it's a widely available 
open source component that costs nothing to incorporate into an IPv6 stack. 

Your observation simply means that users must be informed when buying IPv6 
devices, just as they must with any product. You can buy either genuine IPv6 or 
half-baked IPv6 products. When I speak of IPv6, I speak only of the genuine 
article. 

 -mel beckman

On Oct 4, 2015, at 7:41 AM, "sth...@nethelp.no"  wrote:

>> Keep in mind that IPv6 has IPSec VPN built into the protocol. It doesn't 
>> need to be in the router. 
>> 
>> Unlike IPv4, where the IPSec VPN protocol is an add-on, optional service, 
>> with IPv6 it's built into every device, because IPsec is a mandatory 
>> component for IPv6, and therefore, the IPsec security model is required to 
>> be supported for all IPv6 implementations.
> 
> If you really believe all IPv6 devices support IPsec, I can only
> conclude that your IPv6 experience is limited...
> 
> Steinar Haug, Nethelp consulting, sth...@nethelp.no

Re: /27 the new /24

[Mel Beckman]

Randy,

Your claim is a red herring. IPSec has nothing to do with IPv6 deployment. 
Deployment doesn't require global IPSec, which need only reside in endpoint 
nodes. It's not needed at all in the routjg and distribution infrastructure, 
which is where deployment happens

The vast majority of IPv6 nodes -- which is where the IPSec requirement exists 
-- have IPSec built in: Linux, Mac OSX, and Windows. Devices that sometimes act 
as nodes, such as firewalls terminating IPSec tunnels, also obviously need 
IPSec. Devices that are simply IPv6 pass-through, such as consumer-grade 
routers, don't.

Users can buy whatever level of functionality they need at the edges. If you 
don't need IPSec tunnel support in your firewall, you can buy one without it. 
Deployment cares nothing about IPSec.

 -mel beckman

On Oct 4, 2015, at 8:05 AM, Randy Bush > 
wrote:

If it doesn't support IPSec, it's not really IPv6.

by that criterion, ipv6 deployment is effectively zero

Re: /27 the new /24

[Sander Steffann]

Hi,

> Op 4 okt. 2015, om 16:52 heeft Mel Beckman  het volgende 
> geschreven:
> 
> If it doesn't support IPSec, it's not really IPv6. Just as if it failed to 
> support any other mandatory IPv6 specification, such as RA. 

I think you're still looking at an old version of the IPv6 Node Requirements. 
Check https://tools.ietf.org/html/rfc6434#section-11, specifically this bit:

"""
Previously, IPv6 mandated implementation of IPsec and recommended the key 
management approach of IKE.  This document updates that recommendation by 
making support of the IPsec Architecture a SHOULD for all IPv6 nodes.
"""

This was published in December 2011.

Cheers,
Sander

Agenda

[John Springer]

The times for tonight's event differ from the guidebook to the online 
version @ nanog


nanog   6-8PM
guidebook   7-11PM

Which is correct?

Re: /27 the new /24

[Denis Fondras]

> Building a secure firewall takes more than just knowing how to issue
> ip6table commands; one also needs to know exactly what goes into those
> commands.  NANOG concentrates on network operators who need to provide a
> good Internet experience to all their downstream customers, which is why I
> see the bias toward openness...as it should be.  Those of us who run edge
> networks have different problems to solve.
> 

NIST has very good publication on this subject :
http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf
(Table 3-7 is a must read for any IPv6 newbie)

Denis

Re: /27 the new /24

[Mel Beckman]

I recommend any of a number of online courses for a quick understanding of 
IPv6. But nothing beats making your own IPv6 lab and getting hands-on 
experience. Here's a course I built walking you through that process:

http://windowsitpro.com/build-your-own-ipv6-lab-and-become-ipv6-guru-demand

 -mel beckman

> On Oct 4, 2015, at 7:49 AM, Stephen Satchell  wrote:
> 
>> On 10/04/2015 06:40 AM, Matthias Leisi wrote:
>> Fully agree. But the current state of IPv6 outside "professional“
>> networks/devices is sincerely limited by a lot of poor CPE and
>> consumer device implementations.
> 
> I have to ask:  where is the book _IPv6 for Dummies_ or equivalent?
> 
> Specifically, is http://www.xnetworks.es/contents/Infoblox/IPv6forDummies.pdf 
> any good? (I just downloaded it to inspect.)
> 
> My bookshelf is full of books describing IPv4.  Saying "IPv6 just works" 
> ignores the issues of configuring intelligent firewalls to block the 
> ne-er-do-wells using the new IP-level protocol.
> 
> In Robert L. Ziegler's book _Linux Firewalls_ Second Edition (2002, ISBN 
> 0-7357-1099-6), the *only* mention of IPv6 is in the discussion of NAT, and 
> that discussion is limited to "NAT is a stopgap until IPv6 achieves wide 
> implementation.  A preview of the Third Edition fails to mention ip6tables at 
> all, the same lack that the Second Edition has.
> 
> I use CentOS, the community version of Red Hat Enterprise.  I looked around 
> for useful books on building IPv6 firewalls with the same granularity as the 
> above-mentioned book for IPv4, and haven't found anything useful as yet.  In 
> particular, I'm looking for material that lays out how to build a 
> mostly-closed firewall and DMZ in IPv6.  The lack of IPv6 support goes 
> further:  I didn't find anything useful in Red Hat (CentOS) firewall tools 
> that provides IPv6 support...but that's probably because I don't know what 
> I'm looking for.  (Also, that GUI software is intended for use on individual 
> servers/computers, not in a edge-firewall with forwarding and DMZ 
> responsibilities.)
> 
> Building a secure firewall takes more than just knowing how to issue ip6table 
> commands; one also needs to know exactly what goes into those commands.  
> NANOG concentrates on network operators who need to provide a good Internet 
> experience to all their downstream customers, which is why I see the bias 
> toward openness...as it should be.  Those of us who run edge networks have 
> different problems to solve.
> 
> I'm not asking NANOG to go past its charter, but I am asking the IPv6 
> fanatics on this mailing list to recognize that, even though the net itself 
> may be running IPv6, the support and education infrastructure is still behind 
> the curve.  Reading RFCs is good, reading man pages is good, but there is no 
> guidance about how to implement end-network policies in the wild yet...at 
> least not that I've been able to find.
> 
> "ipv6.disable" will be changed to zero when I know how to set the firewall to 
> implement the policies I need to keep other edge networks from disrupting 
> mine.
> 

Re: /27 the new /24

[Randy Bush]

> Keep in mind that IPv6 has IPSec VPN built into the protocol.

yet another ipv6 fantasy.  it may be in the powerpoint but it is not in
the implementations.

Re: /27 the new /24

[sthaug]

> Keep in mind that IPv6 has IPSec VPN built into the protocol. It doesn't need 
> to be in the router. 
> 
> Unlike IPv4, where the IPSec VPN protocol is an add-on, optional service, 
> with IPv6 it's built into every device, because IPsec is a mandatory 
> component for IPv6, and therefore, the IPsec security model is required to be 
> supported for all IPv6 implementations. 

If you really believe all IPv6 devices support IPsec, I can only
conclude that your IPv6 experience is limited...

Steinar Haug, Nethelp consulting, sth...@nethelp.no

Re: /27 the new /24

[Stephen Satchell]

On 10/04/2015 06:40 AM, Matthias Leisi wrote:

Fully agree. But the current state of IPv6 outside "professional“
networks/devices is sincerely limited by a lot of poor CPE and
consumer device implementations.


I have to ask:  where is the book _IPv6 for Dummies_ or equivalent?

Specifically, is 
http://www.xnetworks.es/contents/Infoblox/IPv6forDummies.pdf any good? 
(I just downloaded it to inspect.)


My bookshelf is full of books describing IPv4.  Saying "IPv6 just works" 
ignores the issues of configuring intelligent firewalls to block the 
ne-er-do-wells using the new IP-level protocol.


In Robert L. Ziegler's book _Linux Firewalls_ Second Edition (2002, ISBN 
0-7357-1099-6), the *only* mention of IPv6 is in the discussion of NAT, 
and that discussion is limited to "NAT is a stopgap until IPv6 achieves 
wide implementation.  A preview of the Third Edition fails to mention 
ip6tables at all, the same lack that the Second Edition has.


I use CentOS, the community version of Red Hat Enterprise.  I looked 
around for useful books on building IPv6 firewalls with the same 
granularity as the above-mentioned book for IPv4, and haven't found 
anything useful as yet.  In particular, I'm looking for material that 
lays out how to build a mostly-closed firewall and DMZ in IPv6.  The 
lack of IPv6 support goes further:  I didn't find anything useful in Red 
Hat (CentOS) firewall tools that provides IPv6 support...but that's 
probably because I don't know what I'm looking for.  (Also, that GUI 
software is intended for use on individual servers/computers, not in a 
edge-firewall with forwarding and DMZ responsibilities.)


Building a secure firewall takes more than just knowing how to issue 
ip6table commands; one also needs to know exactly what goes into those 
commands.  NANOG concentrates on network operators who need to provide a 
good Internet experience to all their downstream customers, which is why 
I see the bias toward openness...as it should be.  Those of us who run 
edge networks have different problems to solve.


I'm not asking NANOG to go past its charter, but I am asking the IPv6 
fanatics on this mailing list to recognize that, even though the net 
itself may be running IPv6, the support and education infrastructure is 
still behind the curve.  Reading RFCs is good, reading man pages is 
good, but there is no guidance about how to implement end-network 
policies in the wild yet...at least not that I've been able to find.


"ipv6.disable" will be changed to zero when I know how to set the 
firewall to implement the policies I need to keep other edge networks 
from disrupting mine.

Re: /27 the new /24

[Randy Bush]

i give

< plonk >

Re: Agenda

[Betty Burke <be...@nanog.org>]

Thanks John for letting us know we will get fixed asap ... the time is
Sunday, October 4 Sponsored by: Resolve Systems  Time: 6:00pm - 8:00pm
Where:  Moxie's, 1207 Robert-Bourassa Boulevard, Montreal - See more at:
https://www.nanog.org/node/1624#sthash.YBeEXhC3.dpuf

Betty J. Burke
NANOG Executive Director
2864 Carpenter Rd., Ste 100
Ann Arbor, MI 48108
+1 866-902-1336


On Sun, Oct 4, 2015 at 12:41 PM, John Springer 
wrote:

> The times for tonight's event differ from the guidebook to the online
> version @ nanog
>
> nanog   6-8PM
> guidebook   7-11PM
>
> Which is correct?
>

Re: /27 the new /24

[Matthias Leisi]

> One or more of these things will be the death of IPv4:

IPv4 will not die, it will be superseded by something better :) 

What I have found to be the greatest obstacle to IPv6 adoption is the state of 
IPv6 support in various types of CPEs / network equipment. The support is 
mostly OK in higher-end gear. But have you checked the support in home- or 
small-office devices? 

In the handful of devices I recently had to deal with, IPv6 is always at best a 
„second class citizen“. First, there is some GUI for setup around IPv4. Then, 
if you are lucky, there are some poorly and inconsistently labelled  „Advanced“ 
settings that may or may not enable IPv6. Or may enable some semi-consistent 
state that has been in an obscure lab setup once upon a time. 

The built-in VPN which only supports IPv4 (that one specifically on an Asus 
router). A printer that behaves differently at different times under IPv4 than 
under IPv6. A NAS that works with IPv6 - *most* of the time. 

While I can personally work around most of these issues, it simply does not 
scale to even a small office environment with some semi-technical people. 
That’s basic stuff that just needs to work, regardless of whether it runs on 
IPv4 or IPv6. 

> Fortunately, in this case, we have a nice new body that we can transplant the 
> internet into that has many fruitful years ahead
> of it. So… Do whatever you have to to survive in the meantime, but focus on 
> getting your stuff onto the IPv6 internet so that
> we can all let IPv4 go gently into that good night and have it’s well 
> deserved final rest.

Fully agree. But the current state of IPv6 outside "professional“ 
networks/devices is sincerely limited by a lot of poor CPE and consumer device 
implementations. 

— Matthias



smime.p7s
Description: S/MIME cryptographic signature

Re: /27 the new /24

[Randy Bush]

> If it doesn't support IPSec, it's not really IPv6.

by that criterion, ipv6 deployment is effectively zero

Re: Inexpensive probes for automated bandwidth testing purposes

[Alex Brooks]

Hi,

On Sun, Oct 4, 2015 at 1:56 AM, John Levine  wrote:
> In article <37dba43e-ee76-4323-962c-30bb988d0...@hathcock.org> you write:
>>Greetings, NANOG.  Happy Saturday to all.
>>
>>I am running a DOCSIS network that has a noisy cable plant.  I want to be 
>>able to substantiate and quantify users' bandwidth issues.  I would
>>like a set of inexpensive probes that I could place at selected customer's 
>>homes/businesses that would on a scheduled basis perform bandwidth
>>tests.
>
> The RIPE Atlas project uses TP-Link TL-MR3020 minirouters reprogramed
> to be network probes collecting data not unlike what you're interested
> in.  They are $28 apiece at Amazon so I'd expect them to be under $20
> in any quantity.
>
> RIPE gives away the source code here:
>
> https://atlas.ripe.net/get-involved/source-code/

As well as the RIPE atlas (which is an excellent project), there is
also the SamKnows whitebox; the device used by the FCC (Measuring
Broadband America), CRTC, Ofcom and the EU Commission for their
consumer broadband monitoring projects.  They are also more than happy
to work directly with ISPs if you want to buy a few boxes off them,
and are currently working with some of the larger providers to embed
their monitoring technology within consumer CPEs.  Have a look at
https://www.samknows.com/infrastructure.

Alex

Re: /27 the new /24

[Jon Lewis]

On Sun, 4 Oct 2015, Mel Beckman wrote:

If it doesn't support IPSec, it's not really IPv6. Just as if it failed 
to support any other mandatory IPv6 specification, such as RA.


Go tell cisco that.  IIRC, the first network I dual-stacked, I was kind of 
surprised when I found I could not use authentication in OSPFv3, because 
OSPFv3 assumes IPv6 will supply the IPSec to do auth...but these routers 
didn't support IPSec.  They still managed to route IPv6 and support IPv6 
customers...so it really was IPv6...just not the full suite of everything 
you'd expect from IPv6.


Your observation simply means that users must be informed when buying 
IPv6 devices, just as they must with any product. You can buy either 
genuine IPv6 or half-baked IPv6 products. When I speak of IPv6, I speak 
only of the genuine article.


Does anyone buy "IPv6 devices"?

The biggest hurdle I've seen with IPv6 adoption (i.e. going dual-stack, 
with the idea that we'll gradually transition most things / most traffic 
from v4 to v6) is the number of end-user network providers that don't 
offer v6 at all.  My home cable internet provider still doesn't offer 
IPv6.  When I asked one of their support people about it recently, I was 
told not to worry, they have plenty of v4 addresses left, but it was 
implied that they do plan to start offering v6 sometime soon.  They should 
have started rolling out IPv6 to any customers that wanted it years ago, 
so that by today, it would be standard for all their installations to be 
dual-stack.  But here we are, nearly 2016, and they don't have a single 
IPv6 customer (AFAIK) yet.


--
 Jon Lewis, MCP :)   |  I route
 |  therefore you are
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: /27 the new /24

[Mel Beckman]

What Cisco routers, and what vintage IOS, are you finding have no IPSec 
support? I've not run into that problem. 

 -mel beckman

> On Oct 4, 2015, at 8:33 AM, Jon Lewis  wrote:
> 
>> On Sun, 4 Oct 2015, Mel Beckman wrote:
>> 
>> If it doesn't support IPSec, it's not really IPv6. Just as if it failed to 
>> support any other mandatory IPv6 specification, such as RA.
> 
> Go tell cisco that.  IIRC, the first network I dual-stacked, I was kind of 
> surprised when I found I could not use authentication in OSPFv3, because 
> OSPFv3 assumes IPv6 will supply the IPSec to do auth...but these routers 
> didn't support IPSec.  They still managed to route IPv6 and support IPv6 
> customers...so it really was IPv6...just not the full suite of everything 
> you'd expect from IPv6.
> 
>> Your observation simply means that users must be informed when buying IPv6 
>> devices, just as they must with any product. You can buy either genuine IPv6 
>> or half-baked IPv6 products. When I speak of IPv6, I speak only of the 
>> genuine article.
> 
> Does anyone buy "IPv6 devices"?
> 
> The biggest hurdle I've seen with IPv6 adoption (i.e. going dual-stack, with 
> the idea that we'll gradually transition most things / most traffic from v4 
> to v6) is the number of end-user network providers that don't offer v6 at 
> all.  My home cable internet provider still doesn't offer IPv6.  When I asked 
> one of their support people about it recently, I was told not to worry, they 
> have plenty of v4 addresses left, but it was implied that they do plan to 
> start offering v6 sometime soon.  They should have started rolling out IPv6 
> to any customers that wanted it years ago, so that by today, it would be 
> standard for all their installations to be dual-stack.  But here we are, 
> nearly 2016, and they don't have a single IPv6 customer (AFAIK) yet.
> 
> --
> Jon Lewis, MCP :)   |  I route
> |  therefore you are
> _ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: /27 the new /24

[Nick Hilliard]

On 04/10/2015 16:03, Randy Bush wrote:
> yet another ipv6 fantasy.  it may be in the powerpoint but it is not in
> the implementations.

the ipsec tickbox was removed from ipv6 in rfc6434 (2011).

Nick

Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

[Barry Shein]

>From the time we began to take the idea of an address runout seriously
in the early 90s to the actual address runout which would be just
about now new priorities arose such as spam which I'll say really got
going in the late 90s.

There were others such as the potential routing table explosion which
no doubt got passing notice from the start but I think it's safe to
say has been looming more and more as a potential big problem in
recent years.

And security & privacy which perhaps something like an IPv6 couldn't
much solve, most of that is higher in the stack, but then again maybe
not. Didn't OSI have some sort of L2 credentials passing?

That's all difficult to debate if for no other reason than one says
"security" and several different definitions and priorities pop into
people's heads ranging from low-level issues such as ddos and spoofing
and simple sniff and MITM avoidance to what it might mean to a bank
security officer or credit card undewriter or an individual at
risk. And spam and phishing and all that. Oh and toss intellectual
property rights management on the fire because it casts such a lovely
glow.

This has been a moving target and a canvas on which to paint each now
and evolving challenge of a technology which has grown into ubiquity.

Around 1992 when IPv6 was just picking up steam the net engineering
community was pretty happy if an email got delivered in well under a
minute and an FTP went smoothly. Words like congestion and route
flapping could take up entire career paths.

I think we need to stop replaying history like what if there weren't a
Russian winter and just press forward.

-- 
-Barry Shein

The World  | b...@theworld.com   | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR, Canada
Software Tool & Die| Public Access Internet | SINCE 1989 *oo*

Re: [outages] Akamai Cert Issues today

[coolhandluke]

On 2015-10-04 14:42, Jay Ashworth wrote:

as to why your users just started it, nfi. my best guess is that they
weren't using https previously.


Well, "more people may be using HTTPS-Anywhere" may have something to
do with it.


fwiw, https-anywhere doesn't just try to connect via https to every site 
you visit. there are rules that control where it will use https over 
plain http.


irs.gov and www.irs.gov are explicitly disabled, however, so it's not 
this.


cf. https://goo.gl/zTlzAu, lines 135-136.

Or, it might be that some new browser release just enabled HTTP/2.0, 
which
in many implementations *requires* SSL and might also trip this, as 
noted
in a posting on the topic which I just inadvertantly posted to this 
same

mailing list 5 minutes ago.  :-)


that's possible, i don't know enough about http/2.0 to comment.

--
coolhandluke

HTTP/2.0 to ship in weeks

[Jay Ashworth]

We all knew about this, right?

http://arstechnica.com/information-technology/2015/02/http2-finished-coming-to-browsers-within-weeks/

One - few - many - all?  What's that?

Cheers,
-- jra

-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Disregard: HTTP/2.0 to ship in weeks

[Jay Ashworth]

Damnit.  

Apologies everyone; no clue why Ars was pushing that *now*, 6 months after
its dateline.

- Original Message -
> From: "Jay Ashworth" 
> To: "NANOG" 
> Sent: Sunday, October 4, 2015 2:30:00 PM
> Subject: HTTP/2.0 to ship in weeks
> We all knew about this, right?
> 
> http://arstechnica.com/information-technology/2015/02/http2-finished-coming-to-browsers-within-weeks/
> 
> One - few - many - all? What's that?
> 
> Cheers,
> -- jra
> 
> --
> Jay R. Ashworth Baylink j...@baylink.com
> Designer The Things I Think RFC 2100
> Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII
> St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274

-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Re: Inexpensive probes for automated bandwidth testing purposes

[Brandon Ross]

On Sat, 3 Oct 2015, Lorell Hathcock wrote:

I am running a DOCSIS network that has a noisy cable plant.  I want to 
be able to substantiate and quantify users' bandwidth issues.  I would 
like a set of inexpensive probes that I could place at selected 
customer's homes/businesses that would on a scheduled basis perform 
bandwidth tests.


Check out Netbeez:

https://netbeez.net/

Let me know if you'd like an introduction to them.

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

Re: /27 the new /24

[Mel Beckman]

Stefann,

You're right. I remember hearing rumblings of vendors requesting this change, 
mostly because embedded processors of the time had difficulty performing well 
with IPv6. I see that in 2011 rfc6434 lowered IPSec from "must" to "should". 
Nevertheless, plenty of products produced before 2011 included IPSec and the 
vast majority of IPv6-capable nodes on the Internet have it today. Performance 
is no longer an issue. 

 -mel beckman

> On Oct 4, 2015, at 8:58 AM, Sander Steffann  wrote:
> 
> Hi,
> 
>> Op 4 okt. 2015, om 16:52 heeft Mel Beckman  het volgende 
>> geschreven:
>> 
>> If it doesn't support IPSec, it's not really IPv6. Just as if it failed to 
>> support any other mandatory IPv6 specification, such as RA.
> 
> I think you're still looking at an old version of the IPv6 Node Requirements. 
> Check https://tools.ietf.org/html/rfc6434#section-11, specifically this bit:
> 
> """
> Previously, IPv6 mandated implementation of IPsec and recommended the key 
> management approach of IKE.  This document updates that recommendation by 
> making support of the IPsec Architecture a SHOULD for all IPv6 nodes.
> """
> 
> This was published in December 2011.
> 
> Cheers,
> Sander
> 

Re: [outages] Akamai Cert Issues today

[Jay Ashworth]

- Original Message -
> From: "coolhandluke via Outages" 

> > -We're wondering what happened yesterday to break all these
> > disparate
> > websites

> note that this is *by design*, as sean pointed out.
> 
> the "fix" is simple: don't use https on www.irs.gov. any ssl pages
> served by the irs as served on different hostnames.
> 
> as to why your users just started it, nfi. my best guess is that they
> weren't using https previously.

Well, "more people may be using HTTPS-Anywhere" may have something to 
do with it.

Or, it might be that some new browser release just enabled HTTP/2.0, which
in many implementations *requires* SSL and might also trip this, as noted
in a posting on the topic which I just inadvertantly posted to this same
mailing list 5 minutes ago.  :-)

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Re: /27 the new /24

[Jon Lewis]

sup720-3bxl, but this was a number of years ago.  I don't recall the 
exact version.  It was probably 12.2SXI-something.


On Sun, 4 Oct 2015, Mel Beckman wrote:


What Cisco routers, and what vintage IOS, are you finding have no IPSec 
support? I've not run into that problem.

-mel beckman



--
 Jon Lewis, MCP :)   |  I route
 |  therefore you are
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: /27 the new /24

[Mel Beckman]

 A lot has changed since 12.2 :)

I believe all shipping gear supports IPSec in IPv6. 

 -mel beckman

> On Oct 4, 2015, at 11:48 AM, Jon Lewis  wrote:
> 
> sup720-3bxl, but this was a number of years ago.  I don't recall the exact 
> version.  It was probably 12.2SXI-something.
> 
>> On Sun, 4 Oct 2015, Mel Beckman wrote:
>> 
>> What Cisco routers, and what vintage IOS, are you finding have no IPSec 
>> support? I've not run into that problem.
>> 
>> -mel beckman
>> 
> 
> --
> Jon Lewis, MCP :)   |  I route
> |  therefore you are
> _ http://www.lewis.org/~jlewis/pgp for PGP public key_

Looking for upstream provider with BGP Flow Spec support / RFC 5575

[Pavel Odintsov]

Hello, dear Nanog Community!

I'm looking for upstreams with BGP Flow Spec / RFC 5575 support in US
(West and East coast are welcome).

We have implemented support for BGP Flow Spec traffic filtering in our
own open source DDoS detection toolkit and using it on our own MX
routers. Works really well.

But we are experiencing so much attacks on channel overflow and want
to lock part of traffic on upstream's side.

Thanks!

-- 
Sincerely yours, Pavel Odintsov