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: 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

Reply via email to