ctivity.
Owen
On Jan 20, 2024, at 07:36, Abraham Y. Chen wrote:
Hi, Owen:
1) " ... IPv4 used to work before NAT made everything horrible. ":
Utilizing 240/4, RAN is a flat space which should support this
kind of rudimentary end-to-end connectivity within each RAN. (ca
No. No matter how you cobble it, IPv4 doesn’t have enough addresses to restore proper end to end connectivity. OwenOn Jan 20, 2024, at 07:36, Abraham Y. Chen wrote:
Hi, Owen:
1) " ... IPv4 used
to work before NAT made everything hor
Hi, Owen:
1) " ... IPv4 used to work before NAT made everything horrible. ":
Utilizing 240/4, RAN is a flat space which should support this kind
of rudimentary end-to-end connectivity within each RAN. (called L2
routing, correct?)
Regards,
Abe (2024-01-20 10:35)
On
, it’s not like dial-up modem operations in the PSTN in that IP is an
inherently connectionless packet switched service while modems were an
inherently circuit switched connection oriented service.
However, it does work like IPv4 used to work before NAT made everything
horrible.
Owen
> On
Hi, Forrest:
1) " if you have IPv6 service and I have IPv6 service, our IPv6 devices
can talk directly to each other without needing any VPN or similar. ":
Thanks. So, is it true that the reason IPv4 could not do so is solely
because it does not have enough static addresses for every subscri
On Mon, Jan 15, 2024, 3:08 PM Abraham Y. Chen wrote:
> 1)Re: Ur. Pt. 1):The initial deployment of EzIP overlay is only
> applying 240/4 to existing (IPv4 based) CG-NAT facility to become the
> overlaying RAN, plus upgrading RG-NATs (Routing / Residential NATs) to
> OpenWrt.
On Mon, Jan 15, 2024, 1:21 PM Abraham Y. Chen wrote:
> If I subscribe to IPv6, can I contact another similar subscriber to
> communicate (voice and data) directly between two homes in private like the
> dial-up modem operations in the PSTN? If so, is it available anywhere right
> now?
>
Yes,
onflict, this probably
>>> is on my low priority to-do list for the time being.
>>> 4) Of course, if you have any alternative to suggest, my ears are
>>> all yours.
>>>
>>> Regards,
>>>
>>> Abe (2024-01-15 18:48)
>>>
>>>
17:14, sro...@ronan-online.com wrote:
>>
>> Please don’t use the term RAN, this acronym already has a very specific
>> definition in the telecom/network space as “Radio Access Network.”
>>
>> Shane
>>
>> On Jan 15, 2024, at 5:12 PM, Abraham Y. Chen
>> w
at 5:12 PM, Abraham Y. Chen
> wrote:
>
>
> Hi, Forrest:
>
> 1)Re: Ur. Pt. 1):The initial deployment of EzIP overlay is only
> applying 240/4 to existing (IPv4 based) CG-NAT facility to become the
> overlaying RAN, plus upgrading RG-NATs (Routing / Residential NAT
Chen
wrote:
Hi, Forrest:
1) Re: Ur. Pt.
1): The initial deployment of EzIP overlay is only
applying 240/4 to existing (IPv4 based) CG-NAT f
RAN, this acronym already has a very
specific definition in the telecom/network space as “Radio Access
Network.”
Shane
On Jan 15, 2024, at 5:12 PM, Abraham Y. Chen wrote:
Hi, Forrest:
1) Re: Ur. Pt. 1): The initial deployment of EzIP overlay is
only applying 240/4 to existing (IPv4 bas
re largely on the same page here.
>
> The transition I see happening next is that the consumer traffic largely
> moves to IPv6 with no CG-NAT. That is, if you're at home or on your phone
> watching video or doing social media or using whatever app is all the rage
> it's go
deployment of EzIP overlay is only applying 240/4 to
existing (IPv4 based) CG-NAT facility to become the overlaying
RAN, plus upgrading RG-NATs (Routing / Residential NATs) to
OpenWrt. So that none of the on-premises IoTs will sense any
changes. I don't see how an upgra
Hi, Forrest:
1) Re: Ur. Pt. 1): The initial deployment of EzIP overlay is only
applying 240/4 to existing (IPv4 based) CG-NAT facility to become the
overlaying RAN, plus upgrading RG-NATs (Routing / Residential NATs) to
OpenWrt. So that none of the on-premises IoTs will sense any changes
-15 15:20)
Let me start with I think we're largely on the same page here.
The transition I see happening next is that the consumer traffic
largely moves to IPv6 with no CG-NAT. That is, if you're at home or
on your phone watching video or doing social media or using whatever
app
On 2024-01-13 04:03, Brett O'Hara wrote:
They have no interest in trying new things or making new technology
work without a solid financial reason and there is none for them
implementing ipv6.
When I left $DAYJOB-1 almost 2 years ago, they had just finished
increasing fees on IPv4 blocks (la
+1
From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] On
Behalf Of Brett O'Hara
Sent: Saturday, January 13, 2024 1:04 PM
To: Forrest Christian (List Account)
Cc: Chen, Abraham Y. ; NANOG
Subject: Re: One Can't Have It Both Ways Re: Streamline the CG-NAT Re: EzIP
- Original Message -
> From: "William Herrin"
> Respectfully, your MUA is not the only MUA. Others work differently.
>
> GMail, for example, follows the message IDs as you say but assumes
> that if you change the subject line in your reply (more than adding
> "Re:") then you intend to st
- Original Message -
> From: "Abraham Y. Chen"
> Hi, Bryan:
[ ... ]
> 2) From the Wikipedia explanation of RFC5822, I as a ThunderBird
> user, really have nothing to do with the Message-ID that it puts on my
> MSGs nor how does it make use of such to display the threads. And, my
> Su
Bryan:
> Gmail is therefore in violation of the RFC5822. It's quite clear how it
should work per the RFC appendix.
Actually, no it's not. RFC5322 reads: "This specification is not intended
to dictate ... any of the characteristics of user interface programs that
create or read messages".
5822 h
>
> Gmail is therefore in violation of the RFC5822. It's quite clear how it
> should work per the RFC appendix.
>
Well, no. Asterisks added for emphasis.
This specification is intended as a definition of what message
>content format is to be passed between systems. Though some message
>
On Sat, Jan 13, 2024 at 12:58 PM Bryan Fields mailto:br...@bryanfields.net>> wrote:
> On 1/12/24 3:04 PM, Mu wrote:
>> Would it be possible for you to reply in-thread, rather than creating a new
>> thread with a new subject line every time you reply to someone?
>>
>> Trying to follow the conversa
> I am so glad that you decided to come out to be a well-informed referee.
> For more than one year, I have been accused of breaking the eMail etiquette
> established by a standard, yet never identified. It seriously distracted our
> attention from the topic of essence. You now have demons
Hi, Bryan:
1) " ... Gmail is therefore in violation of the RFC5822. ... I
think it's quite unreasonable to expect others to compensate for an MUA
which doesn't implement 25+ year old standards properly. ... ":
I am so glad that you decided to come out to be a well-informed
referee.
On 1/14/24 1:01 AM, William Herrin wrote:
> Respectfully, your MUA is not the only MUA. Others work differently.
Bill, I use multiple MUA's, among them Thunderbird, mutt, kmail and even the
zimbra web interface. All follow and implement RFC5822 as it pertains to
threading.
Note, threading works
On Sat, Jan 13, 2024 at 12:58 PM Bryan Fields wrote:
> On 1/12/24 3:04 PM, Mu wrote:
> > Would it be possible for you to reply in-thread, rather than creating a new
> > thread with a new subject line every time you reply to someone?
> >
> > Trying to follow the conversation becomes very difficult
Things you have to remember. Not everyone uses thunderbird. Not every mail client threads like thunderbird. — Sent from my iPhoneOn Jan 13, 2024, at 17:39, Abraham Y. Chen wrote:
Hi, Bryan:
0) Thank you so much
for coming to the rescue!!!
Hi, Bryan:
0) Thank you so much for coming to the rescue!!!
1) Basically trained as a radio frequency hardware engineer, I am
only capable of using software as tools necessary for my work. For
eMail, I have been using ThunderBird ever since its beginning. With my
own time-stamping Subje
On 1/12/24 3:04 PM, Mu wrote:
Would it be possible for you to reply in-thread, rather than creating a new
thread with a new subject line every time you reply to someone?
Trying to follow the conversation becomes very difficult for no reason.
Threading has nothing to do with subject lines. RF
they terminate their
remote users? How will they do B2B with out inbound NAT? Yes, there are
solutions, but if you don't need to, why? They pay good money, why can't
they have real ipv4? All their internal networks are IPv4 rfc1918. They
are happy with NAT. Their application service
Hi, Christopher:
Thanks for the confirmation.
Regards,
Abe (2024-01-13 11:42)
On 2024-01-12 07:30, Christopher Hawker wrote:
"Source NAT changes the source address in IP header of a packet. It
may also change the source port in the TCP/UDP headers. The typical
usage is to change
On 13/01/2024, 08:40:11, "Giorgio Bonfiglio via NANOG"
wrote:
2) Assume that Google decided that they would no longer support IPv4 for any
of their services at a specific date a couple of years in the future. […] I
really expect something like this to be the next part of the end game for I
Let me start with I think we're largely on the same page here.
The transition I see happening next is that the consumer traffic largely
moves to IPv6 with no CG-NAT. That is, if you're at home or on your phone
watching video or doing social media or using whatever app is all the rage
> 2) Assume that Google decided that they would no longer support IPv4 for any
> of their services at a specific date a couple of years in the future. […] I
> really expect something like this to be the next part of the end game for
> IPv4.
It’s never gonna happen … why would Google, or any ot
ser, Shockwave and flash, and on and on.
I see no reason why IPv4 should be any different.
On Fri, Jan 12, 2024, 3:42 PM Abraham Y. Chen wrote:
> Hi, Forrest:
>
> 0)You put out more than one topic, all at one time. Allow me to
> address each briefly.
>
> 1) "
Hi, Forrest:
0) You put out more than one topic, all at one time. Allow me to
address each briefly.
1) " The existence of that CG-NAT box is a thorn in every provider's
side and every provider that has one wants to make it go away as quickly
as possible. ":
e the predominant
> operation model is CDN supported by CG-NAT, the primary reason to look for a
> publicly routable IPv4 address is to create another CG-NAT cluster. On the
> other hand, if there is a way to expand the capacity of the existing CG-NAT
> cluster, the need for additional
n model is CDN supported by CG-NAT, the primary reason to look
for a publicly routable IPv4 address is to create another CG-NAT
cluster. On the other hand, if there is a way to expand the capacity of
the existing CG-NAT cluster, the need for additional publicly routable
IPv4 address is reduced.
"Source NAT changes the source address in IP header of a packet. It may
also change the source port in the TCP/UDP headers. The typical usage is to
change the a private (rfc1918) address/port into a public address/port for
packets leaving your network."
"Destination NAT changes
Hi, Christopher:
1) " destination/source NAT ":
I am not sure about this terminology. Could you please elaborate?
If you are referring EzIP being a bigger CG-NAT, it is exactly correct.
That is, the first step of EzIP implementation is just to give CG-NAT a
larger netblock to
The problem isn't the quantity of "inside" CG-NAT address space. It's the
existence of CG-NAT at all.
It doesn't matter if the available space is a /12 or a /4, you still need
something to translate it to the public internet. The existence of that
CG-NAT box is a thorn
Not going to lie, EzIP just seems to be some version of destination/source
NAT on steroids.
Regards,
Christopher Hawker
On Fri, 12 Jan 2024 at 14:36, Abraham Y. Chen wrote:
> Hi, Forrest:
>
> 0)Thanks for your in-depth analysis.
>
> 1) However, my apologies for not pres
Hi, Nick:
1) Perhaps it will be easier to visualize the EzIP scheme by
replacing the 100.64/10 netblock with 240/4, so that the CG-NAT is
enhanced, starting from being 64 fold bigger in address capacity.
Regards,
Abe (2024-01-11 22:42)
On 2024-01-11 05:25, Nick Hilliard wrote:
Dave
Hi, Forrest:
0) Thanks for your in-depth analysis.
1) However, my apologies for not presenting the EzIP concept
clearer. That is, one way to look at the EzIP scheme is to substitute
the current 100.64/10 netblock in the CG-NAT with 240/4. Everything
else in the current CG-NAT setup
ngthy debate. Instead, I would like to address below only one
> aspect that you brought up.
>
> 2)"... an operator clearly looking to acquire *publicly routable*
> space without being clear that this suggestion wouldn't meet their needs.
> ":
>
> Since 240/4 has
Abraham,
There is no need to run one giant cluster. Many small clusters with VRFs and
CG-NAT devices to bridge the gap from the VRF to the Internet and keep the
blast radius small, are enough. A CG-NAT ISP should not need to work so hard to
provide a unique enough CG-NAT IP address, as long as
2)"... an operator clearly looking to acquire *publicly routable* space
without being clear that this suggestion wouldn't meet their needs. ":
Since 240/4 has 256M addresses while 100.64/10 has only 4M, a current
CG-NAT cluster can be expanded 64 fold once th
es while 100.64/10 has only 4M, a
current CG-NAT cluster can be expanded 64 fold once the 240/4 is used.
Looking from another angle, an IAP will then be able to expand the
subscriber set 64 fold with still the original one publicly routable
IPv4 address.
3) This 64 fold scaling factor is c
Hi, Bill:
0) Thanks for bringing up the NANOG posting guideline. We now have
something tangible to discuss.
1) Section 6. looks most relevant. So, I copy and paste it below for
our discussion:
A. 6.1.1. "... > relevant excerpt 1 response to excerpt 1 ...
": This seems
ng at line rate in silicon? ": No.
For the first phase of implementing EzIP, the configuration is called
RAN (Regional Area Network). It is essentially a numbering plan
enhancement to CG-NAT. There is no change to the basic IPv4 Header. The
only engineering effort is "disabling t
uot;*/natural resources/*", instead of the current
treatment of being "*/personal properties/*", actually "*/business
property/*". --- This is analogous to how PSTN numbers were handled in
the old days.
3) "... You have not discussed in the document CGNA
use).
You have not discussed in the document CGNAT case that is typically called
NAT444 (double NAT translation).
I assume it is possible, but would be a big question how to coordinate one
240/4 distribution between all subscribers. Because address space between
Carrier and Subscriber are
256M addresses) as the
replacement to that of CG-NAT (100.64/10 netblock with about 4M
addresses). This much bigger (2^6 times) pool enables every customer
premises to get a static IP address from the 240/4 pool to operate in
simple router mode, instead of requesting for a static port number and
:07.473656 IP 13.86.101.172.123 > 192.2XX.XXX.58291: NTPv3,
> Server, length 48
>
> // Public ip obfuscated. I know, it indeed starts with 192.2. It's
> EBOX in Canada.
>
> What we see on the public side, is that a network device did a NAT
> translation of the SRC U
On 6/10/2021 4:04 AM, Fernando Gont wrote:
Hi, Blake,
Thanks a lot for your comments! In-line
On Fri, 2021-06-04 at 11:13 -0500, Blake Hudson wrote:
Current gen Cisco ASA firewalls have logic so that if the connection
from a private host originated from a privileged source port, the
NAT
2.123 > 192.2XX.XXX.58291: NTPv3, Server, length
48
// Public ip obfuscated. I know, it indeed starts with 192.2. It's EBOX in
Canada.
What we see on the public side, is that a network device did a NAT translation
of the SRC UDP port to 58921. My clock synced perfectly.
So your goal is to
y using SRC UDP ports > 1024.
This is indeed the case we're addressing. The NTP spec mandates srt
port=123, even for client-to-server cases.
> In your case, it sounds like you want to achieve NTP server to NTP
> server, but you mention NTP clients behind NAT devices.
Nope. W
SRC UDP port > 1024.
In short, server to server wants SRC and DST UDP 123. The query and the
response will be fully 123 when server to server.
In your case, it sounds like you want to achieve NTP server to NTP server, but
you mention NTP clients behind NAT devices.
Because multiple c
lementations that always use src
> > port=123,
> > dst port=123 might be in trouble if there are multiple NTP clients
> > behind the same NAT device
>
> This problem used to be very common for 500/udp. Ref
> https://datatracker.ietf.org/doc/html/rfc3715#section-2.3
TH
clients
> behind the same NAT device
This problem used to be very common for 500/udp. Ref
https://datatracker.ietf.org/doc/html/rfc3715#section-2.3
Bjørn
NTP clients
behind the same NAT device
Thanks!
Regards,
--
Fernando Gont
Director of Information Security
EdgeUno, Inc.
PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531
Hi, Blake,
Thanks a lot for your comments! In-line
On Fri, 2021-06-04 at 11:13 -0500, Blake Hudson wrote:
> Current gen Cisco ASA firewalls have logic so that if the connection
> from a private host originated from a privileged source port, the
> NAT
> translation to public
reference.
Alvaro
On Fri, Jun 4, 2021 at 10:14 AM Blake Hudson wrote:
> Current gen Cisco ASA firewalls have logic so that if the connection
> from a private host originated from a privileged source port, the NAT
> translation to public IP also uses an unprivileged source port (not
>
Current gen Cisco ASA firewalls have logic so that if the connection
from a private host originated from a privileged source port, the NAT
translation to public IP also uses an unprivileged source port (not
necessarily the same source port though).
I found out that this behavior can cause
ng to achieve?
Jean
-Original Message-
From: NANOG On Behalf Of Fernando
Gont
Sent: June 4, 2021 3:00 AM
To: nanog@nanog.org
Subject: NAT devices not translating privileged ports
Folks,
While discussing port randomization (in the context of
https://www.ietf.org/archive/id/draft-ietf-ntp
Folks,
While discussing port randomization (in the context of
https://www.ietf.org/archive/id/draft-ietf-ntp-port-randomization-06.txt
), it has been raised to us that some NAT devices do not translate the
source port if the source port is a privileged port (<1024).
Any clues/examples of t
Hey Rob, quick question for you.
Are you able to see the connection ID when you are forwarding the frames and
doing NAT?
I thought this is encrypted. Can you confirm?
Thanks
Jean
-Original Message-
From: NANOG On Behalf Of Jean
St-Laurent via NANOG
Sent: June 1, 2021 6:51 AM
To
The first thing that comes to mind is to check the NAT timers.
By default, TCP is 86400 seconds or 24h.
Udp is usually shorter at around 300 seconds or 5 minutes.
This is not a standard, but it seems to be broadly accepted in the industry.
I am not sure, if UDP/443 should be left at 300 or
the 5tuple includes protocol so increased adoption of QUIC alongside
TCP bound services effectively does increase the potential size of the
NAT binding table but if we're really a single-browser model and all
going to QUIC enabled webs, the effective outcome is to burn the port
space in UDP
s over IP. QUIC replaces the TCP sessions that
a web
browser uses but the device is still doing all of the other IP stuff that it
does.
I could imagine that the connection ID might slightly increase the load on a
NAT since a device
might be hopping back and forth between networks, e.g. mobile and
QUIC has Connection IDs independent from IP. This was done to
make it easier to move from one IP network to another while keeping
connections active, as most here will know.
Does the existence of Connection IDs separate from IP mean that
the host/IP contention ratio in CGNAT can be higher? I
I currently have about ~2750 public IP's (11 /24's) for ~53,000 broadband
customers. (ftth, cable modem and dsl)
I cap them at 3,000 ports using PBA, port block allocation.. Blocks of 100
at a time, and 30 blocks per subscriber. (100*30=3000)
I usually see, when a private internal IP is u
Hello NANOG (and friends),
Asking if anyone would care to share their CGNAT and NAT ratios. We're looking
at some best practices and I wanted to see what the community at large has seen
working, and not working.
I am by no means a NAT expert, and usually I see the other end where it'
Controls source route verification
> net.ipv4.conf.default.rp_filter = 0
> # Do not accept source routing
> net.ipv4.conf.default.accept_source_route = 1
>
>
>
> -Original message-
> *From:* Anurag Bhatia
> *Sent:* Wed 06-12-2019 04:45 pm
> *Subject:* Issue
On 6/15/19 2:06 PM, William Herrin wrote:
This is probably enabled on one or both ends:
http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.kernel.rpf.html
Do some distros enable this now?
I thought it was disabled by default.
Disable it.
Or make sure it's using loose (2) filtering.
rp_filter
ols. The point to point
IPs stay reachable (which is over expected links i.e symmetric via both
ends). As long as both ends prefer link1 or link2, it works fine. At first,
I thought it had to do something with NAT but still can't understand how.
Since VPN tunnels have a keep-alive timer (for 1
t;> link1 between home -> server and prefer link 2 between server -> home then
>> connectivity completely breaks between the routed pools. The point to point
>> IPs stay reachable (which is over expected links i.e symmetric via both
>> ends). As long as both ends prefer link1
se IPs are inside the VPN or outside the VPN?
As long as both ends prefer link1 or link2, it works fine.
Okay.
At first, I thought it had to do something with NAT but still can't
understand how. Since VPN tunnels have a keep-alive timer (for 10
seconds), the tunnel is always up.
Is NAT o
te verification
net.ipv4.conf.default.rp_filter = 0
# Do not accept source routing
net.ipv4.conf.default.accept_source_route = 1
-Original message-
From:Anurag Bhatia
Sent:Wed 06-12-2019 04:45 pm
Subject:Issue with point to point VPNs behind NAT and asymmetric traffic
To:NANOG Mailing
expected links i.e symmetric via both
> ends). As long as both ends prefer link1 or link2, it works fine. At first,
> I thought it had to do something with NAT but still can't understand how.
> Since VPN tunnels have a keep-alive timer (for 10 seconds), the tunnel is
> always up. Any
ink 2 between server ->
home then connectivity completely breaks between the routed pools. The
point to point IPs stay reachable (which is over expected links i.e
symmetric via both ends). As long as both ends prefer link1 or link2,
it works fine. At first, I thought it had to do something wi
s. The point to point
IPs stay reachable (which is over expected links i.e symmetric via both
ends). As long as both ends prefer link1 or link2, it works fine. At first,
I thought it had to do something with NAT but still can't understand how.
Since VPN tunnels have a keep-alive timer (for 10 se
So comparing the ARP and ND tables on my Mikrotik home router, I see
that my Apple TV, indeed, does have an IPv6 address assigned to it
(SLAAC), even though the device, itself, does not display any IPv6
information in its network settings.
Then again, Apple never did think an "HDD is Active" blink
On 28/Nov/18 17:23, Nikolay Shopik wrote:
> tvOS will only show IPv6 dns servers in their "Network Settings" tab.
> They just forgot to update interface for some reason, like they did in
> back ios10 iirc to show all network configuration including IPv6.
I'm running tvOS 12.1 (16J602), and the
On 28/11/18 5:25 pm, Mark Tinka wrote:
> Well, my Apple TV interface only has IPv4 bits to show.
>
> Are you saying IPv6 is hidden from the "Network Settings" tab? I haven't
> done an actual wire tap.
tvOS doesn't expose IPv6 addresses but it fully supported just like all
ios based systems since
On 11/28/18 8:25 AM, Mark Tinka wrote:
On 28/Nov/18 13:37, Nikolay Shopik wrote:
Sony Entertainment is know to be slowpoke in this area. PS4
firmware/kernel is SLAC enabled IPv6 but its not exposed to devs and
thus apps doesn't use it at all.
Which is what really surprised me with this 2014
On 28/Nov/18 16:15, Radu-Adrian Feurdean wrote:
> Or there is some braindead wifi in-between that does not allow IPv6 to
> function (or makes it unreliable). Already seens a number of such devices
> from different vendors.
I have mine hooked into Cat-6 to my home switch (which has switching
On 28/Nov/18 15:41, valdis.kletni...@vt.edu wrote:
> Odd. Mine does DHCPv6. It might do SLAC as well, my OpenWRT wouldn't
> notice an unused SLAC address..
On what Sony device? I know they have different OS's for different TV
models, which could have an impact on this...
Mark.
signature.as
On 28/Nov/18 13:37, Nikolay Shopik wrote:
> Sony Entertainment is know to be slowpoke in this area. PS4
> firmware/kernel is SLAC enabled IPv6 but its not exposed to devs and
> thus apps doesn't use it at all.
Which is what really surprised me with this 2014 TV I have, considering
it stopped g
On Wed, Nov 28, 2018, at 12:37, Nikolay Shopik wrote:
> Are you sure about ATV4 netflix app? Support is there and I've seen
> traffic from it when recently did tcpdump from ATV4.
Or there is some braindead wifi in-between that does not allow IPv6 to function
(or makes it unreliable). Already see
On Wed, 28 Nov 2018 14:37:06 +0300, Nikolay Shopik said:
> Sony Entertainment is know to be slowpoke in this area. PS4
> firmware/kernel is SLAC enabled IPv6 but its not exposed to devs and
> thus apps doesn't use it at all.
Odd. Mine does DHCPv6. It might do SLAC as well, my OpenWRT wouldn't
not
Sony Entertainment is know to be slowpoke in this area. PS4
firmware/kernel is SLAC enabled IPv6 but its not exposed to devs and
thus apps doesn't use it at all.
Are you sure about ATV4 netflix app? Support is there and I've seen
traffic from it when recently did tcpdump from ATV4.
On 28/11/18 9:
On 26/Nov/18 06:47, Dave Temkin wrote:
>
> And yes, IPv6 is fully supported by every piece of our infrastructure;
> the issue is TVs and STBs that do not support v6 - but we have finally
> seen the largest device manufacturers commit to supporting it (if they
> don't already on their late model
On Tue, Nov 27, 2018 at 3:48 AM Grant Taylor via NANOG
wrote:
> On 11/25/2018 09:47 PM, Dave Temkin wrote:
> > Putting an OCA with bypass through the CGN with RFC1918 space will
> > actually work just fine. We (Netflix) don't formally support it because
> > of the vast number of non-standard CGN
On 11/25/2018 09:47 PM, Dave Temkin wrote:
Putting an OCA with bypass through the CGN with RFC1918 space will
actually work just fine. We (Netflix) don't formally support it because
of the vast number of non-standard CGN implementations out there, but if
your clients are in RFC1918 space and th
o supporting it (if they don't already
> on their late model sets) so that should change year over year.
>
> -Dave
>
> On Mon, Sep 17, 2018 at 11:52 PM Jared Mauch
> wrote:
>
>>
>>
>> > On Sep 17, 2018, at 6:54 AM, Tom Ammon wrote:
>> >
&g
17, 2018 at 11:52 PM Jared Mauch wrote:
>>
>>
>> > On Sep 17, 2018, at 6:54 AM, Tom Ammon wrote:
>> >
>> > I'm looking to understand the impact of CG-NAT on a set of netflix OCAs,
>> > in an ISP environment. I see in Netflix's FAQ
p 17, 2018 at 11:52 PM Jared Mauch wrote:
>
>
> > On Sep 17, 2018, at 6:54 AM, Tom Ammon wrote:
> >
> > I'm looking to understand the impact of CG-NAT on a set of netflix OCAs,
> in an ISP environment. I see in Netflix's FAQ on the subject that traffic
The problem asking whether this can be done "at line rate" in a specific
switch platform ignores these critical measurements:
- what's the packet rate expected for the nat flows?
- will the control plane add a forwarding plane rule for every new session?
if so, how quickly can that
1 - 100 of 756 matches
Mail list logo
