Definitively, please respond to the survey.
The point here is to be able to tell the ISPs, “hey why are you using /64
instead of /48 (or /56). You know that with /64, your customers can’t have
different subnets in their network, for example an /64 in the SSID for guest,
or different /64 for the
Hi Aaron,
Sorry to heard that. Is the first report I got about this problem (253
responses already and many using Chrome), so may be specific to Chrome+Linux,
not sure if you have been able to try with another browser or OS.
Regards,
Jordi
-Mensaje original-
De: NANOG en nombre de "A
Thanks a lot ¡
Saludos,
Jordi
-Mensaje original-
De: "Aaron C. de Bruyn"
Responder a:
Fecha: domingo, 22 de mayo de 2016, 22:11
Para: Jordi Palet Martinez
CC: John Curran , NANOG
Asunto: Re: IPv6 Residential Deployment Survey
>Did some digging, it's was being
Hi,
The intend is to make the survey simple, so in that case, you have two choices:
1) The same IPv6 services by means of DSL and FTTH (example), then you can use
“other” and indicate that.
2) Different IPv6 services with different access technology, then you better
fill one survey for each tec
This is done so if you are part of a trial can keep answering. Otherwise, no
sense to keep going, I guess …
In other words, if you don’t offer IPv6 you must not answer to the survey …
Saludos,
Jordi
-Mensaje original-
De: NANOG en nombre de Christopher Morrow
Responder a:
Fecha: lu
Exactly, I was arguing exactly the same with some folks this week during the
RIPE meeting.
The same way that certifications are needed to avoid radio interferences, etc.,
and if you don’t pass those certifications, you can’t sell the products in some
countries (or regions in case of EU for exam
It happens too often, unfortunately.
People deploying IPv6 at web sites and other services, don’t check if PMTUD is
broken by filtering, ECMP, load balancers, etc.
This is the case here:
tbit from 2001:df0:4:4000::1:115 to 2605:3100:fffd:100::15
server-mss 1440, result: pmtud-fail
app: http, ur
I think it is not just a matter of testing behind a 1280 MTU, but about making
sure that PMTUD is not broken, so it just works in any circumstances.
Regards,
Jordi
-Mensaje original-
De: NANOG en nombre de Mark Andrews
Responder a:
Fecha: jueves, 17 de noviembre de 2016, 9:26
Para: L
I tested from my home and happy eyeballs is not falling back to IPv4.
So, I tend to suspect that is not ICMPv6 filtering, but something else, such as
wrong load balancer or ECMP configuration.
Regards,
Jordi
-Mensaje original-
De: NANOG en nombre de Carl Byington
Responder a:
Fecha
t follow RIPE LABS site:
https://labs.ripe.net/Members/jordipaletm/results-of-the-ipv6-deployment-survey
Regards,
Jordi
-Mensaje original-
De: NANOG en nombre de JORDI PALET MARTINEZ
Responder a:
Fecha: viernes, 18 de noviembre de 2016, 21:05
Para:
Asunto: Re: pay.gov and IPv6
at 10:51 +0100, JORDI PALET MARTINEZ wrote:
> > For example, you will not get this working if you have a lower MTU
> > than 1.500, which is quite normal, not just for tunnels, but also
> > because the PPP/others encapsulation in many access links:
>
> &g
Just make sure that nothing breaks PTB as it happens if you don’t pay attention
to ECMP.
RFC7690
1&1 in Germany has this issue since at least 18-24 months ago, so all their
customers with IPv6 enabled are *broken* for anyone having a smaller MTU
because tunnels or the ISP technology, etc. They
Hello all,
At the last LACNIC event, I mentioned on a couple of occasions the need for
ISPs in the region, especially small and medium-sized ones, to participate in
the decisions taken in the IETF IPv6 Operations Working Group (v6ops). I’m
sending this here as well, as I believe the situation a
Fully agree, 464XLAT is the way to go.
We have tested this in many IPv6-only access deployments, non-cellular networks
(cellular is well tested by T-Mobile and others, that have got it in production
for years).
We always have the issue of the CPEs support, but this is the same problem if
you w
There are several ISPs doing trials (thousands of users).
RFC6877 (464XLAT), section 4. Network Architecture, indicates clearly “Wireline
Network Architecture can be used in situations where there
are clients behind the CLAT, regardless of the type of access service
-- for example, fiber to
This may be helpful:
https://www.ripe.net/publications/docs/ripe-690/
Regards,
Jordi
-Mensaje original-
De: NANOG en nombre de Mike
Responder a:
Fecha: miércoles, 20 de diciembre de 2017, 19:26
Para:
Asunto: Waste will kill ipv6 too
On 12/17/2017 08:31 PM, Eric Kuhnke wrote:
This may be useful as well, somehow related, as using /64 has a clear advantage:
https://datatracker.ietf.org/doc/draft-palet-v6ops-p2p-from-customer-prefix/
Regards,
Jordi
-Mensaje original-
De: NANOG en nombre de JORDI PALET MARTINEZ
Responder a:
Fecha: miércoles, 20 de diciembre
Nice ;-)
I’ve been doing this for some time already … and have trials with several
customers (tens of thousands of customers).
Note that most of the routers that support LEDE (quite a big list), will work
by default with a standard stable release.
You mention it, but we use something like for
Para:
CC:
Asunto: Re: Implementing 464XLAT at a small WISP
On Thu, Dec 28, 2017 at 1:11 PM, JORDI PALET MARTINEZ
wrote:
> Nice ;-)
>
> I’ve been doing this for some time already … and have trials with several
customers (tens of thousands of customers).
>
reflash that “nice” hardware with LEDE, and
done!
Regards,
Jordi
-Mensaje original-
De: Loganaden Velvindron
Responder a:
Fecha: jueves, 28 de diciembre de 2017, 12:04
Para:
CC:
Asunto: Re: Implementing 464XLAT at a small WISP
On Thu, Dec 28, 2017 at 2:43 PM, JORDI PALET MARTINEZ
Not really.
RFC6164 is meant to make sure routers support /127, but doesn’t mandate or say
that you must use that.
This is another perspective:
https://datatracker.ietf.org/doc/draft-palet-v6ops-p2p-from-customer-prefix/
Regards,
Jordi
-Mensaje original-
De: NANOG en nombre de Octa
This may be useful:
https://www.ripe.net/publications/docs/ripe-690/
Regards,
Jordi
-Mensaje original-
De: NANOG en nombre de Octavio Alvarez
Responder a:
Fecha: jueves, 28 de diciembre de 2017, 19:31
Para: Owen DeLong
CC:
Asunto: Re: Assigning /64 but using /127 (was Re: Waste wil
Totally agree.
In IPv6, polices are in some RIRs and MUST be in all them, balancing
conservation and aggregation, but in case of conflict aggregation is the top
priority.
I can read it at the NRPM:
6.3.8. Conflict of goals
The goals described above will often conflict with each other, or with th
Hi all,
I will like to know, from those deploying IPv6 services to residential
customers, if you are planning to provide static or dynamic IPv6 prefixes.
Just to be clear, I'm for static prefix delegation to residential
customers, however I heard that some ISPs are doing dynamic delegations,
the
-Mensaje original-
De: Jeroen Massar
Organización: Unfix
Responder a:
Fecha: Tue, 26 Jul 2011 17:05:41 +0200
Para: Jordi Palet Martinez
CC: NANOG list
Asunto: Re: dynamic or static IPv6 prefixes to residential customers
>On 2011-07-26 16:58 , JORDI PALET MARTINEZ wrote:
>&g
Hi Cameron,
What about routers ? In some locations, users may have only the choice of
cellular broadband instead of DSL, cable or fiber.
Regards,
Jordi
-Mensaje original-
De: Cameron Byrne
Responder a:
Fecha: Tue, 26 Jul 2011 08:34:36 -0700
Para: Jordi Palet Martinez
CC: NANOG
And they need to do anyway, if they want to keep the contract:
http://www.ipv6tf.org/index.php?page=news/newsroom&id=8494
Regards,
Jordi
-Mensaje original-
De: Jeff Fisher
Responder a:
Fecha: Wed, 28 Mar 2012 11:53:35 -0600
Para:
Asunto: Re: Quad-A records in Network Solutions ?
One more (free) book:
http://www.ipv6tf.org/index.php?page=news/newsroom&id=8281
(available in several languages)
**
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company
This electronic message contains inform
Add value. You must not charge for the addresses at all, they are not
yours, you can't sell them.
In every "smart" business, the future is not anymore selling "goods" but
added value.
If you have a quasi-unlimited number of addresses in every customer, you
can star building up new value added ser
Furlly agree.
Time is very short, but if that help I will volunteer to work on something
(workshop, panel, etc., or even all together). Of course, it will need to be
agreed *immediately*.
Regards,
Jordi
> De: "Steven M. Bellovin" <[EMAIL PROTECTED]>
> Organización: Columbia University
> Resp
I agree, it is *right now* one of the main drivers.
In addition to what I'd mention yesterday about a possible workshop or
panel, I've prepared an extensive document (21 pages at the time being)
about the IPv4 exhaustion and all the temporary/permanent "mitigations",
results they could provide an
NAT-PT is not the only solution for this. In addition to that, even if
deprecated, load balancers (there are quite a few), still support it. In
general, this is only needed if you can't update your Apache, IIS or
whatever web server to dual-stack, which normally should not be a problem at
all !
A
I need to insist on this: I agree that having the content providers
dual-stack is nice to have, of course, and I will applaud it if happens in
Google, Yahoo, Microsoft, etc.. BUT it is NOT an immediate need.
We should not deploy IPv6-only networks at the LANs. We may have IPv6 only
at core infras
Regards,
Jordi
> De: "Chris L. Morrow" <[EMAIL PROTECTED]>
> Responder a: <[EMAIL PROTECTED]>
> Fecha: Sun, 27 May 2007 17:27:40 + (GMT)
> Para: JORDI PALET MARTINEZ <[EMAIL PROTECTED]>
> CC: Nanog
> Asunto: Re: NANOG 40 agenda posted
>
>
&g
nsition is needed and it is a smart
thing.
Regards,
Jordi
De: Manolo Hernandez <[EMAIL PROTECTED]>
Responder a: <[EMAIL PROTECTED]>
Fecha: Sun, 27 May 2007 13:50:14 -0400
Para: "Chris L. Morrow" <[EMAIL PROTECTED]>
CC: JORDI PALET MARTINEZ <[EMAIL PROTECTED]>,
I don't really agree 100%. There is DHCPv6 Prefix Delegation, and it just
works !
Regards,
Jordi
> De: Iljitsch van Beijnum <[EMAIL PROTECTED]>
> Responder a: <[EMAIL PROTECTED]>
> Fecha: Tue, 29 May 2007 10:46:47 +0200
> Para: Donald Stahl <[EMAIL PROTECTED]>
> CC: Jeroen Massar <[EMAIL PROT
This is useless. Users need to use the same name for both IPv4 and IPv6,
they should not notice it.
And if there are issues (my experience is not that one), we need to know
them ASAP. Any transition means some pain, but as sooner as we start, sooner
we can sort it out, if required.
Regards,
Jord
gt;
> CC: Nanog
> Asunto: Re: NANOG 40 agenda posted
>
> Jordi,
>
> On May 29, 2007, at 6:50 AM, JORDI PALET MARTINEZ wrote:
>> This is useless. Users need to use the same name for both IPv4 and
>> IPv6,
>
> Why?
>
> The IETF chose to create a new
nt), so make sure to make it just a starting point.
Regards,
Jordi
> De: JORDI PALET MARTINEZ <[EMAIL PROTECTED]>
> Fecha: Tue, 29 May 2007 18:09:17 +0200
> Para: Nanog
> Conversación: NANOG 40 agenda posted
> Asunto: Re: NANOG 40 agenda posted
>
> What I'm sayin
When I do IPv6 trainings, I always clearly state that it is, in principle,
same secure as IPv4: IPsec is the same.
However, you can *always* turn on IPsec with IPv6, which is not always true
for IPv4 (NATs, no end-to-end, etc.).
Also, port scanning is not "so simple", and while in IPv6 a /24 can
We do have dual stack in all our customer sites, and at the time being
didn't got complains or support calls that may be considered due to the
.
I heard the same from other people. I also heard the opposite some times,
but I haven't been able to debug any of those cases to understand where is
But now PI is there, no more restrictions in the path, so they can use
"traditional" multihoming :-)
Regards,
Jordi
> De: Donald Stahl <[EMAIL PROTECTED]>
> Responder a: <[EMAIL PROTECTED]>
> Fecha: Tue, 29 May 2007 20:53:36 -0400 (EDT)
> Para: JORDI PALET
y 2007 10:12:54 -0400 (EDT)
> Para: JORDI PALET MARTINEZ <[EMAIL PROTECTED]>
> CC: Nanog
> Asunto: Re: IPv6 Deployment (Was: Re: NANOG 40 agenda posted)
>
>
>> But now PI is there, no more restrictions in the path, so they can use
>> "traditional" multih
For core networks I will suggest to use pure dual-stack or MPLS/6PE. In the
worst case, if you can't do that, just use manually configured tunnels. For
the upstream, dual-stack or again manually configured tunnels
(6in4/protocol-41 or GRE).
6to4, in general, is useful for end users with a public
I've been trying to collect the info about services (including ISPs and
transit providers) and products (software and hardware) that "say" they
offer IPv6 (still in the phase of verifying one by one, but almost done !).
Is still not complete, but I think provides a good picture.
http://www.ipv6-t
Hi Nathan,
I can probably talk about our own experience ...
We started running Teredo Server+Relay in the Windows 2003 implementation
around 3-4 years ago (not completely sure right now). Unfortunately, when
the Service Pack (SP1 I think) was released, stopped working.
Until then it was working
rds,
Jordi
> De: Nathan Ward <[EMAIL PROTECTED]>
> Responder a: <[EMAIL PROTECTED]>
> Fecha: Thu, 31 May 2007 11:44:21 +1200
> Para: Nanog
> Asunto: Re: Microsoft and Teredo
>
>
>
> On 31/05/2007, at 10:52 AM, JORDI PALET MARTINEZ wrote:
>
>>
&g
Hi Sean,
Most of the access providers, can't quickly move to dual-stack. It may be a
problem of existing equipment or even L2 technology (as the cable/DOCSIS 2.0
case).
The bigger issue is upgrading the CPEs. Lack of plans in the last years,
didn't helped the low cost vendors to deliver them wit
In windows, you have IPv6 firewall, so even if Teredo traverses the "IPv4
security", there is still something there.
A good description of all this is available at:
http://www.microsoft.com/technet/network/ipv6/teredo.mspx
Regards,
Jordi
> De: Adrian Chadd <[EMAIL PROTECTED]>
> Responder a:
Agree, and indeed one of the issues for the transition is to make sure that
border firewalls and other security stuff get updated.
Regards,
Jordi
> De: Adrian Chadd <[EMAIL PROTECTED]>
> Responder a: <[EMAIL PROTECTED]>
> Fecha: Thu, 31 May 2007 21:12:49 +0800
> Pa
We also organize frequently non-for-profit IPv6 workshops at different
venues, including ARIN meetings and also dedicated workshops for customers
all around the world where there is a demand for it.
Regards,
Jordi
> De: "William F. Maton Sotomayor" <[EMAIL PROTECTED]>
> Responder a: <[EMAIL P
love the idea of the
nanog net doubling as an ipv6 play area for those of us who otherwise don't
have the time to set up and muck with this stuff.
I bet if we allocate Sunday morning or afternoon time to another free ipv6
hands on tutorial folks would participate.
Bill
On 5/31/07, JORDI
If I'm not wrong, you could get some service from MCI and AT&T, tunnels only
from SPRINT. Global Crossing provides service, as I believe Level3 and
Abovenet do.
You may want to do a free search for "ISP" at
http://www.ipv6-to-standard.org
Regards,
Jordi
> De: "Krichbaum, Eric" <[EMAIL PROTEC
Hi all,
I've published a document trying to analyze the IPv4 exhaustion problem and
what is ahead of us, considering among others, changes in policies.
http://www.ipv6tf.org/index.php?page=news/newsroom&id=3004
I guess this could be useful in order to understand possible implications of
modifyi
> Para: <[EMAIL PROTECTED]>
> CC:
> Asunto: Re: The Choice: IPv4 Exhaustion or Transition to IPv6
>
>
> On 27-jun-2007, at 21:08, JORDI PALET MARTINEZ wrote:
>
>> I've published a document trying to analyze the IPv4 exhaustion
>> problem and
In ARIN you have a policy to request IPv6 PI. So what is the problem ?
Regards,
Jordi
> De: Christian Kuhtz <[EMAIL PROTECTED]>
> Responder a: <[EMAIL PROTECTED]>
> Fecha: Fri, 29 Jun 2007 13:37:23 +
> Para: Andy Davidson <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, Donald Stahl
> <[EMAIL PR
Some weeks ago I started to work in documenting how to setup 6to4 and Teredo
relays/servers in several platforms for the afripv6-discuss mailing list.
There are many 6to4 relays already, but it becomes even more important to
have them where the bandwidth is more expensive, because it avoids traff
This is one more reason, some OSs may not support IPv6 DNS transport, so you
need to keep dual stack.
Also, if roots/TLDs do not support yet IPv6, you will need to have at least
a dual stack DNS in your network.
I think in the long term we will be there, using IPv6-only in LANs, but
don't see th
What I recall from the ICANN Lisbon meeting (end of March), after the SSAC
and RSSAC recommendations, is that a plan is being worked out with the root
operators in order to make sure that they have the deployment done and then
the hints file is modified.
I believe this will not take too much time
ete Templin <[EMAIL PROTECTED]>
> Responder a: <[EMAIL PROTECTED]>
> Fecha: Fri, 29 Jun 2007 19:14:30 -0500
> Para: <[EMAIL PROTECTED]>
> CC:
> Asunto: Re: ICANN registrar supporting v6 glue?
>
> JORDI PALET MARTINEZ wrote:
>> My view is that deploying on
I don't see the problem. I've deployed IPv6 in may web servers, and nothing
failed, we had firewall support for IPv6 most of the time, and otherwise we
used iptables6. The DNS thing has been replied already as I can see.
I think we have lots of documents on-line explaining all this, including our
Below, in-line.
Regards,
Jordi
> De: Stephen Wilcox <[EMAIL PROTECTED]>
> Responder a: <[EMAIL PROTECTED]>
> Fecha: Sat, 30 Jun 2007 14:23:37 +0100
> Para: JORDI PALET MARTINEZ <[EMAIL PROTECTED]>
> CC:
> Asunto: Re: IPv6 & DNS
>
>
> On F
FYI
Regards,
Jordi
-- Mensaje reenviado
De: "Ernest Byaruhanga (AfriNIC)" <[EMAIL PROTECTED]>
Organización: AfriNIC - http://www.afrinic.net
Responder a: <[EMAIL PROTECTED]>
Fecha: Thu, 12 Jul 2007 17:24:02 +0400
Para: <[EMAIL PROTECTED]>
CC: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>,
<[EMA
Well said.
One more reason is transition mechanisms.
For example, 6to4, TBs, manual tunnels, those are just a few examples, which
use/provide /48.
We have today many customers using /48, which have already their own
internal addressing plans, or manual subnets configured internally.
Are you goi
And then next you can say ok, so /32 bits is big enough for your home, so
let's change it again, kill autoconfiguration, ask existing IPv6 users to
redo their addressing plans, renumber, etc., and use all the rest of the
bits for routing ?
And so on, of course, where is the limit ? You should prop
s, but for many reasons,
autonconfiguration is good enough, and much more simple.
Regards,
Jordi
> From: Matthew Kaufman
> Reply-To:
> Date: Fri, 23 Jul 2010 07:22:53 -0700
> To: Jordi Palet Martínez
> Cc:
> Subject: Re: Addressing plan exercise for our IPv6 course
>
6in4 is IPv6 encapsulated in IPv4 = protocol 41, typically used in manual
tunnelling configuration and also in tunnel brokers and some other type of
tunnels.
6to4 is an automatic transition mechanism that uses 6in4 to automatically
create IPv6 tunnels using a special IPv6 prefix 2002::/16, appendi
9:27 +0900
Para: Jordi Palet Martinez
CC:
Asunto: Re: Real World NAT64 deployments
>> 6to4 is an automatic transition mechanism
> ^ non-
>
>which allows an end site to have horrible v6 pseudo-connectivity over a
>provider who ha
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
, 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 w
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.
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
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
/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
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
1 - 100 of 169 matches
Mail list logo
