Subject: [dhcwg] Draft minutes from wg meeting at IETF 70

From: Stig Venaas <[email-masked]>
Date: Sun, 23 Dec 2007 14:19:18 +0100

The draft minutes from IETF 70 have been uploaded at
http://www3.ietf.org/proceedings/07dec/minutes/dhc.txt

Please let Ralph and me know if you have any corrections,
additions etc.

The minutes are also attached for your convenience,

Stig
IETF DHC WG

2007-12-04 @ 13:00
Chairs: Ralph Droms <[email-masked]>
        Stig Venaas <[email-masked]>

Scribe: Shane Kerr <[email-masked]>
Jabber scribe: John Brzozowski <[email-masked]>

Slides:
http://tools.ietf.org/wg/dhc/agenda?item=agenda70.html

- ----------------------------------------------------------------------

Announcement from Alain Durand:
There is a DHCPv6 Bake-Off this weekend.

- ----------------------------------------------------------------------

Agenda:
http://www3.ietf.org/proceedings/07dec/slides/dhc-6.pdf

- ----------------------------------------------------------------------

Stig: DHC is slightly outside what I usually work on. Looking for
  another co-chair for this working group. It's been good to be here
  and learn a lot about DHCP.
Ralph: Thank you for your efforts!

(Applause)

- ----------------------------------------------------------------------

RFC 3942 status update
Bernie Volz

http://www3.ietf.org/proceedings/07dec/slides/dhc-9.pdf

Need to get IANA to represent current status of things.
Option 177 is special - should not be used or reassigned.
New file moves a number of options into the unassigned category.

Issues with Etherboot: 128 & 129 are already assigned to PXE, 150 is
  supposed to be TFTP for VoIP.
