From owner-freebsd-net@freebsd.org Wed Oct 2 22:51:40 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BBD0F13B2E9 for ; Wed, 2 Oct 2019 22:51:40 +0000 (UTC) (envelope-from jinmei.tatuya@gmail.com) Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46kBG25t6Vz45pB for ; Wed, 2 Oct 2019 22:51:38 +0000 (UTC) (envelope-from jinmei.tatuya@gmail.com) Received: by mail-wr1-f50.google.com with SMTP id w12so771314wro.5 for ; Wed, 02 Oct 2019 15:51:38 -0700 (PDT) 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; bh=NkBVSLrOMRh2/yuMiFMtj3rj4sA3/ihb0Bdjo/Ki9K8=; b=rGYGy1xCdmQAx08uo7TbvzhOZYVQA0gy1vAdnSDG3+9Kjw6UyBURB/Dr8cevz202FG 8HBagR/IJTQG2RwN2sRuiaiJ0SKmadjRL7f09l+jFrXsmmx2yfhhFUyu0HM6cZ8ixnNM ggs1YnFAlPbapXi9hts7AHoQBIa+aD8JMRQdNC+mfDasYHwqIgkpTWi+bUMBBp8zj5/T R31D6rvS3eF1d41hYEi8NjX17Z47Pr6q7MyxlVfAZ7+SQ48FztUKdk9OSINOI9GwBJJK cdTUxyhGERZ1qM3WF6+QikVDXjDhz8VK8SX7iWH555Lrp3AizbwthdZDgxJ5gOQlmyzw OhPg== X-Gm-Message-State: APjAAAUNh8or70urUmg0wSRpk1+kc65WgURH8DKWZ2u+O0QAkyq/Tlw4 xm0BhFooYYxHIo43/FrA0qQFutKHWF4JLe0aBDtysv6M X-Google-Smtp-Source: APXvYqwDH73xv4grWUZyK9ij0LbCivA3w+swVDmlBJwnOCz/yX3Un69QpxS8rLpHvCPBQSJzFIeic8yd/tXJ47gR1hI= X-Received: by 2002:adf:ea41:: with SMTP id j1mr4705471wrn.378.1570056696996; Wed, 02 Oct 2019 15:51:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Wed, 2 Oct 2019 15:51:25 -0700 Message-ID: Subject: Re: IPv6: Invalid nd6 entry created for an RA without an lladdr To: Ryan Stone Cc: freebsd-net X-Rspamd-Queue-Id: 46kBG25t6Vz45pB X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of jinmeitatuya@gmail.com designates 209.85.221.50 as permitted sender) smtp.mailfrom=jinmeitatuya@gmail.com X-Spamd-Result: default: False [-2.09 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.997,0]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; DMARC_NA(0.00)[wide.ad.jp]; URI_COUNT_ODD(1.00)[3]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[50.221.85.209.list.dnswl.org : 127.0.5.0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(-1.10)[ipnet: 209.85.128.0/17(-3.27), asn: 15169(-2.16), country: US(-0.05)]; FORGED_SENDER(0.30)[jinmei@wide.ad.jp,jinmeitatuya@gmail.com]; FREEMAIL_TO(0.00)[gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[50.221.85.209.rep.mailspike.net : 127.0.0.17]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[jinmei@wide.ad.jp,jinmeitatuya@gmail.com]; TAGGED_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2019 22:51:40 -0000 At Wed, 2 Oct 2019 17:04:23 -0400, Ryan Stone wrote: > > At work, our product is putting through an IPv6 conformance test and > it's found an issue in our handling of Routing Advertisements (RAs). > If we receive an RA that does not specify an lladdr, then > nd6_cache_lladdr() is called with lladdr NULL: > > https://svnweb.freebsd.org/base/head/sys/netinet6/nd6.c?revision=347984&view=markup#l1961 > > In this case, the linkhdr cache is never initialized, but we still put > the entry in the STALE state at line 2032. If lladdr is NULL shouldn't it reach line 2032? if (lladdr != NULL) { /* (7) */ nd6_llinfo_setstate(ln, ND6_LLINFO_STALE); EVENTHANDLER_INVOKE(lle_event, ln, LLENTRY_RESOLVED); } In any case, if a host receives an RA without a link-layer address option and no neighbor cache entry exists for the RA sender at that point, it shouldn't set the state of a newly created cache entry to STALE. While RFC4861 is not so explicit about this particular condition, I believe it's pretty clear from Section 6.3.4 of the RFC (it may even be questionable just to create an entry in this case, but that's probably within the scope of acceptable implementation choices as long as the entry is a mere placeholder). I also believe FreeBSD used to not do this (correctly), so if it currently sets it to STALE it's quite likely to be some regression. -- JINMEI, Tatuya