[05:38:16] lmwangi joins the room [06:06:58] lmwangi leaves the room [16:19:48] ꈲ joins the room [17:00:58] yohba727 joins the room [17:01:03] yohba727 leaves the room [18:28:06] ꈲ leaves the room [18:56:12] brian.bnsmith joins the room [19:22:31] ꈲ joins the room [19:49:36] ꈲ leaves the room [19:53:15] ALDE joins the room [19:55:04] Hi there... anybody knows where are the slides thank you. [19:55:16] ALDE leaves the room [19:57:05] Dave Thaler joins the room [19:57:16] Alex Petrescu joins the room [20:00:11] rossce1 joins the room [20:00:29] rossce1 leaves the room [20:01:39] ꈲ joins the room [20:05:59] agenda at: http://www.ietf.org/proceedings/10mar/agenda/6lowpan.txt [20:06:23] consolidated-slideset at: http://www.ietf.org/proceedings/10mar/slides/6lowpan-0.pdf [20:07:21] Colman Ho joins the room [20:07:46] Colman Ho leaves the room [20:07:48] h-suzuki joins the room [20:07:54] yohba727 joins the room [20:08:53] Colman Ho joins the room [20:09:07] Ed Beroset joins the room [20:09:50] ryuji@Anaheim joins the room [20:10:43] Ulrich Herberg joins the room [20:11:09] thrasher joins the room [20:12:59] I'm monitoring the progress from another meeting, I want to know when you get close to the ND item on the agenda so I can head over [20:13:42] Pete St. Pierre joins the room [20:13:53] I'll try to give you a few minutes notice when ND item is imminent. [20:13:53] I am having dinner at the same time, I wait for the SLAAC short addresses and prefixes in RA... [20:14:00] thanks Ed [20:14:09] np [20:14:19] thnak [20:14:19] s [20:15:25] 80bit prefixes can't work with certain RFCs in the SLAAC family... only /64 works. [20:15:52] shall I relay now or do you want me to wait to the end? [20:16:06] Ed, thanks, no relay needed now. [20:16:12] ok [20:20:00] yuichi igarashi joins the room [20:22:17] thanks! [20:22:18] zdshelby joins the room [20:22:38] yuichi igarashi leaves the room [20:22:52] yuichi igarashi joins the room [20:23:05] Wes Beebee joins the room [20:23:05] gridmerge joins the room [20:23:32] shep joins the room [20:23:42] what slide are you on now [20:23:47] Dave Thaler: the nd-08 is the next item on the agenda and the lines at the mic are short, so it's probably going to start soon. [20:23:55] We're on slide 10 [20:24:12] but we've already been to 11 [20:24:30] the 6lowpan agenda does not have the relevant draft names... would be good in the future to include the id draft names [20:24:30] momose joins the room [20:25:14] colin.oflynn joins the room [20:25:19] shep: agreed -- I'll pass that on to Goeff and Carsten as a request [20:25:25] rababy joins the room [20:25:41] in particular, which draft is relevant to this talk that is just now about to end? [20:26:02] must draft something 6lowpan something nd-0X.txt [20:26:03] I do see the list at http://tools.ietf.org/wg/6lowpan/ [20:26:42] This might be (slightly) clearer http://tools.ietf.org/wg/6lowpan/agenda?item=agenda77.html [20:27:34] in the slide first page they say draft-ietf-6lowpan-hc-06 [20:28:33] however in the draft I can't find the idea of "80" bit prefixes for SLAAC. [20:29:18] yeah, it's the prefix length stuff I wanted to see the text in the draft about [20:29:30] Ulrich Herberg leaves the room [20:29:31] yohba727 leaves the room [20:30:11] momose leaves the room [20:30:20] thrasher leaves the room [20:30:21] behcet.sarikaya joins the room [20:30:33] momose joins the room [20:30:42] Ulrich Herberg joins the room [20:30:56] We could ask whether this 80bit prefixlen has been documented anywhere or is it just floating the idea on the slide. [20:31:11] ꈲ leaves the room [20:31:34] I'll ask [20:31:44] thanks [20:31:50] Andrew McGregor joins the room [20:31:52] sorry it's 111bit prefixlen [20:32:36] I think it is to handle short addresses [20:33:01] ok, thanks. [20:33:40] we're on slide 12 [20:33:41] zdshelby leaves the room [20:34:06] next up is ND-08 [20:34:09] I have two comments, but don't want to use up meeting time by going to the microphone. (1) I thought IPv6 addressing architecture precluded any prefix lengths longer than 64 bits. (2) I thought that 6-byte ethernet addresses had a bit (the 2nd least significant bit in first byte) which is used to indicate if the address uniqueness is achieved via global allocation or via local administrative responsibility... so the use of the pseudo ethernet address on his slide would want that bit to always have a particular value. [20:34:27] (1) no. SLAAC just doesn't work with ones that are longer. [20:34:40] v4-mapped addrsses are an example of a prefix > 64 [20:35:19] actually they're precluded for anything that doesn't start with binary 000 [20:35:27] that's what you're referring to I think [20:35:39] (v4-mapped aren't DADed either, don't respond to MAC address resolution either...) [20:35:48] The proposal is just 1) to remove the PAN ID and then 2) whether you slide in 0xfffe in the middle or put a 1 in the 17th bit [20:35:49] ah, so maybe (1) is OK in this context. Thanks for the clues. [20:35:53] RFC 4291 section 2.5.1: "For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format." [20:36:18] you can have a 64-bit interface id that contains a bunch of 0's on the left [20:36:29] So this is a proposal for an IID specification really [20:36:37] that's how I understood it yes [20:37:02] But the Modified EUI-64 format is important (i.e. it reserves the 'u' bit for a specific purpose) [20:37:12] I agree [20:37:33] I am ambivalent as long as the U/L bit is preserved [20:38:02] me too [20:38:32] hmm... yet DHCPv6 doesn't deliver U/L bits (i.e. 1::1/127 is possible with DHCPv6) [20:38:47] 1:: starts with binary 000 [20:40:09] 8888::1/127 is not legal but 1::1/127 is. [20:40:13] yuichi igarashi leaves the room [20:40:15] righht the address arch document. [20:43:57] is there any assumption that a node can only have 1 EUI-64? [20:45:48] and what about IIDs constructedusing other methods like RFC3041, CGAs, etc? [20:45:56] are those precluded? [20:46:16] Dave: Are you in the room or should I relay? [20:47:37] (apparently Dave is in the room since he is now speaking at the mic) [20:47:40] ah, that answers my question. :) [20:47:42] :-) [20:50:27] :) [20:50:54] yeah I came in to the room just before Zach got up so thanks for the time warning Ed [20:53:27] that assumes EUI-64s are not just vendor unique but globally uniques [20:54:33] so this is a multilink subnet with onlink prefixes, with all the issues in RFC 4903? [20:55:04] or is it something else? (autoconf is different as it's the offlink model I believe) [20:55:19] yes, I was wondering the same thing as Dave... [20:55:53] Dapeng Liu joins the room [20:57:13] ok here's the answer on this slide, it's also the offlink model (not L set) [20:57:18] Wes Beebee leaves the room [20:57:57] so the end host does not believe it's on a common subnet [20:58:09] is that in the draft? [20:58:15] zdshelby joins the room [20:58:15] it's on the slide [20:58:21] don't know about draft [20:58:29] http://tools.ietf.org/id/draft-chakrabarti-6lowpan-ipv6-nd-simple-00.txt [20:58:57] section 7.3: "An RA MUST carry Prefix information option with L bit being unset" [20:59:03] It's like the MANET architecture with routers doing L3 forwarding on the same prefix [20:59:05] (thanks Ed for the doc ptr) [21:00:28] yep [21:02:00] sectionb 4 says, with respect to my previous question about multiple IPv6 addresses: "Other IPv6 addresses, including those based on 16-bit IEEE 802.15.4 short addresses, are out of scope." [21:02:10] :-) [21:03:52] Overall I don't understand why "Basic idea is for routers to listen to RA and use that in the RA they send"... they could do so with every packet not only RA. [21:07:14] (no need to relay, I'll ask on the list later). [21:08:04] ok [21:09:58] we've backed to slide 26 which asks the question, "what is missing in RFC 4861?" [21:13:12] back to "Open Issues" (slide 42) [21:18:16] Pascal's point is a good one - all this information could be distributed in RPL DIOs thus making this optional [21:18:32] or in MEXT RAs two drafts :-) [21:18:43] Assuming the 6LBR is a DODAG root which is highly likely [21:18:51] or with RFC "more specific routes" [21:20:04] Erik says this does something which a routing protocols does... ok, but a routing protocols also avoids loops - does this too? [21:20:23] yohba727 joins the room [21:20:24] (I'll write this to list too some day). [21:21:43] momose leaves the room [21:23:06] momose joins the room [21:23:26] ("more specific routes" == RFC 4191) [21:23:32] :-) [21:23:34] many indicate that short addresses must be supported; a few say that "use DHCP6" is the way to do that [21:23:47] gridmerge: Not quite. Hosts have no concept of a routing algorithm. [21:24:11] some hosts do. see RFC 4191 section 3 [21:24:16] beroset: Yes, this is exactly the consensus we had after Hiroshima. [21:24:24] Tina TSOU joins the room [21:24:27] there's 3 classes of hosts [21:26:04] depending on what you mean by routing algorithm [21:27:24] This is propagation not routing which may not be quite the same. You need meta-routing to establish routing :-) [21:27:39] why does it "propagate" prefixes if not for routing? [21:27:49] For autoconfiguration [21:28:14] autoconf needs more than just prefixes... needs multicast to work too needs every other bit in RA not only the prefix... [21:29:54] (the NA, the NS, the RS everything... not just prefixes). [21:30:40] the default route too :-) [21:34:02] I like clean slate. [21:40:23] velt joins the room [21:50:36] very few indicate implementation of 2003; maybe a dozen for 2006 [21:51:30] I think it is good enough O:) [21:52:02] I counted one, but perhaps he was just stretching... [21:52:55] Dapeng Liu leaves the room [21:53:40] mcharlesr joins the room [21:56:14] Geoff at the mic [22:00:02] Ulrich Herberg leaves the room [22:00:46] momose leaves the room [22:02:33] Pete St. Pierre leaves the room [22:02:55] does he use slides? [22:02:58] ryuji@Anaheim leaves the room [22:03:08] Yes, he has slides [22:03:31] we're now on slide 51 of this http://tools.ietf.org/agenda/77/slides/6lowpan-0.pdf [22:06:21] YEs makes sense. [22:07:10] Yes - I think this makes a lot of sense, and support this as well [22:09:28] There are security implications, e.g. if we get addresses from any old DHCP server. [22:09:51] still probably worthwhile [22:10:16] using DHCPv6 would let one manage the node's 15.4 short address & IPv6 address from one location, and also ensure IPv6 addresses match required short addresses for maximum compressibility [22:10:23] right. [22:10:25] I have no problem if someone wants to use DHCPv6. But this might be too much work for this WG right now. Maybe in the future? [22:11:41] behcet.sarikaya leaves the room [22:11:48] zdshelby leaves the room [22:11:49] Dave Thaler leaves the room [22:11:54] shep leaves the room [22:11:55] We have two months to get a solution... [22:11:59] gridmerge leaves the room [22:12:13] Colman Ho leaves the room [22:12:22] It's much easier to extend/modify an existing DHCPv6 message than defining a new protocol, I guess. [22:12:56] now we're even more done than we were 15 minutes ago [22:13:01] :) [22:13:13] thanks Ed. [22:13:15] h-suzuki leaves the room [22:13:23] colin.oflynn leaves the room [22:13:37] Ed Beroset leaves the room [22:13:38] seems adjourned? [22:13:52] bye. [22:14:09] Alex Petrescu leaves the room [22:16:45] Andrew McGregor leaves the room [22:17:48] rababy leaves the room: Computer went to sleep [22:18:56] it's very funny what you pick up from the mic after the session is over. [22:25:57] Colman Ho joins the room [22:27:19] Colman Ho leaves the room [22:28:09] velt leaves the room [22:31:29] yohba727 leaves the room [22:33:19] h-suzuki joins the room [22:34:50] h-suzuki leaves the room [22:36:43] Tina TSOU leaves the room [22:38:53] ꈲ joins the room [22:40:00] ryuji@Anaheim joins the room [22:43:17] ryuji@Anaheim leaves the room [22:46:34] mcharlesr leaves the room [23:41:14] ꈲ leaves the room