Re: [spring] IPv6 Addresses and SIDs

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 <markzzzsmith@gmail.com> wrote:

>
>
> On Mon, 14 Oct 2019, 08:24 Robert Raszuk, <robert@raszuk.net> 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=
>> 40juniper.net@dmarc.ietf.org> 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
>> spring@ietf.org
>> https://www.ietf.org/mailman/listinfo/spring
>>
>