Re: V6 still not supported

[JORDI PALET MARTINEZ via NANOG]

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 Francis Booth via NANOG" 
 escribió:

I think you’re jumping to conclusions that Sony is doing this purely from 
the darkness in their hearts. The same thing could be said about Netflix and 
Hulu blocking traffic from addresses that appear as proxies/VPNs. Like it or 
not we had many years where the primary expectation of the Internet was that 
you could map a single ISP customer back to an IP address and MANY services 
still cling to this belief.


https://news.slashdot.org/story/21/05/22/0151220/6th-grader-expelled-after-zoom-provided-possibly-inaccurate-ip-address

This is why we have situations like this where even law enforcement 
agencies can’t seem to wrap their heads around multiple customers all sharing 
the same IP address. You have to remember that a majority of people do not see 
all this behind the scenes stuff so as far as they are concerned the Internet 
will continue working as it always has and any deviation in that is a problem 
with the ISP when all of their friends can connect fine except for them.  


> On
> Apr 4, 2022, at 8:00 AM, Jared Brown  wrote:
> 
> A root cause fix would address Sony's hostile behavior.




**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: V6 still not supported

[JORDI PALET MARTINEZ via NANOG]

I don't think this can happen if I'm right and the reason they need to block 
"shared" IPs is because the games/apps just don't work.

If I'm a gamer, and one of my possible ISPs is using CGN, and from time to time 
stops working, and another ISP is providing me a public and/or static IPv4 
address, always working, and there is not too much price difference, what I 
will do?

And of course, as I just said in my previous email, the trend is only supported 
by transitioning to IPv6. Sony has been a lagger on that, instead XBOX had IPv6 
support quite early and developers where properly trained to use it.

(note that I'm not a gamer, neither have any game console at home, actually 
never used one!, so I've no preference or any business relation with any game 
related company ... just commenting what I can see)

 
Regards,
Jordi
@jordipalet
 
 

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. This blocking is "forever" 
(I'm not aware of anyone that has been able to convince PSN to unblock them). 
Then the ISP will rotate the addresses that are in the CGN (which means some 
work renumbering other parts of the network).
>
> You do this with all your IPv4 blocks, and at some point, you don't have 
any "not black-listed" block. Then you need to transfer more addresses.
>
> So realistically, in many cases, for residential ISPs it makes a lot of 
sense to analyze if you have a relevant number of customers using PSN and make 
your numbers about if it makes sense or not to buy CGN vs transfer IPv4 
addresses vs the real long term solution, which is IPv6 even if you need to 
invest in replacing the customer CPEs.
>
>
> Regards,
> Jordi
> @jordipalet
>   

I would expect the trend to become that ISP's refuse to accommodate 3rd 
party vendors shenanigans to the point where it hampers their operations 
or to the point where it cost them more to do so.

Likely, they would sooner tell the customer that their vendor (whom they 
pay money) is blocking the ISP and that there must a) deal with their 
vendor and/or b) pay/use a dedicated static IP

Because as you point out, its impossible to support this trend after a 
certain point, and really, why should you?

With enough of that attitude, the trend reverses and vendors will have 
to start using other mechanisms, perhaps even ones where cooperation 
with the SP is a possibility.

Joe



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: V6 still not supported

[JORDI PALET MARTINEZ via NANOG]

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 blockings.

I'm convinced that it will be cheaper and much easier to port to IPv6 those 
games/apps and at the same time be a long-term solution.
 
Regards,
Jordi
@jordipalet
 
 

El 4/4/22, 14:03, "NANOG en nombre de Jared Brown" 
 escribió:

My apologies for expressing myself poorly.

What I meant to say is that this is primarily a problem caused by Sony and 
the Sonys of the world. Less so a problem inherent to IPv4. A root cause fix 
would address Sony's hostile behavior.


- Jared



Jordi Palet 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 "forever" 
(I'm not aware of anyone that has been able to convince PSN to unblock them). 
Then the ISP will rotate the addresses that are in the CGN (which means some 
work renumbering other parts of the network).

You do this with all your IPv4 blocks, and at some point, you don't have 
any "not black-listed" block. Then you need to transfer more addresses.

So realistically, in many cases, for residential ISPs it makes a lot of 
sense to analyze if you have a relevant number of customers using PSN and make 
your numbers about if it makes sense or not to buy CGN vs transfer IPv4 
addresses vs the real long term solution, which is IPv6 even if you need to 
invest in replacing the customer CPEs.


Regards,
Jordi
@jordipalet



El 30/3/22, 21:02, "NANOG en nombre de Jared Brown" 
 escribió:

Not to necessarily disagree with you, but that is more of a Sony 
problem than an IPv4 problem.


- Jared



Jordi Palet wrote:

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 sense to NOT 
invest in CGN, and use that money to transfer up-front more IPv4 addresses at 
once, you will get a better price than if you transfer them every few months.


Regards,
Jordi
@jordipalet



El 30/3/22, 18:38, "NANOG en nombre de Jared Brown" 
 escribió:

Randy Carpenter wrote:
> >> >> Owen DeLong via NANOG wrote:
> >> >> When your ISP starts charging $X/Month for legacy protocol 
support
> >> >
> >> > Out of interest, how would this come about?
> >>
> >> ISPs are facing ever growing costs to continue providing IPv4 
services.
> >  Could you please be more specific about which costs you are 
referring to?
> >
> >  It's not like IP transit providers care if they deliver IPv4 
or IPv6 bits to
> >  you.
>
> Have you priced blocks of IPv4 addresses lately?
  IPv4 address blocks have a fixed one-time cost, not an ongoing 
$X/month cost.

- Jared




**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: V6 still not supported

[JORDI PALET MARTINEZ via NANOG]

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). 
Then the ISP will rotate the addresses that are in the CGN (which means some 
work renumbering other parts of the network).

You do this with all your IPv4 blocks, and at some point, you don't have any 
"not black-listed" block. Then you need to transfer more addresses.

So realistically, in many cases, for residential ISPs it makes a lot of sense 
to analyze if you have a relevant number of customers using PSN and make your 
numbers about if it makes sense or not to buy CGN vs transfer IPv4 addresses vs 
the real long term solution, which is IPv6 even if you need to invest in 
replacing the customer CPEs.


Regards,
Jordi
@jordipalet
 
 

El 30/3/22, 21:02, "NANOG en nombre de Jared Brown" 
 escribió:

Not to necessarily disagree with you, but that is more of a Sony problem 
than an IPv4 problem.


- Jared



Jordi Palet wrote:

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 sense to NOT invest 
in CGN, and use that money to transfer up-front more IPv4 addresses at once, 
you will get a better price than if you transfer them every few months.


Regards,
Jordi
@jordipalet



El 30/3/22, 18:38, "NANOG en nombre de Jared Brown" 
 escribió:

Randy Carpenter wrote:
> >> >> Owen DeLong via NANOG wrote:
> >> >> When your ISP starts charging $X/Month for legacy protocol 
support
> >> >
> >> > Out of interest, how would this come about?
> >>
> >> ISPs are facing ever growing costs to continue providing IPv4 
services.
> >  Could you please be more specific about which costs you are 
referring to?
> >
> >  It's not like IP transit providers care if they deliver IPv4 or 
IPv6 bits to
> >  you.
>
> Have you priced blocks of IPv4 addresses lately?
  IPv4 address blocks have a fixed one-time cost, not an ongoing 
$X/month cost.

- Jared





**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: V6 still not supported

[JORDI PALET MARTINEZ via NANOG]

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 sense to NOT invest in 
CGN, and use that money to transfer up-front more IPv4 addresses at once, you 
will get a better price than if you transfer them every few months.
 
 
Regards,
Jordi
@jordipalet
 
 

El 30/3/22, 18:38, "NANOG en nombre de Jared Brown" 
 escribió:

Randy Carpenter wrote:
> >> >> Owen DeLong via NANOG wrote:
> >> >> When your ISP starts charging $X/Month for legacy protocol support
> >> >
> >> > Out of interest, how would this come about?
> >>
> >> ISPs are facing ever growing costs to continue providing IPv4 services.
> >  Could you please be more specific about which costs you are referring 
to?
> >
> >  It's not like IP transit providers care if they deliver IPv4 or IPv6 
bits to
> >  you.
>
> Have you priced blocks of IPv4 addresses lately?
  IPv4 address blocks have a fixed one-time cost, not an ongoing $X/month 
cost.

- Jared



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: A straightforward transition plan (was: Re: V6 still not supported)

[JORDI PALET MARTINEZ via NANOG]

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 missing 2 phases:
4) IPv6-only with IPv4aaS (we have 5 technologies, see RFC8585 for a summary of 
what is needed in the CPEs), when there is still a significant amount of IPv4 
traffic in the customer LANs.
5) IPv6-only with IPv4aaS when IPv4 traffic is residual in most of the 
customers LANs. How fast we move to this phase depends on more and more 
devices, and apps using IPv6.

The advantage is:
a) The job is done in the CPE (no need for a more powerful one, etc.), 
customers are not aware of it. Part of the job is done in the operators 
networks, of course, but it is comparable and much cheaper, in terms of OpEx 
and CapEx, to alternatives such as dual-stack or NAT444/CGN.
b) When moving to 5 above, the operators can measure the reduction on the usage 
of the NAT64 (in the case of 464XLAT), and even in the usage of IPv4 public 
addresses, so they can transfer them, so laggers can use them for their own 
transition. On the side of the customers, there is nothing to do. You may 
remove IPv4, but actually is not costing you "anything" to keep it.
 

Regards,
Jordi
@jordipalet
 
 

El 28/3/22, 15:23, "NANOG en nombre de Philip Homburg" 
 escribió:

>If by ?straightforward transition plan? one means a clear and rational set 
of 
>options that allows networks to plan their own migration from IPv4-only to 
IPv
>6, while maintaining connectivity to IPv4-only hosts and with a level of 
effor
>t reasonable comparable to just running IPv4, then I would disagree, as 
such a
>n "IPng transition plan? was achievable, expected, and we collectively 
failed 
>to deliver on it (as noted below) 

I'm a bit confused about the achievable part.

Obviously, the adoption of IPv6 without a clear transition plan was a 
process
failure. However, it is not clear to me that waiting a few years would 
have brought something much better. And waiting more than a decade would
mean that today there would not be a mature IPv6.

Transition to IPv6 so far seems to have consisted of 3 phases:
1) Lots of tunnels due lack of a wide spread IPv6 backbone.
2) Early adopters being happy that they can run IPv6 native, usually as
   dual stack.
3) Lots of people looking into IPv6-only.

I'd say 1) mostly worked. 6to4 was a bit of mess. But otherwise tunnels
worked. Obviously, deploying IPv6 using tunnels is a lot more complex
than deploying native IPv4 without NAT. 
From a technical perspective 2) just works. From an operational perspective
it is about twice as expensive as IPv4-only. So 2) is popular with people
who really want IPv6. 

The big issue is 3). If we look at the current internet, there are parties
who lack IPv4 addresses and want to switch to IPv6. Obviously, they
want to be IPv6-only. The lack of IPv4 address makes dual stack even harder.
On the other hand, there are parties who have enough IPv4 addresses and
have no reason to switch to IPv6.

So we are clearly in the situation of 'migration from IPv4-only to IPv6,
while maintaining connectivity to IPv4-only hosts'

It should be clear that an IPv4-only host only speaks IPv4. This means that
communication with an IPv4-only host has to be IPv4. So either the
IPv6-only host or something in the network has to speak IPv4. If the
IPv6 host speaks IPv4 then we get dual stack, which has been rejected
as a broken solution. Technically, it is also possible to tunnel IPv4
packets, then the host is in some sense dual stack, but most of the network
is not. However, automatic tunnel configuration is hard, and tunnels
tend to be fragile.

So the only option is a device in the network that translates between
IPv6 and IPv4. Currently we have such a protocol, NAT64. And from
a technical point of view it is a disaster.

Looking back, we can say that the only feature of IPv6 that makes people
invest in IPv6 is the bigger address space. So it is safe to say that
most of the internet would have waited to invest in IPv6 until we were
(almost) out of IPv4 addresses. So by its very nature this transation 
between IPv6 and IPv4 would have NAT component.

In my opinion, It is clear that during the time IPv6 was developed, any
solution involving NAT would have been rejected.

So I'm confused, what transition technology was achievable (also in the
political sense) but not delivered?

If there is a magical transition technology that allows an IPv6-only host to
talk to an IPv4-only host, then let's deploy it.



**
IPv4 is over
Are you ready for the new Internet ?

Re: MAP-T (was: Re: V6 still not supported)

[JORDI PALET MARTINEZ via NANOG]

It comes from actual measurements in residential networks that already offer 
IPv6.

In typical residential networks, a very high % of the traffic is 
Google/Youtube, Netflix, Facebook, CDNs, etc., which all are IPv6 enabled.

Typically, is also similar in mobile networks, and this has been confirmed also 
by measurements in v6ops mailing list, for example from T-Mobile. If I recall 
correctly that was 3-4 years ago and was already 75% IPv6 traffic.

Enterprises usually have a lower IPv6 %, so actual numbers in a given ISP my 
depend on the ratio of enterprise/residential customers. It may 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 
will get 70-80% IPv6 traffic, so the state in the NAT64 using 464XLAT is lower 
and lower every day.

Not disagreeing, but where does that number come from?  Anectodally, on my 
home network I see
less than 50%.

R's,
John



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: MAP-T (was: Re: V6 still not supported)

[JORDI PALET MARTINEZ via NANOG]

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 means more IPv4 
addresses even if the ports are not used. In some countries, like India, MAP 
was not alllowed by the regulator, because the lack of proper logging, so it 
was push-back by the bigger provider (probably the bigger in the world - Jio) 
of IPv6.

At the end, if you turn on IPv6 to residential customers, typically you will 
get 70-80% IPv6 traffic, so the state in the NAT64 using 464XLAT is lower and 
lower every day.

With 464XLAT there is no restriction on the number of ports per subscriber, the 
usage of IPv4 addresses is more efficient, and of course, you can use the same 
protocol in cellular networks, with also make simpler the support of backup 
links in CPEs (for example GPON in the primary link and 4G in the backup one).

Last but not least, 464XLAT also allows enterprise networks to swich to 
IPv6-only (with IPv4aaS) providing a smooth transition to a final IPv6-only 
stage.

The fact that in terms of users 464XLAT exceeds all the other transition 
tehcnologies all together, should mean something.

There is a bunch of information at 
https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-comparison/, which 
is just waiting for the final OK from the IESG to jumpt to the final stage (RFC 
Editor).

Regads,
Jordi
 
 
Saludos,
Jordi
@jordipalet
 

-Original Message-
From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] On 
Behalf Of Jared Brown
Sent: Friday, March 25, 2022 4:49 PM
To: nanog@nanog.org
Subject: MAP-T (was: Re: V6 still not supported)

Most IPv6 transition mechanisms involve some form of (CG)NAT. After 
watching a NANOG presentation on MAP-T, I have a question regarding this.

Why isn't MAP-T more prevalent, given that it is (almost) stateless on the 
provider side?

Is it CPE support, the headache of moving state to the CPE, vendor support, 
or something else?


NANOG 2017
Mapping of Address and Port using Translation MAP T: Deployment at Charter 
Communications https://www.youtube.com/watch?v=ZmfYHCpfr_w


- Jared



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Making Use of 240/4 NetBlock

[JORDI PALET MARTINEZ via NANOG]

Because it is a single Internet, and what we do in some parts of Internet will 
affect others?

Because, at least in my case, I'm investing my efforts in what it seems to be 
the best in the long-term for the global community, not my personal preferences?
 
 

El 12/3/22 9:10, "William 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 patches to it, then test 
that everything keeps working as expected, versus the benefits and gained time, 
it is much best invested in continue the IPv6 deployment which is already going 
on in this region and the rest of the world.
>
> It would not make sense, to throw away all the efforts that have been 
already done with IPv6 and we should avoid confusing people.
>
> I just think that even this thread is a waste of time (and will not 
further participate on it), time that can be employed in continue deploying 
IPv6.


Why are so many otherwise smart engineers so vulnerable to false
dilemma style fallacies? There's no "either/or" here. It's not a zero
sum game. If you don't see value in doing more with IPv4 then why
don't you get out of the way of folks who do?

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Making Use of 240/4 NetBlock

[JORDI PALET MARTINEZ via NANOG]

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 continue the IPv6 deployment which is already going on 
in this region and the rest of the world.

 

It would not make sense, to throw away all the efforts that have been already 
done with IPv6 and we should avoid confusing people.

 

I just think that even this thread is a waste of time (and will not further 
participate on it), time that can be employed in continue deploying IPv6.

 

Regards,

Jordi

@jordipalet

 

 

 

El 12/3/22 6:32, "NANOG en nombre de Greg Skinner via NANOG" 
 escribió:

 

 



On Mar 10, 2022, at 8:44 PM, Masataka Ohta  
wrote:


IIRC, at some time, perhaps when CIDR was deployed widely and
having something other than IPv4 was a hot topic, there was a
discussion on releasing 240/4 in IETF. Reasonings against it were
that the released space will be consumed quickly (at that time,
NAT already existed but was uncommon) and that new IP will be
designed and deployed quickly (we were optimistic).

    
   Masataka Ohta

 

There have been many discussions about 240/4 in the IETF.  For some examples, 
query “240/4” in the ‘ietf’ mail archive on mailarchive.ietf.org.

 

—gregbo



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: 25G SFP28 capable of rate-adaption down to 1G?

[JORDI PALET MARTINEZ via NANOG]

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 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 also work at 2.5 and 5 Gbit/s,  not sure 

For example, an old 1 Gbit/s SFP-only switch works fine connecting it to a 
newer switch that has SFP+ (10 Gbit/s). Of course, the speed goes down to 1 
Gbit/s only. In this specific case, just for fun, I tried both copper and 
optical, and both worked.

Some DAC and AOC also work the same as I know.

Note that it may depend on the specific vendor/model, and some of them you 
may need to "program" them to support multispeed or a fixed speed.

SFP28 is just an enhanced SFP+, an in fact SFP28 work in SFP+ interfaces. 
So it should be the same, as the electrical signals are the same.


Regards,
Jordi
@jordipalet



El 31/1/22 19:07, "NANOG en nombre de Bill Woodcock" 
 
escribió:

Hey, does anyone know of an SFP28 capable of rate-adapting down from 
25G on the cage side down to 1G on the line side?  Can be copper or fiber on 
the line side, I don’t care, my interest is in the chip inside.

Thanks,

-Bill




**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.






**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: 25G SFP28 capable of rate-adaption down to 1G?

[JORDI PALET MARTINEZ via NANOG]

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 also work at 2.5 and 5 Gbit/s,  not sure 

For example, an old 1 Gbit/s SFP-only switch works fine connecting it to a 
newer switch that has SFP+ (10 Gbit/s). Of course, the speed goes down to 1 
Gbit/s only. In this specific case, just for fun, I tried both copper and 
optical, and both worked.

Some DAC and AOC also work the same as I know.

Note that it may depend on the specific vendor/model, and some of them you may 
need to "program" them to support multispeed or a fixed speed.

SFP28 is just an enhanced SFP+, an in fact SFP28 work in SFP+ interfaces. So it 
should be the same, as the electrical signals are the same.


Regards,
Jordi
@jordipalet
 
 

El 31/1/22 19:07, "NANOG en nombre de Bill Woodcock" 
 
escribió:

Hey, does anyone know of an SFP28 capable of rate-adapting down from 25G on 
the cage side down to 1G on the line side?  Can be copper or fiber on the line 
side, I don’t care, my interest is in the chip inside.

Thanks,

-Bill




**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Powerline Broadband Usecases

[JORDI PALET MARTINEZ via NANOG]

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 offered for a few years.

 

We demonstrated that the complains of radio amateurs about interferences were 
unfounded and provided IPv6, QoS, VoIP, triple play, etc., etc.

 

There were many other commercial deployments as a result of this project. The 
problem was that in the next years the demand for more bw was easier and 
cheaper to achieve with FTTH and DOCSIS.

 

However all the development was used for offering PLC in-home, and to allow the 
electricity meters to be controlled via the power line, which in my opinion is 
a good project success.

 

It may be still interesting in some remote areas if you can bring fiber to the 
nearest medium to low voltage transformer.

 

