How doesn’t it work? As long as IPv6 is *on* NAT444 + dual stack has the same
properties (or better, less PMTUD issues) as turning on 464XLAT in the CPE.
Traffic shifts to IPv6 due to hosts preferring IPv6. You can still disable
sending RA’s in either scenario.
Mark
> On 26 Aug 2020, at 16
It was a way to say.
Because you use IPv4 pools in the CGN. Then when detected by some services such
as PSN, they are black-listed. You use other pools, they become black listed
again, and so on.
This is not the case with NAT64/464XLAT.
So yeah, it works but the cost of purchasing CGN is actua
Good morning everyone,
I have a doubt about RPKI chain of trust. The 5 RIRs hold a self-signed
root certificate for all the resources they have in the registry. The root
certificate is used to sign the LIR's certificates that lists LIR's
resources. LIRs use their private key to sign ROAs. LIR's pub
Perhaps this clarifies things:
https://rpki.readthedocs.io/en/latest/rpki/introduction.html#mapping-the-resource-allocation-hierarchy-into-the-rpki
As well as this section:
https://rpki.readthedocs.io/en/latest/rpki/securing-bgp.html
Cheers,
Alex
> On 26 Aug 2020, at 10:25, Fabiano D'Agostino
Brandon Martin writes:
> On 8/25/20 3:38 PM, JORDI PALET MARTINEZ via NANOG wrote:
>> This is very common in many countries and not related to IPv6, but
>> because many operators have special configs or features in the CPEs
>> they provide.
>
> I really, really hate to force users to use my networ
What problem are you trying to solve?
Bjørn
Hi Alex,
thank you. I read that documentation and I was reading this one from page
201:
https://www.ripe.net/support/training/material/bgp-operations-and-security-training-course/BGP-Slides-Single.pdf
It seems that RIRs have a self-signed root certificate. They use this
certificate to sign LIR's
Hi Fabiano,
> On 26 Aug 2020, at 11:03, Fabiano D'Agostino
> wrote:
>
> Hi Alex,
> thank you. I read that documentation and I was reading this one from page 201:
> https://www.ripe.net/support/training/material/bgp-operations-and-security-training-course/BGP-Slides-Single.pdf
>
>
> It seems
On 26/Aug/20 10:49, Bjørn Mork wrote:
> You aren't forcing anything if you allow the users to use any CPE and
> document the features it must/should have.
>
> You want IPv4 access without DNS? Then you need CLAT
> You don't know what CLAT is? Call your CPE vendor for support
> You don't car
To be clear, UDP port 0 is not and probably shouldn't be blocked
because some network gear and reporting tools may mistake a fragmented
UDP PDU for port 0. That's an implementation error, but one that may
be common enough to create issues for users. Blocking inbound TCP
port 0 is something that I
K. Scott Helms wrote on 26/08/2020 13:55:
To be clear, UDP port 0 is not and probably shouldn't be blocked
because some network gear and reporting tools may mistake a fragmented
UDP PDU for port 0. That's an implementation error, but one that may
be common enough to create issues for users.
do
Over sub at around 20-40 to 1 is very easy now. With PBA, DET-NAT and other
tools, the average customer largely doesn’t know it is happening and it solves
for many provider side issues as well (logging being the biggest). For those
customers who have issues, the over-sub ratios leave IPv4 space
I’ve not experienced this with PSN and NAT444. I have a LOT of customers doing
it without issue. Maybee it’s that the customer has native IPv6 and solves for
the problem that way, but then this just becomes make sure IPv6 is provided and
it solves for the corner case.
> On Aug 26, 2020, at 2:13
On 26/Aug/20 16:38, Brian Johnson wrote:
> Over sub at around 20-40 to 1 is very easy now. With PBA, DET-NAT and other
> tools, the average customer largely doesn’t know it is happening and it
> solves for many provider side issues as well (logging being the biggest). For
> those customers w
On 8/26/20 4:49 AM, Bjørn Mork wrote:
You aren't forcing anything if you allow the users to use any CPE and
document the features it must/should have.
You want IPv4 access without DNS? Then you need CLAT
You don't know what CLAT is? Call your CPE vendor for support
You don't care what CLA
On 8/26/20 2:48 AM, JORDI PALET MARTINEZ via NANOG wrote:
This is why we wrote RFC8585, so users can freely buy their own router ...
It's a great RFC. Hopefully it continues to gain traction.
Do you know of a single router available in the US (or even broader
North American) retail market th
The crazy thing is that PSN doesn't (up to my knowledge) yet work with IPv6 ...
but I understand that when several players are behind the same CGN, games don't
work as expected (may be not all them). So, Sony decided long time ago to ban
forever, any CGN IPv4 pools that they detect on that situa
I work and I'm in touch with many CPE vendors since long time ago ... many are
on the way (I can remember about 12 on top of my head right now, but because
contracts, can't name them). It takes time. However, in many cases, they just
do for specific customers or specific models. I know other peo
On 26/Aug/20 18:42, JORDI PALET MARTINEZ via NANOG wrote:
> The crazy thing is that PSN doesn't (up to my knowledge) yet work with IPv6
> ...
To this day, my PS4, running Sony's latest code, does not support IPv6.
That might be a good place to start, for them.
At the rate they are doing, th
This sounds like a Sony problem more than a network problem. They need to get
on the IPv6 train and play nice with the Internet. X-BOX has had IPv6 support
since X-BOX One.
> On Aug 26, 2020, at 1:09 PM, Mark Tinka wrote:
>
>
>
> On 26/Aug/20 18:42, JORDI PALET MARTINEZ via NANOG wrote:
>
>
On 26/Aug/20 20:14, Brian Johnson wrote:
> This sounds like a Sony problem more than a network problem. They need to get
> on the IPv6 train and play nice with the Internet. X-BOX has had IPv6 support
> since X-BOX One.
IIRC, someone here said the issue wasn't so much PS4 (which runs
FreeBSD
On 26/Aug/20 18:48, JORDI PALET MARTINEZ via NANOG wrote:
> I work and I'm in touch with many CPE vendors since long time ago ... many
> are on the way (I can remember about 12 on top of my head right now, but
> because contracts, can't name them). It takes time. However, in many cases,
> th
Either way. Nothing you can do in the network will help Sony enable IPv6
capability, Or to serve their users even if using a technology that they do not
like.
> On Aug 26, 2020, at 1:17 PM, Mark Tinka wrote:
>
>
>
> On 26/Aug/20 20:14, Brian Johnson wrote:
>
>> This sounds like a Sony prob
On 26/Aug/20 20:20, Brian Johnson wrote:
> Either way. Nothing you can do in the network will help Sony enable IPv6
> capability, Or to serve their users even if using a technology that they do
> not like.
Agreed.
The problem is gaming customers that neither care for nor know about how
NAT4
I‘m going further... They shouldn’t have to care. Sony should understand what
they are delivering and the circumstance of that. That they refuse to serve
some customers due to the technology they use is either a business decision or
a faulty design. The end-customer (gamer) doesn’t care. They ju
On 26/Aug/20 20:38, Brian Johnson wrote:
> I‘m going further... They shouldn’t have to care. Sony should understand what
> they are delivering and the circumstance of that. That they refuse to serve
> some customers due to the technology they use is either a business decision
> or a faulty d
And in the end it will come down to a clueful customer taking Sony to task.
with the backing of a government for selling a product which is not fit for
purpose. They have paid to play games and if Sony is blocking them because
they happen to be on a CGN, which they have no control over, then So
I can prove, as an ISP, that I am delivering the packets. Many providers will
have to do this until the content moves to IPv6, so what will their excuse be?
The provider has no choice when they have more customers than IPv4 address
space. They will have to do something to provide access to the I
This is nothing new, when I first started installing CGN platforms something
like 10 years ago there was only ever one company that caused issues, can you
guess which? It got to the point of lawyers exchanging desist letters as PSN
constantly told our customers that they were blocking to contac
On 26/Aug/20 21:14, Brian Johnson wrote:
> I can prove, as an ISP, that I am delivering the packets. Many providers will
> have to do this until the content moves to IPv6, so what will their excuse
> be? The provider has no choice when they have more customers than IPv4
> address space. They
Mark: We are completely in agreement. Great dialog here.
> On Aug 26, 2020, at 2:30 PM, Mark Tinka wrote:
>
>
>
> On 26/Aug/20 21:14, Brian Johnson wrote:
>
>> I can prove, as an ISP, that I am delivering the packets. Many providers
>> will have to do this until the content moves to IPv6, so
On 8/26/20 9:28 AM, Tony Wicks wrote:
They're the worst service company I have ever had the displeasure of dealing
with, the arrogance and attitude of we are big, you are small we don't care
about your customers was infuriating. Never have I seen a single call related
to their opposition wh
I have/do. Do you have a point?
> On Aug 26, 2020, at 3:06 PM, surfer wrote:
>
>
>
> On 8/26/20 9:28 AM, Tony Wicks wrote:
>> They're the worst service company I have ever had the displeasure of dealing
>> with, the arrogance and attitude of we are big, you are small we don't care
>> about y
I believe Sony missed:
1) Telling the developers to make sure that they program with IPv6 in mind
(MS/XBOX did for years).
2) Fully supporting IPv6 in the PSN and the PlayStation OS (MS/XBOS did).
3) Setting a deadline for developers to start using it (MS/XBOX did, Apple -
different business I kn
They know we are there ... so they don't come!
By the way I missed this in the previous email: I heard (not sure how much true
on that) that they are "forced" to avoid CGN because the way games are often
programmed in PSP break them. So maybe will not be enough to sort out the
problem with an O
How does 464XLAT solve the problem if you are out of IPv4 space?
> On Aug 26, 2020, at 3:23 PM, JORDI PALET MARTINEZ via NANOG
> wrote:
>
> They know we are there ... so they don't come!
>
> By the way I missed this in the previous email: I heard (not sure how much
> true on that) that they a
Because:
1) It needs *much less* IPv4 addresses (in the NAT64) for the same number of
customers.
2) It provides the customers as many ports they need (no a limited number of
ports per customer).
3) It is not blocked by PSN (don't know why because don't know how the games
have problems with CGN)
On 8/26/20 9:28 AM, Tony Wicks wrote:
They're the worst service company I have ever had the displeasure of dealing
with, the arrogance and attitude of we are big, you are small we don't care
about your customers was infuriating. Never have I seen a single call related
to their opposition where
Nick,
Data on blocking inbound TCP or the kinds of gear that mistakenly
labels UDP fragments as DST port 0?
Scott Helms
On Wed, Aug 26, 2020 at 9:00 AM Nick Hilliard wrote:
>
> K. Scott Helms wrote on 26/08/2020 13:55:
> > To be clear, UDP port 0 is not and probably shouldn't be blocked
> > be
On Wed, 26 Aug 2020 18:42:14 +0200, JORDI PALET MARTINEZ via NANOG said:
> The crazy thing is that PSN doesn't (up to my knowledge) yet work with IPv6 .
Has anybody heard if they plan to fix that with the imminent Playstation 5? The
PS4 OS will actually talk IPV6 far enough to DHCPv6 and answer pi
Responses in-line
> On Aug 26, 2020, at 4:07 PM, JORDI PALET MARTINEZ via NANOG
> wrote:
>
> Because:
>
> 1) It needs *much less* IPv4 addresses (in the NAT64) for the same number of
> customers.
I cannot see how this is even possible. If I use private space internally to
the CGN, then the
I do not work at either NANOG or Sony. How would my response imply that? Again,
what is your point?
I have attended a lot of NANOG meetings and CGM/IPv6 transition was a point of
discussion many times, but as usual it was always in the ether. Few actually
deployed examples and always worried ab
On 26/Aug/20 22:12, JORDI PALET MARTINEZ wrote:
> And the PS developers missed by themselves all about IPv6. Furthermore, I
> still see some game makers *encouraging customers* to disable IPv6. I call
> this a *criminal action*.
Most developers do not understand the constraints the industry
Brian Johnson writes:
>> 1) It needs *much less* IPv4 addresses (in the NAT64) for the same number of
>> customers.
>
> I cannot see how this is even possible. If I use private space
> internally to the CGN, then the available external space is the same
> and the internal customers are the same
On 26/Aug/20 22:23, JORDI PALET MARTINEZ via NANOG wrote:
> Maybe the only way to force this is to tell our customers (many ISPs in every
> country) "don't buy Sony PS, they are unable to support new technologies, so
> you games will be blocked by Sony". Of course, unless we all decide to use
On 27/Aug/20 07:58, Bjørn Mork wrote:
> Because NAT64 implies DNS64, which avoids NATing any dual stack service.
> This makes a major difference today.
NAT64/DNS64 was the original solution.
464XLAT is the improved approach.
See:
https://tools.ietf.org/id/draft-ietf-v6ops-nat64-deployme
> On 27 Aug 2020, at 15:58, Bjørn Mork wrote:
>
> Brian Johnson writes:
>
>>> 1) It needs *much less* IPv4 addresses (in the NAT64) for the same number
>>> of customers.
>>
>> I cannot see how this is even possible. If I use private space
>> internally to the CGN, then the available extern
This one is the published version:
https://datatracker.ietf.org/doc/rfc8683/
El 27/8/20 8:10, "NANOG en nombre de Mark Tinka"
escribió:
On 27/Aug/20 07:58, Bjørn Mork wrote:
> Because NAT64 implies DNS64, which avoids NATing any dual stack service.
> This makes a major differ
48 matches
Mail list logo
