Im getting fed up with "consultants" On Thu, Oct 27, 2016 at 11:22 AM, Cassidy B. Larson <c...@infowest.com> wrote:
> Normally it’s up to and including a /48 that most providers will accept. > > > > On Oct 27, 2016, at 10:20 AM, Chris Wright <ch...@velociter.net> wrote: > > Would be nice. I can’t even get a straight answer from AT&T what the > smallest public ipv6 prefix I can send them via BGP is. I’m hearing /32 > from one guy and /48 from the next. > > This is reminiscent of my moment of enlightenment when I realized the best > kept secret of adulthood is that we’re all just taller children and most of > us are assumptively credited intelligence simply because we survived > puberty. > > Chris Wright > Network Administrator > > *From:* Af [mailto:af-boun...@afmug.com <af-boun...@afmug.com>] *On > Behalf Of *Chuck McCown > *Sent:* Thursday, October 27, 2016 9:00 AM > *To:* af@afmug.com > *Subject:* Re: [AFMUG] Fwd: [WISPA] IPV6 deploymernt > > 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 > > > -- If you only see yourself as part of the team but you don't see your team as part of yourself you have already failed as part of the team.
