Re: Unimus Network Automation https://unimus.net/

All > > > > Anyone using Unimus for Network Automation ? https://unimus.net/ > > > > i.e. mass configuration / push / pull configurations looking for something > more powerful than rconfig for a Cisco Nexus and Juniper environment. > > > > And or happy with any

Re: Unimus Network Automation https://unimus.net/

ason Kuehl" Cc: "Mike Hammett" , "NANOG" Sent: Wednesday, January 13, 2021 8:46:35 AM Subject: Re: Unimus Network Automation https://unimus.net/ I've been using Unimus for almost as long as Mike. Met Tomas at a show in Vegas, very smart guy. I use it exclusiv

Re: Unimus Network Automation https://unimus.net/

http://www.midwest-ix.com From: "Josh Luthman" To: "Jason Kuehl" Cc: "Mike Hammett" , "NANOG" Sent: Wednesday, January 13, 2021 8:46:35 AM Subject: Re: Unimus Network Automation https://unimus.net/ I've been using Unimu

Re: Unimus Network Automation https://unimus.net/

-ix.com - Original Message - From: "Josh Luthman" To: "Jason Kuehl" Cc: "Mike Hammett" , "NANOG" Sent: Wednesday, January 13, 2021 8:46:35 AM Subject: Re: Unimus Network Automation https://unimus.net/ I've been using Unimus for almost as lon

Re: Unimus Network Automation https://unimus.net/

>>> >>> Very easy to install and update. >>> >>> >>> >>> - >>> Mike Hammett >>> Intelligent Computing Solutions >>> http://www.ics-il.com >>> >>> Midwest-IX >>> http://www.midwest-ix.com >

Re: Unimus Network Automation https://unimus.net/

> Midwest-IX >> http://www.midwest-ix.com >> >> ------ >> *From: *"James Braunegg" >> *To: *nanog@nanog.org >> *Sent: *Wednesday, January 13, 2021 12:38:53 AM >> *Subject: *Unimus Network Automation https://unimus.net/ >

Re: Unimus Network Automation https://unimus.net/

> Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > -- > *From: *"James Braunegg" > *To: *nanog@nanog.org > *Sent: *Wednesday, January 13, 2021 12:38:53 AM > *Su

Re: Unimus Network Automation https://unimus.net/

to install and update. - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com - Original Message - From: "James Braunegg" To: nanog@nanog.org Sent: Wednesday, January 13, 2021 12:38:53 AM Subject: Unimus Network Automa

Unimus Network Automation https://unimus.net/

Dear All Anyone using Unimus for Network Automation ? https://unimus.net/ i.e. mass configuration / push / pull configurations looking for something more powerful than rconfig for a Cisco Nexus and Juniper environment. And or happy with any other suggestions Kindest Regards James Braunegg

Major issues with Cloudflare DNS (specifically DNS-over-HTTPS)

). The issues appears to be centered around Firefox users who have DNS-over-HTTPS enabled, with Cloudflare as the provider. Thanks John

Re: Apple http/https

; > It's something you enable on a mac (we use a mac mini) which then get > discovered on your local network via a DNS TXT record or bonjour. > > https://support.apple.com/en-au/guide/mac-help/mchl3b6c3720/mac > > Hope this helps. > > MIKE G > > > On Thu, 14 No

Re: Apple http/https

Hi Ahmed, We have been using the Apple specific content caching feature for a while now. It's something you enable on a mac (we use a mac mini) which then get discovered on your local network via a DNS TXT record or bonjour. https://support.apple.com/en-au/guide/mac-help/mchl3b6c3720/mac Hope

Re: Apple http/https

enforce that for other things too (like app store downloads). On 11/13/2019 12:21 PM, ahmed.dala...@hrins.net wrote: Does anyone know if there is an apple cache? Today we noticed that apple store applications and updates are not caching anymore by HTTPs cache servers, and when we checked through DPI

Apple http/https

