Re: [EXTERNAL] Extending a /64

[Gyan Mishra <[e-mail]>]

On Mon, Nov 9, 2020 at 2:26 AM <[e-mail]> wrote:

> Gyan,
>
> So far the only technical/relevant to protocols problem I have managed to
> extract from these discussions is the one I stated starting this thread.
>
> "The problem of an end-user that has been allocated only a /64; how can
> she extend her network with multiple links".
>
> Do you concur with that?


    Agreed.  The use case could be any use case where you are given a /64
by the service provider and have a requirement to further segment to
multiple downstream devices.

    Here is a second major issue below.

    Please see this thread with subject “ SLAAC, Static & DHCPv6 day 1
interoperability issue”.

 I just responded to Brian Carpenter on the thread.

>
>
> Best regards,
> Ole
>
> > On 9 Nov 2020, at 01:28, Gyan Mishra <[e-mail]> 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.
> >
> > 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 <
> [e-mail]> wrote:
> > From: Mark Smith <[e-mail]>
> >
> > > 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
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> > --
> >
> >
> > Gyan Mishra
> > Network Solutions Architect
> > M 301 502-1347
> > 13101 Columbia Pike
> > Silver Spring, MD
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > 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