From owner-svn-src-all@freebsd.org Sat Aug 20 15:42:55 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 675A7BC0AEF; Sat, 20 Aug 2016 15:42:55 +0000 (UTC) (envelope-from bms@fastmail.net) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 293F218C7; Sat, 20 Aug 2016 15:42:54 +0000 (UTC) (envelope-from bms@fastmail.net) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id D9A86202F5; Sat, 20 Aug 2016 11:42:53 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Sat, 20 Aug 2016 11:42:53 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=LYUiRwQW/Yn0ths87CpgZiZgB3k=; b=LLZSIc /4dEN4bPR8LZNV0pVk97oPatlvOCi3fR3ng3wkcfoC3wx9pcCPSrpm56MmS9G4xx 6cED7pjGf5Bklbh6LnHNA5yWckKCdnmF7x7AU2Sczw+xOPK05jzcv8nJ8ctlTbLQ BTTKIgKVauYxvtk7psDSrPXudLtk41oez/bK0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=LYUiRwQW/Yn0ths 87CpgZiZgB3k=; b=UK2Esf1gn6ZpSIYDvMQ8a6+kAsRA901DcVhJimC6xoozUd7 E0+qUHSQAjkRai5wk2ZPz+x2TnwvQqkmX1DxM679iAbER7UEzzyE3f6DTP9yr5YO an48Ddp7fnG6K3gKE/1HiVFuK3lhhav1waDEp8R6PhpHndgvV4WAMazwlK/o= X-Sasl-enc: xwIL2zYPqE4RXuqZLNZV+0mKcz0R/myLAhUpidRGoScs 1471707773 Received: from pion.local (cpc96954-walt26-2-0-cust843.13-2.cable.virginm.net [82.31.91.76]) by mail.messagingengine.com (Postfix) with ESMTPA id 04CA2F296F; Sat, 20 Aug 2016 11:42:52 -0400 (EDT) Subject: Re: svn commit: r304436 - in head: . sys/netinet To: Ryan Stone References: <201608182259.u7IMx5oW002018@repo.freebsd.org> <4fbc2e1d-3a62-5963-83d5-f9c931503e51@fastmail.net> <3806700d-ed27-7915-4818-c2d64f7b806d@fastmail.net> Cc: Ryan Stone , "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" From: Bruce Simpson Message-ID: <6f4449f2-d145-8b49-c3f0-433e8ff4d2a2@fastmail.net> Date: Sat, 20 Aug 2016 16:42:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2016 15:42:55 -0000 On 20/08/16 16:27, Ryan Stone wrote: > Can you send a broadcast packet through an L3 tunnel? I thought that a > L2 tunnel was required. Yes. This is perfectly legal and necessary for forwarding of IPv4 broadcasts to work. (it is Internet Protocol after all, not Infernal-ethernet-extension Protocol. ;-)) The change is in UDP input so it will not affect routers. But if a FreeBSD system were at the end of a link layer, and was the final recipient of the IPv4 broadcast packet, then if that link layer is not Ethernet, all bets are off. That situation could occur very easily where FreeBSD is hanging off the end of a PPPoE link: e.g. consumer DSL, microwave, etc. The underlying link layer for the tunnel might be Ethernet, but it will be demuxed as a PPP tunnel. PPP is treated as a bit pipe and does not normally distinguish between unicast, broadcast, multicast. Broadcast destined for the host on its PPP address would be transported inside the tunnel, encapsulated as a normal unicast Ethernet packet. > But this mbuf flag is not guaranteed to be set in all situations; > e.g. where the link layer does not have the concept of broadcast > being distinct from other kinds of network traffic. PPP and ATM are > the most obvious examples. > > > We don't support ATM, but PPP is a good example. I hadn't thought of > that. Hm, ip_input() already has to check for a broadcast IP. What it > set M_BCAST on the mbuf at that time? ATM is one of those things everyone kind of has to support by default in some way because of the ITU ADSL specs. It is literally written into G.992.x. Linux can do it, FreeBSD can't. PPP over ATM is something BT inflicted on the UK all by themselves, though, and we wish it would just go away. Whilst your suggestion may work, it may be dangerous, as you are then stepping on the meaning of the flags. Some of them are intended to be used for one layer to signal another. M_BCAST is pretty rigidly defined in mbuf.h as "The link layer received this as a broadcast / I intended for link layer to send this as a broadcast". M_PROTOFLAGS is normally used to clear flags with different meaning in different protocol layers. M_MCAST also has similar status. On my PhD, I wrote code which uses a private Ethernet link between FreeBSD routers for load distribution; it distributes unicast traffic using IPv6 multicast. It uses multicast both as convenience, and as a way to 'channelise' traffic if the Ethernet link supports it, using multicast groups. (Modern shared memory switches can slice L2 multicast traffic like this quite efficiently. So one slice of unicast traffic could be switched across locations purely at L2. However, the distribution of actual IPv6 multicast was out of scope.) The routers have to very carefully clear M_MCAST on egress, to ensure normal L2 next-hop resolution for IPv6 destinations.