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

Tom Herbert <tom@herbertland.com> Sun, 31 May 2020 01:19 UTC

Return-Path: <tom@herbertland.com>
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 844AD3A107E for <ipv6@ietfa.amsl.com>; Sat, 30 May 2020 18:19:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
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 80iUu-A0x1XV for <ipv6@ietfa.amsl.com>; Sat, 30 May 2020 18:19:01 -0700 (PDT)
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEA3B3A107D for <ipv6@ietf.org>; Sat, 30 May 2020 18:19:00 -0700 (PDT)
Received: by mail-ej1-x62f.google.com with SMTP id o15so5796686ejm.12 for <ipv6@ietf.org>; Sat, 30 May 2020 18:19:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Xds5sZdwxcoC1z0mVLWR8vxTTe0Ai9DGOZngr6T3pSc=; b=XbsZgsXPKVM4VfiRmoFwaCEFg4NCTdryQSSEQAdKrc1giyyOAw0L9tQNVIMTXGjLgj MyTqi/hqP8bK/2CP+5+9NSW8mZ6gS1CpNct8dJPtTmN5uLypGEF3cKXLB9pQ4m5rCd5c cWOeQaZPBcFRqJUNc7IT6qcqtgXlOSnV/0Kv9kjZI73LfXoCvKW+LoN9UGpOkQCAJ0S4 6ilzEIpP3G5IoCEeuFBK5SLRulAsnEtmRJawTn756Cq9cYQg1kElrey1iOp2GeVjwRG/ N91eAVc3lvqNJWTuUsONOSQ4208y/KvEG//XkxA9wXwbce0kqCkYm8Dmi3+F01gjtsKZ Mhmw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Xds5sZdwxcoC1z0mVLWR8vxTTe0Ai9DGOZngr6T3pSc=; b=FvkZcLTGLWeKA7BDxOhcWEdwgE3fJNUgMcKqvJAZU6szLskNVKVn5/1utd4Yuqw1uw ugT/DZO/A/XxJA3DIkSNULJJrDtiV71iHPk/HLR3LVGaUe79pmQn+D/WVwbNeRVOTNsX QGBxGwqvW68x1yM45c7ba5vRg1yasnSLobAcc4y7edrAAwjw1K53snaW+QroTCnEpyIv hGfFCx0R8aczRWM1ymbvtllL9OVnGvOoYApSKwNoOrgZyUgCzI2btYqeGgjq0FlRSS3h Dl2sOlutA1j1fdlY9XrBdGIhjwrFMWR4w2cQuKKHHBo5xl9xe9Sw3lEEaQApHJOji8Ri x7Mg==
X-Gm-Message-State: AOAM5326xRjVRbiVGwsRwFaGjS4YFx+W0zPBxi0FXuaSfNOCZoF71UDR 2KuVNZ0GoafMx07dsnx8jyyO6lSWF4aXW4Du55OEyg==
X-Google-Smtp-Source: ABdhPJy3DrNTX8tT+F9kf65fLvaJm78CXKR1rdhlvi90Z2qcezQ43gwgQ6oRLAbuZeFWdpZH/FwWNr3WS/HZC1xv4U8=
X-Received: by 2002:a17:906:9404:: with SMTP id q4mr13627886ejx.138.1590887938919; Sat, 30 May 2020 18:18:58 -0700 (PDT)
MIME-Version: 1.0
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> <006401d636d2$e7263040$b57290c0$@olddog.co.uk>
In-Reply-To: <006401d636d2$e7263040$b57290c0$@olddog.co.uk>
From: Tom Herbert <tom@herbertland.com>
Date: Sat, 30 May 2020 18:18:48 -0700
Message-ID: <CALx6S37Ley_Qp-m1OsxThm+V5_sWE5htUhnqs_jSc26h6yr43w@mail.gmail.com>
Subject: Re: Compatibility with SRH requirement (was Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)")
To: Adrian Farrel <adrian@olddog.co.uk>
Cc: James Guichard <james.n.guichard@futurewei.com>, John Scudder <jgs@juniper.net>, IPv6 List <ipv6@ietf.org>, Bob Hinden <bob.hinden@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/kQxZ_fm6ia15zlpmYL_z3zIZ42c>
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: Sun, 31 May 2020 01:19:04 -0000

On Sat, May 30, 2020 at 3:38 PM Adrian Farrel <adrian@olddog.co.uk> wrote:
>
> 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.)

Adrian,

It's not the same thing. For MPLS the equivalent would be more like
sending 16 bit labels instead of 32 bits. As long as all possible
receivers understand that labels or 16 bits it will work. Conceptually
the technique could be applied to any protocol field in any protocol.
For instance, IPv6 addresses in the IPv6 header could be compressed to
64 bits in some limited domain as long as _all_ the devices agree that
IPv6 addresses are 64 bits within the domain. The problem is that all
really means _all_, if even one node misses the news that addresses
have a different size then the node cannot correctly process packets--
this isn't just bad rouitng, it's fundamental and systematic
misinterpretation of a standard protocol and hence the protocol is not
robust and not backwards compatible.

Tom

>
>
>
> 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>
> Sent: Saturday, May 30, 2020 4:29 PM
> To: James Guichard <james.n.guichard@futurewei..com>
> Cc: Tom Herbert <tom@herbertland.com>om>; 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)")
>
>
>
> Jim,
>
>
>
> On May 30, 2020, at 3:46 PM, James Guichard <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
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------