The company that designed the chip set (DS2, a Spanish company), was acquired 
by Marvell 
(https://www.marvell.com/company/newsroom/marvell-acquires-ds2-technology.html).
 I’m sure that they have many products (semiconductors) as a result of what we 
did in the project, but I don’t know the status, which are used in in-home PLC 
for sure. However, I’m not sure if there are many device providers using them 
for PLC services, CPEs, etc.

 

Regards,

Jordi

@jordipalet

 

 

 

El 27/9/21 19:06, "NANOG en nombre de Noah" 
 escribió:

 

Hi Folks

 

I would like to find out if there are any known State run broadband 
connectivity services for homes? I mean government providing IP based 
connectivity over grid power?

 

Noah



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: IPv6 woes - RFC

[JORDI PALET MARTINEZ via NANOG]

You're confusing things.

The fact that cellular providers, actually cellular equipment vendors, do not 
implement DHCPv6-PD, doesn't mean that you can't use DHCPv6-PD for assigning 
IPv6 prefixes using 464XLAT in broadband.

See RFC8585 and RFC8683.
 

El 6/9/21 14:56, "NANOG 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
IPv6.  You can pick anyone you like.  But the extra layers still do not
come for free.

And cellular providers give you a single /64.  Not even useful as IPv6
access for anything larger than a single handset.  Extending that /64 to
something you can use is non-trivial.  How many providers have actually
done that?

And how many end users cared?




Bjørn



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: IPv6 woes - RFC

[JORDI PALET MARTINEZ via NANOG]

Users don't care about IP at all.

They just want to make sure that their apps keep working.

If you switch them to IPv6, and they have faster access for IPv6 enables sites 
and apps (40% faster time to complete HTTP get), and they don't notice that the 
WAN is IPv6-only, because inside 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%.
>
> You need less and less IPv4 addresses in the NAT64, less NAT64 boxes.
>
> Less resources to operate IPv6-only vs dual-stack.
>
> And because the IPv6 traffic is going up more and more with the time,
> you 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.

You're assuming that IPv6 is required.  There is no reason do do that in
the current Internet.  IPv6 is still optional. The number of users who
care about IPv6 access is very close to 0 and dropping.

And as demonstrated in this thread: Even the few who still do care are
not willing to pay extra, or sacrifice anything, for IPv6.  They will
run off to your competitor as soon as they discover the price is lower
there. Which it will be since they saved a lot by building and running
an IPv4 only access network.



Bjørn



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: IPv6 woes - RFC

[JORDI PALET MARTINEZ via NANOG]

It is simple, most of your traffic will use IPv6. Depending on your 
network/customer base 65-85%.

You need less and less IPv4 addresses in the NAT64, less NAT64 boxes.

Less resources to operate IPv6-only vs dual-stack.

And because the IPv6 traffic is going up more and more with the time, you 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 via NANOG
 wrote:

> Reduced Capex and Opex in general.

Can you show the work?

-- 
  ++ytti



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: IPv6 woes - RFC

[JORDI PALET MARTINEZ via NANOG]

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 is IPv4-ignorant.
 
Reduced Capex and Opex in general.
 

El 6/9/21 9:29, "NANOG en nombre de Saku Ytti" 
 
escribió:

On Mon, 6 Sept 2021 at 10:20, Bjørn Mork  wrote:

> Adding new access infrastructure of any sort (Fixed Wireless is the
> hype...)?  Why would you want to continue being stupid even if you
> implemented dual-stack for all your fibre, hfc and dsl customers?  You
> can save a lot by dropping dual-stack complexities in PGWs and FWA CPEs,
> even if we assume most of the fibre/hfc/dsl value chain is reused.

Can you? You need to offer IPv4 anyhow and all the complexities
related to that, i.e. some stateful box. Why would I offer in addition
to that IPv6, which is not being requested by anyone. And by anyone I
mean anyone I want as customer, as those who request it, are probably
going to be expensive to support and I need to subsidise those with my
regular customers, so I'd rather not cater to those.



-- 
  ++ytti



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Abuse Contact Handling

[JORDI PALET MARTINEZ via NANOG]

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 today open 
source tools for that.
 
 

El 5/8/21 22:46, "NANOG en nombre de Matt Corallo" 
 escribió:

There's a few old threads on this from last year or so, but while 
unmonitored abuse contacts are terrible, similarly, 
people have installed automated abuse contact spammer systems which is 
equally terrible. Thus, lots of the large hosting 
providers have deemed the cost of actually putting a human on an abuse 
contact is much too high.

I'm not sure what the answer is here, but I totally get why large providers 
just say "we can better protect a web form 
with a captcha than an email box, go use that if there's real abuse".

Matt

On 8/5/21 09:14, Mike Hammett wrote:
> What does the greater operator community think of RIR abuse contacts that 
are unmonitored autoresponders?
> 
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
> 
> Midwest-IX
> http://www.midwest-ix.com



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Abuse Contact Handling

[JORDI PALET MARTINEZ via NANOG]

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

 

LACNIC

https://www.lacnic.net/4419/2/lacnic/12-registration-and-validation-of-abuse-c-and-abuse-mailbox

 

 

In RIPE and ARIN it failed (even if there is something similar, but not so 
efficient). I plan to resubmit at some point, just thinking in alternative 
approches.

 

Regards,

Jordi

@jordipalet

 

 

 

El 5/8/21 15:16, "NANOG en nombre de Mike Hammett" 
 escribió:

 

What does the greater operator community think of RIR abuse contacts that are 
unmonitored autoresponders?



-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: DualStack (CGNAT) vs Other Transition methods

[JORDI PALET MARTINEZ via NANOG]

In the pilot we have got, up to now, *0* support tickets related to 464XLAT, 
just normal ones.

 

I think Cameron already told, if I’m not confused, they didn’t get support 
tickets, and they are doing 464XLAT in cellular and broadband for many years 
with hundreds of millions of customers.

 

I don’t understand what you mean with the support folks, they just do what 
their boss decides, like in any other technology deployment.

 

Of course I agree that Sony PS is not doing well, but they have been doing so 
bad for ages already (compared with Microsoft, Google, etc., etc.), 
unfortunately they don’t go to events or respond to emails to help them. If 
someone has a better contact, will be happy to help!

 

Regards,

Jordi

@jordipalet

 

 

 

El 6/4/21 0:18, "NANOG en nombre de Douglas Fischer" 
 escribió:

 

Jordi, If I sum the numbers of times "It is a deployment with 25.000.000 
customers, using GPON, DSL and cellular." (or similar)(EN, ES, PT) appears on 
my mail box, I guess will be over 2 hundred...

But every time it hits on:
 -> Support Tickets! What do they tell us?
 -> Field Support and L1 Support Guys. Do they agree with that?

Let me be clear:
- I like IPv6!
- I encourage the use of IPv6!
- I think those guys that say "IPv6 won't be adopted" a bunch of lunatics!

But, more important than IPv4, IPv6, "IPv12" is that my customers become happy 
and D'ONT BOTHER ME.
If I would use IPX/SPX and get them even happier than they are today, I would 
do!

The important message on Tore's post IS NOT "464XLAT is better then Dual Stack".
The important message on Tore's post IS NOT "Sony and Playstation are doing 
IPv6 in the wrong way!".  

Could you please help every ISP, Every 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 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.

 

So, we concluded in that discussion that there is *no difference* for the PS5 
being used with 464XLAT vs “regular dual-stack”, as expected.

 

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 deployment with 25.000.000 customers, using GPON, DSL and 
cellular.

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 5/4/21 21:32, "NANOG en nombre de Douglas Fischer" 
 escribió:

 

Here goes a link fo an excellent analysis of IPv6 and Playstation

This says a lot about why some prefer DualStack.

https://toreanderson.github.io/2021/02/23/ipv6-support-in-the-playstation-5.html

 

Em ter., 2 de mar. de 2021 às 07:59, Douglas Fischer  
escreveu:

Hello Mark...

Yes, until when I was decided to Fight Agins IPv4, I tried the Fixes.

But after some time, I saw that very little of the problems were due to 
inadequacies of the ISP's responsibility equipment.


Most of the difficulties stemmed from:
A) Choices of end-users in their networks.
(Something that the ISP may even try to influence, but that ends up bringing 
more "childrens" to the support queue, as customers said, "Your company that 
recommended me to use software X instead of Y, so you have to teach me how to 
use software X".)
B) Lack of adequate support for IPv6 by the companies that provided the service 
on the internet (eGames, IPTV, SIP-VOIP).

After some time beating the dead horse, and mainly seeing that these problems 
did not happen with Dual-Stack, I decided to do what I was able to do well.

Since 1-2 years ago, things have improved a lot in these two points, pointed 
out as problems that do not concern the ISP.
Perhaps it is time to review this approach.

 

 

Em qua., 24 de fev. de 2021 às 18:35, Mark Andrews  escreveu:

Well then use one of the encapsulating IPv4AAS mechanisms rather than 464XLAT 
(DS-Lite, MAP-E). They don’t involve translating the payload between IPv4 and 
IPv6.  That said what you are reporting below are implementation bugs.  Did you 
report them to the vendor?  Did you install the fix?  Rewriting is required as 
you may have native IPv6 clients rather than clients behind a CLAT on the 
customer side.

> On 25 Feb 2021, at 01:48, Douglas Fischer  wrote:
> 
> 
> 
> Is this pain you have lived or verified with first hand testing?
> 
> Yep! A lot!
> 
> LOL gamers can be pretty much insistent...
> (haha.jpg +  haha-crying.jpg)
> 
> And Specifica

Re: DualStack (CGNAT) vs Other Transition methods

[JORDI PALET MARTINEZ via NANOG]

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, JORDI 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 deployment with 25.000.000 customers, using GPON, DSL and 
cellular.


Jordi, one of these days, you are going to have to tell us if this is real :-).

Mark.




**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: DualStack (CGNAT) vs Other Transition methods

[JORDI PALET MARTINEZ via NANOG]

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.

 

So, we concluded in that discussion that there is *no difference* for the PS5 
being used with 464XLAT vs “regular dual-stack”, as expected.

 

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 deployment with 25.000.000 customers, using GPON, DSL and 
cellular.

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 5/4/21 21:32, "NANOG en nombre de Douglas Fischer" 
 escribió:

 

Here goes a link fo an excellent analysis of IPv6 and Playstation

This says a lot about why some prefer DualStack.

https://toreanderson.github.io/2021/02/23/ipv6-support-in-the-playstation-5.html

 

Em ter., 2 de mar. de 2021 às 07:59, Douglas Fischer  
escreveu:

Hello Mark...

Yes, until when I was decided to Fight Agins IPv4, I tried the Fixes.

But after some time, I saw that very little of the problems were due to 
inadequacies of the ISP's responsibility equipment.


Most of the difficulties stemmed from:
A) Choices of end-users in their networks.
(Something that the ISP may even try to influence, but that ends up bringing 
more "childrens" to the support queue, as customers said, "Your company that 
recommended me to use software X instead of Y, so you have to teach me how to 
use software X".)
B) Lack of adequate support for IPv6 by the companies that provided the service 
on the internet (eGames, IPTV, SIP-VOIP).

After some time beating the dead horse, and mainly seeing that these problems 
did not happen with Dual-Stack, I decided to do what I was able to do well.

Since 1-2 years ago, things have improved a lot in these two points, pointed 
out as problems that do not concern the ISP.
Perhaps it is time to review this approach.

 

 

Em qua., 24 de fev. de 2021 às 18:35, Mark Andrews  escreveu:

Well then use one of the encapsulating IPv4AAS mechanisms rather than 464XLAT 
(DS-Lite, MAP-E). They don’t involve translating the payload between IPv4 and 
IPv6.  That said what you are reporting below are implementation bugs.  Did you 
report them to the vendor?  Did you install the fix?  Rewriting is required as 
you may have native IPv6 clients rather than clients behind a CLAT on the 
customer side.

> On 25 Feb 2021, at 01:48, Douglas Fischer  wrote:
> 
> 
> 
> Is this pain you have lived or verified with first hand testing?
> 
> Yep! A lot!
> 
> LOL gamers can be pretty much insistent...
> (haha.jpg +  haha-crying.jpg)
> 
> And Specifically on SIP/Voip over the Internet, with deep analysis at all the 
> parts involved.
> The most common issue is incoming Calls to SIP endpoints behind 464Xlat using 
> IPv4 with unidirectional audio.
> And several types of causes:
>  - CPEs receives the RTP-Stream but doesn't Re-Map it correctly to the IPv4 
> inside end-point
>  - Jool receives the RTP-Stream but ignores it and don't map it to the "fake" 
> v6 address
>  - Some APPs do (by some crazy reason) the re-write of Session Layer header 
> to v6 address, and Sip-Proxys ignores it...
> 
> After hours and hours fighting against the lions, we decided:
> "Let's keep those clients in Dual-Stak and CGNAT" and it just worked.
> 
> And after that, the obvious conclusions:
>  - Why will us keep that much options of endpoints connections, if only one 
> solves all the problems?
>  - We will need to train the guys on the Dual-Stack/CGNAT Scnario, and 
> 464Xlat Scenario... Knowing about Danos, about Jool...
>  - It doesn't scale!
> 
> 
> -- 
> Douglas Fernando Fischer
> Engº de Controle e Automação

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org


 

-- 

Douglas Fernando Fischer
Engº de Controle e Automação


 

-- 

Douglas Fernando Fischer
Engº de Controle e Automação



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so 

Re: OVH datacenter SBG2 in Strasbourg on fire 

[JORDI PALET MARTINEZ via NANOG]

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 mailing lists ...

So, the positive side is a) during some days, we can see an interesting 
decrease in abuse cases, b) because the so many abuse cases, many OVH "honest" 
customers are often being filtered because they share addresses with the "bad 
guys", so it is an opportunity for them to move to alternative DCs that 
probably are more careful about "bad guys".

A good topic for researchers :-)

Regards,
Jordi
@jordipalet
 
 

El 10/3/21 16:44, "NANOG en nombre de Andy Ringsmuth" 
 escribió:


> On Mar 10, 2021, at 3:23 AM, Fredy Kuenzler  wrote:
> 
> Very sad day for our colleagues at OVH AS16276 as they lost their 
datacenter SBG-2 in Strasbourg/France completly („everything is destroyed“) in 
a fire  and the neighboring SBG1/SBG3/SBG4 at least temporary.
> 
> 
https://www.dna.fr/amp/faits-divers-justice/2021/03/10/strasbourg-important-incendie-dans-une-entreprise-situee-sur-un-site-seveso-au-port-du-rhin

Sad to see of course, but also a little surprising that fire suppression 
systems didn’t, well, suppress the fire.

Unless they didn’t exist?



Andy Ringsmuth
5609 Harding Drive
Lincoln, NE 68521-5831
(402) 304-0083
a...@andyring.com

“Better even die free, than to live slaves.” - Frederick Douglas, 1863




**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: DualStack (CGNAT) vs Other Transition methods

[JORDI PALET MARTINEZ via NANOG]

Hi Douglas,

 

I’ve done a lot of testing in several countries and customer networks and I’ve 
never got a single failure because 464XLAT.

 

If anything failed, we tested it with a pure IPv4 network and dual-stack 
network. They failed as well.

 

For example, I recall, in a customer deployment, that PlayStation 4 was not 
working … surprise. It was a specific problem *at that specific time*, so it 
was also not working with IPv4-only. Retested a couple of days after, and it 
worked.

 

I talk very frequently with other engineers which have also deployed 464XLAT in 
both cellular and wireline, and I’ve never heard any complain about any 
specific application or service not working because 464XLAT, so I’m not alone 
on this.

 

So, I think experience talk. Probably the question is about the same as you’re 
indicating “good quality” (whatever, including experience in the matter), makes 
things work without issues!

 

Regards,

Jordi

@jordipalet

 

 

 

El 24/2/21 14:28, "Douglas Fischer"  escribió:

 

P.S.: Forking thread from CGNAT.

Hello Jordi!

Since our last heated talk about transitions methods(Rosario, 2018?), I must 
recognize that the intolerance to other scenarios other than dual-stack had 
reduced(mostly because of improvements on the applications in generral). I'm 
even considering the possibility of using 464Xlat on some scenarios.


But I'm still, as it was in 2018, primarily concerned to avoid end-user support 
tickets.

And I'm still hooked on some specific issues... For example:
- SIP/Voip Applications, that almost all the providers do not work correctly on 
when those streams and connections pass over some v6 only paths.

- Applications with some source-based restrictions(some Internet Banking, some 
Compan-VPNs).

- Games (this is the champion of support tickets).

For that, with 464Xlat we still keep in pain...
But using DualStack with Good Quality CGNAT, the support tickets statistics are 
reduced to less than 5%.


So, the question here is:
How not use Dual-Stack and keep the support tickets as low as possible?


