Re: [v6ops] IPv6 link-local traffic questions
Stewart Bryant <stewart.bryant@gmail.com> Fri, 20 March 2020 15:19 UTC
Return-Path: <stewart.bryant@gmail.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 33D6D3A09EC; Fri, 20 Mar 2020 08:19:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmail.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 J8uefOI1A48o; Fri, 20 Mar 2020 08:19:12 -0700 (PDT)
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 D75AC3A09F8; Fri, 20 Mar 2020 08:19:11 -0700 (PDT)
Received: by mail-wr1-x42f.google.com with SMTP id h9so7929817wrc.8; Fri, 20 Mar 2020 08:19:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oQw3l80YLOHIvxC5YrL558YVDypcKPtQkPVvP0htK7s=; b=Fuf1LxBqJvreus61Aa+w5k8Yz83WwofyihjBEuMKtSYoZLkpXqvL0+LWsshUfDcmuT cLtiOxPPOCeezdovl/29ZyThq+YqOvfexxqcWbI7P85DnjptKZxlZzdYo5duJCpwPIuu p2SSBF92h0P52XroBpvL42QOVKuyvtlitxvcNtQi8zJWDZsGY25vM8W90TxPLho14HLl QAM0gobmXrloa8bclSgyUi4d6jtriyj2Tzb4kG2cK8fDZJBJtY95+jLU4KonrXfRk7eC wxLOymhLs/unfDpc1e/rFB22buBrn81MMxnmTNHKh4w8Ho0i7b53ejYJfF8BjLxrT6FZ 2cFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oQw3l80YLOHIvxC5YrL558YVDypcKPtQkPVvP0htK7s=; b=VBbo2EGrkeKrj4i0x/PvbGIGfvf8+Xqo3+HGucnBDj+ee9KTW0EU5uAMfezWALpOmH hdpBBjglR6R1EtNki9HOPF8mTKE9AWLj6DRogMIEHjZKTofIgcOLJymIrx9BxlqO+fvO sFKmY1xOQ9dXjw0nsCYpi+aL7VGMxwQfkUTN29WPCUhSJLMlDNtvH6LqrTIeK7pyDMbC S+lMNfZ8e/UmfeFY11CqQadIX/A/jcdddqtTEad8c37ZakbLkMQvoU5u4m0KQzxagTP4 zsNFH2JPKG+33vjC/r+QJMoVmcNaoBkkHLsBvV0Bvm/q7Yzb7MuFhfp+Swxxp0waEEsn MVSA==
X-Gm-Message-State: ANhLgQ3BaYNLBzNPcWgWyyb5EzYsXZWzq60JcplzYX99GK1p/YCX9Em+ u3IpO6s5f2zmzAltNl2/Zes=
X-Google-Smtp-Source: ADFU+vsYlNGVwXjcO6P74VVTDmyDs9XasLNojfMRsNPfV3+uQfmmtAlv9t+rGvATe4KjsIDXyrt+OQ==
X-Received: by 2002:a05:6000:cb:: with SMTP id q11mr1724977wrx.25.1584717550040; Fri, 20 Mar 2020 08:19:10 -0700 (PDT)
Received: from broadband.bt.com ([2a00:23a8:4140:0:c881:c394:4fcb:1056]) by smtp.gmail.com with ESMTPSA id i1sm8999916wrs.18.2020.03.20.08.19.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Mar 2020 08:19:08 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
Subject: Re: [v6ops] IPv6 link-local traffic questions
From: Stewart Bryant <stewart.bryant@gmail.com>
In-Reply-To: <20200320143009.GA19351@faui48f.informatik.uni-erlangen.de>
Date: Fri, 20 Mar 2020 15:19:07 +0000
Cc: Stewart Bryant <stewart.bryant@gmail.com>, Gyan Mishra <hayabusagsm@gmail.com>, 6man <6man@ietf.org>, V6 Ops List <v6ops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <046A495C-068F-4F72-8545-003970DF3D25@gmail.com>
References: <20200312000016.GO54522@faui48f.informatik.uni-erlangen.de> <CAFU7BAT-LP5TC9dpYw+5j8T8H_8XMF=tcY-Qsbg5=MOgUYNk+A@mail.gmail.com> <CABNhwV1uCFHCO9r3NK7QeqZ4gvrquoD_534LXoykaf59S48rpA@mail.gmail.com> <20200320143009.GA19351@faui48f.informatik.uni-erlangen.de>
To: Toerless Eckert <tte@cs.fau.de>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/0rTU2xTjXZDSW45Y-Oi16kn4ZIY>
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: Fri, 20 Mar 2020 15:19:15 -0000
> On 20 Mar 2020, at 14:30, Toerless Eckert <tte@cs.fau.de> wrote: > > On Sat, Mar 14, 2020 at 02:07:34AM -0400, Gyan Mishra wrote: >> Jen >> >> I always wondered why RFC 4862 states that ND & RD packets have TTL 255. >> We have run into so many PSIRT bugs with ND which makes it more problematic >> having the TTL 255. > > Is there anything that would makes you think 255 is a worse > choice for security than 1 ? Or is it just implementation bugs ? > > Cheers > Toerless 1 anyone can fake. 255 can only come from a neighbour which it is used as a simple security check. Stewart > >> Since ND & RD packets would always be local scope in your response to >> Toreless you mentioned that GTSM that ND using 255 is kind of an example of >> GTSM in the sense that the TTL is set to 255 for a direct neighbor >> adjacency. I think though the security issues of TTL 255 with ND/RD >> packets seem to make security a bigger issue then just leaving TTL=1. >> >> Gyan >> >> On Wed, Mar 11, 2020 at 8:34 PM Jen Linkova <furry13@gmail.com> wrote: >> >>> On Thu, Mar 12, 2020 at 11:01 AM Toerless Eckert <tte@cs.fau.de> wrote: >>>> >>>> Sorry for cross posting, but this is both ops and arch questions. >>>> >>>> I was trying to find any generic description that/if link-local IPv6 >>>> traffic MUST/SHOULD use Hop-count 1, but could not find one in >>>> rfc8200 or rfc4291 and its updates. Instead, text like >>>> MUST set Hop-limit to 1 is repeated in various RFCs using link-local >>>> IPv6 traffic. >>> >>> I believe it depends what you are trying to achieve. If you want to >>> make sure that the traffic never leaves the network - then hop limit = >>> 1 helps. But using link-local sources/destinations would help even >>> better if the routers comply with RFC4291 Section 2.5.6 >>> If you want to make sure those packets are not sent by a malicious >>> party from outside - hop limit shall be 255. >>> For example, see RFC4861 Section 3.1 >>> >>>> Am i overlooking something ? Or is this intentional in the IPv6 >>> architecture ? >>>> >>>> If intentional, i guess it means: Any RFC introducing some type of >>> link-local >>>> traffic can specify Hop-limit requirements for its traffic. As in >>>> "our WG likes 42 as the Hop-limit" (silly to me, but should be fine with >>>> IPv6 architecture then, right ?). >>>> >>>> In one of my draft document reviews using such link-local IPv6 traffic, >>>> EricV brought up the Q if that traffic shouldn't use RFC5082 instead >>>> of Hop-Count 1 too. But given how we do not seem to have architectural >>>> recommendations for TTL=1 (unless, quite likely i overlook something), >>>> and given how i am not aware of any actual use of GTSM, i am quite >>>> weary to go down that route. Aka: Would like learn of actual uses of >>>> GTSM with IPv6. >>> >>> Neighbor Discovery. >>> >>>> There is an additional set of consideration re. link-local traffic >>>> when trying to use it as a HW accelerated tunneling mechanism across >>> links, >>>> a use we both have in ANIMA, and maybe get the same in BIER (probably >>>> other WGs too, not sure). >>>> >>>> In implementations, i have seen quite a range of issues with >>>> accelerated forwarding planes across link-local addressed tunnels, >>>> and when using non-link-local addresses (loopback addresses), >>>> the HW plane forwarding might have issues doing HW forwarding, because >>>> usually TTL=1 is only used for control plane traffic. Of course, >>>> this is not a good architectural argument, but if given architectural >>>> leeway to even choose 42, maybe GTSM/255 is easier to be supported >>>> across various HW accelerated forwarding planes than 1. >>>> >>>> Opinions and experiences welcome! >>> >>> If you control the router I'd say 'link-local source/destination, >>> HL=255 AND RFC4291 would be the best option. >>> >>> I did see a few devices somewhere far away sending me ICMPv6 (packet >>> too big) from their link-local addresses but it was not very common >>> case. >>> >>> -- >>> SY, Jen Linkova aka Furry >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >> >> >> -- >> >> Gyan Mishra >> >> Network Engineering & Technology >> >> Verizon >> >> Silver Spring, MD 20904 >> >> Phone: 301 502-1347 >> >> Email: gyan.s.mishra@verizon.com > >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > > -- > --- > tte@cs.fau.de > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > --------------------------------------------------------------------
- IPv6 link-local traffic questions Toerless Eckert
- Re: [v6ops] IPv6 link-local traffic questions Jen Linkova
- Re: [v6ops] IPv6 link-local traffic questions Mark Smith
- Re: [v6ops] IPv6 link-local traffic questions Toerless Eckert
- Re: [v6ops] IPv6 link-local traffic questions Toerless Eckert
- Re: [v6ops] IPv6 link-local traffic questions Erik Kline
- Re: [Bier] [v6ops] IPv6 link-local traffic questi… Tony Przygienda
- Re: [Bier] [v6ops] IPv6 link-local traffic questi… Toerless Eckert
- Re: [v6ops] IPv6 link-local traffic questions Gyan Mishra
- Re: [v6ops] IPv6 link-local traffic questions Gyan Mishra
- Re: [v6ops] IPv6 link-local traffic questions Karl Auer
- Re: [v6ops] IPv6 link-local traffic questions Ole Troan
- Re: [v6ops] IPv6 link-local traffic questions Gert Doering
- Re: [v6ops] IPv6 link-local traffic questions Gyan Mishra
- Re: [v6ops] IPv6 link-local traffic questions Gyan Mishra
- Re: [v6ops] IPv6 link-local traffic questions Gyan Mishra
- Re: [v6ops] IPv6 link-local traffic questions Toerless Eckert
- Re: [v6ops] IPv6 link-local traffic questions Stewart Bryant
- Re: [v6ops] IPv6 link-local traffic questions Toerless Eckert
- Re: [v6ops] IPv6 link-local traffic questions Tony Przygienda
- Re: [v6ops] IPv6 link-local traffic questions Gyan Mishra
- Re: [v6ops] IPv6 link-local traffic questions Mark Smith
- Re: [v6ops] IPv6 link-local traffic questions Erik Kline
- Re: [v6ops] IPv6 link-local traffic questions Owen DeLong
- Re: [v6ops] IPv6 link-local traffic questions Brian E Carpenter
- Re: [v6ops] IPv6 link-local traffic questions Owen DeLong
- Re: [v6ops] IPv6 link-local traffic questions Gert Doering
- Re: [v6ops] IPv6 link-local traffic questions Brian E Carpenter
- Re: [v6ops] IPv6 link-local traffic questions Owen DeLong
- Re: [v6ops] IPv6 link-local traffic questions Gert Doering
- Re: [v6ops] IPv6 link-local traffic questions Philip Homburg
- Re: [v6ops] IPv6 link-local traffic questions Brian E Carpenter
- Re: [v6ops] IPv6 link-local traffic questions Jen Linkova