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
- Bit swapping across a DHCP Relay Eric Peterson
- Re: Bit swapping across a DHCP Relay Richard Letts
- Re: Bit swapping across a DHCP Relay Eric Peterson
- Re: Bit swapping across a DHCP Relay Ken Key