Re: [dhcwg] [homenet] What to do when we lose DHCPv4 election?

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 17 August 2015 15:50 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5EAD1ACD83; Mon, 17 Aug 2015 08:50:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6BwC4YnMOva; Mon, 17 Aug 2015 08:50:17 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB0C01ACD7C; Mon, 17 Aug 2015 08:50:17 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 779F12016A; Mon, 17 Aug 2015 12:08:31 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id A331363B10; Mon, 17 Aug 2015 11:50:16 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 725F763AEC; Mon, 17 Aug 2015 11:50:16 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr>
In-Reply-To: <87k2suw6w2.wl-jch@pps.univ-paris-diderot.fr>
References: <87pp2oioik.wl-jch@pps.univ-paris-diderot.fr> <26135.1439773503@sandelman.ca> <87k2suw6w2.wl-jch@pps.univ-paris-diderot.fr>
X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Mon, 17 Aug 2015 11:50:16 -0400
Message-ID: <25711.1439826616@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: <http://mailarchive.ietf.org/arch/msg/dhcwg/psyU8EbE3wqHKbDenDD9HU7uZ7U>
Cc: dhcwg <dhcwg@ietf.org>, Homenet <homenet@ietf.org>
Subject: Re: [dhcwg] [homenet] What to do when we lose DHCPv4 election?
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Aug 2015 15:50:19 -0000

Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr> wrote:
    >>> 1. remain silent;
    >>> 2. remain silent in response to DHCPDISCOVER, but NAK any DHCPREQUEST; or
    >>> 3. NAK both DHCPDISCOVER and DHCPREQUEST?

    >> I think that #2 is probably correct

    > Thanks.  What after a renumbering event and the addresses that the client
    > requests are no longer onlink?  I'd like a precise reference, if that's
    > okay.

    >> 1) do Homenet-aware DHCPv4 servers pick the same rfc1918 address
    >> spaces to
    >> give out?

    > Not necessarily -- if there are multiple prefixes assigned to the link,
    > the spec doesn't say which prefix is used by each server.  (Shncpd uses
    > them all, which I'm not sure is a good idea.)  Electing a single DHCPv4
    > server for each link works around the issue.

Yes... but...  don't kill connections that don't need to be killed.

    >> 2) if a DHCPv4 server previously had given out leases, and the lease
    >>is still
    >> valid, then I think that it ought to ACK a DHCP renew.

    > What if the prefix got renumbered, and the address is no longer being
    > routed?

Those are really three questions.

1) if the v4 prefix on the link is renumbered because a different router
   won the election, then the existing router may still have connectivity,
   and may still be willing to route packets.
   (b) - there may be static IPs assigned, and there may even be port
         forwards which are linked to that first router.

2) if the v4 prefix on the link is renumbered for a different reason, but
   the router still can route/NAT packets, then it should NAK the renew.
   (b) if the v4 prefix on the outside (WAN) is not the same, then the NAT
       sessions are dead anyway, so might as well NAK the packet and push
       the host over to the winning router.

3) if the address can no longer be routed at all (no WAN link...) then
   I think it should NAK.





--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-