Related to the LEA agencies and CGN:
https://www.europol.europa.eu/media-press/newsroom/news/are-you-sharing-same-ip-address-criminal-law-enforcement-call-for-end-of-carrier-grade-nat-cgn-to-increase-accountability-online
Regards,
Jordi
@jordipalet
El 4/4/22, 16:12, "NANOG en nombre de
imon" escribió:
JORDI PALET MARTINEZ via NANOG wrote:
> No, isn't only a Sony problem, becomes a problem for every ISP that has
customers using Sony PSN and have CGN (NAT444), their IP blocks are
black-listed when they are detected as used CGN. This blocking is "foreve
My guess is that fixing that means fixing tons of games/apps. They are somehow
presuming that every user of the game has a different IP.
Note that we are talking only about PSN because it is probably the most
affected one, but I heard about other services with similar problems and
similar
No, isn't only a Sony problem, becomes a problem for every ISP that has
customers using Sony PSN and have CGN (NAT444), their IP blocks are
black-listed when they are detected as used CGN. This blocking is "forever"
(I'm not aware of anyone that has been able to convince PSN to unblock them).
It is not a fixed one-time cost ... because if your users are gamers behind
PSP, Sony is blocking IPv4 ranges behind CGN. So, you keep rotating your
addresses until all then are blocked, then you need to transfer more IPv4
addresses ...
So under this perspective, in many cases it makes more
I don't think we can say that NAT64 is a disaster. I will say so if we want to
keep IPv4 only hosts in the "6" side, of course it doesn't work. However,
that's why we moved further with 464XLAT. And the demonstration is that most of
the operators are using it.
I think in your picture you're
also depend on
the case of residentials, on the age of SmartTVs, which may not be IPv6 enabled.
El 26/3/22, 18:02, "John Levine" escribió:
It appears that JORDI PALET MARTINEZ via NANOG
said:
>At the end, if you turn on IPv6 to residential customers, typically you
w
The cost of deploying MAP in CPEs is a bit higher than 464XLAT, which is not an
issue anyway. There are several open source implementations for both of them.
It is true that MAP avoids state in the network, however, it means higher
"cost" for users in terms of restrictions of ports. It also
errin" escribió:
On Fri, Mar 11, 2022 at 11:58 PM JORDI PALET MARTINEZ via NANOG
wrote:
> Exactly, many previous unsuccessful discussions at IETF about 240/4: IPv6
is the only viable long-term solution.
>
> The effort to “reinvent” any part of IPv4 or patch
Exactly, many previous unsuccessful discussions at IETF about 240/4: IPv6 is
the only viable long-term solution.
The effort to “reinvent” any part of IPv4 or patches to it, then test that
everything keeps working as expected, versus the benefits and gained time, it
is much best invested in
I meant:
The copper ones also work at 2.5 and 5 Gbit/s, not sure the fiber ones can do.
I think those are restricted to 1, 10 and 25 Gbit/s.
Saludos,
Jordi
@jordipalet
El 31/1/22 19:44, "NANOG en nombre de JORDI PALET MARTINEZ via NANOG"
escribió:
Hi Bill,
I did
Hi Bill,
I did that a few months ago with SFP+. Purchased few with copper (different
vendors), few with fiber (from Solid Optics, they provide a very nice USB
interface to configure them if needed), and used them at different speeds,
depending on the equipment on both sides.
The copper ones
Hi Noah,
Take a look at http://www.6power.org/, lots of info.
I was the main designer of this project and technical manager.
It included a masive deployment pilot with ENDESA (several thousands of
customers), one of the main electricity providers in Spain. Then commercial
service was
Bjørn Mork"
escribió:
JORDI PALET MARTINEZ via NANOG writes:
> All this is resolved using IPv6-only and IPv4aaS, the same way as
> cellular providers are doing with 464XLAT.
Sure, there are a gazillion ways to provde edge access to both IPv4 and
IPv6. You can
they still have dual-stack, problem
solved.
El 6/9/21 15:08, "NANOG en nombre de Bjørn Mork"
escribió:
JORDI PALET MARTINEZ via NANOG writes:
> It is simple, most of your traffic will use IPv6. Depending on your
> network/customer base 65-85%.
>
>
can
keep reducing IPv4 addresses and NAT64 boxes. If you are using boxes that can
be used for other functionalities, you even "recover" part of you initial
investment.
El 6/9/21 10:06, "Saku Ytti" escribió:
On Mon, 6 Sept 2021 at 10:48, JORDI PALET MARTINEZ
All this is resolved using IPv6-only and IPv4aaS, the same way as cellular
providers are doing with 464XLAT.
This means you don't need to invest in more IPv4 addressses (at some point you
can even transfer some of them to the laggers), you still provide IPv4 service
to the edge, but the access
One thing I've been thinking for long time is to consider policy proposals to
enforce the usage of the abuse mailbox together with X-ARF/RFC5965/RFC6650.
That will automate probably a so big % of abuse handling that makes sense even
if you need to make some programming, even if there are
In several RIRs we addressed it via a policy, already implemented for some
years in APNIC (very useful results up to now), and recently implemented in
LACNIC:
AFRINIC
https://www.afrinic.net/policy/proposals/2018-gen-001-d7
APNIC
ng Sony and Playstation to
do IPv6 the right way, without wanting to "seize the occasion" to publicize the
IPv6 transition case and consultancy service?
Please?
Em seg., 5 de abr. de 2021 às 17:02, JORDI PALET MARTINEZ via NANOG
escreveu:
Hi Douglas,
In a different mail
I wish I could do it already! As soon as the client starts the massive
deployment, it should be announced. Covid delayed it at least for 1 year up to
now …
Regards,
Jordi
@jordipalet
El 6/4/21 7:07, "NANOG en nombre de Mark Tinka"
escribió:
On 4/5/21 22:00, J
Hi Douglas,
In a different mailing list, we had a discussion with Tore about his testing
and other testing that may not be available in that blog. It was basically
about 464XLAT.
As you know IPv6-only with IPv4aaS, provides *dual-stack* in the customer LANs,
where the PS5 was sitting.
In addition to that, even if this is not good for many "honest" people that was
using the DC, we need to take it in the positive side. In my own case, OVH is
probably the cause of 80% of the abuse cases I report, and they never react.
I'm convinced I'm not the only one, as I read in other ops
Algs. Preferably BPA - Bulk Port
Allocation.
Em qua., 24 de fev. de 2021 às 04:11, JORDI PALET MARTINEZ via NANOG
escreveu:
I did this "economics" exercise for a customer having 25.000.000 customers
(DSL, GPON and cellular). Even updating/replacing the CPEs, the cost of 464XLAT
d
I did this "economics" exercise for a customer having 25.000.000 customers
(DSL, GPON and cellular). Even updating/replacing the CPEs, the cost of 464XLAT
deployment was cheaper than CGN or anything else.
Also, if you consider the cost of buying more IPv4 addresses instead of
investing that
IPv4 as a Service such as 464XLAT, will allow them to use less IPv4 public
addresses than CGNAT, less costly equipment (or open source) and still provide
dual-stack inside the customers networks.
There is nothing from Internet that will not work. I’ve many deployments based
on this, and
nte redes y servicios que operan en
dicha región.”
El 25/1/21 0:15, "Matthew Petach" escribió:
On Sun, Jan 24, 2021 at 4:22 AM JORDI PALET MARTINEZ via NANOG
wrote:
[...]
So, you end up with 2-3 RIRs allocations, not 5. And the real situation is that
3 out of 5 RIR
, the formal text is the Spanish one.
El 24/1/21 23:13, "Masataka Ohta" escribió:
JORDI PALET MARTINEZ wrote:
>> In the case of LACNIC it is spanish, it is clearly indicated in
>> the web site,
>
> I can't see it clearly indicated in LACNIC web site
not convinced it will reach consensus.
El 24/1/21 15:34, "NANOG en nombre de Masataka Ohta"
escribió:
JORDI PALET MARTINEZ via NANOG wrote:
> I fully understand what you mean, however, I don’t think this is a
> problem even if all the RIRs ask for “%50 or eve
El 24/1/21 15:25, "NANOG en nombre de Masataka Ohta"
escribió:
JORDI PALET MARTINEZ via NANOG wrote:
> To summarize several responses:
You don't.
> In the case of LACNIC it is spanish, it is clearly indicated in the
> web site,
I can't see i
ady mention, note that there is a similar case in AFRINIC policy. They
require that *all* the resources you get, are used in the region.
El 24/1/21 12:30, "Matthew Petach" escribió:
On Sat, Jan 23, 2021 at 1:11 AM JORDI PALET MARTINEZ via NANOG
wrote:
When you si
To summarize several responses:
Every RIR decides which one is their official languages for the policies,
contracts, etc.. In case of discrepancies, the one that is binding is the
official one.
In the case of LACNIC it is spanish, it is clearly indicated in the web site,
and in the policy
ACNIC, 30% in APNIC and 30% in RIPE then the
majority of addresses by region are in the LACNIC region.
--
Mark Andrews
> On 22 Jan 2021, at 23:48, JORDI PALET MARTINEZ via NANOG
wrote:
>
>
>
> El 22/1/21 13:25, "NANOG en nombre de Masataka
El 22/1/21 13:25, "NANOG en nombre de Masataka Ohta"
escribió:
JORDI PALET MARTINEZ via NANOG wrote:
> My proposal added the clarification that "majority" is understood as
"over 50%".
And the proposal is denied to be unreasonable by Toma
to policy making.
Regards,
Jordi
@jordipalet
El 22/1/21 12:51, "NANOG en nombre de Masataka Ohta"
escribió:
JORDI PALET MARTINEZ via NANOG wrote:
> Policies in each RIR are developed by the (global) community. I live
> in Madrid, EU, my RIR is RIPE NCC, RIPE commu
again on the same will not be useful for the NANOG community.
El 22/1/21 12:41, "NANOG en nombre de Masataka Ohta"
escribió:
Sorry to have sent uneditted text.
JORDI PALET MARTINEZ via NANOG wrote:
> First think to clarify: In the Spanish version, the text is (mayoría
the rules that will
actually apply are your original document rules?
El 22/1/21 12:19, "NANOG en nombre de Masataka Ohta"
escribió:
JORDI PALET MARTINEZ via NANOG wrote:
> Not at all.
>
> The "top" mandate of any RIR, in terms or resource allocation, is
Right?
Note also that at any point, the policies can change. If you/anyone really
believes that's broken, a policy proposal can be sent for discussion.
El 22/1/21 12:09, "Töma Gavrichenkov" escribió:
Peace,
On Fri, Jan 22, 2021, 12:27 PM JORDI PALET MARTINEZ via NANOG:
;NANOG en nombre de Masataka Ohta"
escribió:
JORDI PALET MARTINEZ via NANOG wrote:
> No, this is not correct. LACNIC policies, state:
that LACNIC has contradicting statements is a problem
of LACNIC and you can not say others that the statement
of your choice is the
No, this is not correct. LACNIC policies, state:
1.14 Principles for Proper Administration and Stewardship
The fundamental principle is to distribute unique Internet numbering resources
according to the technical and operational needs of the networks currently
using, or that will use, these
ost CPE as a "bridge" to its real network.
El 30/8/20 3:05, "NANOG en nombre de Brandon Martin"
escribió:
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 ca
> 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
onses 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.
>
> W
t a single host behind the NAT can have to
the same destination address and port.
El 27/8/20 6:55, "Brian Johnson" escribió:
Responses in-line
> On Aug 26, 2020, at 4:07 PM, JORDI PALET MARTINEZ via NANOG
wrote:
>
> Because:
>
> 1)
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
: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 are "forced" to avoid CGN because the way games
are oft
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
port 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:
>
>> The crazy thing is that PSN doesn't (up to my knowledge) yet work with
IPv6 ...
>
> To
t;
escribió:
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 br
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:51, JORDI PALET MARTINEZ via NANOG
wrote:
>>
>
g 2020, at 16:51, JORDI PALET MARTINEZ via NANOG
wrote:
>
> 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
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 PALET MARTINEZ via NANOG wrote:
>> This is very common in many countries and not related to IPv6, bu
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, JORD
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.
If you don’t use our own CPE, we can’t warrantee the service neither the
support.
El 25/8/20 21:00, "NANOG en nombre de Mike Hammett"
, "NANOG en nombre de Mark Tinka"
escribió:
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
> 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
OG en nombre de Mark Tinka"
escribió:
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
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
I don't know what you tried in APNIC, my experience is that they are usually
responding very quickly.
Have you tried the abuse contacts of the ISP?
If they fail, have you tried to escalate to escalation-ab...@apnic.net,
following our abuse-mailbox proposal
The comparison between MAP-T and 464XLAT is not just state.
With 464XLAT you can have more subscribers (almost unlimited) per IP address,
without a limitation on the number of ports, so you save a lot of money in
addresses.
And of course, a limited number of ports in MAP-T means troubles for
/7/20 23:25, "NANOG en nombre de Fred Baker"
escribió:
For the record, we are asking similar questions about 464XLAT in v6ops. If you
are deploying it, please advise Jordi Palet Martinez.
For those unfamiliar with them, MAP-T and 464XLAT are each deployment
frameworks for
Hi Douglas,
There was, long time ago, something developed by ISC, but I think never
completed and not updated …
464XLAT is always a solution and becomes much cheaper, than CGN from vendors,
even if you need to replace the CPEs. I’m doing that now with 25.000.000
subscribers … (slowed
y"
From: NANOG on behalf of JORDI PALET MARTINEZ via
NANOG
Sent: Wednesday, May 13, 2020 11:17 PM
To: NANOG list
Subject: Re: RIPE NCC Executive Board election
It is curious how many times we have heard that, not only heard in NANOG and
other NOGs, but also in IETF, even debated in long thr
It is curious how many times we have heard that, not only heard in NANOG and
other NOGs, but also in IETF, even debated in long thread with several IDs, and
for some strange reason, we all missed that or maybe because nobody got the
running code to demonstrate his/her point in a realistic way?
Hi Ronald,
The election starts today, but in order to be able to vote, you need to
pre-register with your organizations before 16:00 Amsterdam time *today*.
Here is the info and registration link:
https://www.ripe.net/participate/meetings/gm/meetings/may-2020/voting-at-the-gm
and the list of
And more and more CPE providers support it.
See RFC8585.
I inititally started using OpenWRT, but now I already got samples from several
vendors.
Regards,
Jordi
@jordipalet
El 30/4/20 6:16, "NANOG en nombre de Ca By" escribió:
On Wed, Apr 29, 2020 at 7:17 PM
I will say it is much better to consider 464XLAT with NAT64, if the CPEs allow
it.
https://datatracker.ietf.org/doc/rfc8683/
I’m right now doing a deployment for 25.000.000 customers of an ISP (GPON, DLS
and cellular mix), all the testing has been done, and all doing fine.
I’ve done
I think the only reason DS-Lite got more implementations is that it was the
first and "only" choice or IPv6-only with IPv4aaS.
Regards,
Jordi
@jordipalet
El 8/8/19 22:57, "NANOG en nombre de Jay Hanke" escribió:
> I can't think of a public presentation off the top of my head that
rt team spending their time.
CPE support is the next big frontier in IPv6 deployment.
Lee
>
> On Fri, Aug 2, 2019 at 10:34 AM JORDI PALET MARTINEZ via NANOG
> wrote:
>> I understand that, but the inconvenient is the fix allocation of ports
per
Hi Lee,
I recall the original sender of this post indicated a small number of users,
that’s why I responded that.
Regards,
Jordi
@jordipalet
El 8/8/19 22:17, "NANOG en nombre de Lee Howard" escribió:
On 8/2/19 1:10 PM, JORDI PALET MARTINEZ via NANOG wrote:
The difference is that 464XLAT/NAT64 is the only one that runs in cellular
networks.
Also with 464XLAT, you don't need DNS64. This document is already in the RFC
Editor Queue:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/
El 6/8/19 1:24, "NANOG en nombre de Mark
This is not surprising to me as Dlink was one of my co-authors for RFC8585 ...
and they indicated in v6ops that implementing CLAT was really easy. I guess
they need to improve the GUI, etc.
Note that with 464XLAT, you still need the NAT64 at the ISP side, and also, the
traceroutes will shows
> The cost of sharing IPs in a static way, is that services such as
> SonyPlaystation Network will put those addresses in the black list,
> so you need to buy more addresses. This hasn’t been the case for
> 464XLAT/NAT64, which shares the addresses dynamically.
A
this gives a cost of USD 1.25 per
user for a fully redundant solution. For us it is even cheaper as we can
recirculate existing address space.
Regards,
Baldur
On Fri, Aug 2, 2019 at 5:32 PM JORDI PALET MARTINEZ
wrote:
I understand that, but the inconvenient is the fix allocation of
of having to run a redundant NAT server
setup with thousands of users. MAP is the only alternative that avoids a
provider run NAT server.
Regards,
Baldur
On Fri, Aug 2, 2019 at 3:38 PM JORDI PALET MARTINEZ via NANOG
wrote:
Ask the vendor to support RFC8585.
Also,
Ask the vendor to support RFC8585.
Also, you can do it with OpenWRT.
I think 464XLAT is a better option and both of them are supported by OpenWRT.
You can also use OpenSource (Jool) for the NAT64.
Regards,
Jordi
@jordipalet
El 2/8/19 14:20, "NANOG en nombre de Baldur
We are getting since several weeks ago, intrusion attempts via SIP (among
others) from:
1) cloudstar.is - They are not responding at all.
2) heficed.com - The people responding is "unable" to resolve it.
In both cases the attacks come from different IP addresses.
So, anyone has a "realiable"
Hi Amos,
Just responded in another mailing list on this:
6to4 is still a valid protocol. IT SHOULD NOT be filtered. 6to4 uses the same
protocol as other tunnels such as 6in4 (protocol 41).
https://www.ietf.org/rfc/rfc3056.txt
It works fine for peer to peer applications.
What
Hi,
El 27/4/19 1:35, "Jared Mauch" escribió:
> On Apr 26, 2019, at 5:49 PM, JORDI PALET MARTINEZ
wrote:
>
> "AP stated that at the LACNIC meeting has discussed it and they dismissed
it as out of scope."
>
> LACNIC will have
RSA (https://www.arin.net/about/corporate/agreements/rsa.pdf) clearly state
that the services are subject to the terms and conditions stated in the policy
manual.
There is explicit text in case of lack of payment. Not so clear what to do if
there is a policy violation, but it looks like at
olicy violation".
El 27/4/19 0:08, "Jon Lewis" escribió:
On Fri, 26 Apr 2019, JORDI PALET MARTINEZ wrote:
> The intent is to clearly state that this is a violation of the policies.
>
> The membership documents/bylaws or the RSA, your account may be close
, etc., etc.
Regards,
Jordi
El 27/4/19 0:03, "NANOG en nombre de JORDI PALET MARTINEZ via NANOG"
escribió:
The intent is to clearly state that this is a violation of the policies.
The membership documents/bylaws or the RSA, your account may be closed. I
looked
The intent is to clearly state that this is a violation of the policies.
The membership documents/bylaws or the RSA, your account may be closed. I
looked at it when adapting the policy from RIPE to ARIN, don't have this
information right in my mind, but I'm sure it was there.
Otherwise, if
Not only that. I really think they have not invested enough time to read the
proposal, check with the authors and then take a decision. We have got some
email exchange, but clearly not sufficient. I also must state that the staff
has been very helpful and diligent to clarify and support the
El 26/4/19 20:25, "NANOG en nombre de Matt Harris" escribió:
On Fri, Apr 26, 2019 at 12:49 PM William Herrin wrote:
I personally support the petition. I think the out of scope reasoning is
flawed. By enforcing minimum assignment sizes, ARIN has long acted as a
gatekeeper to the routing
NANOG en nombre de Max Tulyev
Fecha: domingo, 10 de febrero de 2019, 19:21
Para: NANOG
Asunto: Re: IPv6 and forensic requests
Great, thank you!
Did you manage to whitelist APN at Apple so iOS devices can use it too?
10.02.19 20:06, JORDI PALET MARTINEZ пише:
> Well, if
6to4 to certain public IPv4. But it seems mobile need a /64, and it uses
a lot of random IPv6 inside assigned /64, several addresses together at
each time, CLAT uses the most of it (on Android). So direct translation
6->public4 is impossible.
10.02.19 15:51, JORDI PALET MARTI
Do you really mean 6to4 or NAT64? Totally different things ...
If that's the case, I will suggest you go for Jool instead of Tayga.
Also, if you want the customers are able to use old IPv4 apps and devices,
NAT64 is not sufficient, you need also CLAT at the customer premises (so they
can run
Hi Brandon,
This may help:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/
It is in last call right now, I need to send a new version today/tomorrow, as
the IESG review had some inputs, but nothing that change the document as you
can read it now.
Regards,
Jordi
You may use this document, which passed already the last-call and is in the
AD/IESG review:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/
My co-authors may help you to get those products …
I’ve been using myself OpenWRT for such deployments.
Regards,
Jordi
apps that use literals, or they
don't support IPv6, you still need dual-stack in the LANs, but access IPv6-only
is just fine.
Regards,
Jordi
-Mensaje original-
De: Matt Hoppes
Fecha: miércoles, 26 de septiembre de 2018, 15:22
Para: JORDI PALET MARTINEZ , North American Network
You can use Jool for both 464XLAT and just NAT64.
I've done a workshop on this at the LACNIC meeting this week. See slides 43 and
next ones:
http://www.lacnic.net/innovaportal/file/3139/1/ipv6-only_v11_16-9.pdf
Saludos,
Jordi
-Mensaje original-
De: NANOG en nombre de Matt Hoppes
the LTE interface, but space for it).
Regards,
Jordi
De: Mark Tinka
Fecha: viernes, 22 de junio de 2018, 13:23
Para: JORDI PALET MARTINEZ
CC: "nanog@nanog.org"
Asunto: Re: IPv6 faster/better proof? was Re: Need /24 (arin) asap
On 22/Jun/18 12:47, JORDI PALET MART
The problem with its IPv6 support is that is only supporting 6in4, which by the
way, they call it 6to4, so it is very weird and confusing customers ...
That "6-to-4 actually means 6-in-4" was quite confusing to me as well. I just
enabled it to prove that they had a language moment there. Good
I've many customers using MikroTik.
The problem with its IPv6 support is that is only supporting 6in4, which by the
way, they call it 6to4, so it is very weird and confusing customers ...
So for native IPv6 or a 6in4 tunnel, is fine, but any other transition
mechanism is NOT supported, so
One more open source option:
https://www.gestioip.net/
Regards,
Jordi
-Mensaje original-
De: NANOG en nombre de Job Snijders
Fecha: domingo, 10 de junio de 2018, 23:01
Para: Mike Lyon
CC: NANOG
Asunto: Re: What are people using for IPAM these days?
Hey Mike,
On
r...@invaluement.com>
Fecha: domingo, 27 de mayo de 2018, 0:16
Para: <nanog@nanog.org>
Asunto: Re: Whois vs GDPR, latest news
On 5/26/2018 3:36 PM, JORDI PALET MARTINEZ via NANOG wrote:
> Talking from the experience because the previous laws in Spain, LOPD and
LS
Talking from the experience because the previous laws in Spain, LOPD and LSSI
(which basically was the same across the different EU countries).
They had "maximum" fines (it was 600.000 Euros). They start for small law
infringement with 600 euros, 1.500 euros, unless is something very severe,
.@rollernet.us>
Fecha: sábado, 26 de mayo de 2018, 16:00
Para: <nanog@nanog.org>
Asunto: Re: Whois vs GDPR, latest news
On 5/26/18 1:30 PM, JORDI PALET MARTINEZ via NANOG wrote:
> I don't think, in general the DPAs need to use lawsuits.
>
> If they discover
I don't think, in general the DPAs need to use lawsuits.
If they discover (by their own, or by means of a customer claim) that a company
(never mind is from the EU or outside) is not following the GDPR, they will
just fine it and the corresponding government authorities are the responsible
to
1 - 100 of 142 matches
Mail list logo