Does anyone know if there is an apple cache? Today we noticed that apple store applications and updates are not caching anymore by HTTPs cache servers, and when we checked through DPI, we found that it's been changed into HTTPS! Does anyone know what is going on? Ahmed

Re: Merit radb https interface, TLS1.0 only?

Hello - Indeed, the http(s)://www.radb.net load balancer was previously configured to support TLS 1.0. This morning the load balancer was re-configured to support TLS 1.2, modern key exchanges, and contemporary ciphers. We are now prioritizing https-everywhere for www.radb.net. Please reach out

Re: Merit radb https interface, TLS1.0 only?

It's not just you: https://www.ssllabs.com/ssltest/analyze.html?d=radb.net=207.75.117.71 On 02/02/2018 08:15 PM, Eric Kuhnke wrote: Is the radb login page supposed to be TLS1.0 only? This is with the latest version of Firefox. Screenshot: https://imgur.com/nnlFmLZ I also noticed

RE: Merit radb https interface, TLS1.0 only?

@nanog.org list <nanog@nanog.org> Subject: Merit radb https interface, TLS1.0 only? >Is the radb login page supposed to be TLS1.0 only?

Merit radb https interface, TLS1.0 only?

Is the radb login page supposed to be TLS1.0 only? This is with the latest version of Firefox. Screenshot: https://imgur.com/nnlFmLZ I also noticed that the registration page is plain http/non TLS. for reference: https://www.google.com/search?client=ubuntu=fs=tls+1.0+deprecated=utf-8=utf-8

Re: mailops https breakage

In article you write: >> Fun fact about letsencrypt certs, they expire after a month or so. > >90 days Well, yes. That's why highly skilled and experienced administrators such as yourself set up the automatic renewal scripts at the same time they install the initial

Re: mailops https breakage

Both. Either. Take your pick Ed Pers From: Seth Mattinen Sent: Tuesday, June 20, 8:06 PM Subject: Re: mailops https breakage To: nanog@nanog.org On 6/20/17 16:57, Keith Medcalf wrote: > How else would one maintain government control over free encryption certificates? So Let's Encrypt is

Re: mailops https breakage

On 6/20/17 16:57, Keith Medcalf wrote: How else would one maintain government control over free encryption certificates? So Let's Encrypt is run by the Illuminati now? Or is it Freemasons? It's hard to keep track.

Re: mailops https breakage

> How else would one maintain government control over free encryption > certificates? black helicopters

RE: mailops https breakage

in Pers > Cc: NANOG list > Subject: Re: mailops https breakage > > > Fun fact about letsencrypt certs, they expire after a month or so. > > 90 days

Re: mailops https breakage

> Fun fact about letsencrypt certs, they expire after a month or so. 90 days

RE: mailops https breakage

about Ed Pers -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Lyndon Nerenberg Sent: Sunday, June 11, 2017 6:27 PM To: NANOG list <nanog@nanog.org> Subject: mailops https breakage > On Aug 27, 2016, at 6:46 PM, Matt Palmer <mpal...@hezmat

mailops https breakage

t; I was working within the limits of what I had available. >> >> Here's the subscription page for mailop. It's got about as odd >> a mix of people as nanog, ranging from people with single user linux >> machines to people who run some of the largest mail systems in >>

Re: "Access Denied" when hitting https://www.apple.com issue over IPv4 and 6

ted. > > HTTP request sent, awaiting response... 403 Forbidden > > 2015-09-12 00:17:55 ERROR 403: Forbidden. > > > > root@nagios:/tmp# wget -6 https://www.apple.com > > --2015-09-12 00:17:59-- https://www.apple.com/ > > Resolving www.apple.com... 2001:590

RE: "Access Denied" when hitting https://www.apple.com issue over IPv4 and 6

Restored at 1:05 am U.S. Central. Frank -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Frank Bulk Sent: Saturday, September 12, 2015 12:19 AM To: nanog@nanog.org Subject: "Access Denied" when hitting https://www.apple.com issue over IPv4 and 6

