Subject: RE: [dhcwg] draft-forte-dhc-passive-dad-00.txt - client ID support

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Tue, 22 Nov 2005 17:02:07 -0500

> 1. DHCP server can get MAC addresses.   But only if it's on 
> the same wire as 
> the client; otherwise it doesn't see the wire MAC address of 
> the client - it 
> sees the wire MAC address of the router that delivers the 
> relayed packet.

Huh? The DHCP packets have the chaddr (and htype and hlen), so the DHCP
server always has the MAC.

Of course, that only works if there is a MAC address.

But ARP also only runs over Ethernet-like interfaces.

- Bernie 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Ted Lemon
> Sent: Tuesday, November 22, 2005 4:01 PM
> To: Andrea G Forte
> Cc: [email-masked]
> Subject: Re: [dhcwg] draft-forte-dhc-passive-dad-00.txt - 
> client ID support
> 
> On Tuesday 22 November 2005 13:32, Andrea G Forte wrote:
> > I am not sure I follow. Which pre-existing table are you 
> referring to?
> > One of the goals of having the two tables in the AUC is 
> that in this way
> > the traffic between AUC and DHCP server can be reduced by the AUC
> > looking at both tables and only then decide if to send a 
> frame to the
> > server or not.
> 
> The problem with snooping on the network is that it means 
> that you are going 
> to have an incomplete picture of what's going on.   In the 
> case of ARP 
> caching, that's okay, because if you don't have the 
> information in the cache, 
> you're no worse off than you otherwise would have been.   In 
> the case of a 
> MAC address to client identifier map, though, if an entry in 
> the map is 
> missing, you're going to report an address conflict to the 
> DHCP server when 
> no address conflict exists.   So I think a potentially lossy 
> cache doesn't 
> work in this case.
> 
> The more I think about this, the more it seems that it can't 
> really work.   
> The problem is that you need to have an accurate table mapping client 
> identifiers to MAC addresses.   But there is nowhere on the 
> network where you 
> can get this table.   The reasons are as follows:
> 
> 1. DHCP server can get MAC addresses.   But only if it's on 
> the same wire as 
> the client; otherwise it doesn't see the wire MAC address of 
> the client - it 
> sees the wire MAC address of the router that delivers the 
> relayed packet.
> 
> 2. Relay agent can get MAC addresses.   Okay, this is 
> workable, but now you 
> have a custom relay agent that you have to write.
> 
> 3. Not all media use MAC addresses.   No workaround for this, 
> other than 
> declaring that PDAD doesn't work on such media.
> 
> 4. Snoop.   This doesn't work because in practice you can't 
> be sure of 
> successfully snooping every packet.
> 
> So I guess if you're willing to deploy special relay agents 
> and you're willing 
> to say PDAD doesn't work on firewire or infiniband, you can 
> make it work.   
> It's probably a very reasonable line of research.   But I 
> don't see it 
> turning into something that could be readily deployed in a production 
> environment, unless you can talk Cisco, Juniper, and all the 
> other vendors 
> into updating their relay agents.
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Nov 2005 18:29:29 -0600

On Tuesday 22 November 2005 16:02, Bernie Volz (volz) wrote:
> server always has the MAC

It's true that the DHCP server does have the claimed MAC address.