[dhcwg] Comments on draft-ietf-dhc-addr-notification-00
Bernie Volz <bevolz@gmail.com> Thu, 27 July 2023 16:15 UTC
Return-Path: <bevolz@gmail.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96B83C14E513; Thu, 27 Jul 2023 09:15:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1p4lBMXa6dm; Thu, 27 Jul 2023 09:15:09 -0700 (PDT)
Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EDA4C14CE52; Thu, 27 Jul 2023 09:15:01 -0700 (PDT)
Received: by mail-vs1-xe33.google.com with SMTP id ada2fe7eead31-4475df91bb1so458587137.3; Thu, 27 Jul 2023 09:15:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690474500; x=1691079300; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=N50QXmJ6gJ2umIlEPJTdH6/BArqn69x0C23kj+Ro7Oo=; b=DKHzh/akgQNvrQZ0xi9j4HbGdNmnG+IFq53aZQVI3PRQSLqB2MPx8QZqwp88M3LEKH eOWVf8Im3zMtTadkBJLbIobQv99XQIfmUlTmtF+kP3SybSsTkMZ6zL4u3UEQMr4qTz9j ZgG4b17vLyGb7kP40zOtu7Ew3QprObADb9KbBMpewwBTbg9jUQSW+6DL3Yvb2ZT33eIe rDfTwa+5GBnfpKp+ah/4yALf5Pw3i10wADKGeopra1q1WKfRQIgJYO9ncnD+R1xvHEHH ZMOm3uBgQxZPNL4Gfuv4d4PiEH/yyOEa6HgyTuJEBcNztgE1dzg/9seIGOTWPyIEqm7T +WWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690474500; x=1691079300; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=N50QXmJ6gJ2umIlEPJTdH6/BArqn69x0C23kj+Ro7Oo=; b=KvtawbHoAWR2WWlvRLC/7SS8P/8yBVCVi6+xN+/1MQQuSWX/eBj0VDXioM8XSZ4cuB J/n/7YJplp5PernDF7yhTysGYQTkZhhd7MsCbV0SeckMe+4NpuIBfn+A5vm/Vfu8owjn YEMTxS4xfg3nH2heJmPFGk2DO3LLVAVzIRRFzn7tjHY1hT0v3p4WR+BMSj32BeLfLXK1 gENUj8xdGym/SakP3hFMbHYgMkqlDlN0GPCUVTJwX1C7Rgyymuu6mBISMFE7C604liLi rmCCmIDCCL2N2/Sn6804GAp0KPDwVXf1QiFhbI5n741CQzJt+TlVB5nhmp8OQAVhO6K/ f8hA==
X-Gm-Message-State: ABy/qLZetMHWsFPouUy1jBmHVEh8rHN8lZ2pRkHPMfn9vPKsqTJr/3KN 4a5o1oshwvgZbS/zwPczH16zBITNwA==
X-Google-Smtp-Source: APBJJlFXt+rLPbiwiY0jvkeFF/p8Inw7radI3mJMDmIR5gk/owxlB+Be6EHkukYo2W5/1do7tInHfA==
X-Received: by 2002:a67:fc13:0:b0:447:6a0a:4c5f with SMTP id o19-20020a67fc13000000b004476a0a4c5fmr916994vsq.18.1690474499863; Thu, 27 Jul 2023 09:14:59 -0700 (PDT)
Received: from smtpclient.apple (d-24-233-121-124.nh.cpe.atlanticbb.net. [24.233.121.124]) by smtp.gmail.com with ESMTPSA id y3-20020a0cd983000000b0062de6537febsm524112qvj.58.2023.07.27.09.14.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 27 Jul 2023 09:14:59 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Bernie Volz <bevolz@gmail.com>
Mime-Version: 1.0 (1.0)
Date: Thu, 27 Jul 2023 12:14:48 -0400
Message-Id: <6AEF59BC-A4FE-4779-A3D3-940486991141@gmail.com>
References: <8BF13303-C9F3-4921-89A1-FEE7D089F816@gmail.com>
Cc: dhcwg <dhcwg@ietf.org>
In-Reply-To: <8BF13303-C9F3-4921-89A1-FEE7D089F816@gmail.com>
To: draft-ietf-dhc-addr-notification@ietf.org
X-Mailer: iPad Mail (20F75)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/TKd7NbNsLBEPuwM3PFq4cqFvunA>
Subject: [dhcwg] Comments on draft-ietf-dhc-addr-notification-00
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Dynamic Host Configuration <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: Thu, 27 Jul 2023 16:15:14 -0000
Hello: Below are my comments on draft-ietf-dhc-addr-notification-00 … please view these as individual comments (with WG co-chair hat off). Registering Self-generated IPv6 Addresses using DHCPv6 draft-ietf-dhc-addr-notification-00 *** NOTE: My comments should be preceded by "BV>". 1. Introduction It is very common operational practice, especially in enterprise networks, to use IPv4 DHCP logs for troubleshooting or security purposes. Examples of this include a helpdesk dealing with a ticket BV> Perhaps "help desk"? such as "The CEO's laptop cannot connect to the printer"; if the MAC address of the printer is known (for example from an inventory system), the IPv4 address can be retrieved from the DHCP logs and the printer pinged to determine if it is reachable. Another common example is a Security Operations team discovering suspicious events in outbound firewall logs and then consulting DHCP logs to determine which employee's laptop had that IPv4 address at that time so that they can quarantine it and remove the malware. This operational practice relies on the DHCP server knowing the IP address assignments. Therefore, the practice does not work if static IP addresses are manually configured on devices or self-assigned addresses (such as when self-configuring an IPv6 address using SLAAC [RFC4862]) are used. The lack of this parity with IPv4 is one of the reasons which may be hindering IPv6 deployment, especially in enterprise networks. This document provides a mechanism for a device to inform the DHCPv6 server that it has a self-configured IPv6 address (or has a statically configured address), and thus provides parity with IPv4 in this aspect. BV> I'm not sure how strong this argument is. In IPv4, the network does BV> not learn of "static" addresses; the reason it works better in IPv4 BV> is that (almost) all clients implement DHCPv4 - whereas some (Google) BV> have decided not to implement DHCPv6 and hence that is reason this BV> is needed for IPv6. 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Registration Mechanism Overview The DHCPv6 protocol is used as the address registration protocol when a DHCPv6 server performs the role of an address registration server. The DHCPv6 IA Address option [RFC8415] is used to specify the address to be registered. After successfully assigning a self-generated IPv6 address on one of its interfaces, a client implementing this specification SHOULD multicast an ADDR-REG-INFORM message in order to inform the DHCPv6 server that this self-generated address is in use. BV> Perhaps say "(see Figure 1)" or "as shown in Figure 1"? +----+ +----------------+ +---------------+ |Host| |First-hop router| |Addr-Reg Server| +----+ +----------------+ +---------------+ | SLAAC | | |<--------->| | | | | | | ADDR-REG-INFORM | |------------------------------------------------->| | | |Register / log | | ADDR-REG-REPLY |address |<------------------------------------------------- Figure 1: Address Registration Procedure 4. DHCPv6 ADDR-REG-INFORM Message The DHCPv6 client sends an ADDR-REG-INFORM message to inform that an IPv6 address is in use. The format of the ADDR-REG-INFORM message is described as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | msg-type | transaction-id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . options . . (variable) . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ msg-type Identifies the DHCPv6 message type; Set to ADDR-REG-INFORM (TBA1). transaction-id The transaction ID for this message exchange. options Options carried in this message. Figure 2: DHCPv6 ADDR-REG-INFORM message The ADDR-REG-INFORM message MUST NOT contain server-identifier option BV> Use "Server Identification option" as that is official name? and MUST contain the IA Address option. The ADDR-REG-INFORM message is dedicated for clients to initiate an address registration request toward an address registration server. Consequently, clients MUST NOT put any Option Request Option(s) in the ADDR-REG-INFORM message. Clients MAY include other options, such as the Client FQDN Option [RFC4704]. BV> I think some text here would be useful as to what should be placed in BV> the preferred/valid lifetime values (are both used or is preferred perhaps BV> set to 0 as it really isn't applicable to registration). Also, do static BV> addresses have different (valid) lifetimes than RA (PIO) derived ones BV> (which likely use the remaining preferred/valid lifetimes from the PIO BV> times)? Clients MUST discard any received ADDR-REG-INFORM messages. Servers MUST discard any ADDR-REG-INFORM messages that meet any of the following conditions: * the address is not appropriate for the link; * the message does not include a Client Identifier option; * the message includes a Server Identifier option; * the message does not include the IA Address option; * the message includes an Option Request Option. 5. DHCPv6 ADDR-REG-REPLY Message The DHCPv6 server sends an ADDR-REG-REPLY message in response to a valid ADDR-REG-INFORM message. The format of the ADDR-REG-REPLY message is described as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | msg-type | transaction-id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . options . . (variable) . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ msg-type Identifies the DHCPv6 message type; Set to ADDR-REG-REPLY (TBA2). transaction-id The transaction ID for this message exchange. options Options carried in this message. Figure 3: DHCPv6 ADDR-REG-REPLY message The ADDR-REG-INFORM message MUST contain an IA Address option for the address being registered. BV> This is "ADDR-REG-REPLY" message. BV> What should be put in lifetimes in IA Address option? Should these BV> just be values received by server or should fields be set to 0 and BV> ignored by client receiving the message? Servers MUST ignore any received ADDR-REG-REPLY messages. Clients MUST discard any ADDR-REG-REPLY messages that meet any of the following conditions: * The IPv6 destination address does not match the address being registered. * The IA-Address option does not match the address being registered BV> Add period? Or should this be list that uses semicolons? * The address being registered is not assigned to the interface receiving the message. * The transaction-id does not match the transaction-id the client used in its ADDR-REG-INFORM messages. 6. DHCPv6 Address Registration Procedure 6.1. DHCPv6 Address Registration Request The client sends a DHCPv6 ADDR-REG-INFORM message to the address registration server to the All_DHCP_Relay_Agents_and_Servers multicast address (ff02::1:2). The client MUST only send the packet on the network interface that has the address being registered (i.e. if the client has multiple interfaces with different addresses, it should only send the packet on the interface with the address being BV> This "should only" is a bit weird given the MUST. But I think the BV> idea is similar to that in RFC8415 section 17.1? Maybe suggest BV> readers refer to that section? registered). The client MUST send the packet from the address being registered. This is primarily for "fate sharing" purposes - for BV> I think highlighting this difference from the normal client behavior BV> to use the link-local address is important to make it stand out? BV> Perhaps say, "Note that the client MUST NOT send this message using its BV> link-local address as for normal DHCPv6 client behavior as in RFC8415."? example, if the network implements some form of L2 security to prevent a client from spoofing other clients' addresses this prevents an attacker from spoofing ADDR-REG-INFORM messages. The client MUST send separate messages for each address being registered. BV> Would repeating that only one IA Address option with the address BV> being registered MUST be included here be useful? The client MUST include a Client Identifier option in the ADDR-REG- INFORM message. The client MUST generate a transaction ID and insert this value in the "transaction-id" field. The client MUST only send the ADDR-REG-INFORM message for valid ([RFC4862]) addresses of global scope ([RFC4007]). The client MUST NOT send the ADDR-REG-INFORM message for addresses configured by DHCPv6. The client MUST NOT send the ADDR-REG-INFORM message if it has not received any Router Advertisement message with either M or O flags set to 1. After receiving this ADDR-REG-INFORM message, the address registration server SHOULD verify that the address being registered is "appropriate to the link" as defined by [RFC8415]. If the server believes that address being registered is not appropriate to the BV> "that [the] address"? link [RFC8415], it MUST drop the message, and SHOULD log this fact. If the address is appropriate, the server: * SHOULD register or update a binding between the provided Client Identifier and IPv6 address in its database; BV> Add something about registering or extending an existing reservation BV> by the [valid] lifetime in the IA Address option? Also, maybe mention BV> the 0 case? I.E., if [valid] lifetime is zero, remove any existing BV> reservation? BV> When creating/updating a registration, obviously it should only occur BV> if there is not already a registration for a different client. * SHOULD log the address registration information (as is done normally for clients which have requested an address), unless configured not to do so; * SHOULD mark the address as unavailable for use and not include it in future ADVERTISE messages. BV> should replace . with ; as list not done? * SHOULD send back an ADDR-REG-REPLY message. If the DHCPv6 server does not support the address registration function, it MUST drop the message, and SHOULD log this fact. BV> Do we really want to recommend "SHOULD log this fact"? This makes BV> all existing implementations that may not log unknown messages BV> violate a SHOULD? Do we even this paragraph? DHCPv6 relay agents and switches that relay address registration messages directly from clients SHOULD include the client's link-layer address in the relayed message using the Client Link-Layer Address option ([RFC6939]) BV> Needs period to end sentence. BV> I wonder if missing from this section is anything about delaying the BV> initial address registration request? Once an RA with the M or O bits BV> is sent on a network that might not have had either set, the server BV> could receive a flood of registration requests if there is no initial BV> delay. Perhaps when clients reboot, this isn't as much of a problem as BV> it may take the client some (random) time to finalize the SLAAC address BV> before sending out, but in other cases (such as setting M or O that BV> hadn't been set before) could cause a storm? May just be better to BV> always require SOL_MAX_DELAY random initial interval? Or add a new BV> ADDR_REG_MAX_DELAY? 6.2. DHCPv6 Address Registration Acknowledgement The server SHOULD acknowledge receipt of an ADDR-REG-INFORM message by sending a ADDR-REG-REPLY message back, using the address being registered as the destination address for the packet. BV> This is a bit simplistic. If not relayed, this would be the case. BV> If relayed, the path must be via the normal relayed path and the BV> relay closest to the client would use the peer-address field which BV> contains the client's address. (The server would use the relayed BV> packet's IPv6 source address -- basically, in all cases the IPv6 BV> source address of the packet received by the server is used.) The server MUST copy the transaction-id from the ADDR-REG-INFORM message to the transaction-id field of the ADDR-REG-REPLY. The ADDR-REG-REPLY message only indicates that the ADDR-REG-INFORM message has been received. The ADDR-REG-REPLY message MUST NOT be considered as any indication of the address validity and MUST NOT be required for the address to be usable. DHCPv6 relays, or other devices that snoop ADDR-REG-REPLY messages, MUST NOT add or alter any forwarding or security state based on the ADDR-REG-REPLY message. 6.3. Registration Expiry and Refresh The client MUST refresh the registration every AddrRegRefresh seconds, where AddrRegRefresh is min(1/3 of the Valid Lifetime filed in the very first PIO received to form the address; 4 hours ). BV> Perhaps the above is also what should be sent in the [preferred] BV> lifetime (see comment below and earlier on lifetimes and how they BV> are to be interpreted) or some multiple of this value to allow BV> "time" for update communication to happen? Also, this "Valid BV> Lifetime" here is a bit odd given text below about preferred lifetime? Registration refresh packets SHOULD be retransmitted using the same logic as described in the 'Retransmission' section below. In particular, retransmissions SHOULD be jittered to avoid synchronization causing a large number of registrations to expire at the same time. The client SHOULD generate a new transaction ID when refreshing the registration. If the address registration server does not receive such a refresh after the preferred lifetime has passed, it SHOULD remove the record of the Client-Identifier-to-IPv6-address binding. BV> Is it preferred or valid lifetime? Whatever you chose, might require BV> some adjustment to my comments earlier (use preferred vs valid)? The client MAY choose to notify the server when an address is no longer being used (the client is disconnecting from the network, the address lifetime expired or the address is being removed from the interface). To indicate that the address is not being used anymore the client MUST set the preferred-lifetime and valid-lifetime fields of the IA Address option to zero. 6.4. Retransmission To reduce the effects of packet loss on registration, the client SHOULD retransmit the registration message. Retransmissions SHOULD follow the standard retransmission logic specified by section 15 of [RFC8415] with the following default parameters: * IRT 1 sec * MRC 3 The client SHOULD allow these parameters to be configured by the administrator. To comply with section 16.1 of [RFC8415], the client MUST leave the transaction ID unchanged in retransmissions of an ADDR-REG-INFORM message. If an ADDR-REG-REPLY message is received for the address being registered, the client MUST stop retransmission. However, the client cannot rely on the server acknowledging receipt of the registration message, because the server might not support address registration. 7. Host configuration DHCP clients SHOULD allow the administrator to disable sending ADDR- REG-INFORM messages. This could be used, for example, to reduce network traffic on networks where the servers are known not to support the message type. Sending the messages SHOULD be enabled by default. 8. Security Considerations An attacker may attempt to register a large number of addresses in quick succession in order to overwhelm the address registration server and / or fill up log files. Similar attack vectors exist today, e.g. an attacker can DoS the server with messages contained spoofed DUIDs. If a network is using FCFS SAVI [RFC6620], then the DHCPv6 server can trust that the ADDR-REG-INFORM message was sent by the legitimate holder of the address. This prevents a host from registering an address owned by another host. One of the use-cases for the mechanism described in this document is to identify sources of malicious traffic after the fact. Note, however, that as the device itself is responsible for informing the DHCPv6 server that it is using an address, a malicious or compromised device can simply not send the ADDR-REG-INFORM message. This is an informational, optional mechanism, and is designed to aid in troubleshooting and forensics. On its own, it is not intended to be a strong security access mechanism. In particular, the ADDR-REG- INFORM message MUST not be used for authentication and authorization purposes, because in addition to the reasons above, the packets containing the message may be dropped. 9. IANA Considerations This document defines a new DHCPv6 message, the ADDR-REG-INFORM message (TBA1) described in Section 4, that requires an allocation out of the registry of Message Types defined at http://www.iana.org/assignments/dhcpv6-parameters/ BV> What about ADDR-REG-REPLY (TBA2)? Also, add period to end of sentence? - Bernie Volz
- [dhcwg] Codepoint for draft-ietf-dhc-addr-notific… Lorenzo Colitti
- Re: [dhcwg] Codepoint for draft-ietf-dhc-addr-not… Erik Kline
- Re: [dhcwg] Codepoint for draft-ietf-dhc-addr-not… Lorenzo Colitti
- Re: [dhcwg] Codepoint for draft-ietf-dhc-addr-not… Ole Trøan
- Re: [dhcwg] Codepoint for draft-ietf-dhc-addr-not… Bernie Volz
- [dhcwg] Comments on draft-ietf-dhc-addr-notificat… Bernie Volz
- Re: [dhcwg] Comments on draft-ietf-dhc-addr-notif… Jen Linkova
- Re: [dhcwg] Comments on draft-ietf-dhc-addr-notif… Bernie Volz
- Re: [dhcwg] Comments on draft-ietf-dhc-addr-notif… Lorenzo Colitti
- Re: [dhcwg] Comments on draft-ietf-dhc-addr-notif… Bernie Volz
- Re: [dhcwg] Comments on draft-ietf-dhc-addr-notif… Michael Richardson
- Re: [dhcwg] Comments on draft-ietf-dhc-addr-notif… Michael Richardson
- Re: [dhcwg] Comments on draft-ietf-dhc-addr-notif… Bernie Volz
- Re: [dhcwg] Comments on draft-ietf-dhc-addr-notif… Michael Richardson
- Re: [dhcwg] Comments on draft-ietf-dhc-addr-notif… Li HUANG
- Re: [dhcwg] Comments on draft-ietf-dhc-addr-notif… Michael Richardson
- Re: [dhcwg] Comments on draft-ietf-dhc-addr-notif… Lorenzo Colitti
- Re: [dhcwg] Comments on draft-ietf-dhc-addr-notif… Bernie Volz
- Re: [dhcwg] Comments on draft-ietf-dhc-addr-notif… Lorenzo Colitti
- Re: [dhcwg] Comments on draft-ietf-dhc-addr-notif… Bernie Volz
- Re: [dhcwg] Comments on draft-ietf-dhc-addr-notif… Michael Richardson
- Re: [dhcwg] Comments on draft-ietf-dhc-addr-notif… Bernie Volz
- Re: [dhcwg] Comments on draft-ietf-dhc-addr-notif… Bernie Volz
- Re: [dhcwg] Comments on draft-ietf-dhc-addr-notif… Jen Linkova
- Re: [dhcwg] Comments on draft-ietf-dhc-addr-notif… Bernie Volz
- Re: [dhcwg] Comments on draft-ietf-dhc-addr-notif… Jen Linkova
- Re: [dhcwg] Comments on draft-ietf-dhc-addr-notif… Bernie Volz
- Re: [dhcwg] Comments on draft-ietf-dhc-addr-notif… Jen Linkova
- Re: [dhcwg] Comments on draft-ietf-dhc-addr-notif… Jen Linkova
- Re: [dhcwg] Comments on draft-ietf-dhc-addr-notif… Michael Richardson
- Re: [dhcwg] Comments on draft-ietf-dhc-addr-notif… Lorenzo Colitti
- Re: [dhcwg] Comments on draft-ietf-dhc-addr-notif… Lorenzo Colitti
- Re: [dhcwg] Comments on draft-ietf-dhc-addr-notif… Bernie Volz
- Re: [dhcwg] Comments on draft-ietf-dhc-addr-notif… Bernie Volz
- Re: [dhcwg] Comments on draft-ietf-dhc-addr-notif… Michael Richardson
- Re: [dhcwg] Comments on draft-ietf-dhc-addr-notif… Michael Richardson
- Re: [dhcwg] Comments on draft-ietf-dhc-addr-notif… Li HUANG
- Re: [dhcwg] Comments on draft-ietf-dhc-addr-notif… Lorenzo Colitti
- Re: [dhcwg] Comments on draft-ietf-dhc-addr-notif… Lorenzo Colitti