[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[dhcwg] Minutes from March WG meeting
I've attached draft minutes from the March WG meeting. Please let me
know if you have any additions or corrections. I plan to send the
minutes off for publication at the end of the day on 2005-04-07.
- Ralph
Minutes from dhc WG meeting at IETF 62.
Thanks to John Schnizlein 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).
_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg