Re: Bit swapping across a DHCP Relay

[Ken Key <[e-mail]>]

Hi Folks,

Actually, it is very clear in RFC 1542, section 4.1.1 BOOTREQUEST Messages,
(specifically, Page 15, Para 6):

"All other BOOTP fields MUST be preserved intact"

The chaddr is where the MAC address is.  It must be preserved intact. 

Relay agents CANNOT touch the contents of a BOOTP/DHCP packet it is 
forwarding.  Forwarding is sent to an IP address pre-configured in
the forwarder.  The relay cannot know if the final network is Ether/Token/
Tin-Cans-And-String.  The DHCP server needs to be configured to match
the bit-string corrisponding to the MAC address on the native remote network.
This is easy to do.


[Warning, soapbox]
Now, of course, if you're talking Translation Bridging, this all goes out 
the window. Translation bridging, by it's very nature, requires that the
bridge be all seeing/all knowing so it can fake out the other side of the
translation's at all protocol levels up and down the stack.  In other words,
a "proper" translation bridge has to be SMARTER than a router, as it has to
be omnicient of all protocols that might use a MAC address in order to perform
it's magic.


Friends Don't Let Friends Translation Bridge,
K^2 
(who's been burned by entirely too many translation bridges in his 
lifetime that were too smart/dumb for their own good).


> 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  [phone] WORK: [e-mail]
>                                     HOME: [e-mail]
--
Ken Key    ([e-mail])  | cisco Systems, Inc.   | (Formerly TGV, Inc.)  
[phone] (voice) | 101 Cooper St.        | We are Borg of cisco.
[phone] (fax)   | Santa Cruz, CA  95060 | Prepare to be assimilated.