Re: v6 deagg
On Feb 20, Saku Ytti s...@ytti.fi wrote: Is deaggregation inherently undesirable? In some RIR LIR will not get new No. Excessive deaggregation is undesirable, but we lack a method to teach routers to enforce this subtlety and maybe also a wide agreement on what is excessive. allocation, just because LIR lacks INET connectivity between their datacenter or pop. This wasn't issue in IPv4, because you actually could reasonably fill your IPv4 allocation and were eligible for another allocation for your discontinuous locations. But at least in the RIPE region this can be easily solved by deaggregating /32s out of your /29. -- ciao, Marco pgpMElo4U_R7A.pgp Description: PGP signature
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.
Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment
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
Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment
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: Comcast Support (from NANOG Digest, Vol 84, Issue 23)
FWIW, if you phone support you generally end up with a tier-1 person. In cases where people have more technical background, you may want to try things that land in more senior levels of Care (or even get checked by engineering directly) such as: - Customer support forums: http://forums.comcast.com/comcastsupport/ - Twitter: @ComcastCares https://twitter.com/comcastcares - Broadband Reports forum: http://www.dslreports.com/forum/comcast - Reddit: http://www.reddit.com/r/comcast - Jason On 2/23/15, 1:25 AM, Peter Loron pet...@standingwave.orgmailto: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
Re: What would you do about questionable domain pointing A record to your IP address?
Thank you, everyone, for all of the responses, both on and offlist! 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: AOL Postmaster
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
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
Ok, it took 21 days from the time I opened a ticket with them last month for them to respond to me. I ended up having to have our ISP update our rDNS. Not sure if it's something similar for you but I felt the same way after a week of waiting for a response from them. On Feb 23, 2015 3:56 PM, John Zettlemoyer j...@west-canaan.net wrote: 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: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment
On Mon, Feb 23, 2015 at 10:02 AM, Eric Germann ekgerm...@cctec.com wrote: In spitballing, the boat hasn't sailed too far to say Why not use 100.64/10 in the VPC? 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. 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 -- William Herrin her...@dirtside.com b...@herrin.us Owner, Dirtside Systems . Web: http://www.dirtside.com/
Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment
I put lots of these to good use http://en.wikipedia.org/wiki/Reserved_IP_addresses Regarding public cloud with ipv6 support, contact me off-list i might even get you a special discount On Mon, Feb 23, 2015 at 10:52 AM, 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
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 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).
AOL Postmaster
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: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment
Subject: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment Date: Mon, Feb 23, 2015 at 10:02:44AM -0500 Quoting Eric Germann (ekgerm...@cctec.com): Currently engaged on a project where they’re building out a VPC infrastructure for hosted applications. snip Thoughts and thanks in advance. using the wasted /10 for this is pretty much equal to using RFC1918 space. IPv6 was invented to do this right. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 It's NO USE ... I've gone to CLUB MED!! signature.asc Description: Digital signature
Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment
On Mon, Feb 23, 2015 at 9:02 AM, Eric Germann ekgerm...@cctec.com wrote: In spitballing, the boat hasn’t sailed too far to say “Why not use 100.64/10 in the VPC?” Read RFC6598. If you can assure the conditions are met that are listed in 4. Use of Shared CGN Space.. Then usage of the 100.64/10 shared space may be applicable, under other conditions it may be risky; the proper usage of IP addresses is in accordance with the standards or by the registrant under the right assignment agreements. If you are just needing space to squat on regardless of the standardized usage, then you might do anything you want --- you may as well use 25/8 or 11.0.0.0/8 internally, after taking steps to ensure you will not be leaking Reverse DNS queries, routes, or anything like that, this space is larger than a /10 and would provide more expansion flexibility. 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. -- -JH
Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment
Then usage of the 100.64/10 shared space may be applicable, under other conditions it may be risky about as risky as the rest of private address space. randy
Re: v6 deagg
On Mon, Feb 23, 2015 at 1:33 PM, Randy Bush ra...@psg.com wrote: you might find http://www.route-aggregation.net/ interesting Hi Randy, I found it very interesting. Wish I'd noticed when it was fresh. 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. Deriving only from the information available to each router at each step, look at page 58 in the presentation and see if you can figure out what happens to the network in that start state when the link between u7 and u9 drops. Remember that all the slashed half-moons mean that the router in that position does not relay the disaggregate and, in most cases, does not know that the disaggregate exists. I've emailed the authors and asked them to clarify. I hope I'm wrong. I'm tried of being a killjoy on this sort of thing and it would be truly cool if it turns out they've cracked the problem. Regardless, if we could presume (with support from the registries) that disaggregates are always reachable from the aggregate (always TE, never downstream customers or discrete sites) and everybody with an address block was courteous enough to advertise an aggregate then it might be usable to control IPv6 deagg. Actually, as long as we could assume the first part we could probably have routers synthesize aggregates to cover the second. But without the first assumption it looks dysfunctional. I discussed the cutouts problem in my 2010 presentation to ARIN XXVI in Atlanta: https://bill.herrin.us/network/201010-cutouts.pdf Regards, Bill Herrin -- William Herrin her...@dirtside.com b...@herrin.us Owner, Dirtside Systems . Web: http://www.dirtside.com/
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: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment
Might be ill-advised since AWS uses it themselves for their internal networking. Just traceroute to any API endpoint from an EC2/VPC resource or instance. :) On Mon, Feb 23, 2015 at 2:43 PM, Måns Nilsson mansa...@besserwisser.org wrote: Subject: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment Date: Mon, Feb 23, 2015 at 10:02:44AM -0500 Quoting Eric Germann (ekgerm...@cctec.com): Currently engaged on a project where they’re building out a VPC infrastructure for hosted applications. snip Thoughts and thanks in advance. using the wasted /10 for this is pretty much equal to using RFC1918 space. IPv6 was invented to do this right. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 It's NO USE ... I've gone to CLUB MED!!
Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment
Mulling over the implications of this. [root@ip-100-64-0-55 ~]# traceroute s3.amazonaws.com traceroute to s3.amazonaws.com (54.231.0.64), 30 hops max, 60 byte packets 1 ec2-79-125-0-202.eu-west-1.compute.amazonaws.com (79.125.0.202) 1.068 ms 0.824 ms 0.787 ms 2 178.236.1.18 (178.236.1.18) 1.193 ms 1.164 ms 0.869 ms 3 * * * 4 54.239.41.133 (54.239.41.133) 76.046 ms 76.029 ms 75.986 ms 5 54.239.41.166 (54.239.41.166) 76.314 ms 76.281 ms 76.244 ms 6 72.21.220.77 (72.21.220.77) 76.143 ms 76.054 ms 76.095 ms 7 205.251.245.224 (205.251.245.224) 76.346 ms 72.21.222.149 (72.21.222.149) 76.261 ms 205.251.245.230 (205.251.245.230) 76.360 ms 8 * * * ... 30 * * * but, [root@ip-100-64-0-55 ~]# wget https://s3.amazonaws.com --2015-02-24 04:20:18-- https://s3.amazonaws.com/ Resolving s3.amazonaws.com... 54.231.12.48 Connecting to s3.amazonaws.com|54.231.12.48|:443... connected. HTTP request sent, awaiting response... 307 Temporary Redirect Location: http://aws.amazon.com/s3/ [following] --2015-02-24 04:20:18-- http://aws.amazon.com/s3/ Resolving aws.amazon.com... 54.240.250.195 Connecting to aws.amazon.com|54.240.250.195|:80... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: “index.html.1” [= ] 179,606 158K/s in 1.1s 2015-02-24 04:20:20 (158 KB/s) - “index.html.1” saved [179606] ICMP would break from the intermediates, but ICMP from the API endpoint should still work. Will have to chew on this a bit overnight. EKG On Feb 23, 2015, at 9:03 PM, Blair Trosper blair.tros...@gmail.com wrote: Might be ill-advised since AWS uses it themselves for their internal networking. Just traceroute to any API endpoint from an EC2/VPC resource or instance. :) On Mon, Feb 23, 2015 at 2:43 PM, Måns Nilsson mansa...@besserwisser.org mailto:mansa...@besserwisser.org wrote: Subject: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment Date: Mon, Feb 23, 2015 at 10:02:44AM -0500 Quoting Eric Germann (ekgerm...@cctec.com mailto:ekgerm...@cctec.com): Currently engaged on a project where they’re building out a VPC infrastructure for hosted applications. snip Thoughts and thanks in advance. using the wasted /10 for this is pretty much equal to using RFC1918 space. IPv6 was invented to do this right. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 tel:%2B46%20705%20989668 It's NO USE ... I've gone to CLUB MED!!
