In what quantity, for a /24, a /22, a /20? Huge difference in pricing between 'buying' by the individual /24 or something much larger.
On Tue, Aug 2, 2016 at 6:37 AM, Chuck McCown <[email protected]> wrote: > We have seen it go from $1 to $10 per IP since April. > > *From:* Josh Reynolds <[email protected]> > *Sent:* Monday, August 01, 2016 7:55 PM > *To:* [email protected] > *Subject:* Re: [AFMUG] NAT64 > > > I could also argue here that ipv4 pricing is still continuing to rise, and > will do so for the foreseeable future. Buying it now will result in a > valuable resource as long as you don't wait too long to sell it :) > > On Aug 1, 2016 6: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> >> >>
