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
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 Mon, Aug 03, 2020 at 08:57:53AM -0400, Tom Beecher wrote:
> Telia made a mistake. They owned it and will endeavor to do better. What
> more can be asked?
Figure out how that mistake happened -- what factors led to it? Then make
changes so that it can't happen again, at least not in that
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
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 journalism across the board, I don't suspect it'll 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:
> 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
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
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
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
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,
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
> 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
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
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
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
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
> 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
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:
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
22 matches
Mail list logo
