[09:53:47] --- FDupont has joined
[09:57:43] --- The Co-Chair has joined
[09:57:53] <The Co-Chair> Working?
[09:58:37] <FDupont> Yes
[09:58:47] <The Co-Chair> Thanks!
[09:59:48] --- The Co-Chair has left: Logged out
[10:01:46] --- arifumi@2entwine.net has joined
[10:02:02] --- Hankins has joined
[10:02:03] --- linsner has joined
[10:02:06] --- jinmei has joined
[10:02:45] --- andreaf has joined
[10:03:08] --- marka has joined
[10:03:14] --- mellon has joined
[10:03:21] --- miyahiro has joined
[10:03:29] <mellon> <- jabber scribe
[10:03:37] <mellon> Drafts ready for wglv
[10:03:39] <mellon> wglc
[10:03:55] <mellon> dhcpv6-opt-dnsdomain
[10:03:58] <mellon> vpn-option
[10:04:02] <mellon> agentopt-delegate
[10:04:07] <mellon> rfc868-servers
[10:04:30] <mellon> we're doing a second wglc on dnsdomain to make sure everybody's read the last version.
[10:04:43] <mellon> the last two are for DOCSIS 3.0, intend to specify use of RFC868 timeservers.
[10:04:57] <mellon> Just like DOCSIS 2.0. Need an option to carry address of servers.
[10:05:25] <mellon> Delegate option is a relay agent option to have server inform relay agent of address assignments and prefix delegations so relay agent can take appropriate action based on that information.
[10:05:31] <mellon> vpn option didn't pass wglc.
[10:05:59] <mellon> Only one response to wglc or vpn option, asked several questions, need to follow up on that.
[10:06:03] <mellon> Any others we've missed?
[10:06:09] <mellon> Now getting report from TAHI.
[10:06:29] <mellon> Hideshi Enokihara speaking.
[10:06:37] --- ogud has joined
[10:07:20] <mellon> Tester status. Will release verson 1.0 of DHCPv6 tester on April 1.
[10:07:33] * marka has set the topic to: March 23 2006
[10:07:39] <mellon> Covers RFC3315, etc. Supports delayed athentication protocol, not reconfigure key protocol.
[10:08:20] <mellon> They aren't clear on the reconfigure key authentication protocol, need help from wg to understand how it works. Will be asking on wg mailing list.
[10:08:35] <mellon> Conformance test, five implementations were tested. 2 servers, 3 clients.
[10:08:59] <mellon> Found bugs in tester and implementations. Discussed some issues in RFCs.
[10:09:24] <mellon> Interoperability test, six participants.
[10:09:43] <mellon> Issue 1, how to treat invalid option. Clients should discard messages that contains options that aren not allowed to appear in received message.
[10:09:58] <mellon> Moast implementations ignore options rather than discarding message.
[10:10:23] <mellon> Opinion of Bernie: servers are designed for performance. It doesn't cause interoperability problem. If new option is defined, requires constant maintenance.
[10:10:41] <mellon> Second issue, where is correct position of NotOnLink status code - reply to a request.
[10:11:03] <mellon> RFC says "with a status code option," question is in main option area, or IA option.
[10:11:08] <mellon> Bernie says in IA option.
[10:11:36] <mellon> There are some other status codes for which the position might be unclear as well.
[10:11:47] <mellon> Last issue, coexistance of success and nobinding status code option in reply to a renew.
[10:11:52] <mellon> RFC doesn't say what to do.
[10:12:05] <mellon> Some implementations include success status code in main part of message, nobinding in IA option.
[10:12:23] <mellon> Bernie says this is okay. The outer status code isn't interesting, so we should ignore it.
[10:12:34] <mellon> All this information is available at www.tahi.org/dhcpv6/
[10:12:47] <mellon> If you are interested in our tests, please take this URL. That's all, any questions?
[10:12:51] <mellon> Jinmei-san, issue 1.
[10:13:10] <mellon> Which message causes this problem? (discarding messages with bogus options)
[10:13:57] <mellon> Preference option sent to server. RFC said preference option must not include ...
[10:14:12] <mellon> (Jinmei says "okay, I understand.")
[10:14:36] * marka has set the topic to: timezone option
[10:15:05] <mellon> Eliot Lear is now presenting the timezone option.
[10:15:22] <mellon> Reason: what's in v4 is broken. Ralph said "send text."
[10:15:54] <mellon> Client can't determine if in DST, can't determine what timezone they are in - e.g., Cuba's rules different from US rules, can't tell whether in Cuba based on offset.
[10:16:09] <mellon> Client operating systems really don't know what to do with just an offset. Most interfaces are for timezones, not offsets.
[10:16:19] <mellon> There are four standards to describe timezone information.
[10:16:37] <mellon> The draft as it currently is written has suboptions for several different timezones, posix strings are mandatory to implement.
[10:16:54] <mellon> This is e.g. TZ="EST5EDT4,M3.2.0/02:00,M11.1.0/02:00"
[10:17:10] <mellon> Understood by Unix systems, concise, no database needed.
[10:17:25] <mellon> The TZ database is well known, all unix systems use it, mnemonic for example "America/Central"
[10:17:45] <mellon> Even some JVMs use it, widely distributed, impressive in terms of how much data it keeps. Nice because you don't have to send rule - you just send reference to rule.
[10:17:53] <mellon> Example of what MS does - big XML splat.
[10:18:11] <mellon> Looks a lot like POSIX string in terms of amount of info it carries, but many more bytes.
[10:18:23] <mellon> Standard index number, two bytes.
[10:18:36] <mellon> Last one is VTIMEZONE entries, from icalendar standard, RFC2445.
[10:18:47] <mellon> There is no limit to size of a timezone entry, practically speaking it's a couple of hundred bytes.
[10:19:01] <mellon> Keeps same amount of info as TZ database. Sending whole thing on the wire. Not amenable to use by DHCP.
[10:19:07] <mellon> I say that as someone who is active in that wg.
[10:19:32] <mellon> What I did in current draft is set up option with suboptions, POSIX (mandatory), TZ database and Microsoft Timezone element index.
[10:19:44] <mellon> Who cares? Mobile laptops. IP-based phones. Set top boxes.
[10:20:12] <mellon> DHCP is the right vehicle largely because change of link-layer info is a good hint that you've changed locations.
[10:20:20] <mellon> Granularity good - timezone generally applies to whole system.
[10:20:30] <mellon> Mobile multiuser systems are uncommon.
[10:20:50] <mellon> Concerns in draft - do we have the right mandatory suboption? Should we be using suboptions?
[10:21:06] <mellon> Just after submission of draft, on ML discussion said just use three options, not suboptions. That's fine with me.
[10:21:16] <mellon> THe only other issue is whether we should bother with all three, should I just do two?
[10:21:29] <mellon> THe one I'm thinking not to do is that I haven't gotten any feedback from Microsoft.
[10:21:35] <mellon> Ralph: I thought there were four.
[10:21:42] <mellon> Eliot: we eliminated VTIMEZONE.
[10:21:48] <mellon> Other question, are the field sizes appropriate?
[10:22:12] <mellon> Neither author, other is Paul Eggert who coordinates TZ database, substantial review would be very much appreciated, we know very little about DHCP.
[10:22:47] <mellon> David Hankins: third suboption is missing a length field.
[10:23:23] <mellon> I think suboptions are right. It's true that a given client is not going to use the suboptions, but it's small enough, at worst 30-40 bytes, I think that's acceptable.
[10:23:31] <mellon> Eliot: I think it's closer to 60.
[10:23:42] <mellon> Question about TZ database (schnitzlein)
[10:23:53] <mellon> When you say TZ database has historical record, how is that provided to the client?
[10:24:00] <mellon> ELiot: sending reference to an entry, not contents of entry.
[10:24:13] <mellon> Eliot: what comes down the wire is US/Central, which presumes that client has those.
[10:24:23] <mellon> Eliot: mandatory to implement is posix 1003.1 string, not TZ database.
[10:24:36] <mellon> TZ database is not the same thing as posix string.
[10:25:00] <mellon> John: I thought this was a record from the TZ database, maybe I was confused by fact it starts with TZ.
[10:25:17] <mellon> Eliot: it's confusing. TZ database is sometimes called the Olsen database, but authors and maintainers prefer that it be called TZ database.
[10:25:31] <mellon> John: so is this line (the POSIX string) different than what's in the TZ database?
[10:25:52] <mellon> Eliot: yes, entry in TZ database includes timezone history for timezone, some entries go back to 1960s.
[10:26:35] <mellon> John: what is the most appropriate way to enable a host to get the correct time?
[10:26:39] <mellon> Eliot: timezone.
[10:26:47] <mellon> John: which one is mandatory?
[10:26:55] <mellon> Eliot: POSIX string. It's the only de-facto standard.
[10:27:09] <mellon> John: for mandatory to implement, you get info about current timezone, and when it will change, and what the new timezone will be.
[10:27:24] <mellon> John: and for TZ database it's presumed that correct TZ database is in the host, there's no mechanism for updating that.
[10:27:44] <mellon> Eliot: we've considered this in other groups, consensus is that that's a vendor problem - vendors already update that information, so we don't need to be in that business.
[10:28:25] <mellon> John: it's a real problem in US where there are lots of changes in the implied contents of that. What we might face is a situation where if this were implemented, host might get wrong wall-clock time because it doesn't know about changes in Indiana, US experiment with moving changes a month forward and back.
[10:28:48] <mellon> Eliot: that might be possible, depends on vendor. If vendor doesn't distribute that information ina timely manner info will be wrong, and that's how it is today.
[10:29:29] <mellon> Mark Andrews: I've lived through changes that have turned up a month before. The timezone database is easy to change, usually get it in source form, easy to update on the machine usually. POSIX strings are nice, but you need to update them every year or half-year.
[10:29:42] <mellon> Jean-francoise Amelie? timezone is coupled with location, right?
[10:29:48] --- william.gilliam has joined
[10:29:53] <mellon> Eliot: coarse granularity, not like geopriv.
[10:30:10] <mellon> JF: defining it without binding locations we have is ???
[10:30:22] <mellon> In security considerations, when you give timezone in device, there may be some privacy issues.
[10:30:29] <mellon> Eliot: we talk about that a little bit in the draft.
[10:30:46] <mellon> JF: given wording geopriv uses for location-related conveyance of information, you may want to strengthen language.
[10:30:58] <mellon> Eliot: send text or reference to text you think is appropriate.
[10:31:30] <linsner> correct speaker name - Jean Francios Mule
[10:31:33] <mellon> JF: first point, with James Dowlen string option later on, we're starting to provide to clients all kinds of parameters that are linked with location information, POSIX string is fine, I wonder whether this should be suboptions on location option?
[10:31:34] <mellon> Thanks.
[10:31:46] <mellon> Eliot: is it possible to hand somebody timezone without location information?
[10:32:04] <mellon> JFM: timezone without location seems to me you get timezone because you're in location. Somehow it's linked.
[10:32:25] <mellon> Eliot: location information is harder than timezone information, timezone easy to implement in environment.
[10:32:30] <mellon> enterprise environment.
[10:33:01] <linsner> speaker - Kim Kinnear
[10:33:30] <marka> kim: there are times when you don't want to link timezone and location e.g. run all in GMT
[10:33:42] <linsner> KK: lack of consencious on binding location and timezone
[10:34:46] <linsner> KK: discuss suboption vs. option
[10:35:01] <marka> kim: who wins amoungst the sub options
[10:35:22] <marka> answer other option usually
[10:36:00] <marka> kim prefers sub-options to provide ordering
[10:36:57] <marka> Ralph: don't worry about consuming option space
[10:37:09] <linsner> speaker - James Polk
[10:37:17] <linsner> JP: this is a good draft
[10:38:02] <marka> thinks this is a good draft. client can request location and timezone if they want both
[10:38:28] <marka> ted votes for options
[10:38:45] <marka> ted thinks this is a good idea
[10:39:04] <marka> hankins: clarify if null terminated or not
[10:39:18] <mellon> Ralph: all in favor hum
[10:39:23] <mellon> (of adopting as wg item)
[10:39:27] <mellon> Not in favor hum?
[10:39:31] <marka> hum in favour of adoption
[10:39:31] <mellon> Nobody hummed against.
[10:40:15] <mellon> James Polk
[10:40:22] * marka has set the topic to: DHC emergancy dialstring option
[10:40:25] <mellon> DHC Emergency Dialstring option
[10:40:42] <mellon> Requirement: at boot time, to download the emergency dialstring.
[10:40:51] <mellon> (see draft for option format)
[10:41:10] --- gdweber has joined
[10:42:50] <mellon> Ecrit brought up idea of putting dialstrings in their URI mapping protocol query.
[10:42:54] <mellon> Mapping location to PSAP URI.
[10:43:04] <mellon> I think that's a great idea, don't think it's going to happen all the time.
[10:43:12] <mellon> I don't know if it's going to be successful.
[10:43:30] <mellon> I want a DHCP option also. Another possibility, put a dialstring query into a SIP register message.
[10:43:52] <mellon> Here you'd take location information from option 123 and get the SIP registrar to give you your dialstring.
[10:44:06] <mellon> Lost query from SIP device to get me my PSAP URI and visited dialstring is another way to do it.
[10:44:12] <mellon> Mark?
[10:44:35] <mellon> Mark Linsner: just to reconfirm what James said, wg is examining this functionality, trying to determine best place to advise client of dialstrings.
[10:44:50] <mellon> My personal opinion is that I'm mixed as to whether DHC is the right place to do that.
[10:45:04] <mellon> This is an application thing, more than a host thing, although location is related to DHC.
[10:45:27] <mellon> We're having a terms discussion in ecrit. Home and visited come from cellular world. I propose local and home.
[10:45:41] --- gdweber has left
[10:45:48] <mellon> There is no visited network - internet is one network. Local is where you are at now, home is what you are used to from a culture standpoint.
[10:46:33] <mellon> Ralph: ecrit considering several alternatives. Function James is proposing is subsumed by that review process?
[10:46:40] <mellon> ML: correct.
[10:46:56] <mellon> James: you're looking at layer 7 alternatives, I'm looking at access infrastructure solution.
[10:47:06] <mellon> ML: DHC Operator is quite removed from that location.
[10:47:19] <mellon> Henning Schultzrinne: ecrit is not restricting attention to layer seven.
[10:47:24] <mellon> No charter restriction on that.
[10:47:31] <mellon> Currently this proposal has not been discussed within ecrit.
[10:47:49] <mellon> I am generally concerned, consider it premature to have DHC to do this work, because it affects architecture in ecrit.
[10:48:20] <mellon> Secondarily, worried about having two many ways of doing the same thing. Unless you have a widely-deployed mechanism, e.g. if you have two, it's probable that different mechanisms will be deployed on client vs. server.
[10:48:32] <mellon> If you have three or four, likely that values will disagree, how do we pick?
[10:48:48] <mellon> We should defer this discussion until ecrit has a better idea of what they want to do, and what solutions make sense in different scenarios.
[10:49:03] <mellon> DHC services also operated implicitly by agencies that have no clue about emergency calling.
[10:49:29] <mellon> E.g., my linksys box I got from sweden. Likelihood that I would be able to configure it properly, or that vendor would set it up correctly, is low.
[10:49:41] <mellon> New emergency numbers are coming out, e.g. in former eastern bloc countries.
[10:50:20] <mellon> James: ecrit doesn't have requirement for dialstring, curious that they're coming in here saying ecrit is where this should be pursued.
[10:50:46] <mellon> Ecrit limited at four deliverables.
[10:50:53] <mellon> Can't add this to Ecrit charter.
[10:51:10] <mellon> How many different layers is location going to be delivered to end device? DHC might not do it, layer 2 might not do it, layer 7 might not do it.
[10:51:44] <mellon> Stig: minor comment, think if you want to support multiple dialstrings, need to change format of option, I think.
[10:51:58] <mellon> Because if you look at option as it is now, just have country code, purpose, dialstring.
[10:52:16] <mellon> James: no, I have service indicator. E.g., police=118, fire = 119, that's a service identifier.
[10:52:24] <mellon> THey have five unique dialstrings, five different deliveries.
[10:52:33] <mellon> (responses were from James)
[10:52:44] <mellon> Stig: Okay, we need to discuss this offline. See what groups are appropriate.
[10:52:54] <mellon> Ralph: need to get together with IESG to find out where this should land.
[10:53:23] <mellon> Our current charter mode of operation is that options like this are reviewed for requirements of defining options, we review for syntactic correctness and impact on DHC Protocol, but we don't know where it should go.
[10:53:54] <mellon> Jean-Francoise Mule - strong support for this option - for some networks, heavy users of DHCP, we think there is applicability there. Along the lines of what stig proposed, why does this have to be local to country?
[10:54:08] <mellon> 112 is local emergency number for europe, +33 112, +44 112, still an emergency number.
[10:54:28] <mellon> If i live in region where I am borderline btw france, switzerland and italy, how do I do that with current draft?
[10:54:40] <mellon> James: could you provide country codes for each thing?
[10:54:51] <mellon> Ralph: sorry to interrupt, really running late, way out of expertise of wg.
[10:55:11] <mellon> Peter Blodwick: would like to use this inside enterprise to indicate dialstring for local security, chemical spill, etc.
[10:55:23] <mellon> Also have similar concerns about breaking down into larger or smaller domains.
[10:55:36] <mellon> Ralph: taking more out of realm of DHC, that's more application oriented.
[10:56:00] <mellon> I agree it's application specific, but nice thing abotu DHC is it's driven by layer two: where you actually are.
[10:56:06] <mellon> (that was Peter again)
[10:56:15] <mellon> Soohong Daniel Park presenting
[10:57:00] <mellon> DHCPv4 ption for diascovering IEEE 802.21 Information Service Location
[10:57:08] <mellon> draft-daniel-dhc-mihis-opt-02.txt
[10:57:29] * marka has set the topic to: Discovery of 802.21 Information Server Location
[10:57:33] <mellon> For more understanding I will introduce briefly what is going on within 802.21 wg.
[10:58:01] <mellon> 802.21: three kinds of service - media independent event service, , MI command service, MI information service.
[10:58:19] <mellon> Event and cmmand are local utility to trigger making a kind of link trigger, down trigger, to the operator.
[10:58:30] <mellon> Some of comment to down lower layer from the upper layer. (not operator)
[10:58:58] <mellon> MIIS is kind of mobility framework. MIIS include all mobility information, e.g. location information, wireless characteristic, whatever.
[10:59:15] <mellon> Then this information should be exchanged between mobile station and network peer. Peer is media independent information server.
[10:59:15] --- gdweber has joined
[10:59:24] <mellon> Information also consist of several information element called IEs.
[10:59:37] <mellon> IEs must be included in MIIS server.
[10:59:48] <mellon> Information is made by several schemas.
[11:00:02] <mellon> Currently the 21 spec defines two kinds of schema, basic and extended.
[11:00:21] <mellon> At the last January meeting, DHCP was decided as candidate mechanism to discover Information Service Server.
[11:00:26] <mellon> That's why I'm proposing these options.
[11:00:45] <mellon> Currently of course I had some time to discuss these issues in 21 meeting, propose three kinds of options.
[11:01:00] <mellon> One is IPv4 addr of info server, fqdn of server, unique URI of IS server.
[11:01:04] --- ogud has left
[11:01:13] --- william.gilliam has left
[11:01:25] <mellon> As you can see, I am using the suboption format following dhc discussion on mailing list. Let me give a simple example.
[11:01:34] <mellon> (diagram - download the presentation)
[11:01:50] <mellon> 21 mobile station request where 21 is server is located.
[11:01:56] <mellon> server provides this information
[11:02:09] <mellon> 21 mobile client does MIIS exchange with the server.
[11:02:19] <mellon> MIIS exchange is out of scope of DHCwg.
[11:02:32] <mellon> MIPSHOP working group is doing this part.
[11:03:14] <mellon> Made some changes from initial version. First, change from encoding byte to suboptions. Schema URI is a single field now, single URI.
[11:03:35] <mellon> URI doesn't exceed 255 bytes.
[11:03:55] <mellon> So far only considering IPv4 environment, but we will consider IPv6 next.
[11:04:36] <mellon> 21 wg already decided DHCP is one candidate for discovering IS server location. If you need 21 spec, current version at http://www1.ietf.org/mail-archive/web/mipshop/current/msg02410.html
[11:05:37] <mellon> John Schnitzlein: why do you need all three since it would appear that in order to perform the function you're looking for, URI would have to be resolved, or FQDN would, then you have another suboption that is IP address of server. If function is to find the server for a local network, then the simple address would be sufficient; why all three?
[11:05:57] <mellon> Daniel: it's based on 21 spec. Currently, 21 spec is defining three kinds of information for discovering IS server.
[11:06:13] <mellon> As I indicated, address is mandatory, but sometimes, 21 client needs the other options to discover IS server location.
[11:06:22] --- narten has joined
[11:06:33] <mellon> JS: what are the cases where it's necessary to go through multiple steps of resolution to get address rather than sending address. Why all three ways?
[11:07:22] <mellon> Other question: it appears to me that the purpose of the MI service has to do with a layer two function, facilitating handovers and such. If the function that you're reaching has all of its behavior within that layer two network, and you have protocols already in existence, why use Layer 2.5 protocol to find a server that appears to be guaranteed to be within that subnet?
[11:07:37] <mellon> IS server include all handle information for ?? and handover.
[11:08:14] <mellon> JS: if you get this information discovery ability, along with your IP address, it's only good as long as you're in that subnet - if you go to a different subnet, you have to get an IP address. If all this handover happens within this subnet, why do we need even to go to an IP address?
[11:08:24] <mellon> Why not use the same kind of protocol that you're using for layer two communication?
[11:09:16] <mellon> Quick example, I have wireless link, need to move to another wireless link, and then the 21 mobile client needs to obtain some of neighbor wireless information, e.g. which wireless is available, which is more preferable, which process point is more provide high bandwidth than others. All information is included in IS server.
[11:09:39] <mellon> 21 mobile station, before moving to link, can obtain handle information from IS server, that's why I need to discover IS server location.
[11:11:07] <marka> ted: worries about picking apart other wg work. Why not just uri?
[11:11:52] <mellon> Daniel: DHCP was decided on as candidate for this kind of mechanism, but we're open to ??
[11:12:04] <mellon> Ralph: 802.21 committee has not come to final decision about DHCP, or have they decided on DHCP?
[11:12:14] <mellon> Daniel: they definitely want DHCP. Another mechanism could be added.
[11:12:54] <mellon> Lionel Morand: DHCP options for PAA
[11:12:57] * marka has set the topic to: DHCP options for PAA
[11:13:51] <mellon> One of the solutions described in pana specification is a pana authentication agent. THis option provides list of pana authentication agents. List of domain names or IP addresses.
[11:14:18] <mellon> Initially version 00 defined IPv4 options, decided to include DHCPv6 option also. Only one draft.
[11:14:28] <mellon> One defined for domain list, another for IP addresses.
[11:14:34] <mellon> Defines behavior of client and server.
[11:14:50] <mellon> Another version submitted using container of suboptions.
[11:17:18] <Hankins> Ted lemon: Why both IP addresses AND FQDN's?
[11:17:41] <Hankins> Morand: I don't actually have a strong opinion on that.
[11:18:15] <Hankins> Lemon: Unless you have some strong reason for having FQDNs, I recommend simplifying only IP addresses.
[11:18:32] <Hankins> Droms: Is there an advantage in the FQDN versus the IP address (to the client)?
[11:18:35] --- ogud has joined
[11:20:07] <mellon> JS: you're really only doing this at the beginning, so why do you need the information to be updated if it changes in the DNS?
[11:20:35] <mellon> LM: not just to authenticate user at beginning - there is no restriction on when.
[11:20:54] <mellon> We can remove this. If it is easier to rely on IP address list.
[11:21:16] <mellon> Stig: I also think it's a good idea to just have an address, but if PANA decides it's very important to have FQDN...
[11:21:41] <mellon> LM: here it is not a PANA issue, it's about implementation within access network. It's just how you will implement this in your network - it's a network operator issue.
[11:22:31] <mellon> Kim Kinnear: server override option
[11:22:47] <mellon> We're trying to resolve some issues that came up late in server override draft.
[11:23:05] * marka has set the topic to: Server Overide
[11:23:30] * marka has set the topic to: Server Override
[11:23:47] <mellon> Server override, relay agent tells DHCP server what value to put in server identifier option, then DHCP server will put that into the option. So DHCP clients will think that when they want to talk to DHCP server, they will unicast renews to the relay agent, not hte server. Relay agents then forwards to DHCP server.
[11:24:15] <mellon> Relay agent will add option 82 information, and in the event that the relay agent was mediating access between client and server, it would actually get to the server, there are situations where client can talk to relay agent but not to server.
[11:24:31] <mellon> So right now the giaddr is the only reliable multiplatform way to tell that a packet was broadcast as opposed to unicast.
[11:24:48] <mellon> DHCP server can't tell if packet was forwarded to relay agent if a unicast packet gets a giaddr.
[11:25:00] <mellon> Er, that packet was unicast vs. broadcast.
[11:25:05] <mellon> That creates three issues.
[11:25:40] <mellon> 1. RFC2131 says that NAK based on connectivity can't follow a renew.
[11:25:58] <mellon> 2. Makes load balancing less valuable.
[11:26:13] <mellon> 3. clients get two ACKs when failover is used regardless of load balancing.
[11:26:22] <mellon> Third issue isn't particularly major.
[11:26:27] <mellon> What could we do about this?
[11:26:34] <mellon> Initial plan was don't worry about it.
[11:26:54] <mellon> Don't configure your network stupidly - if you do, it won't work.
[11:27:13] <mellon> Another suggestion is to add flag byte that indicates whether packet was unicast or broadcast.
[11:27:44] <mellon> Alternative - create new relay agent info suboption to indicate same information.
[11:28:00] <mellon> Another thing to be done would be to move load balancing algorithm to relay agent.
[11:29:26] <mellon> Bernie Volz: on that second alternative, adding it to the suboption, doesn't that kindof not work because server id suboption goes from server to relay, not relay to server.
[11:29:40] <mellon> KK: no, relay sends server id to server saying "put this into server identifier."
[11:30:30] <mellon> Recommendation: do new suboption rather than putting it into server id override suboption. There are other reasons why relay agents can receive unicast packets, useful to have.
[11:30:46] <mellon> Disadvantage: linking drafts. Can we let this draft go forward without that draft?
[11:31:46] <marka> ted: the two drafts will need to linked
[11:32:58] <marka> Ralph: is unlinked state un acceptable
[11:33:03] <marka> ted: yes
[11:33:45] <marka> MUST/SHOULD for linking
[11:34:57] <marka> ted: load balancing in relay should not be a gating requirement but really is needed.
[11:35:31] <marka> ted: how does the server know if it should respond to a query?
[11:36:19] <marka> plain case. renews to one server by default
[11:36:56] <marka> with relay it gets sent to both servers. extra load on servers.
[11:37:41] <marka> defering to mailing list
[11:41:31] <marka> mark staff: suggests that new draft be a informative reference
[11:43:56] <mellon> Some of the text in RFC2131 is there because there were bootp relay agents that would round-robin.
[11:45:15] * marka has set the topic to: DHCPv6 Leasequery
[11:46:04] <mellon> DHCPv6 leasequery is needed for DOCSIS 3.0.
[11:46:20] <mellon> Need some way to recover tables associated with general DHCPv6 information in routers and relay agent kinds of devices.
[11:46:31] <mellon> As well as external access to IP lease data.
[11:46:58] <mellon> Client is a router, requests information using DHCPv6, uses usual relay agent configuration information to get there.
[11:50:58] <mellon> (Kim is basically describing the draft in detail)
[11:51:45] --- ogud has left
[11:54:19] <Hankins> (unknown speaker): Why not SNMP?
[11:54:29] <jinmei> He's Francis Dupont
[11:54:52] <Hankins> Kim: This information is substantially more complex than v4 information, and trying to create a v6 mib when we haven't even solved the problem of a v4 mib...it's like translating information into another language and translating it back again.
[11:55:58] <Hankins> Lemon: It's really hard to do this with SNMP. With DHCP, you can multicast a request to a well known multicast address. With SNMP you either have to define a similar well known multicast address, or you're going to have to configure these addresses manually.
[11:56:13] <Hankins> thanks Jinmei
[11:57:04] * marka has set the topic to: PAssive DAD for DHCP
[11:57:12] <mellon> Passive DAD. Don't know speaker's name.
[11:57:46] <mellon> They've modified the implementaiton to keep a client identifier table.
[11:58:36] <mellon> We have a router/relay agent. THe AUC is on the relay agent.
[11:58:50] <mellon> Builds association between DUID and MAC, tells us which IP addresses are in use for which MAC.
[11:59:03] <mellon> Sends packet to server in three possible scenarios.
[11:59:18] <mellon> "I see this new IP address in use." Server can mark it in use.
[11:59:34] <mellon> "I see a potential duplicate address." Sees same IP address for two different MAC addresses with two different DUIDs.
[12:00:04] <mellon> Also sends packet when it sees an unauthorized IP address - an IP address that is in use for a MAC address for which it doesn't have any entry in DUID/MAC table, meaning it hasn't seen any DHCP traffic for that IP/Mac address.
[12:01:11] <mellon> FInal decision is taken by DHCP server. AUC tells the DHCP server what it sees, DHCP server knows exactly how IPs are being assigned, and to which MAC address. DHCP server takes final decision - this is a duplicate address, or is not.
[12:01:31] <mellon> Traffic load, maximum pps sent from AUC to DHCP server is 57 packets. Not a lot of traffic.
[12:01:45] <mellon> 99% of the time, number of packets sent to DHCP server is less than five.
[12:02:12] <mellon> pDAD not performed during IP address acquisition. So low delay for mobile devices, in particular if we have devices that need fast handoff, this is going to help.
[12:02:28] <mellon> More reliable than current DAD, because DAD is based on ICMP, which is really slow, not adequate for realtime traffic.
[12:02:47] <mellon> Most firewalls block incoming ICMP requests. E.g. Windows, Mandriva 2005, Zonealarm firewall.
[12:03:14] <mellon> Duplicate address using pDAD can be discovered in realtime, not at moment of address acquisition. If I acquire address legally, doesn't mean someone isn't going to take it later on.
[12:03:25] <mellon> Duplicate address can also be resolved - e.g., FORCERENEW option.
[12:03:46] <mellon> Intrusion detection - unauthorized access easy to detect.
[12:04:03] <mellon> And we actually detected one in our experiments, says Heinrich.
[12:04:13] --- ogud has joined
[12:04:16] <mellon> Also detect VPN servers, like that.
[12:04:38] <mellon> Security is a big concern. DHCP infrastructure has to be secured, and it's not secured right now.
[12:04:51] <mellon> Not in scope of pDAD. pDAD doesn't introduce new vulnerability.
[12:05:09] <mellon> Main concern in security is role of relay agent. People were thinking of adding new functionality to relay agent.
[12:05:26] <mellon> Do we provide keys to relay agent?
[12:05:45] <mellon> What do we do about non-802.11 devices? THere is no MAC address, but they usually have unique identifier.
[12:06:13] <mellon> We have to think about this devices within rfc3315id draft. pDAD follows 3315id draft, so that takes care of it.
[12:06:33] <mellon> Changes to relay agents, logical functionality is an add-on, so no changes to actual relay agent implementation.
[12:07:10] <mellon> Last thing is IPv6. This architecture wouldn't work for stateless configuration, or mixed stateless/stateful. That is true, we wrote in draft, not supported in scenarios where we have any stateless configuration.
[12:07:18] <mellon> Would like to know what you guys think, any comments?
[12:07:23] <mellon> Jinmei-san.
[12:07:51] <mellon> Maybe this is already discussed, would like to clarify that DAD defined for IPv6 is also supposed to be used for addresses allocated by DHCPv6.
[12:08:13] <mellon> I personally think if we want to deal with delay in DAD for IPv6, should use already existing optimization for optimistic DAD.
[12:08:34] <mellon> Presentor: this draft is for v4, we just added a few lines at end of draft, no big problem in applying to IPv6 when no stateless configuraiton.
[12:08:55] <mellon> Not an expert, not saying we should replace existing IPv6 solution. I think this works for IPv4, might also be something you could do for v6.
[12:09:34] <mellon> Jinmei-san: main point is not stateless vs. stateful. My point is that there is already an existing mechanism for optimizing DAD whether stateless or stateful. Which one is better? This one or existing? Comparison could be better.
[12:09:46] <mellon> Presentor: not a real big issue of wg decides we should remove the comment.
[12:09:58] <mellon> Jinmei-san - personally don't have opinion about comparison between the two.
[12:10:16] <mellon> Mark Stapp: new process in relay agent, that process has a table in it, how is table reconstructed on reboot?
[12:10:21] <mellon> Presentor: if relay agent reboots?
[12:10:32] <mellon> If table is cleared, will have to be repopulated.
[12:10:45] <mellon> What's going to happen is that there will be some unnecessary traffic sent to DHCP server.
[12:11:13] <mellon> DHCP server when it receives packet from AUC, marks IP address as in use, so in a sense the DHCP server would have a copy of this table locally, and knows that that IP address has been marked in use because received packet from AUC.
[12:11:29] <mellon> If it gets rebooted, has to rebuild table. You might have some unnecessary traffic sent to tDHCP server.
[12:11:47] <mellon> MJS: if I were misbehaving host on AUC network, sent off ARPS for various addresses, what affect would that have?
[12:11:54] <mellon> Presentor: would mark those addresses as in use.
[12:12:14] <mellon> MJS: unless those kind of issues can be addressed, would not like to move something forward that people will think solves a problem when it introduces a worse problem.
[12:12:29] <mellon> Presentor: you have this problem today. You can still have a device that replies to every ICMP echo request.
[12:12:53] <mellon> MJS: but I don't have to introduce a new protocol that produces the same problem.
[12:13:00] <mellon> Presentor: I'm not claiming this solves that problem.
[12:13:12] <mellon> Henning: basic problem is that existing DAD doesn't work today.
[12:13:38] <mellon> Everything else you do WRT intrusion detection is gravy, but this is not replacement for IDS, it's a useful tool.
[12:13:56] <mellon> Told us things we didn't know before. Bad hosts, illegal non-assigned MAC addresses doing funny things.
[12:14:13] <mellon> Attempt to solve broken DAD that we have today. Today we have worst of both worlds - no working DAD, but we wait anyway.
[12:14:32] * marka has set the topic to: PAssive DAD for DHCP
[12:15:25] <mellon> Tim Chown: DHCPv4 and DHCPv6 in Dual-Stack networks.
[12:15:37] * marka has set the topic to: Tim: DHCPv4 and DHCPv6 in dual Stack networks
[12:15:55] <mellon> Previously we've been looking at issues of running dual-stack networks.
[12:16:40] <mellon> We looked at two general approaches - use DHCPv4 and DHCPv6 and merge what we get, other option is to add IPv4 options to DHCPv6.
[12:16:47] <mellon> We have minimal deployment experience.
[12:16:56] <mellon> Next step was to propose some best practices.
[12:17:16] <mellon> We expect a slow transition to IPv6. In interim dual stack will be common.
[12:17:36] <mellon> Might not be consistent - when we deploy dual-stack on wire, not all services are dual-stack. Might have dual-stack DNS but not NTP.
[12:17:57] <mellon> Some links may be IPv4-only or IPv6-only.
[12:18:10] <mellon> Also need to make sure when we preovide information it should be consistent.
[12:18:11] --- linsner has left
[12:18:21] <mellon> Merge draft is in formative stages.
[12:18:34] <mellon> Two main sections, one is a list of tools we think we can use to solve this problem. Looking into what might work or might not work.
[12:18:45] <mellon> No conclusions yet. Ideally come up with BCP recommendations.
[12:18:52] <mellon> Document will probably only be informational.
[12:19:05] <mellon> First, add some sort of DHCP preference option so server can inform client which service it should prefer answers from.
[12:19:16] <mellon> Second, add some dual-stack indicator so client can inform server that it's dual-stack.
[12:19:31] <mellon> Server if it's already seen DHCPv4 query, could omit repeated information in DHCPv6 response subsequently.
[12:19:47] <mellon> Next, DUID common for v4 and v6 with duid RFC published recently.
[12:19:58] <mellon> So a server might already know what was supplied to client.
[12:20:14] <mellon> Fourth tool, use some DHCPv6 option to tell client to use DHCPv4 all the time.
[12:20:23] <mellon> Fifth thing, use IPv4-mapped addresses in DHCPv6 responses.
[12:20:43] <mellon> Stig: clarification, for this DHCPv6 option to tell it to use DHCPv4, might as well have option to say don't use DHCPv4.
[12:21:25] <mellon> DUID - if you are trying to use DUID to track whether you've seen same queries, may be more difficult if v4 and v6 services are running on separate servers.
[12:21:34] <mellon> Also could use server DUID.
[12:21:56] <mellon> If you look at RFC3315, says DHCPv6 servers should have unique DUIDs. Would you consider having same DUID for v4 and v6 server, or should they be different?
[12:22:22] <mellon> Where do you put intelligence? Inform server you're dual-stack, let server decide what to send.
[12:22:30] <mellon> Or give info to client, give it preference hint.
[12:22:41] <mellon> We do make assumption that information is being managed in a consistent way.
[12:22:59] <mellon> mapped addresses.
[12:23:23] <mellon> If you just had a preference option, if you had two v4 and two v6 servers, you could order them. If you have mapped addresses you can order them how you like.
[12:23:43] <mellon> What about resiliance? We need consider that you may be dual stack, may lose your v4 or v6 connectivity.
[12:23:51] <mellon> If you put intelligence in server you are perhaps a little less flexible.
[12:23:57] <mellon> May be better to pass info to client with preference hints.
[12:24:18] <mellon> Need to discuss way forward.
[12:24:28] <mellon> Is this work timely?
[12:25:58] <marka> ted: this is interesting and useful work. maybe to early, likes client smart.
[12:26:27] <marka> create a list of things that can be configured then look for issues
[12:27:03] <marka> too early for specific recomendations but we can still say some stuff
[12:27:23] <marka> steg: do we right up the stuff
[12:27:31] --- gdweber has left
[12:27:46] <marka> ted: info draft of things that need to be covered
[12:28:06] <marka> tim: only one deul product today
[12:28:27] <marka> hankins: too early but interesting
[12:28:42] <marka> need eol for v4
[12:29:17] <marka> steg: any dual stack client?
[12:30:05] <marka> ted: working on one. stupid. defers to "network manager" for resolution of conflicts
[12:30:40] <marka> tim: should we start now or defer
[12:30:48] <marka> ted: defer
[12:31:32] <mellon> ??: the process is valuable (Peter Bl??) even if we're not ready to do it yet.
[12:31:37] <mellon> ready to specify anything yet.
[12:33:18] <mellon> DOCSIS 3.0 normally assumes that devices will do either v4 or v6 but not both.
[12:33:43] <mellon> There's an alternative mode. We can write into specifications what should be done in dual-stack configuration.
[12:33:55] <mellon> My question to stig a second ago, we had suggestion to publish informational RFC.
[12:34:02] <mellon> Where are we now with that?
[12:34:16] <mellon> Tim: I think going through options, see where this really matters, is a good idea.
[12:34:21] --- andreaf has left
[12:34:31] <mellon> Is it a wg item?
[12:34:32] <mellon> Yes.
[12:34:54] <mellon> Almost on time, if there are no other comments, if you have been taking notes, send them to one or both of us, we'll integrate into minutes.
[12:34:57] * marka has set the topic to: closed
[12:35:02] <marka> closed
[12:35:10] --- jinmei has left
[12:35:15] --- Hankins has left
[12:35:27] --- arifumi@2entwine.net has left: Logged out
[12:35:46] --- mellon has left
[12:37:05] --- narten has left
[12:39:05] --- marka has left
[12:40:35] --- miyahiro has left
[12:41:43] --- ogud has left
[12:44:01] --- FDupont has left
[12:58:04] --- jjmbcom has joined
[13:26:21] --- FDupont has joined
[13:26:25] --- FDupont has left
[13:27:37] --- jjmbcom has left
[16:47:19] --- andreaf has joined
[16:50:04] --- andreaf has left
[18:38:31] --- HannesTschofenig has joined
[19:37:32] --- HannesTschofenig has left