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 numb
:37, "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 cho
n that region. 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
hat document or 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
again and 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 i
ibuting 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,
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
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
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 man
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
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, but I'm 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
If you want services from LACNIC (as well as any other RIR), you need to sign
the contracts (legal part) and know the policies.
In that case you will reach *that* text in both pages.
Google doesn't necessarily is right when doing translations, specially,
because, as said several times, the form
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
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 this
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 mon
PCP, UPnP, and NAT-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, th
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 ma
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.
ORDI PALET MARTINEZ via NANOG wrote:
Further to that, I’ve done a very complete testing, for a customer, with a PS4
in a LAN with 464XLAT and everything worked fine. Unfortunately, as this was
contracted by a customer, I can’t disclose all the test set, but believe me it
worked. It is a deplo
ry Gamer, demanding 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
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
https://www.apnic.net/community/policy/proposals/prop-125
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 already
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
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 Brand
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 c
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?
ot;
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
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 dow
I’m here ;-)
I’m tracking all possible products and deployments of NAT64/DNS64/464XLAT. I’ve
done a few of them myself for many customers.
The idea is to bring the relevant RFCs to Internet Standards
We could try to do the same also with MAP-T and others. However, my point right
now i
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 cu
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
(https://www.apnic.net/wp-content/upl
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
"NANOG 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
> 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
, "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
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"
e
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
rs 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 rela
26 Aug 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)
ties (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:51, JORDI PALET MARTINEZ via NANOG
wrote:
ndon Martin"
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 i
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
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
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 are "forced" to avoid CGN because the way
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
llel connections that 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:
&g
Johnson" escribió:
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&q
> 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
low cost 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
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
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
e the LANs 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%.
>
G en nombre de 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
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
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 al
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
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 c
iam Herrin" 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 patche
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 mean
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
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 mis
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 sen
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).
T
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 block
El 4/4/22, 14:06, "Joe Maimon" 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.
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
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 sys
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 peti
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 need
, 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
A policy proposal typically is not perfect when submitted.
However, not having the discussion, doesn't allow to improve it and maybe then,
reach consensus.
It may happen that the end of the discussion is, instead of a group of experts,
we need something different, or may be a compensation for t
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 a
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 the first meeting where this topic
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 th
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" c
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 Nor
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, you can
ers. 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, you can do it with OpenWRT.
I think 464XLAT is a better option and both of t
> 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 pr
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 so
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 Andrews"
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:
T
t
that's probably not how you want your support 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, bu
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
However, if an EU citizen or resident uses the services of those companies,
they are bound to comply with the GDPR.
So, if you target your services to people outside the EU, you must have a way
to DENY that anyone in the EU register to your services, or even sent a request
via a form in your we
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 c
yo de 2018, 16:00
Para:
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 (by their own, or by means of a customer claim) that a
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, the
ngo, 27 de mayo de 2018, 0:16
Para:
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
LSSI
Jordi,
LOPD/LSSI does not = GDPR
But even if
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 S
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 w
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’m not really sure “you get what you pay for” … compare with OpenWRT … you
have frequent updates, even in days when some important security flaw is
discovered, as it happened a few months ago with WiFi. You can even develop
yourself what you want or pay folks to do it for you.
And of course
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
This document, which is already in the IESG review, may answer your question:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/
Also take a look into this one:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/
Remember that if your enterprise network has app
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
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
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 46
Well, if it is mobile, then definitively you should use /64 for every PDP
context, and clearly is NAT64.
In this case, you don't need to take care about the CLAT part, just look at the
/64 prefix for the logging.
Make sure to talk about stateful NAT64 ... otherwise you create lot of
confusion.
1 - 100 of 101 matches
Mail list logo
