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