Re: [EXTERNAL] Re: Extending a /64

One of the major benefits of IPv6 is that IPv6 scarcity is non existent of
address space  exhaustion and thus the need for NAT eliminated.

There are still special use cases for security hide NAT to hide internal
space or dual homing.

As IPv4 is limited in registered space the use of RFC1918 and NAT is much
more widespread as compare to IPV6 use of ULA with NAT as the use cases are
far less due to v6 scarcity being non existent.

As we know all the pains of NAT from IPv4 and NAT ALG complexities
learnings and NAT for IPV6 should be an absolute last resort if no other
option is available.  Also DNS NAT complexity it’s best to stay clear of
NAT on CPE.

I would put changing slaac to prefer longer prefixes to be preferred well
over NAT66.

One other point to make is that even if ISPs race  to the bottom
hypothetically which would never happen as IPv6 space will never be
exhausted, but hypothetically we would only this unique situation which
would never happen do Port address translation PAT  /127 outbound interface
overload to extend IPv6 downstream devices.

So by thinking to do NAT now as an optimal best solution is no different
then the race to bottom FUD we are fearful of and are doing exactly that
scenario of NAT66 to extend IPv6 to downstream devices.

We might as well pretend we are at the race to the bottom now and have the
ISP not wait for actual race to bottom  and  give us only a /127 wan IP now
so can desperately use NAT as the optimal solution to extend IPV6 to our
downstream devices.

Gyan

On Sun, Nov 8, 2020 at 4:46 PM Manfredi (US), Albert E <
albert.e.manfredi@boeing.com> wrote:

> From: Mark Smith <markzzzsmith@gmail.com>
>
> > See RFC2993.
> >
> > See also the 3 part "The Trouble With NAT" articles, using network
> operation criteria.
> >
> > https://blog.apnic.net/author/mark-smith/
>
> With IPv6, network prefix translation only (NPT), at the platform's
> interfaces with the ISPs.
>
> "The fundamental constraint of NAT is that it prevents IP nodes attached
> to the same network from acting as peers of each other."
>
> How so? I'm saying, these NAT problems, mostly experienced with NAPTs,
> either won’t happen, or can be managed in a platform with well-managed
> internal architecture. Is it a problem if state has to be maintained in
> such NAT (NPT) devices? I'd rather have that, than rely on the fixed ISPs,
> no? Plus, I'm not even using the NAT to provide some sort of inherent
> security benefit. Just using it to solve every single problem mentioned in
> these related threads. End to end connectivity can be retained.
>
> Yes, the NPT boxes have to be managed reliably, but in these scenarios,
> that's preferable to expecting wither the end systems or the ISPs, to do
> everything predictably.
>
> Bert
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD