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