[dhcwg] Sending Rebind upon link-layer address change (rfc3315bis)

"Templin, Fred L" <Fred.L.Templin@boeing.com> Thu, 11 August 2016 15:08 UTC

From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: "<dhcwg@ietf.org>" <dhcwg@ietf.org>
Thread-Topic: Sending Rebind upon link-layer address change (rfc3315bis)
Thread-Index: AdHz4ZCUjU/FA9MiSmKfxRC3gKOpMA==
Date: Thu, 11 Aug 2016 15:07:51 +0000
Message-ID: <6cf583d1d21f4115b25c68e19d8e693e@XCH15-05-05.nw.nos.boeing.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/_XxtsdnArmCK7yKPND1lzt4TeV0>
Subject: [dhcwg] Sending Rebind upon link-layer address change (rfc3315bis)
Precedence: list

RFC3315(bis) gives a list of conditions under which the client may send a Rebind
message. I would like to see an additional condition added for the case that
the client's link-layer address(es) have changed.

In IPv6 ND, a node announces a link-layer address change by sending unsolicited
NAs. However, these messages are unacknowledged, and are not secured. So,
a rogue client on the link could send spoofed NA messages even if the link is
secured through link-layer encryption and/or physical security. Using DHCPv6
Rebind for this addresses thewse points.

Therefore, I suggest the following changes: 

> 15) Section 17.1.5, add a trailing sentence to this section:
>     "The client MAY send a Rebind message if its link-layer
>     address(es) have changed, e.g., to update any cached
>     link-layer address information."
> 
> 18) Section 17.1.12, add the following as a new last item in the
>     bulleted list:
>
>   o The requesting router's link-layer address(es) change.

Thanks - Fred
fred.l.templin@boeing.com

[dhcwg] Sending Rebind upon link-layer address ch… Templin, Fred L