* "Good Quality CGNAT" means:
 - OBVIOUSLY have an extensive, deep, and GOOD deployment of IPv6(to avoid as 
much as possible the use of IPv4)
 - Good rules of CGNAT By-Pass (Ex.: Traffic between customers and Internal 
Servers don't need to be NATed.)
 - CGNAT with support to 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, 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 money in CGN, you avoid CGN troubles (like black listening your 
IPv4 addresses by Sony and others and the consequently operation/management 
expenses to rotate IPv4 addresses in the CGN, resolve customers problems, 
etc.), it becomes cheaper than CGN boxes.

It's easy to predict that you will buy now CGN and tomorrow you will need to 
buy some new IPv4 addresses because that black listening.

Regards,
Jordi
@jordipalet



El 24/2/21 3:13, "NANOG en nombre de Owen DeLong via NANOG" 
 escribió:



> On Feb 22, 2021, at 6:44 AM, na...@jima.us wrote:
> 
> While I don't doubt the accuracy of Lee's presentation at the time, at 
least two base factors have changed since then:
> 
> - Greater deployment of IPv6 content (necessitating less CGN capacity per 
user)

This is only true if the ISP in question is implementing IPv6 along side 
their CGN deployment and only if they get a significant uptake of IPv6 
capability by their end users.

> - Increased price of Legacy IP space on the secondary market (changing 
the formula) -- strictly speaking, this presentation was still in "primary 
market" era for LACNIC/ARIN/AFRINIC

While that’s true, even at current prices, IPv4 addresses are cheaper to 
buy and/or lease than CGN.

> IPv6 migration is not generally aided by CGNAT, but CGNAT deployment is 
generally aided by IPv6 deployment; to reiterate the earlier point, any ISPs 
deploying CGNAT without first deploying IPv6 are burning cash.

Yep.

I still think that implementing CGN is a good way to burn cash vs. the 
alternatives, but YMMV.

Owen

> 
> - Jima
> 
> From: NANOG On Behalf Of Owen DeLong
> Sent: Sunday, February 21, 2021 16:59
> To: Steve Saner
> Cc: nanog@nanog.org
> Subject: Re: CGNAT
> 
> 
> On Feb 18, 2021, at 8:38 AM, Steve Saner wrote:
> 
>> We are starting to look at CGNAT solutions. The primary motivation at 
the moment is to extend current IPv4 resources, but IPv6 migration is also a 
factor.
> 
> IPv6 Migration is g

Re: CGNAT

[JORDI PALET MARTINEZ via NANOG]

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 money in CGN, you avoid CGN troubles (like black listening your 
IPv4 addresses by Sony and others and the consequently operation/management 
expenses to rotate IPv4 addresses in the CGN, resolve customers problems, 
etc.), it becomes cheaper than CGN boxes.

It's easy to predict that you will buy now CGN and tomorrow you will need to 
buy some new IPv4 addresses because that black listening.

Regards,
Jordi
@jordipalet
 
 

El 24/2/21 3:13, "NANOG en nombre de Owen DeLong via NANOG" 
 escribió:



> On Feb 22, 2021, at 6:44 AM, na...@jima.us wrote:
> 
> While I don't doubt the accuracy of Lee's presentation at the time, at 
least two base factors have changed since then:
> 
> - Greater deployment of IPv6 content (necessitating less CGN capacity per 
user)

This is only true if the ISP in question is implementing IPv6 along side 
their CGN deployment and only if they get a significant uptake of IPv6 
capability by their end users.

> - Increased price of Legacy IP space on the secondary market (changing 
the formula) -- strictly speaking, this presentation was still in "primary 
market" era for LACNIC/ARIN/AFRINIC

While that’s true, even at current prices, IPv4 addresses are cheaper to 
buy and/or lease than CGN.

> IPv6 migration is not generally aided by CGNAT, but CGNAT deployment is 
generally aided by IPv6 deployment; to reiterate the earlier point, any ISPs 
deploying CGNAT without first deploying IPv6 are burning cash.

Yep.

I still think that implementing CGN is a good way to burn cash vs. the 
alternatives, but YMMV.

Owen

> 
> - Jima
> 
> From: NANOG On Behalf Of Owen DeLong
> Sent: Sunday, February 21, 2021 16:59
> To: Steve Saner
> Cc: nanog@nanog.org
> Subject: Re: CGNAT
> 
> 
> On Feb 18, 2021, at 8:38 AM, Steve Saner wrote:
> 
>> We are starting to look at CGNAT solutions. The primary motivation at 
the moment is to extend current IPv4 resources, but IPv6 migration is also a 
factor.
> 
> IPv6 Migration is generally not aided by CGNAT.
> 
> In general, the economics today still work out to make purchasing or 
leasing addresses more favorable than CGNAT.
> 
> It’s a bit dated by now, but still very relevant, see Lee Howard’s 
excellent research presented at the 2012 Rocky
> mountain v6 task force meeting:
> 
> https://www.rmv6tf.org/wp-content/uploads/2012/11/TCO-of-CGN1.pdf
> 
> Owen
> 
> 
> We've been in touch with A10. Just wondering if there are some 
alternative vendors that anyone would recommend. We'd probably be looking at a 
solution to support 5k to 15k customers and bandwidth up to around 30-40 gig as 
a starting point. A solution that is as transparent to user experience as 
possible is a priority.
> 
> Thanks
> 
> -- 
> Steve Saner
> ideatek HUMAN AT OUR VERY FIBER
> This email transmission, and any documents, files or previous email 
messages attached to it may contain confidential information. If the reader of 
this message is not the intended recipient or the employee or agent responsible 
for delivering the message to the intended recipient, you are hereby notified 
that any dissemination, distribution or copying of this communication is 
strictly prohibited. If you are not, or believe you may not be, the intended 
recipient, please advise the sender immediately by return email or by calling 
tel:620.543.5026. Then take all steps necessary to permanently delete the email 
and all attachments from your computer system.
> 




**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: CGNAT

[JORDI PALET MARTINEZ via NANOG]

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 is the transition mechanism that have more millions of 
customers, even if compared with all the others together.

 

Regards,

Jordi

@jordipalet

 

 

 

El 19/2/21 21:15, "NANOG en nombre de Tony Wicks" 
 escribió:

 

Because then a large part of the Internet won't work

 

From: NANOG  on behalf of Mark 
Andrews 
Sent: Saturday, 20 February 2021, 9:04 am
To: Steve Saner
Cc: nanog@nanog.org
Subject: Re: CGNAT


Why not go whole hog and provide IPv4 as a service? That way you are not 
waiting for your customers to turn up IPv6 to take the load off your NAT box.

 

Yes, you can do it dual stack but you have waited so long you may as well miss 
that step along the deployment path.

-- 

Mark Andrews




On 20 Feb 2021, at 01:55, Steve Saner  wrote:



We are starting to look at CGNAT solutions. The primary motivation at the 
moment is to extend current IPv4 resources, but IPv6 migration is also a factor.

 

We've been in touch with A10. Just wondering if there are some alternative 
vendors that anyone would recommend. We'd probably be looking at a solution to 
support 5k to 15k customers and bandwidth up to around 30-40 gig as a starting 
point. A solution that is as transparent to user experience as possible is a 
priority.

 

Thanks


-- 

Steve Saner

ideatek HUMAN AT OUR VERY FIBER

This email transmission, and any documents, files or previous email messages 
attached to it may contain confidential information. If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering the message to the intended recipient, you are hereby notified that 
any dissemination, distribution or copying of this communication is strictly 
prohibited. If you are not, or believe you may not be, the intended recipient, 
please advise the sender immediately by return email or by calling 
620.543.5026. Then take all steps necessary to permanently delete the email and 
all attachments from your computer system.

 



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Past policies versus present and future uses

[JORDI PALET MARTINEZ via NANOG]

Hi Matthew,

 

I’m not sure I’ve succeded to explain it in previous emails.

The requirement for the LACNIC policies about majority of usage *in the region* 
of the resources provided has been there for many years. I’m almost sure than 
since day 1, but will need to dig into older versions of the policy manual to 
check that.

The *text* was only using the work “mayoría”, but the interpretation when 
ensuring policy compliance, was following that definition of “mayoria”, which 
is more than 50%. My policy proposal, was “cleaning” and “clarifiying” text 
here and there. For example, there were some text that clearly apply to IPv4 
and IPv6, and was only in the IPv4 section, etc. The policy proposal also did a 
lot of major changes for the recovery of uncompliant addressing space by 
ensuring that LACNIC setup periodic and automatic policy compliance checks.

So: the “>50%” was not a “change”, was just making explicit the actual 
practice, and during the discussion of the proposal, we made sure in the 
mailing list that everybody agree with that clarification of the *existing* 
interpretation. Nobody, absolutely nobody, objected or said “I don’t read it 
that way”. In fact, I asked if the people prefers to use some “other %”, or 
completely delete it or whatever.

I don’t have the exact details of the case that Ron discovered in Belize, 
because, of course, most of the details are under NDA between the resourse 
holder and LACNIC, private documents, etc., etc. So I’m not sure if “initially” 
the resource holder was really having the “majority” of the resources operated 
in Belize or some other place in the region and then they “forgot” that they 
need to follow the policy (as said, the policy has not changed in that sense). 
My guess is that they provided false information to LACNIC “yes we have the 
majority of the operation in the region”, and the RIR trusted the provided 
documents, but is only my guess.

I fully see your point, however *every ISP/LIR needs to follow the policies in 
every RIR where they have resources*. Policy changes may require changes in 
their operation, and if they don’t agree, *this is the reason* they MUST 
participate in policy discussions, to be able to defend their position.

This is *nothing new*! Is part of the job of the ISPs/LIRs, to ensure that they 
follow the policy discussions, the same way as citizens follow law development 
because changes in law (new taxes, etc.), can change their compliance with law. 
Is not about retroactivity, is about every one of us developing the “laws” and 
justify why something can’t be changed.

The solution to those that don’t want to follow (even if is part of their 
“job”) the policy development, is to have warnings when there is a policy 
change that affects them. In fact I’ve included that in a policy proposal in 
AFRINIC 
(https://www.afrinic.net/policy/proposals/2020-gen-001-d1?lang=en-GB#proposal), 
by means of a dash-board. This could be done also by other RIRs as part of 
their “operational” terms in the customers accounts (such in “mylacnic” in the 
case of LACNIC), etc., and in fact it was the main intent of my policy proposal.

As said, remember that this has been not changed, just added a clarification 
based on the existing understanding of the previuos text. LACNIC will not have 
provided to this resource-holder in 2013 the resources if they didn’t had 
indicated that the majority (over 50%) of those resrouces aren’t being operated 
in the region.

I found and older archived version of the policy manual from 2013 (in Spanish):

https://www.lacnic.net/innovaportal/file/543/1/manual-politicas-sp-2.0.pdf

In section 1.11, has exactly the same text:

“Los recursos de numeración de Internet bajo la custodia de LACNIC se deben 
distribuir a organizaciones legalmente establecidas en su región de servicio 
[COBERTURA] y para atender mayoritariamente 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 RIRs communities, decided to be more relaxed on that requirement, so 
you don’t need actually more than 1 or may be 2 allocations. Of course, we are 
talking “in the past” because if we are referring to IPv4 addresses, you 
actually have a different problem trying to get them from the RIRs.

 

Hi Jordi,

 

I've adjusted the subject line to reflect the real thrust of this discussion.

 

You're right--if we're trying to get "new" allocations of IPv4 addresses, we've 
got bigger problems to solve.

 

But when it comes to IPv6 address blocks and ASNs, these questions are still 
very relevant.

 

And, going back to the original article that spawned the parent thread, the 
problem wasn't about companies requesting *new* blocks, it was about the usage 
of old, already granted blo

Re: Nice work Ron

[JORDI PALET MARTINEZ via NANOG]

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 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, at all.
> 
> Where is it? How does it stated?
> 
> [Jordi] There may be some problem with your browser or Internet
> connectivity that is missing some parts of the web site, as I can see
> it in many places, and especially those more relevant (bylaws and
> policy manual):
> 
> https://www.lacnic.net/76/2/lacnic/bylaws
> 
> https://www.lacnic.net/680/2/lacnic/policy-manual-[v214---24_07_2020]

That it is stated some random pages deep within LACNIC website
does not mean "clearly indicated in LACNIC web site".

As such, LACNIC can't expect English-using people see the pages,
which means it is fault of LACNIC if they believe policy
in English is a formal one.

> Could you explain why google translation says "mayoria" in English 
> means (sorted by frequency) "most", "majority", "many", "bulk" and 
> "plurality"?
> 
> [Jordi] I'm not native English speaker, so I'm not the best one to
> explain that.

I'm afraid you are saying you have no say on the meaning of "mainly".

 > As I said, several times, the official documents are the Spanish
 > version, and in the Spanish version the right word being used is
 > "mayoría", which I believe, in *this context* it is better
 > translated to "majority".

which is not compatible with translation by google.

Masataka Ohta




**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Nice work Ron

[JORDI PALET MARTINEZ via NANOG]

Again, I'm not saying is the best way, is what the community *decided* before I 
added a clarification. The 50% was not a change, just to make it explicit, what 
was the actual interpretation.

If you don't like it, stop complaining, and send a policy proposal, I could 
even support it, 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 “%50 or even 100%” of usage in
> the region.

So, you don't know how most, if not all, ISPs are operating
their network.

 > That will make your life more complex, as you will need to obtain

It makes ISP's operations a lot more complex and a lot less
profitable to be ignored by almost all, if not all, ISPs.

Your theory that ISPs could have behaved otherwise is not
helpful in the real world of business and not practically
acceptable by RIRs mostly consisting of ISPs.

Masataka Ohta



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Nice work Ron

[JORDI PALET MARTINEZ via NANOG]

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 it clearly indicated in LACNIC web site, at all.

Where is it? How does it stated?

[Jordi] There may be some problem with your browser or Internet connectivity 
that is missing some parts of the web site, as I can see it in many places, and 
especially those more relevant (bylaws and policy manual):

https://www.lacnic.net/76/2/lacnic/bylaws

https://www.lacnic.net/680/2/lacnic/policy-manual-[v214---24_07_2020]



 > I've already informed LACNIC that "mainly", in my opinion, is a wrong
 > translation for "mayoria", and should be majority, but in any case,
 > the spanish version is the relevant one.

Could you explain why google translation says "mayoria" in English
means (sorted by frequency) "most", "majority", "many", "bulk" and
"plurality"?

[Jordi] I'm not native English speaker, so I'm not the best one to explain 
that. As I said, several times, the official documents are the Spanish version, 
and in the Spanish version the right word being used is "mayoría", which I 
believe, in *this context* it is better translated to "majority".





**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Nice work Ron

[JORDI PALET MARTINEZ via NANOG]

I fully understand what you mean, however, I don’t think this is a problem even 
if all the RIRs ask for “%50 or even 100%” of usage in the region.

 

That will make your life more complex, as you will need to obtain addresses 
from each RIR. In the worst case, if all them ask for the same:

If you need 2.000 addresses in LACNIC, 4.000 in ARIN, 3.000 in RIPE, 5.000 in 
APNIC and 1.000 in AFRINIC (just an example). This makes in total a global need 
for your network of 15.000 addresses. You will sign 5 contracts, and you will 
get a block from each RIR, that is a bit higher than your actual needs in that 
region. This means that you have more than 50% of the usage in that region and 
in the case of LACNIC, it means that you need to ensure that 1.000 addresses 
are used there. Probably you will not actually need to get addresses from every 
RIR, for example, the 1.000 addresses that you need for AFRINIC, are the excess 
of addresses from LACNIC, etc.

 

So, you end up with 2-3 RIRs allocations, not 5. And the real situation is that 
3 out of 5 RIRs communities, decided to be more relaxed on that requirement, so 
you don’t need actually more than 1 or may be 2 allocations. Of course, we are 
talking “in the past” because if we are referring to IPv4 addresses, you 
actually have a different problem trying to get them from the RIRs.

 

It is the decision of the community if they don’t like this complexity and they 
don’t care if you get all the addresses from LANIC (for whatever reason you 
have that preference, or the corporation is sitting them, etc.), and actually 
only 20% of the addresses are being used in the region (for example) and the 
community can change that at any time.

 

For that, you *don’t need to convince me*, you need to go to the LACNIC policy 
list and convince the community there.

 

My policy proposal *didn’t change that*. The word “majority” was already there. 
It was already being interpreted “literally” as “you need to operate more than 
the half of the IPs *that you get from LACNIC* in the LACNIC region”. I just 
added a footnote (as part of a mayor set of policy changes), to make sure that 
everybody is clearly reading the same with >50% instead of coming to the list 
or to the staff to ask for clarity every other day.

 

Note that you are interpreting the % from your “complete network”. LACNIC 
community that did the original policy and adopted the recent change, may have 
a more “regional” perspective, culture, or whatever you call it (may be because 
the lack of IPv4 addresses, the lack of business cases – in general – for 
organizations that are from that region but operate globally, etc., etc.).

 

As I already 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 sign a contract with a RIR (whatever RIR), is always 2 parties, so 
majority of resources operated in the region (so to have the complete context) 
clearly means that you are using in the region >50% of the provided IPs.

 

No.

 

If you operate a global backbone on six continents, 

and obtain a block of addresses to use for building 

that backbone, you can easily end up in a situation 

where there is no continent with >50% utilization of 

resources; it can easily end up with the space being

split 10%, 10%, 20%, 25%, 35%.  Every time I have 

gone to an RIR for resources, and have described the 

need, explaining that the largest percentage of the 

addresses will be used within the primary region 

has been sufficient.  No RIR has stated that a global 

backbone buildout can only be built in a region if > 50% 

of the addresses used on that backbone reside within 

their region.  Otherwise, you end up at a stalemate 

with no RIR able to allocate addresses for your backbone 

in good faith, because no region holds more than 50% of 

the planet's regions.

 

"Mainly" has been interpreted to be "the largest percentage"

every time I have requested space.

 

If RIRs start to put a >50% requirement in place, you're 

going to see global backbone providers put into the awkward 

position of having to lie about their buildout plans--so they're

going to consistently vote against language that explicitly says

">50%" just so that nobody is put into the position of having to

knowingly lie on an attestation.

 

I understand where you're coming from; but as someone who

has built global infrastructure in the past, I think it would be 

good to consider the view from the other side of the table,

and realize why the language is kept a bit more loose, to 

allow for the creation of infrastructure that spans multiple 

regions.

 

Thanks!

 

Matt

 



**
IPv4 is over
Are you 

Re: Nice work Ron

[JORDI PALET MARTINEZ via NANOG]

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 manual:

"This document and/or information was originally written in Spanish, the 
official language of Uruguay, the country where LACNIC is legally incorporated 
and whose laws and regulations LACNIC must meet. Likewise, unofficial 
information and/or documents are also written in Spanish, as this is the 
language in which most of LACNIC's collaborators and officers work and 
communicate. We do our best to ensure that our translations are reliable and 
serve as a guide for our non-Spanish-speaking members. However, discrepancies 
may exist between the translations and the original document and/or information 
written in Spanish. In this case, the original text written in Spanish will 
always prevail."
 

I've already informed LACNIC that "mainly", in my opinion, is a wrong 
translation for "mayoria", and should be majority, but in any case, the spanish 
version is the relevant one.

If you decide to do business in a region or country where the language is not 
english, at a minimum you should be able to understand the official language 
(even official government, notary, contracts, etc., documents to establish the 
business will be in that language). If you don't have the skills yourself, I 
bet you will contract a consultant, lawyer, or whatever for that.


El 23/1/21 4:23, "NANOG en nombre de Masataka Ohta" 
 escribió:

Mark Andrews wrote:

> Majority only means >50%

But actual word used by LACNIC is "mainly" as Jordi wrote:

: *“Mainly” is understood to mean more than 50%.
: (https://www.lacnic.net/681/2/lacnic/)
: The 50% was not there before, so I submitted a "recent"
: policy proposal that reached consensus,

and that is "recent" change.

Moreover, corresponding word in Spanish page is "mayoritariamente",
English translation of which is "mostly", "mainly", "chiefly" or
"by majority" according to:

https://www.spanishdict.com/dictionary

Masataka Ohta



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Nice work Ron

[JORDI PALET MARTINEZ via NANOG]

When you sign a contract with a RIR (whatever RIR), is always 2 parties, so 
majority of resources operated in the region (so to have the complete context) 
clearly means that you are using in the region >50% of the provided IPs.
 

El 23/1/21 3:06, "Mark Andrews"  escribió:

Majority only means >50%
when there are 2 parties.

When there is more than 2 parties the majority can be less than 50%.   When 
there is more than 2 parties, one uses the term “absolute majority” to indicate 
>50%. 

There are more than 2 RIRs. 

If 40% of address are used in LACNIC, 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 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 and, more
>aggressively, by me.
> 
>So?
> 
> [Jordi] The proposal, on this specific point, only made a 
"clarification", didn't mean an actual policy change. The existing policy 
already had "majority", so unless you believe that majority means something 
different than more than 50% (in the context of the full text), the change was 
"neutral". If anyone disagree with a policy in any region, MUST DO SOMETHING 
ABOUT THAT: "bring the problem to the policy list, discuss it with the 
community, and if needed make a policy proposal". In Spain we say "barking dogs 
seldom bite" and in this context means "if you complain, but don't act, then 
you have nothing to do".
> 
>> The staff was already interpreting the policy like that, because
>> usually when you say majority, you mean more than half. Do you
>> agree on that?
> 
>How can you ask such a question. already opposed by Toma and,
>more aggressively, by me, to me?
> 
> [Jordi] I think if we don't agree what means majority, then it is 
difficult to get us understanding among ourselves, so that's why I'm asking if 
you agree that in English, majority means more than half. In Spanish it means 
that.
> 
>My point is that locality requirement, whether it is 50% or 40%, is
>impractical and, with operational practices today, is not and can
>not be enforced.
> 
> [Jordi] Then you need to come to the right mailing list and discuss that 
with the community. It is not me who decides that!
> 
>>> The community decided that my proposal to add the explicit "footnote"
> 
>Then, the "footnote" might be applicable to *SOME* part of "the
>community" but definitely not beyond it.
> 
> [Jordi] A footnote in the policy manual is a clarification to the manual 
text, and of course *applies* to anyone who signs a contract with the RIR to 
obtain resources.
> 
>Masataka Ohta
> 
> 
> 
> **
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
> 
> This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.
> 
> 
> 




**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Nice work Ron

[JORDI PALET MARTINEZ via NANOG]

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 and, more
aggressively, by me.

So?

[Jordi] The proposal, on this specific point, only made a "clarification", 
didn't mean an actual policy change. The existing policy already had 
"majority", so unless you believe that majority means something different than 
more than 50% (in the context of the full text), the change was "neutral". If 
anyone disagree with a policy in any region, MUST DO SOMETHING ABOUT THAT: 
"bring the problem to the policy list, discuss it with the community, and if 
needed make a policy proposal". In Spain we say "barking dogs seldom bite" and 
in this context means "if you complain, but don't act, then you have nothing to 
do".

 > The staff was already interpreting the policy like that, because
 > usually when you say majority, you mean more than half. Do you
 > agree on that?

How can you ask such a question. already opposed by Toma and,
more aggressively, by me, to me?

[Jordi] I think if we don't agree what means majority, then it is difficult to 
get us understanding among ourselves, so that's why I'm asking if you agree 
that in English, majority means more than half. In Spanish it means that.

My point is that locality requirement, whether it is 50% or 40%, is
impractical and, with operational practices today, is not and can
not be enforced.

[Jordi] Then you need to come to the right mailing list and discuss that with 
the community. It is not me who decides that!

 >> The community decided that my proposal to add the explicit "footnote"

Then, the "footnote" might be applicable to *SOME* part of "the
community" but definitely not beyond it.

[Jordi] A footnote in the policy manual is a clarification to the manual text, 
and of course *applies* to anyone who signs a contract with the RIR to obtain 
resources.

Masataka Ohta



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Nice work Ron

[JORDI PALET MARTINEZ via NANOG]

I'm not sure how to interpret your response, but was not a meant of attacking 
anyone, on the other way around, I put my own example that *not being member of 
any RIR (not having resources in any of them, but having customers in all the 
regions, and helping them in that)* I'm contributing 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 community, however, I
> contribute to policy making process in all the regions (all the
> RIRs), even if I've no resources in any of them.

I acknowledge your statement that even yellows like me can and
should contribute to the *GLOBAL* community.

I really thank you very much.

Masataka Ohta



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Nice work Ron

[JORDI PALET MARTINEZ via NANOG]

No, what I'm saying is that the original text of the policy *BEFORE* I send my 
proposal to amend it was:

"majority" (not clarifying what is majority)

My proposal added the clarification that "majority" is understood as "over 50%".

The staff was already interpreting the policy like that, because usually when 
you say majority, you mean more than half. Do you agree on that?

The community decided that my proposal to add the explicit "footnote" to 
clarify "majority" is understood as more than 50%, agreed on that, so consensus 
was declared and the policy was amended to add that footnote.

Again, if you (or anyone) think this is wrong, you need to come to the LACNIC 
policy mailing list and discuss it there and even submit a policy proposal. I 
think I've provided sufficient clarifications here about that and responding 
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 is (mayoría)
> "majority" (that's why I said the translation as mainly, to me -not a
> native English-, is wrong).

I'm afraid you have already stated:

 > *“Mainly” is understood to mean more than 50%.

So, do you mean "majority" can mean 50% or 40% according to your
discretion?

 > Note also that the original text, before my policy proposal already
 > said the same, but didn't stated if majority is 50% or what, but in
 > general majority is well interpreted as more than half, right?

Are you, now, saying unreasonable request of "50%" is the requirement
and "40%" is not enough?

Masataka Ohta



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Nice work Ron

[JORDI PALET MARTINEZ via NANOG]

I think you're missing the point about what are policies in the RIRs.

Policies in each RIR are developed by the (global) community. I live in Madrid, 
EU, my RIR is RIPE NCC, RIPE community, however, I contribute to policy making 
process in all the regions (all the RIRs), even if I've no resources in any of 
them.

Policies are not for the RIR employees, are for *anyone* that want to apply for 
resources in a given RIR.

And that means that to apply for the resources you need to *read, understand 
and agree* with those policies. If you don't agree with the policies, then you 
send a policy proposal and it may be adopted by the community, but meanwhile, 
you're bind to it if you obtain the resources.

I agree that the document that you mention will be nicer if it has a clear 
publication date and a note that states "This is only a guideline valid at time 
of publication and may not be complete neither accurate. The actual policies 
apply.". However, you should note that this document has been done by NIC.BR, 
they are non-native Spanish, non-native English, so they may have even used the 
Portuguese translation of the policies, which again may be inaccurate (as far 
as you try to translate something from one idiom to another, always there may 
be missing details and inaccuracy).

(maybe there is some text like that in the document, I didn't read it word by 
word)

And to complement that, as I previously said ... this document is NOT an 
official LACNIC document in terms of policies. Is only a guideline. LACNIC only 
translated it.

If I publish a document in Spanish about some rules that you wrote in Japanese, 
and then you translate my document to Japanese even with my authorization, are 
you responsible of the rules set by that 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 resource allocation, is
> what the policies say.
Within LACNIC, yes, of course. LACNIC can specify some document
specifies the policy to be followed by all the employees of LACNIC.

However, that is a convention only valid locally within LACNIC.

That is, LACNIC can not enforce it to people who have looked at and
followed LACNIC statements stating otherwise.

So?

It should also be noted that you can't expect a Russian company
having some business in LACNIC region read document of LACNIC
not in English or Russian, which is why some reservation
statements I mentioned could have been essentially important.

Masataka Ohta



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Nice work Ron

[JORDI PALET MARTINEZ via NANOG]

Hi Toma,

 

First think to clarify: In the Spanish version, the text is (mayoría) 
"majority" (that's why I said the translation as mainly, to me -not a native 
English-, is wrong).

 

Note also that the original text, before my policy proposal already said the 
same, but didn't stated if majority is 50% or what, but in general majority is 
well interpreted as more than half, right?

 

The decision of having the resources used in one region or another depends on 
the RIR communities, which set the policies.

 

I think that multinationals are more often located in ARIN, RIPE or APNIC 
regions, so it is more "usual" that they get the resources from those regions, 
which I recall don't have that restriction. In AFRINIC is even worst (all the 
recourses need to be used in the region).

 

Last but not least, nothing excludes that a company having business in 
different RIR coverage areas, obtain resources from several (all) of them. This 
allows a company having 40% of their business in a given region and needing 40% 
of the resources in that region, asking in that RIR that amount, so they will 
have actually 100% of the requested resources in 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 MARTINEZ via NANOG:

The numbering resources under the stewardship of LACNIC must be distributed 
among organizations legally constituted within its service region [COBERTURA] 
and mainly *serving networks and services operating in this region. External 
clients connected directly to main infrastructure located in the region are 
allowed.

*“Mainly” is understood to mean more than 50%.

 

Just out of curiosity, I wonder what would happen if all the RIRs implemented 
the same policy.  What if a company does business across the globe and any 
particular ICANN ASO region is only responsible e.g. of 40% of revenue at most?

 

--

Töma



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Nice work Ron

[JORDI PALET MARTINEZ via NANOG]

Not at all.

The "top" mandate of any RIR, in terms or resource allocation, is what the 
policies say.

The document that you linked is just a "guide" and unfortunately, unless I 
missed it, the document doesn't have a "publication date", but I bet is several 
years old. Further to that is authored by NIC.BR, it can have mistakes. LACNIC 
only did the English translation.

As we all know, the policies in all the RIRs evolve. The only valid document in 
terms of policies, in any RIR, is the *last version* of the policy manual (or 
equivalent web pages).

If you look at the LACNIC policy manual at 
https://www.lacnic.net/680/2/lacnic/policy-manual-[v214---24_07_2020], it 
clearly states that the official source is the Spanish version:

"This document and/or information was originally written in Spanish, the 
official language of Uruguay, the country where LACNIC is legally incorporated 
and whose laws and regulations LACNIC must meet. Likewise, unofficial 
information and/or documents are also written in Spanish, as this is the 
language in which most of LACNIC's collaborators and officers work and 
communicate. We do our best to ensure that our translations are reliable and 
serve as a guide for our non-Spanish-speaking members. However, discrepancies 
may exist between the translations and the original document and/or information 
written in Spanish. In this case, the original text written in Spanish will 
always prevail."

Regarding the resource transfer that you mention, it will follow the transfer 
policy (2.3.2.18 - IPv4 address transfers) and there will be checks in both 
RIRs (source and destination), depending on the policies of each one. There is 
not a single answer to your example, we will need to see if is LACNIC to LACNIC 
(intra-RIR, and in that case the 50% usage in the region rule is sustained) or 
if it is from LACNIC to another RIR (inter-RIR, then it will not depend anymore 
on the LACNIC rules - after the transfer, but the destination RIR).



Regards,
Jordi
@jordipalet
 
 

El 22/1/21 11: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 choice is the one others must follow.

 > (look at the Spanish version, English seems not updated)

If there is a reservation statement such as "English
version is just informational and not authentic" or
"Certain restrictions may apply. See x for details."
in PDF I quoted, your point could have been valid.

Moreover,

> The numbering resources under the stewardship of LACNIC must be
> distributed among organizations legally constituted within its
> service region [COBERTURA] and mainly *serving networks and services
> operating in this region. External clients connected directly to main
> infrastructure located in the region are allowed.
> 
> *“Mainly” is understood to mean more than 50%.
requirement of such locality is, these days, seemingly
badly impractical and attempt to enforce it will likely
to be considered invalid.

For example, what if someone sells part of IP addresses assigned
from LACNIC to someone else performing business outside of
LACNIC region? If there is no restriction, it means locality
requirement is effectively invalidated.

Masataka Ohta



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Nice work Ron

[JORDI PALET MARTINEZ via NANOG]

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 numbering resources, allowing the sustainable 
growth of the Internet.

The numbering resources under the stewardship of LACNIC must be distributed 
among organizations legally constituted within its service region [COBERTURA] 
and mainly *serving networks and services operating in this region. External 
clients connected directly to main infrastructure located in the region are 
allowed.

*“Mainly” is understood to mean more than 50%.

(https://www.lacnic.net/681/2/lacnic/)

The 50% was not there before, so I submitted a "recent" policy proposal that 
reached consensus, so added that to make sure that we have a "clear" line of 
what is "mainly". Note that in LACNIC the policies are in Spanish, so the 
English translation, may not be "perfect".

So clearly, a resource holder needs to "have" the majority (>50%) of the 
services operating in the region. I think the English version is not 
sufficiently clear on that, but the Spanish one is accurate.

Also, the only reason why, as I explained to Ron when he contacted me about 
this case, it takes so long to recover resources, is because claiming for a 
resource is a really terrible situation. If a RIR makes a mistake, maybe there 
is no way back, so the RIR needs to ensure that all is very well investigated 
and the resource-holder has sufficient chances to clarify the situation.

The same policy proposal 
(https://politicas.lacnic.net/politicas/detail/id/LAC-2019-9/language/en) also 
did lots of changes across the entire policy manual, and the most important 
ones are related to section 7 (resource revocation and return):

https://www.lacnic.net/687/2/lacnic/7-resource-revocation-and-return

(look at the Spanish version, English seems not updated)

This proposal is not fully implemented yet, because it requires "automated" 
checking's for the policies, which will take some time to get fully 
implemented, and may not be possible to automate it 100%. So, for example 
ensuring that the IP addresses are actually (>50%) operating in the region, 
will be automatically detected.

If an organization get resources, say "we have a contract in a DC in Belize" to 
host them, and even they probe that to LANIC, but after obtaining the 
resources, they cancel the DC contract and use the resources outside the 
region, LACNIC didn't have a way to automatically verify it. Now with this 
policy, once fully implemented, they will have it and they will get alerts so 
they can manually do a verification, and if needed contact with the resource 
holder.

Of course, in case of non-compliance, section 7.1 of the policy, gives several 
chances, across 3 months, so the resource holder can either probe that there is 
compliance, or if they did a "mistake" they still have the opportunity to 
correct it.

In certain cases (such as fraud in documents), the RSA has precedence, and it 
can mean "no opportunity" to correct the situation, but still, the process may 
take 3 months, to give opportunity to the resource holder to probe it.
 
 
Regards,
Jordi
@jordipalet
 
 

El 22/1/21 9:32, "NANOG en nombre de Masataka Ohta" 
 escribió:

Eric Kuhnke wrote:

> Based on my cursory knowledge of offshore corporate registrations in
> Belize, Panama and the Cayman Islands, identifying those locations which
> are only mailboxes versus actual business office addresses should not be
> overly complicated or difficult.

A problem, however, is that, these days, one can perform
real business at remote locations without actual business
offices there.

Moreover, as page 28 of:


https://www.lacnic.net/innovaportal/file/1016/3/lacnic-fasciculo-infraestructura-internet-en.pdf

says:

REQUIREMENTS FOR OBTAINING AN IP ADDRESS BLOCK AND AN ASN

The organization must be legally incorporated in the LACNIC
service region.

incorporation is enough and physical presence is *NOT* required
by LACNIC.

Though there may be other reasons, the article explains:


https://krebsonsecurity.com/2021/01/ddos-guard-to-forfeit-internet-space-occupied-by-parler/

that are supposed to be given only to entities with a
physical presence in the region

Masataka Ohta

PS

I'm, anyway, glad that Ron now understand that "stealing" of IP
addresses through AFRINIC for money is a crime of fraud.





**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of 

Re: Ipv6 help

[JORDI PALET MARTINEZ via NANOG]

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 what you have 
behind. Many customers will just have one or two routers acting just as APs in 
a single bridged domain, others may have different subnets, etc.

This keeps the customer happy if they need to have a better WiFi, or whatever.

If you have just a dozen of deployments per month, I think the choice to buy a 
good Chinese hardware that already comes with OpenWRT, or your preferred retail 
CPE that allows to be reflashed with OpenWRT, is handy. That system will work 
for most of the customers, and if some customer want a "bigger" system, just 
provide the 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 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 people 
that contacted the same vendors and they told them "we could do it for the 
model you use as well". In some cases, they require a minimum volume per year 
(less than what you could expect. I've seen cases that start with just 500 
units per month).
> 
> But this only works if you contact them. The CPE vendors business model 
seems to be very "ISP" direct. I think the retail marked models, unfortunately, 
will take a bit more time.
> 
> A hint about some vendors: You may take a look at the co-authors in the 
RFC.

The whole point here is not that some vendors can support these features 
in a semi-custom firmware image that's specific to a particular ISP 
deployment - I know that's a possibility and have vendors willing to 
work with me on a much smaller volume than even what you've indicated - 
but rather what about customers who want to "upgrade" their router or, 
for whatever reason (and there are some very valid ones) want to provide 
their own.

Right now, it's essentially impossible for them to walk into a local 
retailer and walk out with a model that they know for sure will work 
with my network if I'm requiring e.g. 464XLAT for basic functionality. 
Even if they buy online and dive fairly deep into model documentation, 
it is still hard to come up with a model that they know will work, and 
the lack of documentation will limit their choice of models 
unnecessarily (i.e. there are probably some options that support the 
necessary functionality but don't advertise it in the slightest).

If someone wants me to provide them with a router, then of course I'll 
hand them one that I know works on my network.  That's easy since I have 
control over the selection of it (and have presumably done some testing) 
even if I don't have my own provider-customized firmware.

I'll point out that 500 new services (taking a new router) per month is 
not a particularly small provider.  It's not large, no, but it's also a 
lot bigger than many deployments are at least when they're new, and 
these are questions you have to essentially answer "up front" in many cases.
-- 
Brandon Martin



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Ipv6 help

[JORDI PALET MARTINEZ via NANOG]

> 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 even much 
cheaper. I know there is one open source implementation of NAT444. However, the 
number of NAT64 boxes that you need vs NAT444 is lower, and it will keep going 
lower as more and more services in Internet are IPv6 ready and those that suck 
more bw such as those video services, are already IPv6 and the increase in 
their traffic keeps going up.

>  as well as replace all CPE with CLAT capable devices (). I will also 
need to deal with the infancy period as I will GUARANTEE that the CPE will 
break badly and will create additional cost ().
>
> For NAT444 I just need to install NAT444 router(s) . No additional cost 
for CPE or added troubleshooting as the existing CPE is fully baked. Agreed 
that customers will need help with IPv6, but that will be required either way. 
Also, the customer maintains a native IPv4 service (all be it NATed) until IPv4 
does the dodo dance. In the end, the provider turns-off the NAT444 and disables 
IPv4 on their core, which has already been enabled for IPv6 when deploying 
dual-stack.

Well, you need to run the numbers on time, support and acquisition of
new revenue if you maintain NAT44, while the rest of the world (and your
competitors) are going as native IPv6 as they can.

You need to consider if it's worth taking the risk of being left behind,
or not.

[Jordi] This is the key. Make your numbers, each network is a different world. 
Some questions:
1) How much cost the NAT64 vs CGN ?
2) How much traffic will move to IPv6 if you use a CPE with CLAT ?
3) How many IPv4 addresses you need using CGN vs NAT64 ? That may be a lot of 
money.
4) How much you will save in helpdesk support because CGN ? (Sony today, 
tomorrow some others)
5) How much you can ask your customers to contribute to the replacement of the 
CPE (which cost you below 20-25 USD including logistic to ship within your 
country) while offering them a dual radio and better WiFi, "faster IPv6 
experience", less issues with apps because the CGN, faster LAN ports, future 
proof "New Internet" connection, better security (in the WiFi and a better 
firewall in the CPE), etc., etc. Is not that I like to use marketing, but it is 
a fact that if you don't do, sooner or later your competitor will do, and 
customers like to "upgrade" things (and everybody loves better WiFi). How many 
new customers you can get from the competitor because that marketing?

