Re: OT: VPS with Routed IP space
Partial thread jack How about VPS providers who will do BGP... Do they exist? /Partial thread jack On Tue, Feb 24, 2015 at 3:11 PM, Owen DeLong o...@delong.com wrote: Or NOT. That’s a horribly ugly thing to do in a situation where the desired behavior shouldn’t be that hard to achieve. Owen On Feb 24, 2015, at 11:07 , Baldur Norddahl baldur.nordd...@gmail.com wrote: You just need to enable proxy ARP on the box to simulate a routed subnet. Den 24/02/2015 19.25 skrev Alex Buie alex.b...@frozenfeline.net: Anybody know of or have recommendations for providers of small VPS-line boxen (or alternative solutions) to serve as GRE endpoints? (for a small amount of IP addresses, /29 or /28 at most) I am finding a lot of places that will give you extra IPs on the box itself (oftentimes out of the provider's own larger unsubnetted prefix) but I am looking more for a setup with a single IP on the box and a prefix routed to it. TIA for your insight. Alex (if you or your company can do this, direct solicitations are okay too. do keep in mind it's just a personal project and I do not have larger commercial volume at this time) -- Zach Giles zgi...@gmail.com
Re: OT: VPS with Routed IP space
deploy two utm's with bgp on the two internal and external interfaces col Sent from my iPhone On 24 Feb 2015, at 20:29, Zachary Giles zgi...@gmail.com wrote: Partial thread jack How about VPS providers who will do BGP... Do they exist? /Partial thread jack On Tue, Feb 24, 2015 at 3:11 PM, Owen DeLong o...@delong.com wrote: Or NOT. That’s a horribly ugly thing to do in a situation where the desired behavior shouldn’t be that hard to achieve. Owen On Feb 24, 2015, at 11:07 , Baldur Norddahl baldur.nordd...@gmail.com wrote: You just need to enable proxy ARP on the box to simulate a routed subnet. Den 24/02/2015 19.25 skrev Alex Buie alex.b...@frozenfeline.net: Anybody know of or have recommendations for providers of small VPS-line boxen (or alternative solutions) to serve as GRE endpoints? (for a small amount of IP addresses, /29 or /28 at most) I am finding a lot of places that will give you extra IPs on the box itself (oftentimes out of the provider's own larger unsubnetted prefix) but I am looking more for a setup with a single IP on the box and a prefix routed to it. TIA for your insight. Alex (if you or your company can do this, direct solicitations are okay too. do keep in mind it's just a personal project and I do not have larger commercial volume at this time) -- Zach Giles zgi...@gmail.com
Re: OT: VPS with Routed IP space
Or NOT. That’s a horribly ugly thing to do in a situation where the desired behavior shouldn’t be that hard to achieve. Owen On Feb 24, 2015, at 11:07 , Baldur Norddahl baldur.nordd...@gmail.com wrote: You just need to enable proxy ARP on the box to simulate a routed subnet. Den 24/02/2015 19.25 skrev Alex Buie alex.b...@frozenfeline.net: Anybody know of or have recommendations for providers of small VPS-line boxen (or alternative solutions) to serve as GRE endpoints? (for a small amount of IP addresses, /29 or /28 at most) I am finding a lot of places that will give you extra IPs on the box itself (oftentimes out of the provider's own larger unsubnetted prefix) but I am looking more for a setup with a single IP on the box and a prefix routed to it. TIA for your insight. Alex (if you or your company can do this, direct solicitations are okay too. do keep in mind it's just a personal project and I do not have larger commercial volume at this time)
Re: OT: VPS with Routed IP space
Same here, we do as well. But as per the OPs question: we will route additional space but you generally need a good reason for it. Regards, Tim Raphael On 25 Feb 2015, at 4:38 am, Jeff Fisher na...@techmonkeys.org wrote: On 02/24/2015 02:29 PM, Zachary Giles wrote: Partial thread jack How about VPS providers who will do BGP... Do they exist? /Partial thread jack Hit and miss I find. We do it for the odd client and haven't really had any issues.
Re: OT: VPS with Routed IP space
On 02/24/2015 02:29 PM, Zachary Giles wrote: Partial thread jack How about VPS providers who will do BGP... Do they exist? /Partial thread jack Hit and miss I find. We do it for the odd client and haven't really had any issues.
RE: AOL Postmaster
Same here. I want to solve things that they seem to have issues with. But when I ask what is wrong they either don't respond (in any meaningful manner) or say that they 'solved it', without me ever knowing what 'it' was. I prefer swimming in seaweed instead of contacting Yahoo (or MS for that matter). And the seaweed here is quite gross. David Hofstee Deliverability Management MailPlus B.V. Netherlands (ESP) -Oorspronkelijk bericht- Van: NANOG [mailto:nanog-boun...@nanog.org] Namens Fred Verzonden: Tuesday, February 24, 2015 3:19 AM Aan: nanog@nanog.org Onderwerp: Re: AOL Postmaster Having exactly the same issue. Also never received any response from AOL. Quite annoying. John Zettlemoyer: No, started using an IP address that hasn’t been used since we got the range from Arin, and got this - 554- (RTR:BL) Tried to contact AOL through normal channels, and no response in over a week. Feedback loop has been in place for years, and we check it every day (its clean). John Zettlemoyer From: Bill Patterson [mailto:billpatterso...@gmail.com] Sent: Monday, February 23, 2015 3:46 PM To: John Zettlemoyer Cc: nanog@nanog.org Subject: Re: AOL Postmaster Did you suddenly start getting AOL will not accept delivery of this message bounce backs? On Feb 23, 2015 3:30 PM, John Zettlemoyer j...@west-canaan.net wrote: Could someone from AOL who deals with the email systems please contact me off-list. Thank you. John Zettlemoyer WCiT LLC 856.310.1375 x221 j...@wcit.net
Re: AOL Postmaster
On Tue, Feb 24, 2015 at 03:19:06AM +0100, Fred wrote: Having exactly the same issue. Also never received any response from AOL. Quite annoying. I've been waiting since January 26th for a response from dmarc-h...@teamaol.com, which is their stipulated contact point for DMARC issues. Of course I wouldn't *need* a response about that if they hadn't implemented DMARC so foolishly. It seems that the days when Carl Hutzler ran the place -- and ran it well -- are now well behind them. I didn't always agree with their decisions, but it was obvious that they were working hard and trying to make AOL a good network neighbor, so even when I disagreed I could at least acknowledge their good intentions. It seems now that AOL is determined to permit unlimited abuse directed at the entire rest of the Internet while simultaneously making life as difficult as possible for everyone who *doesn't* abuse...and is counting on their size to make them immune from the consequences of that decision. ---rsk
Re: AOL Postmaster
block aol like china blocks with no engagement of comms as justification colin Sent from my iPhone On 24 Feb 2015, at 12:36, Rich Kulawiec r...@gsp.org wrote: On Tue, Feb 24, 2015 at 03:19:06AM +0100, Fred wrote: Having exactly the same issue. Also never received any response from AOL. Quite annoying. I've been waiting since January 26th for a response from dmarc-h...@teamaol.com, which is their stipulated contact point for DMARC issues. Of course I wouldn't *need* a response about that if they hadn't implemented DMARC so foolishly. It seems that the days when Carl Hutzler ran the place -- and ran it well -- are now well behind them. I didn't always agree with their decisions, but it was obvious that they were working hard and trying to make AOL a good network neighbor, so even when I disagreed I could at least acknowledge their good intentions. It seems now that AOL is determined to permit unlimited abuse directed at the entire rest of the Internet while simultaneously making life as difficult as possible for everyone who *doesn't* abuse...and is counting on their size to make them immune from the consequences of that decision. ---rsk
Re: AOL Postmaster
And how many users do you have, again? On Feb 24, 2015 6:29 PM, Colin Johnston col...@gt86car.org.uk wrote: block aol like china blocks with no engagement of comms as justification colin Sent from my iPhone On 24 Feb 2015, at 12:36, Rich Kulawiec r...@gsp.org wrote: On Tue, Feb 24, 2015 at 03:19:06AM +0100, Fred wrote: Having exactly the same issue. Also never received any response from AOL. Quite annoying. I've been waiting since January 26th for a response from dmarc-h...@teamaol.com, which is their stipulated contact point for DMARC issues. Of course I wouldn't *need* a response about that if they hadn't implemented DMARC so foolishly. It seems that the days when Carl Hutzler ran the place -- and ran it well -- are now well behind them. I didn't always agree with their decisions, but it was obvious that they were working hard and trying to make AOL a good network neighbor, so even when I disagreed I could at least acknowledge their good intentions. It seems now that AOL is determined to permit unlimited abuse directed at the entire rest of the Internet while simultaneously making life as difficult as possible for everyone who *doesn't* abuse...and is counting on their size to make them immune from the consequences of that decision. ---rsk
Re: AOL Postmaster
On Tue, Feb 24, 2015 at 06:33:08PM +0530, Suresh Ramasubramanian wrote: And how many users do you have, again? So professionalism, competence, diligence, etc. are reserved for only the operations considered large enough? Good to know. ---rsk
Re: AOL Postmaster
On Tue, 24 Feb 2015 08:45:15 -0500, Rich Kulawiec said: On Tue, Feb 24, 2015 at 06:33:08PM +0530, Suresh Ramasubramanian wrote: And how many users do you have, again? So professionalism, competence, diligence, etc. are reserved for only the operations considered large enough? Good to know. No, but being able to ignore 800 pound gorillas *is* reserved for only the operations considered small enough pgpQBI7FY5qdW.pgp Description: PGP signature
Re: Comcast Support (from NANOG Digest, Vol 84, Issue 23)
I thought you were just supposed to give your Geek License number. :-) #nothingScales - Original Message - From: Kevin McElearney kevin_mcelear...@cable.comcast.com To: Peter Loron pet...@standingwave.org, John Brzozowski john_brzozow...@cable.comcast.com Cc: nanog@nanog.org Sent: Monday, February 23, 2015 9:16:37 AM Subject: Re: Comcast Support (from NANOG Digest, Vol 84, Issue 23) You forgot to use the word “Shibboleet” when you called care. Contacted Peter off-list - Kevin On 2/23/15, 1:25 AM, Peter Loron pet...@standingwave.org wrote: Apologies for a bit off topic, but I’m trying to get an issue resolved and am having trouble reaching anybody who seems clue positive. From home via Comcast cable, I’m having trouble reaching some destinations. According to mtr, there is a particular node (be-11-pe02.11greatoaks.ca.ibone.comcast.net) which is suffering 30% loss. Contacting the Comcast consumer support folks is useless (what are the lights on your modem doing? Did you power cycle it?). When this is happening, I usually am told they need to send a tech to my house. insert facepalm. Is there a way to drop a note to the NOC or other folks who would understand the info and be able to act on it? Thanks! -Pete On Jan 23, 2015, at 09:14, Brzozowski, John john_brzozow...@cable.comcast.com wrote: Folks, The thread below was sent to me a few times, apologies for not catching it sooner. Janet, I sent you mail unicast with a request for some information. I am happy to help you out. For the larger NANOG audience, Comcast has recently launched IPv6 support for our BCI products, these are our DOCSIS based commercial offerings. This means that if you gateway device is in fact in RG mode you will be delegated a dynamic IPv6 prefix, by default customers are delegated a /56 prefix along with a single IPv6 address that is assigned to the WAN of the gateway device. IPv6 support applies to the following makes and models: SMC D3G CCR (http://mydeviceinfo.comcast.net/device.php?devid=216) Cisco BWG (http://mydeviceinfo.comcast.net/device.php?devid=347) Netgear CG3000D (http://mydeviceinfo.comcast.net/device.php?devid=347) For customers where you bring your own cable modem or have one of the above in bridge mode we have enabled IPv6 support for you as well. However, your router behind the modem must be running software and configured with IPv6 support. Specifically, your router needs to be support stateful DHCPv6 for IPv6 address and prefix acquisition. We have received a number of reports from customers that the Juniper SRX does not appear to properly support IPv6. We are working with Juniper and also recommend that you reach out to Juniper as well. Please keep checking http://www.comcast6.net for updates, we will post some additional information here in the next week or so. In the mean time if you have questions feel free to send me mail or post them here on the NANOG list. HTH, John = John Jason Brzozowski Comcast Cable p) 484-962-0060 w) www.comcast6.net e) john_brzozow...@cable.comcast.com = -Original Message- From: nanog-requ...@nanog.orgmailto:nanog-requ...@nanog.org nanog-requ...@nanog.orgmailto:nanog-requ...@nanog.org Reply-To: NANOG nanog@nanog.orgmailto:nanog@nanog.org Date: Friday, January 23, 2015 at 07:00 To: NANOG nanog@nanog.orgmailto:nanog@nanog.org Subject: NANOG Digest, Vol 84, Issue 23 Date: Thu, 22 Jan 2015 22:42:17 + From: Janet Sullivan jan...@nairial.netmailto:jan...@nairial.net To: 'nanog@nanog.orgmailto:'nanog@nanog.org' nanog@nanog.orgmailto:nanog@nanog.org Subject: Comcast Support Message-ID: cy1pr0701mb1164f3448b35404bbae671a8dc...@cy1pr0701mb1164.namprd07.prod.o utlook.commailto:CY1PR0701MB1164F3448B35404BBAE671A8DC490@CY1PR0701MB116 4.namprd07.prod.outlook.com Content-Type: text/plain; charset=us-ascii I hate to use NANOG for this, but support has now ended a chat with me twice without fixing anything, they just kicked me off. I'm not getting an IPv6 address on the Comcast provided cable modem/router. I'm not getting a PD. My machines thus have no IPv6. I've hard reset my router 4 times while working with Comcast, and I've been told to do things like switch to a static IPv4 address, which shows a level of clue that is scary. And before that they were convinced it was a wireless problem even though I have a wired connection, and told them that multiple times. I've wasted two hours with Comcast today, and even when I asked for escalation I got nothing. Just hung up on. It's honestly the worst customer support I've ever received. I don't think I ever got them to understand the difference between IPv4 and IPv6. -- Jay R. Ashworth Baylink j...@baylink.com
RE: Comcast Support (from NANOG Digest, Vol 84, Issue 23)
Ah, Comcast support. Those people who keep calling my Ford Motor Company phone, to threaten to shut off service to my home, which I don't have (I have uverse). They keep saying they will take my Ford number off the account (which of course, I don't know the account number because I don't have an account) and then they call again, with the same threat. Real winners. And yes, I've been saving the chats with support. -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Jay Ashworth Sent: Tuesday, February 24, 2015 11:23 AM To: NANOG Subject: Re: Comcast Support (from NANOG Digest, Vol 84, Issue 23) I thought you were just supposed to give your Geek License number. :-) #nothingScales - Original Message - From: Kevin McElearney kevin_mcelear...@cable.comcast.com To: Peter Loron pet...@standingwave.org, John Brzozowski john_brzozow...@cable.comcast.com Cc: nanog@nanog.org Sent: Monday, February 23, 2015 9:16:37 AM Subject: Re: Comcast Support (from NANOG Digest, Vol 84, Issue 23) You forgot to use the word “Shibboleet” when you called care. Contacted Peter off-list - Kevin On 2/23/15, 1:25 AM, Peter Loron pet...@standingwave.org wrote: Apologies for a bit off topic, but I’m trying to get an issue resolved and am having trouble reaching anybody who seems clue positive. From home via Comcast cable, I’m having trouble reaching some destinations. According to mtr, there is a particular node (be-11-pe02.11greatoaks.ca.ibone.comcast.net) which is suffering 30% loss. Contacting the Comcast consumer support folks is useless (what are the lights on your modem doing? Did you power cycle it?). When this is happening, I usually am told they need to send a tech to my house. insert facepalm. Is there a way to drop a note to the NOC or other folks who would understand the info and be able to act on it? Thanks! -Pete On Jan 23, 2015, at 09:14, Brzozowski, John john_brzozow...@cable.comcast.com wrote: Folks, The thread below was sent to me a few times, apologies for not catching it sooner. Janet, I sent you mail unicast with a request for some information. I am happy to help you out. For the larger NANOG audience, Comcast has recently launched IPv6 support for our BCI products, these are our DOCSIS based commercial offerings. This means that if you gateway device is in fact in RG mode you will be delegated a dynamic IPv6 prefix, by default customers are delegated a /56 prefix along with a single IPv6 address that is assigned to the WAN of the gateway device. IPv6 support applies to the following makes and models: SMC D3G CCR (http://mydeviceinfo.comcast.net/device.php?devid=216) Cisco BWG (http://mydeviceinfo.comcast.net/device.php?devid=347) Netgear CG3000D (http://mydeviceinfo.comcast.net/device.php?devid=347) For customers where you bring your own cable modem or have one of the above in bridge mode we have enabled IPv6 support for you as well. However, your router behind the modem must be running software and configured with IPv6 support. Specifically, your router needs to be support stateful DHCPv6 for IPv6 address and prefix acquisition. We have received a number of reports from customers that the Juniper SRX does not appear to properly support IPv6. We are working with Juniper and also recommend that you reach out to Juniper as well. Please keep checking http://www.comcast6.net for updates, we will post some additional information here in the next week or so. In the mean time if you have questions feel free to send me mail or post them here on the NANOG list. HTH, John = John Jason Brzozowski Comcast Cable p) 484-962-0060 w) www.comcast6.net e) john_brzozow...@cable.comcast.com = -Original Message- From: nanog-requ...@nanog.orgmailto:nanog-requ...@nanog.org nanog-requ...@nanog.orgmailto:nanog-requ...@nanog.org Reply-To: NANOG nanog@nanog.orgmailto:nanog@nanog.org Date: Friday, January 23, 2015 at 07:00 To: NANOG nanog@nanog.orgmailto:nanog@nanog.org Subject: NANOG Digest, Vol 84, Issue 23 Date: Thu, 22 Jan 2015 22:42:17 + From: Janet Sullivan jan...@nairial.netmailto:jan...@nairial.net To: 'nanog@nanog.orgmailto:'nanog@nanog.org' nanog@nanog.orgmailto:nanog@nanog.org Subject: Comcast Support Message-ID: cy1pr0701mb1164f3448b35404bbae671a8dc...@cy1pr0701mb1164.namprd07.prod.o utlook.commailto:CY1PR0701MB1164F3448B35404BBAE671A8DC490@CY1PR0701MB116 4.namprd07.prod.outlook.com Content-Type: text/plain; charset=us-ascii I hate to use NANOG for this, but support has now ended a chat with me twice without fixing anything, they just kicked me off. I'm not getting an IPv6 address on the Comcast provided cable modem/router. I'm not getting a PD. My machines thus have no IPv6. I've hard reset
Re: Comcast Support (from NANOG Digest, Vol 84, Issue 23)
On Tue, Feb 24, 2015 at 10:27 AM, Kain, Rebecca (.) bka...@ford.com wrote: Ah, Comcast support. Those people who keep calling my Ford Motor Company phone, to threaten to shut off service to my home, which I don't have (I have uverse). They keep saying they will take my Ford number off the account (which of course, I don't know the account number because I don't have an account) and then they call again, with the same threat. Real winners. And yes, I've been saving the chats with support. -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Jay Ashworth Sent: Tuesday, February 24, 2015 11:23 AM To: NANOG Subject: Re: Comcast Support (from NANOG Digest, Vol 84, Issue 23) I thought you were just supposed to give your Geek License number. :-) #nothingScales - Original Message - From: Kevin McElearney kevin_mcelear...@cable.comcast.com To: Peter Loron pet...@standingwave.org, John Brzozowski john_brzozow...@cable.comcast.com Cc: nanog@nanog.org Sent: Monday, February 23, 2015 9:16:37 AM Subject: Re: Comcast Support (from NANOG Digest, Vol 84, Issue 23) You forgot to use the word “Shibboleet” when you called care. Contacted Peter off-list - Kevin On 2/23/15, 1:25 AM, Peter Loron pet...@standingwave.org wrote: Apologies for a bit off topic, but I’m trying to get an issue resolved and am having trouble reaching anybody who seems clue positive. From home via Comcast cable, I’m having trouble reaching some destinations. According to mtr, there is a particular node (be-11-pe02.11greatoaks.ca.ibone.comcast.net) which is suffering 30% loss. Contacting the Comcast consumer support folks is useless (what are the lights on your modem doing? Did you power cycle it?). When this is happening, I usually am told they need to send a tech to my house. insert facepalm. Is there a way to drop a note to the NOC or other folks who would understand the info and be able to act on it? Thanks! -Pete On Jan 23, 2015, at 09:14, Brzozowski, John john_brzozow...@cable.comcast.com wrote: Folks, The thread below was sent to me a few times, apologies for not catching it sooner. Janet, I sent you mail unicast with a request for some information. I am happy to help you out. For the larger NANOG audience, Comcast has recently launched IPv6 support for our BCI products, these are our DOCSIS based commercial offerings. This means that if you gateway device is in fact in RG mode you will be delegated a dynamic IPv6 prefix, by default customers are delegated a /56 prefix along with a single IPv6 address that is assigned to the WAN of the gateway device. IPv6 support applies to the following makes and models: SMC D3G CCR (http://mydeviceinfo.comcast.net/device.php?devid=216) Cisco BWG (http://mydeviceinfo.comcast.net/device.php?devid=347) Netgear CG3000D (http://mydeviceinfo.comcast.net/device.php?devid=347) For customers where you bring your own cable modem or have one of the above in bridge mode we have enabled IPv6 support for you as well. However, your router behind the modem must be running software and configured with IPv6 support. Specifically, your router needs to be support stateful DHCPv6 for IPv6 address and prefix acquisition. We have received a number of reports from customers that the Juniper SRX does not appear to properly support IPv6. We are working with Juniper and also recommend that you reach out to Juniper as well. Please keep checking http://www.comcast6.net for updates, we will post some additional information here in the next week or so. In the mean time if you have questions feel free to send me mail or post them here on the NANOG list. HTH, John = John Jason Brzozowski Comcast Cable p) 484-962-0060 w) www.comcast6.net e) john_brzozow...@cable.comcast.com = -Original Message- From: nanog-requ...@nanog.orgmailto:nanog-requ...@nanog.org nanog-requ...@nanog.orgmailto:nanog-requ...@nanog.org Reply-To: NANOG nanog@nanog.orgmailto:nanog@nanog.org Date: Friday, January 23, 2015 at 07:00 To: NANOG nanog@nanog.orgmailto:nanog@nanog.org Subject: NANOG Digest, Vol 84, Issue 23 Date: Thu, 22 Jan 2015 22:42:17 + From: Janet Sullivan jan...@nairial.netmailto:jan...@nairial.net To: 'nanog@nanog.orgmailto:'nanog@nanog.org' nanog@nanog.orgmailto:nanog@nanog.org Subject: Comcast Support Message-ID: cy1pr0701mb1164f3448b35404bbae671a8dc...@cy1pr0701mb1164.namprd07.prod.o utlook.commailto: CY1PR0701MB1164F3448B35404BBAE671A8DC490@CY1PR0701MB116 4.namprd07.prod.outlook.com Content-Type: text/plain; charset=us-ascii I hate to use NANOG for this, but support has now ended a chat with me
Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment
That's sort of what I meant to say. I did not articulate it well. The problem *with* AWS is that in VPC (or different regions), the internal network space is unique to each region. So, in theory, I could get 10.1.2.3 in two regions on two instances. In VPC, you can also designate your own subnets, which makes things a little more tough a la interconnecting the disparate regions. But, as you say, IPv6 would be an elegant solution to that problem...and that's what I meant to articulate. IPv6 as a region unification tool as well as an Internet-facing protocol. On Tue, Feb 24, 2015 at 12:27 PM, Luan Nguyen lngu...@opsource.net wrote: Shouldn't it be the other way around? Ipv6 as the unique universal external network and you can define your own IPv4 within your cloud context separate from the cloud provider network and from other customers. So if you have contexts in different region - you can interconnect using layer 3 or layer 2 - through the cloud provider network...bring your own IPv4. If you need internet access, you'll get NATted. If you need connections to your branches/HQs...etc, build your own tunnel or use the cloud provider - which by the way gives you your own vrf so no need to worry about overlapping anything. Noone heard of Dimension Data Cloud? :) On Tue, Feb 24, 2015 at 1:10 PM, Blair Trosper blair.tros...@gmail.com wrote: ADDENDUM: They're taking into consideration my suggestion of using IPv6 as a universal internal network so that the different regions could be interconnected without having to give up the region-independent use of 10.0.0.0/8, which I think would be an elegant solution. On Tue, Feb 24, 2015 at 12:08 PM, Blair Trosper blair.tros...@gmail.com wrote: I have an unimpeachable source at AWS that assures me they're working hard to deploy IPv6. As it was explained to me, since AWS was sort of first to the table -- well before IPv6 popped, they had designed everything on the v4 only. Granted, you can get an IPv6 ELB, but only in EC2 classic, which they're phasing out. But I'm assured they're rushing IPv6 deployment of CloudFront and other services as fast as they can. I'm assured of this. But you also have to appreciate the hassle of retrofitting a cloud platform of that scale, so I do not envy the task that AWS is undertaking. On Tue, Feb 24, 2015 at 11:35 AM, Owen DeLong o...@delong.com wrote: Amazon is not the only public cloud. There are several public clouds that can support IPv6 directly. I have done some work for and believe these guys do a good job: Host Virtual (vr.org http://vr.org/) In no particular order and I have no relationship with or loyalty or benefit associated with any of them. I neither endorse, nor decry any of the following: Linode SoftLayer RackSpace There are others that I am not recalling off the top of my head. Owen On Feb 23, 2015, at 07:52 , Ca By cb.li...@gmail.com wrote: On Mon, Feb 23, 2015 at 7:02 AM, Eric Germann ekgerm...@cctec.com wrote: Currently engaged on a project where they’re building out a VPC infrastructure for hosted applications. Users access apps in the VPC, not the other direction. The issue I'm trying to get around is the customers who need to connect have multiple overlapping RFC1918 space (including overlapping what was proposed for the VPC networks). Finding a hole that is big enough and not in use by someone else is nearly impossible AND the customers could go through mergers which make them renumber even more in to overlapping 1918 space. Initially, I was looking at doing something like (example IP’s): Customer A (172.28.0.0/24) — NAT to 100.127.0.0/28 —— VPN to DC —— NAT from 100.64.0.0/18 —— VPC Space (was 172.28.0.0/24) Classic overlapping subnets on both ends with allocations out of 100.64.0.0/10 to NAT in both directions. Each sees the other end in 100.64 space, but the mappings can get tricky and hard to keep track of (especially if you’re not a network engineer). In spitballing, the boat hasn’t sailed too far to say “Why not use 100.64/10 in the VPC?” Then, the customer would be allocated a /28 or larger (depending on needs) to NAT on their side and NAT it once. After that, no more NAT for the VPC and it boils down to firewall rules. Their device needs to NAT outbound before it fires it down the tunnel which pfSense and ASA’s appear to be able to do. I prototyped this up over the weekend with multiple VPC’s in multiple regions and it “appears” to work fine. From the operator community, what are the downsides? Customers are businesses on dedicated business services vs. consumer cable modems (although there are a few on business class cable). Others are on MPLS and I’m hashing that out. The only one I can see is if the customer has a service
Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment
Amazon is not the only public cloud. There are several public clouds that can support IPv6 directly. I have done some work for and believe these guys do a good job: Host Virtual (vr.org http://vr.org/) In no particular order and I have no relationship with or loyalty or benefit associated with any of them. I neither endorse, nor decry any of the following: Linode SoftLayer RackSpace There are others that I am not recalling off the top of my head. Owen On Feb 23, 2015, at 07:52 , Ca By cb.li...@gmail.com wrote: On Mon, Feb 23, 2015 at 7:02 AM, Eric Germann ekgerm...@cctec.com wrote: Currently engaged on a project where they’re building out a VPC infrastructure for hosted applications. Users access apps in the VPC, not the other direction. The issue I'm trying to get around is the customers who need to connect have multiple overlapping RFC1918 space (including overlapping what was proposed for the VPC networks). Finding a hole that is big enough and not in use by someone else is nearly impossible AND the customers could go through mergers which make them renumber even more in to overlapping 1918 space. Initially, I was looking at doing something like (example IP’s): Customer A (172.28.0.0/24) — NAT to 100.127.0.0/28 —— VPN to DC —— NAT from 100.64.0.0/18 —— VPC Space (was 172.28.0.0/24) Classic overlapping subnets on both ends with allocations out of 100.64.0.0/10 to NAT in both directions. Each sees the other end in 100.64 space, but the mappings can get tricky and hard to keep track of (especially if you’re not a network engineer). In spitballing, the boat hasn’t sailed too far to say “Why not use 100.64/10 in the VPC?” Then, the customer would be allocated a /28 or larger (depending on needs) to NAT on their side and NAT it once. After that, no more NAT for the VPC and it boils down to firewall rules. Their device needs to NAT outbound before it fires it down the tunnel which pfSense and ASA’s appear to be able to do. I prototyped this up over the weekend with multiple VPC’s in multiple regions and it “appears” to work fine. From the operator community, what are the downsides? Customers are businesses on dedicated business services vs. consumer cable modems (although there are a few on business class cable). Others are on MPLS and I’m hashing that out. The only one I can see is if the customer has a service provider with their external interface in 100.64 space. However, this approach would have a more specific in that space so it should fire it down the tunnel for their allocated customer block (/28) vs. their external side. Thoughts and thanks in advance. Eric Wouldn't it be nice if Amazon supported IPv6 in VPC? I have disqualified several projects from using the public cloud and put them in the on-premise private cloud because Amazon is missing this key scaling feature -- ipv6. It is odd that Amazon, a company with scale deeply in its DNA, fails so hard on IPv6. I guess they have a lot of brittle technical debt they can't upgrade. I suggest you go with private cloud if possible. Or, you can double NAT non-unique IPv4 space. Regarding 100.64.0.0/10, despite what the RFCs may say, this space is just an augment of RFC1918 and i have already deployed it as such. CB
Re: v6 deagg
On Feb 19, 2015, at 21:25 , Christopher Morrow morrowc.li...@gmail.com wrote: On Thu, Feb 19, 2015 at 10:16 PM, manning bill bmann...@isi.edu wrote: and then there are the loons who will locally push /64 or longer, some of which may leak. 2001:2b8:46:::/64 ... a fairly extensive list actually show route table inet6.0 | grep ^2 | except /4[876543210] | except /3 | except /2 | count Count: 297 lines Some are likely my local network's interfaces (so skip ~50 or so? to be generous) and some might be my provider's customers? (but they shouldn't send me shorter than a /48, right?) -chris (note on another observation point I don't see this sort of thing so perhaps it's just one upstream in a collection... I'll ask them seperately) Your regular expression will not only count /49 and longer, it will also count /19 and shorter. In my routing table, there are at least some examples of such routes. Owen
ControlNow / MailEssentials Admin Requested
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Could a clueful ControlNow smtp admin contact me off-ist. RE: na0102.smtpout.com - -- Jason Hellenthal JJH48-ARIN -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJU7LauAAoJEDLu+wRc4KcIMecIAI35ZHbTDyLWcSLtYkuM8oxP zvsDZhHtD5r3j0iUkhD0jDpEWS2F1wTkQwZ6fZDWfaLcrqM90y2F5jQMYkmQ1FZa IlyAOlOqqOGvzLAuhNlXEac92MoIGMK6bcgxl1LBunO2k7CyGa1j0kFn7e0df5jp vSD3J5Rt97AvnqWUjLxJ37wy2tDlVTZbYASvaW+bDRen2oeU0rZu8blHoWbMTILo V/9JOblSgMpp3NvyjfeZI7G5u/qswescr6zikErHfIMx0t3sO0NYnsmmgV9yXuJw +uswFRclM3MGs6ExKDkg3Vsu8rMv/6S/0BjF1v4hmIDOo6T/d2W0IybpTjnOtlo= =ikhw -END PGP SIGNATURE-
Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment
As one of the authors involved in what eventually became RFC6598, this isn’t entirely accurate. 100.64/10 is intended as space to be used by service providers for dealing with situations where additional shared private address space is required, but it must be distinct from the private address space in use by their customers. Stacked NAT in a CGN scenario is only the most common example of such a situation. The application described is another example, though if the application provider’s customers are with ISPs that start doing CGN and using RFC6598 for that process, some difficulties could arise which the application provider would have to be prepared to cope with. Owen On Feb 23, 2015, at 10:52 , Benson Schliesser bens...@queuefull.net wrote: Hi, Eric - Bill already described the salient points. The transition space is meant to be used for cases where there are multiple stacked NATs, such as CGN with CPE-based NAT. In theory, if the NAT implementations support it, one could use it repeatedly by stacking NAT on top of NAT ad nauseum, but the wisdom of doing so is questionable. If one uses it like additional RFC1918 space then routing could become more difficult, specifically in the case where hosts (e.g. VPC servers) are numbered with it. This is true because, in theory, you don't need the transition space to be routed on the internal network which avoids having NAT devices hold conflicting routes etc. Even if the edge NAT devices don't currently see conflicting routes to 100.64/10, if that changes in the future then client hosts may find themselves unable to reach the VPC hosts at that time. That being said, if you understand the risks that I described above, then it may work well for a community of interest type of inter-network that hosts non-global resources. From your description it sounds like that might be the situation you find yourself in. To be clear, it's not unwise to do so, but it does carry risk that needs to be evaluated (and documented). Cheers, -Benson William Herrin mailto:b...@herrin.us February 23, 2015 at 12:58 PM Hi Eric, The main risk is more or less as you summarized it. Customer has no firewall or originates the VPN directly from their firewall. Customer buys a non-hosting commodity Internet product that uses carrier NAT to conserve IP addresses. The customer's assigned address AND NETMASK combined overlap some of the hosts you're trying to publish to them. Mitigations for that risk: Can you insist that the customer originate connections from inside their firewall (on RFC1918 space)? Most service providers using 100.64/10 either permit customers to opt out (getting dynamic globally routable addresses) or offer customers the opportunity to purchase static global addresses for a nominal fee. Are you comfortable telling impacted customers that they have to do so? A secondary risk comes in to play where a customer may wish to interact with another service provider doing the same thing as you. That essentially lands you back in the same problem you're having now with RFC1918. One more question you should consider: what is the nature of your customer's networks? Big corps that tend to stretch through 10/8 won't let their users originate VPN connections in the first place. They also don't touch 100.64/10 except where someone is publishing a service like yours. Meanwhile, home and SOHO users who are at liberty to originate VPNs might currently hold a 100.64/10 address. But they just about never use the off-bit /16s in 10/8. By off-bit I mean the ones with 4 or 5 random 1-bits in the second octet. My opinion: The likelihood of collisions in 100.64/10 increases significantly if you use them on servers. I would confine my use to client machines and try to put servers providing service to multiple organizations on globally unique IPs. Confining 100.64/10 to client machines, you're unlikely to encounter a problem you can't readily solve. Regards, Bill Herrin Eric Germann mailto:ekgerm...@cctec.com February 23, 2015 at 10:02 AM Currently engaged on a project where they’re building out a VPC infrastructure for hosted applications. Users access apps in the VPC, not the other direction. The issue I'm trying to get around is the customers who need to connect have multiple overlapping RFC1918 space (including overlapping what was proposed for the VPC networks). Finding a hole that is big enough and not in use by someone else is nearly impossible AND the customers could go through mergers which make them renumber even more in to overlapping 1918 space. Initially, I was looking at doing something like (example IP’s): Customer A (172.28.0.0/24) — NAT to 100.127.0.0/28 —— VPN to DC —— NAT from 100.64.0.0/18 —— VPC Space (was 172.28.0.0/24) Classic overlapping subnets on both ends with allocations out of 100.64.0.0/10 to NAT in both
routing issue? could someone from verizon FiOS please take a look?
Verizon Fios cannot connect me to lavra.spb.ru This is the Russian site of the second most important monastery in Russia. It is reachable from Boston avra.spb.ru (91.218.229.131), 64 hops max, 52 byte packets 1 192.168.100.1 (192.168.100.1) 2.293 ms 0.815 ms 0.764 ms 2 100.64.0.129 (100.64.0.129) 1.108 ms 3.013 ms 1.068 ms 3 10.16.28.1 (10.16.28.1) 1.411 ms 1.277 ms 1.068 ms 4 10.16.13.1 (10.16.13.1) 4.796 ms 2.301 ms 5.207 ms 5 69.46.226.129.lightower.net (69.46.226.129) 4.380 ms 3.138 ms 4.630 ms 6 ae2.bstpmallj42.lightower.net (64.72.64.113) 3.768 ms 6.008 ms 3.888 ms 7 xe-4-0-2.bar2.boston1.level3.net (4.53.56.153) 6.030 ms 4.890 ms 7.058 ms 8 ae-231-3607.edge4.london1.level3.net (4.69.166.25) 91.525 ms 81.571 ms ae-232-3608.edge4.london1.level3.net (4.69.166.29) 81.327 ms 9 ae-231-3607.edge4.london1.level3.net (4.69.166.25) 78.121 ms ae-232-3608.edge4.london1.level3.net (4.69.166.29) 79.734 ms 78.890 ms 10 195.50.122.186 (195.50.122.186) 173.491 ms 133.054 ms 198.495 ms 11 * * * 12 oversun-gw.transtelecom.net (217.150.54.25) 210.399 ms 138.519 ms 139.291 ms 13 mr-o-rtc1-rsw-2.oversun.ru (94.198.48.154) 131.070 ms 131.007 ms 129.553 ms 14 mr-o-rtc5-rsw-2.oversun.ru (94.198.48.110) 140.012 ms 208.023 ms 145.352 ms 15 vip-h5.ihc-ru.net (91.218.229.131) 131.485 ms 133.319 ms 129.822 ms and from comcast and other locations apparently it has v6 routing info as well ..someone much more knowledgable than i suggested that this can be a source of reachability problems but here is what happens on my machine ordons-mac-pro:~ gordoncook$ traceroute lavra.spb.ru traceroute to lavra.spb.ru (92.242.140.21), 64 hops max, 52 byte packets 1 wireless_broadband_router (192.168.1.1) 0.654 ms 0.351 ms 0.295 ms 2 l100.cmdnnj-vfttp-26.verizon-gni.net (98.110.50.1) 4.607 ms 4.326 ms 7.869 ms 3 g0-1-0-0.cmdnnj-lcr-22.verizon-gni.net (130.81.223.100) 12.172 ms 9.502 ms 7.242 ms 4 xe-9-1-6-0.ny5030-bb-rtr2.verizon-gni.net (130.81.199.226) 15.080 ms xe-9-1-2-0.ny5030-bb-rtr2.verizon-gni.net (130.81.209.144) 8.986 ms xe-4-1-8-0.ny5030-bb-rtr2.verizon-gni.net (130.81.209.84) 22.085 ms 5 * * * 6 0.ae1.br2.nyc4.alter.net (140.222.229.91) 79.467 ms 77.046 ms 74.729 ms 7 204.255.168.114 (204.255.168.114) 85.591 ms 86.899 ms 204.255.168.110 (204.255.168.110) 87.011 ms 8 be2061.ccr42.jfk02.atlas.cogentco.com (154.54.3.69) 96.323 ms be2060.ccr41.jfk02.atlas.cogentco.com (154.54.31.9) 84.779 ms be2061.ccr42.jfk02.atlas.cogentco.com (154.54.3.69) 85.063 ms 9 be2482.ccr21.cle04.atlas.cogentco.com (154.54.27.157) 31.562 ms 31.990 ms be2483.ccr22.cle04.atlas.cogentco.com (154.54.29.201) 27.548 ms 10 be2351.ccr41.ord01.atlas.cogentco.com (154.54.44.85) 37.087 ms be2185.ccr42.ord01.atlas.cogentco.com (154.54.43.177) 42.273 ms be2351.ccr41.ord01.atlas.cogentco.com (154.54.44.85) 39.590 ms 11 be2157.ccr22.mci01.atlas.cogentco.com (154.54.6.117) 49.793 ms be2156.ccr21.mci01.atlas.cogentco.com (154.54.6.85) 50.583 ms be2157.ccr22.mci01.atlas.cogentco.com (154.54.6.117) 49.492 ms 12 be2133.ccr22.sfo01.atlas.cogentco.com (154.54.30.65) 77.446 ms be2132.ccr21.sfo01.atlas.cogentco.com (154.54.30.53) 77.060 ms be2133.ccr22.sfo01.atlas.cogentco.com (154.54.30.65) 77.001 ms 13 be2164.ccr21.sjc01.atlas.cogentco.com (154.54.28.34) 74.999 ms 74.569 ms be2165.ccr22.sjc01.atlas.cogentco.com (154.54.28.66) 74.852 ms 14 be2063.rcr21.b001848-1.sjc01.atlas.cogentco.com (154.54.1.162) 74.377 ms be2095.rcr21.b001848-1.sjc01.atlas.cogentco.com (154.54.3.138) 77.126 ms 89.476 ms 15 c1.sj.mpt.fiberinternetcenter.net (66.201.58.2) 82.483 ms 86.964 ms 80.094 ms 16 sanjose2.barefruit.co.uk (66.201.32.134) 125.112 ms 106.932 ms 124.778 ms 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * 31 * * * 32 * * * 33 * * * 34 * * * 35 * * * 36 * * * 37 * * * 38 * * * 39 * * * 40 * unallocated.barefruit.co.uk (92.242.140.21) 111.898 ms * gordons-mac-pro:~ gordoncook$ PS: my FIOS contract is up in april. Any suggestion of how to avoid a $30 per month price increase would be greatly appreciated OFF list of course many thanks Gordon Cook COOK Report on Internet Protocol signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment
ADDENDUM: They're taking into consideration my suggestion of using IPv6 as a universal internal network so that the different regions could be interconnected without having to give up the region-independent use of 10.0.0.0/8, which I think would be an elegant solution. On Tue, Feb 24, 2015 at 12:08 PM, Blair Trosper blair.tros...@gmail.com wrote: I have an unimpeachable source at AWS that assures me they're working hard to deploy IPv6. As it was explained to me, since AWS was sort of first to the table -- well before IPv6 popped, they had designed everything on the v4 only. Granted, you can get an IPv6 ELB, but only in EC2 classic, which they're phasing out. But I'm assured they're rushing IPv6 deployment of CloudFront and other services as fast as they can. I'm assured of this. But you also have to appreciate the hassle of retrofitting a cloud platform of that scale, so I do not envy the task that AWS is undertaking. On Tue, Feb 24, 2015 at 11:35 AM, Owen DeLong o...@delong.com wrote: Amazon is not the only public cloud. There are several public clouds that can support IPv6 directly. I have done some work for and believe these guys do a good job: Host Virtual (vr.org http://vr.org/) In no particular order and I have no relationship with or loyalty or benefit associated with any of them. I neither endorse, nor decry any of the following: Linode SoftLayer RackSpace There are others that I am not recalling off the top of my head. Owen On Feb 23, 2015, at 07:52 , Ca By cb.li...@gmail.com wrote: On Mon, Feb 23, 2015 at 7:02 AM, Eric Germann ekgerm...@cctec.com wrote: Currently engaged on a project where they’re building out a VPC infrastructure for hosted applications. Users access apps in the VPC, not the other direction. The issue I'm trying to get around is the customers who need to connect have multiple overlapping RFC1918 space (including overlapping what was proposed for the VPC networks). Finding a hole that is big enough and not in use by someone else is nearly impossible AND the customers could go through mergers which make them renumber even more in to overlapping 1918 space. Initially, I was looking at doing something like (example IP’s): Customer A (172.28.0.0/24) — NAT to 100.127.0.0/28 —— VPN to DC —— NAT from 100.64.0.0/18 —— VPC Space (was 172.28.0.0/24) Classic overlapping subnets on both ends with allocations out of 100.64.0.0/10 to NAT in both directions. Each sees the other end in 100.64 space, but the mappings can get tricky and hard to keep track of (especially if you’re not a network engineer). In spitballing, the boat hasn’t sailed too far to say “Why not use 100.64/10 in the VPC?” Then, the customer would be allocated a /28 or larger (depending on needs) to NAT on their side and NAT it once. After that, no more NAT for the VPC and it boils down to firewall rules. Their device needs to NAT outbound before it fires it down the tunnel which pfSense and ASA’s appear to be able to do. I prototyped this up over the weekend with multiple VPC’s in multiple regions and it “appears” to work fine. From the operator community, what are the downsides? Customers are businesses on dedicated business services vs. consumer cable modems (although there are a few on business class cable). Others are on MPLS and I’m hashing that out. The only one I can see is if the customer has a service provider with their external interface in 100.64 space. However, this approach would have a more specific in that space so it should fire it down the tunnel for their allocated customer block (/28) vs. their external side. Thoughts and thanks in advance. Eric Wouldn't it be nice if Amazon supported IPv6 in VPC? I have disqualified several projects from using the public cloud and put them in the on-premise private cloud because Amazon is missing this key scaling feature -- ipv6. It is odd that Amazon, a company with scale deeply in its DNA, fails so hard on IPv6. I guess they have a lot of brittle technical debt they can't upgrade. I suggest you go with private cloud if possible. Or, you can double NAT non-unique IPv4 space. Regarding 100.64.0.0/10, despite what the RFCs may say, this space is just an augment of RFC1918 and i have already deployed it as such. CB
Re: routing issue? could someone from verizon FiOS please take a look?
Hi, I actually saw this issue a few weeks back but with a customer's website. It's actually not a routing issue, but a DNS issue. If you check the IPs that Verizon resolves for you, they'll be different from the IPs that other resolvers will resolve. It's weird, I know, but that's all the information I have for you. Hope I helped, Ammar. On 24 Feb 2015, at 9:53 pm, Gordon Cook c...@cookreport.com wrote: Verizon Fios cannot connect me to lavra.spb.ru This is the Russian site of the second most important monastery in Russia. It is reachable from Boston avra.spb.ru (91.218.229.131), 64 hops max, 52 byte packets 1 192.168.100.1 (192.168.100.1) 2.293 ms 0.815 ms 0.764 ms 2 100.64.0.129 (100.64.0.129) 1.108 ms 3.013 ms 1.068 ms 3 10.16.28.1 (10.16.28.1) 1.411 ms 1.277 ms 1.068 ms 4 10.16.13.1 (10.16.13.1) 4.796 ms 2.301 ms 5.207 ms 5 69.46.226.129.lightower.net (69.46.226.129) 4.380 ms 3.138 ms 4.630 ms 6 ae2.bstpmallj42.lightower.net (64.72.64.113) 3.768 ms 6.008 ms 3.888 ms 7 xe-4-0-2.bar2.boston1.level3.net (4.53.56.153) 6.030 ms 4.890 ms 7.058 ms 8 ae-231-3607.edge4.london1.level3.net (4.69.166.25) 91.525 ms 81.571 ms ae-232-3608.edge4.london1.level3.net (4.69.166.29) 81.327 ms 9 ae-231-3607.edge4.london1.level3.net (4.69.166.25) 78.121 ms ae-232-3608.edge4.london1.level3.net (4.69.166.29) 79.734 ms 78.890 ms 10 195.50.122.186 (195.50.122.186) 173.491 ms 133.054 ms 198.495 ms 11 * * * 12 oversun-gw.transtelecom.net (217.150.54.25) 210.399 ms 138.519 ms 139.291 ms 13 mr-o-rtc1-rsw-2.oversun.ru (94.198.48.154) 131.070 ms 131.007 ms 129.553 ms 14 mr-o-rtc5-rsw-2.oversun.ru (94.198.48.110) 140.012 ms 208.023 ms 145.352 ms 15 vip-h5.ihc-ru.net (91.218.229.131) 131.485 ms 133.319 ms 129.822 ms and from comcast and other locations apparently it has v6 routing info as well ..someone much more knowledgable than i suggested that this can be a source of reachability problems but here is what happens on my machine ordons-mac-pro:~ gordoncook$ traceroute lavra.spb.ru traceroute to lavra.spb.ru (92.242.140.21), 64 hops max, 52 byte packets 1 wireless_broadband_router (192.168.1.1) 0.654 ms 0.351 ms 0.295 ms 2 l100.cmdnnj-vfttp-26.verizon-gni.net (98.110.50.1) 4.607 ms 4.326 ms 7.869 ms 3 g0-1-0-0.cmdnnj-lcr-22.verizon-gni.net (130.81.223.100) 12.172 ms 9.502 ms 7.242 ms 4 xe-9-1-6-0.ny5030-bb-rtr2.verizon-gni.net (130.81.199.226) 15.080 ms xe-9-1-2-0.ny5030-bb-rtr2.verizon-gni.net (130.81.209.144) 8.986 ms xe-4-1-8-0.ny5030-bb-rtr2.verizon-gni.net (130.81.209.84) 22.085 ms 5 * * * 6 0.ae1.br2.nyc4.alter.net (140.222.229.91) 79.467 ms 77.046 ms 74.729 ms 7 204.255.168.114 (204.255.168.114) 85.591 ms 86.899 ms 204.255.168.110 (204.255.168.110) 87.011 ms 8 be2061.ccr42.jfk02.atlas.cogentco.com (154.54.3.69) 96.323 ms be2060.ccr41.jfk02.atlas.cogentco.com (154.54.31.9) 84.779 ms be2061.ccr42.jfk02.atlas.cogentco.com (154.54.3.69) 85.063 ms 9 be2482.ccr21.cle04.atlas.cogentco.com (154.54.27.157) 31.562 ms 31.990 ms be2483.ccr22.cle04.atlas.cogentco.com (154.54.29.201) 27.548 ms 10 be2351.ccr41.ord01.atlas.cogentco.com (154.54.44.85) 37.087 ms be2185.ccr42.ord01.atlas.cogentco.com (154.54.43.177) 42.273 ms be2351.ccr41.ord01.atlas.cogentco.com (154.54.44.85) 39.590 ms 11 be2157.ccr22.mci01.atlas.cogentco.com (154.54.6.117) 49.793 ms be2156.ccr21.mci01.atlas.cogentco.com (154.54.6.85) 50.583 ms be2157.ccr22.mci01.atlas.cogentco.com (154.54.6.117) 49.492 ms 12 be2133.ccr22.sfo01.atlas.cogentco.com (154.54.30.65) 77.446 ms be2132.ccr21.sfo01.atlas.cogentco.com (154.54.30.53) 77.060 ms be2133.ccr22.sfo01.atlas.cogentco.com (154.54.30.65) 77.001 ms 13 be2164.ccr21.sjc01.atlas.cogentco.com (154.54.28.34) 74.999 ms 74.569 ms be2165.ccr22.sjc01.atlas.cogentco.com (154.54.28.66) 74.852 ms 14 be2063.rcr21.b001848-1.sjc01.atlas.cogentco.com (154.54.1.162) 74.377 ms be2095.rcr21.b001848-1.sjc01.atlas.cogentco.com (154.54.3.138) 77.126 ms 89.476 ms 15 c1.sj.mpt.fiberinternetcenter.net (66.201.58.2) 82.483 ms 86.964 ms 80.094 ms 16 sanjose2.barefruit.co.uk (66.201.32.134) 125.112 ms 106.932 ms 124.778 ms 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * 31 * * * 32 * * * 33 * * * 34 * * * 35 * * * 36 * * * 37 * * * 38 * * * 39 * * * 40 * unallocated.barefruit.co.uk (92.242.140.21) 111.898 ms * gordons-mac-pro:~ gordoncook$ PS: my FIOS contract is up in april. Any suggestion of how to avoid a $30 per month price increase would be greatly appreciated OFF list of course many thanks Gordon Cook COOK Report on Internet Protocol
Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment
On Tue, Feb 24, 2015 at 10:08 AM, Blair Trosper blair.tros...@gmail.com wrote: I have an unimpeachable source at AWS that assures me they're working hard to deploy IPv6. As it was explained to me, since AWS was sort of first to the table -- well before IPv6 popped, they had designed everything on the v4 only. Granted, you can get an IPv6 ELB, but only in EC2 classic, which they're phasing out. But I'm assured they're rushing IPv6 deployment of CloudFront and other services as fast as they can. I'm assured of this. talk is cheap. I suggest people use Cloudflare or Akamai for proper IPv6 CDN reach to major IPv6 eyeball networks at ATT, Verizon, Comcast, and T-Mobile US -- all of which have major ipv6 deployments http://www.worldipv6launch.org/measurements/ But you also have to appreciate the hassle of retrofitting a cloud platform of that scale, so I do not envy the task that AWS is undertaking. work is hard On Tue, Feb 24, 2015 at 11:35 AM, Owen DeLong o...@delong.com wrote: Amazon is not the only public cloud. There are several public clouds that can support IPv6 directly. I have done some work for and believe these guys do a good job: Host Virtual (vr.org http://vr.org/) In no particular order and I have no relationship with or loyalty or benefit associated with any of them. I neither endorse, nor decry any of the following: Linode SoftLayer RackSpace There are others that I am not recalling off the top of my head. Owen On Feb 23, 2015, at 07:52 , Ca By cb.li...@gmail.com wrote: On Mon, Feb 23, 2015 at 7:02 AM, Eric Germann ekgerm...@cctec.com wrote: Currently engaged on a project where they’re building out a VPC infrastructure for hosted applications. Users access apps in the VPC, not the other direction. The issue I'm trying to get around is the customers who need to connect have multiple overlapping RFC1918 space (including overlapping what was proposed for the VPC networks). Finding a hole that is big enough and not in use by someone else is nearly impossible AND the customers could go through mergers which make them renumber even more in to overlapping 1918 space. Initially, I was looking at doing something like (example IP’s): Customer A (172.28.0.0/24) — NAT to 100.127.0.0/28 —— VPN to DC —— NAT from 100.64.0.0/18 —— VPC Space (was 172.28.0.0/24) Classic overlapping subnets on both ends with allocations out of 100.64.0.0/10 to NAT in both directions. Each sees the other end in 100.64 space, but the mappings can get tricky and hard to keep track of (especially if you’re not a network engineer). In spitballing, the boat hasn’t sailed too far to say “Why not use 100.64/10 in the VPC?” Then, the customer would be allocated a /28 or larger (depending on needs) to NAT on their side and NAT it once. After that, no more NAT for the VPC and it boils down to firewall rules. Their device needs to NAT outbound before it fires it down the tunnel which pfSense and ASA’s appear to be able to do. I prototyped this up over the weekend with multiple VPC’s in multiple regions and it “appears” to work fine. From the operator community, what are the downsides? Customers are businesses on dedicated business services vs. consumer cable modems (although there are a few on business class cable). Others are on MPLS and I’m hashing that out. The only one I can see is if the customer has a service provider with their external interface in 100.64 space. However, this approach would have a more specific in that space so it should fire it down the tunnel for their allocated customer block (/28) vs. their external side. Thoughts and thanks in advance. Eric Wouldn't it be nice if Amazon supported IPv6 in VPC? I have disqualified several projects from using the public cloud and put them in the on-premise private cloud because Amazon is missing this key scaling feature -- ipv6. It is odd that Amazon, a company with scale deeply in its DNA, fails so hard on IPv6. I guess they have a lot of brittle technical debt they can't upgrade. I suggest you go with private cloud if possible. Or, you can double NAT non-unique IPv4 space. Regarding 100.64.0.0/10, despite what the RFCs may say, this space is just an augment of RFC1918 and i have already deployed it as such. CB
Re: v6 deagg
Hi Bill, I don't fully understand the math yet but the algorithm doesn't smell right. As near as I can figure it may only be correct in a static system. If after convergence the disaggregate ceases to be reachable from the aggregate, there doesn't appear to be either enough information in the system or enough triggers traveling between routers for it to reconverge to a correct state. If a network announces an aggregate when they can't reach all more-specifics then things will already be broken. Don't announce address space that you can't handle traffic for... But true: without Dragon the more specific would still arrive via another path and it would still be reachable. Cheers, Sander
Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment
I personally find it amusing that companies try to have it both ways. We are huge, you should use us instead of $LITTLE_GUY because our resources scale make us better able to handle things. Oh, what, you want IPv6? We're too big to do that quickly But hey, I would try the same thing in their position. -- TTFN, patrick On Feb 24, 2015, at 13:15 , Ca By cb.li...@gmail.com wrote: On Tue, Feb 24, 2015 at 10:08 AM, Blair Trosper blair.tros...@gmail.com wrote: I have an unimpeachable source at AWS that assures me they're working hard to deploy IPv6. As it was explained to me, since AWS was sort of first to the table -- well before IPv6 popped, they had designed everything on the v4 only. Granted, you can get an IPv6 ELB, but only in EC2 classic, which they're phasing out. But I'm assured they're rushing IPv6 deployment of CloudFront and other services as fast as they can. I'm assured of this. talk is cheap. I suggest people use Cloudflare or Akamai for proper IPv6 CDN reach to major IPv6 eyeball networks at ATT, Verizon, Comcast, and T-Mobile US -- all of which have major ipv6 deployments http://www.worldipv6launch.org/measurements/ But you also have to appreciate the hassle of retrofitting a cloud platform of that scale, so I do not envy the task that AWS is undertaking. work is hard On Tue, Feb 24, 2015 at 11:35 AM, Owen DeLong o...@delong.com wrote: Amazon is not the only public cloud. There are several public clouds that can support IPv6 directly. I have done some work for and believe these guys do a good job: Host Virtual (vr.org http://vr.org/) In no particular order and I have no relationship with or loyalty or benefit associated with any of them. I neither endorse, nor decry any of the following: Linode SoftLayer RackSpace There are others that I am not recalling off the top of my head. Owen On Feb 23, 2015, at 07:52 , Ca By cb.li...@gmail.com wrote: On Mon, Feb 23, 2015 at 7:02 AM, Eric Germann ekgerm...@cctec.com wrote: Currently engaged on a project where they’re building out a VPC infrastructure for hosted applications. Users access apps in the VPC, not the other direction. The issue I'm trying to get around is the customers who need to connect have multiple overlapping RFC1918 space (including overlapping what was proposed for the VPC networks). Finding a hole that is big enough and not in use by someone else is nearly impossible AND the customers could go through mergers which make them renumber even more in to overlapping 1918 space. Initially, I was looking at doing something like (example IP’s): Customer A (172.28.0.0/24) — NAT to 100.127.0.0/28 —— VPN to DC —— NAT from 100.64.0.0/18 —— VPC Space (was 172.28.0.0/24) Classic overlapping subnets on both ends with allocations out of 100.64.0.0/10 to NAT in both directions. Each sees the other end in 100.64 space, but the mappings can get tricky and hard to keep track of (especially if you’re not a network engineer). In spitballing, the boat hasn’t sailed too far to say “Why not use 100.64/10 in the VPC?” Then, the customer would be allocated a /28 or larger (depending on needs) to NAT on their side and NAT it once. After that, no more NAT for the VPC and it boils down to firewall rules. Their device needs to NAT outbound before it fires it down the tunnel which pfSense and ASA’s appear to be able to do. I prototyped this up over the weekend with multiple VPC’s in multiple regions and it “appears” to work fine. From the operator community, what are the downsides? Customers are businesses on dedicated business services vs. consumer cable modems (although there are a few on business class cable). Others are on MPLS and I’m hashing that out. The only one I can see is if the customer has a service provider with their external interface in 100.64 space. However, this approach would have a more specific in that space so it should fire it down the tunnel for their allocated customer block (/28) vs. their external side. Thoughts and thanks in advance. Eric Wouldn't it be nice if Amazon supported IPv6 in VPC? I have disqualified several projects from using the public cloud and put them in the on-premise private cloud because Amazon is missing this key scaling feature -- ipv6. It is odd that Amazon, a company with scale deeply in its DNA, fails so hard on IPv6. I guess they have a lot of brittle technical debt they can't upgrade. I suggest you go with private cloud if possible. Or, you can double NAT non-unique IPv4 space. Regarding 100.64.0.0/10, despite what the RFCs may say, this space is just an augment of RFC1918 and i have already deployed it as such. CB
Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment
Shouldn't it be the other way around? Ipv6 as the unique universal external network and you can define your own IPv4 within your cloud context separate from the cloud provider network and from other customers. So if you have contexts in different region - you can interconnect using layer 3 or layer 2 - through the cloud provider network...bring your own IPv4. If you need internet access, you'll get NATted. If you need connections to your branches/HQs...etc, build your own tunnel or use the cloud provider - which by the way gives you your own vrf so no need to worry about overlapping anything. Noone heard of Dimension Data Cloud? :) On Tue, Feb 24, 2015 at 1:10 PM, Blair Trosper blair.tros...@gmail.com wrote: ADDENDUM: They're taking into consideration my suggestion of using IPv6 as a universal internal network so that the different regions could be interconnected without having to give up the region-independent use of 10.0.0.0/8, which I think would be an elegant solution. On Tue, Feb 24, 2015 at 12:08 PM, Blair Trosper blair.tros...@gmail.com wrote: I have an unimpeachable source at AWS that assures me they're working hard to deploy IPv6. As it was explained to me, since AWS was sort of first to the table -- well before IPv6 popped, they had designed everything on the v4 only. Granted, you can get an IPv6 ELB, but only in EC2 classic, which they're phasing out. But I'm assured they're rushing IPv6 deployment of CloudFront and other services as fast as they can. I'm assured of this. But you also have to appreciate the hassle of retrofitting a cloud platform of that scale, so I do not envy the task that AWS is undertaking. On Tue, Feb 24, 2015 at 11:35 AM, Owen DeLong o...@delong.com wrote: Amazon is not the only public cloud. There are several public clouds that can support IPv6 directly. I have done some work for and believe these guys do a good job: Host Virtual (vr.org http://vr.org/) In no particular order and I have no relationship with or loyalty or benefit associated with any of them. I neither endorse, nor decry any of the following: Linode SoftLayer RackSpace There are others that I am not recalling off the top of my head. Owen On Feb 23, 2015, at 07:52 , Ca By cb.li...@gmail.com wrote: On Mon, Feb 23, 2015 at 7:02 AM, Eric Germann ekgerm...@cctec.com wrote: Currently engaged on a project where they’re building out a VPC infrastructure for hosted applications. Users access apps in the VPC, not the other direction. The issue I'm trying to get around is the customers who need to connect have multiple overlapping RFC1918 space (including overlapping what was proposed for the VPC networks). Finding a hole that is big enough and not in use by someone else is nearly impossible AND the customers could go through mergers which make them renumber even more in to overlapping 1918 space. Initially, I was looking at doing something like (example IP’s): Customer A (172.28.0.0/24) — NAT to 100.127.0.0/28 —— VPN to DC —— NAT from 100.64.0.0/18 —— VPC Space (was 172.28.0.0/24) Classic overlapping subnets on both ends with allocations out of 100.64.0.0/10 to NAT in both directions. Each sees the other end in 100.64 space, but the mappings can get tricky and hard to keep track of (especially if you’re not a network engineer). In spitballing, the boat hasn’t sailed too far to say “Why not use 100.64/10 in the VPC?” Then, the customer would be allocated a /28 or larger (depending on needs) to NAT on their side and NAT it once. After that, no more NAT for the VPC and it boils down to firewall rules. Their device needs to NAT outbound before it fires it down the tunnel which pfSense and ASA’s appear to be able to do. I prototyped this up over the weekend with multiple VPC’s in multiple regions and it “appears” to work fine. From the operator community, what are the downsides? Customers are businesses on dedicated business services vs. consumer cable modems (although there are a few on business class cable). Others are on MPLS and I’m hashing that out. The only one I can see is if the customer has a service provider with their external interface in 100.64 space. However, this approach would have a more specific in that space so it should fire it down the tunnel for their allocated customer block (/28) vs. their external side. Thoughts and thanks in advance. Eric Wouldn't it be nice if Amazon supported IPv6 in VPC? I have disqualified several projects from using the public cloud and put them in the on-premise private cloud because Amazon is missing this key scaling feature -- ipv6. It is odd that Amazon, a company with scale deeply in its DNA, fails so hard on IPv6. I guess they have a lot of brittle
Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment
I have an unimpeachable source at AWS that assures me they're working hard to deploy IPv6. As it was explained to me, since AWS was sort of first to the table -- well before IPv6 popped, they had designed everything on the v4 only. Granted, you can get an IPv6 ELB, but only in EC2 classic, which they're phasing out. But I'm assured they're rushing IPv6 deployment of CloudFront and other services as fast as they can. I'm assured of this. But you also have to appreciate the hassle of retrofitting a cloud platform of that scale, so I do not envy the task that AWS is undertaking. On Tue, Feb 24, 2015 at 11:35 AM, Owen DeLong o...@delong.com wrote: Amazon is not the only public cloud. There are several public clouds that can support IPv6 directly. I have done some work for and believe these guys do a good job: Host Virtual (vr.org http://vr.org/) In no particular order and I have no relationship with or loyalty or benefit associated with any of them. I neither endorse, nor decry any of the following: Linode SoftLayer RackSpace There are others that I am not recalling off the top of my head. Owen On Feb 23, 2015, at 07:52 , Ca By cb.li...@gmail.com wrote: On Mon, Feb 23, 2015 at 7:02 AM, Eric Germann ekgerm...@cctec.com wrote: Currently engaged on a project where they’re building out a VPC infrastructure for hosted applications. Users access apps in the VPC, not the other direction. The issue I'm trying to get around is the customers who need to connect have multiple overlapping RFC1918 space (including overlapping what was proposed for the VPC networks). Finding a hole that is big enough and not in use by someone else is nearly impossible AND the customers could go through mergers which make them renumber even more in to overlapping 1918 space. Initially, I was looking at doing something like (example IP’s): Customer A (172.28.0.0/24) — NAT to 100.127.0.0/28 —— VPN to DC —— NAT from 100.64.0.0/18 —— VPC Space (was 172.28.0.0/24) Classic overlapping subnets on both ends with allocations out of 100.64.0.0/10 to NAT in both directions. Each sees the other end in 100.64 space, but the mappings can get tricky and hard to keep track of (especially if you’re not a network engineer). In spitballing, the boat hasn’t sailed too far to say “Why not use 100.64/10 in the VPC?” Then, the customer would be allocated a /28 or larger (depending on needs) to NAT on their side and NAT it once. After that, no more NAT for the VPC and it boils down to firewall rules. Their device needs to NAT outbound before it fires it down the tunnel which pfSense and ASA’s appear to be able to do. I prototyped this up over the weekend with multiple VPC’s in multiple regions and it “appears” to work fine. From the operator community, what are the downsides? Customers are businesses on dedicated business services vs. consumer cable modems (although there are a few on business class cable). Others are on MPLS and I’m hashing that out. The only one I can see is if the customer has a service provider with their external interface in 100.64 space. However, this approach would have a more specific in that space so it should fire it down the tunnel for their allocated customer block (/28) vs. their external side. Thoughts and thanks in advance. Eric Wouldn't it be nice if Amazon supported IPv6 in VPC? I have disqualified several projects from using the public cloud and put them in the on-premise private cloud because Amazon is missing this key scaling feature -- ipv6. It is odd that Amazon, a company with scale deeply in its DNA, fails so hard on IPv6. I guess they have a lot of brittle technical debt they can't upgrade. I suggest you go with private cloud if possible. Or, you can double NAT non-unique IPv4 space. Regarding 100.64.0.0/10, despite what the RFCs may say, this space is just an augment of RFC1918 and i have already deployed it as such. CB
OT: VPS with Routed IP space
Anybody know of or have recommendations for providers of small VPS-line boxen (or alternative solutions) to serve as GRE endpoints? (for a small amount of IP addresses, /29 or /28 at most) I am finding a lot of places that will give you extra IPs on the box itself (oftentimes out of the provider's own larger unsubnetted prefix) but I am looking more for a setup with a single IP on the box and a prefix routed to it. TIA for your insight. Alex (if you or your company can do this, direct solicitations are okay too. do keep in mind it's just a personal project and I do not have larger commercial volume at this time)
Re: OT: VPS with Routed IP space
You just need to enable proxy ARP on the box to simulate a routed subnet. Den 24/02/2015 19.25 skrev Alex Buie alex.b...@frozenfeline.net: Anybody know of or have recommendations for providers of small VPS-line boxen (or alternative solutions) to serve as GRE endpoints? (for a small amount of IP addresses, /29 or /28 at most) I am finding a lot of places that will give you extra IPs on the box itself (oftentimes out of the provider's own larger unsubnetted prefix) but I am looking more for a setup with a single IP on the box and a prefix routed to it. TIA for your insight. Alex (if you or your company can do this, direct solicitations are okay too. do keep in mind it's just a personal project and I do not have larger commercial volume at this time)
Re: OT: VPS with Routed IP space
never saw that post. right up my alley. Thanks! On Tue, Feb 24, 2015 at 8:04 PM, Jared Mauch ja...@puck.nether.net wrote: On Feb 24, 2015, at 7:45 PM, William Herrin b...@herrin.us wrote: On Tue, Feb 24, 2015 at 1:18 PM, Alex Buie alex.b...@frozenfeline.net wrote: Anybody know of or have recommendations for providers of small VPS-line boxen (or alternative solutions) to serve as GRE endpoints? (for a small amount of IP addresses, /29 or /28 at most) I am finding a lot of places that will give you extra IPs on the box itself (oftentimes out of the provider's own larger unsubnetted prefix) but I am looking more for a setup with a single IP on the box and a prefix routed to it. Hi Alex, You can usually deconfigure the extra IP's on the box and send them down the tunnel. At worst you do a little proxy arp to tell the router that your vps still serves those addresses. You'll find providers are reluctant to assign /28's and /29's to low-dollar VPS services. On Tue, Feb 24, 2015 at 3:29 PM, Zachary Giles zgi...@gmail.com wrote: How about VPS providers who will do BGP... Do they exist? They do but it's BYOA and $10/mo generally doesn't cut it. Nat Morris has been doing this, here’s a presentation he has on this topic: http://www.slideshare.net/natmorris/anycast-on-a-shoe-string - Jared -- Zach Giles zgi...@gmail.com
Re: AOL Postmaster
For anyone having issues with AOL right now, if you would like, contact me offlist and I will see what I can do about getting it in front of our contact at AOL. Please be as specific as you can be about the issue, about who controls the IPs, about your own role and authority over the IPs and the email that flows through them, and please include at least one sample if possible. Anne Anne P. Mitchell, Esq. CEO/President ISIPP SuretyMail Email Reputation, Accreditation Certification Your mail system + SuretyMail accreditation = delivered to their inbox! http://www.SuretyMail.com/ http://www.SuretyMail.eu/ Author: Section 6 of the Federal CAN-SPAM Act of 2003 Member, California Bar Cyberspace Law Committee Ret. Professor of Law, Lincoln Law School of San Jose 303-731-2121 | amitch...@isipp.com | @AnnePMitchell | Facebook/AnnePMitchell
Re: OT: VPS with Routed IP space
On Tue, Feb 24, 2015 at 1:18 PM, Alex Buie alex.b...@frozenfeline.net wrote: Anybody know of or have recommendations for providers of small VPS-line boxen (or alternative solutions) to serve as GRE endpoints? (for a small amount of IP addresses, /29 or /28 at most) I am finding a lot of places that will give you extra IPs on the box itself (oftentimes out of the provider's own larger unsubnetted prefix) but I am looking more for a setup with a single IP on the box and a prefix routed to it. Hi Alex, You can usually deconfigure the extra IP's on the box and send them down the tunnel. At worst you do a little proxy arp to tell the router that your vps still serves those addresses. You'll find providers are reluctant to assign /28's and /29's to low-dollar VPS services. On Tue, Feb 24, 2015 at 3:29 PM, Zachary Giles zgi...@gmail.com wrote: How about VPS providers who will do BGP... Do they exist? They do but it's BYOA and $10/mo generally doesn't cut it. Regards, Bill Herrin -- William Herrin her...@dirtside.com b...@herrin.us Owner, Dirtside Systems . Web: http://www.dirtside.com/
ARIN+NANOG On The Road
Thank you to all who put this event on! It was fun getting to meet everyone :) Eric Miller, CCNP Network Engineering Consultant (407) 257-5115
Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment
http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-peering.html On 2/24/15 10:59 AM, Blair Trosper wrote: In VPC, you can also designate your own subnets, which makes things a little more tough a la interconnecting the disparate regions. On Tue, Feb 24, 2015 at 12:27 PM, Luan Nguyen lngu...@opsource.net wrote: Shouldn't it be the other way around? Ipv6 as the unique universal external network and you can define your own IPv4 within your cloud context separate from the cloud provider network and from other customers. So if you have contexts in different region - you can interconnect using layer 3 or layer 2 - through the cloud provider network...bring your own IPv4. If you need internet access, you'll get NATted. If you need connections to your branches/HQs...etc, build your own tunnel or use the cloud provider - which by the way gives you your own vrf so no need to worry about overlapping anything. Noone heard of Dimension Data Cloud? :) On Tue, Feb 24, 2015 at 1:10 PM, Blair Trosper blair.tros...@gmail.com wrote: ADDENDUM: They're taking into consideration my suggestion of using IPv6 as a universal internal network so that the different regions could be interconnected without having to give up the region-independent use of 10.0.0.0/8, which I think would be an elegant solution. On Tue, Feb 24, 2015 at 12:08 PM, Blair Trosper blair.tros...@gmail.com wrote: I have an unimpeachable source at AWS that assures me they're working hard to deploy IPv6. As it was explained to me, since AWS was sort of first to the table -- well before IPv6 popped, they had designed everything on the v4 only. Granted, you can get an IPv6 ELB, but only in EC2 classic, which they're phasing out. But I'm assured they're rushing IPv6 deployment of CloudFront and other services as fast as they can. I'm assured of this. But you also have to appreciate the hassle of retrofitting a cloud platform of that scale, so I do not envy the task that AWS is undertaking. On Tue, Feb 24, 2015 at 11:35 AM, Owen DeLong o...@delong.com wrote: Amazon is not the only public cloud. There are several public clouds that can support IPv6 directly. I have done some work for and believe these guys do a good job: Host Virtual (vr.org http://vr.org/) In no particular order and I have no relationship with or loyalty or benefit associated with any of them. I neither endorse, nor decry any of the following: Linode SoftLayer RackSpace There are others that I am not recalling off the top of my head. Owen On Feb 23, 2015, at 07:52 , Ca By cb.li...@gmail.com wrote: On Mon, Feb 23, 2015 at 7:02 AM, Eric Germann ekgerm...@cctec.com wrote: Currently engaged on a project where they’re building out a VPC infrastructure for hosted applications. Users access apps in the VPC, not the other direction. The issue I'm trying to get around is the customers who need to connect have multiple overlapping RFC1918 space (including overlapping what was proposed for the VPC networks). Finding a hole that is big enough and not in use by someone else is nearly impossible AND the customers could go through mergers which make them renumber even more in to overlapping 1918 space. Initially, I was looking at doing something like (example IP’s): Customer A (172.28.0.0/24) — NAT to 100.127.0.0/28 —— VPN to DC —— NAT from 100.64.0.0/18 —— VPC Space (was 172.28.0.0/24) Classic overlapping subnets on both ends with allocations out of 100.64.0.0/10 to NAT in both directions. Each sees the other end in 100.64 space, but the mappings can get tricky and hard to keep track of (especially if you’re not a network engineer). In spitballing, the boat hasn’t sailed too far to say “Why not use 100.64/10 in the VPC?” Then, the customer would be allocated a /28 or larger (depending on needs) to NAT on their side and NAT it once. After that, no more NAT for the VPC and it boils down to firewall rules. Their device needs to NAT outbound before it fires it down the tunnel which pfSense and ASA’s appear to be able to do. I prototyped this up over the weekend with multiple VPC’s in multiple regions and it “appears” to work fine. From the operator community, what are the downsides? Customers are businesses on dedicated business services vs. consumer cable modems (although there are a few on business class cable). Others are on MPLS and I’m hashing that out. The only one I can see is if the customer has a service provider with their external interface in 100.64 space. However, this approach would have a more specific in that space so it should fire it down the tunnel for their allocated customer block (/28) vs. their external side. Thoughts and thanks in advance. Eric Wouldn't it be nice if Amazon supported IPv6 in VPC? I have disqualified several projects from using the public cloud and put them in the on-premise private cloud because Amazon is
Re: AOL Postmaster
The quickest way of contacting the AOL Mail Team I'm aware of is through their Twitter account at @AOLMail (https://twitter.com/AOLMail). Tell them @6 sent you. ;) Cordially, A - ~~ vox: +1 202 459 9800 x.1300 // secure: +1 410 874 0050 (phone calls need to be arranged in advance) e: adr...@2600.com // e: adrian.l...@us.army.mil GPG/PGP public key: https://keybase.io/comsec/key.asc PGP Fingerprint (64 bit): 324B EE81 A275 E619 (COMSEC First! Verify fingerprint before using key.) ~~ El 2015-02-24 13:03, Suresh Ramasubramanian escribió: And how many users do you have, again? On Feb 24, 2015 6:29 PM, Colin Johnston col...@gt86car.org.uk wrote: block aol like china blocks with no engagement of comms as justification colin Sent from my iPhone On 24 Feb 2015, at 12:36, Rich Kulawiec r...@gsp.org wrote: On Tue, Feb 24, 2015 at 03:19:06AM +0100, Fred wrote: Having exactly the same issue. Also never received any response from AOL. Quite annoying. I've been waiting since January 26th for a response from dmarc-h...@teamaol.com, which is their stipulated contact point for DMARC issues. Of course I wouldn't *need* a response about that if they hadn't implemented DMARC so foolishly. It seems that the days when Carl Hutzler ran the place -- and ran it well -- are now well behind them. I didn't always agree with their decisions, but it was obvious that they were working hard and trying to make AOL a good network neighbor, so even when I disagreed I could at least acknowledge their good intentions. It seems now that AOL is determined to permit unlimited abuse directed at the entire rest of the Internet while simultaneously making life as difficult as possible for everyone who *doesn't* abuse...and is counting on their size to make them immune from the consequences of that decision. ---rsk
RE: OT: VPS with Routed IP space
ARP Networks: https://www.arpnetworks.com/vps Routed IP space (v4 and v6) as well as BGP peering. -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Zachary Giles Sent: Tuesday, February 24, 2015 12:29 PM To: Owen DeLong Cc: NANOG Subject: Re: OT: VPS with Routed IP space Partial thread jack How about VPS providers who will do BGP... Do they exist? /Partial thread jack [...] Den 24/02/2015 19.25 skrev Alex Buie alex.b...@frozenfeline.net: Anybody know of or have recommendations for providers of small VPS-line boxen (or alternative solutions) to serve as GRE endpoints? [...]
Quality of ROAs in RPKI repositories
Hi all, As part of my master thesis and research work at IIJ, I've created a page to monitor the quality of ROAs in all RIR's RPKI repositories. http://rpki.me/quality.html Overall, the ROAs are quite good. Of course there are problems: I found out some ROAs which are very likely to be mis-registrations and make several BGP announcements invalid. On the page you can see the list of those ROAs, and the list of BGP announcements related to each of them. I would suggest to check if any of your prefixes are on this list. These problems could be easily fixed by registering correct ROAs. What I do is basically origin-validating BGP announcements that I find in a RIB dump from LINX node of route-views, using ROAs taken from a validated RPKI cache (using rcynic). You can find other information on under the what does this table mean? button. I'm also keeping updated a page monitoring which DNS root servers have their BGP announcements covered by a valid ROA: http://rpki.me/dns.html I would appreciate to hear any comment or suggestion. Regards -- Daniele Iamartino Student at Politecnico di Milano, Italy
Re: OT: VPS with Routed IP space
On Feb 24, 2015, at 7:45 PM, William Herrin b...@herrin.us wrote: On Tue, Feb 24, 2015 at 1:18 PM, Alex Buie alex.b...@frozenfeline.net wrote: Anybody know of or have recommendations for providers of small VPS-line boxen (or alternative solutions) to serve as GRE endpoints? (for a small amount of IP addresses, /29 or /28 at most) I am finding a lot of places that will give you extra IPs on the box itself (oftentimes out of the provider's own larger unsubnetted prefix) but I am looking more for a setup with a single IP on the box and a prefix routed to it. Hi Alex, You can usually deconfigure the extra IP's on the box and send them down the tunnel. At worst you do a little proxy arp to tell the router that your vps still serves those addresses. You'll find providers are reluctant to assign /28's and /29's to low-dollar VPS services. On Tue, Feb 24, 2015 at 3:29 PM, Zachary Giles zgi...@gmail.com wrote: How about VPS providers who will do BGP... Do they exist? They do but it's BYOA and $10/mo generally doesn't cut it. Nat Morris has been doing this, here’s a presentation he has on this topic: http://www.slideshare.net/natmorris/anycast-on-a-shoe-string - Jared
Re: v6 deagg
On Tue, Feb 24, 2015 at 12:27 PM, Owen DeLong o...@delong.com wrote: On Feb 19, 2015, at 21:25 , Christopher Morrow morrowc.li...@gmail.com wrote: On Thu, Feb 19, 2015 at 10:16 PM, manning bill bmann...@isi.edu wrote: and then there are the loons who will locally push /64 or longer, some of which may leak. 2001:2b8:46:::/64 ... a fairly extensive list actually show route table inet6.0 | grep ^2 | except /4[876543210] | except /3 | except /2 | count Count: 297 lines Some are likely my local network's interfaces (so skip ~50 or so? to be generous) and some might be my provider's customers? (but they shouldn't send me shorter than a /48, right?) -chris (note on another observation point I don't see this sort of thing so perhaps it's just one upstream in a collection... I'll ask them seperately) Your regular expression will not only count /49 and longer, it will also count /19 and shorter. In my routing table, there are at least some examples of such routes. yup, not very many and I think not enough to matter over all, give then actual point was I see many smaller (longer?) than /48 in the table.
Re: OT: VPS with Routed IP space
On 2/24/15 1:42 PM, Michael Helmeste wrote: ARP Networks: https://www.arpnetworks.com/vps Routed IP space (v4 and v6) as well as BGP peering. +1 for Arp, I'm a happy customer (no other affiliation). FWIW, Doug
Re: OT: VPS with Routed IP space
Thanks to those who mailed off-list for the BGP thread-jack. Seems like those providers that do BGP would probably route their own space to VPS as well.. (Like OP want. if I understand correctly). Some of them even state that they even SWIP the addresses, which is positive. On Tue, Feb 24, 2015 at 5:59 PM, Doug Barton do...@dougbarton.us wrote: On 2/24/15 1:42 PM, Michael Helmeste wrote: ARP Networks: https://www.arpnetworks.com/vps Routed IP space (v4 and v6) as well as BGP peering. +1 for Arp, I'm a happy customer (no other affiliation). FWIW, Doug -- Zach Giles zgi...@gmail.com
Re: v6 deagg
On Tue, Feb 24, 2015 at 1:16 PM, Sander Steffann san...@steffann.nl wrote: Bill Herrin said: I don't fully understand the math yet but the algorithm doesn't smell right. As near as I can figure it may only be correct in a static system. If after convergence the disaggregate ceases to be reachable from the aggregate, there doesn't appear to be either enough information in the system or enough triggers traveling between routers for it to reconverge to a correct state. If a network announces an aggregate when they can't reach all more-specifics then things will already be broken. Don't announce address space that you can't handle traffic for... Howdy, That's... basically the opposite of how customer cutout routes work today. Funny thing about customers... when they go to the trouble of announcing a route to another ISP, they expect it to work even when the link to you fails. Not sure where they came up with such an unreasonable expectation. ;) Anyway, I heard back from DRAGON's authors. Paraphrasing: An aggregate (e.g. 10.0.0.0/8) must be withdrawn if the aggregate's origin loses its direct route to the filterable disaggregate's origin (e.g. 10.2.3.0/24). The withdrawn aggregate is replaced with a synthesized set of announcements which fully cover the aggregate's address space excluding the unreachable disaggregate (e.g. 10.0.0.0/15, 10.2.0.0/23, 10.2.2.0/24, 10.2.4.0/22, 10.2.8.0/21, 10.2.16.0/20, etc.) When direct connectivity is restored, the aggregate is again announced and the synthetic announcements withdrawn. This overcomes my objection. The aggregate's origin can reasonably be programmed to trigger on the nearby disaggregate's withdrawal. System-wide withdrawal of the aggregate route is a sufficient trigger to cancel filtering on the disaggregate which should then fully propagate. And the overall savings should still be substantial even with transient synthetics in the table. I look forward to seeing how the authors address the many implications of this requirement. I'm not sold just yet but I am suitably impressed. Regards, Bill Herrin -- William Herrin her...@dirtside.com b...@herrin.us Owner, Dirtside Systems . Web: http://www.dirtside.com/