Possible actions:
  1. Per RFC 3942, say "sorry", give them up and require assignments
     via IETF process.
  2. Allow their "claim". (Can't do fully due to existing conflicts.)
  3. Some of both: 128, 129, 150 need to move, others are okay.

Ralph: Have any of you run into a conflict?
(Nobody.)

Bernie: Has anybody configured Etherboot or knows someone running it?
Stig: I know people using it, but no personal experience.

Ted Lemon: Given that neither implementation went through proper
  channels, lets publish both drafts and register with IANA as
  "reserved and used by following RFCs".
Bernie: That's sort of option #2.

Richard Johnson: Started using 150 when not part of public space, and
  now it is, it has been out there for a while and we were following
  what we supposed to use.
Bernie: They did liaison early on, but did not complete the process.
Richard: Anyone from Etherboot here?
(No.)

Bernie: We are no worse off if it is documented.
Ralph: Will go through details on the mailing list.

David Hankins: Some listed as deprecated. (175 and 177.) Would be good
  to not drop those. They should go back to "deprecated". Mark the
  land-mine with a flag and move on.

- ----------------------------------------------------------------------

Virtual Subnet Selection Option
Richard Johnson
http://www.ietf.org/internet-drafts/draft-ietf-dhc-vpn-option-07.txt

http://www3.ietf.org/proceedings/07dec/slides/dhc-0.pdf
http://www3.ietf.org/proceedings/07dec/slides/dhc-10.pdf

Virtual Subnet Selection RAIO Sub-Option
Kim Kinnear
http://www.ietf.org/internet-drafts/draft-ietf-dhc-agent-vpn-id-05.txt

Want volunteers to commit to write a review of the revised version of
these documents so we can go through WGLC.

Who will volunteer?
  Bernie Volz
  David Hankins
  Evan Hunt

David Hankins: In one section you specify that if a server does not
  support the sub-option it will omit it. This is incorrect, servers
  will echo back entire contents of the relay agent sub-option whether
  they support it or not.
Kim: Good point. Implies you used it in the allocation. We'll deal
  with that.

- ----------------------------------------------------------------------

Container Option for Server Configuration
Ralph Droms
http://www.ietf.org/internet-drafts/draft-droms-dhc-container-opt-01.txt

http://www3.ietf.org/proceedings/07dec/slides/dhc-3.pdf

Willing to take this on as a WG work item?
(Hum: strong support for this)

Will confirm on mailing list.

- ----------------------------------------------------------------------

DHCPv6 Bulk Leasequery
Mark Stapp
http://www.ietf.org/internet-drafts/draft-stapp-dhc-dhcpv6-bulk-leasequery-00.txt

http://www3.ietf.org/proceedings/07dec/slides/dhc-8.pdf

Mark: Adopt as WG document?
John Brzozowski: Query requirement ID, what about link address in
  context? (Going across multiple relay-agents.)
Mark: If useful in DOCSIS cable-land, then we definitely should add
  this.
John: Another query mechanism would increase the usability.

Bernie: Think about relay agent that just rebooted; if not configured
  with explicit unicast addresses it has no way of discovering what
  the TCP usable addresses are. Might want a new query to find out
  what the servers are.
Bernie: This won't work where you have multiple hops and there is no
  connectivity via TCP (only via relay). Should probably just be
  documented as not working in those kinds of environments.

Ted Lemon: Depending on structure of database and DHCP server, may be
  quite difficult to enumerate across all the entries in the table
  that has that. Should only ask for those keys you really need.
Mark: Unsaid explicitly in the draft, but did say it on mailing list
  discussion. Would like to have specific queries with data that is
  identifiable and locatable. Would rather target things we know and
  understand and expect to use.

David: Authentication. No indication of anything other than "I trust
  your IP address".
Mark: IPv6 answer to all security questions is IPSEC. If you don't
  trust the traffic, there is a way to do it...
John: I don't know that by default you can assume secure
  communications.
Mark: All for wordsmithing a draft now, but I won't remember anything
  I agre to change.

Ralph: Please hum if you think the WG should take on as a work item.
(Large volume in favor, no against.)

- ----------------------------------------------------------------------

Layer 2 Relay Agent Information
http://www.ietf.org/internet-drafts/draft-joshi-dhc-l2ra-00.txt
Stefaan De Cnodder on behalf of Bharat Joshi, Pavan Kurapati

http://www3.ietf.org/proceedings/07dec/slides/dhc-2.pdf

David Miles: Is this working group considering similar L2 information
  for DHCPv6?
Stefaan: Work coming from DSL forum, so not considered for IPv6.

Ted Lemon: Whole point is just to document existing practice, in which
  case the end result will be informational RFC?
Ralph: Yes. For this document. May be other documents.
Ted: Doing at L2 is because IP addresses are scarce?
Stefaan: Maybe devices belonging to different service providers. Want
  to avoid IP addresses.
Ted: Suggest solving this problem by giving each device an IPv6
  address. But since this is informational probably not that
  important.

Erik Nordmark: Make it hard for someone to steal another domains'
  resources. This type of technology is useful in a broader context.
  Should we have some different ways of doing flexible relays. The
  suggestion to not have to configure these devices can help it scale
  up.

Mark Stapp: Does get used a lot. It is undocumented. I do have issues
  with some of the details. It is valuable work to be taking on. I
  would rather see the WG guide the recommendations and descriptions
  than a vendor document vendor-specific practice. Think WG should
  take on the work.
Ralph: You mean beyond just one specific implementation?
Mark: Capturing what is being done and generating guidelines will
  increase interoperability.

David Miles: Complexity of adding IPv6 addresses is expensive.
  Benefits to using a DHCPv6 layer relay agent. Make the DSLAM as
  simple as possible.

Ralph: Take document to publish as informational RFC?
(Some hum in favor, no opposition.)

- ----------------------------------------------------------------------

NTP Options for DHCPv6
Benoit Lourdelet
http://www.ietf.org/internet-drafts/draft-gayraud-dhcpv6-ntp-opt-00.txt

http://www3.ietf.org/proceedings/07dec/slides/dhc-1.pdf

(Not slides actually used.)

John: Can you describe why you didn't specify one option and a flag
  that says, "this is an address" or "this is an FQDN"?
Benoit: This will probably be in the next version.
Ted: Could be a very long discussion, but... historically we have not
  done that. It creates complexity without really adding value. From
  my own perspective, the draft looks great, but would allow for more
  than one IP address. Putting FQDN and IP address is more complexity
  than we usually have. Encourage you to think twice about that.
Benoit: Was quite in favor of just IPv6 address. Look through all of
  the IP services defined, and they all had just address. Prefer that
  now.
Ralph: There are a couple of ways to fix this. Just because the IP
  address is sent in the protocol, does not mean the server has to be
  *configured* that way.
Brain Haberman: A lot of the confusion was lack of understanding in
  the NTP community about how DHCP works.
Ralph: The option is going to be developed as an NTP working group
  item. If necessary will get volunteers and take names for this
  option in the NTP working group.

David Hankins: NTP clueless! Don't understand SNTP and NTP protocols.
Benoit: When you receive an SNTP server you cannot redistribute that
  to a downward client. But the bits are the same on the wire.

Benoit: In some cases you can specify a delay for a multicast address.

John (questions from Jabber): Just put an address not a name, can get
  a new address on renew. If you have not yet set your time how can
  you use DNSSEC.

Richard Gayraud: You have a need to fine tune the parameters. You will
  want a list of servers and parameters for each server. Added an
  option which can appear several times in a DHCP message. Some people
  suggested we use sub-options. Any suggestions on how to handle this
  and have it be implementable?

Ted: Should probably read RFC 3396. Adding more than one of the same
  type of option doesn't do what you think it does. (Bernie: This is
  DHDPv6.) Never mind!

