[dhcwg] DRAFT minutes for IETF 69 dhc WG meeting

[Ralph Droms <[e-mail]>]

DRAFT minutes are included below.  Please respond with additions,  
corrections, deletions by 8/29.

- Ralph

		       dhc WG meeting, IETF 69
			   Meeting Minutes
		       -----------------------

Thanks to John Schnizlein for taking notes during the meeting and to
the Jabber scribe, Alexandru Petrescu.

* Draft last call and adoption announcements

The chairs gave an update on the status of dhc WG documents and noted
that two drafts are in WG last call:

   draft-ietf-dhc-vpn-option
   draft-ietf-dhc-agent-vpn-id


* Progressing two drafts under RFC 3942

The chairs announced that two drafts, which had been taken on as WG
work items before the publication of RFC 3942, will now be published
as Informational RFCs, under the guidelines of RFC 3942:

draft-ietf-dhc-subnet-alloc
draft-raj-dhc-tftp-addr-option


* Update to DHCP options guideline

draft-dhankins-dhcp-option-guidelines-00 has been published as a
revision to draft-dhankins-atomic-dhcp-00.  The revised document has
been reorganized and several sections have been extended.  The chairs
will ask the WG for consensus to take this document as a WG work item
when it is available at the IETF I-D repository.


* Using DHCPv6 and AAA Server for mobile station PD

Bechet Sarikaya gave a presentation on
draft-sarikaya-16ng-prefix-delegation-01, which requires dhc WG input
as it proposes changes to the definition of the IAID for address
assignment and prefix delegation.  The 16nf WG proposes to use DHCPv6
prefix delegation for assignment of a prefix to a mobile station.
draft-sarikaya-16ng-prefix-delegation-01 proposes changing the IAID to
6 bytes, which would accommodate the remote station MAC address as an
identifier.  David Hankins and Jari Arkko opposed redefining the
IAID.  John Schnizlein asked for a clarification about the prefix
requested through prefix delegation: does the access router request
the prefix for use on the AR<->mobile link, or for use on additional
links attached to mobile link?  The WG will be asked to discuss the
use of prefix delegation in the 16nf scenario and how to identify
clients within the 4 byte IAID.


* Layer 2 relay agent and relay agent chaining

Pavan Kurapati discussed two drafts:
draft-joshi-dhc-layer2-relay-agent-01 and
draft-kurapati-dhc-relay-chaining-dhcpv4-01.  The first of these
drafts describes guidelines for interpretations of existing DHCP
specifications to successfully allow L2 relay agents to participate in
DHCPv4 message exchanges.  Hankins commented that this draft is needed
to formalize existing deployment scenarios, which have yielded
unexpected results.

The second draft describes extensions to DHCPv4 to allow both an L2
relay agent and an L3 relay agent to insert relay agent options into a
message from a DHCP client to the server.  John Schnizlein noted that
this proposal violates RFC 3046, which allows only one set of relay
agent options, and which requires trust of the L2 relay agent on the
part of the L3 relay agent.

The members of the WG at the meeting expressed interest in continuing
discussion of these drafts of the dhc WG mailing list.

* TAHI DHCPv6 Test tool for IPv6 Ready Logo

Hideshi Enokihara gave a brief summary of the TAHI DHCPv6 test tool
and the results of DHCPv6 testing at the most recent TAHI test event.
There is now an IPv6 Ready (phase 1) logo for DHCPv6, and a phase 2
program started earlier this year.  Ted Lemon asked if there are any
common client failures.  Hideshi responded that the problem most
frequent problem with clients is sending RFC-compliant messages.

* Extensions to DHCPv6 for prefix and default router information

Tim Chown led a discussion of handling rogue RAs in an IPv6
deployment.  The motivation for this presentation is that
administrators of operational networks, mostly universities are
comfortable with DHCP, but are finding problems with 'rogue Router
Advertisments'.  One possible alternative is to avoid RAs and use DHCP
for prefix and default router information.

Bogus RAs can originate from several sources:

1) configuration error - sometimes with long lifetime
2) User-induced accidents: host acting as 6to4 router from home
3) malice

Arkko said that it's not clear DHCP is the right way to deal with
these problems.  Dave Thaler pointed out that SeND is the official
solution to this problem, so creating another solution does not
improve the situation.  Thaler also pointed out that, with the
revision to the "on-link assumption" in RFC 2461bis, there may be a
need for passing prefix information in DHCP.  Alain Durand expressed
interest in using DHCP for prefix and default router information.  Tim
Chown promised to publish a draft documenting the problem.

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