In many situations it will make sense to keep the CPE provided by the ISP in a
configuration equivalent to a "bridge" (I know is not a bridge, I'm trying to
use a single word to describe it), so it runs things like the NAT for IPv4 and
the CLAT for IPv6, even DHCP, or RA, etc. It all depends on
On 8/26/20 12:48 PM, 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, they just do
Another thing worth of consideration is that virtually any box with an OpenWRT
image can support CLAT if it has enough resources.
Owen
> On Aug 24, 2020, at 8:21 AM, JORDI PALET MARTINEZ via NANOG
> wrote:
>
> You probably mean 464XLAT
>
> Ask you vendors. They should support it. Ask f
I must have been tired. I read it as do I go to NANOG meetings. Sorry for the
confusion.
> On Aug 27, 2020, at 12:59 PM, surfer wrote:
>
>
> On Aug 26, 2020, at 4:22 PM, surfer wrote:
> On 8/26/20 9:28 AM, Tony Wicks wrote:
>> They're the worst service company I have ever had the displeas
On Aug 26, 2020, at 4:22 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 your customers was infuriating. Never have I seen a
On 27/Aug/20 15:38, Mike Hammett wrote:
> Another approach (not likely to be any more successful than others
> mentioned) is to get the tech journalists to understand and write
> about the issues. That has the greatest chance of amplifying the
> message, but also given the poor quality of journa
12:59:06 AM
Subject: Re: Ipv6 help
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
On Thu, Aug 27, 2020 at 1:00 AM Brian Johnson
wrote:
> I hope I’m not adding to any confusion. I find this conversation to be
> interesting and want it to be productive. I have not deployed 464XLAT and
> am only aware of android phones having a proper client.
Platforms with CLAT include:
Andro
> So for 464XLAT I will need to install a PLAT capable device(s)...
PLAT support has been around already with the traditional vendors. It's
not new.
[Jordi] NAT64 (PLAT) is there available in excellent open source
implementations. You can use VMs in big rackable servers and it gets e
On 27/Aug/20 10:33, Brian Johnson wrote:
> Let’s say that we switch to a model of all NAT444 for IPv4, with an exception
> for paid static IPv4 customers and that rate is linked to the current going
> rate for an IP address on the market. :)
>
> This is easily doable with any of the access pl
I'm glad we don’t have the logging requirement in the US where I operate. Is it
required in other NANOG locations? Canada? Mexico?
Given that there is always the ability to assign additional port blocks as
needed if a customer exceeds their allotment (requires logging but is still
minimized due
Great Write-up Mark. I have some points in-line...
> On Aug 27, 2020, at 3:12 AM, Mark Tinka wrote:
>
>
>
> On 27/Aug/20 09:33, Brian Johnson wrote:
>
>> If an ISP provides dual-stack to the customer, then the customer only uses
>> IPv4 when required and then will only use NAT444 to compensa
In many jurisdictions you need to log every connection even if all the ports
belong to each customer. In others not. I've seen jurisdictions where you don't
need to log anything and some others, like India, where MAP was discarded by
the regulator, because MAP doesn't provide the 5-tuple log, so
On 27/Aug/20 09:33, Brian Johnson wrote:
> If an ISP provides dual-stack to the customer, then the customer only uses
> IPv4 when required and then will only use NAT444 to compensate for a lack of
> IPv4 address space when an IPv4 connection is required. What am I missing?
While modern OS's
On 27/Aug/20 08:57, JORDI PALET MARTINEZ via NANOG wrote:
> This one is the published version:
>
> https://datatracker.ietf.org/doc/rfc8683/
Good man.
NAT64/DNS64 is broken. I found this out myself in 2011 when I deployed
it at $old_job in Malaysia. Skype broke, as did IPv4 literals.
At the
I hope I’m not adding to any confusion. I find this conversation to be
interesting and want it to be productive. I have not deployed 464XLAT and am
only aware of android phones having a proper client. I have worked with so many
CPE devices and know that most have solid deployments of the require
> On 27 Aug 2020, at 17:33, Brian Johnson wrote:
>
> If an ISP provides dual-stack to the customer, then the customer only uses
> IPv4 when required and then will only use NAT444 to compensate for a lack of
> IPv4 address space when an IPv4 connection is required. What am I missing?
Lots of
Responses in-line...
> On Aug 27, 2020, at 2:22 AM, JORDI PALET MARTINEZ via NANOG
> wrote:
>
> You need to understand the different way NAT64 works vs CGN (and 464XLAT uses
> NAT64 for the translation): The ports are allocated "on demand" in NAT64.
>
> While in CGN you allocate a number of p
If an ISP provides dual-stack to the customer, then the customer only uses IPv4
when required and then will only use NAT444 to compensate for a lack of IPv4
address space when an IPv4 connection is required. What am I missing?
> On Aug 27, 2020, at 1:20 AM, Mark Andrews wrote:
>
>
>
>> On 27
You need to understand the different way NAT64 works vs CGN (and 464XLAT uses
NAT64 for the translation): The ports are allocated "on demand" in NAT64.
While in CGN you allocate a number of ports per customer, for example, 2.000,
4.000, etc.
If a customer is not using all the ports, they are ju
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
> 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
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 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
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: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
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
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
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
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
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)
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
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
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
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
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
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 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
n
Johnson
Sent: Thursday, 27 August 2020 7:14 am
To: Mark Tinka
Cc: nanog@nanog.org
Subject: Re: Ipv6 help
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
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
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
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
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: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
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 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
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
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 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
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
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
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
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 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
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
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
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
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
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
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
No, this doesn't work
The point your're missing (when I talked before about putting all the costs to
make a good calculation of each case and then replacing CPEs become actually
cheaper) is that you need more IPv4 addresses in CGN than in NAT64 and further
to that, in CGN, your IPv4 pools soone
This is why we wrote RFC8585, so users can freely buy their own router ...
The ISP can also list some of the compatible models in case they are using
"additional" features.
El 25/8/20 22:16, "NANOG en nombre de Brandon Martin"
escribió:
On 8/25/20 3:38 PM, JORDI PALET MARTINEZ via NA
On 25/Aug/20 22:40, Brian Johnson wrote:
> I usually solve this problem by designing for NAT444 and dual-stack. This
> solves both problems and allows for users to migrate as they are able/need
> to. If you try and force the change, you will loose users.
At some point, you run out of IPv4.
On 25/Aug/20 22:15, Brandon Martin wrote:
> I really, really hate to force users to use my network edge router (I
> provide the ONT, though, and I provide an edge router that works and
> most users do take it), but it can be tough to ensure users have
> something that supports all the right mod
On 25/Aug/20 21:36, JORDI PALET MARTINEZ via NANOG wrote:
>
>
> A few years ago, I was thinking that the cost of the “replacement” of
> the CPE was too high for most of the operators. Not because the CPE
> itself, but the logistics or actually replacing it.
>
Which makes (or made) the case f
Simplest solution that comes to mind is run a GRE/IPv6 tunnel from one end to
the other with IPv4 addresses on the tunnel endpoints only.
Owen
> On Aug 22, 2020, at 6:47 AM, Brian wrote:
>
> Is there anyway to deploy ipv6 and push ipv4 traffic end to end across the
> ipv6 network. With out
I usually solve this problem by designing for NAT444 and dual-stack. This
solves both problems and allows for users to migrate as they are able/need to.
If you try and force the change, you will loose users.
> On Aug 25, 2020, at 3:15 PM, Brandon Martin wrote:
>
> On 8/25/20 3:38 PM, JORDI PA
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 network edge router (I
provide the ONT,
west-ix.com
From: "Roman Tatarnikov"
To: "Ca By"
Cc: "NANOG"
Sent: Saturday, August 22, 2020 12:55:08 PM
Subject: Re: Ipv6 help
I've been looking into implementing 646XLAT, however I found the problem ends
up with clients' routers.
When you give t
Even comparing Mikrotik (volume) vs low-volume purchases in China, there are
few much cheaper products offering at least the same Mikrotik
functions/performance.
A few years ago, I was thinking that the cost of the “replacement” of the CPE
was too high for most of the operators. Not because
On 8/25/20 12:28 PM, Ca By wrote:
I am aware of other big CPE makers too, but this is the public one
providing product today. Also, anything based on OpenWRT works... which
is increasingly the base vendors build on.
Last I asked SmartRG (Adtran), they were supporting 464XLAT with CLAT,
though
- Original Message -
From: "Roman Tatarnikov"
To: "Ca By"
Cc: "NANOG"
Sent: Saturday, August 22, 2020 12:55:08 PM
Subject: Re: Ipv6 help
I've been looking into implementing 646XLAT, however I found the problem ends
up with clients' routers.
When
On 25/Aug/20 19:36, JORDI PALET MARTINEZ via NANOG wrote:
>
>
>
>
> --- I’ve managed to get better support from vendors which are
> different than Mikrotik. Some years ago, I even offered Mikrotik
> **free** help to correctly do transition … and I’m still waiting for a
> single response. I g
> Many vendors are running on top of OpenWRT or Linux, and both of them have
> CLAT support.
>
> Unfortunately, I can't give names which aren't already published, such as
> Sagemcom, D-Link, NEC and Technicolor. Believe me there are others, you just
> need to ask them.
This shouldn't be t
On 25/Aug/20 18:46, JORDI PALET MARTINEZ via NANOG wrote:
> Many vendors are running on top of OpenWRT or Linux, and both of them have
> CLAT support.
>
> Unfortunately, I can't give names which aren't already published, such as
> Sagemcom, D-Link, NEC and Technicolor. Believe me there are ot
Many vendors are running on top of OpenWRT or Linux, and both of them have CLAT
support.
Unfortunately, I can't give names which aren't already published, such as
Sagemcom, D-Link, NEC and Technicolor. Believe me there are others, you just
need to ask them.
Mikrotik is the worst vendor for any
On 25/Aug/20 18:28, Tom Hill wrote:
> I'd wager that a lot of them already build upon a Linux kernel of some
> flavour. Tore (et al) wrote a CLAT for Linux that builds upon TAYGA's
> NAT64 functionality: https://github.com/toreanderson/clatd
I guess my point was this is out in the wild on mil
On 25/Aug/20 18:28, Ca By wrote:
>
> Askey ships 464xlat boxes for T-Mobile in the USA, so they have the
> products and the knowledge to make it work
>
> https://www.askey.com.tw/index.html
>
> I am aware of other big CPE makers too, but this is the public one
> providing product today. Also, an
On Tue, Aug 25, 2020 at 9:17 AM Mark Tinka wrote:
>
>
>
>
> On 24/Aug/20 17:21, JORDI PALET MARTINEZ via NANOG wrote:
>
>
>
> > You probably mean 464XLAT
>
> >
>
> > Ask you vendors. They should support it. Ask for RFC8585 support, even
> better.
>
> >
>
> > If they don't do, is because they
On 25/08/2020 17:13, Mark Tinka wrote:
> If only CPE's could run Android, or Windows :-).
I'd wager that a lot of them already build upon a Linux kernel of some
flavour. Tore (et al) wrote a CLAT for Linux that builds upon TAYGA's
NAT64 functionality: https://github.com/toreanderson/clatd
--
To
On 24/Aug/20 17:21, JORDI PALET MARTINEZ via NANOG wrote:
> You probably mean 464XLAT
>
> Ask you vendors. They should support it. Ask for RFC8585 support, even better.
>
> If they don't do, is because they are interested only in selling new boxes
> ... just something to think in the futu
You probably mean 464XLAT
Ask you vendors. They should support it. Ask for RFC8585 support, even better.
If they don't do, is because they are interested only in selling new boxes ...
just something to think in the future about those vendors.
I can tell you that many vendors now support or
I've been looking into implementing 646XLAT, however I found the problem ends
up with clients' routers.
When you give them Ethernet cable that has internet on it, whatever it gets
plugged into must support CLAT in order for 646XLAT to work. I was not able to
find any small devices that support
On Sat, Aug 22, 2020 at 6:51 AM Brian wrote:
> Is there anyway to deploy ipv6 and push ipv4 traffic end to end across
> the ipv6 network. With out having an ipv4 address for everything that is
> ipv6? If someone could reach out off list if there is a real solution to
> deploy ipv6 as almost midd
Is there anyway to deploy ipv6 and push ipv4 traffic end to end across the
ipv6 network. With out having an ipv4 address for everything that is ipv6?
If someone could reach out off list if there is a real solution to deploy
ipv6 as almost middleware.
Last month after a service upgrade/reprovisioning I am no longer
getting an IPv6 prefix. Now all I see are RAs and never a response to
DHCPv6 solicit. I have tried different support channels but no luck
getting an answer.
>From what I gathered IPv6 is available in my market and no known
outages. C
86 matches
Mail list logo
