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
<http://www.linktechs.net/>
Radio Frequiency Coverages: www.towercoverage.com
<http://www.towercoverage.com/>
Office: 314-735-0270 <tel:314-735-0270>
E-Mail: [email protected] <mailto:[email protected]>
*From:*Af [mailto:[email protected]] *On Behalf Of *Paul Stewart
*Sent:* Thursday, October 27, 2016 2:00 PM
*To:* [email protected] <mailto:[email protected]>
*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 <[email protected]
<mailto:[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] <mailto:[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] <mailto:[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 <tel:305%20663%205518> x 232
Help-desk: (305)663-5518 <tel:%28305%29663-5518> Option 2
or Email: [email protected]
<mailto:[email protected]>
------------------------------------------------------------------------
*From: *"Tim Way" <[email protected] <mailto:[email protected]>>
*To: *"WISPA General List" <[email protected]
<mailto:[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] <mailto:[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] <mailto:[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]
<mailto:[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]
<mailto:[email protected]>
http://lists.wispa.org/mailman/listinfo/wireless
<http://lists.wispa.org/mailman/listinfo/wireless>
_______________________________________________
Wireless mailing list
[email protected] <mailto:[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] <mailto:[email protected]>
http://lists.wispa.org/mailman/listinfo/wireless
<http://lists.wispa.org/mailman/listinfo/wireless>
_______________________________________________
Wireless mailing list
[email protected] <mailto:[email protected]>
http://lists.wispa.org/mailman/listinfo/wireless
<http://lists.wispa.org/mailman/listinfo/wireless>
