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 >> <http://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 <tel:509-927-7837> >>>>> ptera.com <http://ptera.com/> | >>>>> facebook.com/PteraInc <http://facebook.com/PteraInc> | twitter.com/Ptera >>>>> <http://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 >>>>> <http://lists.wispa.org/mailman/listinfo/wireless> >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Wireless mailing list >>>> [email protected] <> >>>> http://lists.wispa.org/mailman/listinfo/wireless >>>> <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 <tel:509-927-7837> >>> ptera.com <http://ptera.com/> | >>> facebook.com/PteraInc <http://facebook.com/PteraInc> | twitter.com/Ptera >>> <http://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 >>> <http://lists.wispa.org/mailman/listinfo/wireless> >>> >> >> >> >> _______________________________________________ >> Wireless mailing list >> [email protected] >> http://lists.wispa.org/mailman/listinfo/wireless
