Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!hao!boulder!forys
From: forys@sigi.Colorado.EDU (Jeff Forys)
Newsgroups: comp.unix.wizards
Subject: Re: Trouble with Ethernet
Message-ID: <2358@sigi.Colorado.EDU>
Date: Sat, 26-Sep-87 22:29:31 EDT
Article-I.D.: sigi.2358
Posted: Sat Sep 26 22:29:31 1987
Date-Received: Sun, 27-Sep-87 11:54:12 EDT
References: <9473@brl-adm.ARPA> <15078@topaz.rutgers.edu>
Reply-To: forys@boulder.Colorado.EDU (Jeff Forys)
Organization: University of Colorado, Boulder
Lines: 15
Summary: Class D addrs

>  addresses beginning with 224 through 254 are reserved for "class D"
>	and "class E", which are currently not defined.  It is common
>	for software to treat all addresses 192 and above as class C.

I believe the "Class D" addresses (224-239) have been reserved for "host
groups" (for hosts that support IP multicasting).  If you dont support it,
your host should silently discard these "Class D" IP datagrams.  "Class D"
addresses then, become dyamically `bound' to a set of interfaces, on a set
of IP nets (the point is, that a "Class D" address isnt bound to a set of
unicast IP addrs).  For more information on IP multicast extensions, consult
RFC 988 (Steve Deering/Stanford).  He is also working on mods to 4.3BSD to
support these extensions (currently ftp'able from "gregorio.stanford.edu").
---
Jeff Forys @ UC/Boulder Engineering Research Comp Cntr (303-492-4991)
forys@boulder.Colorado.EDU  -or-  ..!{hao|nbires}!boulder!forys