From owner-freebsd-net@FreeBSD.ORG Wed Jun 20 21:20:15 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A5BC01065674; Wed, 20 Jun 2012 21:20:15 +0000 (UTC) (envelope-from rpaulo@felyko.com) Received: from felyko.com (stark.strangled.net [IPv6:2607:f2f8:a528::3:1337:ca7]) by mx1.freebsd.org (Postfix) with ESMTP id 864198FC14; Wed, 20 Jun 2012 21:20:15 +0000 (UTC) Received: from [IPv6:2620:149:4:f01:95db:5be2:ed96:7cb] (unknown [IPv6:2620:149:4:f01:95db:5be2:ed96:7cb]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id E384B3EC3A; Wed, 20 Jun 2012 14:20:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=felyko.com; s=mail; t=1340227215; bh=RlTOdloEm1wnc/eoNZI7bxDEZ5EL1FFOwl4uMAVgb68=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=iKBjAEMu2oLIlTmM1nmu2AMKke1FJ4rBLA+ynv7zPo2XmhvSAIZboltudLKRxjEgF jlHwzg95/S9V2rVWZtG6HBllhoQWNwqiHJ4FDDyn2Z13Pngxw4mJpB9keOztoGWqOI I7uIMhJ33pRKBEHw1M6gM9lwy5PZ3t9hg3pkbf8A= Content-Type: text/plain; charset=GB2312 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1477\)) From: Rui Paulo In-Reply-To: Date: Wed, 20 Jun 2012 14:20:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <36507982-766F-4AD3-96A3-6872B9F32793@felyko.com> References: To: GuYong , bms@freebsd.org X-Mailer: Apple Mail (2.1477) Cc: freebsd-net@freebsd.org Subject: Re: Question about MLDv2 implemenation in Kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Jun 2012 21:20:15 -0000 On 20 Jun 2012, at 01:12, GuYong wrote: > 1. RFC3810 clause 6.1 mentions there is a Source Retransmission = Counter associated to each source, so that the merged report could = contain the content that is interrupted by a new state change report = BUT, I didn't see this is implemented currently! I think this is stored in the mli_rv variable and decremented = accordingly. > 2. Regarding the 'Older Version Querier Present timer', the code is = like this:old_version_timer =3D (mli->mli_rv * mli->mli_qi) + = mli->mli_qri; > while mli->mli_qri =3D maxdelay, and maxdelay =3D = ntohs(mld->mld_maxdelay). BUT, mld_maxdelay is in units of = milliseconds (clause 5.1.3), I think it should be divided by 1000 before = it adds to old_version_timer. I think you're right and it should be divided by MLD_TIMER_SCALE. > 3. According to RFC, a node MUST accept and process any Query whose = IP Destination Address field contains *any* of the address (unicast or = multicast) assigned to the interface on which the Query arrives. = BUT, I see the code only accept General Query addressed to FF02::1. Hmm, I disagree. Here's what the RFC says: 5.1.15. Destination Addresses for Queries In MLDv2, General Queries are sent to the link-scope all-nodes multicast address (FF02::1). Multicast Address Specific and Multicast Address and Source Specific Queries are sent with an IP destination address equal to the multicast address of interest. *However*, a node MUST accept and process any Query whose IP Destination Address field contains *any* of the addresses (unicast or multicast) assigned to the interface on which the Query arrives. This might be useful, e.g., for debugging purposes. My reading of it suggests that we are doing the right thing. We do = accept it and process it, but, like the text implies, we shouldn't take = any action. -- Rui Paulo