Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Fernando Gont <> Fri, 29 May 2020 00:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0638B3A1058 for <>; Thu, 28 May 2020 17:57:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yWYoyu5bYXpw for <>; Thu, 28 May 2020 17:57:06 -0700 (PDT)
Received: from ( [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 559313A1056 for <>; Thu, 28 May 2020 17:57:06 -0700 (PDT)
Received: from [IPv6:2800:810:464:8801:587:f01d:af30:844f] (unknown [IPv6:2800:810:464:8801:587:f01d:af30:844f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id F2B692809CC; Fri, 29 May 2020 00:57:01 +0000 (UTC)
From: Fernando Gont <>
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"
To: "Kamran Raza (skraza)" <>, Bob Hinden <>, IPv6 List <>
References: <> <>
Message-ID: <>
Date: Thu, 28 May 2020 21:56:57 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 29 May 2020 00:57:09 -0000

On 28/5/20 19:49, Kamran Raza (skraza) wrote:
> I do not support the WG adoption of this document.
> In addition to numerous technical and other points made by others on the list already, I would like to highlight the tax this proposal puts on ASICs/hardware:

It is interesting, because the PSP behaviour that Spring shipped in 
is apparently meant to deal with implementations that cannot even ignore 
a RH where SL==0, as required by RFC8200.

If anything, it would seem to me that shorter headers would make life 
easier when it comes to processing the headers.

> 2) VPN Service's DOH header processing:
> For CRH based solution, the VPN context is encoded in a Dest Opt header located after the CRH which adds the following challenges:
> - At the egress PE, the packet arrives with both CRH and Dest Opt headers. The egress PE first needs to process the CRH to see whether SL = 0 and ignore the rest of it.
> - Then, it needs to process DoH and the options within it. This overall combination will be challenging for many ASICs.

Welcome to the IPv6 world. If you can't handle this, you are not 
compliant with RFC8200.

As before, these comments are neither in favor nor against CRH, but 
rather against about bogus arguments.

Fernando Gont
SI6 Networks
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492