Re: "Access Denied" when hitting https://www.apple.com issue over IPv4 and 6

On 9/11/2015 10:19 PM, Frank Bulk wrote: Monitoring system reporting this since 11:11 pm U.S. Central [snippy] Resolving www.apple.com... 2001:590:1807:187::c77, 2001:590:1807:186::c77 Connecting to www.apple.com|2001:590:1807:187::c77|:80... connected. HTTP request sent, awaiting

"Access Denied" when hitting https://www.apple.com issue over IPv4 and 6

... connected. HTTP request sent, awaiting response... 403 Forbidden 2015-09-12 00:17:55 ERROR 403: Forbidden. root@nagios:/tmp# wget -6 https://www.apple.com --2015-09-12 00:17:59-- https://www.apple.com/ Resolving www.apple.com... 2001:590:1807:186::c77, 2001:590:1807:187::c77 Connecting

Re: HTTPS redirects to HTTP for monitoring

By the way, I hope that all of the people who have been ranting about this have read this note. The only way this filtering works is if the client computers have a special CA cert installed into their browsers. That means it's a private organizational network that manages all its client

Re: HTTPS redirects to HTTP for monitoring

On Tue, Jan 20, 2015 at 5:23 AM, Tim Franklin t...@pelican.org wrote: I'd still very much *want* the organization to tell the users that the internal IT people are breaking their SSL, so please not to have any expectation that security is doing what you think it is. Blame it on the browser

Re: HTTPS redirects to HTTP for monitoring

