Hi Mark, I am in complete agreement with you that NAT is evil and should be avoided **.
However let me explain my use case of NAT. It is described in section 7 of draft-raszuk-teas-ip-te-np-00 only uses destination address mapping without requirement that the destination is a local interface on a mid point TE node: As an alternative solution to avoid unnecessary processing of extension header by nodes which are not required to do so implementation can treat SID with last four bits set to zero as none local destination address. In such scenario source+destination lookup will instead of triggering local extension header processing invoke destination IPv6 NAT function as defined in [RFC6296 <https://tools.ietf.org/html/rfc6296>]. The NAT rules which will be pre-programmed using information contained in the PATH_LIST will effectively result in destination address swap. Such NAT translation is to be of unidirectional character can can remain fully stateless. The way I read Ron's suggestion - it would result in huge address space waist for no reason. That's all. Many thx, Robert. PS. ** As side comment let me share that some of my observations lead me to believe that the biggest obstacle of IPv6 deployment in a lot of enterprises is the notion of end to end IPv6 transparency. But this is different topic and different thread. On Sun, Oct 13, 2019 at 11:46 PM Mark Smith <[email protected]> wrote: > > > On Mon, 14 Oct 2019, 08:24 Robert Raszuk, <[email protected]> wrote: > >> Hi Ron, >> >> I disagree. >> >> Your suggestion violates longest prefix match principle in routing. >> >> It is huge waist of address space and is not specific to IPv6 at all. >> >> Let me describe the deployment case where your suggestion would cause it >> to break: >> >> I have /64 prefix where a few /128s from that space I allocate to local >> interfaces making it a local v6 destinations on those nodes. >> >> However in the spirit of CIDR I still want to to use some blocks of that >> space - say /126 or /124 as blocks which I only use to trigger local NAT >> as per rfc6296. >> > > Realise that RFC6296 is Experimental, and therefore nothing standard track > can rely on it. > > Don't use NAT. IPv6 is pointless if you do. > > RFC2993 - Architectural Implications of NAT > *https://tools.ietf.org/html/rfc2993 <https://tools.ietf.org/html/rfc2993>* > > > The Touble with NAT - APNIC blog articles > > https://blog.apnic.net/2016/10/25/trouble-nat-part-1/ > > https://blog.apnic.net/2016/10/26/trouble-nat-part-2/ > > https://blog.apnic.net/2016/10/27/trouble-nat-part-3/ > > > And NAT does not require local address to be a destination address so it >> would be a big disservice to kill such deployment option. >> >> Many thx, >> R. >> >> >> On Sun, Oct 13, 2019 at 10:59 PM Ron Bonica <rbonica= >> [email protected]> wrote: >> >>> Folks, >>> >>> >>> >>> I think that we need a global rule that says: >>> >>> >>> >>> “With a /64, if one /128 represents an IPv6 interface, as described in >>> RFC 4291, all /128 MUST either: >>> >>> >>> >>> - Represent an IPv6 interface, as described in RFC 4291, or >>> - Be unassigned” >>> >>> >>> >>> The 6man WG will need to make such a statement since it owns RFC 4291. >>> >>> >>> >>> Ron >>> >> _______________________________________________ >> spring mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/spring >> >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