All that means less investment in the operator side, which you can use to fund 
the acquisition or update of CPEs (in some projects we updated the Mikrotik 
rubish to OpenWRT!).

My take on this. If you really want to keep using dual-stack, fine, but don't 
use CGN, you don't need that. It is way cheaper to just go into the transfers 
market and get more IPv4 addresses. Problem solved (including 1-4 above).

Either way, your customers will, at some point or other, show you what
will work :-).

For me, my time is very limited, particularly on this rock we call
earth. I could spend it maintaining a CGN, but I'd rather spend it
chasing down CPE vendors to get CLAT support, or bad-mouthing Sony to
get with the program. If I have to lose a few customers in the process,
so be it. If I run out of breath before I reach my goal, well, hopefully
the work done along the way will help the next idiot that sees things
the same way I do :-).

Mark.




**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Ipv6 help

[JORDI PALET MARTINEZ via NANOG]

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 the deployment 
was stopped.

So, in some places, where you will prefer a lower log volume, you can't do it. 
Or if you do it, it means you need more IPv4 addresses. Where is the balance? 
Up to each case.

Is not the same as NAT444, because in NAT444 you need to predefine the number 
of ports per customer. So there is an under-utilization of IPv4 addresses, or 
you are exposed to calls to the helpdesk to resolve problems due to the too low 
number of ports.

I've done some 464XLAT deplopyments, so I've "some" idea about what I'm talking 
about. Most of them small "pilots" (3.000 to 12.000 subscribers), right now 
doing one for 25.000.000 subscribers. Working without issues, just slowed down 
because the Covid-19 situation. I will prepare some slides about this project 
once allowed by my customer.


El 27/8/20 9:50, "Brian 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" 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 just wasted. If a 
customer needs more ports, will have troubles.

So this is actually necessary to lower log volume. Without that, logging 
would have to be per session and would require  excessive storage and long-term 
storage. With deterministic-NAT, we can all but eliminate logging as the 
external IP and port block is algorithmically reversible to the internal 
address and vice-versa.

> 
> This doesn't happen in NAT64.
> 
> Let's assume and operator that can get only a /22.

> 
> Let's make some numbers. If an average user uses 300 ports (from a public 
IP). When using 464XLAT, the number of users within the network, which in IPv4 
is behind NAT46, does not trigger that number of ports. Anyway, let's be 
pessimistic and assume they are quadruple 1,200 ports.
> 
> Approximately 80% of the traffic (2 years ago it was 75%, in many cases 
it is reaching 90-95%) is IPv6. After the 1,200 ports we only count 20% for 
IPv4, which is 240 ports.
> 
> Broadly speaking, if we assign NAT64 1,000 IPv4 addresses (assuming the 
operator needs 24 public IPv4 addresses for BGP and infrastructure, I have done 
it with much less - because 99% of the infrastructure can be IPv6-only or use 
private IPv4 for management), and that we use of each IPv4 address assigned to 
NAT64 only 64,511 ports (65,536-1,024), even knowing that they can all be used 
(may be you want to allocate some static IP/ports to some customers, etc.):
> 
> 1,000 x 64,511 / 240 = 268,795 subscribers. This is assuming all the 
subscribers are using all the ports, which typically is not the case.

So this is the same math for NAT444. The typical regional provider would be 
extremely happy getting this much mileage from a /22 block.

> 
> Now, if you have a NAT64 that tracks connections with a 5-tuple, then the 
number of external ports per user will be almost unlimited.

So we will have to log all sessions?

> 
> But also, this applies to the CLAT, which typically is doing (in CPEs) a 
stateful NAT44 (to a single private IPv4 address)+stateless NAT46. The NAT44 in 
iptables uses a 5-tuple for connection tracking, so the same external ports can 
be reused many times as the source address and destination address/port will be 
different. So in practical cases, the number of external ports only limits the 
number of parallel 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:
>> 
>> 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 and I can do the same over sub ratio under both 
circumstance. Tell me how the math is different.
> 
>> 2) It provides the customers as many ports they need (no a limited 
number of ports per customer).
> 

Re: Ipv6 help

[JORDI PALET MARTINEZ via NANOG]

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 just wasted. If a customer 
needs more ports, will have troubles.

This doesn't happen in NAT64.

Let's assume and operator that can get only a /22.

Let's make some numbers. If an average user uses 300 ports (from a public IP). 
When using 464XLAT, the number of users within the network, which in IPv4 is 
behind NAT46, does not trigger that number of ports. Anyway, let's be 
pessimistic and assume they are quadruple 1,200 ports.

Approximately 80% of the traffic (2 years ago it was 75%, in many cases it is 
reaching 90-95%) is IPv6. After the 1,200 ports we only count 20% for IPv4, 
which is 240 ports.

Broadly speaking, if we assign NAT64 1,000 IPv4 addresses (assuming the 
operator needs 24 public IPv4 addresses for BGP and infrastructure, I have done 
it with much less - because 99% of the infrastructure can be IPv6-only or use 
private IPv4 for management), and that we use of each IPv4 address assigned to 
NAT64 only 64,511 ports (65,536-1,024), even knowing that they can all be used 
(may be you want to allocate some static IP/ports to some customers, etc.):

1,000 x 64,511 / 240 = 268,795 subscribers. This is assuming all the 
subscribers are using all the ports, which typically is not the case.

Now, if you have a NAT64 that tracks connections with a 5-tuple, then the 
number of external ports per user will be almost unlimited.

But also, this applies to the CLAT, which typically is doing (in CPEs) a 
stateful NAT44 (to a single private IPv4 address)+stateless NAT46. The NAT44 in 
iptables uses a 5-tuple for connection tracking, so the same external ports can 
be reused many times as the source address and destination address/port will be 
different. So in practical cases, the number of external ports only limits the 
number of parallel 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:
> 
> 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 and I can do the same over sub ratio under both 
circumstance. Tell me how the math is different.

> 2) It provides the customers as many ports they need (no a limited number 
of ports per customer).

See response to answer 1

> 3) It is not blocked by PSN (don't know why because don't know how the 
games have problems with CGN).

Interesting, but I’m not sure how any over-loaded NAT translation would 
look different from the external system. Since you cannot explain it, it’s hard 
to discuss it.

> 
> You could share among an *almost unlimited* number of subscribers an 
small IPv4 block (even just a /22).

The math would be the same as a CGN, so I do not see how this is any less 
or more useful. It does, however, require CPE capability that appears lacking 
and NAT444 does not. 

> 
> Regards,
> Jordi
> @jordipalet
> 
> 
> 
> El 26/8/20 22:31, "Brian Johnson"  escribió:
> 
>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 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 OS and/or PSN change, all the affected games, will need to 
be adjusted.
>> 
>> 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 
464XLAT instead of CGN ... which resolves the problem.
>> 
>> A massive campaing could work ...
>> 
>> 
>> El 26/8/20 22:08, "NANOG en nombre de surfer" 
 escribió:
>> 
>> 
>> 
>>   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,

Re: Ipv6 help

[JORDI PALET MARTINEZ via NANOG]

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 difference today.

NAT64/DNS64 was the original solution.

464XLAT is the improved approach.

See:

https://tools.ietf.org/id/draft-ietf-v6ops-nat64-deployment-04.html

Mark.



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Ipv6 help

[JORDI PALET MARTINEZ via NANOG]

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).

You could share among an *almost unlimited* number of subscribers an small IPv4 
block (even just a /22).

Regards,
Jordi
@jordipalet
 
 

El 26/8/20 22:31, "Brian Johnson"  escribió:

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 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 OS and/or PSN change, all the affected games, will need to 
be adjusted.
> 
> 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 
464XLAT instead of CGN ... which resolves the problem.
> 
> A massive campaing could work ...
> 
> 
> El 26/8/20 22:08, "NANOG en nombre de surfer" 
 escribió:
> 
> 
> 
>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 as PSN accounted for about 10-20% of helpdesk 
calls. I don't understand why its seemingly impossible for them to implement 
ipv6 as almost everything I have deployed with CGN is dual stack V6.
> 
>On 8/26/20 9:30 AM, Mark Tinka wrote:
>> We'll have to be creative with how we pressure them into getting serious
>> about IPv6.
> 
> 
>Do those guys attend NANOG meetings?   >;-)   (evil smile)
> 
>scott
> 
> 
> 
> **
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
> 
> This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.
> 
> 
> 




**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Ipv6 help

[JORDI PALET MARTINEZ via NANOG]

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 OS and/or PSN change, all the affected games, will need to be 
adjusted.

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 
464XLAT instead of CGN ... which resolves the problem.

A massive campaing could work ...


El 26/8/20 22:08, "NANOG en nombre de surfer" 
 escribió:



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 as PSN accounted for about 10-20% of helpdesk 
calls. I don't understand why its seemingly impossible for them to implement 
ipv6 as almost everything I have deployed with CGN is dual stack V6.

On 8/26/20 9:30 AM, Mark Tinka wrote:
> We'll have to be creative with how we pressure them into getting serious
> about IPv6.


Do those guys attend NANOG meetings?   >;-)   (evil smile)

scott



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Ipv6 help

[JORDI PALET MARTINEZ via NANOG]

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 know - did for IPv6-only in iOS)

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*.

Sony has  IPv6  in other products, but of course, it is a big company, many 
times it happens they are "disconnected" folks there.

El 26/8/20 20:16, "NANOG en nombre de Brian Johnson" 
 escribió:

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:
> 
>> 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, the PS5 might ship with RIPv2.
> 
> Mark.




**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Ipv6 help

[JORDI PALET MARTINEZ via NANOG]

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 people that 
contacted the same vendors and they told them "we could do it for the model you 
use as well". In some cases, they require a minimum volume per year (less than 
what you could expect. I've seen cases that start with just 500 units per 
month).

But this only works if you contact them. The CPE vendors business model seems 
to be very "ISP" direct. I think the retail marked models, unfortunately, will 
take a bit more time.

A hint about some vendors: You may take a look at the co-authors in the RFC.



El 26/8/20 18:30, "NANOG en nombre de Brandon 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 in the US (or even broader 
North American) retail market that has "RFC8585" printed anywhere on the 
outside of the box or even in the documentation one might actually 
consult pre-purchase?  I would love to evaluate it (or, even better, a 
few of them) to ensure I'm compatible on the provider side with how the 
equipment makers have interpreted the RFC!  Then I can also have some 
specific models to direct people toward along with "Or just look for 
'RFC8585' on the box".

But, right now, I am aware of none.
-- 
Brandon Martin



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Ipv6 help

[JORDI PALET MARTINEZ via NANOG]

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 situation. It is not 
something that happens "immediately" you have a CGN, but I'n aware of several 
customers that got into that situation.

Not just Sony, other services are doing the same. I heard about OpenDNS cases 
as well. 
 

El 26/8/20 16:42, "Brian Johnson"  escribió:

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 AM, JORDI PALET MARTINEZ via NANOG 
 wrote:
> 
> 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 actually becoming 
higher and you will need sooner or later, to buy more IPv4 addresses once all 
them are black-listed.
> 
> I've not heard about anyone that has been able to convince Sony to clean 
their addresses from the PSN CGN black-list.
> 
> 
> 
> El 26/8/20 9:07, "Mark Andrews"  escribió:
> 
>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: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 need more IPv4 addresses in CGN than in NAT64 and 
further to that, in CGN, your IPv4 pools sooner or later become blocked by PSN 
(unless you don't have gammers among your customers).
>> 
>> El 25/8/20 22:42, "NANOG en nombre de Brian Johnson" 
 escribió:
>> 
>>   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 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, 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 modern features and can be configured via standard means.
>>> 
>>> It would be nice if the consumer router industry could get its 
collective act together and at least come up with some easy-ish to understand 
feature support table that customers can match up with their service provider's 
list of needs.  The status quo of a list of devices that work right (which is 
of course often staggeringly short if you're doing any of these modern 
transition mechanisms) that needs constant updating and may not be easily 
available is not ideal.
>>> 
>>> Heck just having a real, complete list of supported features on the 
model support page on their website would be an improvement...
>>> -- 
>>> Brandon Martin
>> 
>> 
>> 
>> 
>> **
>> IPv4 is over
>> Are you ready for the new Internet ?
>> http://www.theipv6company.com
>> The IPv6 Company
>> 
>> This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a crimina

Re: Ipv6 help

[JORDI PALET MARTINEZ via NANOG]

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 actually becoming higher 
and you will need sooner or later, to buy more IPv4 addresses once all them are 
black-listed.

I've not heard about anyone that has been able to convince Sony to clean their 
addresses from the PSN CGN black-list.
 
 

El 26/8/20 9:07, "Mark Andrews"  escribió:

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: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 need more IPv4 addresses in CGN than in NAT64 and 
further to that, in CGN, your IPv4 pools sooner or later become blocked by PSN 
(unless you don't have gammers among your customers).
> 
> El 25/8/20 22:42, "NANOG en nombre de Brian Johnson" 
 escribió:
> 
>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 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, 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 modern features and can be configured via standard means.
>> 
>> It would be nice if the consumer router industry could get its 
collective act together and at least come up with some easy-ish to understand 
feature support table that customers can match up with their service provider's 
list of needs.  The status quo of a list of devices that work right (which is 
of course often staggeringly short if you're doing any of these modern 
transition mechanisms) that needs constant updating and may not be easily 
available is not ideal.
>> 
>> Heck just having a real, complete list of supported features on the 
model support page on their website would be an improvement...
>> -- 
>> Brandon Martin
> 
> 
> 
> 
> **
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
> 
> This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.
> 
> 
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org




**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Ipv6 help

[JORDI PALET MARTINEZ via NANOG]

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 sooner or later become blocked by PSN (unless 
you don't have gammers among your customers).

El 25/8/20 22:42, "NANOG en nombre de Brian Johnson" 
 escribió:

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 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, 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 modern features and can be configured via standard means.
> 
> It would be nice if the consumer router industry could get its collective 
act together and at least come up with some easy-ish to understand feature 
support table that customers can match up with their service provider's list of 
needs.  The status quo of a list of devices that work right (which is of course 
often staggeringly short if you're doing any of these modern transition 
mechanisms) that needs constant updating and may not be easily available is not 
ideal.
> 
> Heck just having a real, complete list of supported features on the model 
support page on their website would be an improvement...
> -- 
> Brandon Martin




**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Ipv6 help

[JORDI PALET MARTINEZ via NANOG]

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 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, 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 modern features and can be 
configured via standard means.

It would be nice if the consumer router industry could get its 
collective act together and at least come up with some easy-ish to 
understand feature support table that customers can match up with their 
service provider's list of needs.  The status quo of a list of devices 
that work right (which is of course often staggeringly short if you're 
doing any of these modern transition mechanisms) that needs constant 
updating and may not be easily available is not ideal.

Heck just having a real, complete list of supported features on the 
model support page on their website would be an improvement...
-- 
Brandon Martin



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Ipv6 help

[JORDI PALET MARTINEZ via NANOG]

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" 
 escribió:

 

I just make it easy and don't support the client using their own router. 
Doesn't work? unplug your router and use mine.

 

That eliminates a lot of problems.



-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-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 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 it natively, at least according to their 
description. The only way I found to enable CLAT support is to flash those 
devices with OpenWRT, which is not really an option when you are giving away 
those tiny boxes to residential clients when they sign up with you.

So for now we're stuck with CGNAT. :( I do hope I'm wrong and you can tell me 
which device works with 646XLAT out of the box. And hopefully it's something 
TRENDnet's.

-- 
Roman V Tatarnikov
https://linkedin.com/in/rtatarnikov
W: 310 929 2607 | C: 805 746 2886

 



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Ipv6 help

[JORDI PALET MARTINEZ via NANOG]

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 the CPE itself, but the 
logistics or actually replacing it.

 

But since a few years, when you put the cost of CGN + IPv4 addresses (or 
actually just buying “more” IPv4 addresses and offering dual-stack without CGN 
– because the CGN will require you to swap the IPv4 pools just because Sony PSN 
is continuously blacklisting you) versus the lower number of IPv4 addresses 
needed for 464XLAT and lower number of NAT64 boxes, in  most cases, it 
compensates for the cost of replacing the CPEs, and you have additional 
marketing advantages that you can sell  and even charge for them, such as “Now 
we give you a box with Gigabit ports, greener for the planet -  lower power 
consumption, better WiFi, better security, ready for the future with IPv6,  
IPv6 is faster with your social networks, youtube and many websites, etc., etc.)

 

Regards,

Jordi

@jordipalet

 

 

 

El 25/8/20 19:46, "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 I’m still waiting for a single response. I guess they have 
other priorities than IPv6 at all.

 

--- I can buy 10-15 USD CPEs directly from China, with OpenWRT already 
installed, which have exactly the same design as the Mikrotik (same SoC, same 
number of LAN/WAN ports, etc.).


You're probably right. But if Mikrotik are having great success at meeting the 
budget of most providers and customers, perhaps a different approach is worth 
considering. Not that you haven't done you utmost best, as I know you to always 
do, Jordi.

I wish I didn't have to deal with Mikrotik either, but reality is far more 
different. Heck, I even own and use one myself, for my home FTTH connection :-).

Mark.





**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Ipv6 help

[JORDI PALET MARTINEZ via NANOG]

> 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 that hard.

 

--- NDAs

 

 

> 

> Mikrotik is the worst vendor for anything related to transition. They only 
> run pure dual-stack, and even on that, they are really bad. They even use a 
> broken naming convention against the standards. They use 6to4 instead of 
> 6in4, which get a lot of folks confused ...

 

Agreed. But they are just about the only mass CPE vendor that ships code

to add capability, vs. the traditional ones who require you to buy a new

router every year just to get new features.

 

That and being so cheap, you can't talk customers out of preferring to

buy them. It's not a great situation, but hey... supply & demand.

 

 

--- 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 guess they have 
other priorities than IPv6 at all.

 

--- I can buy 10-15 USD CPEs directly from China, with OpenWRT already 
installed, which have exactly the same design as the Mikrotik (same SoC, same 
number of LAN/WAN ports, etc.).



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Ipv6 help

[JORDI PALET MARTINEZ via NANOG]

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 anything related to transition. They only run 
pure dual-stack, and even on that, they are really bad. They even use a broken 
naming convention against the standards. They use 6to4 instead of 6in4, which 
get a lot of folks confused ...

Regards,
Jordi
@jordipalet
 
 

El 25/8/20 18:15, "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, 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 are waiting for some 
customers to ask for it, the CLAT. I've been doing this for many customers. 
Sometimes, they only do under request, same as many other firmware features.

If CLAT support were wide-spread, it would quickly accelerate the
deployment of IPv6 in broadband applications.

Not even Mikrotik are doing it, and they pretty much own the FTTH CPE
market in many countries.

If only CPE's could run Android, or Windows :-).

Mark.



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Ipv6 help

[JORDI PALET MARTINEZ via NANOG]

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 are waiting for some customers 
to ask for it, the CLAT. I've been doing this for many customers. Sometimes, 
they only do under request, same as many other firmware features.

Regards,
Jordi
@jordipalet
 
 

El 24/8/20 16:32, "NANOG en nombre de Roman Tatarnikov" 
 escribió:

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 it natively, at least according to their 
description. The only way I found to enable CLAT support is to flash those 
devices with OpenWRT, which is not really an option when you are giving away 
those tiny boxes to residential clients when they sign up with you.

So for now we're stuck with CGNAT. :( I do hope I'm wrong and you can tell 
me which device works with 646XLAT out of the box. And hopefully it's something 
TRENDnet's.

-- 
Roman V Tatarnikov
https://linkedin.com/in/rtatarnikov
W: 310 929 2607 | C: 805 746 2886



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Compromized modems in Thai IP Space

[JORDI PALET MARTINEZ via NANOG]

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/uploads/2018/08/prop-125-v001.txt), which was 
adopted long time ago?

 You could also try the APNIC Talk mailing list.
 
Regards,
Jordi
@jordipalet
 
 

El 11/8/20 15:10, "NANOG en nombre de Alexander Maassen" 
 escribió:

Hello folks,

Before you shoot me with 'wrong mailing list' replies, believe me, I
tried, THNOG is dead, APNIC ain't responding either and the ISP's over
there don't seem to care much. And I've been looking at this situation for
over 2 years now since first incident. I simply hope that with the
contacts you folks have due to your professions to be able to help.

So, I came across this botnet which decided to pick my IRC network as
control center, and I have been digging into them. It turns out that in
Thailand, people can easily get cloned modems in order to internet for
'free', it simply boils down to mac cloning, so let me spare you the
details. The problem is that these modems also carry a digital STD in the
form of additional botnet code, allowing the controllers to do, well,
botnet stuff.

I disabled their ability to control by glining everything on join to the
control channel, and since I am maintainer of DroneBL, add them to the
blacklist. Doing that for 2+ years now. The amount of removal requests
because people no longer are able to play on cncnet is amazing.

My question here kinda is, how to permanently get rid of this evil in an
effective way, and who to contact? (yes, I tried to get through to NOC's
of the affected providers), or could perhaps someone be so nice to use one
of their contacts in Thailand to speed things up?

Kind regards,

Alexander Maassen
Maintainer DroneBL




**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: MAP-T in production

[JORDI PALET MARTINEZ via NANOG]

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 customers, 
so help desk cost.

If you have a network with both cellular and wireline, clearly 464XLAT is the 
only solution to have a single transition mechanism.

I've been working a lot with CPE providers (see RFC8585), and I believe that 
464XLAT is getting more support.

I'm now involve in a 25.000.000 subscribers 464XLAT deployment project (DSL, 
GPON and cellular) ... just slowed down because the Covid-19 situation,  but a 
small test best passed all the "evil" testing that we tried.

See also RFC8683.

Regards,
Jordi
@jordipalet
 
 

El 22/7/20 23:32, "NANOG en nombre de Brandon Martin" 
 escribió:

On 7/22/20 5:15 PM, Brian Johnson wrote:
> Has anyone implemented a MAP-T solution in production? I am looking for 
feedback on this as a deployment strategy for an IPv6 only core design. My 
concern is MAP-T CE stability and overhead on the network. The BR will have to 
do overloaded NAT anyway to access IPv4 only resources. The idea being that 
when IPv4 is no longer needed, this will be a quicker “clean-up” project than a 
dual-stack solution.
> 
> I have reviewed Jordan Gotlieb’s presentation from Charter and would love 
to hear if this is still in use at Charter or if was ever fully implemented and 
the experiences)
> 
> I’d love any real life examples and success/failure stories.

I'd love to hear about this (or MAP-E, or lw4o6) as well especially with 
regard to CPE support.  My preferred CPE vendor keeps punting on it 
(though they do claim to support 464XLAT), and I'd really like something 
to point them to that will show them it's a "real thing".  Getting rid 
of state at the CGN as is (or can be, at least) necessary with 464XLAT 
seems like a real boon while placing minimal additional burden on the CPE.

-- 
Brandon Martin



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: MAP-T in production

[JORDI PALET MARTINEZ via NANOG]

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 is that the one with a bigger deployment is 464XLAT (hundreds of millions 
of subscribers), which exceeds by far what has been done with all the other 
transitions technologies all together. The funny thing is that 464XLAT is just 
“informational” :-)

 

Regards,

Jordi

@jordipalet

 

 

 

El 22/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 IPv4/IPv6 translation, as described in RFCs 4164, 4166, 4167, 
and 7915.

Sent from my iPad




On Jul 22, 2020, at 2:16 PM, Brian Johnson  wrote:

Has anyone implemented a MAP-T solution in production? I am looking for 
feedback on this as a deployment strategy for an IPv6 only core design. My 
concern is MAP-T CE stability and overhead on the network. The BR will have to 
do overloaded NAT anyway to access IPv4 only resources. The idea being that 
when IPv4 is no longer needed, this will be a quicker “clean-up” project than a 
dual-stack solution.

I have reviewed Jordan Gotlieb’s presentation from Charter and would love to 
hear if this is still in use at Charter or if was ever fully implemented and 
the experiences)

I’d love any real life examples and success/failure stories.

Thanks.

- Brian



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: CGNAT Opensource with support to BPA, EIM/EIF, UPnP-PCP

[JORDI PALET MARTINEZ via NANOG]

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 down by the Covid-19).

 

Regards,

Jordi

@jordipalet

 

 

 

El 7/7/20 18:44, "NANOG en nombre de Douglas Fischer" 
 escribió:

 

We are looking for a CGNAT solution open source based.

Yep, I know that basic CGNAT can be done with iptables / nftables, or PF / 
IPFILTER / IPFW.

But I only know Open Source CGNAT recipes with predefined public-ports <-> 
private IPs mapping.

What It brings two types of issues:
A - The need to overprovision the number of private IPs (Considering Multiple 
BNGs behind the CGN).
B - The inability of those basic recipes to deal with incoming auxiliary 
connections of p2p protocols (mostly used by games).

Te market solutions that I've dealt with solves those issues beautifully.
a - Bulk-Port Allocation - BPA, avoid the need overprovisioning private address 
that is not being used, and give us an excellent rate between public IPv4 
Address vs Private IP Address.
b - The support of a framework of protocols(Ex.: UPnP, PCP, EIM/EIF, NAT-PMP, 
etc...) ensure an acceptable quality of experience to end-users.

But, the market solution brings also some down-sides...
- The cost, evidently.
- The need for detouring the traffic that doesn't need CGNAT(Internal CDNs, 
Internal Servers, etc), to stay on the license limits of those boxes, sometimes 
brings some issues.

So, I and some friends are(for a long time) looking for an OpenSource solution 
that can give us something near what the market solutions give.

Any of you guys ave some suggestions for that?


P.S.: Yes, I know that IPv6 is the only real solution for that, but until 
there, our customers still want to access a lot os p2p content(mostly audio in 
game rooms, sip calls, and things like that.)

P.S.2: Yes, I also know that 464 could be a good possibility, but is not 
possible in this scenario.

 

-- 

Douglas Fernando Fischer
Engº de Controle e Automação



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: RIPE NCC Executive Board election

[JORDI PALET MARTINEZ via NANOG]

I’m a very transparent guy, nothing to hide about how much I do for the 
community, including voluntary work for many folks that need and want to 
implement IPv6.

 

Probably that explains it!

 

El 13/5/20 22:32, "Elad Cohen"  escribió:

 

Regards,

Jordi
"The IPv6 Company"

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 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?

 

Instead, IPv6 is working for everyone that invest just a little bit of effort, 
in the only credible long-term solution.

 

Of course, like in any aspect of our life, always some people will believe that 
they can keep using legacy tools, I still see some people using abacus instead 
of the “calc.app”, it is nice, just for fun, but is not smart neither 
productive.

 

It is matter of what the world needs.

 

Regards,

Jordi

@jordipalet

 

 

 

El 13/5/20 21:58, "NANOG en nombre de Elad Cohen"  escribió:

 

Your home ISP will support IPv4+ packets exactly as it is now, because IPv4+ is 
based on the exact current IPv4 packet format. With the needed roundtable - 
IPv4+ will be deployed in the whole internet and fast.

From: NANOG  on behalf of David Hubbard 

Sent: Wednesday, May 13, 2020 10:44 PM
To: NANOG list 
Subject: Re: RIPE NCC Executive Board election 

 

It just keeps getting dumber by the minute.  My home ISP hasn’t even updated 
firmware to one that supports v6, but yeah, they’re surely going to update to 
your Frankenstein ipv4 because you’re going to give them a taste of addresses 
from the nightmare pool that will reach even less of the internet than v6.

 

From: NANOG  on behalf of Elad Cohen 
Date: Wednesday, May 13, 2020 at 3:41 PM
To: Mikael Abrahamsson 
Cc: NANOG list 
Subject: Re: RIPE NCC Executive Board election

 



Do you realise that this means you're requiring changing *every* 
socket-speaking application in the world?



Every internet host that will want to speak IPv4+ , will have an update (for 
example through the operating systems automatic updates mechanisms)

 

 



It's taken us decades to get applications to use the new struct to support 
IPv6+IPv4, resetting the timer back to 0 and starting over does not help 
deployment. It just kicks it another 20 years down the line.



