Lee Howard wrote:
So, all we need is NAT44 CPE, which only uses a reserved block of ports,
which is (semi) statically configured by ISP operated gateway.
How would you route from the provider edge?
If CPE A has 192.0.2.15 port 1000-2999
and CPE B has 192.0.2.15 port 3000-4999,
Oops,I
Hi Lee,
> Also but, would that be a Net Neutrality problem, charging less for a service
> that has arguably worse access to Amazon, Reddit, Twitter, etc.?
Net neutrality as it is here in Europe usually is satisfied when no
preferential treatment is given to a limited set of services (Netflix
On 8/9/19 1:32 AM, Vincent Bernat wrote:
❦ 8 août 2019 16:18 -04, Lee Howard :
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
om: NANOG On Behalf Of Lee Howard
> Sent: Friday, August 9, 2019 5:18 AM
> To: nanog@nanog.org
> Subject: Re: MAP-E
>
>
> 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 som
On 8/8/19 9:00 PM, Masataka Ohta wrote:
Lee Howard wrote:
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
On 8/8/19 9:00 PM, Masataka Ohta wrote:
As for protocol, assuming port mapping on UPnP gateway is statically
configured by ISPs not changable from CPE side, GetListOfPortMappings()
of UPnP should be useful for CPEs to know range of ports to be used
by them.
There's actually a DHCPv6 option for
On Thu, 8 Aug 2019, Jay Hanke wrote:
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.
The DOCSIS residential gateway vendors seem to have converged
❦ 8 août 2019 16:18 -04, Lee Howard :
> 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:: address>). The IPv6 prefix in the invented is
Lee Howard wrote:
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
On Fri, Aug 9, 2019 at 5:17 AM Lee Howard wrote:
>
> 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
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
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,
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
> 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
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
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
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
> 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
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.
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
Valdis Kletnieks wrote:
-> Of course, everything has good and bad things, but with NAT444 you
need to do the same,
With static port range assignment, we don't have to.
So you're going to say what ports the users are forced to use...
Like DHCP, yes. So?
Only users know what applications
On Mon, 05 Aug 2019 06:42:30 +0900, Masataka Ohta said:
> JORDI PALET MARTINEZ via NANOG wrote:
> > 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
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 becom
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),
On Sat, Aug 3, 2019 at 11:30 AM JORDI PALET MARTINEZ via NANOG <
nanog@nanog.org> wrote:
>
> > 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
JORDI PALET MARTINEZ via NANOG wrote:
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,
With static port range assignment, we
> 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
Brian J. Murrell wrote:
You can also use OpenSource (Jool) for the NAT64.
Will any of these (including MAP-E) support such nasty (in terms of
burying IP addresses in data payloads) protocols as FTP and SIP/SDP?
Are you saying ICMP and DNS nasty?
As DNS protocol is still actively
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
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
On Fri, Aug 2, 2019 at 5:33 PM Bryan Holloway wrote:
>
>
> On 8/2/19 5:16 PM, Baldur Norddahl wrote:
> >
> > Multiple customers share an IPv4 address each with an assigned port
> range.
> >
>
>
> One downside that has been brought up on the list before is that a DDoS
> attack against a single
Is there a summary presentation someplace laying out the options that
are active in the wild with some deployment stats?
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
On 8/2/19 5:16 PM, Baldur Norddahl wrote:
Multiple customers share an IPv4 address each with an assigned port range.
One downside that has been brought up on the list before is that a DDoS
attack against a single subscriber will impact many, but that particular
drawback may not
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.
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,
On Fri, Aug 2, 2019 at 3:49 PM Brian J. Murrell
wrote:
>
> Will any of these (including MAP-E) support such nasty (in terms of
> burying IP addresses in data payloads) protocols as FTP and SIP/SDP?
>
>
All MAP-E does is reserving a port range for each customer. So customer A
might be assigned
On Fri, 2 Aug 2019 at 14:49, Brian J. Murrell wrote:
> Will any of these (including MAP-E) support such nasty (in terms of
> burying IP addresses in data payloads) protocols as FTP and SIP/SDP?
>
I'm a fan of these solutions that (only) use NAT44 in the CPE as this is
exactly what they're
On Fri, 2 Aug 2019, Brian J. Murrell wrote:
Will any of these (including MAP-E) support such nasty (in terms of
burying IP addresses in data payloads) protocols as FTP and SIP/SDP?
LW4o6 is regular NAT44 and then tunnel encap. MAP-E is similar.
So if there is NAT44 helper for these protocols
On Fri, 2019-08-02 at 15:37 +0200, 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
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
On Fri, 2 Aug 2019, Baldur Norddahl wrote:
be a demand. Alternatively I need to find a different CPE vendor that
has MAP-E support, but are there any?
Broadcom supports MAP-E and LW4o6 encap/decap in fastpath on at least
BCM63138 with their latest BSP versions.
--
Mikael Abrahamsson
41 matches
Mail list logo
