Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Fri, 07 Aug 2020 17:43:42 -0700 (PDT)
Message-Id: <20200807.174342.2147963305722259387.davem@davemloft.net>
To:     ahabdels@gmail.com
Cc:     kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org,
        netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
        andrea.mayer@uniroma2.it
Subject: Re: [PATCH] seg6: using DSCP of inner IPv4 packets
From:   David Miller <davem@davemloft.net>
In-Reply-To: <7f8b1def-0a65-d2a4-577e-5f928cee0617@gmail.com>
References: <20200804074030.1147-1-ahabdels@gmail.com>
        <20200805.174049.1470539179902962793.davem@davemloft.net>
        <7f8b1def-0a65-d2a4-577e-5f928cee0617@gmail.com>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

From: Ahmed Abdelsalam <ahabdels@gmail.com>
Date: Thu, 6 Aug 2020 08:43:06 +0200

> SRv6 as defined in [1][2] does not mandate that the hop_limit of the
> outer IPv6 header has to be copied from the inner packet.

This is not an issue of seg6 RFCs, but rather generic ip6 in ip6
tunnel encapsulation.

Therefore, what the existing ip6 tunnel encap does is our guide,
and it inherits from the inner header.

And that's what the original seg6 code almost certainly used to
guide the decision making in this area.