I wrote about the usage of a roundtable in order to implement everything fast 
(the roundtable will include one representative from each of the operating 
system vendors, one representative from each of the routing equipment 
manufacturers and one representative from each of the 5 RIR's), if I will be 
elected to RIPE board I will do everything in my power so this roundtable will 
be formed fast and that the needed updates will be created fast. Each party in 
the roundtable will receive an amount of free IPv4 addresses from the new IPv4+ 
pool, and each ASN will also receive for example a /21 , home-routers and 
home-modems will not be needed to be updated and they will support IPv4+.

 

 



You're just inventing yet another incompatible standard and you have to 
touch everything, DHCP, DNS all applications etc.



There is an adjustment to IPv4+ that the format of addresses will not be 
[0-655365].[0-655365]v4 - but it will be [256-511].[0-255].[0-255].[0-255]

So IPv4+ addresses will be in the format of IPv4 addresses - it will end-user 
adoption of IPv4+ easier and also integration in the applicative layer easier 
(as application developers will only need to set that the first number can be 
higher instead to support a new format of [0-655365].[0-655365]v4 )

 

 

From: Mikael Abrahamsson 
Sent: Wednesday, May 13, 2020 10:22 PM
To: Elad Cohen 
Cc: Brielle ; NANOG list 
Subject: Re: RIPE NCC Executive Board election 

 

On Wed, 13 May 2020, Elad Cohen wrote:

> LOL funny seeing you changing your mind by 180 degrees when someone you 
> know in the community writing to you the exact same thing.

"In addition, the sockets API should be extended to support IPxl with a 
new socket domain PF_IPXL which is identical to PF_INET in every respect 
save that the IP addresses are 8 bytes long instead of 4."

Do you realise that this means you're requiring changing *every* 
socket-speaking application in the world?

It's taken us decades to get applications to use the new struct to support 
IPv6+IPv4, resetting the timer back to 0 and starting over does not help 
deployment. It just kicks it another 20 years down the line.

You're just inventing yet another incompatible standard and you have to 
touch everything, DHCP, DNS all applications etc.

-- 

Re: RIPE NCC Executive Board election

[JORDI PALET MARTINEZ via NANOG]

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?

 

Instead, IPv6 is working for everyone that invest just a little bit of effort, 
in the only credible long-term solution.

 

Of course, like in any aspect of our life, always some people will believe that 
they can keep using legacy tools, I still see some people using abacus instead 
of the “calc.app”, it is nice, just for fun, but is not smart neither 
productive.

 

It is matter of what the world needs.

 

Regards,

Jordi

@jordipalet

 

 

 

El 13/5/20 21:58, "NANOG en nombre de Elad Cohen"  escribió:

 

Your home ISP will support IPv4+ packets exactly as it is now, because IPv4+ is 
based on the exact current IPv4 packet format. With the needed roundtable - 
IPv4+ will be deployed in the whole internet and fast.

From: NANOG  on behalf of David Hubbard 

Sent: Wednesday, May 13, 2020 10:44 PM
To: NANOG list 
Subject: Re: RIPE NCC Executive Board election 

 

It just keeps getting dumber by the minute.  My home ISP hasn’t even updated 
firmware to one that supports v6, but yeah, they’re surely going to update to 
your Frankenstein ipv4 because you’re going to give them a taste of addresses 
from the nightmare pool that will reach even less of the internet than v6.

 

From: NANOG  on behalf of Elad Cohen 
Date: Wednesday, May 13, 2020 at 3:41 PM
To: Mikael Abrahamsson 
Cc: NANOG list 
Subject: Re: RIPE NCC Executive Board election

 



Do you realise that this means you're requiring changing *every* 
socket-speaking application in the world?



Every internet host that will want to speak IPv4+ , will have an update (for 
example through the operating systems automatic updates mechanisms)

 

 



It's taken us decades to get applications to use the new struct to support 
IPv6+IPv4, resetting the timer back to 0 and starting over does not help 
deployment. It just kicks it another 20 years down the line.



I wrote about the usage of a roundtable in order to implement everything fast 
(the roundtable will include one representative from each of the operating 
system vendors, one representative from each of the routing equipment 
manufacturers and one representative from each of the 5 RIR's), if I will be 
elected to RIPE board I will do everything in my power so this roundtable will 
be formed fast and that the needed updates will be created fast. Each party in 
the roundtable will receive an amount of free IPv4 addresses from the new IPv4+ 
pool, and each ASN will also receive for example a /21 , home-routers and 
home-modems will not be needed to be updated and they will support IPv4+.

 

 



You're just inventing yet another incompatible standard and you have to 
touch everything, DHCP, DNS all applications etc.



There is an adjustment to IPv4+ that the format of addresses will not be 
[0-655365].[0-655365]v4 - but it will be [256-511].[0-255].[0-255].[0-255]

So IPv4+ addresses will be in the format of IPv4 addresses - it will end-user 
adoption of IPv4+ easier and also integration in the applicative layer easier 
(as application developers will only need to set that the first number can be 
higher instead to support a new format of [0-655365].[0-655365]v4 )

 

 

From: Mikael Abrahamsson 
Sent: Wednesday, May 13, 2020 10:22 PM
To: Elad Cohen 
Cc: Brielle ; NANOG list 
Subject: Re: RIPE NCC Executive Board election 

 

On Wed, 13 May 2020, Elad Cohen wrote:

> LOL funny seeing you changing your mind by 180 degrees when someone you 
> know in the community writing to you the exact same thing.

"In addition, the sockets API should be extended to support IPxl with a 
new socket domain PF_IPXL which is identical to PF_INET in every respect 
save that the IP addresses are 8 bytes long instead of 4."

Do you realise that this means you're requiring changing *every* 
socket-speaking application in the world?

It's taken us decades to get applications to use the new struct to support 
IPv6+IPv4, resetting the timer back to 0 and starting over does not help 
deployment. It just kicks it another 20 years down the line.

You're just inventing yet another incompatible standard and you have to 
touch everything, DHCP, DNS all applications etc.

-- 
Mikael Abrahamssonemail: swm...@swm.pp.se



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is 

Re: RIPE NCC Executive Board election

[JORDI PALET MARTINEZ via NANOG]

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 candidates and links to their bios:

https://www.ripe.net/participate/meetings/gm/meetings/may-2020/confirmed-candidates



Regards,
Jordi
@jordipalet
 
 

El 13/5/20 11:52, "NANOG en nombre de Ronald F. Guilmette" 
 escribió:

Many of you here may be dues-paying members of both ARIN and RIPE.

Those of you who are may wish to be aware of the fact that there will
be an election held on (I believe) May 14th, just a day or two from
now, for three open RIPE NCC Executive Board seats.

I have it on good authority that one of the candidates running for
the open RIPE NCC board seats in this election has hired legal
counsel in South Africa, and that said legal counsel has then
proceeded to threaten various officials of the City of Cape Town,
South Africa with possible legal action if they do not relinquish
to him their rights in and title to the 165.25.0.0/16 block, a
block that all historical records, including even ARIN "WhoWas"
historical records show, clearly and unambiguously, has been
legally registered to the City of Cape Town for over twenty years.
(I am assured that at no time did the City of Cape Town ever sell,
trade, or barter away their rights to this valuable IPv4 block,
and that they are defending themselves, as best as they can, against
this attempt to extort them out of their rightful prooperty.)

Where I come from, this kind of thing is called barratry, but you
be the judge.

In any case, prior to the RIPE election, I wanted to let you all
know these facts about the candidate in question, as well as a
number of additional startling facts relating to the people who
nominated this candidate for a RIPE NCC Executive board seat, as
documented by my friend, South African journalist Jan Vermeulen:


https://mybroadband.co.za/news/internet/350973-man-connected-to-african-ip-address-heist-running-for-board-position-at-european-ip-address-organisation.html

I could go into more detail about many of the nominators mentioned
in the above article, but I don't want to make this email too long,
so I'll await some explict request for that additional info.  For now
it should suffice to make at least some of the basic facts more widely
available, a task which is accomplished just by sharing the above link,
IMHO.


Regards,
rfg


P.S.  I have been specifically and explicitly enjoined and constrained
from posting here anything at all that might smack of being either
partisan or of an even vaguely "political" nature, and thus, I will
refrain from doing so.  I would be remiss hoever if I did not at least
note in passing that history records that in times such as these, when
people of good character and good intent are, as they rightly should be,
focused on the health and safety of themselves, their loved ones, and
their professional collegues, and when the gaze of the world is elsewhere,
persons of less than honorable intent reach for power and, with unfortunate
regularity, obtain it.

I cannot and do not ask that those of you who have been saddled with
personal or local crises during this sad time turn away from those
responsibilities to give attention to matters of Internet governance,
however urgent those may appear at the moment.  For all of us, our first-
order duty lies nearby, with family, friends, and collegues.  But for
those of you who still have a few cycles to spare, I do ask that you
consider carefully the newfound and critical importance of this tool,
this Internet, in the lives of so many millions, all around the world,
and the self-evident risks of its governance being handed over, by default
or otherwise, to persons with an interest only in what is best for them
personally, to the exclusion of all else.

P.P.S.  I would be posting this info and the above link also to the
very relevant RIPE members-discuss mailing list, but as I am not a
due-paying member of RIPE, I have no ability to do so.  Separately,
due in no small part to the candidate's own recent and manifest on-list
transgressions on that very list, that list has recently been switched
to a heavy-handed moderation, under which, it seems, even discussion of
the pros and cons of candidates in the upcoming RIPE NCC Executive Board
election are now categorized as "too controversial" and thus, themselves,
are now entirely off-limits.

I cannot help but be reminded of a catch-phrase that I saw somewhere,
not too long ago:

 "Democracy dies in darkness."
  

Re: CGNAT Solutions

[JORDI PALET MARTINEZ via NANOG]

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 Brandon Martin  wrote:

On 4/29/20 10:12 PM, William Herrin wrote:
>> What allows them to work with v6 in such an efficient manner?
> A piece of client software is installed on every phone that presents
> an IPv4 address to the phone and then translates packets to IPv6 for
> relay over the network. This works because T-Mobile has considerable
> control over the phone.

FWIW, this software component (the CLAT) can also be on the CPE edge 
router which many ISPs either control outright these days or at least 
can influence.
-- 
Brandon Martin

 

Correct, and T-Mobile uses this 464xlat approach for their home broadband 
product as well

 

 



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: CGNAT Solutions

[JORDI PALET MARTINEZ via NANOG]

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 it already for smaller ISPs, but the size of this project is more 
interesting to better demonstrate that it just works.

 

I plan to do a presentation when the information can be made public … bit delay 
because the Covid-19 confinement.

 

Regards,

Jordi

@jordipalet

 

 

 

El 28/4/20 21:15, "NANOG en nombre de John Alcock"  escribió:

 

Afternoon,

 

I run a small ISP in Tennessee.  COVID has forced a lot of people to work from 
home.  I am starting to run low on IP's and need to consider CGNAT.

 

I do have IPV6 space, but we all know that until we force everyone to move to 
IPV6, we need to keep IPV4 up and running.

 

I could buy more space, but I am really wondering if that is the best option.  
It is expensive. I know CGNAT devices are expensive as well, but it looks like 
I could stretch it out a bit.

 

My thinking is to convert about 50% of my subscribers to CGNAT.

 

I am interested in vendors or devices you have used in the past.  I already 
know about the pitfalls many of my subscribers will have with CGNAT such as 
VPN's, Gamers, etc.

 

What are your thoughts on CGNAT vendors?  

 

A10Networks

F5Networks

Others?



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: MAP-E

[JORDI PALET MARTINEZ via NANOG]

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
> explains how each major transition technology works, and the pros and
> cons of each. There must be one, but it's hard to cover the major
> options in an hour.

Actually your post is better than a presentation. I was quite
surprised at the adoption rate of DS-Lite. There must be some pretty
decent B4 implementations with that many operators deployed.

Even though the spreadsheet is small sample size, there isn't much
DS-lite deployment in the US.

So from 10k feet, MAP-E is basically the same thing as DS-Lite except
for the location of the NAT?




**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: MAP-E

[JORDI PALET MARTINEZ via NANOG]

The point is that the situation is that same for *all* the transition 
mechanisms, except DS-Lite, which was the first one.

Even lw4o6, which is a better choice than DS-LITE is not well supported even 
the CE is basically doing the same!

I've a recent presentation in the last APNIC meeting, which is also recorded in 
youtube:

https://conference.apnic.net/47/program/schedule/#/day/11/ipv4aas-tutorial-and-hands-on---part-1


Regards,
Jordi
@jordipalet
 
 

El 8/8/19 22:21, "NANOG en nombre de Lee Howard"  escribió:


On 8/2/19 11:39 AM, Jay Hanke wrote:
> Is there a summary presentation someplace laying out the options that
> are active in the wild with some deployment stats?

I can't think of a public presentation off the top of my head that 
explains how each major transition technology works, and the pros and 
cons of each. There must be one, but it's hard to cover the major 
options in an hour.

If you want to know who is using any given transition technology, 
there's this crowd-sourced list:


https://docs.google.com/spreadsheets/d/1ksOoWOaRdRyjZnjLSikHf4O5L1OUTNOO_7NK9vcVApc/edit#gid=0

Very brief summary of options:

NAT444. Your basic NAT, plus NAT again. You really need to deploy IPv6, 
too, or all your traffic will go through a translator (everything else 
below assumes native IPv6 is deployed). State information can get 
expensive. Well understood.

Dual-stack Lite. CPE sends IPv4 traffic through an IPv6 tunnel 
(softwire) to a pre-configured DS-Lite box, which does NAT44. Works 
fine, deployed at scale (see sheet above), but keeping state on lots of 
NAT44 can get expensive at scale.

NAT64. IPv6-only to users. DNS resolver given in provisioning 
information is a DNS64 server. When it does a lookup but there's no 
, it invents one based on the A record (e.g., 2001:db8:64::). The IPv6 prefix in the invented  is actually a NAT64 
translator. Pro: no CPE support required, well understood. Con: No 
support for IPv4-only stuff in the prem, breaks DNSSEC.

464xlat. IPv6-only between CE and NAT64. Any IPv4 traffic the CPE 
receives, it translates to IPv6 and forwards to a destination that's the 
NAT64 server, which translates again. Pro: widely deployed at scale on 
mobile networks. Con: Very little CPE support in home routers.

MAP-T, MAP-E. IPv6-only between CE and Border Relay (BR). CPE is 
provisioned with an IPv4 address and a range of ports. It does basic 
NAT44, but only uses the reserved ports. Then it translates to IPv6 
(MAP-T) or encapsulates in IPv6 (MAP-E) and forwards to the configured 
Border Relay (BR), which changes it to IPv4. Pro: Stateless, very 
efficient. Con: Very little CPE support in home routers.

Jordi is going to tell me there's plenty of support for 464xlat. 
However, you can't go into any old electronics store in North America 
and buy a home gateway with support for 464xlat or MAP. You can't buy 
them directly from a vendor, unless you're large enough to request a 
specific firmware build. Yes, you can get support from OpenWRT, but 
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, but the inconvenient is the fix allocation of ports 
per client, and not all the clients use the same number of ports. Every option 
has good and bad things.
>>
>>
>>
>> MAP is less efficient in terms of maximizing the “use” of the existing 
IPv4 addresses.
>>
>>
>>
>> https://datatracker.ietf.org/doc/draft-lmhp-v6ops-transition-comparison/
>>
>>
>>
>>
>>
>> Regards,
>>
>> Jordi
>>
>> @jordipalet
>>
>>
>>
>>
>>
>>
>>
>> El 2/8/19 17:25, "NANOG en nombre de Baldur Norddahl" 
 escribió:
>>
>>
>>
>> Hi Jordi
>>
>>
>>
>> My alternative to MAP-E is plain old NAT 444 dual stack. I am trying to 
avoid the expense and operative nightmare 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 suppo

Re: MAP-E

[JORDI PALET MARTINEZ via NANOG]

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 cost of sharing IPs in a static way, is that services such as Sony 
Playstation 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.

 

Furthermore, if some users need less ports than others, you “infra-utilize” 
those addresses, which again is not the case for 464XLAT/NAT64. Each user gets 
automatically as many ports as he needs at every moment.

 

So, you save money in terms of addresses, that you can invest in a couple of 
servers running a redundant NAT64 setup 
(https://www.jool.mx/en/session-synchronization.html). Those servers can be 
actually VMs, so you don’t need dedicated hardware, especially because when you 
deploy IPv6 with 464XLAT, typically 75% (and going up) of you traffic will be 
IPv6 and only 25% will go thru the NAT64.

You work on much smaller networks than I do if a "couple of servers running 
Jool" can handle your load.  Jool is great, and the team that built it is 
great, but a couple of 10Gbps NICs on a pizza box doesn't go very far. I've 
tried 100Gbps and can't get the throughput with any normal CPU. Hoping to get 
back to it and run some actual measurements.

Lee

 

Regards,

Jordi

@jordipalet

 

 

 

El 2/8/19 18:24, "NANOG en nombre de Baldur Norddahl"  escribió:

 

The goal is to minimize cost. Assuming 4 bits for the MAP routing (16 users 
sharing one IPv4), leaving 12 bits for customer ports (4096 ports) and a 
current price of USD 20 per IPv4 address, 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 ports per 
client, and not all the clients use the same number of ports. Every option has 
good and bad things.

 

MAP is less efficient in terms of maximizing the “use” of the existing IPv4 
addresses.

 

https://datatracker.ietf.org/doc/draft-lmhp-v6ops-transition-comparison/

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 2/8/19 17:25, "NANOG en nombre de Baldur Norddahl"  escribió:

 

Hi Jordi

 

My alternative to MAP-E is plain old NAT 444 dual stack. I am trying to avoid 
the expense and operative nightmare 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 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 Norddahl"  escribió:

 

Hello

 

Are there any known public deployments of MAP-E? What about CPE routers with 
support?

 

The pricing on IPv4 is now at USD 20/address so I am thinking we are forced to 
go the CGN route going forward. Of all the options, MAP-E appears to be the 
most elegant. Just add/remove some more headers on a packet and route it as 
normal. No need to invest in anything as our core routers can already do that. 
No worries about scale.

 

BUT - our current CPE has zero support. We are too small that they will make 
this feature just for us, so I need to convince them there is going to be a 
demand. Alternatively I need to find a different CPE vendor that has MAP-E 
support, but are there any?

 

What is holding MAP-E back?  In my view MAP-E could be the end game for IPv4. 
Customers get full IPv6 and enough of IPv4 to be somewhat compatible. The ISP 
networks are not forced to do a lot of processing such as CGN otherwise 
requires.

 

I read some posts from Japan where users are reporting a deployment of MAP-E. 
Anyone know about that?

 

Regards,

 

Baldur

 


**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution

Re: MAP-E

[JORDI PALET MARTINEZ via NANOG]

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"  escribió:



> On 6 Aug 2019, at 9:05 am, Mark Tinka  wrote:
> 
> 
> 
> On 2/Aug/19 14:17, Baldur Norddahl wrote:
> 
>> 
>> 
>> The pricing on IPv4 is now at USD 20/address so I am thinking we are
>> forced to go the CGN route going forward. Of all the options, MAP-E
>> appears to be the most elegant. Just add/remove some more headers on a
>> packet and route it as normal. No need to invest in anything as our
>> core routers can already do that. No worries about scale.
> 
> Actually, I think NAT64/DNS64/464XLAT is the best option, because as
> more IPv4 falls away, you are automatically translating less and going
> native IPv6 more. And there is nothing for you to "turn off" or migrate
> away from after all is said & done.
> 
> Mark.

Which only applies to DNS64 and not 464XLAT.  That said, every IPv6 node
should be attempting to connect over IPv6 first.  That alone moves most of
the traffic to IPv6 regardless of the IPv4aaS method in use.  DNS64 also
breaks DNSSEC which is not a good thing.

DNS64 alone also depends on *everybody* having good (complete) IPv6 
connectivity
and not leaving IPv6 breakages uncorrected.  There is no fallback to IPv4
with DNS64 alone.  If you also have 464XLAT with DNS64 then there is NO
DIFFERENCE to MAP-[ET] or DS-Lite in terms of traffic shifting to native 
IPv6.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org





**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: MAP-E

[JORDI PALET MARTINEZ via NANOG]

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 something weird, so not trustable unless you understand 
very well how it works. However, testing a web site or other services will work 
fine.

Regards,
Jordi
@jordipalet
 
 

El 5/8/19 3:45, "NANOG en nombre de Philip Loenneker"  escribió:

Moving away from the discussion around what technology people may choose to 
go with, and instead what CPEs may be suitable...

I know this is 464XLAT rather than MAP-E that was originally requested, but 
recent versions of D-Link firmware, eg for the DVA-2800, include the CLAT 
functionality. My testing in November last year showed that it only partially 
worked, with the traceroutes to 64:ff9b::1.1.1.1 working, but it would not 
automatically translate a traceroute to 1.1.1.1 to the IPv6 version. There have 
been a few new revisions since then and it is on my to-do list to re-test 
things, but I haven't had the time. 

It is also worth noting that, in the original firmware revision I tested, I 
had to manually enter the URL for the CLAT configuration screen. It simply 
wasn't on the menu. On another version, it had a link to DS-Lite configuration, 
and from there you get a link to the CLAT options. It is possible that other 
devices and/or vendors also have this option, or options for similar 
technologies such as MAP-E, but they just don't have a link to it in the 
interface.

-Original Message-
From: NANOG  On Behalf Of Masataka Ohta
Sent: Monday, 5 August 2019 11:07 AM
To: nanog@nanog.org
Subject: Re: MAP-E

Baldur Norddahl wrote:

> Or the case of Playstation network. Yes they WILL blacklist your CGN 
> just the same as they can blacklist a shared MAP ip address. Except it 
> affects more users.

If IP address sharing by blocks of ports becomes common and there is 
typical block size (say, 1024), blacklisting will be done block-wise.

Masataka Ohta




**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: MAP-E

[JORDI PALET MARTINEZ via NANOG]

> 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 problem of dynamic sharing is that logging information to be
used for such purposes as crime investigation becomes huge.


-> Of course, everything has good and bad things, but with NAT444 you need to 
do the same, and because if you deploy 464XLAT you have less than 25% (and 
going down) of your traffic with IPv4, your cost for logging decreases. I'm 
assuming that you follow for IPv6 RIPE690 recommendations and you do persistent 
prefixes to customers, otherwise you also need IPv6 logging (but this is not 
different regardless of what transition mechanism you use).


> Furthermore, if some users need less ports than others, you 
> "infra-utilize" those addresses,

Users needing more ports should pay more money and share an
IP address with smaller number of users.

-> I don't agree. Users don't know if they need more or less ports, and this is 
something that may happen dynamically, depending on what apps are you using in 
your home, or if it is Xmas and you have extra family at home. This is not good 
for users, is not good for ISPs. If ISPs want to provide "different" services 
they should CLEARLY say it: "Dear customer, you have two choices 4.000 ports, 
16.000 ports or all the ports for you with a single IP address". Otherwise 
you're cheating to customers, which in many countries is illegal, because 
providing a reduced number of ports IS NOT (technically) Internet connectivity, 
is a reduced functionality of Internet connectivity, and you must (legally) 
advertise it and of course, most customers don't understand that!

> which again is not the case for 464XLAT/NAT64. Each user gets 
> automatically as many ports as he needs at every moment.

Unless all the ports are used up.

-> That's right, but you need to calculate a sufficient number of IPv4 
addresses for your pool (which for sure will be lower than in MAP or lw4o6 or 
DS-Lite), and even if your number of customers go up, because more and more 
services are available with IPv6, your number of IPv4 will not keep growing. If 
you define 4.000 ports per customer, some customers may be using only 300 ports 
(average) and that means that you're infra-utilizing 3,700 ports x number of 
users with that average. Not good!

Thus, even with dynamic port assignment, users needing more
ports should pay more money and share an IP address with
smaller number of users.

-> Never we should have charged users for IP addresses. This is a bad business 
model. Is not technically a good thing to provide non-persistent addresses. If 
we keep saying that, we will end up providing a single IPv6 address to every 
customer and doing NAT again. If an ISP want to do that, fine, but the 
competitors will be smarter (hopefully!).

Masataka Ohta




**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: MAP-E

[JORDI PALET MARTINEZ via NANOG]

The cost of sharing IPs in a static way, is that services such as Sony 
Playstation 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.

 

Furthermore, if some users need less ports than others, you “infra-utilize” 
those addresses, which again is not the case for 464XLAT/NAT64. Each user gets 
automatically as many ports as he needs at every moment.

 

So, you save money in terms of addresses, that you can invest in a couple of 
servers running a redundant NAT64 setup 
(https://www.jool.mx/en/session-synchronization.html). Those servers can be 
actually VMs, so you don’t need dedicated hardware, especially because when you 
deploy IPv6 with 464XLAT, typically 75% (and going up) of you traffic will be 
IPv6 and only 25% will go thru the NAT64.

 

Regards,

Jordi

@jordipalet

 

 

 

El 2/8/19 18:24, "NANOG en nombre de Baldur Norddahl"  escribió:

 

The goal is to minimize cost. Assuming 4 bits for the MAP routing (16 users 
sharing one IPv4), leaving 12 bits for customer ports (4096 ports) and a 
current price of USD 20 per IPv4 address, 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 ports per 
client, and not all the clients use the same number of ports. Every option has 
good and bad things.

 

MAP is less efficient in terms of maximizing the “use” of the existing IPv4 
addresses.

 

https://datatracker.ietf.org/doc/draft-lmhp-v6ops-transition-comparison/

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 2/8/19 17:25, "NANOG en nombre de Baldur Norddahl"  escribió:

 

Hi Jordi

 

My alternative to MAP-E is plain old NAT 444 dual stack. I am trying to avoid 
the expense and operative nightmare 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 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 Norddahl"  escribió:

 

Hello

 

Are there any known public deployments of MAP-E? What about CPE routers with 
support?

 

The pricing on IPv4 is now at USD 20/address so I am thinking we are forced to 
go the CGN route going forward. Of all the options, MAP-E appears to be the 
most elegant. Just add/remove some more headers on a packet and route it as 
normal. No need to invest in anything as our core routers can already do that. 
No worries about scale.

 

BUT - our current CPE has zero support. We are too small that they will make 
this feature just for us, so I need to convince them there is going to be a 
demand. Alternatively I need to find a different CPE vendor that has MAP-E 
support, but are there any?

 

What is holding MAP-E back?  In my view MAP-E could be the end game for IPv4. 
Customers get full IPv6 and enough of IPv4 to be somewhat compatible. The ISP 
networks are not forced to do a lot of processing such as CGN otherwise 
requires.

 

I read some posts from Japan where users are reporting a deployment of MAP-E. 
Anyone know about that?

 

Regards,

 

Baldur

 


**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.


**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the cont

Re: MAP-E

[JORDI PALET MARTINEZ via NANOG]

I understand that, but the inconvenient is the fix allocation of ports per 
client, and not all the clients use the same number of ports. Every option has 
good and bad things.

 

MAP is less efficient in terms of maximizing the “use” of the existing IPv4 
addresses.

 

https://datatracker.ietf.org/doc/draft-lmhp-v6ops-transition-comparison/

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 2/8/19 17:25, "NANOG en nombre de Baldur Norddahl"  escribió:

 

Hi Jordi

 

My alternative to MAP-E is plain old NAT 444 dual stack. I am trying to avoid 
the expense and operative nightmare 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 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 Norddahl"  escribió:

 

Hello

 

Are there any known public deployments of MAP-E? What about CPE routers with 
support?

 

The pricing on IPv4 is now at USD 20/address so I am thinking we are forced to 
go the CGN route going forward. Of all the options, MAP-E appears to be the 
most elegant. Just add/remove some more headers on a packet and route it as 
normal. No need to invest in anything as our core routers can already do that. 
No worries about scale.

 

BUT - our current CPE has zero support. We are too small that they will make 
this feature just for us, so I need to convince them there is going to be a 
demand. Alternatively I need to find a different CPE vendor that has MAP-E 
support, but are there any?

 

What is holding MAP-E back?  In my view MAP-E could be the end game for IPv4. 
Customers get full IPv6 and enough of IPv4 to be somewhat compatible. The ISP 
networks are not forced to do a lot of processing such as CGN otherwise 
requires.

 

I read some posts from Japan where users are reporting a deployment of MAP-E. 
Anyone know about that?

 

Regards,

 

Baldur

 


**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: MAP-E

[JORDI PALET MARTINEZ via NANOG]

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 Norddahl"  escribió:

 

Hello

 

Are there any known public deployments of MAP-E? What about CPE routers with 
support?

 

The pricing on IPv4 is now at USD 20/address so I am thinking we are forced to 
go the CGN route going forward. Of all the options, MAP-E appears to be the 
most elegant. Just add/remove some more headers on a packet and route it as 
normal. No need to invest in anything as our core routers can already do that. 
No worries about scale.

 

BUT - our current CPE has zero support. We are too small that they will make 
this feature just for us, so I need to convince them there is going to be a 
demand. Alternatively I need to find a different CPE vendor that has MAP-E 
support, but are there any?

 

What is holding MAP-E back?  In my view MAP-E could be the end game for IPv4. 
Customers get full IPv6 and enough of IPv4 to be somewhat compatible. The ISP 
networks are not forced to do a lot of processing such as CGN otherwise 
requires.

 

I read some posts from Japan where users are reporting a deployment of MAP-E. 
Anyone know about that?

 

Regards,

 

Baldur

 



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

contacts for two abuse cases - cloudstar.is and heficed.com

[JORDI PALET MARTINEZ via NANOG]

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" contact or each case that may be useful to resolve 
the problems?

Thanks in advance!
 
Regards,
Jordi
@jordipalet
 
 



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: IPv6 ingress filter

[JORDI PALET MARTINEZ via NANOG]

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 the IETF deprecated is anycast for 6to4 relays:

 

https://tools.ietf.org/html/rfc7526

 

I believe Hurricane Electric still hosts 6to4 relays.


Regards,

Jordi

 

 

 

El 14/5/19 17:32, "NANOG en nombre de Amos Rosenboim"  escribió:

 

Hello,

 

As we are trying to tighten the security for IPv6 traffic in our network, I was 
looking for a reference IPv6 ingress filter.

I came up with Job Snijders suggestion (thank you Job) that can be conveniently 
found at whois -h whois.ripe.net fltr-martian-v6

 

After applying the filter I noticed some traffic from 6to4 addresses 
(2002::/16) to our native IPv6 prefixes (residential users in this case).

The traffic is a mix of both UDP and TCP but all on high port numbers on both 
destination and source.

It seems to me like some P2P traffic, but I really can’t tell.

 

This got me thinking, why should we filter these addresses at all ?

I know 6to4 is mostly dead, but is it inherently bad ?

 

And if so, why is the prefix (2002::/16) still being routed ?

 

I would love to hear some thoughts on this, and understand if others are 
actually filtering this at both data plane and control plane.

 

Thanks,

 

Amos Rosenboim

-- 

 



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation

[JORDI PALET MARTINEZ via NANOG]

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 will be discussed in 
two weeks from now. How come an AC member can lie such way?
> 
> If I'm an AC member, or any other similar team, I will make sure to 
inform myself before stating something like that. In this case there is no 
excuse, you just need to visit a web page for the LACNIC policy proposals, 
similar in every RIR.
> 
> Then I continue reading this: "AP stated that she believed that the 
author was using ARIN to solve their problem."
> 
> How come somebody that doesn't know me, can state that?

I’m not going to go in depth on the above comments.  I’ve received at least 
one off-list inquiry and I’ll also assume no explicit malice here, but as you 
point out, it doesn’t smell tide fresh :)

-> And I'm also convinced there is not any malice, but is wrong doing this kind 
of accusations or providing such false information.


The linked AC minutes page does say "These minutes are DRAFT. They have 
been reviewed by the ARIN Advisory Council prior to posting. These minutes will 
remain draft until they are reviewed and approved by the ARIN Advisory Council 
at their next regularly scheduled meeting.”

I have pointed out another area that I consider suspect off-list, I will 
set a calendar item to watch for new minutes to see if they are approved with 
revisions.  Hopefully there’s misunderstandings here, but I’m also not 
confident as much of the conversation seems to have a disjoint with operational 
realities.  (This isn’t anything new with ARIN btw, they’ve long been concerned 
about interacting with systems that are operational as doing that may mean 
staffing for on call or other functions).

I’m hoping to see some updates/corrections to the text, so taking a 
snapshot may be useful to watch for the corrections to the draft minutes.

-> If this is changed in the final minutes, then it will be very suspicious 
that the AC is empowered to change something that in reality happened. I call 
this manipulation and the community need to be aware of such things if it 
happen. Minutes should reflect the reality of what happened in the meeting. I 
really thing the right way is that they use a side note or whatever to ack it 
was mistakes, lack of knowledge, lack of chat with the authors, whatever, but 
never an alternation of the minutes.


I’m also debating if I spend the weekend with family or pinging everyone I 
know on the AC (which is more than one) about these issues.  Either way, I’ll 
pick this up “soon” on my side.

I do consider that abuse of ARIN allocated resources (coke/pepsi for 
numbering or other integers for AS4_PATH) something that ARIN can efforts to 
enforce revocation in the case of violation of the RSA.

- Jared







**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation

[JORDI PALET MARTINEZ via NANOG]

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 minimum, you will not get 
further services neither further resources.

 

Bylaws 
(https://www.arin.net/about/corporate/bylaws/#bylaws-of-american-registry-for-internet-numbers-ltd)
 don’t explicitly talk about the obligations of members. This may be related to 
US law, that you don’t need to explicitly say that behavior against other 
members is forbidden. In some countries, it is evident that if a member of an 
association is not following the rules (policies) or is acting against the 
rights of other members, it can be expelled.

 

As I said before, we may need another policy proposal to stated what to do.

 

Why a different policy proposal? Because the same policy section must be 
related to other policy violations (may be with warnings in case of policy 
violations and resource recovery only in extreme cases or repetitive 
misbehavior – this is the case in RIPE), if that’s not clear already in the 
bylaws, US laws, or RSA.

 

For me, it is obvious that an association MUST protect members about *any* 
misbehavior of other members. 


Regards,

Jordi

 

 

 

El 27/4/19 0:58, "NANOG en nombre de William Herrin"  escribió:

 

On Fri, Apr 26, 2019 at 2:36 PM Jon Lewis  wrote:

Maybe I missed it in the proposal, but I don't see that it actually says 
what ARIN will do other than produce a report "Yep, our expert panel says 
this is hijacked.".  What's the expected result (other than the report)? 
i.e. What action is ARIN expected to take after it's determined a route 
advertisement is a hijacking that will make a difference?

 

Tough question! If the author's petition succeeds so he's not cut off at the 
knees by the Advisory Council's out-of-scope ruling, I'll look forward to 
hearing how he answers.

 

Regards,

Bill Herrin

 

 

-- 

William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation

[JORDI PALET MARTINEZ via NANOG]

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 them  is needed,  or 
instead of a complex policy we need a simple one, in the line of:
"The resources are allocated for the exclusive use of the recipient. 
Consequently, other members can't use them (unless authorized by the legitimate 
resource-holder) and not following this rule is a policy 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 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 needed another policy should state something like "if you 
> keep violating policies" this and that may happen. This should be 
> something generic for *any* policy violation not in general. We have 
> this in RIPE and LACNIC, and I'm also convinced that in APNIC and 
> AFRINIC (still working on those versions).

Not swip'ing your IPs is also a violation of the agreement, but until you 
go back to ARIN for more IPs (opps, they're out), that's not an issue.  I 
see this policy as pointless as written because it doesn't say that ARIN 
will take any action other than publishing an opinion.  I think you're 
also assuming there's a pool of experts standing by willing to investigate 
every alleged hijacking (for free?).  Maybe there are.  If there aren't, 
or once they get tired of investigating allegations, what then?


--
  Jon Lewis, MCP :)   |  I route
  |  therefore you are
_ http://www.lewis.org/~jlewis/pgp for PGP public key_




**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation

[JORDI PALET MARTINEZ via NANOG]

By the way, even if ARIN (or the community) decides to do *nothing* in case of 
a policy violation, clearly the victim will have a better situation to defend 
the case in courts, and not rely in the judgement of inexperienced folks that 
will know nothing about what is an Internet Resource, BGP, 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 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 needed another policy should state something like "if you 
keep violating policies" this and that may happen. This should be something 
generic for *any* policy violation not in general. We have this in RIPE and 
LACNIC, and I'm also convinced that in APNIC and AFRINIC (still working on  
those versions).

Regards,
Jordi
 
 

El 26/4/19 23:41, "NANOG en nombre de Jon Lewis"  escribió:

On Fri, 26 Apr 2019, William Herrin wrote:

> On Fri, Apr 26, 2019 at 9:41 AM Matt Harris  wrote:
>   Can you (or someone else on the list, perhaps even someone who 
was involved in voting this down) provide some more details as to why it was 
rejected?
> 
> 
> Hi Matt,
> 
> As I understand it (someone with better knowledge feel free to 
correct me) the proposal was ruled out of scope for ARIN because ARIN registers 
numbers, it doesn't
> decide how they're allowed to be routed. ISPs do that. 
> 
> 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 system, controlling who can and can not participate. For 
better or worse, that puts the proposal in scope.
> 
> I personally think it's for worse. I oppose the proposal itself. I'd 
just as soon ARIN not act as a gatekeeper to BGP and certain don't want to see 
it expand that
> role. 

Maybe I missed it in the proposal, but I don't see that it actually 
says 
what ARIN will do other than produce a report "Yep, our expert panel 
says 
this is hijacked.".  What's the expected result (other than the 
report)? 
i.e. What action is ARIN expected to take after it's determined a route 
advertisement is a hijacking that will make a difference?

Anecdotally, ARIN has, in the past, gotten involved in this sort of 
thing. 
Many years ago, during an acquisition that went sour at the last 
minute, 
the renegging seller went to ARIN complaining that we were hijacking 
his 
IP space.  ARIN contacted our upstreams and pressured them to pressure 
us 
to stop advertising the IP space.  Perhaps there's no official policy, 
and 
perhaps they wouldn't do this today without one?

--
  Jon Lewis, MCP :)   |  I route
  |  therefore you are