Ted: As far as structures... always good to stick with formats that
  have been used before. But if you want a structure as long as it is
  reasonable you can do that.
Richard: Was told not to have records because that is not what servers
  currently do.

Stig: Take to NTP work group and tell them how to understand DHCP.
  Other volunteers?
(Some hands.)

- ----------------------------------------------------------------------

Service Identfiers List Option for DHCPv6
Hui Deng

http://www.ietf.org/internet-drafts/draft-deng-dhc-service-identifiers-00.txt

http://www3.ietf.org/proceedings/07dec/slides/dhc-5.pdf

Ted: If you provide a list of ports that you allow through, this could
  be very large. The opposite could also be very large. Unless the
  list is quite restricted in length it is impractical.
Ted: As far as identifiers go, you need to say what they mean or it
  does not mean a whole lot.
Hui: We have talked about this.
Ted: It seems like you will need to have a registry of strings. Also
  you need to specify how the variable length identifier length is
  given. If I was going to do this I would just want to know what
  network I am connected to and the client would then know what is
  going on.

David Miles: Why would you tell the client what protocols are not
  supported, rather than just assuming those are not supported.
Hui: Quite a special consideration. When the mobile node has a second
  wireless connection the node has to think about handover.
David Miles: Imply that any options not listed are not supported.
  Otherwise the list grows quite large.
Mark: Felt like this draft was not very complete. I could not
  understand at all how the information would make it to any
  application running on the device. I can't understand how this would
  possibly work, considering all of the issues. Until all the pieces
  are present in writing it is hard to imagine how this would
  function.
Jari Arkko: Recognize the need to sometimes do things like this, but I
  would suggest that this be done very carefully and in a limited
  manner. Previous networks have led to problems with user interface
  problems. Doesn't make sense from the point of view of the operator
  either, since they are missing out on income. If you want to do
  something like this, you may want to do this at a coarser level,
  "the Internet", "corporate network", and so on.
Bernie: Echo Mark's comments. Don't understand how this is supposed to
  be used, already are some protocols that might help or have some of
  this information in it. Not clear where this fits in and why it
  can't be done using some of those other techniques. Why are existing
  techniques to do some of this stuff undesirable.

Ralph: This is interested and WG is interested in reviewing it, but it
  is not yet ready to be a WG work item. Encourage you to bring back
  to WG mailing list.

Jari: Think it is unlikely that this will be part of this working
  group's charter. Rethink why you are doing this.

- ----------------------------------------------------------------------
DHCPv6 Delegation of Certificates Option
Ralph Droms
http://www.ietf.org/internet-drafts/draft-popoviciu-dhc-certificate-opt-00.txt

If routers using SEND, need a way to pass the certificate to
downstream links.

Stig: What is the pointer? Also a bit worried about the UDP packet
  being too big.

