Date: Thu, 23 Oct 2003 17:15:14 -0400 From: Charles Swiger <cswiger@mac.com> To: Barney Wolff <barney@databus.com> Cc: net@freebsd.org Subject: Re: Help Broadcasting a UDP packet on the LAN:URGENT Message-ID: <FE50EDE9-059D-11D8-92E1-003065ABFD92@mac.com> In-Reply-To: <20031023194350.GA9424@pit.databus.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FE50EDE9-059D-11D8-92E1-003065ABFD92>