_ http://www.lewis.org/~jlewis/pgp for PGP public key_




**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.







**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a cri

Re: Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation

[JORDI PALET MARTINEZ via NANOG]

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 needed another policy should state something like "if you keep 
violating policies" this and that may happen. This should be something generic 
for *any* policy violation not in general. We have this in RIPE and LACNIC, and 
I'm also convinced that in APNIC and AFRINIC (still working on  those versions).

Regards,
Jordi
 
 

El 26/4/19 23:41, "NANOG en nombre de Jon Lewis"  escribió:

On Fri, 26 Apr 2019, William Herrin wrote:

> On Fri, Apr 26, 2019 at 9:41 AM Matt Harris  wrote:
>   Can you (or someone else on the list, perhaps even someone who was 
involved in voting this down) provide some more details as to why it was 
rejected?
> 
> 
> Hi Matt,
> 
> As I understand it (someone with better knowledge feel free to correct 
me) the proposal was ruled out of scope for ARIN because ARIN registers 
numbers, it doesn't
> decide how they're allowed to be routed. ISPs do that. 
> 
> 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 system, controlling who can and can not participate. For better 
or worse, that puts the proposal in scope.
> 
> I personally think it's for worse. I oppose the proposal itself. I'd just 
as soon ARIN not act as a gatekeeper to BGP and certain don't want to see it 
expand that
> role. 

Maybe I missed it in the proposal, but I don't see that it actually says 
what ARIN will do other than produce a report "Yep, our expert panel says 
this is hijacked.".  What's the expected result (other than the report)? 
i.e. What action is ARIN expected to take after it's determined a route 
advertisement is a hijacking that will make a difference?

Anecdotally, ARIN has, in the past, gotten involved in this sort of thing. 
Many years ago, during an acquisition that went sour at the last minute, 
the renegging seller went to ARIN complaining that we were hijacking his 
IP space.  ARIN contacted our upstreams and pressured them to pressure us 
to stop advertising the IP space.  Perhaps there's no official policy, and 
perhaps they wouldn't do this today without one?

--
  Jon Lewis, MCP :)   |  I route
  |  therefore you are
_ http://www.lewis.org/~jlewis/pgp for PGP public key_




**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation

[JORDI PALET MARTINEZ via NANOG]

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 petition process. 
Just the point is, should have never been needed, it exposes how bad (in my 
opinion) is the ARIN AC model.

Some details:

This is absolutely fake:
"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 will be discussed in two 
weeks from now. How come an AC member can lie such way?

If I'm an AC member, or any other similar team, I will make sure to inform 
myself before stating something like that. In this case there is no excuse, you 
just need to visit a web page for the LACNIC policy proposals, similar in every 
RIR.

Then I continue reading this: "AP stated that she believed that the author was 
using ARIN to solve their problem."

How come somebody that doesn't know me, can state that?

In my country, at least, this is an illegal (criminal) act (slander, ad 
hominem, etc.), unless you can prove that what you're suggesting is *actually 
true*.

I don't want to make a problem with that or even consider to go to courts with 
the case, but I really think that before saying that from someone, you must 
talk to him before.

I'm a very open and transparent guy, and I *never ever* did a policy proposal 
for *any* personal or even business motivation. I did that because if I 
discover an issue, and I believe I can contribute to resolve it and it will be 
good for the community, I just go for it. Even in several occasions my own 
proposal has been ***against*** my personal point of view and when I presented 
those policies I *clearly* stated that (for example when I was presenting 
policy proposals in all the 5 RIRs for IPv6 PI and I can find the videos if 
somebody doubt what I'm saying).

And by the way, I'm not new on this. A month ago, during the IETF meeting in 
Prague, somebody asked me how many proposals I've submitted to all the RIRs 
(since my first one around 2003 or so). I didn't know, no idea at all, so I 
decided to count them, and then I discovered that I authored over 75 (a few of 
them with other co-authors). And this isn't including an average of 3-4 
versions of each one, or many other documents in IETF (and the "n" number of 
versions of each one as well).

I do this at the cost of my own personal pocket for traveling to the RIR 
meetings, I contribute as much as I can with tutorials, workshops, 
presentations, all kind of documents, articles, sharing my *own* time. So, 
reading that is really exasperating and frustrating.

And just to be clear, let me state that I don't have anything against anyone in 
the AC or ARIN. In fact, I've been always convinced that the AC model for the 
PDP in ARIN is a bad one, and this is demonstrating that. Authors and comminity 
lose the control on a policy proposal at some point (and in this case is even 
rejected before starting).

Speaking in general, even if a proposal don't reach consensus, I'm sure any 
open discussion is always very productive and can bring new ideas, or new 
approaches to the problem.

In the Internet RIRs system, I don't think we need a kind of "representative 
democracy". The community is able to use, in any of the 5 RIRs, a very simple 
process to work on achieving (or not) consensus in policy proposals: a mailing 
list.

Regards,
Jordi
 
 

El 26/4/19 22:35, "NANOG en nombre de Jared Mauch"  escribió:

There are factual errors in the ARIN meeting minutes. It really is a 
disservice that people on the AC don’t have facts about ARIN and the function 
of their routing registry (for example).

It would be good if the ARIN AC had people that were more aware of the 
functions ARIN provides. 

If you control vote of resources by ARIN I encourage you to use this as 
part of your process. 

Sent from my iCar

> On Apr 26, 2019, at 12:47 PM, Joe Provo  wrote:
> 
>> On Fri, Apr 26, 2019 at 11:41:18AM -0500, Matt Harris wrote:
>> [snip]
>> Can you (or someone else on the list, perhaps even someone who was 
involved
>> in voting this down) provide some more details as to why it was rejected?
>> What were the arguments in favor of rejecting the proposal?  This seems
>> like an interesting idea to me, and one that I can't immediately come up
>> with any arguments against from my own perspective.  There's probably 
some
>> room for discussing and tuning specifics, but ultimately the concept 
seems
>> reasonable to me.  What am I missing here?
> 
> Speaking solely for myself, it would be reasonable to start
> any discussion based upon the on-record rationales for its
> rejection.  As such I would direct interested parties to the 
> Draft Advisory 

Re: Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation

[JORDI PALET MARTINEZ via NANOG]

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 system, controlling who can and can not participate. 
For better or worse, that puts the proposal in scope.

 

I personally think it's for worse. I oppose the proposal itself. I'd just as 
soon ARIN not act as a gatekeeper to BGP and certain don't want to see it 
expand that role. 

 

A couple of things spring to mind here now that I've given this a few more 
minutes' thought.  I agree with your reasoning as to why it makes sense for 
this to be considered in scope for ARIN.  

 

As far as expanding roles goes... Over the past few decades, we've all watched 
as the internet became less and less "wild wild west" and more and more 
controlled (sometimes centrally, sometimes in a more or less decentralized way) 
by various organizations and entities.   In various and sundry ways, bad actors 
could get away with plenty of things in 1990 that they cannot so easily today.  
It may be the case that this problem will be "solved" in some way by someone, 
but that "someone" may end up being a less engaged community or a less 
democratic organization than ARIN is.  Ultimately, ARIN does a better job than 
some other internet governance bodies of promoting stakeholder and community 
interaction and some degree of democracy.  We have to consider the question: if 
some organization is going to expand into this role, is it better that ARIN be 
the organization to do so instead of one which may be ultimately less 
democratic and more problematic?  

 

Exactly, one of our thoughts (as co-authors) is: if we do nothing, some other 
governmental bodies will take care of it, even courts, taking irrational 
judgments.

 

One major problem with the proposal, having given it a couple of minutes 
thought, that I can see as of now would be enforcement being dependent on 
knowing whom the perpetrator is.  If I decide to announce to some other 
networks some IP space owned by Carlos, but I prepend Bill's ASN to my 
announcement, how does Carlos know that I'm the bad actor and not Bill?  Having 
good communication between network operators to determine where the issue 
actually lies is critical.  Unfortunately, that doesn't always happen.  When we 
talk about leveraging ARIN's authority or potentially applying penalties of any 
sort to bad behavior, we have to be able to be certain whom the bad actor is so 
that the penalties are not inappropriately applied to an uninvolved or innocent 
third party.  

 

The proposal is “guarantor”, or at least that’s our intent. Is not ARIN taking 
the decision, is the community by means of experts. We have improved it in the 
v2 that will be posted in a matter of days in RIPE, but we can’t improve it in 
ARIN because simply discussing it is not allowed by the AC decision.

 

One thing to clarify, is that the policy is basically saying something that is 
written in all the RIRs documents: “if you get resources from us, you have the 
exclusive right to use them or your authorized customers”.

 

Now if another ARIN member is misusing your resources (not by an operational 
mistake, but repeatedly), ARIN is not going to do anything about it?

 

In any membership association, members are bound to the rules (policies in the 
case of RIRs), and members can’t act against the rights of OTHER members. If 
you don’t follow the rules, you can get a warning, or even lose your 
membership. If you go to courts because you lost your membership, courts will 
confirm “you have not followed the rules, so the association has the right to 
get you out”.

 

Is not a problem or ARIN becoming the “routing police”. This has been 
completely misunderstood by the AC. Is about ARIN making sure that the rights 
of the members are respected by other members.

 

And again, it must be clear that it is intentional, not a mistake, not fat 
fingers.

 

Without clear rules, other members can do whatever they want with resources 
allocated to another member.

 

Additionally, a question of scope does arise with regard to which resources 
ARIN would be able to enforce any such policy with regard to.  Indeed, the 
proposal as written currently calls for a "pool of worldwide experts" despite 
being a proposal submitted to an RIR which is explicitly not worldwide in 
scope.  For example, if a network with an ASN assigned by ARIN is "hijacking" 
address space that is allocated by APNIC (or any other RIR) to an entity 
outside of ARIN's region, would this be an issue for ARIN to consider?  What if 
ARIN-registered address space is being "hijacked" by an entity with a RIPE ASN 
and which is not located within ARIN territory?  I suspect that for this 
proposal to have any meaningful enforcement mechanisms, it would require 
inter-RIR 

Re: IPv6 and forensic requests

[JORDI PALET MARTINEZ via NANOG]

Apple doesn't use CLAT, because apps should support IPv6-only since a couple of 
year ago.

If they don't something "close" to a CLAT is done by RFC8305.

If is doing tethering, then the CLAT is done towards the tethered devices.

Regards,
Jordi
 
 

-Mensaje original-
De: 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 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.
> 
> You've some deployment hints at
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/
> 
> Also, google for some of my IPv6-only tutorials (last RIPE meeting, APNIC 
meeting, etc., there are even videos of them).
> 
> Regards,
> Jordi
>   
>   
> 
> -Mensaje original-
> De: NANOG  en nombre de Max Tulyev 

> Fecha: domingo, 10 de febrero de 2019, 16:30
> CC: NANOG 
> Asunto: Re: IPv6 and forensic requests
> 
>  Hello Jordi,
>  
>  thank you, I will take a look on Jool!
>  
>  Exactly CLAT was the issue.
>  
>  First, I thought to provide a /128 to every mobile, and then do a 
static
>  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 MARTINEZ пише:
>  > 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 464XLAT).
>  >
>  > Regards,
>  > Jordi
>  >
>  >
>  >
>  > -Mensaje original-
>  > De: NANOG  en nombre de Max Tulyev 

