From owner-freebsd-net@FreeBSD.ORG Thu Oct 23 14:15:23 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9492216A4D8 for ; Thu, 23 Oct 2003 14:15:23 -0700 (PDT) Received: from smtpout.mac.com (A17-250-248-89.apple.com [17.250.248.89]) by mx1.FreeBSD.org (Postfix) with ESMTP id C36B543F75 for ; Thu, 23 Oct 2003 14:15:22 -0700 (PDT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id h9NLFK9D012080; Thu, 23 Oct 2003 14:15:20 -0700 (PDT) Received: from mac.com (dpvc-68-161-244-25.ny325.east.verizon.net [68.161.244.25]) (authenticated bits=0)h9NLFGbn013312; Thu, 23 Oct 2003 14:15:19 -0700 (PDT) Date: Thu, 23 Oct 2003 17:15:14 -0400 Content-Type: text/plain; delsp=yes; charset=WINDOWS-1252; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Barney Wolff From: Charles Swiger In-Reply-To: <20031023194350.GA9424@pit.databus.com> Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.552) cc: net@freebsd.org Subject: Re: Help Broadcasting a UDP packet on the LAN:URGENT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2003 21:15:23 -0000 On Thursday, October 23, 2003, at 03:43 PM, Barney Wolff wrote: > On Thu, Oct 23, 2003 at 02:23:57PM -0400, Charles Swiger wrote: >>> What are you going to do when IPv6 comes into more general use, = since >>> it has no broadcast address? >> >> Are you asking what a IPv4-to-IPv6 translator (like gif?) should do, =20= >> or >> are you worried about the case of a machine configured for IPv6 only >> and not for IPv4? I expect that most people will be using IPv4 for >> quite some time; we don't have to do something for the IPv6-only case >> to still have this be useful. > > My expectation is the same as yours, but I strongly believe that > anyone doing a new design that deliberately ignores IPv6 is being very > shortsighted. "Quite some time" is now only years, not decades. There are people using IPv6 now, certainly. There are also a number of =20= possible opinions with regard to the utility of IPv6-- whether IPv6 can =20= solve problems sufficiently better than IPv4 (or IPv4 plus NAT, =20 particularly) as to make IPv6-only networks a reasonable alternative to =20= existing IPv4 networks is an open question. Perhaps I am being shortsighted in my focus on IPv4, but I don't think =20= that I am ignoring IPv6 so much as concluding that IPv4 all-ones =20 broadcast doesn't need to have a precise cognomen in the realm of IPv6 =20= to still be useful. No doubt the kind and friendly people on this list =20= will continue to point out any major bits of stupidity or =20 shortsightedness on my part in the future. :-) >> Multicast and broadcast addressing are working at layer-3, but the >> point of using VLAN tags is to create logically 'seperate' networks >> where the flow of traffic is being handled/segregated at layer-2 =20 >> rather >> than layer-3. > > VLANs are meant to allow segregating a physical switch into multiple > logical switches. That's the primary usage, certainly. You can use VLAN tags on a =20 non-switched environment, however, just as you can send packets for =20 more than one IP subnet over the same physical cabling. > VLAN tagging is used on inter-switch trunks, so > that multiple logical switches can be connected by a single physical > circuit. In either case, whether the switch *itself* (that is, its > management interface) is on a particular VLAN depends on whether it > has a level-3 address on that VLAN, at least in the normal case that > a VLAN corresponds to an IP subnet. The switches I have experience with-- 3com Superstack 2 and 3 family, =20= and Cisco equivalents-- implement VLAN membership on a per-port basis =20= via 802.1Q tagging of the packets (which can be used for hosts and not =20= just switches), as well as inter-switch connectivity (what 3com calls =20= VLT for Virtual LAN Trunk). > Since we're talking here of sending IP packets, that reasoning would =20= > seem to apply. (For level 2 purposes such as spanning tree, of course = =20 > the switch is "on" every > configured VLAN.) Things aren't always as simple-- please see page 201 of the following =20= document: http://support.3com.com/infodeli/tools/switches/s_stack2/1695/=20 manual.a01/manage.pdf "Figure 50 shows a network containing VLANs 1 and 2, and they are connected using the 802.1Q-tagged link between Switch B and Switch C. By default, this link has a path cost of 100 and is automatically =20 blocked because the other Switch-to-Switch connections have a path cost of 36 (18+18). This means that both VLANs are now subdivided =97 VLAN 1 on Switch units A and B cannot communicate with VLAN 1 on Switch C, and VLAN 2 on Switch units A and C cannot communicate with VLAN 2 on Switch B. [ ...diagram unrepresentable in ASCII... ] To avoid any VLAN subdivision, we recommend that all connections carrying traffic for multiple VLANs have a lower path cost than those carrying traffic for single VLANs. You can do this in two ways: 1=01 Using connections that have a higher bandwidth (which, by default, have a lower path cost) 2=01 Lowering the path cost of the connections using a Network Management application" >> The all-ones broadcast is supposed to go to all physically connected >> network segments, regardless of whether a particular interface is >> ifconfig'ured with an IP that is part of a particular layer-3 subnet. >> You should be able to send the broadcast packet out from an interface >> which is up but does not have an IPv4 address assigned, right? > > In what sense are you using "supposed" - required by some standard, > or simply what you'd like to have happen? If the former, please point > to the standard. Sending a packet out from an interface with no IP > address assigned leads immediately to the question of what source IP > address to use, and how a responder knows where to send its response. They might use a source IP that starts with 169.254, per technologies =20= called Rendevous at Apple, or "zero configuration" (Microsoft). http://www.zeroconf.org has IETF drafts which discuss this, and might =20= also explain my interest in bootstrapping a network without necessarily =20= having host network interfaces explicitly configured with valid IPs. > Among other things, the thing at the other end of the cable from a > port using VLAN tagging may not approve of a frame sent > with no tag (although cisco's can be configured with a default VLAN > for that case). Agreed, using a VLAN tag of 0 or 1 which represents the "default VLAN". --=20 -Chuck