There is a number of rules you are not allowed to break (otherwise your bridge will do).
A port can only be a member of one bridge.
A bridge knows nothing about routes.
A bridge knows nothing about higher protocols than ARP. That's the reason why it can bridge any possible protocol possibly running on your Ethernet.
No matter how many ports you have in your logical bridge, it's covered by only one logical interface
As soon as a port (e.g. a NIC) is added to a bridge you have no more direct control about it.
| Warning |
If one of the points mentioned above is not clear to you now, don't continue reading. Read the documents listed in Appendix B first. |
If you ever tried to ping an unmanaged switch, you will know that it doesn't work, because you don't have a IP-address for it. To switch datagrams it doesn't need one. The other thing is if you want to manage the switch. It's too much strain, to take a dumb terminal, walk to the place you installed it (normally a dark, dusty and warm room, with a lot of green and red Christmas lights), to connect the terminal and to change the settings.
What you want is remote management, usually by SNMP, telnet, rlogin or (best) ssh. For all this services you will need a IP. That's the exception to the transparency. The new code allows you without any problem to assign a IP address to the virtual interface formed by the bridge-instance you will create in Section 6.2. All NIC's (or other interfaces) in your bridge will happily listen and respond to datagrams destined to this IP.
All other data will not interfere with the bridge. The bridge just acts like a switch.