>  > Fecha: domingo, 10 de febrero de 2019, 14:26
>  > Para: NANOG 
>  > Asunto: IPv6 and forensic requests
>  >
>  >  Hi All,
>  >
>  >  we are implementing IPv6 only infrastructure.
>  >
>  >  For IPv4 access, we using tayga for 6to4 translation and then 
CGN for NAT.
>  >
>  >  There is a number of ways for Linux based NAT to store 
information for
>  >  future forensic requests (i.e. "who was it cracking that 
website?").
>  >
>  >  But what about 6to4 translators, as tayga? I believe there 
should be
>  >  well-known patches or solutions. The aim is to have what /64 
(not even
>  >  /128) was translated to what IPv4 at the requested time.
>  >
>  >  Is there any?
>  >
>  >
>  >
>  >
>  > **
>  > IPv4 is over
>  > Are you ready for the new Internet ?
>  > http://www.theipv6company.com
>  > The IPv6 Company
>  >
>  > This electronic message contains information which may be 
privileged or confidential. The information is intended to be for the exclusive 
use of the individual(s) named above and further non-explicilty authorized 
disclosure, copying, distribution or use of the contents of this information, 
even if partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.
>  >
>  >
>  >
>  >
>  
> 
> 
> 
> **
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
> 
> This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this 

Re: IPv6 and forensic requests

[JORDI PALET MARTINEZ via NANOG]

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.

You've some deployment hints at
https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/

Also, google for some of my IPv6-only tutorials (last RIPE meeting, APNIC 
meeting, etc., there are even videos of them).

Regards,
Jordi
 
 

-Mensaje original-
De: NANOG  en nombre de Max Tulyev 

Fecha: domingo, 10 de febrero de 2019, 16:30
CC: NANOG 
Asunto: Re: IPv6 and forensic requests

Hello Jordi,

thank you, I will take a look on Jool!

Exactly CLAT was the issue.

First, I thought to provide a /128 to every mobile, and then do a static 
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 MARTINEZ пише:
> 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 464XLAT).
> 
> Regards,
> Jordi
>   
>   
> 
> -Mensaje original-
> De: NANOG  en nombre de Max Tulyev 

> Fecha: domingo, 10 de febrero de 2019, 14:26
> Para: NANOG 
> Asunto: IPv6 and forensic requests
> 
>  Hi All,
>  
>  we are implementing IPv6 only infrastructure.
>  
>  For IPv4 access, we using tayga for 6to4 translation and then CGN 
for NAT.
>  
>  There is a number of ways for Linux based NAT to store information 
for
>  future forensic requests (i.e. "who was it cracking that website?").
>  
>  But what about 6to4 translators, as tayga? I believe there should be
>  well-known patches or solutions. The aim is to have what /64 (not 
even
>  /128) was translated to what IPv4 at the requested time.
>  
>  Is there any?
>  
> 
> 
> 
> **
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
> 
> This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.
> 
> 
> 
> 




**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: IPv6 and forensic requests

[JORDI PALET MARTINEZ via NANOG]

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 464XLAT).

Regards,
Jordi
 
 

-Mensaje original-
De: NANOG  en nombre de Max Tulyev 

Fecha: domingo, 10 de febrero de 2019, 14:26
Para: NANOG 
Asunto: IPv6 and forensic requests

Hi All,

we are implementing IPv6 only infrastructure.

For IPv4 access, we using tayga for 6to4 translation and then CGN for NAT.

There is a number of ways for Linux based NAT to store information for 
future forensic requests (i.e. "who was it cracking that website?").

But what about 6to4 translators, as tayga? I believe there should be 
well-known patches or solutions. The aim is to have what /64 (not even 
/128) was translated to what IPv4 at the requested time.

Is there any?




**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Auto-configuring IPv6 transition mechanisms on customer devices

[JORDI PALET MARTINEZ via NANOG]

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
 
 

-Mensaje original-
De: NANOG  en nombre de Brandon Martin 

Fecha: viernes, 14 de diciembre de 2018, 17:20
Para: "nanog@nanog.org" 
Asunto: Auto-configuring IPv6 transition mechanisms on customer devices

Are there any (draft, standard, or otherwise) defined mechanisms for 
indicating to customer-provided devices that they should configure IPv6 
to IPv4 transition mechanisms such as MAP, 4rd, 464XLAT, etc. and 
providing the configuration details thereof?

I'm not aware of any.  It seems like this is something that, if defined, 
would make deployment of such mechanisms a lot easier even if SPs 
provide the customer edge router that implements said mechanisms.  I 
guess they'd probably be implemented as extensions to DHCPv6 or similar 
or embedded in RAs (the latter seems ugly).
-- 
Brandon Martin




**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: new(ish) ipv6 transition tech status on CPE

[JORDI PALET MARTINEZ via NANOG]

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

 

 

 

De: NANOG  en nombre de Tom Ammon 

Fecha: miércoles, 10 de octubre de 2018, 0:14
Para: NANOG 
Asunto: new(ish) ipv6 transition tech status on CPE

 

Are there any CPE vendors providing MAP-T features yet? I'm working on rolling 
v6 to residential subscribers and am trying to understand what the landscape 
looks like on the CPE side, for MAP-T specifically.

 

What about 464XLAT on a CPE - is that a thing? I know that 464XLAT has been 
running for a while on some mobile provider networks, but are there any vendors 
out there with a decent/mature CLAT implementation in a CPE product that is 
ready to buy right now?

 

Thanks, 

Tom

 

-- 

-
Tom Ammon
M: (801) 784-2628
thomasam...@gmail.com
-



**
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Deploying IPv6 XLAT64

[JORDI PALET MARTINEZ via NANOG]

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 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 
Operators' Group 
Asunto: Re: Deploying IPv6 XLAT64

Thanks... that is what I don't understand:  Why is NAT64 such a 
difficult concept to put into routers and firewalls?  We already do NAT 
with IPv4 just fine.

I feel like IPv6 adoption would be much faster if there was a transition 
mechanism other than dual stacking.

Think: Corporate offices.  Rather than renumbering everything inside, 
they just turn on NAT64 and now they can begin a slow and controlled 
transition.

On 9/26/18 2:19 PM, JORDI PALET MARTINEZ wrote:
> 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 

> Fecha: miércoles, 26 de septiembre de 2018, 15:03
> Para: North American Network Operators' Group 
> Asunto: Deploying IPv6 XLAT64
> 
>  Looking at getting into IPv6 here ourselves... one of the big hold 
ups
>  has been the dual stacking.
>  
>  Can anyone recommend a quality, not ridiculously convoluted to setup,
>  XLAT64 translator that we could run in our network to take the IPv6 
to
>  an IPv4 address when the remote server doesn't have 6 capability?
>  
> 
> 
> 
> **
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.consulintel.es
> The IPv6 Company
> 
> This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.
> 
> 
> 




**
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Deploying IPv6 XLAT64

[JORDI PALET MARTINEZ via NANOG]

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 

Fecha: miércoles, 26 de septiembre de 2018, 15:03
Para: North American Network Operators' Group 
Asunto: Deploying IPv6 XLAT64

Looking at getting into IPv6 here ourselves... one of the big hold ups 
has been the dual stacking.

Can anyone recommend a quality, not ridiculously convoluted to setup, 
XLAT64 translator that we could run in our network to take the IPv6 to 
an IPv4 address when the remote server doesn't have 6 capability?




**
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: IPv6 faster/better proof? was Re: Need /24 (arin) asap

[JORDI PALET MARTINEZ via NANOG]

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 don’t depend on a specific hardware vendor. You can have a 
single model or several ones depending on customer’s needs, but all share the 
same firmware. You can buy very good quality products from China with 1-5 
FastEthernet or Gigabit ports, 1 or dual radio WiFi, 1 or several USB (2.0 or 
3.0), with or without Bluetooth, SD card support, even SATA support, and even 
LTE support. You have so many vendors that you can even decide what CPU you 
prefer to have and even what Wireless chips …

 

A basic one will be around 15 USD, the most powerful one will be around 30 USD 
(without 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 MARTINEZ wrote:





Yeah I can confirm, as I tested it several times, 6to4 for them is proto41, but 
it is very confusing and against standards nomenclature … This don’t say 
anything good from a vendor, in my opinion!


Even those networks I know running MikroTik for revenue generation don't run 
around saying they think they are working with the best vendor :-).

But the truth is in the numbers - I'm to find another vendor in my parts that 
sells more gear without presence in any country on the continent.




 

They basically run a Linux … and you have OpenWRT sources with all what they 
need to implement 4in6 transition mechanisms, so no excuses! I must say also 
that no excuses for other CPE vendors, of course, but others at least have 
DS-Lite or even lw4o6. Very few offer 464XLAT (CLAT part is what the CPE needs) 
or MAP-T/E. Hopefully this will change soon.


On the plus side, MikroTik regularly push out updates for their devices, unlike 
traditional home CPE whose updates tend to disappear one year after you buy and 
install them, leaving the only option to update software being a hardware 
swap-out.

Can MikroTik do more, certainly. But this is clearly a case of "you get what 
you pay for". 

On the other hand, Cisco have (yet again) delayed ORR until 2019/2020, if at 
all. Juniper have screwed up their EX switch CLI with this ELS monstrosity, a 
problem they hope to correct in 2019/2020, if at all. And I'm paying through 
eyes for those puppies...

Mark.




**
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: IPv6 faster/better proof? was Re: Need /24 (arin) asap

[JORDI PALET MARTINEZ via NANOG]

 
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 thing it didn't 
backfire on me :-).


Yeah I can confirm, as I tested it several times, 6to4 for them is proto41, but 
it is very confusing and against standards nomenclature … This don’t say 
anything good from a vendor, in my opinion!



So for native IPv6 or a 6in4 tunnel, is fine, but any other transition 
mechanism is NOT supported, so we end up reflashing then with OpenWRT.

Not sure I'd blame them either - they develop a lot of features for pretty much 
next-to-nothing; and are being enabled by customers that are willing to take 
the risk for relief on budget. 


I’ve got very good customers from Mikrotik asking them in private and in public 
and they even didn’t reply. No other transition mechanism is available, no 
roadmap. So, you can’t use them for example for an IPv6-only access network 
which clearly is what is needed now.


They could be more inclined to fix bugs and develop corner-case features sooner 
if they were in the premium market. But, as my (well-known on this list) 
American friend would say, "I conjecturbate" :-).

 

They basically run a Linux … and you have OpenWRT sources with all what they 
need to implement 4in6 transition mechanisms, so no excuses! I must say also 
that no excuses for other CPE vendors, of course, but others at least have 
DS-Lite or even lw4o6. Very few offer 464XLAT (CLAT part is what the CPE needs) 
or MAP-T/E. Hopefully this will change soon.

 



**
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: IPv6 faster/better proof? was Re: Need /24 (arin) asap

[JORDI PALET MARTINEZ via NANOG]

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 we end up reflashing then with OpenWRT.



Regards,

Jordi

 

 



-Mensaje original-

De: NANOG  en nombre de Mark Tinka 


Fecha: viernes, 22 de junio de 2018, 9:07

Para: Jared Mauch , Job Snijders 

CC: North American Network Operators' Group 

Asunto: Re: IPv6 faster/better proof? was Re: Need /24 (arin) asap







On 20/Jun/18 05:48, Jared Mauch wrote:



> MikroTik is getting there but most people are just not enabling it either.



I have a MikroTik hAP Lite router for my FTTH service at my house.



It has excellent support for IPv6, including a ton of translation

mechanisms.



My problem is my home provider doesn't do IPv6, so I run a 6-in-4 tunnel

back to my own backbone for the service (no latency impact as my home

provider is my IP Transit customer :-) ). This is a little unstable

because my home provider doesn't know how to give me a stable IPv4

address for my FTTH service.



But I do have to say that I am massively impressed by what that little

MikroTik box can do. IPv6 on my home LAN works as expected, as it does

across the 6-in-4 tunnel.



Mark.






**
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: What are people using for IPAM these days?

[JORDI PALET MARTINEZ via NANOG]

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 Sun, Jun 10, 2018 at 8:48 PM, Mike Lyon  wrote:
> Title says it all... Currently using IPPlan, but it is kinda antiquated..

This is always a good thing to review every 2-3 years or so.

My current favorites in the open source world are:

Netbox - https://github.com/digitalocean/netbox
NIPAP - http://spritelink.github.io/NIPAP/
ed - http://man.openbsd.org/ed ;-)

Give a few of the IPAMs out there a chance and just see which one
suits your operational procedures best! (Though, using a spreadsheet
file on a shared network drive is still not recommended.)

Kind regards,

Job




**
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Whois vs GDPR, latest news

[JORDI PALET MARTINEZ via NANOG]

I know that LOPD and LSSI is not the same as GDPR.

However, each country in the EU need to modify its own LOPD in order to adapt 
it to the GDPR.

*I've done some further reading and according to the 1st and 2nd paragraphs of 
GDPR Art. 83 each DPA will establish the fines, which should respect what is 
said in 4, 5 and 6 (including the maximum fines, so clearly 10 and 20 MEuros or 
2% and 4% of the previous year turnover).

So after that, I found what is going on and in the case of Spain, the council 
of Ministers approved the law 24th Nov. 2017 
(http://www.congreso.es/docu/docum/ddocum/dosieres/sleg/legislatura_12/spl_13/pdfs/1.pdf)
 and it was expected to be sanctioned by the Parliament last week, after some 
discussion and some changes. However seems to be delayed as the parliament 
asked for some amendments.

In this document, again, it is indicated that the DPA will follow what is being 
said in GDPR (see * above) and doesn't mention the amount of each fine, because 
"Each supervisory authority shall ensure that the imposition of administrative 
fines pursuant to this Article in respect of infringements of this Regulation 
referred to in paragraphs 4, 5 and 6 shall in each individual case be 
effective, proportionate and dissuasive." See also the text in p. 2 of the GDPR.

This facilitates the DPAs to take in consideration *each* individual case, or 
even to change the fines in the future.

However, the Spanish law, talks about some specific fine amounts in the article 
78, referred to the prescription of the infringements depending on the fine 
amount. For example, for fines up to 40.000 Euros, 300.000 euros and over 
300.000 euros.

What that means? Each DPA have to modify the "actual" LOPD and associated 
tables of fines, and the GDPR only stablishes the maximum amounts.

Other countries already have done that:
Italy: LEGGE 20 novembre 2017, n. 167
Germany: Bundesdatenschutzgesetz
France: looks like a similar situation as Spain

So, for the countries that have not yet finalized the approval of the "new 
LOPD", the fines are still the same as the ones defined in the "actual LOPD". 
So, I think I was right in my assertion, and the minimum fines in Spain, will 
be for sure lower than 40.000 euros, and my guess is that will start as today 
with 600 or so ... at the end in will depend on the "individual decision" 
(based in a categorization table, which the Spanish DPA for sure has already 
prepared, but will not make public until the new LOPD is approved by the 
parliament).

Of course I'm not saying that you should ignore the GDPR because the fines are 
low. I think everybody really need to adapt their data protection procedures to 
it.

Regards,
Jordi
 
 PD: An informal document that I've found say that the new fines are in the 
ranges of 900-40.000, 40.001-300.000 and 300.000-600.000.



-Mensaje original-
De: NANOG <nanog-boun...@nanog.org> en nombre de Rob McEwen 
<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 
LSSI

Jordi,

LOPD/LSSI does not = GDPR

But even if there was a probability that GDPR would operate like they do: 
(1) it is alarming that the fines mentioned on GDPR are 10-20X higher than even 
LOPD/LSSI's higher fines -AND- regarding LOPD/LSSI's relatively low minimum 
fine of 600 EUROs that you mentioned - it was explicated mentioned on the page 
you referenced - HOWEVER there is NOT any similar official (relatively) 
low-cost fines mentioned for GDPR anywhere there is only that 
NOT-reassuring "up to" phrase.

For someone hit with a GDPR fine, I don't think telling them, "JORDI PALET 
MARTINEZ claimed that the fine will be more reasonable for a smaller business 
that had a less egregious offense" - is going to necessarily make it so.

Believe me, I WANT you to be my GDPR fairy. I really really do. But I have 
to operate my business more realistically.

-- 
Rob McEwen
https://www.invaluement.com






**
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, i

Re: Whois vs GDPR, latest news

[JORDI PALET MARTINEZ via NANOG]

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, then 
it come to something like 30.000 euros, etc.

If you keep repeating the law infringement, then the 2nd time it may become 
150.000 Euros.

If it is massive infringement (for example massive spam), then it comes to 
300.000 or even 600.000 euros.

Here there is an explanation for the LOPD fines, is in Spanish, but a 
translator should work:
http://www.cuidatusdatos.com/infracciones/

My guess is that the GDPR maximum fines are there just as maximum, and there 
will be agreements among the EU DPAs, to better define how much is the fine, in 
a similar way they are doing now.

Regards,
Jordi
 
 

-Mensaje original-
De: NANOG  en nombre de Rob 
McEwen 
Fecha: sábado, 26 de mayo de 2018, 21:06
Para: 
Asunto: Re: Whois vs GDPR, latest news

On 5/26/2018 2:36 PM, Michel 'ic' Luczak wrote:
> Original text from EU Commission:
> "Infringements of the following provisions shall, in accordance with 
paragraph 2, be subject to administrative fines up to 10 000 000 EUR, or in the 
case of an undertaking, up to 2 % of the total worldwide annual turnover of the 
preceding financial year, whichever is higher”
>
> -> Administrative fines_up to_  10M (or 2% if your 2% is higher than 10M).
>
> It’s a cap, not a minimum.


Thanks for the clarification. But whether that fine will be less than 
10M is extremely vague and (I guess?) left up to the opinions or whims 
of a Euro bureaucrat or judge panel, or something like that... based on 
very vague and subjective criteria. I've searched and nobody can seem to 
find any more specifics or assurances. Therefore, there is NOTHING that 
a very small business with a very small data breach or mistake, could 
point to... to give them confidence than their fine will be any less 
than 10M Euros, other than that "up to" wording - that is in the same 
sentence where it also clarifies "whichever is larger".

All these people in this discussion who are expressing opinions that 
penalties in such situations won't be nearly so bad - are expressing 
what may very with be "wishful thinking" that isn't rooted in reality.

-- 
Rob McEwen
https://www.invaluement.com
  





**
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Whois vs GDPR, latest news

[JORDI PALET MARTINEZ via NANOG]

I don't recall right now the exact details about how they calculate the fine, 
which is appropriate for each case, but the 4% of turnover or 20 million Euros 
is just the maximum amount (per case). I'm sure there is something already 
documented, about that, or may be is each country DPA the one responsible to 
define the exact fine for each case.

For example, up to now (with the previous law, LOPD for Spain), the maximum 
fine was 600.000 euros, and the "starting" fine was 1.500 euros. So, depending 
on the number of people affected, the degree of infringement, if it is the 
first time or if the company has been warned or fined before, you can get a 
fine in the "middle" of those figures.

I'm sure it will be the same way for the GDPR.

Regards,
Jordi
 
 

-Mensaje original-
De: NANOG <nanog-boun...@nanog.org> en nombre de Seth Mattinen 
<se...@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 (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 cash the fine, even with "bank account embargos". If the company 
is outside the EU, but there are agreements with that country, they can proceed 
to that via the third country authorities.


If someone were to show up and issue me a 10 or 20 million euro fine 
(more in USD), I'd just laugh since I'll never see that much money at 
one time in my whole life.

I'm not convinced they will limit reach to the Facebooks and Googles of 
the world until a lower limit is codified. I suspect that won't happen 
until enough small guys are fined 10-20 million euros who could never 
hope to repay it in a lifetime.

~Seth




**
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Whois vs GDPR, latest news

[JORDI PALET MARTINEZ via NANOG]

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 cash the fine, even with "bank account embargos". If the company is outside 
the EU, but there are agreements with that country, they can proceed to that 
via the third country authorities.

Same as when you don't pay a traffic fine in the EU and you are from non-EU 
countries (some allow the embargo, others not).

This has been happening, in most of the EU countries for a while. In recent 
months, the Spanish DPA has ordered fines of 600.000 euros (with the previous 
law, LOPD), to companies such as Facebook, Google, Whatsapp, and many others ...

Regards,
Jordi
 
 

-Mensaje original-
De: NANOG  en nombre de Nick Hilliard 
Fecha: sábado, 26 de mayo de 2018, 11:29
Para: Seth Mattinen 
CC: 
Asunto: Re: Whois vs GDPR, latest news

Seth Mattinen wrote on 26/05/2018 08:41:
> Good luck getting multiple millions worth of fines out of small 
> businesses that never even touch a million a year in revenue, let alone 
> the added expenses of trying to do all the crap GDPR thinks everyone can 
> suddenly afford out of nowhere.

You can put the straw man away - Europe isn't the US.  No Data 
Protection Authority in Europe is going to sue a mom & pop business in 
the US for millions because they haven't clarified their cookies policy. 
The upper limits of the fines are aimed at the robber barons of the world.

The DPAs in Europe are for the most part lawsuit-averse and engage with 
companies to build alignment rather than taking the punitive approach 
and liberally dishing out lawsuits and fines.  The emphasis on GDPR 
compliance is aiming at reasonable steps rather than pretending that 
every organisation is going to end up redesigning their entire existence 
around GDPR on may 25.

Nick




**
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.