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>
