RE: Compatibility with SRH requirement (was Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)")

Adrian Farrel <adrian@olddog.co.uk> Sat, 30 May 2020 22:37 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D613A3A0B3A for <ipv6@ietfa.amsl.com>; Sat, 30 May 2020 15:37:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGhODSPs30xE for <ipv6@ietfa.amsl.com>; Sat, 30 May 2020 15:37:38 -0700 (PDT)
Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D8803A0B39 for <ipv6@ietf.org>; Sat, 30 May 2020 15:37:37 -0700 (PDT)
Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id 04UMbWaj015291; Sat, 30 May 2020 23:37:32 +0100
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 764A222044; Sat, 30 May 2020 23:37:32 +0100 (BST)
Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs2.iomartmail.com (Postfix) with ESMTPS id 60B7A22042; Sat, 30 May 2020 23:37:32 +0100 (BST)
Received: from LAPTOPK7AS653V ([84.93.26.18]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 04UMbUtC005961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 30 May 2020 23:37:31 +0100
Reply-To: <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'James Guichard'" <james.n.guichard@futurewei.com>, "'John Scudder'" <jgs@juniper.net>
Cc: "'Bob Hinden'" <bob.hinden@gmail.com>, "'IPv6 List'" <ipv6@ietf.org>
References: <19D30186-B180-4F65-BF00-7AD07CEF3925@gmail.com> <C7C2E1C43D652C4E9E49FE7517C236CB02A53F3E@dggeml529-mbx.china.huawei.com> <CALx6S37UQa5rEAkz54N6S_POaduyUnS=ApN+qQGoepnm0=JdkA@mail.gmail.com> <DM6PR13MB306688749E076BDC84AB0023D28F0@DM6PR13MB3066.namprd13.prod.outlook.com> <CALx6S36stS3KSs1d+MxpPzDC4_Gb1N94NW=-gjGho-p9J_UwLw@mail.gmail.com> <DM6PR13MB3066CF17824590C766914C2ED28F0@DM6PR13MB3066.namprd13.prod.outlook.com> <CALx6S35Q7YfH-Widw1KmYv=7VzXF0FT7D=tPnW9huXOFJHEPjQ@mail.gmail.com> <DM6PR13MB30666079D88BC4A8CBF54BB1D28C0@DM6PR13MB3066.namprd13.prod.outlook.com> <CALx6S36va5ctnMi8uSwp1=e_2_jj6e8ftwPncen_EyxjYvdcCw@mail.gmail.com> <DM6PR13MB306694860DBDA60465449ACBD28C0@DM6PR13MB3066.namprd13.prod.outlook.com> <DA0B91AF-FAEB-411A-9F6B-8F84FEFE84D2@juniper.net> <DM6PR13MB30667DE45FCD26DFB9AE107FD28C0@DM6PR13MB3066.namprd13.prod.outlook.com>
In-Reply-To: <DM6PR13MB30667DE45FCD26DFB9AE107FD28C0@DM6PR13MB3066.namprd13.prod.outlook.com>
Subject: RE: Compatibility with SRH requirement (was Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)")
Date: Sat, 30 May 2020 23:37:28 +0100
Organization: Old Dog Consulting
Message-ID: <006401d636d2$e7263040$b57290c0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0065_01D636DB.48EA9840"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIsWF0jlslINrn3oqQuDGcbyE6D1wKQoiVDAj2fbzYBVdi4OwKQ/qfDAhZ4wtUBQ28xoAH2CG7lAf9VDh8BAp8XAwHbbXKfAnYh3v6nai87oA==
Content-Language: en-gb
X-Originating-IP: 84.93.26.18
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25452.003
X-TM-AS-Result: No--23.595-10.0-31-10
X-imss-scan-details: No--23.595-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25452.003
X-TMASE-Result: 10--23.594900-10.000000
X-TMASE-MatchedRID: pS5owHKhBO3xIbpQ8BhdbMEvKlG0CjjIvMRNh9hLjFkmwE7sgPtN9tOi GFjeqLkCV6tdfPsYlsUPlEAAoiHEASmk+7p/yAwbKpEngz2rs6/4nOjGtd/rn2quw69QUQrLnnj oZ9Trly3g67+X35LTgCkN5XeYr8sG8oWuLhK0Tf2kvaQteDAtwvy9bLgnh4Ap+S5C/08hWc0jUS pSye9msPL1MwDxxhwelQ/yYOpZUjYGYKq163LsnYoQo5xl9nbEZ56CohkJYZCpUxQxmTD4QgfG0 ij0IgfAWOGJiDeupLpFC5kQvxioTQCJOXgOtwv5b8FSRpF1HQmghxnyQNIbHSGD+Fp3vZHUwQiQ 3MWIPEsl35IZc0iVfIeq7QrlDyi18Cpk6fCFCW1fYa9W9OjitRfJTYLG2XFvbVFysv2X2Rnx/hK 2QE5rfriW7TGfzwPNnCacOL7CaYlzbOi1xi7r+CD3NF+wUeO9Dvc/j9oMIgWl2W0YqJaLRVEtMR GFGDWDC+NQAuB6DKrR79T77LOI5IF/NtSFUkWCyZHnIMmQ+DjtZS7eXk7p4HQ8D+SLaQjsueok1 chxwqvJ3jhK5xvrva/xMC8mu+5XtAnihQXnq+iBFNZJ/RfzGY7P8sslRxoeyaqtcUsWOxbppfxN giuPW4VkJmWfrkeOm3oThgo4i6h2HFlMiaoq+UUfqhOIibCHezSI3KNQ1fIML9Wb3Qh/hXQ04Hb 6wtwekklFR/TZlNEkhV0S2olMbO5NCr61QzTwL4+sB3yBsckmtaWTLzkUTIhIjrzeyQMKjXRnWw YGEzqO8n2KB7QYyxQAXi4Ga9GRHxPMjOKY7A+DGx/OQ1GV8gM5kYUazKEVsOzOncrmCoMlgmiZ6 B9vB7IJLbm29xDKC/j94INE4eQF96v65meuN0AneFAX1RAH
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/JtGiu17wUZtMwBBgFGX-4ILcvfQ>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 May 2020 22:37:41 -0000

Hi Jim,

 

Isn’t this the MPLS argument? If you put the wrong label on a packet (at any point in its path) or if you forward it to the wrong next hop, then all bets are off. (Well, actually, there is a pretty good bet – the packet will be misdelivered.)

 

You are correctly saying that placing an incorrect ‘next hop’ address on a packet will result in it being delivered to the wrong next hop, and the next lookup will give undesired results because the context for the lookup is broken.

 

This is, of course, a problem with overlays and private address spaces. Just imagine if the wrong VRF identifier was used (in any form of VPN), or if the packet was tunnelled to the wrong PE. But does that stop us from using VPNs? No, it makes us be more careful with how we write the code.

 

Best,

Adrian

 

From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of James Guichard
Sent: 30 May 2020 23:05
To: John Scudder <jgs@juniper.net>
Cc: Bob Hinden <bob.hinden@gmail.com>om>; IPv6 List <ipv6@ietf.org>
Subject: RE: Compatibility with SRH requirement (was Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)")

 

Hi John,

 

Let me try to make what I said clearer as you are right, I was not saying two nodes have the same address. 

 

I was trying to point out that with any source routed solution you quite obviously need to make sure that you send the packets to the right nodes along the path specified by your policy and those nodes must support the functionality that you require for that path. Why? Because if you send a CRH packet to the *wrong* node and that node happens to have an identifier matching the one on the packet received, then it will do a lookup on that identifier and forward to the IP address resolved from the identifier -> IPv6 address mapping and that destination might not be the one you meant to send it to next on the path. Likewise, if you send a packet to the *wrong* node with G-SRH and that node does not support compression then this would be bad as well. Moral of the story I was trying to tell is don’t do that and in fact in practice it will not happen if the policy reflects the intent which in the case Tom was talking about would mean that the original node should no longer be in the policy as the policy should have been updated when the node was lost from the topology. 

 

Jim

 

 

 

From: John Scudder <jgs@juniper.net <mailto:jgs@juniper.net> > 
Sent: Saturday, May 30, 2020 4:29 PM
To: James Guichard <james.n.guichard@futurewei.com <mailto:james.n.guichard@futurewei.com> >
Cc: Tom Herbert <tom@herbertland.com <mailto:tom@herbertland.com> >; Bob Hinden <bob.hinden@gmail.com <mailto:bob.hinden@gmail.com> >; IPv6 List <ipv6@ietf.org <mailto:ipv6@ietf.org> >
Subject: Re: Compatibility with SRH requirement (was Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)")

 

Jim,

 

On May 30, 2020, at 3:46 PM, James Guichard <james.n.guichard@futurewei.com <mailto:james.n.guichard@futurewei.com> > wrote:

 

Further, in normal operation of any source routed solution you will need to make sure that packets end up at the right nodes as nasty things might happen if you don’t - this is actually especially bad with CRH as far as I can tell as if you send a packet to the wrong node and it happens to have a local identifier the same as the incoming packet its going to use that local CRH-FIB entry and send the packet to some IPv6 destination that was not the intended recipient.

 

I think you’re mistaken, or at least the situation you describe is far more pathological than the one Tom described and you’re dismissing. Consider that in order for what you say to happen, the incoming packet would have to have, as its destination address, an address of the “wrong node”. You can’t just send the packet out the wrong interface and have its CRH identifier misconstrued by any old router that touches it, the DA has to identify the node that receives it.

 

So now, by definition, you’re saying that two different nodes in the same network have the same (non link-local, also by definition) address. That’s a broken network, of course it’s doing broken things. Alternately, you didn’t mean to say that, and are mistaken about CRH processing.

 

—John