Re: Bit swapping across a DHCP Relay

Eric Peterson <eric@xylan.com> Fri, 25 October 1996 19:49 UTC

Received: from cnri by ietf.org id aa17457; 25 Oct 96 15:49 EDT
Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa20227; 25 Oct 96 15:49 EDT
Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AA16333; Fri, 25 Oct 1996 15:41:30 -0400
Date: Fri, 25 Oct 1996 15:41:30 -0400
Message-Id: <9610251818.AA23560@omni.xylan.com>
Errors-To: droms@bucknell.edu
Reply-To: dhcp-v4@bucknell.edu
Originator: dhcp-v4@bucknell.edu
Sender: dhcp-v4@bucknell.edu
Precedence: bulk
From: Eric Peterson <eric@xylan.com>
To: Multiple recipients of list <dhcp-v4@bucknell.edu>
Subject: Re: Bit swapping across a DHCP Relay
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: Discussion of DHCP for IPv4
Mime-Version: 1.0
X-Mailer: ELM [version 2.4ME+ PL15 (25)]

Richard Letts writes:
> Eric Peterson wrote....
> > 
> >    3. What RFC defines this behavior? (I examined rfc1542, and although it
> > 	discusses the issue of bit-ordering in the 'chaddr' field, it
> > 	hardly mentions the actual MAC address.)
> > 
> If I were implementing a DHCP client/forwarder I'd use canonical addresses
> thoughought. The Client would put its canonical address inside the packet,
> which would not be touched by the relay. when the response comes back from the
> DHCP server the relay converts the canonical address inside the packet into
> the form required for the physical interface.

	I agree that the relay *should* put the address on the network in
	the form required by that network media; what I didn't understand
	was why the relay (in this case) was NOT doing that, but was
	putting out a canonical address on a non-canonically addressed 
	network (FDDI).

	The reasoning given for not putting the network address in canonical
	form (in the internal DHCP chaddr field) was to streamline updating ARP
	caches (which store things differently for different media, and even
	stranger for token-ring...).

> The alternative is for the client to put the mac address in in the form
> requireed for the medium (canonical for ethernet, non-canonical for broken
> ring and FDDI, and the relay agents NOT to touch it, but to use it as-is.
> 
> ie it doesn't matter what the client does, as long as it is consistant.
> the Relayshould never touch the contents of the packet, EXcept to put its IP
> address in the field inside the packet if it doesn't already have one.
>
> As there is a a HWTYPE field the Server should know what sort of address it
> is dealing with.

	Exactly.  I'm just trying to make my case against the maker of
	the router that does the (to me) broken MAC bit-swapping.  As I
	mentioned before, there's not much in rfc1542 that specifies what
	MAC goes on the network (though I have a feeling that there must
	be a document somewhere that says one's not supposed to put an
	address on the network that's bit swapped incorrectly for that
	media type).

Thanks for the info,
Eric

-- 
Eric Peterson WB6PYK  (818)878-4537 WORK: eric@xylan.com
                                    HOME: eric@rain.org