in my experience, differences in latency between ipv4 and ipv6 are
mostly due to non-congruent peering/transit. sometimes, one or the
other has to actually go farther.
randy
On 27/Aug/15 17:57, Brandon Ross wrote:
>
>
> I strongly advise you to not assume that just because an IPv4 address
> is "public" (which I'm reading as RFC1918) means that it's not NATed.
>
> I learned the hard way that Tmobile, for one, squats on other
> organization's public IP space on thei
On Thu, 27 Aug 2015, Mark Tinka wrote:
If your IPv4 is public, you should not "feel slow". Of course, if your
IPv4 is private, then yes, some NAT44 may happen somewhere along the path.
I strongly advise you to not assume that just because an IPv4 address is
"public" (which I'm reading as RFC1
On Thu, Aug 27, 2015 at 5:59 AM, Bjoern A. Zeeb <
bzeeb-li...@lists.zabbadoz.net> wrote:
>
> > On 26 Aug 2015, at 15:23 , Ca By wrote:
> >
> > On Wed, Aug 26, 2015 at 8:16 AM, wrote:
> >
> >> On Wed, 26 Aug 2015 07:28:08 -0700, Ca By said:
> >>
> >>> Another relevant metric, less than 25% of my
On 27/Aug/15 14:59, Bjoern A. Zeeb wrote:
>
>
> The question I have not seen the answer yet to is “why?”
>
> Is this really because of the network, e.g., separate pipes in some places
> still, with forwarding devices handling a lot less pps?
>
> Is it because of people having done a newer cleane
> On 26 Aug 2015, at 15:23 , Ca By wrote:
>
> On Wed, Aug 26, 2015 at 8:16 AM, wrote:
>
>> On Wed, 26 Aug 2015 07:28:08 -0700, Ca By said:
>>
>>> Another relevant metric, less than 25% of my mobile subscribers traffic
>>> require NAT64 translating. 75+% of bits flows through end-to-end IPv6
On 27/Aug/15 08:34, Tore Anderson wrote:
> Hi Mark,
>
> There's not much difference between 464XLAT and MAP-*/DS-Lite/lw4o6 in
> this respect, the way I see it. In all cases you need four things:
>
> 0) Native IPv6.
> 1) A central component connected to the IPv4 internet and the IPv6.
>access
* Mark Tinka
> On 27/Aug/15 07:16, Mark Andrews wrote:
>
> >
> > Or why you are looking at NAT64 instead of DS-Lite, MAP-E, or MAP-T
> > all of which are better solutions than NAT64. NAT64 + DNS64 which
> > breaks DNSSEC.
>
> Because with NAT64/DNS64/464XLAT, there isn't any "undo work" after
On 27/Aug/15 07:16, Mark Andrews wrote:
>
> Or why you are looking at NAT64 instead of DS-Lite, MAP-E, or MAP-T
> all of which are better solutions than NAT64. NAT64 + DNS64 which
> breaks DNSSEC.
Because with NAT64/DNS64/464XLAT, there isn't any "undo work" after the
dust settles.
There is v
In message <20150827065346.58554...@echo.ms.redpill-linpro.com>, Tore Anderson
writes:
> Hi Mark,
>
> * Mark Tinka
>
> > In our deployment, we do not offer customers private IPv4 addresses. I
> > suppose we can afford to do this because a) we still have lots of
> > public IPv4, b) we are not a
On 27/Aug/15 06:53, Tore Anderson wrote:
> Why wait until then?
I didn't say that we're waiting :-)...
>
> Any particular reason why you cannot already today provide IPv6
> addresses to your [new] customers in parallel with IPv4?
As a standard delivery of service, all our customers (BGP- and
Hi Mark,
* Mark Tinka
> In our deployment, we do not offer customers private IPv4 addresses. I
> suppose we can afford to do this because a) we still have lots of
> public IPv4, b) we are not a mobile carrier. So any of our customers
> with IPv4 will never hit the NAT64 gateway.
>
> When we do
On 27/Aug/15 03:21, Jared Mauch wrote:
>
> Sure...
>
> For DS, I could send IPv6 native and IPv4 via NAT. I suspect this
> actually the most common home setup at this point. It's certainly the
> way mine looks.
>
> I have noticed that IPv4 "feels" slow on my t-mobile usa co
On Wed, Aug 26, 2015 at 04:39:11PM +0200, Mark Tinka wrote:
> On 26/Aug/15 16:32, Jared Mauch wrote:
> > This for me is an important note, because if your site only gives out an A
> > address,
> > it’s going to be slowed by the NAT process. I have noticed the IPv4
> > penalty getting
> > worse w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 26/Aug/15 18:42, valdis.kletni...@vt.edu wrote:
>
> Actually, the point is that if you're a content provider, there's a good
> chance that turning up IPv6 will result in happier eyeballs, which can
> probably be leveraged into a competitive ad
On Wed, 26 Aug 2015 17:59:24 +0200, Mark Tinka said:
> The point is you need a transition tech. solution if you are serious
> about providing a service to your customers. Assuming you don't is
> living in denial.
Actually, the point is that if you're a content provider, there's a good
chance that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 26/Aug/15 17:16, valdis.kletni...@vt.edu wrote:
>
> So I'm guessing that 75% of the traffic flows with better latency than
> the 25% IPvhorse-n-buggy traffic? ;)
Practically, when we've tested NAT64 at reasonable scale, it does not
add any no
On Wed, Aug 26, 2015 at 8:16 AM, wrote:
> On Wed, 26 Aug 2015 07:28:08 -0700, Ca By said:
>
> > Another relevant metric, less than 25% of my mobile subscribers traffic
> > require NAT64 translating. 75+% of bits flows through end-to-end IPv6
> > (thanks Google/Youtube, Facebook, Netflix, Yahoo,
On Wed, 26 Aug 2015 07:28:08 -0700, Ca By said:
> Another relevant metric, less than 25% of my mobile subscribers traffic
> require NAT64 translating. 75+% of bits flows through end-to-end IPv6
> (thanks Google/Youtube, Facebook, Netflix, Yahoo, Linkedin and so on ...).
So I'm guessing that 75%
On 26/Aug/15 16:32, Jared Mauch wrote:
> This for me is an important note, because if your site only gives out an A
> address,
> it’s going to be slowed by the NAT process. I have noticed the IPv4 penalty
> getting
> worse with many locations.
But you only need to hit the NAT64 gateway "if" y
On 26/Aug/15 16:28, Ca By wrote:
>
>
> From largish deployment ...
>
> Another relevant metric, less than 25% of my mobile subscribers
> traffic require NAT64 translating. 75+% of bits flows through
> end-to-end IPv6 (thanks Google/Youtube, Facebook, Netflix, Yahoo,
> Linkedin and so on ...).
> On Aug 26, 2015, at 10:28 AM, Ca By wrote:
>
>
>> From largish deployment ...
>
> Another relevant metric, less than 25% of my mobile subscribers traffic
> require NAT64 translating. 75+% of bits flows through end-to-end IPv6
> (thanks Google/Youtube, Facebook, Netflix, Yahoo, Linkedin and
On Wed, Aug 26, 2015 at 7:19 AM, Mark Tinka wrote:
>
>
> On 26/Aug/15 16:13, Izaac wrote:
>
> > Yes, I'm curious about this too. I'd like a solid list of providers to
> > avoid.
>
> NAT64 is opt-in.
>
> It will mostly be used for customers that can no longer obtain IPv4
> addresses.
>
> Service
On 26/Aug/15 16:13, Izaac wrote:
> Yes, I'm curious about this too. I'd like a solid list of providers to
> avoid.
NAT64 is opt-in.
It will mostly be used for customers that can no longer obtain IPv4
addresses.
Service providers do not like NAT64 anymore than you do, but there needs
to be so
On Thu, Aug 20, 2015 at 07:44:10AM -0600, Jawaid Shell2 wrote:
> Who out there is using production-scale NAT64? What solution are you using?
Yes, I'm curious about this too. I'd like a solid list of providers to
avoid.
--
. ___ ___ . . ___
. \/ |\ |\ \
. _\_ /__ |-\ |-\ \__
://tools.ietf.org/html/rfc6146#section-1
> This document specifies stateful NAT64, a mechanism for IPv4-IPv6
> transition and IPv4-IPv6 coexistence.
Lo and behold! Your 464XLAT «carrier NAT box» (a.k.a. «PLAT») *is* a
NAT64 box. Thus, if you intend to deploy 464XLAT in production, you&#
On 26 August 2015 at 00:55, Mark Tinka wrote:
>
> On 20/Aug/15 15:44, Jawaid Shell2 wrote:
>
>> Who out there is using production-scale NAT64? What solution are you
>> using?
>
> NAT64/DNS64 on Cisco ASR1006's distributed across the network.
We're doing NAT6
On 20/Aug/15 15:44, Jawaid Shell2 wrote:
> Who out there is using production-scale NAT64? What solution are you
> using?
NAT64/DNS64 on Cisco ASR1006's distributed across the network.
Boxes deployed, traffic minimal as we still have IPv4 addresses as well
(AFRINIC region).
Mark.
On Thu, Aug 20, 2015 at 1:22 PM, Ca By wrote:
> On Thu, Aug 20, 2015 at 9:36 AM, William Herrin wrote:
>> Seriously though, if you want to run a v6-only network and still
>> support access to IPv4 Internet resources, consider 464XLAT or
>> DS-Lite.
>
> NAT64 is a required component of 464XLAT.
S
On Thu, Aug 20, 2015 at 9:36 AM, William Herrin wrote:
> On Thu, Aug 20, 2015 at 9:44 AM, Jawaid Shell2 wrote:
> > Who out there is using production-scale NAT64? What solution are you
> using?
>
> You used "NAT64" and "production" in the same sentence.
On Thu, Aug 20, 2015 at 9:44 AM, Jawaid Shell2 wrote:
> Who out there is using production-scale NAT64? What solution are you using?
You used "NAT64" and "production" in the same sentence. Good one.
Seriously though, if you want to run a v6-only network and still
support
The ALU 7750 MS-ISA card can handle 10Gbps of NAT64 traffic and supports
464XLAT as well.
On Thu, Aug 20, 2015, at 07:44 AM, Jawaid Shell2 wrote:
> Who out there is using production-scale NAT64? What solution are you
> using?
On Thu, 20 Aug 2015 07:44:10 -0600, Jawaid Shell2 said:
> Who out there is using production-scale NAT64? What solution are you using?
OK, I'll bite - what definition of "production-scale" are you using?
Production use for how many digits worth of simultaneous users?
Who out there is using production-scale NAT64? What solution are you using?
Thanks,
Jawaid
34 matches
Mail list logo
