Re: [EXTERNAL] Extending a /64

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?

Best regards,
Ole

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