[dhcwg] Edit #5 of DHCPv6 spec

[Ralph Droms <[e-mail]>]

Narten:

  > 18.1.2. Creation and transmission of Confirm messages
  > 
  >  Whenever a client may have moved to a new link, its IPv6 addresses
  >  and other configuration information may no longer be valid.  Examples
  >  of times when a client may have moved to a new link include:
  > 
  >    o The client reboots
  > 
  >    o The client is physically disconnected from a wired connection
  > 
  >    o The client returns from sleep mode
  > 
  >    o The client using a wireless technology changes access points
  > 
  >  In any situation when a client may have moved to a new link, the
  >  client MUST initiate a Confirm/Reply message exchange.  The client

  Hmm. I wonder if movement detection should just be dropped from
  DHC. The problem of determining whether you have reconnected to a new
  link is a generic problem, not just one that DHC has. If you have
  routers, for example, you could use RAs to determine that you have
  moved, which would then retrigger DHC (as appropriate). I could
  imagine an RA option that included a unique identifier for the link
  (this might be useful for mobility in general). Or, you could just see
  of the router you were using has changed (its link-local address is an
  identifier). Or, use the set of on-link prefixes on the RA. If they
  are the same as before, you presumably haven't moved. Having the
  client send DHC messages to the server to determine whether it has
  moved seems like a fair amount of overhead and sub optimal.

  Also, if one dropped the movement detection from DHC, would this allow
  you to do away with the Confirm? I.e., if a client detects that it has
  moved, then just have it redo the normal DHC exchanges. That would
  seem simpler. Plus, if a node has actually moved, the confirm will
  fail, and the normal DHC exchanges have to be used anyway.

Response: We have clarified the definitions of Confirm, Renew and
Rebind (see below).  We have retained the Confirm message as it is
used by a client in different situations from Rebind and Renew, and we
have retained the references to "movement detection" as examples of
situations in which a DHCP client may send a Confirm message.

*** dhcpv6.tty	Wed May 15 05:35:23 2002
--- dhcpv6-24.txt	Tue Apr 23 15:35:14 2002
***************
*** 752,776 ****
        REQUEST (3)        A client sends a Request message to request
                           configuration parameters from a server.
  
!       CONFIRM (4)        A client sends a Confirm message to any
!                          available server when it detects that it may
!                          have moved to a new link to request that the
!                          servers verify that the addresses and current
!                          configuration parameters assigned by the server
!                          to the client are still valid.
  
        RENEW (5)          A client sends a Renew message to the server
                           that originally provided the client's addresses
!                          and configuration parameters to extend the
!                          leases on the addresses assigned to the client
!                          and to update other configuration parameters.
! 
!       REBIND (6)         A client sends a Rebind message to any
!                          available server to extend the leases on the
!                          addresses assigned to the client and to update
!                          other configuration parameters; this message is
!                          sent after a client receives no response to a
!                          Renew message.
  
        REPLY (7)          A server sends a Reply message containing
                           assigned addresses and configuration parameters
--- 752,778 ----
        REQUEST (3)        A client sends a Request message to request
                           configuration parameters from a server.
  
!       CONFIRM (4)        A client sends a Confirm message to servers to
!                          request that the server validate and confirm
!                          that the addresses and current configuration
!                          parameters assigned by the server to the client
!                          are still valid.
  
        RENEW (5)          A client sends a Renew message to the server
                           that originally provided the client's addresses
!                          and configuration addresses to update the
!                          addresses assigned to the client and the
!                          lifetimes for those addresses, as well as the
!                          current configuration parameters assigned by
!                          the server to the client.
! 
!       REBIND (6)         A client sends a Rebind message to update
!                          the addresses assigned to the client and the
!                          lifetimes for those addresses, as well as the
!                          current configuration parameters assigned by
!                          the server to the client; this message is sent
!                          after a client receives no response to a Renew
!                          message.
  
        REPLY (7)          A server sends a Reply message containing
                           assigned addresses and configuration parameters

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