Simon. Let's talk. On Oct 27, 2016 12:50 PM, "Simon Westlake" <simon@sonar.software> wrote:
> I'm not sure, but I think we are probably in a minority, as we're > onboarding a lot of customers right now who came to us explicitly looking > for IPv6 support. > > On 10/27/2016 2:48 PM, Jason Wilson wrote: > > 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 <simon@sonar.software> > 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: dmburg...@linktechs.net >> >> >> >> *From:* Af [mailto:af-boun...@afmug.com <af-boun...@afmug.com>] *On >> Behalf Of *Paul Stewart >> *Sent:* Thursday, October 27, 2016 2:00 PM >> *To:* af@afmug.com >> *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 <ch...@wbmfg.com> 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:* af@afmug.com >> >> *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 <ch...@wbmfg.com> 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 <305%20663%205518> x 232 >> >> Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net >> >> >> ------------------------------ >> >> *From: *"Tim Way" <t...@way.vg> >> *To: *"WISPA General List" <wirel...@wispa.org> >> *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 <asteph...@ptera.com> >> 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 <t...@way.vg> 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 <asteph...@ptera.com> >> 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 >> wirel...@wispa.org >> http://lists.wispa.org/mailman/listinfo/wireless >> >> >> >> >> _______________________________________________ >> Wireless mailing list >> wirel...@wispa.org >> 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. >> 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 >> wirel...@wispa.org >> http://lists.wispa.org/mailman/listinfo/wireless >> >> >> >> >> _______________________________________________ >> Wireless mailing list >> wirel...@wispa.org >> http://lists.wispa.org/mailman/listinfo/wireless >> >> ...