Francis Dupont: Not useful only for SEND. Used by all kinds of secure
  routing, SBGP and things like that.
Francis: Agree not a good idea to send certificates. Should include a
  pointers.
Francis: Usually for SEND you need 1 certificate. Usually a 1-to-1
  match.

Jari: In SEND you need both a certificate and a key pair. How does the
  DHCP server know what the key pair of the router is.
Ralph: The security issue is getting the key from the router to the
  DHCP server.

Ted: Is this the solution for how to get routing information into the
  router in PD?
Stig: First thing I said when I saw the draft. Interesting to look at.

Jari: BoF Thursday on SEND-CGA maintenance. There is a work item on
  how SEND and DHCP live together. And now it is not very well. That
  BoF is to look at that problem. If this is to support router
  certificates it should go to SIDR or something like that.
Ralph: Didn't know about that BoF. If it becomes a WG will be in touch
  with that group.

  http://www3.ietf.org/proceedings/07dec/agenda/csi.txt

Co-chair for the BoF. How it is worded in the BoF is that the
requirements will come from the BoF and the work would happen here.
Jari: Will talk off-line about who does what.

- ----------------------------------------------------------------------

Rebind Capability in DHCPv6 Reconfigure Msgs
Ralph Droms
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-reconfigure-rebind-03.txt

http://www3.ietf.org/proceedings/07dec/slides/dhc-4.pdf

No comments.

- ----------------------------------------------------------------------

Neighbor Discovery Information over DHCP
Suresh Krishnan

http://www.ietf.org/internet-drafts/draft-krishnan-dhc-ndc-option-00.txt

http://www3.ietf.org/proceedings/07dec/slides/dhc-7.pdf

Alain Durand: Some of the things that we need from the RA (like prefix
  length), but most of the things are not necessary. Do we really need
  to have this complexity and import *all* the RAs? Would it not be
  better to add the critical pieces that are missing? I think it is a
  much, much simpler route.

Jari: Agree with previous comments. Real issue is what do you do with
  the data that you get? So the container aspect is not the issue, the
  semantics are the issue. Better to decide that we have 2 options
  that we need in DHCP as well, and not keep adding stuff.

Suresh: If you bring them as separate options, the problem does not go
  away. You still have to resolve the precedence of these two!
Alain: If you define it in DHCP, don't use RA any more.
Ralph: If we are defining the DHCP options one by one rather than a
  container option, then we can add words about how to resolve them
  when we define them.
Suresh: But is that up to the protocol to specify? Isn't that local
  policy?
Ralph: Good question, but at least we have some way to write down the
  rules.
Bernie: More information that may want to come through the DHCP
  method. Because you are not able to update the lifetimes, for
  instance. You may want the information to be updated much more
  frequently. I think there is much more verbiage that you would want
  to put in the DHCPv6 option. Allows you to add information about the
  precedence, and so on. Having more well-defined options for each
  individual need lets us write more about how you use this.

[ Ralph cuts comment line off due to time. ]

Shin Maruyama: Still remember difference between DHCP and RA. IP vs.
  UDP protocols.  Almost nothing different other than UDP vs. IP. So I
  agree to use same scheme to send to client - should have only one.
  DHCP doesn't have DAE, need something like an RA, but we should stop
  extending the RA. Lets use DHCP. If we need some extension we can
  develop DHCP for this.
Suresh: If we decide not to develop any more stuff for RA, then read
  my draft for v6man. Want to have one place to define an option, not
  2 places.
Shin: Other difference is RA usually implemented in kernel code. In
  DHCP it is usually easy to add, without patching kernels. If you
  need new parameters modify the daemon on top. Stop extending RA!

Hemant Singh: Getting v6 completely backwards. All the prefix and
  subnet design should be on the router. If you do this kind of a
  thing then you are taking DHCPv6 backwards.

David Hankins: Regarding precedence... I always found them confusing
  whenever anyone brings it up. When DHCP was written, we didn't look
  at RARP. No point arguing about which goes first or last.

- ----------------------------------------------------------------------

Ralph: Thank you all, see you in Philadelphia.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg