Re: [EXTERNAL] Re: Extending a /64

On Mon, 9 Nov 2020, 11:29 Gyan Mishra, <hayabusagsm@gmail.com> wrote:

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

RFC4864.

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