That feature requires you to use a private IP address, so if you have a VPN or Direct Connect to another location you could load balance across locations. In the case of the global load balancers those will be public addresses though.
"The IP addresses that you register must be from the subnets of the VPC for the target group, the RFC 1918 range (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16), and the RFC 6598 range (100.64.0.0/10). You cannot register publicly routable IP addresses."
If you know your AWS account team, they'd like to get that feedback. Otherwise my contact information is in my profile and you can email me and I can try to connect you to some AWS folks responsible for the partner as well.
yes, with partner at high level (competencies) I read that partner requesting to be partner have to be checked by a 3rd party:
"Once your firm’s application has been submitted through the APN (aws,ndr) Portal, the APN Team will review for
compliance, then send to the third party audit firm to coordinate scheduling of the technical review."
so there is somehow a double check on partner competencies.
So, as I see, we made the mistake of choosing a "normal" partner and not one with competencies.
Do you think aws care some how to know our "bad" experience to get a better network of partners? or should be expect them to tell us: get a "competent" partner?
Mistake seems like a harsh word here. There are lots of partners that aren't in the competency tier that do perfectly fine work. But we try to highlight the ones we can somehow quantify as 'top tier', which is competency. It's imperfect just like any other subjective rating.
AWS definitely cares about any bad experiences. It's the way we improve things for customers, so let us (or me, or anyone at AWS) know the details.
Basically integrating OVS APIs into Docker so it could use more mature networking code as well as VXLAN forwarding. VXLAN is basically IP encapsulation (a 16-bit ID) that the networking industry has standardized on. It more or less allows for L2 over L3 links. I like to think of it as the next Spanning Tree.
So the unwieldy part is the weight OVS brings as well as the VXLAN encapsulation in software - both of which have momentum towards being more lightweight.
I've been on break/fix and on the Sales Engineer side and know both - there's never a single side to these things.
Sales Engineers in particular don't want to sell something dishonestly - it opens the company up to risk and it hurts their credibility, particularly if you sell multiple products.
There are a few reasons I can think of:
1. The technical people that run the current implementation didn't put their requirements into the sales process.
2. Some of those features really don't matter to the business and were fodder.
3. The requirements were listed, but not accurately or with enough depth.
4. The Sales team didn't have enough knowledge (or training) to know the difference - or inaccurate documentation.
5. It was roadmapped close enough to implementation and including delays to go ahead anyway.
6. The competitor claims to have this feature but theirs is broken also, so it's a race to who can sell broken stuff faster - because nobody can truly do it.
The people and the companies that support this exist certainly - just not for very long.
I see different incentives within my own organization. Sales and sales engineers makes commission so they want to close the deal no matter what. I deliver a specific product so I just want to get it done and stay under budget. Another consulting group handles the long term customer relationship so they are more inclined to give away free work for future relationship building that I am not incentivized to want to do.
Skype pulls in a lot of revenue in the OCS/Lync product set. Companies want still largely want to be able to IM MSN, Yahoo, Skype, and AOL users and they're the only ones that have access to all those user groups. They also leverage B2C video/calls to Skype users.
Not a flame - your perspective is very typical for people that don't have a lot of experience with networking past the host or server level. (Very little experience with networking in the core, provider, or putting together network services architecture).
1. In theory the routing table with IPv6 can be smaller. The address design should be hierarchical, which means you should be able to have much fewer routes. It's too early to tell if this is actually true or not, but the addresses themselves are 4x larger - which isn't going to be the determining factor in routing table size.
2. Not everything needs to be publically routable, true. IPv6 has the idea of link local and autonomous system local addressing which IPv4 doesn't have. The RFC 1918 block was used instead. But think for a second - there's only 4 billion addresses (less when you count bogons and multicast ranges), and it's only a matter of time until those are taken up. So we can choose to do it now, 2 years from now, or 5 years from now, but devices are growing faster than ever and it's only a function of time.
3. NAT is not a security feature, is not good for the internet, and the sunk costs spent building an ALG for every protocol to work around it is a significant development sinkhole. It's a workaround often masqueraded as security, and does cause many application problems. It's just not normally the application developers that have to fix those problems - it's the network and security teams.
4. IPv6 was created in the late 90's. People have been waiting for brilliance to supercede IPv6 for a while. I'll admit it's not the easiest, but there are a certain set of problems you have when you expand the address space.
5. I'm familiar with all the IPv4 headers, and nearly all of them are used. ID is used for packet identification, particularly through network services, DSCP is used heavily, DF and other flags are used - they're just obscure. If you look at IPv6 those same headers are basically recreated, though with slightly different names. The ones that aren't included are addressable through the extension headers.
So, yeah. That's another perspective that may help you understand why IPv6 is a bit of a quagmire. The faster people understand this, the sooner we get to a place where the chicken-egg problem fades away.
I only care about one point. That NAT is not a security feature.
The original reason that I began using NAT was so that my ISP couldn't charge me per device. You just plugged in a NAT enabled router, and ran everything behind it. That became so ubiquitous that ISPs gave up on trying.
My concern about IPv6 is that ISPs will want to go back to charging per device. I didn't like that then, and I don't want it now.
From a host perspective it's a great security feature.
you have a local address means your host cannot be contacted from the outside world.
You want your host to have an IPv6 address, VPN into an IPv6 provider.
The fact that demand for this is so low, just goes to show it's not needed at the moment.
In fact, I can't think of a single reason "why" IPv6 would be needed.
I definately don't want all my devices to have a web reachable address, far from it, total security nightmare.
one entry point - a VPN on IPv4 is just great thanks, secure and easy to manage. want to access my other devices, jump on the VPN.
I that sense, you can describe IPv6 security, as configuring your VPN with no password and letting anyone connect to it.
The other way to look at it, is the successsor to IPv4 is called tor.
> one entry point - a VPN on IPv4 is just great thanks, secure and easy to manage. want to access my other devices, jump on the VPN.
There are 4 billion IPv4 addresses and 7 billion people on the planet. Before we even get into business use of IPv4 for servers and such we don't have enough addresses to do what you want.
Is that even remotely close to being true in practise? Would we expect to see it be smaller than IPv4? Given the quadrupling of address sizes, wouldn't that mean there'd need to be 1/4th the number of routes? And peering destroys the hierarchy, does it not?
I was under the impression that the hierarchical routing had an assumption that networks could renumber at will. So multiple subnets might map to the same host or something to that effect. Is that incorrect?
>3. NAT is not a security feature
Except it turns out that proper NAT is equivalent to a firewall with inbound deny, outbound allow. Which is a pretty good start for security.
>ALG for every protocol
Applications that break with NAT usually do so due to poor design (hey SIP and FTP). With a firewall with default inbound deny, programs can't just accept inbound connections without doing work anyways (UPnP or whatnot). Although sure, it makes known-two-way datagram applications easier since you start transmitting and get a flow opened. Wouldn't help TCP based applications, for instance.
> Is that even remotely close to being true in practise? Would we expect to see it be smaller than IPv4? Given the quadrupling of address sizes, wouldn't that mean there'd need to be 1/4th the number of routes? And peering destroys the hierarchy, does it not?
No.. the point is that each ISP will get only one very large prefix (/32 or bigger) instead of many small ones, which can't be aggregated like it is the case for IPv4.
Right now there are about 46k ASN's in the legacy internet announcing about 490k IPv4 routes. Best case with IPv6 you would end up with 46k routes.
In practise it looks like there are 8k ASNs in the internet announcing about 16k IPv6 routes. So while not perfect, it's still quite a lot better than for the legacy internet.
> Applications that break with NAT usually do so due to poor design
So how would you design a P2P application that has no poor design?
Might the current IPv6 numbers just reflect that a lot of people aren't peering or anything? I was under the impression that a lot of announcements were driven by the need for not relying on a single provider.
>So how would you design a P2P application that has no poor design?
SIP and FTP break even in non-P2P scenarios, so my comment was mainly directed at them. For P2P apps, NAT doesn't pose a whole lot more of a problem than a firewall with the same configuration. So you'd use UPnP or whatever protocol to get around it. At that point, it doesn't really matter, does it? The app talks to local gateway and ask for the IP and port forwarding either way.
> Might the current IPv6 numbers just reflect that a lot of people aren't peering or anything?
Peering doesn't require you to announce more routes per se, although some networks do it for traffic engineering purposes. From an BGP [1] perspective there is not that much difference between peering and transit.
> I was under the impression that a lot of announcements were driven by the need for not relying on a single provider.
Multihoming is another issue. And you can explain the difference in the number of AS [2] as networks not having deployed IPv6 yet. But the number of announced routes per network will be lower for IPv6 than it is for IPv4 (which hasn't even reached the worst case yet).
> For P2P apps, NAT doesn't pose a whole lot more of a problem than a firewall with the same configuration. So you'd use UPnP or whatever protocol to get around it. At that point, it doesn't really matter, does it? The app talks to local gateway and ask for the IP and port forwarding either way.
But that way you are still pushing more logic into the applications (namely that they have to implement UPnP). Which actually might end up requiring more code than your actual application (SAFT [3] for instance..). Now in the firewall you could just allow known-good inbound ports and be done with it.
Trying to plot this it means that the crunch will probably really hit increasingly hard from about 2015 through 2016. You go from predicting two years out to one year out (two years later).
These aren't brick walls but the shortage is already being felt. I know that at Efficito, one of the reasons we switched hosting providers was that we couldn't get ipv6 connections working flawlessly to our backup connections before (meaning more ipv4 space required). I don't think we will ever hit exhaustion per se.
There are downside to AWS other than reliability (a la Netflix). One of those is privacy. If you host with AWS Amazon has access to all of your user data, and with Amazon likely the NSA. If you want to maintain a free and open forum for people to express support for people like Snowden and Assange and question the NSA or military / industrial complex' percent of the federal budget (>50) then you have to run your own servers in a skilled, ethical, small to mid-sized ISP's facility.
This doesn't explain the penny-wise (IMO) allocation of hardware or dev/sysadmin resources of course.
Interesting, I'm at 1084 days so I missed a chance at a round-number-blog-post.
I would echo many of the same things. I graduated with a computer science degree (and computer systems engineering) but up until about a year ago I had not written a single program. I've started kicking around with Python again, have signed up for Coursera courses that involve Github, AWS, and programming. As well, it's helping me professionally because I'm gradually moving away from VoIP technologies into datacenter networking where Dev Ops, AWS, IaaS, and the latest programming trends are important. I got an Arduino and started hacking around with it as well.
Even though I'm not at a startup, I try to treat my job with the same type of entrepreneurial spirit as those touted in the Silicon Valley Startup Echo Chamber posts. I try to keep in mind many of the core entrepreneurial concepts - fail fast, iterate, A/B test, get feedback, focus on value, user experience is paramount, etc in mind with my comparatively tame 'cushy' corporate job.
Just checked for and I joined 8 days prior to you. 1092 so far.
I remember stumbling upon HN a few months prior and initially was wondering the 'hacker' part but for whatever reason my google search for a few weeks was always redirecting me to some HN threads one way or another.
"The IP addresses that you register must be from the subnets of the VPC for the target group, the RFC 1918 range (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16), and the RFC 6598 range (100.64.0.0/10). You cannot register publicly routable IP addresses."
[1] https://docs.aws.amazon.com/elasticloadbalancing/latest/netw...