On Sun, Jan 18, 2015 at 4:29 AM, Grant Ridder shortdudey...@gmail.com wrote: It looks like Websense might do decryption ( http://community.websense.com/forums/t/3146.aspx) while Covenant Eyes does some sort of session hijack to redirect to non-ssl (atleast for Google) (https://twitter.com

Re: HTTPS redirects to HTTP for monitoring

will be effective. If someone is really interested, there are clever ways to bypass it, more clever than your options to filter it. Forcing http fallback for https communication is not only wrong, it's a general regression regarding security policy and best practices. You are risking privacy, or confidentiality

Re: HTTPS redirects to HTTP for monitoring

In article 54bcc924.1000...@cox.net you write: On 1/18/2015 12:55, John R. Levine wrote: There are also ISPs that provide intrusive filtering as a feature. I wouldn't use one, but I know people who do, typically members of conservative religious groups. Can you provide credible evidence to

Re: HTTPS redirects to HTTP for monitoring

We use Fortinet firewalls and SSL (HTTPS, FTPS, IMAPS, POP3S, SMTPS, SSH) inspection is a standard feature. It works by rolling out a custom CA certificate from the device to all of the desktops and whenever you hit a SSL site, a cert signed with the CA is generated and presented to the user

Re: HTTPS redirects to HTTP for monitoring

On 1/18/2015 12:55, John R. Levine wrote: There are also ISPs that provide intrusive filtering as a feature. I wouldn't use one, but I know people who do, typically members of conservative religious groups. Can you provide credible evidence to support typically members of conservative

Re: HTTPS redirects to HTTP for monitoring

use? enterprise enterprise? It looks like Websense might do decryption ( http://community.websense.com/forums/t/3146.aspx) while Covenant Eyes does some sort of session hijack to redirect to non-ssl (atleast for Google) ( https://twitter.com/CovenantEyes/status/451382865914105856). Thoughts

Re: HTTPS redirects to HTTP for monitoring

From my point of view, it is better than violate user privacy safety. Sneaky is evil. On 18/01/2015 15:53, Ammar Zuberi wrote: So your idea is to block every HTTPS website? On 18 Jan 2015, at 6:48 pm, Ca By cb.li...@gmail.com wrote: On Sunday, January 18, 2015, Grant Ridder shortdudey

Re: HTTPS redirects to HTTP for monitoring

We use Fortinet firewalls and SSL (HTTPS, FTPS, IMAPS, POP3S, SMTPS, SSH) inspection is a standard feature. It works by rolling out a custom CA certificate from the device to all of the desktops and whenever you hit a SSL site, a cert signed with the CA is generated and presented to the user

Re: HTTPS redirects to HTTP for monitoring

So your idea is to block every HTTPS website? On 18 Jan 2015, at 6:48 pm, Ca By cb.li...@gmail.com wrote: On Sunday, January 18, 2015, Grant Ridder shortdudey...@gmail.com wrote: Hi Everyone, I wanted to see what opinions and thoughts were out there. What software, appliances

Re: HTTPS redirects to HTTP for monitoring

/3146.aspx) while Covenant Eyes does some sort of session hijack to redirect to non-ssl (atleast for Google) ( https://twitter.com/CovenantEyes/status/451382865914105856). Thoughts on having a product that decrypts SSL traffic internally vs one that doesn't allow SSL to start with? -Grant

Re: HTTPS redirects to HTTP for monitoring

? enterprise enterprise? It looks like Websense might do decryption ( http://community.websense.com/forums/t/3146.aspx) while Covenant Eyes does some sort of session hijack to redirect to non-ssl (atleast for Google) ( https://twitter.com/CovenantEyes/status/451382865914105856). Thoughts

HTTPS redirects to HTTP for monitoring

://community.websense.com/forums/t/3146.aspx) while Covenant Eyes does some sort of session hijack to redirect to non-ssl (atleast for Google) ( https://twitter.com/CovenantEyes/status/451382865914105856). Thoughts on having a product that decrypts SSL traffic internally vs one that doesn't allow SSL

Re: HTTPS redirects to HTTP for monitoring

On 18 Jan 2015 18:15:09 -, John Levine jo...@iecc.com said: I expect your users would fire you when they found you'd blocked access to Google. Doesn't goog do certificate pinning anyways, at least in their web browser? pgphGF6ZqCQVo.pgp Description: PGP signature

RE: HTTPS redirects to HTTP for monitoring

interested, there are clever ways to bypass it, more clever than your options to filter it. Forcing http fallback for https communication is not only wrong, it's a general regression regarding security policy and best practices. You are risking privacy, or confidentiality and integrity if you prefer

Re: HTTPS redirects to HTTP for monitoring

I expect your users would fire you when they found you'd blocked access to Google. And they would sue you for gross negligence for decrypting their ssn when access company payroll and cpni data May I suggest that playing Junior Lawyer on nanog rarely turns out well. These filter boxes are

Re: HTTPS redirects to HTTP for monitoring

On Sunday, January 18, 2015, John Levine jo...@iecc.com wrote: So your idea is to block every HTTPS website? From my point of view, it is better than violate user privacy safety. Sneaky is evil. I expect your users would fire you when they found you'd blocked access to Google

Re: HTTPS redirects to HTTP for monitoring

enterprise? Hi Grant, Fidelis Security (part of GD) does this for USG customers. Good guys with a strong, scalable product. http://www.fidelissecurity.com/ Basically, all internal web browsers get a custom CA which authenticates a re-signing cert. HTTPS traffic is decrypted by an IDS agent

Re: HTTPS redirects to HTTP for monitoring

On Sunday, January 18, 2015, Ammar Zuberi am...@fastreturn.net wrote: So your idea is to block every HTTPS website? My idea is to provide secure internet and tell the truth about it. Proxying And mitm SSL/TLS is telling a lie to the end user and exposing them and the proxying organization

Re: HTTPS redirects to HTTP for monitoring

So your idea is to block every HTTPS website? From my point of view, it is better than violate user privacy safety. Sneaky is evil. I expect your users would fire you when they found you'd blocked access to Google. These boxes that violate end to end encryption are a great place

Re: HTTPS redirects to HTTP for monitoring

On Sun, Jan 18, 2015 at 08:05:18PM +, Kelly Setzer wrote: I don't know if you're referring to HSTS. No, HSTS is separate to certificate pinning. Certificate pinning would, in fact, cause Chrome to freak out in the presence of an HTTPS-intercepting proxy, but that's what it's supposed to do

Re: HTTPS redirects to HTTP for monitoring

chris tknch...@gmail.com writes: I have been going through something very interesting recently that relates to this. We have a customer who google is flagging for abusive search behavior. Because google now forces all search traffic to be SSL, it has made attempting to track down the supposed

Re: HTTPS redirects to HTTP for monitoring

I don't know if you're referring to HSTS. If not, it's worth noting in this thread. As I understand HSTS, session decryption is still possible on sites that send the 'Strict-Transport-Security' header. See: https://tools.ietf.org/html/rfc6797 I suspect it's only a matter of time before

Re: Verizon FIOS issues in the Washington DC issue with HTTPS traffic?

On Fri, Mar 14, 2014 at 4:28 PM, Ulf Zimmermann u...@alameda.net wrote: We have a number of customers in the DC area on Verizon Fios who can talk to us using http, but not https. Linkedin also tweeted there are issues via Verzion Fios. Verizon support so far denies everything. Anyone else

Verizon FIOS issues in the Washington DC issue with HTTPS traffic?

We have a number of customers in the DC area on Verizon Fios who can talk to us using http, but not https. Linkedin also tweeted there are issues via Verzion Fios. Verizon support so far denies everything. Anyone else seeing issues? -- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501

Re: HTTPS-everywhere vs. proxy caching

On Fri, May 3, 2013 at 12:06 PM, Jay Ashworth j...@baylink.com wrote: It occurs to me that I don't believe I've seen any discussion of the Unexpected Consequence of pervasive HTTPS replacing HTTP for unauthenticated sessions, like non-logged-in users browsing sites like Wikipedia

HTTPS-everywhere vs. proxy caching

It occurs to me that I don't believe I've seen any discussion of the Unexpected Consequence of pervasive HTTPS replacing HTTP for unauthenticated sessions, like non-logged-in users browsing sites like Wikipedia. That traffic's not cacheable, is it? Proxy caches on services like mobile 3/4G

Re: HTTPS-everywhere vs. proxy caching

On Fri, May 3, 2013 at 3:06 PM, Jay Ashworth j...@baylink.com wrote: It occurs to me that I don't believe I've seen any discussion of the Unexpected Consequence of pervasive HTTPS replacing HTTP for unauthenticated sessions, like non-logged-in users browsing sites like Wikipedia

Re: HTTPS-everywhere vs. proxy caching

On 5/3/13 2:06 PM, Jay Ashworth wrote: It occurs to me that I don't believe I've seen any discussion of the Unexpected Consequence of pervasive HTTPS replacing HTTP for unauthenticated sessions, like non-logged-in users browsing sites like Wikipedia. That traffic's not cacheable

Re: HTTPS-everywhere vs. proxy caching

On Fri, May 3, 2013 at 3:33 PM, Wes Felter w...@felter.org wrote: On 5/3/13 2:06 PM, Jay Ashworth wrote: It occurs to me that I don't believe I've seen any discussion of the Unexpected Consequence of pervasive HTTPS replacing HTTP for unauthenticated sessions, like non-logged-in users

Re: IPv6 and HTTPS

for the address). Then the tide might turn. Date: Sun, 28 Apr 2013 17:34:48 -0500 From: Jimmy Hess mysi...@gmail.com To: Randy Bush ra...@psg.com Cc: North American Network Operators Group nanog@nanog.org Subject: Re: IPv6 and HTTPS Message-ID: caaawwbwyrt4dbqoxwq-qkhgou15voenbtr8qbbklchx90t8

Re: IPv6 and HTTPS

On 4/28/13 3:46 PM, Randy Bush wrote: -- for example: large Cable providers getting together and agreeing to implement a 100ms RTT latency penalty for IPv4 we do not see intentionally damaging our customers as a big sales feature. but we think all our competitors should do so. This business

Re: IPv6 and HTTPS

On 4/29/13, Jakob Heitz jakob.he...@ericsson.com wrote: That's evil. Charge what it costs to provide each service. If and when it costs more to provide IPv4 service (and only then), then charge more for it. Which of the below do you suggest is evil? Offering an IPv6 only service and charging

Re: IPv6 and HTTPS

On Apr 28, 2013, at 6:37 PM, Jimmy Hess mysi...@gmail.com wrote: On 4/28/13, Owen DeLong o...@delong.com wrote: I don't see turning IPv4 off as a short-term goal for anyone. OTOH, I do see the cost of maintaining residential IPv4 service escalating over about the next 5-7 years. Yes...

Re: IPv6 and HTTPS

On 4/29/2013 3:19 AM, Owen DeLong wrote: Depends. Unless there is sufficient mass of residential subscribers willing to pay the premium for CGN (unlikely in my estimation), it'll make the most sense for residential providers to simply turn off IPv4 services and tell laggard web sites like

Re: IPv6 and HTTPS

On Apr 29, 2013, at 7:28 AM, Jack Bates jba...@brightok.net wrote: On 4/29/2013 3:19 AM, Owen DeLong wrote: Depends. Unless there is sufficient mass of residential subscribers willing to pay the premium for CGN (unlikely in my estimation), it'll make the most sense for residential

Re: IPv6 and HTTPS

On 4/29/2013 11:11 AM, Owen DeLong wrote: Best of luck with that strategy. I think this ignores the growing IPv4 demand that will be coming from your business customers and assumes that your residential customers are all that you have to stack onto these addresses. The residential currently

Re: IPv6 and HTTPS

On Apr 29, 2013, at 10:29 AM, Jack Bates jba...@brightok.net wrote: On 4/29/2013 11:11 AM, Owen DeLong wrote: Best of luck with that strategy. I think this ignores the growing IPv4 demand that will be coming from your business customers and assumes that your residential customers are all

Re: IPv6 and HTTPS

On 4/29/2013 12:40 PM, Owen DeLong wrote: What does the CGN cost you per subscriber (equipment, additional staff, etc.?) In my case, very little. Equipment was covered by bandwidth usage which mandated upgrading to higher end routers that support more than I need. It looks like my trios

Re: IPv6 and HTTPS

On 04/29/2013 11:00 AM, Jack Bates wrote: If the existing cards handle CGN without additional licensing, then the only real cost is personal, my sanity, and the company need/will not factor that in. One thing to consider is what the new support load will be from issues dealing with CGN

Re: IPv6 and HTTPS

In message 05cd8f9b-46dd-4069-9ebe-2c922...@delong.com, Owen DeLong writes: On Apr 26, 2013, at 9:55 PM, Jima na...@jima.us wrote: On 2013-04-26 01:29, Don Gould wrote: I agree with others that there is still way to much XP and other non supporting platforms and I suspect that by

Re: IPv6 and HTTPS

Doing away with IPv4 isn't a sane short-term goal for anyone who wants global internet connectivity/reachability, period. folk who advocate disconnecting from ipv4 should lead by example or stfu. either way, it would reduce the drivel level. randy

Re: IPv6 and HTTPS

On 4/28/13, Randy Bush ra...@psg.com wrote: Doing away with IPv4 isn't a sane short-term goal for anyone who wants global internet connectivity/reachability, period. Breaking global connectivity is bad. I don't see networks turning off ipv4. I would favor differentiation of network

Re: IPv6 and HTTPS

-- for example: large Cable providers getting together and agreeing to implement a 100ms RTT latency penalty for IPv4 we do not see intentionally damaging our customers as a big sales feature. but we think all our competitors should do so. randy

Re: IPv6 and HTTPS

On 4/28/13, Randy Bush ra...@psg.com wrote: -- for example: large Cable providers getting together and agreeing to implement a 100ms RTT latency penalty for IPv4 we do not see intentionally damaging our customers as a big sales feature. but we think all our competitors should do so. Yes, I

Re: IPv6 and HTTPS

I don't see turning IPv4 off as a short-term goal for anyone. OTOH, I do see the cost of maintaining residential IPv4 service escalating over about the next 5-7 years. Lee Howard sees roughly the same thing. (He has fancier math and better statistics than I used). Bottom line, it is unlikely

Re: IPv6 and HTTPS

On 4/28/13, Owen DeLong o...@delong.com wrote: I don't see turning IPv4 off as a short-term goal for anyone. OTOH, I do see the cost of maintaining residential IPv4 service escalating over about the next 5-7 years. Yes... Which I interpret to result in an outcome of less service, for more

Re: IPv6 and HTTPS

In message 517b608a.9060...@jima.us, Jima writes: On 2013-04-26 23:08, shawn wilson wrote: There's ways around it for most software but old jetdirect stuff, switches, routers, ip control systems. Things are going to be 6to4 for a while. In fact I won't be surprised to see little hardware

Re: IPv6 and HTTPS

On Apr 26, 2013, at 9:55 PM, Jima na...@jima.us wrote: On 2013-04-26 01:29, Don Gould wrote: I agree with others that there is still way to much XP and other non supporting platforms and I suspect that by the time we get those out of the system we'll be most of the way there for IPv6 access.

Re: IPv6 and HTTPS

On 4/27/13 1:22 , Jima wrote: On 2013-04-26 23:08, shawn wilson wrote: There's ways around it for most software but old jetdirect stuff, switches, routers, ip control systems. Things are going to be 6to4 for a while. In fact I won't be surprised to see little hardware boxes that do it for $30

Re: IPv6 and HTTPS

On 2013-04-27 11:01, Owen DeLong wrote: On Apr 26, 2013, at 9:55 PM, Jima wrote: On 2013-04-26 01:29, Don Gould wrote: I agree with others that there is still way to much XP and other non supporting platforms and I suspect that by the time we get those out of the system we'll be most of the

Re: IPv6 and HTTPS

how much IPv4 space is allocated *specifically* to cater to the fact that HTTPS requires a dedicated IP per DNS name? It doesn't, or doesn't if if your clients are not stuck in the past. TLS SNI has existed for a rather long time. Is that a statistically significant percentage of all the IPs

Re: IPv6 and HTTPS

Ashworth wrote: Ok, here's a stupid question[1], which I'd know the answer to if I ran bigger networks: Does anyone know how much IPv4 space is allocated *specifically* to cater to the fact that HTTPS requires a dedicated IP per DNS name? Is that a statistically significant percentage of all the IPs

Re: IPv6 and HTTPS

If the hosting provider can still charge for IPv4 addresses, why would they support SNI or IPv6 SSL ;) I have seen a CDN using certificates with tons of domain names in subject alternative name. Old Symbian phones don't support SAN.. On Thu, Apr 25, 2013 at 10:32 PM, Jay Ashworth

Re: IPv6 and HTTPS

On 2013-04-26 01:29, Don Gould wrote: I agree with others that there is still way to much XP and other non supporting platforms and I suspect that by the time we get those out of the system we'll be most of the way there for IPv6 access. And heck, you don't even need to get rid of XP for IPv6

Re: IPv6 and HTTPS

There's ways around it for most software but old jetdirect stuff, switches, routers, ip control systems. Things are going to be 6to4 for a while. In fact I won't be surprised to see little hardware boxes that do it for $30 or so (probably late with this idea but have no need to know). On Apr 27,

Re: IPv6 and HTTPS

On 2013-04-26 23:08, shawn wilson wrote: There's ways around it for most software but old jetdirect stuff, switches, routers, ip control systems. Things are going to be 6to4 for a while. In fact I won't be surprised to see little hardware boxes that do it for $30 or so (probably late with this

IPv6 and HTTPS

Ok, here's a stupid question[1], which I'd know the answer to if I ran bigger networks: Does anyone know how much IPv4 space is allocated *specifically* to cater to the fact that HTTPS requires a dedicated IP per DNS name? Is that a statistically significant percentage of all the IPs in use

Re: IPv6 and HTTPS

Once upon a time, Jay Ashworth j...@baylink.com said: Does anyone know how much IPv4 space is allocated *specifically* to cater to the fact that HTTPS requires a dedicated IP per DNS name? Is that a statistically significant percentage of all the IPs in use? I have no numbers, but my gut

RE: IPv6 and HTTPS

RE: IPv6 and HTTPS

...@baylink.com] Sent: Thursday, April 25, 2013 9:25 PM To: NANOG Subject: IPv6 and HTTPS Ok, here's a stupid question[1], which I'd know the answer to if I ran bigger networks: Does anyone know how much IPv4 space is allocated *specifically* to cater to the fact that HTTPS requires

Re: IPv6 and HTTPS

- Original Message - From: Chris Adams cmad...@hiwaay.net Once upon a time, Jay Ashworth j...@baylink.com said: Does anyone know how much IPv4 space is allocated *specifically* to cater to the fact that HTTPS requires a dedicated IP per DNS name? Is that a statistically

RE: IPv6 and HTTPS

From: Jay Ashworth [mailto:j...@baylink.com] Sent: Thursday, April 25, 2013 9:47 PM To: NANOG Subject: Re: IPv6 and HTTPS When you say it is mostly deployed, what exactly do you mean? Is it layer 7 or 4? Does it live in libraries that can be upgraded behind users' backs

Re: IPv6 and HTTPS

- Original Message - From: David Hubbard dhubb...@dino.hostasaurus.com The web server has to support it too, which means compiling apache with SNI support and there are of course plenty of hosts running old apache. Well, sure, but for the hoster, it's a direct benefit, not an

Re: IPv6 and HTTPS

On Apr 25, 2013, at 9:47 PM, Jay Ashworth j...@baylink.com wrote: - Original Message - From: Chris Adams cmad...@hiwaay.net Once upon a time, Jay Ashworth j...@baylink.com said: Does anyone know how much IPv4 space is allocated *specifically* to cater to the fact that HTTPS

Re: IPv6 and HTTPS

On 04/25/2013 09:32 PM, Jay Ashworth wrote: - Original Message - From: David Hubbarddhubb...@dino.hostasaurus.com The web server has to support it too, which means compiling apache with SNI support and there are of course plenty of hosts running old apache. Well, sure, but for the

Re: IPv6 and HTTPS

On 4/25/13 6:24 PM, Jay Ashworth wrote: Ok, here's a stupid question[1], which I'd know the answer to if I ran bigger networks: Does anyone know how much IPv4 space is allocated *specifically* to cater to the fact that HTTPS requires a dedicated IP per DNS name? It doesn't, or doesn't

Re: IPv6 and HTTPS

On Apr 26, 2013, at 00:19 , joel jaeggli joe...@bogus.com wrote: On 4/25/13 6:24 PM, Jay Ashworth wrote: Ok, here's a stupid question[1], which I'd know the answer to if I ran bigger networks: Does anyone know how much IPv4 space is allocated *specifically* to cater to the fact that HTTPS

Re: IPv6 and HTTPS

*specifically* to cater to the fact that HTTPS requires a dedicated IP per DNS name? It doesn't, or doesn't if if your clients are not stuck in the past. TLS SNI has existed for a rather long time. Is that a statistically significant percentage of all the IPs in use? Wasn't there something going

  1   2   >