Last Modified: 2005-01-20
| Done | WG Last Call on DHCP Options for Internet Storage Name Service (draft-ietf-dhc-isnsoption-03.txt) | |
| Done | WG Last Call on Load Balancing for DHCPv6 (draft-ietf-dhc-dhcpv6-loadb-02.txt) | |
| Done | WG Last Call on Time Configuration Options for DHCPv6 (draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt) | |
| Done | WG Last Call on IPv6 Prefix Options for DHCPv6 (draft-troan-dhcpv6-opt-prefix-delegation-02.txt) | |
| Done | WG Last Call on DNS Configuration options for DHCPv6 (draft-ietf-dhc-dhcpv6-opt-dnsconfig-01.txt) | |
| Done | WG Last Call on NIS Configuration Options for DHCPv6 (draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt) | |
| Done | Resubmit draft-ietf-dhc-dhcpv6-28.txt to IESG | |
| Done | Identify DHCPv4 authentication design team | |
| Done | Identify DHCPv4 specification review design team | |
| Done | Identify DHCPv4 relay agent message authentication design team | |
| Done | Submit DHCP Options for Internet Storage Name Service to IESG (draft-ietf-dhc-isnsoption) | |
| Done | Submit DNS Configuration options for DHCPv6 to IESG (draft-ietf-dhc-dhcpv6-opt-dnsconfig) | |
| Done | Submit NIS Configuratio Options for DHCPv6 to IESG (draft-ietf-dhc-dhcpv6-opt-nisconfig) | |
| Done | Submit IPv6 Prefix Options for DHCPv6 to IESG (draft-troan-dhcpv6-opt-prefix-delegation) | |
| Jul 04 | Submit 'Detection of Network Attachment (DNA) in IPv4' to IESG (draft-ietf-dhc-dna-ipv4) | |
| Jul 04 | Resolve IPR issues around 'Rapid Commit Option for DHCPv4' | |
| Aug 04 | Publish report on dual-stack issues in DHCP (draft-ietf-dhc-dual-stack) | |
| Aug 04 | Publish report on requirements for renumbering using stateless DHCPv6 (draft-ietf-dhc-stateless-dhcpv6-renumbering) | |
| Sep 04 | Submit 'Lifetime Option for DHCPv6' to IESG (draft-ietf-dhc-lifetime) | |
| Sep 04 | DHCPv4 authentication design team report completed, 'Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Threat Analysis' | |
| Sep 04 | DHCPv4 specification review report completed | |
| Sep 04 | Submit 'DHCP Failover Protocol' to IESG (draft-ietf-dhc-failover) | |
| Sep 04 | Submit 'Rapid Commit Option for DHCPv4' to IESG (draft-ietf-dhc-rapid-commit-opt) | |
| Dec 04 | Submit DDNS/DHCP documents to IESG | |
| Dec 04 | Submit 'Node-Specific Client Identifiers for DHCPv4' to IESG (draft-ietf-dhc-3315id-for-v4) |
| RFC | Status | Title |
|---|---|---|
| RFC1531 | PS | Dynamic Host Configuration Protocol |
| RFC1532 | PS | Clarifications and Extensions for the Bootstrap Protocol |
| RFC1533 | PS | DHCP Options and BOOTP Vendor Extensions |
| RFC1534 | DS | Interoperation Between DHCP and BOOTP |
| RFC1541 | PS | Dynamic Host Configuration Protocol |
| RFC1542 | DS | Clarifications and Extensions for the Bootstrap Protocol |
| RFC2131 | DS | Dynamic Host Configuration Protocol |
| RFC2132 | DS | DHCP Options and BOOTP Vendor Extensions |
| RFC2241 | PS | DHCP Options for Novell Directory Services |
| RFC2242 | PS | Netware/IP Domain Name and Information |
| RFC2485 | PS | DHCP Option for The Open Group's User Authentication Protocol |
| RFC2489 | BCP | Procedure for Defining New DHCP Options |
| RFC2563 | PS | DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients |
| RFC2610 | PS | DHCP Options for Service Location Protocol |
| RFC2937 | PS | The Name Service Search Option for DHCP |
| RFC2939 | BCP | Procedure for Defining New DHCP Options and Message Types |
| RFC3004 | PS | The User Class Option for DHCP |
| RFC3011 | PS | The Subnet Selection Option for DHCP |
| RFC3046 | PS | DHCP Relay Agent Information Option |
| RFC3074 | PS | DHC load balancing algorithm |
| RFC3118 | PS | Authentication for DHCP Messages |
| RFC3203 | PS | DHCP reconfigure extension |
| RFC3256 | PS | The DOCSIS Device Class DHCP Relay Agent Information Sub-option |
| RFC3315 | PS | Dynamic Host Configuration Protocol for IPv6 (DHCPv6) |
| RFC3396 | PS | Encoding Long Options in DHCPv4 |
| RFC3442 | PS | The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4 |
| RFC3495 | PS | Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client Configuration |
| RFC3527 | PS | Link Selection sub-option for the Relay Agent Information Option for DHCPv4 |
| RFC3594 | PS | PacketCable Security Ticket Control Sub-option for the the DHCP CableLabs Client Configuration (CCC)Option |
| RFC3633 | Standard | IPv6 Prefix Options for DHCPv6 |
| RFC3634 | Standard | KDC Server Address Sub-option |
| RFC3646 | Standard | DNS Configuration Options for DHCPv6 |
| RFC3679 | I | Unused DHCP Option Codes |
| RFC3736 | Standard | Stateless DHCP Service for IPv6 |
| RFC3898 | Standard | NIS Configuration Options for DHCPv6 |
| RFC3925 | Standard | Vendor-Identifying Vendor Options for DHCPv4 |
| RFC3942 | Standard | Reclassifying DHCPv4 Options |
| RFC4014 | Standard | RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option |
|
Minutes from dhc WG meeting at IETF 62.
Thanks to John Schnizlein and the anonymous Jabber scribe for taking notes from which these minutes were composed. 3315id-for-v4 as requirement for other WG specifications? Ted Lemon ------------------------------------------------------------------- Ted Lemon asked that the WG discuss the use of the client-identifier option, as defined in draft-ietf-dhc-3315id-for-v4-04.txt, in future specifications that involve DHCP. In particular, the specification for DHCP for IP-over-infiniband, draft-ietf-ipoib-dhcp-over-infiniband-09.txt, explicitly references the definitions for the client-identifier option from RFC 2132, rather than the new format defined in draft-ietf-dhc-3315id-for-v4-04.txt. Because draft-ietf-dhc-3315id-for-v4-04.txt formally updates the DHCP specification and deprecates other formats for the client-identifier, there is no need for the dhc WG to take any specific action. The dhc WG chairs will go the ipoib WG to insist that the deprecated formats for the client-identifier not be mentioned in draft-ietf-ipoib-dhcp-over-infiniband-09.txt. SMTP Option for DHCPv6 Martin Stiemerling --------------------------------------------------------------------- draft-cadar-dhc-dhcpv6-opt-smtp-00.txt defines the equivalent of the DHCPv4 SMTP server option for DHCPv6. Ted Lemon said that the DHCPv4 option is unused and can be used to mount a denial of service attack. Stig Venaas said there is no evidence any e-mail clients use the DHCPv4 option. Ted said that it's not likely to be a good idea for a host to use the local SMTP server when roaming. Mark Andrews expressed that the option sounds like a good idea but the security issues need to be addressed. Christian will ask on an SMTP-related mailing list about whether the SMTP option is useful. The WG will then reconsider whether to take on the draft as a WG work item. Source Address Selection Policy option for DHCPv6 T. Fujisaki -------------------------------------------------------------- Fujisaki gave a short presentation about the option in draft-hirotaka-dhc-source-address-selection-opt-01.txt, which configurees the policy table for address selection in RFC 3484. Stig said the option looks useful and might even be extended to destination address selection. Alain Durand said that a policy global to the host won't be adequate because it may be application-dependent. Margaret Wasserman said that RFC 3484 says the table should be configurable, and it makes sense to carry thin-s configuration in DHCP, but the work on the option should be in the ipv6 WG. Fujisaki will rewrite draft-hirotaka-dhc-source-address-selection-opt-01.txt to define the option to carry only the RFC 3484 table configuration bits; a pointer to RFC 3484 will motivate need for selection table and this option. Fujisaki will take the edited draft to the ipv6 WG for review. DHCPv6 Relay agent RADIUS Attribute Option Wing Cheong Lau ------------------------------------------------------------------ Thomas Narten asked the WG to consider the criteria for RADIUS attributes that may be carried in the relay agent option defined in draft-ietf-dhc-v6-relay-radius-00.txt. DHCPv6 Options for Fast Handovers Takeshi Ogawa ---------------------------------------------------------------- The author presented this draft at the mobopts IRTF WG, but there was no time for discussion. Consensus is that this draft should belong to a MIP-related WG. Service-Oriented Address Assignment using DHCP Syam Madanapalli ------------------------------------------------------------------- Madanapalli summarized the mechanism in draft-ietf-dhc-soa-option-00.txt and draft-syam-dhc-soav4-option-00.txt as automating the process of assigning anycast addresses to services. The mechanism is based on the premise that some services will be provided through an anycast address. These addresses would be assigned dynamically on demand from the providing server, rather than using a well-known address. Ralph Droms asked how different kinds and types of services would be defined. Madanapalli responded that a draft defining the service descriptions needs to be written. Stig Venaas said that anycast wouldn't work when a client needs to choose a specific web server. Also, anycast has routing implications; how would anycast routing information be injected into the routing protocols? Margaret Wasserman found these options and the concepts confusing: addresses are assigned to interfaces, not services. Ralph responded that the mechanism in these drafts enables application services to be assigned an anycast address for the anycast-enabled service; the concept is similar to MADCAP assignment of multicast addresses. Thomas Narten asked who is the customer for these options? Droms asked if there is a document that describes the anycast service framework in more detail to provide a context for these options. Alain Durand said that this is a very complex area; how does the server know its role in asking for an anycast address? The WG consensus is to wait for an overall framework paper and specific customers before proceeding. Relay Agent Options Bernie Volz -------------------------------------------------------------- Bernie Volz described draft-volz-dhc-dhcpv6-remoteid-00.txt and draft-volz-dhc-dhcpv6-subid-00.txt as IPv6 version of the equivalent DHCPv4 relay agent option sub-options. The WG consensus was to accept these two drafts as WG work items. The WG then discussed forwarding DHCPv6 prefix delegation (DHCPv6-PD) through relay agents. The key issue is injecting routing information about delegated prefixes if the delegation is not done at the router to which the requesting router is attached. A couple of alternatives were discussed: edge router acts as DHCPv6-PD requesting router to internal DHCP server and then acts as delegating router to customer requesting router; new relay agent option allows delegating server to inform edge router of delegation in message carrying delegation to requesting router. Ted Lemon asked what happens if the edge router reboots and loses the information about delegated prefixes. Someone answered that the link to the CPE requesting router would flap and it would re-request the prefix delegation. David Hankins expressed a preference for using a real routing protocol like BGP. Discussion to continue on the WG mailing list. Zone Suffix Option for DHCPv6 Renxiang Yan --------------------------------------------------------------- Renxiang Yan was unable to attend the WG meeting. Droms presented some slides from an updated draft and explained that the server sends a domain to which the client prepends its host name to form an FQDN. No WG action taken at this time. DHCP: IPv4 and IPv6 Dual-Stack Issues ------------------------------------- Droms asked for WG consensus that draft-ietf-dhc-dual-stack-02.txt is ready for WG last call. Alain Durand said that the more general problem is really a multi-homed host problem rather than just IPv4-IPv6. The WG agreed that there is a multi-homed host problem, but there may be simplifying assumptions in the IPv4-IPv6 case so that considering this draft is a way to make progress. Consensus at the meeting was that the draft is ready for WG last call. Resolving the IPv4 and IPv6 Dual-Stack Issues Tim Chown ------------------------------------------------------------ WG was asked what are the next steps in resolving the dual stack issues listed in draft-ietf-dhc-dual-stack-02.txt. One conclusion from draft-ietf-dhc-dual-stack-02.txt is that IPv4 configuration should not be added to DHCPv6; rather, DHCPv4 and DHCPv6 should be kept separate, with the assumption that a single admin can keep the servers in sync. Droms asked what the scope of the next document might be. Ted Lemon said that he doesn't think there is a protocol solution. Another comment was that how to handle configuration of merging is a hard problem. Tim Chown suggested limiting the scope of a next document to the scenario in which both the DHCPv4 and DHCPv6 services are managed in the same admin domain. Dave Thaler said that there are two separate problems: (1) in absence of external input, how should information from different DHCP services be merged? (2) how does the DHCP service administrator resolve loss of information. The WG can help with (2). Alain Durand said that the first step is to determine if the information comes from the same domain and is, therefore, mergeable. Margaret Wasserman said that merging the list of DNS server is not as easy as it might seem - think about a client where one of its interfaces is in a split-DNS environment. The WG will continue to work on this issue. RFC3118 Delayed DHCP Authentication Using EAP Alper Yegin -------------------------------------------------------------- Alper Yegin gave a presentation on draft-yegin-eap-boot-rfc3118-01.txt, which uses RFC 3118 authentication with a shared key derived from the EAP authentication step. This mechanism would use a new relay agent suboption to push the key to the DHCP server, and a new option in authentication mechanisms (PANA, AVP; 802.1x TBD) to push the key to the client. draft-yegin-eap-boot-rfc3118-01.txt is a derivative of an earlier EAP-DHCP authentication by Yegin, which was not picked up as a WG work item because of technical concerns. Yegin will rewrite draft-yegin-eap-boot-rfc3118-01.txt to describe DHCP authentication independent of PANA, PPP or 802.1x, and include an appendix showing a specific implementation (preferably 802.1x). |