https://aws.amazon.com/about-aws/whats-new/2016/10/amazon-route-53-now-supports-dns-queries-over-ipv6-networks/
https://aws.amazon.com/about-aws/whats-new/2016/10/ipv6-support-for-cloudfront-waf-and-s3-transfer-acceleration/ Still no AWS compute to my knowledge, but it looks like they are getting closer. On Oct 27, 2016 7:03 PM, "Mike Hammett" <[email protected]> wrote: > That's just the storage, right, not actual compute? > > > > ----- > Mike Hammett > Intelligent Computing Solutions <http://www.ics-il.com/> > <https://www.facebook.com/ICSIL> > <https://plus.google.com/+IntelligentComputingSolutionsDeKalb> > <https://www.linkedin.com/company/intelligent-computing-solutions> > <https://twitter.com/ICSIL> > Midwest Internet Exchange <http://www.midwest-ix.com/> > <https://www.facebook.com/mdwestix> > <https://www.linkedin.com/company/midwest-internet-exchange> > <https://twitter.com/mdwestix> > The Brothers WISP <http://www.thebrotherswisp.com/> > <https://www.facebook.com/thebrotherswisp> > > > <https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg> > ------------------------------ > *From: *"Josh Reynolds" <[email protected]> > *To: *[email protected] > *Sent: *Thursday, October 27, 2016 5:19:03 PM > *Subject: *Re: [AFMUG] [WISPA] IPV6 deploymernt > > https://aws.amazon.com/blogs/aws/now-available-ipv6-support-for-amazon-s3/ > > On Oct 27, 2016 2:49 PM, "Mike Hammett" <[email protected]> wrote: > >> Anyone in AWS won't, given AWS's poor to no IPv6 support. >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions <http://www.ics-il.com/> >> <https://www.facebook.com/ICSIL> >> <https://plus.google.com/+IntelligentComputingSolutionsDeKalb> >> <https://www.linkedin.com/company/intelligent-computing-solutions> >> <https://twitter.com/ICSIL> >> Midwest Internet Exchange <http://www.midwest-ix.com/> >> <https://www.facebook.com/mdwestix> >> <https://www.linkedin.com/company/midwest-internet-exchange> >> <https://twitter.com/mdwestix> >> The Brothers WISP <http://www.thebrotherswisp.com/> >> <https://www.facebook.com/thebrotherswisp> >> >> >> <https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg> >> ------------------------------ >> *From: *"Jason Wilson" <[email protected]> >> *To: *[email protected] >> *Sent: *Thursday, October 27, 2016 2:48:07 PM >> *Subject: *Re: [AFMUG] [WISPA] IPV6 deploymernt >> >> Is sonar the only CRM that supports IPV6? >> >> I know currently Visp Does not. >> >> >> Jason Wilson >> Remotely Located >> Providing High Speed Internet to out of the way places. >> 530-651-1736 >> 530-748-9608 Cell >> www.remotelylocated.com >> >> On Thu, Oct 27, 2016 at 12:37 PM, Simon Westlake <[email protected]> >> wrote: >> >>> What do you mean, 'even Sonar'? We aren't chopped liver! >>> >>> On 10/27/2016 2:12 PM, Dennis Burgess wrote: >>> >>> I would totally agree here. We have deployed IPv6 quite a bit for >>> clients, our networks etc. However, the major issue is the hosting >>> companies, most big guys, google, amazon, etc all support IPv6, heck even >>> Sonar does now! Hahah, but until the cost of IPv4 addresses is so high that >>> no one; even the major guys can afford it, IPv6 deployment will keep >>> stalling. >>> >>> >>> >>> >>> >>> *Dennis Burgess** –** Network Solution Engineer – Consultant * >>> >>> MikroTik Certified Trainer/Consultant >>> <http://www.linktechs.net/productcart/pc/viewcontent.asp?idpage=5> – >>> MTCNA, MTCRE, MTCWE, MTCTCE, MTCINE >>> >>> >>> >>> For Wireless Hardware/Routers visit www.linktechs.net >>> >>> Radio Frequiency Coverages: www.towercoverage.com >>> >>> Office: 314-735-0270 >>> >>> E-Mail: [email protected] >>> >>> >>> >>> *From:* Af [mailto:[email protected] <[email protected]>] *On >>> Behalf Of *Paul Stewart >>> *Sent:* Thursday, October 27, 2016 2:00 PM >>> *To:* [email protected] >>> *Subject:* Re: [AFMUG] [WISPA] IPV6 deploymernt >>> >>> >>> >>> Actually in my opinion what we need is better IPv6 adoption in general >>> and this becomes a non-problem quickly :) >>> >>> >>> >>> I know .. good theory … and “we” are getting better though …. a lot of >>> providers have gotten their heads out of the clouds in the past few years >>> alone …. >>> >>> >>> >>> >>> >>> On Oct 27, 2016, at 2:26 PM, Chuck McCown <[email protected]> wrote: >>> >>> >>> >>> What we all need, is a low cost solution to stop needing more V4 IPs. >>> >>> >>> >>> If it is CGN at the edge with a limited pool of V4, so be it. >>> >>> >>> >>> But I want a solid solution that can be trusted. >>> >>> And I want and expert to come drop it into my company. >>> >>> >>> >>> *From:* Paul Stewart >>> >>> *Sent:* Thursday, October 27, 2016 11:23 AM >>> >>> *To:* [email protected] >>> >>> *Subject:* Re: [AFMUG] [WISPA] IPV6 deploymernt >>> >>> >>> >>> while I’m not a fan of NAT64, CGN etc (but understand in some situations >>> the need for it), I completely agree that companies will be looking for >>> consultants to help with this in some scenarios (both large and small >>> companies alike) - this has been ongoing in some larger companies for many >>> years already (IPv6 adoption) and often through resident engineer >>> placements from vendors >>> >>> >>> >>> >>> >>> On Oct 27, 2016, at 11:59 AM, Chuck McCown <[email protected]> wrote: >>> >>> >>> >>> Some consultant needs to specialize in this and help folks provision, >>> configure, deploy, test etc. >>> >>> We all need this or will need this. >>> >>> >>> >>> *From:* Faisal Imtiaz >>> >>> *Sent:* Wednesday, October 26, 2016 8:31 PM >>> >>> *To:* af >>> >>> *Subject:* [AFMUG] Fwd: [WISPA] IPV6 deploymernt >>> >>> >>> >>> An excellent detailed solution (from one of the other forums). >>> >>> >>> >>> Faisal Imtiaz >>> Snappy Internet & Telecom >>> 7266 SW 48 Street >>> Miami, FL 33155 >>> Tel: 305 663 5518 x 232 >>> >>> Help-desk: (305)663-5518 Option 2 or Email: [email protected] >>> >>> >>> ------------------------------ >>> >>> *From: *"Tim Way" <[email protected]> >>> *To: *"WISPA General List" <[email protected]> >>> *Sent: *Tuesday, October 25, 2016 9:01:51 PM >>> *Subject: *Re: [WISPA] IPV6 deploymernt >>> >>> Art, >>> >>> So I know of two solid methods that could solve your problem. Neither >>> are super awesome and both would involve NAT. >>> >>> >>> >>> 1. IPv6 only to the client with NAT64 and DNS64 to handle IPv4 only >>> connectivity >>> >>> 2. IPv4 CGN Shared Address Space, RFC 6598 100.64.0.0/10, and IPv6 >>> Global Unicast running in Dual Stack >>> >>> >>> >>> Either one would work. I apologize in advance for the long post that >>> follows. >>> >>> >>> >>> I've only done the configurations on Cisco routers with the radios just >>> passing traffic at layer 2. I'd have to check the feature set of your >>> routers routing wise but it shouldn't be hard. It also could be built in a >>> lab with static routing largely. I think Mikrotik supports NAT64 but again >>> for a lab environment any recent Cisco device could be used with IP >>> Services licensing. >>> >>> >>> >>> Your address plan for your global unicast IPv6 space comes into play. >>> This is how I would lab it up including moving routing to the tower with >>> the CPE in bridge mode: >>> >>> >>> >>> Your fictional IPv6 prefix: 9999:8888::/32 >>> >>> >>> >>> Your NAT64 Prefix: 9999:8888:cc00::/96 >>> >>> >>> >>> Customer DHCPv6-PD Allocation Prefix: 9999:8888:aa00::/40 >>> >>> Your fictional customer #1: The Johnson Family, 9999:8888:aa00:0100::/56 >>> >>> Your fictional customer #2: The Billings' Family, >>> 9999:8888:aa00:0200::/56 >>> >>> >>> >>> Fictional Tower 1 >>> >>> ISP Mgmt VLAN of CPE: 11, 9999:8888:bb00:0011::/64 >>> >>> ISP Customer VLAN of CPE: 12, 9999:8888:bb00:0012::/64 >>> >>> ISP Router at the tower on VLAN 11: 9999:8888:bb00:0011::1/64 >>> >>> ISP Router at the tower on VLAN 12: 9999:8888:bb00:0012::1/64 >>> >>> >>> >>> The Johnson Family Setup: >>> >>> ISP CPE VLAN 11 IP: 9999:8888:bb00:0011::f/64 >>> >>> Customer's Netgear WAN Interface: 9999:8888:bb00:0012::f/64 >>> >>> Customer's Netgear LAN Interface: 9999:8888:aa00:010a::1/64 >>> >>> Customer's Netgear Guest WiFi: 9999:8888:aa00:010b::1/64 >>> >>> >>> >>> The Billings' Family Setup: >>> >>> ISP CPE VLAN 11 IP: 9999:8888:bb00:0011::e/64 >>> >>> Customer's Netgear WAN Interface: 9999:8888:bb00:0012::e/64 >>> >>> Customer's Netgear LAN Interface: 9999:8888:aa00:020a::1/64 >>> >>> Customer's Netgear Guest WiFi: 9999:8888:aa00:020b::1/64 >>> >>> >>> >>> 1. You'd bridge VLAN 12 through the CPE to customer's WAN interface as >>> the native VLAN and put the IP on VLAN 11. >>> >>> 2. If you use static routing and manual address assignment to eliminate >>> variables in the lab you'll want to add static routes on the tower router >>> for the ::/56 prefixes that would be allocated to each customer. Normally >>> these routes will be injected into the routing table at the DHCPv6 router >>> and could be distributed from there. >>> >>> 3. The last piece of the puzzle will be adding in the NAT64 and DNS64 >>> devices. BIND can do DNS64 and you could use a Cisco router to do the >>> NAT64. You'd want the "Customer's Netgear" to use the DNS64 server as it's >>> upstream DNS server to ensure that it receives AAAA records for sites that >>> only have A records. This is the fragile component of the DNS64 and NAT64 >>> deployment because it requires the customers computer or router uses your >>> resolver. You will want to ensure the router performing NAT64 is >>> advertising the prefix it is using for NAT64 into your IGP or that your >>> default routed traffic lands on that NAT64 to ensure it is routed correctly. >>> >>> >>> This should get you a functional IPv6 only customer network that only >>> returns AAAA records for all DNS requests. It's a little late so I >>> apologize for any mistakes in the addressing. Also I will think about doing >>> this with routing at the CPE as well overnight and add that response. I'd >>> be very intrigued to see this in a lab environment with the fictional >>> customers all setup to see how NAT64 and DNS64 actually works in reality >>> instead of just implementing CGN which I see as the less visible or >>> resilient change for the customer. That said I see the pure IPv6 deployment >>> with NAT64 and DNS64 as the better long term solution if you could reliably >>> ensure your customers use your DHCP server or ensure that your tech support >>> says to reset that right away. It also would break a customer using OpenDNS >>> to restrict web-sites from their kid's for example. >>> >>> >>> >>> Thanks, >>> >>> >>> >>> Tim >>> >>> >>> >>> On Tue, Oct 25, 2016 at 4:42 PM, Art Stephens <[email protected]> >>> wrote: >>> >>> Tim, >>> >>> So we are an IPV4 ISP not able to get any more IPV4 address space. We >>> have IPV6 working in office, and on server network. >>> >>> I have working windows and linux IPV6 only configured machines but >>> obviously they can only access IPV6 capable web sites and such. >>> >>> >>> >>> But we will need to start assigning IPV6 WAN address to customer routers >>> and UBNT radios in radio router mode when we get a CRM that supports IPV6. >>> >>> I am a little aware of NAT64 but all my googling for NAT64 applications >>> yields NAT64 for networks with Public address on one side and private >>> addresses on the other. >>> >>> We try to keep all of our network WAN on public addresses. >>> >>> >>> >>> So far I have tried three so called ipv6 ready routers and could get >>> none of them to work with static IPV6 addressing. >>> >>> >>> >>> Hope that explains what you are looking for. >>> >>> >>> >>> Thanks for your help. >>> >>> >>> >>> >>> >>> On Tue, Oct 25, 2016 at 12:52 PM, Tim Way <[email protected]> wrote: >>> >>> Dual stack is a different architecture than having two separate networks >>> running with one running IPv4 and one running IPv6. To connect the two >>> disparate networks you would need to perform address family translation >>> (NAT64). In dual-stack it will prefer IPv6 when available, minus happy >>> eyeballs, but otherwise has legs or transit via both protocols to access >>> the necessary resource if it is either IPv4 or IPv6. >>> >>> To start I would ask to clarify what you are trying to do and I'd be >>> happy to help in anyway I can. I'm a bit of an IPv6 crazy. >>> >>> >>> >>> Tim >>> >>> >>> >>> On Tue, Oct 25, 2016 at 2:41 PM, Art Stephens <[email protected]> >>> wrote: >>> >>> Any out there successfully deployed dual stack network can share what >>> equipment used for pure ipv6 access to ipv4 networks? >>> >>> -- >>> >>> Arthur Stephens >>> >>> Senior Networking Technician >>> >>> Ptera Inc. >>> PO Box 135 >>> 24001 E Mission Suite 50 >>> Liberty Lake, WA 99019 >>> 509-927-7837 >>> >>> ptera.com | >>> >>> facebook.com/PteraInc | twitter.com/Ptera >>> >>> ----------------------------------------------------------------------------- >>> >>> "This message may contain confidential and/or propriety information, and >>> is intended for the person/entity to whom it was originally addressed. >>> Any use by others is strictly prohibited. Please note that any views or >>> opinions presented in this email are solely those of the author and are not >>> intended to represent those of the company." >>> >>> >>> _______________________________________________ >>> Wireless mailing list >>> [email protected] >>> http://lists.wispa.org/mailman/listinfo/wireless >>> >>> >>> >>> >>> _______________________________________________ >>> Wireless mailing list >>> [email protected] >>> http://lists.wispa.org/mailman/listinfo/wireless >>> >>> >>> >>> >>> -- >>> >>> Arthur Stephens >>> >>> Senior Networking Technician >>> >>> Ptera Inc. >>> PO Box 135 >>> 24001 E Mission Suite 50 >>> Liberty Lake, WA 99019 >>> 509-927-7837 >>> >>> ptera.com | >>> >>> facebook.com/PteraInc | twitter.com/Ptera >>> >>> ----------------------------------------------------------------------------- >>> >>> "This message may contain confidential and/or propriety information, and >>> is intended for the person/entity to whom it was originally addressed. >>> >>> ...
