Then the term you're looking for is probably '4 over 6' or 'lightweight 4 over 6' or maybe 'Dual-Stack Light'.
The question then becomes, what protocols can your CPE do? The 'real dual stack' solution that I described seems the cleanest and easiest right now unless your CPE can handle some sort of tunneling protocol like 4 over 6. -forrest On Mon, Aug 1, 2016 at 5:00 PM, Chuck McCown <[email protected]> wrote: > Yeah this seems so... - 2001 creating a WISP using a single cable modem- > type of doing things. > > I don’t want to use NAT64 to squish a V6 packet on the V4 internet, I want > it to automagically tunnel V4 traffic from the customer to the NAT64 > gateway where it can go on its merry way if there is no V6 destination > address for the other end. Same thing but different words. > > Really, I want to stop having to acquire more V4 addresses. That is truly > the ONLY goal. > > *From:* Forrest Christian (List Account) <[email protected]> > *Sent:* Monday, August 01, 2016 4:54 PM > *To:* af <[email protected]> > *Subject:* Re: [AFMUG] NAT64 > > Let me see if I can help the 'light go on'. > > Forget IPv6 for a second. > > You assign all of your customers addresses from 100.64.0.0/10, then use a > standard, garden variety (but preferably at least somewhat carrier grade) > NAT box to NAT them to the internet. The customers computers talk IPv4, > the NAT box does IPv4 to IPv4 NAT (using addresses you already have) and > everything is happy. This is dirt cheap to do and requires very little > existing infrastructure change. > > You can then add non-NATed IPv6 on top of this so each customer also gets > a new shiny IPv6 address which isn't NAT'ed. > > NAT64 is expensive and can be buggy since you're trying to squish a heavy > IPV6 packet into the IPV4 internet. This avoids this problem. > > > On Mon, Aug 1, 2016 at 4:36 PM, Chuck McCown <[email protected]> wrote: > >> Exactly, this is what we need to solve. No more new V4 addresses and >> only V6 going forward. >> >> -----Original Message----- From: Matt >> Sent: Monday, August 01, 2016 4:29 PM >> To: [email protected] >> Subject: Re: [AFMUG] NAT64 >> >> We can, but at the edge, to talk to a V4 host you need a publically >>> routable >>> V4 address. >>> We will be out of addresses very soon. >>> >> >> With NAT64 you will still need one public routeable IPv4 address just >> the same as if you did dual stack with with NATed IPv4 addresses. >> Unless there is something I do not know here? >> >> No matter how you do it I am very interested how it all turns out and >> hope you keep us all posted. >> >> >> -----Original Message----- From: Matt >>> Sent: Monday, August 01, 2016 3:41 PM >>> To: [email protected] >>> Subject: Re: [AFMUG] NAT64 >>> >>> Why not dual stack them with IPv6 and a NATed IPv4 IP? I thought >>> 100.64.0.0/10 private space was just for that purpose. Seems to be >>> what most cellphones are doing. >>> >>> >>> On Mon, Aug 1, 2016 at 4:34 PM, Chuck McCown <[email protected]> wrote: >>> >>>> >>>> Our V6 only customers need to connect to V4 only destinations. >>>> >>>> From: Sterling Jacobson >>>> Sent: Monday, August 01, 2016 3:33 PM >>>> To: [email protected] >>>> Subject: Re: [AFMUG] NAT64 >>>> >>>> >>>> Why use NAT64 again? >>>> >>>> >>>> >>>> I thought we all just route out IPv6 blocks to customers on DHCPv6, no >>>> NAT >>>> required. >>>> >>>> >>>> >>>> From: Af [mailto:[email protected]] On Behalf Of Chuck McCown >>>> Sent: Monday, August 1, 2016 3:32 PM >>>> To: [email protected] >>>> Subject: [AFMUG] NAT64 >>>> >>>> >>>> >>>> Still searching for a good solution to go IPV6 only with the subs. >>>> Takes >>>> a >>>> pretty expensive piece of hardware at the core router to do NAT64 in a >>>> carrier class manner. If anyone has suggestions I am anxious to learn. >>>> >>> >>> >>> >> > > > -- > *Forrest Christian* *CEO**, PacketFlux Technologies, Inc.* > Tel: 406-449-3345 | Address: 3577 Countryside Road, Helena, MT 59602 > [email protected] | http://www.packetflux.com > <http://www.linkedin.com/in/fwchristian> <http://facebook.com/packetflux> > <http://twitter.com/@packetflux> > > -- *Forrest Christian* *CEO**, PacketFlux Technologies, Inc.* Tel: 406-449-3345 | Address: 3577 Countryside Road, Helena, MT 59602 [email protected] | http://www.packetflux.com <http://www.linkedin.com/in/fwchristian> <http://facebook.com/packetflux> <http://twitter.com/@packetflux>
