Anycast provider for SMTP?

Baldur Norddahl baldur.norddahl at gmail.com
Fri Jun 19 13:43:09 UTC 2015


On 19 June 2015 at 10:39, Mike Meredith <mike.meredith at port.ac.uk> wrote:

> On Thu, 18 Jun 2015 15:51:31 -0400, "Joe Abley" <jabley at hopcount.ca>
> may have written:
> > Since DHCP uses broadcast and multicast addresses when a client is
> > discovering a server, it's not obvious why you'd have to.
>
> And broadcast/multicast when renewing a lease (DHCPREQUEST). You will
> of course see unicast addresses on the server side if the server is
> seeing requests forwarded by a udp helper.
>


RFC 2131 section 4.4.5:

"At time T1 the client moves to RENEWING state and sends (*via unicast*) a
DHCPREQUEST message to the server to extend its lease. The client sets the
'ciaddr' field in the DHCPREQUEST to its current network address. The
client records the local time at which the DHCPREQUEST message is sent for
computation of the lease expiration time. The client MUST NOT include a
'server identifier' in the DHCPREQUEST message."

Also from section 4.3.2:

"DHCPREQUEST generated during RENEWING state: 'server identifier' MUST NOT
be filled in, 'requested IP address' option MUST NOT be filled in, 'ciaddr'
MUST be filled in with client's IP address. In this situation, the client
is completely configured, and is trying to extend its lease. This message
will be *unicast*, so *no relay agents will be involved in its transmission*.
Because 'giaddr' is therefore not filled in, the DHCP server will trust the
value in 'ciaddr', and use it when replying to the client."

If there is no reply to the unicast, the client should eventually do a
fallback to broadcast, but a great number of DHCP clients fail to implement
that. They will instead keep unicasting until the lease expire, then start
over including deconfiguring the IP stack and then send DISCOVER.

Regards,

Baldur



More information about the NANOG mailing list